Představa, že umělá inteligence navrhuje a optimalizuje systémy pro běh svých vlastních nástupců, přestává být teoretickým konceptem z futurologických esejí. Vývojářský tým čínské laboratoře Zhipu AI zveřejnil detailní technickou zprávu o tom, jak model GLM-5.3 vybudoval produkční inferenční infrastrukturu pro odlehčenou verzi GLM-5.3-Flash. Během necelých dvou týdnů dokázal autonomní agent ztrojnásobit propustnost obřího klastru čítajícího více než 100 000 domácích čínských akcelerátorů. Tento průlom demonstruje propastný rozdíl mezi pasivním webovým chatovacím oknem a skutečnou agentní architekturou zapojenou do inženýrské praxe.
Stotisícový klastr bez Nvidie a neprobádaný hardware
Když tým Zhipu AI připravoval spuštění modelu GLM-5.3-Flash, stál před bezprecedentní inženýrskou výzvou. Provoz modelu s kontextovým oknem o délce jednoho milionu tokenů a multimodálními schopnostmi bylo nutné zajistit na klastru více než 100 000 čínských AI akcelerátorů. V takovém měřítku domácí čínský křemík doposud nikdo nenasadil.
Inženýři naráželi na tvrdé limity: omezenou kapacitu a propustnost pamětí čipů, nezralý softwarový ekosystém, neúplnou podporu nízkoúrovňových výpočetních jader (kernelů) i chybějící dokumentaci. V běžném vývojovém cyklu by optimalizace takto rozsáhlé infrastruktury zabrala týmu zkušených systémových inženýrů celé měsíce. Místo toho většinu práce převzal autonomní Infra Agent poháněný modelem GLM-5.3.
Výsledek se v praxi projevil okamžitě. Model GLM-5.3-Flash byl nejprve anonymně testován na platformách OpenCode a OpenRouter pod označením Ox-Alpha. Během prvních šesti dnů zpracoval přes 62 bilionů tokenů a stal se nejvyužívanějším modelem na obou platformách, přičemž dosáhl hardwarové efektivity i nákladů na token srovnatelných s moderními GPU od Nvidie.
Webový chat vs. agentní AI: Proč samotné psaní kódu nestačí
Úspěch projektu ukázal hluboký technologický předěl současné umělé inteligence: rozdíl mezi pasivním webovým rozhraním a autonomním agentem.
Většina uživatelů zná AI jako webové chatovací rozhraní (například ChatGPT, Claude nebo Kimi v prohlížeči). V tomto režimu funguje velký jazykový model jako jednorázový textový prediktor. Uživatel vloží zadání, model vygeneruje kód a proces tím končí. Model nemá žádnou vazbu na reálné prostředí: netuší, zda jím navržený kód lze zkompilovat, jestli netrpí numerickou nestabilitou, jak zatěžuje mezipaměť grafického procesoru nebo zda nezpůsobuje zablokování procesorových vláken. Pokud kód selže, veškerá diagnostika a ruční přepis chybových hlášek zůstávají na člověku.
Naproti tomu agentní AI (v tomto případě specializovaný Infra Agent) pracuje jako aktivní účastník inženýrského procesu v uzavřené smyčce:
- Autonomní formulace hypotéz: Na základě zadaného cíle agent analyzuje kód i systémové metriky a sám navrhuje konkrétní inženýrské úpravy.
- Přímý přístup k nástrojům a prostředí: Agent samostatně upravuje zdrojový kód v jazycích C++, Pythonu a Tritonu, spouští kompilaci a provádí lokální mikrobenchmarky.
- Práce s dynamickým kontextem: Místo statického čtení repozitáře sleduje časové osy provádění instrukcí, latenci jednotlivých jader a vytížení paměťových sběrnic.
- Iterativní validace: Změnu nepovažuje za hotovou po vygenerování textu, ale teprve ve chvíli, kdy projde sadou lokálních testů správnosti a výkonnostních měření. Pokud úprava způsobí pokles výkonu nebo chybu v zaokrouhlování, agent ji okamžitě zahodí nebo přepracuje.
Princip husté zpětné vazby (Dense Feedback)
Vývojáři Zhipu AI zdůrazňují, že schopnost modelu psát kvalitní kód by sama o sobě nestačila. Tradiční monitorovací metriky jsou pro autonomního agenta příliš hrubé. Pokud model po změně obdrží pouze informaci, že celková propustnost klesla o 20 % nebo že selhal koncový integrační test, nedokáže určit, ve které vrstvě systému chyba nastala.
Tým proto vybudoval prostředí postavené na takzvané husté zpětné vazbě (Dense Feedback). Tato metodika stojí na třech pevných pilířích:
- Lokální zaměření: Zpětná vazba je vázána na konkrétní výpočetní jádro, konkrétní parametry spuštění nebo přesně vymezené časové okno provádění, nikoli na celý systém jako celek.
- Nízká cena a rychlost měření: Ověření hypotézy probíhá na izolovaných mikrobenchmarkových testech během sekund, aniž by bylo nutné pokaždé nasazovat celý klastr a čekat na rozsáhlé zátěžové testy.
- Objektivní verifikace: Výsledky se striktně porovnávají s referenční implementací z hlediska numerické tolerance a reálného času běhu.
Tři inženýrské oříšky, které agent vyřešil
Zpráva Zhipu AI dokumentuje konkrétní případy, kdy Infra Agent odhalil anomálie, které by lidským vývojářům snadno unikly:
1. Skrytá numerická chyba v dlouhém kontextu
Při optimalizaci paralelismu kontextu (Context Parallelism) v jádře KDA docházelo při dlouhých textech k postupné degradaci výstupů. Agent porovnal výstupy rozděleného a nerozděleného výpočtu na úrovni jednotlivých tenzorových operací. Odhalil, že volání tl.dot ve frameworku Triton standardně využívalo formát TF32 namísto FP32, což vedlo k postupné akumulaci zaokrouhlovacích chyb. Agent nastavil operace do režimu input_precision="tf32x3", čímž chybu eliminoval při zachování vysokého výkonu tenzorových jader. Oprava byla následně oficiálně začleněna do upstream repozitáře Flash Linear Attention (PR #1180).
2. Odhalení úzkého hrdla v zámku Python GIL
Při souběžném přenosu mezipaměti klíčů a hodnot (KV Transfer) a fázi prefill zaostával výkon o více než 20 % za stanoveným cílem. Podrobná analýza časové osy ukázala, že přenosy se nepřekrývají s výpočty. Agent vystopoval problém až na rozhraní mezi Pythonem a C++ v knihovně DeepEP v1.2.1: funkce intranode_dispatch a intranode_combine při čekání procesoru na data z grafického čipu neuvolňovaly globální zámek interpretu (Python GIL). Vlákno obsluhující přenosy tak zůstávalo zablokované. Po úpravě kódu a včasném uvolnění zámku klesl výkonnostní propad pod 1 %.
3. Odstranění zbytečných výpočtů v jádře KDA Decode
Při ladění jádra pro generování odpovědí agent zjistil, že původní implementace dělila data podél dimenze V způsobem, který vedl ke čtyřnásobnému opakování identické normalizace v plné přesnosti FP32. Agent sloučil tato vlákna do jediného bloku, uchoval mezivýsledky přímo v registrech a nahradil redundantní operace jedinou redukcí na úrovni warpu. Tímto zásahem zrychlil běh jádra 1,71×.
Architektura EPD a cesta k rekurzivnímu zdokonalování
Kromě ladění jednotlivých jader agent pomohl nasadit disagregovanou architekturu Encode-Prefill-Decode (EPD), která fyzicky odděluje kódování vstupu od samotného generování textu. V kombinaci s kvantizací vah i aktivací W8A8 a hybridní kvantizací mezipaměti KV (kombinující formáty INT8, FP8 a BF16) dokázal systém ztrojnásobit celkovou propustnost klastru.
Vzniká tím uzavřený inženýrský cyklus: model optimalizuje systém a systém následně provozuje model. V odborné komunitě se pro tuto schopnost vžilo označení rekurzivní sebezdokonalování (Recursive Self-Improvement neboli RSI). Tým Zhipu AI však zůstává nohama na zemi a upozorňuje, že plné RSI zatím nenastalo. Klíčové mantinely, strategické zadání cílů a finální kontrolu bezpečnostních rizik mají stále v rukou lidští vývojáři. Zkušenost ze stotisícového klastru však ukazuje, že v roli systémových inženýrů a ladičů nízkoúrovňového kódu jsou agenti připraveni převzít hlavní díl práce.
Co je to Infra Agent a jak se liší od běžného kódovacího asistenta?
Běžný kódovací asistent pouze generuje textový návrh kódu v chatu. Infra Agent naproti tomu autonomně operuje v reálném vývojovém a běhovém prostředí: sám mění kód v repozitáři, spouští mikrobenchmarky, profiluje systémové stopy na hardwaru a na základě naměřených výsledků iteruje řešení až k ověřenému cíli.
Na jakém hardwaru klastr Zhipu AI běží?
Systém pohání více než 100 000 domácích čínských AI akcelerátorů. Přesný typ výrobce zpráva nespecifikuje, ale potvrzuje, že díky softwarovým optimalizacím dosáhl klastr nákladové a výkonnostní efektivity na úrovni běžných grafických čipů NVIDIA.
Co znamená zkratka EPD v moderních inferenčních systémech?
EPD označuje disagregovanou architekturu Encode-Prefill-Decode. Zpracování vstupního textu (prefill) a následné generování jednotlivých tokenů (decode) mají odlišné hardwarové nároky. Jejich oddělení na různé uzly klastru zabraňuje zbytečnému čekání a výrazně zvyšuje propustnost.
