Llama.cpp umí dvoubitový Q2_0 i na kartách NVIDIA a ternární model 8B má 2,15 GiB.

Program llama.cpp pouští jazykové modely na běžném počítači, bez cloudu. Váhy čte z vlastního formátu GGUF a skoro vždycky zmenšené: místo šestnácti bitů na jednu váhu jich zabírají osm, pět nebo čtyři. Tomu zmenšení se říká kvantizace. Od 30. července 2026 zvládne llama.cpp i variantu, kde na váhu vycházejí dva bity a kousek.

Ten den se do hlavní větve slil návrh číslo 25707 s podporou formátu Q2_0 pro karty NVIDIA. První sestavení, které ji obsahuje, je b10192 z téhož dne; ověřili jsme to porovnáním obou značek v repozitáři, protože sestavení tu vznikají po hodinách a podle času vydání se to určit nedá. O den později přibylo násobení matic pro SYCL, které je podle dokumentace projektu mířené hlavně na karty Intelu.

Osmnáct bajtů na čtyřiašedesát vah

Formát je popsaný v hlavičkovém souboru ggml-common.h a je jednoduchý. Váhy se berou po skupinách po 64. Každá skupina má jedno společné měřítko v šestnáctibitovém desetinném čísle, tedy dva bajty, a za ním následuje 64 dvoubitových kódů, tedy šestnáct bajtů. Blok je dohromady 18 bajtů na 64 vah, což je 2,25 bitu na váhu. Nástroj llama-quantize to v nápovědě uvádí sám: „2.25 bpw quantization (group 64)“.

Kód nabývá hodnot 0 až 3. Při čtení se od něj odečte jednička a výsledek se vynásobí měřítkem, takže z něj vyjde minus jednou, nula, jednou nebo dvakrát měřítko. Model, jehož váhy nabývají jen tří hodnot, potřebuje první tři; čtvrtou karta modelu označuje za rezervovanou pro pozdější použití.

Šest procent, o která se vedl spor

Autoři formátu chtěli skupinu po 128 vahách, protože tak mají zabalené vlastní modely. V rozpravě číslo 22019 jim to správce projektu Georgi Gerganov rozmluvil: skupina po 64 podle něj stojí méně než šest procent paměti navíc, zato je praktičtější, protože sedne na víc tvarů tenzorů, a dá lepší výsledek. Autor souhlasil a oficiální Q2_0 má skupinu 64.

Přepočítali jsme si to. Skupina po 128 vahách vyjde na 34 bajtů, tedy 2,125 bitu na váhu, skupina po 64 na 2,25 – rozdíl je 5,9 %. Sedí to i na hotových souborech: osmimiliardový model má v balení po 128 vahách 2,03 GiB, v balení po 64 pak 2,15 GiB, což je přesně o 5,9 % víc.

Sedmkrát menší soubor

Modely, kvůli kterým formát vznikl, se jmenují Ternary Bonsai a vydala je firma Prism ML. Ternární tady znamená, že váha nabývá jen tří hodnot: minus jedna, nula, plus jedna. Takový model se do dvou bitů vejde beze zbytku, protože víc hodnot ani nemá.

Podle výpisu souborů v repozitáři osmimiliardové verze má model v šestnáctibitovém formátu F16 15,26 GiB a v Q2_0 se skupinou 64 pak 2,15 GiB, tedy 7,1krát méně. U verze s 27 miliardami parametrů je to 50,1 GiB proti 7,06 GiB, tedy stejný poměr. Váhy osmimiliardové verze jsou pod licencí Apache 2.0 v plném znění, bez prahů na tržby nebo počet uživatelů; přiložený soubor NOTICE dodává, že model je postavený z Qwen3-8B.

Velikost souboru ovšem není celá spotřeba paměti. K vahám se za běhu přičítá vyrovnávací paměť na kontext, která roste s délkou zpracovávaného textu. Kolik zabere, závisí na nastavení a na délce kontextu; osmimiliardový model jich podle své karty zvládne 65 536.

Čí jsou čísla o kvalitě

V návrhu s podporou karet NVIDIA je i tabulka přesnosti. Autor v ní porovnal výstupy modelu v Q2_0 s týmž modelem v F16, a to na dvaceti úsecích po 512 tokenech z datové sady wikitext-2. U osmimiliardové verze mu vyšla průměrná divergence 0,000446, shoda v nejpravděpodobnějším tokenu v 98,53 % případů a poměr perplexity 1,0001. Měřil to člověk, který formát navrhl, a porovnával model sám se sebou. Vypovídá to o tom, že zabalení do dvou bitů z ternárních vah nic neubere – ne o tom, jak je model dobrý.

Srovnání s jinými modely je na kartě modelu a měřila ho rovněž Prism ML: nástrojem EvalScope 1.4.2 nad vLLM 0.15.1 na kartě H100 jí Ternary Bonsai 8B vyšel v průměru šesti testů na 75,5 bodu proti 79,3 u modelu Qwen 3 8B, ze kterého je odvozený. Veřejně to zatím nikdo nezopakoval.

Nezávisle ověřený je kód, ne model. Výpočetní funkce pro Vulkan psal a ladil někdo jiný než autor formátu a ve stále otevřeném návrhu na zrychlení pro procesory x86 jeho autor porovnal 14 000 náhodných vstupů s obecnou implementací a shodly se bit po bitu.

Na běžný model to není

Nástroj llama-quantize nabízí Q2_0 jako cíl pro jakýkoli model. Referenční kvantizér v ggml-quants.c vezme největší absolutní hodnotu v bloku jako měřítko a každou váhu zaokrouhlí na nejbližší ze čtyř úrovní. Co z běžného modelu po takovém zaokrouhlení zbude, žádný ze sloučených návrhů neměří – Q2_0 vznikl pro modely, které jsou ternární už z trénování. Na ostatní má llama.cpp jiné formáty včetně jednobitových, jenže u těch největších modelů zbude i po nich 594 GB.

Ternární formáty v llama.cpp mimochodem už byly: TQ1_0 se 1,69 a TQ2_0 se 2,06 bitu na váhu. Autoři je nepoužili proto, že mají skupinu po 256 vahách, kdežto jejich modely jsou dělané po 128, a že podle nich míří hlavně na procesor.

Zbývá dodělávka, která se čtenáře týká přímo. V repozitářích na Hugging Face leží obě balení vedle sebe a odlišuje je jen název: soubory s _g64 odpovídají tomu, co je v hlavní větvi, kdežto Q2_0.gguf bez přípony je starší balení po 128 vahách z vlastní odnože llama.cpp – píše to autor přímo v návrhu a přejmenování slíbil, až se sloučí podpora pro všechny druhy hardwaru. Karta osmimiliardového modelu má poslední úpravu z 10. června 2026 a pořád tvrdí, že Q2_0 v hlavní větvi llama.cpp není a že je na něj potřeba odnož.

Zdroje: zdrojový kód a návrhy změn v repozitáři ggml-org/llama.cpp (čísla 24448, 25419, 25430, 25707, 26231 a 26348, rozprava 22019), karty modelů a výpisy souborů u prism-ml/Ternary-Bonsai-8B-gguf a 27B. Přepočty bitů na váhu a poměrů velikostí jsou naše.