Kvantizace LLM: 7 metod v porovnání (s čísly z benchmarků)

Kvantizace LLM: 7 metod v porovnání (s čísly z benchmarků)

Llama 3.3 70B potřebuje ve FP16 jen na váhy 140 GB. Dvě H100. Při Q4_K_M se stejný model vejde do zhruba 42 GB, což je jedna ojetá RTX A6000 z bazaru. Přesně tato mezera je celý důvod, proč kvantizace LLM existuje, a volba špatné metody vás stojí buď kvalitu, kterou uvidíte, nebo VRAM, který nemáte.

Tento průvodce kvantizací LLM porovnává 7 metod, na nichž v roce 2026 záleží, a každé číslo v něm vede k publikovanému zdroji.

Hlavní body

• Kvantizace vyměňuje paměť a šířku pásma za měřitelnou, obvykle malou, ztrátu kvality.
• GPTQ a AWQ jsou primárně GPU metody; GGUF je formát, který běží i na CPU.
• Q4_K_M se pohybuje kolem 4,8 bitu na váhu, ne 4. Názvosloví tento navýšení skrývá.
• 6bitová kvantizace se podle PR k-quants v llama.cpp drží do ~0,1 % perplexity FP16.

Co vlastně kvantizace LLM s modelem dělá?

Kvantizace LLM ukládá váhy modelu v nižší číselné přesnosti, čímž zmenšuje paměť a šířku pásma za cenu chyby zaokrouhlení. Model se 70B parametry klesne ze 140 GB ve FP16 na zhruba 42 GB při 4 bitech. Inteligence zůstává; mizí desetinná místa. Každá metoda v tomto průvodci je variantou tohoto obchodu.

Žebříček přesnosti začíná u FP32 (32 bitů), pokračuje přes FP16 a BF16 (oba 16 bitů), pak INT8 a nakonec INT4. Každý krok zpola sníží počet bajtů na parametr. Formáty plovoucí čárky definuje standard IEEE 754 a článek Marka Horowitze z roku 2014 "Computing's Energy Problem" ukázal, proč energetickým nákladům dominuje přesun těchto bajtů, ne aritmetika nad nimi. To je fyzikální důvod, proč kvantizace zrychluje inferenci.

Kvantizaci zprovozňují dva parametry: škálovací faktor (násobitel, který mapuje celočíselný rozsah zpět na reálné hodnoty) a nulový bod (celé číslo představující 0,0). Symetrická kvantizace vystředí rozsah kolem nuly a nulový bod vynechá; asymetrická kvantizace ho posune, aby využila celý celočíselný rozsah, když se váhy shlukují mimo nulu.

Váhy se kvantizují čistě, protože jsou statické a normálně rozložené. Aktivace ne. Odlehlé aktivace, někdy 100násobek mediánu, při naivní kvantizaci chybu zaokrouhlení rozstřelí. Právě tato asymetrie je důvod, proč většina zdejších metod kvantizuje pouze váhy (W4A16) a aktivace nechává ve FP16.

Pokvantizační kvantizace (PTQ, post-training quantization) převádí hotový model po tréninku. Kvantizačně uvědomělý trénink (QAT, quantization-aware training) simuluje zaokrouhlení během tréninku, aby se model přizpůsobil. Vše v tomto článku je PTQ. QAT stojí víc výpočtů a tréninkový běh; je to samostatné rozhodnutí.

Řádky INT4 a NF4 jsou teoretické čisté 4 bity: 4 bity na váhu a nic navíc. Reálné 4bitové formáty nesou navrch blokové škály a minima, takže skončí výš. Model 70B v Q4_K_M má kolem 42 GB, ne 35. Tabulka VRAM níže už používá efektivní hodnoty.

Kvantizace nezmenšuje inteligenci modelu. Zmenšuje počet desetinných míst, do kterých tu inteligenci ukládá. A pokud platíte za token API inference, snížení účtu za LLM API často začíná právě tím, že si kvantizovaný model spustíte sami.

7 metod kvantizace vedle sebe

Sedm metod níže pokrývá každou produkční cestu kvantizace LLM v roce 2026. Dvě jsou pouze pro GPU (GPTQ, AWQ), jedna běží kdekoli (GGUF), jedna kvantizuje až při načtení (BitsandBytes), dvě míří na vysokopropustnostní serving (SmoothQuant, FP8) a jedna je nativní pro PyTorch (TorchAO). Správná volba závisí na vašem hardwaru, ne na tom, která metoda má nejvyšší skóre v žebříčku.

