Model se vejde do VRAM. Proč s ním ale AI agent nemusí zvládnout projekt

Velikost souboru není velikost běžícího modelu

Při výběru grafické karty pro lokální AI se často začíná u jednoduchého pravidla: pokud má kvantizovaný model například 17 GB, měl by se vejít do 24GB grafiky. To je užitečný první odhad, ale nikoli provozní specifikace. GGUF soubor obsahuje především váhy modelu. Po načtení je potřeba další paměť pro výpočetní pracovní prostor, přesuny tensorů, runtime a především pro kontext.

U modelů jako Llama 3.1 8B, Gemma 3 27B nebo Llama 3.3 70B se proto provozní nároky mohou lišit od velikosti samotného GGUF souboru. Rozhoduje konkrétní kvantizace, backend, délka kontextu a další nastavení. Bez přímého technického podkladu s přesnou konfigurací nelze jednotlivé hodnoty považovat za ověřenou provozní specifikaci.

Nejde o univerzální tabulku platnou pro každý backend a každé nastavení. Paměťové nároky je proto třeba vždy posuzovat podle konkrétní konfigurace, nikoli pouze podle velikosti souboru. Je to důležitá změna uvažování: velikost modelu na disku není totéž jako minimální kapacita VRAM.

KV cache: druhá paměť modelu

KV cache je pracovní paměť, do které si transformer ukládá reprezentace již zpracovaných tokenů. Díky ní nemusí při každém novém slově znovu počítat celou konverzaci od začátku. Při udržování jedné aktivní kontextové relace s každým dalším tokenem obvykle přibývá také spotřebovaná paměť. Čím delší je historie, tím více prostoru KV cache zabere. Neplatí to ale bez výjimky pro každý API backend: stateless API může historii při každém požadavku znovu posílat, aniž by na serveru kumulovalo stejnou KV cache mezi požadavky.

Proto nestačí říct, že Qwen3.8-27B v konkrétní kvantizaci má velikost odpovídající volné kapacitě grafické karty. U konkrétního GGUF souboru nemusí po načtení vah zbýt dostatek prostoru pro režii a KV cache. Menší kvantizace se do 16 GiB může vejít, ale záleží na jejím přesném provedení a použitém runtime. Velikost proto závisí na konkrétní kvantizaci a je důležité rozlišovat mezi GB, které se používají u velikosti souboru či označení karty, a GiB, v nichž se často zobrazuje skutečně dostupná kapacita.

Při dlouhém kontextu může KV cache zabrat významnou část paměti a v některých konfiguracích i více prostoru než samotné váhy modelu. Konkrétní spotřeba se mění podle architektury, počtu hlav, datového typu KV cache a použitého backendu. Pointa ale zůstává stejná: dlouhé kontextové okno může být větší než samotné váhy modelu.

Proč je to kritické právě u AI agenta

Chatbot obvykle dostane jednu otázku a odpoví. Coding agent pracuje jinak. Prohlíží strom projektu, čte soubory, vyhledává symboly, spouští testy, zpracovává chybové výpisy a podle výsledků plánuje další krok. Do dalšího požadavku se mohou vracet instrukce, předchozí rozhodnutí, výstupy nástrojů, části zdrojového kódu i výsledky externího vyhledávání.

To všechno se musí nějak vejít do kontextového okna. Pokud aplikace udržuje jednu aktivní relaci a posílá historii v každém požadavku, může s délkou této relace růst také KV cache. U stateless API se historie může znovu posílat bez stejné kumulace cache na serveru, přesto však každý požadavek zvyšuje objem zpracovávaného vstupu. Agent přitom nemusí mít problém při prvním dotazu. Selhání často přijde až po několika krocích, kdy se nahromadí výstupy nástrojů a přečtené soubory.

V tu chvíli může nastat několik scénářů: backend odmítne další požadavek kvůli OOM, začne odkládat část výpočtů do RAM, zkrátí historii, nebo aplikace konverzaci znovu sestaví v osekané podobě. Poslední možnost může vypadat jako zpomalení nebo „zapomínání“ pravidel projektu. Ve skutečnosti nejde nutně o chybu modelu, ale o paměťový limit infrastruktury.

Naše zkušenost s 16 GB VRAM

