Offline vývoj s AI: nástrahy a výhody běhu na vlastním hardwaru

Na desetihodinovém letu bez připojení postavil Dmitri Lerko s lokálním modelem analytický nástroj. Co lokální AI pro vývoj přinese, kolik stojí a kde její výhody končí?
Nálepky:
Sedačka 42A v Boeingu 787 není místo, kde by člověk čekal malou serverovnu. Lerko měl šestnáctipalcový MacBook na klíně, pod ním polštář a deku, která chránila nohy před rozpáleným šasi a zároveň zhoršovala chlazení. Zásuvka dodávala 60 wattů, počítač si při práci bral kolem 70 až 80. Baterie proto podle jeho měření ubývala zhruba o procento za minutu.
Model během letu pomohl vytvořit nástroj pro analýzu dvou let cloudových výdajů firmy loveholidays. Lerko jej použil také na refaktoring, první verze nástrojů pro příkazovou řádku a dokumentaci. Popis experimentu se dostal na Hacker News, kde nasbíral přes sto komentářů.
Autor ovšem rovnou doplnil důležitý kontext. Používal týden starý MacBook Pro M5 Max se 128 GB sjednocené paměti, který stál v přepočtu přibližně 150 tisíc korun. Cílem pokusu nebylo ušetřit. Když potřebuje za daný čas odvést co nejvíc práce, dál používá agentní nástroj Codex a model Claude Opus.
Lokální model není zmenšený frontier model
Na palubě běžel přes LM Studio a OpenCode model qwen/qwen3.6-35b-a3b. U úloh s jasnými hranicemi podle Lerka podával výsledky srovnatelné s modely, které běžně používá v cloudu. Jakmile však kontext překročil přibližně 100 tisíc tokenů, odezva i rychlost se znatelně zhoršovaly. Některá zadání navíc skončila v nekonečné smyčce a potřebovala ruční zásah; autor nedokázal určit, zda byl na vině model, nebo OpenCode.
Výslednou cenu práce určuje hlavně počet pokusů a čas strávený čekáním a kontrolou. Frontier model může stát víc za jeden požadavek, ale u velkého repozitáře může rychleji najít správné soubory a dokončit změnu bez přechodu k jinému nástroji. Lokální model se naopak vyplatí u zadání, která lze rozdělit, rychle otestovat a po chybě levně zopakovat.
Ještě před odletem Lerko splnil jednu důležitou podmínku: v počítači měl stovku nejběžnějších Docker images, vývojová prostředí pro běžné programovací jazyky, potřebné závislosti a řadu nástrojů pro příkazovou řádku. Bez internetu nestačí mít jen model. Chybějící balíček, dokumentace nebo image mohou zastavit práci stejně spolehlivě jako chybějící API.
Model je jen motor. Výsledek určuje i harness
Slovem harness se v této souvislosti myslí agentní program kolem modelu. Rozhoduje, které soubory mu ukáže, dává mu nástroje pro čtení, zápis a příkazovou řádku, aplikuje změny, spouští testy a hlídá oprávnění. Také určuje, zda po chybě skončí, zkusí jiný postup, nebo model pošle do dalšího kola. Samotný model tedy nepíše projekt ve vakuu. To, co uvidí a smí udělat, určuje program kolem něj.
V Lerkově případě tuto roli plnil OpenCode. Jeho agenti mohou mít vlastní model, prompt, omezení počtu kroků i oprávnění k souborům a shellu. Vedle vestavěného čtení, zápisu a bashe lze přidat vlastní nástroje a jako backend připojit cloudové API i lokální provider. Jedno zadání typu „oprav testy“ proto nebývá jeden dotaz a jedna odpověď. Agent nejprve hledá soubory, načte jejich obsah, navrhne změnu, zapíše ji, spustí test a s výsledkem se znovu obrátí na model.
To vysvětluje, odkud se mohou vzít miliony tokenů, i když výsledný kód nemá miliony řádků. Špatně vybraný soubor nebo opakovaně načítaný kontext v cloudu zvyšují počet placených tokenů. U lokálního modelu se za další tokeny neplatí, ale počítač pracuje déle a člověk musí zkontrolovat více mezivýsledků. Lerko proto v každé relaci řešil jediný problém, delší plány ukládal do Markdownu a omezoval zbytečná volání nástrojů.
Agentní nástroj může model volat víckrát i záměrně. Aider v režimu architect/editor nechá první model navrhnout řešení a druhý převést návrh do konkrétních úprav souborů. Rozdělení rolí může editaci zlepšit, ale znamená dvě volání modelu místo jednoho. U cloudového API se zvýší spotřeba tokenů, na vlastním počítači se prodlouží doba zpracování. Dobře nastavený agentní nástroj může ze stejného modelu dostat lepší výsledek, ale slabému modelu nedodá schopnost chápat celý projekt.
Paměť určuje, jak velký problém se vejde do počítače
Počet parametrů se snadno porovnává, sám však neříká, zda model na daném počítači vůbec poběží. Rozhodující je, zda se do dostupné paměti vejdou jeho váhy, kontext a běhové prostředí. Kontext obsahuje zadání, historii konverzace, výsledky nástrojů a části projektu, které má model právě před sebou. Čím je delší, tím více paměti a času spotřebuje.
Kvantizovaná varianta Qwen3-Coder 30B z katalogu Ollamy zabírá přibližně 19 GB, takže se vejde na jednu kartu s 24 GB VRAM. Zbývající paměť potřebují kontext, běhové prostředí a ostatní aplikace. Paměťově taková sestava stačí na úpravy několika souborů a menší agentní úlohy. U rozsáhlého monorepozitáře je už nutné hlídat, kolik souborů, historie a výsledků nástrojů agent do kontextu posílá.
Qwen3-Coder-Next už potřebuje podstatně více paměti. Má 80 miliard parametrů, ale při zpracování jednoho tokenu aktivuje přibližně tři miliardy. To snižuje množství výpočtů, nikoli velikost všech vah. Oficiální soubor Q4_K_M zabírá 48,4 GB. Vedle samotných vah potřebuje počítač další paměť pro kontext a běhové prostředí. Na stroji s 48 GB by tak pro ně téměř nic nezbylo. Pro běžný provoz je bezpečnější počítat nejméně s 64 GB; delší kontext potřebuje další paměť.
U Mistral Small 4 už výrobce počítá se serverovým hardwarem. Jde o model se 119 miliardami parametrů a zhruba 6,5 miliardy aktivních parametrů; Mistral pro offline provoz v FP8 doporučuje nejméně jednu H100 s 80 GB paměti a pro dlouhý kontext ještě více. Takový model patří spíš na server, který bude kromě občasné pomoci s kódem zpracovávat i další náročné úlohy.
Pokud už potřebný hardware vlastníte, nemusíte kvůli lokálnímu modelu kupovat nový počítač. Menší model lze vyzkoušet a sledovat hlavně dobu zpracování, spotřebu energie a čas věnovaný instalaci či aktualizacím. Kdo by ale pořizoval novou sestavu jen kvůli zrušení levného předplatného, musí nákup porovnat se skutečnou měsíční úsporou. Při úspoře několika stokorun měsíčně se pořizovací cena zaplatí až za několik let. A to ještě bez elektřiny, údržby a případné modernizace.
Čtyři miliony tokenů nemají jednu cenu
Cloud nemá jedinou sazbu. GitHub Copilot stojí v tarifu Pro 10 dolarů měsíčně, Pro+ 39 dolarů a Max 100 dolarů. Při platbě přes API záleží na modelu, poměru vstupu a výstupu, použití cache i na tom, kolikrát agent během jedné úlohy model zavolá.
Stejné čtyři miliony tokenů mohou mít podle zvoleného modelu zcela jinou cenu. Při čistě ilustračním poměru 90 procent vstupu a 10 procent výstupu by podle ceníku GPT-5.5 stály 30 dolarů. U Gemini 2.5 Flash-Lite by stejný objem vyšel na 52 centů. Neznamená to, že oba modely odvedou stejnou práci. Výpočet pouze ukazuje, že bez názvu modelu a poměru vstupních a výstupních tokenů nelze ze samotného objemu odhadnout cenu.
Elektřina v tomto případě cenu zásadně nezmění. Deset hodin při příkonu 80 wattů představuje 0,8 kWh, tedy při modelové ceně 8 Kč za kWh asi 6,40 Kč. Na palubě však příkon omezoval délku práce: zásuvka nedokázala pokrýt spotřebu notebooku a rozdíl dodávala baterie. Nadbytečné kroky agenta tak znamenaly hlavně více tepla, rychlejší vybíjení a delší čekání.
Vlastní model potřebuje správný druh práce
Lokální modely se hodí pro časté úlohy s omezeným kontextem: doplňování a úpravy funkcí, přípravu prvních verzí testů, mechanické refaktoringy, sumarizaci nebo třídění velkých objemů textu. Výsledek lze rychle prověřit a opakování úlohy nezvyšuje náklady na API. Model na vlastním počítači se hodí také při práci bez připojení nebo s daty, která mají zůstat ve vlastní infrastruktuře.
Cloud bývá vhodnější pro složité ladění, návrh architektury a dlouhé agentní běhy nad velkou částí projektu. Tam může schopnější model ušetřit víc času, než kolik stojí jeho tokeny. Úlohy lze rozdělit podle následků chyby: levné a vratné pokusy zpracovat lokálně, u drahých rozhodnutí použít nejlepší dostupný model.
U týmu lze cenu jednoho stroje rozdělit mezi více lidí, zároveň se však objeví fronty, souběžné požadavky a někdo se musí starat o aktualizace i dostupnost. Jeden sdílený server proto není ideální jako okamžitě dostupný pomocník pro každého. Lépe se využije u úloh, které mohou čekat ve frontě, například při dávkovém zpracování nebo v úzce vymezeném interním postupu.
Hybridní provoz navíc šetří jen tehdy, když něco skutečně nahradí. Pokud zůstane stejné cloudové předplatné a vedle něj přibude nový počítač, celkové náklady vzrostou. Vlastní model se začne vyplácet, když převezme dost rutinní práce, využije hardware i k jiným úlohám nebo umožní práci bez připojení či s daty, která se do cloudu posílat nemají.
Příklad Lerkova letu ukazuje možnosti lokální AI, ne ekonomickou návratnost nového počítače. Na výkonném notebooku lze bez internetu odvést překvapivě mnoho práce. Když se ale rozroste kontext nebo úloha vyžaduje složitější rozhodování, běh se zpomalí a přibude ruční kontroly. Kdo už vhodný stroj vlastní, může lokální model přidat do výbavy hned. Kdo jej teprve kupuje, měl by vědět, jakou konkrétní práci jím nahradí a zda tím skutečně sníží náklady.
… reposted this!
… liked this!
… reposted this!
… liked this!