GPTQ kvantizuje vrstvu po vrstvě a pomocí inverzní Hessiány přerozděluje chybu zaokrouhlení mezi zbývající váhy. Potřebuje kalibrační sadu a GPU. Článek o GPTQ uvádí kvantizaci 175B modelu na 3-4 bity za zhruba 4 GPU-hodiny.

AWQ identifikuje ~1 % vah, na nichž záleží nejvíc (salientní váhy, nalezené z velikostí aktivací), a naškáluje je, aby je před zaokrouhlením ochránil. Článek o AWQ (nejlepší paper MLSys 2024) uvádí více než 3násobné zrychlení oproti FP16 implementaci HuggingFace na desktopových i mobilních GPU.

GGUF je souborový formát, ne algoritmus. Algoritmus uvnitř je blokové schéma k-quant z llama.cpp PR #1684. Jako jediná zdejší metoda běží na CPU, což z ní dělá výchozí volbu pro lokální inferenci. Co do ní nahrát, ukazuje přehled open-weight modelů vhodných ke kvantizaci.

BitsandBytes kvantizuje při načtení, ne předem. NF4 (4bitový NormalFloat) je jeho vlajkový formát a páteř doladění QLoRA. Kalibrační sada není potřeba.

SmoothQuant přenáší odlehlé aktivace do vah, aby obojí mohlo běžet v INT8. Článek uvádí až 1,56násobné zrychlení a 2násobné snížení paměti a míří na propustnost při servingu s velkými dávkami, kde metody W4A16 nechávají výkon ležet ladem.

FP8 (W8A8) je nativní cesta na GPU H100 a B200. Téměř bezztrátová při 8 bitech, žádné kalibrační trable a vLLM ji podporuje přímo.

TorchAO je vlastní kvantizační knihovna PyTorchu, postavená tak, aby fungovala s torch.compile. Pokud už vaše pipeline stojí na PyTorch, je to cesta nejmenšího odporu.

Ve skutečnosti existují jen dvě otázky: spustí to váš hardware, a unesete ztrátu kvality, kterou to stojí?

Co opravdu ukazují publikované benchmarky?

Publikované benchmarky říkají, že 4bitová kvantizace stojí u 7B modelu 1-2 % perplexity a 6bitová pod 0,1 %. Ta čísla pocházejí z llama.cpp PR #1684 (2023), změřili je správci llama.cpp na jediném 7B modelu na RTX 4080. Jsou to nejcitovanější údaje v oboru kvantizace a jsou reálné. Zároveň je to n = 1.

Zdroj: llama.cpp PR #1684 (2023). Model 7B, RTX 4080, měřeno správci llama.cpp. n = 1 model.

Poznámka ke sloupci bity/váhu: jde o nominální hodnoty základního typu k-quant a mixy s _K efektivní hodnotu zvyšují. Q2_K je toho příkladem. Když do vzorce z tohoto článku dosadíte nominálních 2,5625 a model s 6,74B parametry, vyjde ~2,0 GB, ale řádek uvádí soubor 2,67 GB, což zpětně odpovídá ~3,4 bitu na váhu. Zbytek tohoto článku používá efektivní hodnoty odvozené z těchto velikostí souborů.

Čísla pro GPU metody pocházejí přímo z článků. GPTQ uvádí end-to-end zrychlení inference oproti FP16 zhruba 3,25x na A100 a ~4,5x na A6000, se 175B modelem kvantizovaným na 3-4 bity za asi 4 GPU-hodiny. AWQ uvádí „více než 3násobné zrychlení oproti FP16 implementaci HuggingFace na desktopových i mobilních GPU“ a k tomu první nasazení 70B Llama-2 na mobilním GPU přes TinyChat. Citujeme formulaci článku, místo abychom číslo parafrázovali do falešné přesnosti.

Původní příspěvek tohoto článku je aritmetika. Paměť pro váhy se řídí vztahem: váhy (GB) ≈ parametry (B) × bity na váhu ÷ 8. Háček je v tom, jakou hodnotu bitů na váhu dosadíte. PR #1684 publikuje hodnotu pro základní typ k-quant (Q4_K = 4,5) a mixy _S/_M/_L leží nad touto základní hodnotou, protože věnují extra bity tenzorům attention a feed-forward. Efektivní hodnoty jsme proto odvodili z velikostí souborů, které PR samo publikuje, na modelu 7B, který má ve skutečnosti 6,74B parametrů: Q2_K s 2,67 GB zpětně odpovídá ~3,4 bpw, Q4_K_S s 3,56 GB ~4,5, Q6_K s 5,15 GB ~6,6. Q4_K_M končí kolem 4,8.

