GKE држи 30.000 AI-песочници во еден кластер, но warm pool троши капацитет

Во објавата од 29 септември 2026 година, Google Cloud ги претстави како општо достапни приспособувањето на GKE Agent Sandbox за обука со засилување, неговиот SDK за оркестрација и интеграциите; Jean-Malo Delignon, истражувачки инженер во Mistral AI, го опиша нивното оптоварување со зборовите „handle spikes of over 30,000 sandboxes on a single cluster“. Станува збор за пик од над 30.000 изолирани околини во еден кластер што го пријавува корисникот, а не за гарантиран капацитет на секој GKE кластер.

Брзото доделување околини зависи од SandboxWarmPool: тој ги подготвува пред да пристигне задачата, па дел од кластерските ресурси остануваат зафатени додека околините чекаат. Прегледот на Yeekal ги пренесува резултатите од тестовите на Google: времето до првата команда се намалило од 45–85 на 1–9 секунди, најдолгото чекање од 7,5 минути на помалку од 10 секунди, а создавањето подови приближно трипати. Овие мерења се од споредбена тест-конфигурација, не од објавен тест на кластерот на Mistral AI.

Зошто студениот старт го забавува RL

Во обуката со засилување, моделот создава дејства, меѓу нив и програмски код, кои се извршуваат во изолирани околини за да се добие повратен сигнал. Кога голем број обиди почнуваат истовремено, секоја нова околина треба да се распореди на јазол, да ја добие соодветната контејнерска слика и да заврши со иницијализацијата. Кај синхронизиран циклус, и најбавната околина може да го задржи следниот чекор на обуката, па акцелераторите чекаат на подготвеноста на околините наместо да обработуваат резултати.

SandboxWarmPool одржува веќе стартувани и здрави подови што може да се доделат на ново барање. GKE Image Streaming и однапред планираното распоредување на сликите го поместуваат нивното вчитување пред моментот кога обидот ќе побара околина. Тоа има тежина кај задачи што користат многу различни, големи слики: кешот на еден јазол не може да ја содржи секоја потребна слика, а преземањето за време на циклусот повторно го продолжува чекањето. SDK може и да ја употреби истата околина за следен обид, со што се намалува создавањето нови подови.

Колку капацитет чини подготвениот базен

Подготвениот под зафаќа процесор, меморија и место во кластерот и кога сè уште нема задача. Затоа голем топол базен го намалува ризикот од чекање при бран барања, но остава повеќе ресурси во мирување меѓу брановите. Премал базен брзо се празни; следните барања повторно го минуваат патот на студено стартување додека контролерот создава замени. Брзината со која базенот се пополнува е исто толку важна колку и неговата почетна големина.

За помал тим, компромисот може да се изрази како споредба меѓу резервираниот капацитет за околините и чекањето што го предизвикуваат празен базен или бавно пополнување. Ако акцелераторите често запираат на крајот од синхронизиран бран, дополнителните подготвени околини може да имаат економска смисла. Ако обидите пристигнуваат ретко или можат да почекаат, истата резерва поголем дел од времето само зафаќа ресурси. Ова е начин да се процени сопственото оптоварување, а не објавена пресметка за трошоците на Mistral AI.

Одлуката зависи од распределбата на времето до првата команда, особено кај најбавните барања, и од времето што акцелераторите го минуваат во чекање. Заедно со нив треба да се гледаат бројот на слободни подготвени околини, колку често базенот се празни, времето потребно повторно да се наполни и искористеноста на резервираниот процесор и меморија. Неуспешните околини исто така се важни: ако обидот мора да се повтори, брзото прво доделување само по себе не го скратува целиот циклус на обука.

Каде завршува Sandbox, а каде почнува Substrate

GKE Agent Sandbox обезбедува изолирани околини за извршување код; неговиот контролер го одржува топлиот базен и го ограничува темпото на пополнување за наглиот бран да не го преоптовари Kubernetes API. RL SDK ги доделува околините на обидите, го планира нивното распоредување и може да ги рециклира постојните подови меѓу обиди. Kubernetes и понатаму ги управува подовите, јазлите и ресурсите на кластерот. Со помалку непотребно создавање и бришење подови, контролниот слој има помалку работа токму кога пристигнуваат многу барања.

Во објавата за Agent Substrate од 15 септември 2026 година, Google Cloud опишува посебен извршен слој со сопствен контролен слој за распоредување и брзо паузирање и продолжување на долготрајни агенти. Неговите работнички процеси ги преземаат честите активирања, додека Kubernetes ги управува машините и работничките подови. Тоа е поинаква поделба на работата од RL тестовите со Agent Sandbox и SDK: забрзувањето на студениот старт во тие тестови не бара секое извршување да помине низ Agent Substrate.

Што кажуваат пријавениот пик и тестовите

Пикот на Mistral AI покажува дека конкретна продукциска поставеност опслужувала голем бран изолирани околини во еден кластер. Споредбените тестови одговараат на друго прашање: колку побрзо конфигурацијата со топол базен, пренос на слики и SDK стигнува до првата команда од директното создавање Kubernetes подови. Затоа бројот на околини кај корисникот не треба да се меша со обемот на споредбениот тест, ниту измереното забрзување да се припише само на SandboxWarmPool.

Последицата за тимовите што планираат слична обука е конкретна: капацитетот на базенот треба да одговара на нивните бранови барања и на цената на застојот на акцелераторите. Поголем базен купува пократко чекање само додека има доволно подготвени околини и додека пополнувањето може да го следи темпото на новите задачи. Меѓу брановите, истиот тој капацитет останува резервиран.

Прочитајте и:

• Еден кодиран знак го заобиколи WAF: PeopleSoft повторно е масовно напаѓан