llama.cpp nechá některé velké vkládací tabulky na disku místo v operační paměti
Projekt llama.cpp vydal 4. září 2026 verzi 0.4.0 s volbou --lazy-mode: vybraná vkládací tabulka zůstane v souboru na disku a program z ní čte řádky až ve chvíli, kdy je potřebuje. Sama od sebe se zapne jen u tenzorů nad 4 GiB. Autor návrhu na Gemmě 4 naměřil o 1,2 GB nižší špičku paměti a o desetinu pomalejší generování.
Program llama.cpp pouští jazykové modely na běžném počítači. Váhy čte ze souboru ve formátu GGUF a až dosud je při spuštění celé nastěhoval do operační paměti. Vydání 0.4.0 ze 4. září 2026 to u jedné skupiny tenzorů mění.
Volbu přinesl návrh číslo 27794 od Xuana Sona Nguyena, sloučený 27. srpna 2026 ve 13.14 UTC. První sestavení, které ho obsahuje, je b10653 z téhož dne; rozhraní GitHubu vrací pro porovnání toho commitu s předchozí značkou b10649 stav behind a s b10653 stav identical. O tři dny později se přepínač přejmenoval z --tensor-read-lazy na --lazy-mode a dostal zkratku -lzm.
Tři hodnoty a jeden práh
Nápověda v souboru common/arg.cpp popisuje tři možnosti. on znamená číst řádky takového tenzoru z disku na vyžádání místo toho, aby zůstal celý v paměti, off je staré chování a auto je totéž co on, ale jen pro tenzory větší než 4 GiB. Výchozí je auto. Nastavit se dá i proměnnou prostředí LLAMA_ARG_LAZY_MODE.
Celé to stojí na mapování souboru do paměti. Když je mmap nedostupný, program vypíše varování a tenzor načte celý. Práh je v kódu napsaný natvrdo jako 4ull * 1024 * 1024 * 1024 a komentář nad ním říká, že u malých tenzorů se to nevyplatí kvůli režii.
Podstatnější omezení je jinde. Volba neplatí na libovolnou váhu, ale jen na tenzory, které si o to řekne popis architektury příznakem TENSOR_READ_LAZY. Ve zdrojových souborech vydání 0.4.0 ten příznak nesou dvě architektury: gemma4 a qwen4exp, tedy náhled architektury Qwenu. V obou případech jde o tentýž tenzor, per_layer_token_embd.weight. Takto načtené váhy navíc zůstávají v paměti počítače, ne na grafické kartě, a zámek paměti přes mlock je vynechává, protože zamknout je by znamenalo přečíst je celé.
K čemu jsou tabulky, které se skoro nepočítají
Obě architektury mají cosi, co běžný transformer nemá: vyhledávací tabulku, do které se sahá po jednom řádku na token. Karta modelu Gemma 4 E4B to popisuje u svých malých modelů jako Per-Layer Embeddings a uvádí, že písmeno E ve jméně znamená „efektivní“: E4B má 4,5 miliardy efektivních parametrů a 8 miliard i s vkládáním. Google k tomu píše, že tyhle tabulky jsou velké, ale slouží jen k rychlému vyhledání – proto je počet efektivních parametrů mnohem nižší než celkový. Překlad je náš.
Qwen má obdobu pod jménem engrams a v jeho případě drží ta tabulka 51,2 miliardy parametrů, tedy víc než čtvrtinu celého modelu. Právě ona koncem srpna donutila projekt omezit pracovní paměť kvantizátoru; teď přišla na řadu i strana čtení.
Kolik z toho souboru ta tabulka je
Hlavička souboru GGUF nese jméno, tvar i formát každého tenzoru, takže se dá přečíst rozsahovým dotazem HTTP, bez stažení vah. U souboru gemma-4-E4B-it-Q4_K_M.gguf z repozitáře unsloth/gemma-4-E4B-it-GGUF z ní vychází tohle:
| údaj | hodnota |
|---|---|
| tenzorů v souboru | 720 |
| data všech tenzorů | 4 961 343 656 B |
per_layer_token_embd.weight | Q5_K, 10 752 × 262 144 |
| ta tabulka v bajtech | 1 937 768 448 B |
| její podíl | 39,1 % |
Podíl je vlastní výpočet z obou čísel v tabulce a sedí s tím, co v návrhu uvádí jeho autor (1,94 GB, 39 %). U Qwenu je to ještě názornější: v osmibitové kvantizaci má tentýž tenzor 51 200 245 760 parametrů a 54 400 261 120 B, a je jediným tenzorem svého souboru – třetí ze šesti dílů nenese nic jiného.
Zaplatí se to rychlostí
Autor návrhu měřil na Gemmě 4 E4B v kvantizaci Q4_K_M. Špička obsazené paměti klesla ze 7,37 na 6,16 GB a rezidentní část namapovaného souboru ze 4,6 na 2,8 GB. Generování tokenů kleslo ze 105,8 na 94,2 až 94,7 za sekundu, tedy o 10,7 %; ve variantě bez rady MADV_RANDOM na 97,0 až 97,3, tedy o 8 %. Zpracování zadání se drží mezi 514 a 563 tokeny za sekundu proti 571 až 583 v základu. Jsou to jeho čísla z jeho stroje a nikdo je zatím nezopakoval.
Výchozí nastavení Gemmě 4 nepomůže
Tady je zádrhel, který v poznámkách k vydání nestojí. Těch 1 937 768 448 B je 1,80 GiB, kdežto auto zabírá až od 4 GiB. Na Gemmu 4 E4B v této kvantizaci se tedy výchozí nastavení nechytí a kdo tu úsporu chce, musí napsat --lazy-mode on. Tabulka Qwenu s 54 GB práh překročí i po kvantizaci na čtyři bity.
Není to opomenutí, ale záměr: autor v návrhu píše, že u malých modelů je prodleva čtení znatelná proti rychlosti generování, kdežto u velkých se ztratí. Podle nás je ta hranice postavená spíš podle velikosti tenzoru než podle toho, jak rychlý disk pod ním je – na pomalém úložišti bude zpomalení jiné než na NVMe, kterou měřil autor.
Kdo pouští modely na stroji s málo pamětí, získá volnou paměť na delší kontext. Kdo má paměti dost, nechá off a o nic nepřijde. A kdo čeká, že se model konečně rozběhne na počítači, kam se dosud nevešel, počká si: příznak zatím nesou dvě rodiny modelů a jeden druh tenzoru.
Zdroje
- llama.cpp 0.4.0 – poznámky k vydání
- Návrh 27794 a návrh 27969 – zavedení a přejmenování volby, včetně měření
- Karta modelu Gemma 4 E4B – popis Per-Layer Embeddings
- unsloth/gemma-4-E4B-it-GGUF a unsloth/Qwen3.8-Flash-Next-GGUF – soubory, ze kterých jsme četli hlavičky