To mění titulní číslo. Model 70B v Q4_K_M: 70 × 4,8 ÷ 8 = 42 GB. Většina článků píše 35 GB. Používají 4,0 bpw a zcela ignorují režii blokových škál. Křížová kontrola zabere jedno kliknutí: Llama-3.3-70B-Instruct-Q4_K_M.gguf má na HuggingFace 42,5 GB, shodně v repozitářích bartowski, lmstudio-community i second-state. Každou buňku tabulky VRAM níže jsme na tomto základě přepočítali.

Naše čtení těchto čísel: rozdíl perplexity mezi Q6_K (5,9110) a F16 (5,9066) je 0,0044, což je méně než rozdíl mezi dvěma různými doladěními téhož základního modelu. Proto rada „prostě použijte Q4_K_M nebo Q5_K_M“ přežívá kontakt s reálným hardwarem. Sloupec ms/token taky ukazuje, že Q2_K nekoupí žádnou rychlost oproti Q4_K_S (oba 15,5 ms/token), přitom stojí 0,75 perplexity. Q2_K je nejhorší obchod v tabulce.

Co vám čísla neřeknou: perplexita na wikitextu není totéž co kvalita na vašich promptech. Jeden model na jedné GPU je n = 1. Údaje o rychlosti závisí na velikosti dávky. Berte je jako směrové, ne univerzální.

6bitová kvantizace skončí do zhruba 0,1 % perplexity plně přesného modelu. Na této úrovni je komprese téměř zadarmo.

GPTQ vs AWQ: volba mezi dvěma GPU metodami

GPTQ i AWQ vytvářejí z kalibrační sady 4bitové GPU checkpointy a oba jsou dobře podporované ve vLLM. Rozdíl je v tom, jak nakládají s chybou zaokrouhlení. GPTQ ji přerozděluje mezi zbývající váhy pomocí inverzní Hessiány. AWQ chrání 1 % vah, které aktivace označují jako důležité. Fungují obě. Volba se týká vašeho vzoru servingu.

GPTQ pracuje vrstvu po vrstvě. Pro každou vrstvu kvantizuje jednu váhu po druhé a pak upraví zbývající váhy v dané vrstvě, aby kompenzoval zaokrouhlení, které právě provedl. Úprava využívá informaci druhého řádu z Hessovy matice, proto potřebuje kalibrační sadu pro její výpočet. Výsledek je silný u dávkové inference, kde na propustnosti záleží víc než na latenci jednotlivých tokenů.

AWQ jde na to z jiného úhlu. Identifikuje salientní váhy podle velikostí aktivací napříč kalibrační sadou, zhruba horní 1 % kanálů. Tyto váhy dostanou škálovací faktor po kanálech, který je během zaokrouhlení udrží v rozsahu vyšší přesnosti. Kalibrační sada může být menší než u GPTQ a AWQ se na ni méně přeučuje, protože chrání strukturální rysy, místo aby se fitoval na konkrétní vstupy. Článek uvádí silné výsledky u servingu citlivého na latenci.

Zvolte GPTQ, pokud: děláte dávkovou inferenci na GPU, máte dobrou kalibrační sadu odpovídající vaší doméně a metrikou je propustnost.

Zvolte AWQ, pokud: servírujete požadavky jednoho uživatele s nízkou latencí, chcete menší kalibrační sadu, nebo nasazujete na edge/mobilních GPU.

# Servis publikovaného AWQ checkpointu pomocí vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Servis publikovaného GPTQ checkpointu pomocí vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

Pokud se zároveň rozhodujete mezi servingovými enginy, vLLM proti SGLang rozebírá toto rozhodnutí zvlášť.

GGUF a K-Quants: co vlastně znamená Q4_K_M

GGUF je souborový formát, ne kvantizační algoritmus. Specifikace GGUF definuje kontejner pro váhy modelu, metadata a data tokenizéru. Kvantizační algoritmus uvnitř souboru GGUF je blokové schéma k-quant (nebo i-quant) z llama.cpp PR #1684. Plést si kontejner s algoritmem je v tomto oboru nejčastější chyba a vede k otázkám typu „co je lepší, GGUF, nebo GPTQ?“, které tak docela nedávají smysl.

