Provozuji podstatnou část své práce na vlastním hardwaru: pod stolem mi běží NVIDIA DGX Spark a na něm lokální jazykové modely. Důvod je věcný — data, která nechci posílat do cizího datového centra, a náklady, které nerostou s každým dotazem.
Jeden večer minulý týden se ten stroj dvakrát sám vypnul. Bez chybové hlášky, bez záznamu v logu. Nakonec se ukázalo, že jde o známou vadu, kterou výrobce přiznává na svém fóru — ale cesta k tomu zjištění byla zajímavější než ta vada sama. Tenhle text je o té cestě a o třech pastech, které na ní čekají.
Jak se hledá příčina, po které nezůstane stopa
Stroj nespadl. Vypnul se — se souborovým systémem poškozeným uprostřed zápisu a bez jediného řádku, který by napovídal proč. To je nepříjemné, protože běžné nástroje na hledání příčin pracují s tím, co systém stihl zapsat.
Když chybí přímý důkaz, zbývá vylučovat. Čtyři kontroly, každá odstraní jednu třídu příčin:
- Diagnostika pádu jádra byla aktivní a prázdná — kdyby šlo o pád jádra, byl by v ní záznam.
- Systém je nastavený tak, že se po pádu jádra zastaví, nerestartuje — stroj by zůstal zapnutý.
- Hlídací časovač, který by zatuhlý systém restartoval, za běhu aktivní není — ani zamrznutí by ho nevyplo.
- A stroj byl vypnutý, ne restartovaný. Musel jsem ho zapnout tlačítkem.
Poslední bod je rozhodující: software neumí odebrat napájení. Všechny softwarové způsoby selhání, které ten stroj má k dispozici, nechají počítač zapnutý. Zbývalo tedy něco pod operačním systémem — a to vede k vestavěnému řadiči na desce, který při teplotní špičce odpojí napájení rychleji, než systém stihne cokoli zaznamenat. Výrobce to na svém fóru potvrzuje jako známý problém a doporučuje snížit maximální takt GPU zhruba o devět procent. Stojí to kolem pěti procent výkonu a od té doby je klid.
Ten postup funguje i jinde než u hardwaru: když chybí důkaz o tom, co se stalo, hledejte důkazy o tom, co se stát nemohlo.
Past první: dohled, který hlásí zelenou
Celé to začalo tím, že mi přestali odpovídat AI asistenti na Telegramu — a hlídací služba přitom hlásila, že je všechno v pořádku. Čtyři a půl hodiny.
Dalo se restartovat a jít spát. Zajímavější bylo zjistit, proč kontrola nic nenašla. Systém spouští sedm asistentů a otázka „běží všichni?" se vyhodnocovala z těch, kteří naběhli. Šest ze šesti odpovídalo. Sedmý se nespustil vůbec, takže v seznamu nebyl, takže ho nikdo nepostrádal.
Sčítání přeživších nikdy nenajde mrtvého.
Není to problém hardwaru ani AI. Je to nejběžnější způsob, jak selhává dohled nad čímkoli automatizovaným, a je zákeřný tím, že zelená kontrolka vypadá stejně jako skutečné zdraví. Když dnes u klientů zavádíme automatizaci, tohle je jedna z prvních otázek: proti čemu se ta kontrola porovnává? Odpověď „proti tomu, co běží" znamená, že kontrola z principu neumí najít to, co chybí.
Past druhá: nejelegantnější vysvětlení
Při rekonstrukci prvního pádu se nabídl čistý příběh. Vyfotil jsem tentýž večer oběd a účtenku pár sekund po sobě; z obou fotek se spustilo zpracování lokálními modely, zrovna když na stroji běžel ještě jiný agentní systém. Čtyři modely naráz, chyby alokace paměti v logu, o šest minut později konec.
Byl to dobrý příběh a dal by se podle něj postavit celý systém opatření. Než na to došlo, zkusil jsem ho vyvrátit — a nepřežil to:
- K přetěžování paměti vůbec nedošlo; modely se načetly vedle sebe, nic se nevytlačilo.
- Chyby alokace jsou na tom stroji běžné. Jeden den jich bylo 105 a nestalo se nic; v den pádu jich bylo 7.
- Stejná kolize proběhla bez následků den předtím i den potom.
- Chyby ustaly šest minut před pádem — a vyčerpaná paměť neumí odebrat napájení.
Kolize byla nutná, ale ne dostačující: vyhnala zátěž na maximum, jenže rozhodující proměnná byla teplota, ne paměť. Kdyby ten příběh zůstal neověřený, opatření by mířila proti nesprávné příčině — a při dalším horkém dni by stroj spadl znovu.
Vyvrátit vlastní hypotézu je levnější než stavět podle ní.
Past třetí: jedno měření není vzorek
Pak přišla otázka, jak zabránit tomu, aby si dva systémy šlapaly po GPU. Změřeno: 10,5 % vytížení. To vypadá na spoustu volného místa a návrh by z toho vycházel.
Než z toho něco vzniklo, stačil jeden dotaz do historie čtyř měsíců: 46,5 % v nejsilnějším dni a šest dnů v měsíci nad 24 %. To, co bylo změřeno, byl shodou okolností nejtišší úsek týdne.
Návrh se tím podstatně změnil. Cena té kontroly byla jedna minuta.
Co mají ty tři pasti společného
Ve všech třech případech je po ruce veličina, která vypadá jako odpověď na otázku, ale odpovídá na jinou. Počet běžících procesů místo počtu očekávaných. Věrohodný příběh místo ověřeného mechanismu. Jedno okno místo rozsahu.
Když se dnes dívám na cizí systém, tohle hledám jako první: co ta metrika ve skutečnosti měří — a jak by vypadala, kdyby bylo zle? Metrika, která ve zdraví i v poruše vypadá stejně, není metrika.
Co z toho plyne, pokud zvažujete lokální AI
Nejdřív to podstatné: stojí to za to. Lokální modely dávají smysl všude, kde data nemají opustit firmu, nebo kde by objem dotazů v cloudu byl neúnosný. Ten stroj mi běží dál a dělá práci, kterou bych jinak platil po tokenech.
Ale je to infrastruktura, ne spotřebič. Konkrétně:
- Počítejte s provozem. Ne s denní administrací, ale s tím, že se občas něco stane a někdo to musí umět vyšetřit.
- Dohled patří do zadání, ne mezi přídavky — a je potřeba ověřit, že hlásí opravdu to, co si myslíte.
- Známé vady se dají najít předem. Tahle byla veřejně popsaná i s obejitím. Půl hodiny rešerše před nákupem ušetří večer.
- Jeden stroj je jeden bod selhání. Pokud na něm má stát něco, co firma potřebuje denně, je dobré vědět dopředu, co se stane, až týden nepojede.
Nic z toho není důvod do lokální AI nejít. Je to důvod jít do ní s otevřenýma očima — a s tím firmám pomáhám.