Na serveru jarvisbot jsme Qwen3.8-27B zkoušeli při rozdělení modelu mezi RTX 5060 Ti 16 GB a RTX 3050 6 GB. Interní pozorování z této konfigurace není doplněno o datum testu, použitý backend ani runtime, přesné označení kvantizace, datový typ KV cache, délku vstupu, způsob rozdělení modelu mezi obě karty ani přesný postup měření. Nelze je proto použít jako přesně reprodukovatelný benchmark.

Stejně tak zde neuvádíme externí srovnání rychlosti, protože k němu není k dispozici přímý a ověřitelný odkaz na konkrétní test ani úplná konfigurace. Výsledky podobných měření nelze bez znalosti backendu, runtime, kvantizace, délky vstupu a způsobu měření spolehlivě porovnávat.

U pokusů s OpenCode a delším kontextem proto nelze bez úplných údajů určit obecnou hranici použitelnosti. Výsledek závisí na backendu, konkrétní kvantizaci, datovém typu KV cache, skutečné délce vstupu a způsobu rozdělení modelu. Druhá karta navíc nepřidává svou VRAM automaticky k jedné grafice. Umožní některé formy rozdělení modelu, ale přináší také komunikaci přes PCIe a další režii.

Výsledek je důležitý pro každého, kdo si staví lokální coding nástroj: krátký benchmark v terminálu nemusí říct, jak se systém zachová po hodině práce agenta s větším repozitářem.

Co tedy při výběru GPU měřit

Pro lokální LLM je vhodné rozdělit rozpočet VRAM na čtyři části:

• váhy modelu – například kvantizovaný Qwen3.8-27B;
• runtime a pracovní buffery – paměť potřebná pro samotný výpočet;
• KV cache – při udržování aktivní kontextové relace roste s délkou kontextu a počtem souběžných relací; u stateless API se může historie posílat znovu bez stejné kumulace cache na serveru;
• agentní rezerva – prostor pro nástroje, soubory, výstupy testů a další kroky.

Pokud chcete pouze chat s krátkými dotazy, může být 24 GB pro 27B model v některých konfiguracích rozumný kompromis. Pro coding agenta může být orientačně praktičtější scénář s 32 GB a více, ale záleží na backendu, konkrétní kvantizaci, datovém typu KV cache a délce kontextu. Ani 48 GB proto není obecnou zárukou pro libovolné nastavení a projekt. Neznamená to, že každý uživatel permanentně spotřebuje celé kontextové okno. KV cache se obvykle přiděluje dynamicky. Znamená to ale, že při delší práci nebo několika současných uživatelích potřebujete rezervu.

Výhodné je také nastavit realistický limit kontextu, sledovat skutečnou spotřebu KV cache a používat kompresi nebo shrnování historie. Odkládání KV cache do systémové RAM může pomoci u neaktivních relací, ale aktivní generování přes PCIe je výrazně pomalejší než z VRAM. SSD je vhodné jako úložiště modelů nebo odložených relací, nikoli jako rychlá náhrada VRAM.

Praktický závěr pro domácí i firemní server

Lokální AI server se nemá dimenzovat podle otázky „vejde se mi soubor na grafiku?“. Správná otázka zní: vejde se model, pracovní kontext, KV cache a typická agentní relace současně – a zůstane ještě dost výkonu pro rozumnou odezvu?

Pro českého uživatele, který chce provozovat coding agenta nad vlastním repozitářem, je to rozdíl mezi demonstrací a použitelným nástrojem. 16GB karta může předvést, že moderní model lokálně nastartuje, pokud se použije vhodná kvantizace a odpovídající nastavení. 32GB nebo 48GB karta může v některých konfiguracích nabídnout větší rezervu pro skutečnou práci agenta, nejde však o obecné pravidlo: rozhoduje backend, kvantizace, datový typ KV cache, délka kontextu a způsob rozdělení modelu.

Právě proto se při úvahách o upgradu GPU nevyplatí sledovat pouze počet parametrů a rychlost generování. Stejně důležitá je paměťová rezerva pro kontext a způsob, jakým se model používá. U AI agentů je rozdíl mezi „spustit“ a „pracovat s tím celý den“ mimořádně velký.