Názvosloví se dešifruje následovně. Q znamená blokové schéma k-quant; IQ znamená i-quant s maticí důležitosti (novější varianta, která používá matici důležitosti pro lepší kvalitu při stejné bitové hloubce). Číslo je nominální bitová hloubka. _K označuje rodinu k-quant vůči starým formátům jako Q4_0. _S, _M, _L řídí, které skupiny tenzorů dostanou extra bity: small, medium, large. Vyšší přípona znamená víc bitů pro tenzory attention a feed-forward, na nichž záleží nejvíc.

Efektivní hodnoty, zpětně odvozené z velikostí souborů 7B (6,74B parametrů) publikovaných v PR #1684, ne z hodnot základního typu. Řádky legacy jsou přesné už z konstrukce: blok Q4_0 je 32 vah po 4 bitech plus jedna FP16 škála, což je 4,5 bitu na váhu, a Q8_0 je 32 vah po 8 bitech plus FP16 škála, což je 8,5. PR to potvrzuje, když uvádí soubory 7B Q4_0 a Q4_K_S se stejnými 3,56 GB.

Q4_K_M není 4 bity na váhu. Je to kolem 4,8. Blokové škály a minima se musí někam vejít a mix _M pak utratí extra bity za tenzory attention a feed-forward, což je přesně důvod, proč Q4_K_M leží nad Q4_K_S a Q3_K_M nad Q3_K_S, místo aby se s ním shodoval.

Proč GGUF běží tam, kde GPTQ nemůže: podporuje CPU inferenci a offload vrstev mezi VRAM GPU a systémovou RAM. Model 32B, který se celý nevejde na vaši GPU, může běžet s polovinou vrstev offloadovanou, pomalu, ale funkčně. GPTQ žádnou CPU cestu nemá.

# Stažení konkrétního kvantizačního tagu pomocí Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Převod F16 GGUF na Q4_K_M pomocí llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

Jste v lokálních modelech noví? Začněte rozjezdem prvního lokálního modelu, než budete cokoli kvantizovat. A pokud chcete prohlížečové UI, Open WebUI nad Ollamou zabere asi deset minut. Dokumentace GGUF na HuggingFace vysvětluje, jak Hub vystavuje názvosloví typů kvantizace.

BitsandBytes, Marlin, SmoothQuant a TorchAO

Tyto čtyři pokrývají zbývající produkční cesty. Žádná není „lepší GPTQ“. Řeší různé problémy.

BitsandBytes kvantizuje při načtení, ne předem. Namíříte ho na FP16 checkpoint a on za běhu převede na NF4 nebo FP4. Žádná kalibrační sada, žádný offline krok. Jeho hlavní zásluha je QLoRA: 4bitový zmrazený základní model s LoRA adaptéry trénovanými navrch, což umožňuje doladění 65B modelu na jedné GPU se 48 GB VRAM. QLoRA je tréninková technika, ne inferenční, ale je to důvod, proč většina lidí narazí na BitsandBytes jako první.

Marlin není metoda kvantizace. Je to GEMM kernel se smíšenou přesností INT4xFP16, který zrychluje existující 4bitové checkpointy při středních velikostech dávek. Článek o Marlinu uvádí zrychlení na A100 a H100. Pokud ho váš servingový stack podporuje, zapnete ho na už kvantizovaném modelu. „Kvantizovat pomocí Marlinu“ nelze.

SmoothQuant přesouvá odlehlé aktivace do vah přes škálovací faktor po kanálech, čímž zprovozňuje W8A8 (váhy i aktivace v INT8). Článek míří na serving s velkými dávkami, kde metody W4A16 nechávají propustnost ladem. Pokud servírujete stovky souběžných požadavků, tohle je ta správná hra.

TorchAO je kvantizace nativní pro PyTorch, která funguje s torch.compile. Žádné externí závislosti, žádný převod formátů. Pokud už je vaše inferenční pipeline na PyTorch, je to možnost s nejmenším třením. Pro lokální běh embedding modelů bývá jednodušší cesta přes Ollamu, ale TorchAO sedí custom PyTorch stackům.

Kolik VRAM kvantizovaný model potřebuje?

