llama-quantize si na velký tenzor bere nejvýš osm gigabajtů operační paměti

Nástroj llama-quantize z projektu llama.cpp převádí váhy modelu do úspornějšího formátu, aby se model vešel na kartu nebo aspoň do paměti. Do 27. srpna 2026 si přitom na každý tenzor, který kvantizoval, alokoval dva pomocné bloky, každý o velikosti čtyř bajtů na jeden parametr. U běžné vrstvy jsou to megabajty. U jedné vyhledávací tabulky z čerstvého modelu Qwenu z toho vyšly stovky gigabajtů, a právě ta oprava vyvolala.

Čtyři bajty na parametr, a to dvakrát

Staré znění souboru src/llama-quant.cpp mělo dvě místa, na kterých se to lámalo. První si připravilo výstupní blok příkazem work.resize(nelements * 4), tedy čtyři bajty na každé číslo tenzoru; komentář vedle něj to označuje za horní odhad. Druhé poslalo tenzor rozbalit do desetinných čísel a převodní funkce si na to zvětšila pole typu float na počet prvků tenzoru, tedy znovu čtyři bajty na číslo. Oba bloky žily vedle sebe, dokud nebyl celý tenzor hotový.

Zdrojová data se do paměti nahrávat nemusela. Když je zapnuté mapování souboru do paměti, ukazuje se rovnou do mapy a stránky si uklízí systém sám; bez mapování se ale načetl celý tenzor do třetího bloku. Nároky na paměť tedy neurčovala velikost modelu, ale velikost jeho největšího tenzoru.

Tenzor, který to vyvolal

Popis opravy jmenuje spouštěč přímo: vyhledávací tabulku n-gramů z modelu Qwen3.8-Flash-Next, o jejímž obsahu jsme psali samostatně. Ve zveřejněných vahách je rozsekaná na 128 dílů, převodní skript llama.cpp z nich ale skládá jeden tenzor a komentář nad tím kusem kódu o něm mluví jako o tenzoru „dobře přes 100 GB“. Z hlaviček vah vychází 51 200 245 760 parametrů.

Na takovém tenzoru si stará cesta musela vzít 204,8 GB na jeden pomocný blok, a bloky byly dva. To číslo je náš výpočet z kódu, nikoli údaj ze zdroje: čtyři bajty krát 51,2 miliardy parametrů.

Nově se jede po dávkách řádků

Změna, kterou návrh 27795 zavedl 27. srpna 2026, tenhle postup rozseká na dávky celých řádků. Na jeden řádek připadne místo ve zdrojovém formátu, místo v cílovém formátu a čtyři bajty na každé číslo pro mezikrok s desetinnými čísly; kolik řádků se vejde do jedné dávky, vyjde z podílu stropu a téhle hodnoty. Hotová dávka jde rovnou do výstupního souboru. Tenzory, které se nekvantizují, se opisují po celých řádcích taky – podle komentáře v kódu proto, aby se dala každá dávka ověřit.

Strop je nový přepínač --max-buffer-size, zadává se v mebibajtech a bez něj platí 8 192, tedy 8 GiB. Autor změny Xuan-Son Nguyen v popisu uvádí, že s nižším stropem vyšel výstup bajt po bajtu shodný. Do sestavení se změna dostala týž den: první, které ji obsahuje, je b10656, vydané v 17.40 UTC.

Co z toho má počítač doma

Strop se týká pomocných bloků, ne celého převodu. Vstupní soubor se dál mapuje do paměti a výstupní se dál zapisuje na disk, takže na místo v úložišti to nároky nesnižuje ani o bajt. Podle našeho propočtu se dávkování projeví teprve u tenzoru zhruba nad miliardu čísel; menší modely se kvantizovaly stejně jako dřív a po opravě to tak zůstane.

A jestli se dá Qwen3.8-Flash-Next po kvantizaci provozovat doma, je jiná otázka. Rozhraní Hugging Face hlásí u jedné z veřejných sad GGUF velikost 354 GB pro BF16, 188,2 GB pro Q8_0 a 72,5 GB i u nejmenšího balíku, který je označený jako jednobitový. Za to může právě ta tabulka: llama-quantize ji řadí mezi vkládací tabulky, takže se řídí přepínačem --token-embedding-type, a kdo jí chce dát vlastní formát, musí ji pojmenovat přes --tensor-type.

Ubyla tedy jedna překážka ze dvou. Kvantizovat velký model jde nově i na stroji s běžnou pamětí; vejít se s tím výsledkem někam je pořád na čtenáři.

Zdroje

• llama.cpp, návrh 27795: quantize: cap working memory size to avoid loading big tensors onto RAM
• llama.cpp, návrh 27742: model: add Qwen3.8-Flash-Next (qwen4exp)
• llama.cpp, sestavení b10656
• Hugging Face: Qwen/Qwen3.8-Flash-Next – nastavení modelu, soupis souborů a hlavičky vah
• Hugging Face: unsloth/Qwen3.8-Flash-Next-GGUF – velikosti hotových sad