Vzorec je váhy (GB) ≈ parametry (B) × bity na váhu ÷ 8. Model 70B v Q4_K_M: 70 × 4,8 ÷ 8 = 42,0 GB. Hodnoty níže jsou efektivní, zpětně odvozené z velikostí souborů, které publikuje llama.cpp PR #1684, ne z čísel základního typu, protože mixy _M vždy běží nad svou základní hodnotou k-quant. Přepočítali jsme to, místo abychom opisovali obvyklou zkratku 4,0 bpw.

Spočítáno z efektivních bitů na váhu: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Odvozeno z velikostí souborů 7B (6,74B parametrů) v PR #1684 a následně zkřížově ověřeno proti publikovanému 70B buildu: Llama-3.3-70B-Instruct-Q4_K_M.gguf má 42,5 GB, proti zde předpovězeným 42,0 GB.

Poctivá výhrada: jde o pouhé váhy. KV cache, délka kontextu a režie frameworku se přičítají navrch. KV cache škáluje s délkou kontextu a velikostí dávky. Sezení s 32k kontextem na 70B modelu může přidat několik GB. Tabulka vah je podlaha, ne rozpočet. Vaše kontextové okno si VRAM taky pronajímá. Pro úplný obrázek viz požadavky VRAM podle modelů v detailu.

Kterou metodu kvantizace použít?

Váš hardware rozhodne dřív než vaše preference. Metoda, která neběží na vaší GPU, není volba, je to přání. Tabulka níže mapuje běžné setupy na metodu, která pro ně skutečně funguje, na základě hardwarových omezení a kompromisů kvality popsaných výše.

Pro většinu čtenářů na spotřebitelském hardwaru je správná odpověď předkvantizované GGUF Q4_K_M nebo Q5_K_M. Stáhněte ho z HuggingFace, spusťte v Ollamě nebo llama.cpp a přestaňte optimalizovat. Rozdíl kvality mezi Q4_K_M a Q5_K_M je dost malý na to, abyste rozhodovali podle toho, jestli se soubor vejde, ne podle tabulky perplexity. Všechno nad to je optimalizace kvůli optimalizaci a vyplatí se až ve chvíli, kdy jste ověřili, že model váš problém v Q4 skutečně řeší.

Průvodce nástroji, které tyto modely opravdu spustí lokálně, pokrývá servingovou stranu, jakmile si vyberete úroveň kvantizace.

Pět způsobů, jak kvantizace selže

Selhání kvantizace jsou téměř vždy problémy konfigurace, ne metody. Těchto pět se objevuje neustále.

1. Kalibrační sada neodpovídá vaší doméně. GPTQ i AWQ se fitují na kalibrační data. Pokud kalibrujete na Wikipedii a nasadíte na lékařské přepisy, kvantizovaný model zaostává na tokenech, které nikdy neviděl. Náprava: použijte kalibrační sadu z vaší skutečné vstupní distribuce, pomůže i 128 vzorků.

2. Příliš velká velikost skupiny. Velikost skupiny u GPTQ řídí, kolik vah sdílí škálovací faktor. Standard je 128. Hodnota 256 nebo 512 šetří výpočty během kvantizace, ale u menších modelů naráží na kvalitativní útes. Náprava: zůstaňte na 128, pokud jste nepotvrdili, že kvalita drží i na vašich promptech.

3. Očekávání, že Q2_K je použitelné. Podle dat z PR #1684 stojí Q2_K ~0,87 perplexity oproti F16 a nekoupí žádnou rychlost oproti Q4_K_S (oba 15,5 ms/token na 7B benchmarku). Získáte menší soubor a horší výstup bez zisku latence. Náprava: Q4_K_S je podlaha, pokud není velikost souboru tvrdé omezení.

4. Benchmarkování na perplexitě wikitextu místo na vlastních promptech. Perplexita je metrika jazykového modelování. Neměří, jestli model následuje váš systémový prompt, správně formátuje JSON, nebo zvládá slovní zásobu vaší domény. Náprava: prožeňte 20-30 svých reálných promptů kvantizovaným i nekvantizovaným modelem a porovnejte výstupy.

5. Záměna kontejneru GGUF s kvantizačním algoritmem uvnitř. To vede k porovnávání „GGUF vs GPTQ“, jako by šlo o stejnou kategorii. Nejde. GGUF je souborový formát. Algoritmus uvnitř, schéma k-quant, je ten algoritmus. Náprava: porovnávejte úrovně k-quant (Q4_K_M vs Q5_K_M), ne souborové formáty.

Časté dotazy

Co je kvantizace LLM?

Kvantizace LLM snižuje číselnou přesnost vah modelu, typicky ze 16bitové plovoucí čárky na 4bitová nebo 8bitová celá čísla. Tím snižuje spotřebu paměti a zrychluje inferenci omezením šířky pásma. Model 70B klesne ze 140 GB na zhruba 42 GB při 4 bitech. Cenovka kvality je obvykle 1-2 % perplexity při 4 bitech, méně při 6 bitech.

Snižuje kvantizace přesnost modelu?

Ano, ale méně, než většina lidí čeká. Podle benchmarků z llama.cpp PR #1684 stojí Q4_K_S na 7B modelu asi 2 % perplexity oproti F16 a Q6_K pod 0,1 %. Praktický dopad na reálné prompty bývá menší, než číslo perplexity naznačuje, zejména od Q4_K_M výš.

Je lepší GPTQ, nebo AWQ?

Žádná není univerzálně lepší. GPTQ používá přerozdělení chyby přes inverzní Hessiánu a hodí se pro dávkovou GPU inferenci. AWQ chrání salientní váhy přes škálování uvědomělé vůči aktivacím a hodí se pro serving citlivý na latenci. AWQ potřebuje menší kalibrační sadu a méně se na ni přeučuje. Pokud servírujete požadavky jednoho uživatele s nízkou latencí, začněte u AWQ.

Co znamená Q4_K_M?

Q4_K_M je úroveň kvantizace k-quant GGUF. „Q4“ znamená nominální 4bitovou hloubku, „K“ označuje blokové schéma k-quant (oproti legacy Q4_0) a „M“ znamená medium: tenzory attention a feed-forward dostávají extra bity. Efektivní počet bitů na váhu je kolem 4,8, ne 4,0, protože blokové škály a minima přidávají režii a medium mix navrch utrácí víc.

Spustím kvantizovaný model na CPU?

Ano, ale jen přes GGUF. GPTQ a AWQ jsou formáty pouze pro GPU. Modely k-quant v GGUF běží na CPU přes llama.cpp nebo Ollamu a podporují offload vrstev mezi VRAM GPU a systémovou RAM. Q4_K_M je standardní CPU kvant. Čekejte pomalejší generování tokenů než na GPU, ale funkční inferenci.

Jaký je rozdíl mezi GGUF a GGML?

GGML je starší tenzorová knihovna a souborový formát, který llama.cpp původně používalo. GGUF ho v srpnu 2023 nahradil jako flexibilnější kontejnerový formát s lepší podporou metadat. Soubory GGUF jsou to, co dnes stahujete z HuggingFace. Soubory GGML jsou legacy a už se téměř nešíří.

Mám si model kvantizovat sám, nebo stáhnout předkvantizovaný?

Nejdřív stáhněte předkvantizovaný. Komunity llama.cpp a HuggingFace už většinu populárních modelů kvantizovaly na každé úrovni. Vlastní kvantizace dává smysl, jen pokud potřebujete konkrétní kalibrační sadu pro svou doménu, nebo pokud pro váš model neexistuje předkvantizovaná verze.

Kdy použít kvantizaci místo menšího modelu?

Kvantizaci použijte, když potřebujete schopnosti většího modelu, ale nevejde se vám do paměti. Kvantizovaný model 70B obecně překoná nekvantizovaný 13B model na úlohách složitého uvažování. Menší model použijte tehdy, když je omezením latence, protože menší modely generují tokeny rychleji bez ohledu na kvantizaci.

Jaký je rozdíl mezi kvantizací a distilací?

Kvantizace snižuje číselnou přesnost vah existujícího modelu. Distilace trénuje menší model tak, aby napodoboval větší, a vytváří skutečně odlišnou (menší) architekturu. Kvantizace zachovává architekturu původního modelu a v principu je vratná. Distilace vytváří nový model a vyžaduje tréninkový běh.

Krátká verze: kvantizace je způsob, jak vměstnat model, který chcete, do hardwaru, který máte. Pro většinu lidí na spotřebitelských GPU nebo Apple Siliconu je předkvantizované GGUF Q4_K_M stažené z HuggingFace celé řešení. GPTQ a AWQ jsou odpovědi pro GPU serving. FP8 a SmoothQuant jsou odpovědi pro produkční propustnost. Všechno ostatní je optimalizace poté, co jste ověřili, že model funguje.

Pokud se rozhodujete, co si hostovat sami, a chcete druhý názor na párování hardwaru a metody, radi si promluvíme.