LLM-kvantisointiopas: 7 menetelmää vertailtuna (benchmark-luvuilla)

LLM-kvantisointiopas: 7 menetelmää vertailtuna (benchmark-luvuilla)

Llama 3.3 70B tarvitsee FP16-muodossa pelkkiin painoihin 140 GB. Kaksi H100-korttia. Q4_K_M-tasolla sama malli mahtuu suunnilleen 42 gigatavuun, eli yhteen käytettyyn eBaysta ostettuun RTX A6000 -korttiin. Juuri tämä kuilu on koko syy siihen, miksi LLM-kvantisointi on olemassa, ja väärän menetelmän valinta maksaa sinulle joko näkyvää laatua tai VRAM-muistia, jota sinulla ei ole.

Tämä LLM-kvantisointiopas vertailee seitsemää menetelmää, joilla on merkitystä vuonna 2026, ja jokainen luku on jäljitetty julkaistuun lähteeseen.

Keskeiset havainnot

• Kvantisointi vaihtaa muistia ja kaistanleveyttä mitattavissa olevaan, yleensä pieneen, laatuhäviöön.
• GPTQ ja AWQ ovat GPU-ensijaisia; GGUF on muoto, joka toimii myös CPU:lla.
• Q4_K_M päätyy lähelle 4,8 bittiä painoa kohti, ei 4:ää. Nimeäminen piilottaa päälle tulevan lisätilan.
• 6-bittinen kvantisointi pysyy noin 0,1 prosentin sisällä FP16-perpleksisyydestä llama.cpp:n k-quants-PR:n mukaan.

Mitä LLM-kvantisointi oikeasti tekee mallillesi?

LLM-kvantisointi tallentaa mallin painot pienemmällä numeerisella tarkkuudella, mikä kutistaa muistia ja kaistanleveyttä pyöristysvirheen hinnalla. 70B-parametrinen malli putoaa FP16-tason 140 gigatavusta noin 42 gigatavuun 4-bittisenä. Älykkyys säilyy; desimaalit lähtevät. Jokainen tämän oppaan menetelmä on muunnelma tästä vaihtokaupasta.

Tarkkuustikkaita laskeutuu FP32:sta (32 bittiä) FP16:n ja BF16:n kautta (kumpikin 16 bittiä), sitten INT8:aan ja lopulta INT4:ään. Jokainen porras puolittaa parametria kohti käytetyt tavut. IEEE 754 -standardi määrittelee liukulukumuodot; Mark Horowitzin vuoden 2014 paperi "Computing's Energy Problem" osoitti, miksi juuri näiden tavujen siirtely, ei niillä tehtävä laskenta, hallitsee energiakustannuksia. Se on fysikaalinen syy siihen, miksi kvantisointi nopeuttaa inferenssiä.

Kaksi parametria saa kvantisoinnin toimimaan: skaalauskerroin (kerroin, joka palauttaa kokonaislukualueen takaisin oikeiksi arvoiksi) ja nollapiste (kokonaisluku, joka edustaa arvoa 0,0). Symmetrinen kvantisointi asettaa alueen keskiön nollaan ja jättää nollapisteen pois; asymmetrinen kvantisointi siirtää sitä, jotta koko kokonaislukualue tulee käyttöön, kun painot kasautuvat kauas nollasta.

Painot kvantisoituvat siististi, koska ne ovat staattisia ja normaalijakautuneita. Aktivaatiot eivät kvantisoidu. Aktivaatiopoikkeamat, joskus 100-kertaisia mediaaniin nähden, räjäyttävät pyöristysvirheen, jos ne kvantisoi suoralta kädeltä. Juuri tämä epäsymmetria on syynä siihen, miksi useimmat tämän oppaan menetelmät kvantisoivat vain painot (W4A16) ja jättävät aktivaatiot FP16-tasolle.

Koulutuksen jälkeinen kvantisointi (PTQ) muuntaa valmiin mallin koulutuksen jälkeen. Kvantisointitietoinen koulutus (QAT) simuloi pyöristystä koulutuksen aikana, jotta malli sopeutuu. Kaikki tässä artikkelissa käsiteltävä on PTQ:ta. QAT maksaa enemmän laskentaa ja vaatii oman koulutusajon; se on erillinen päätös.

INT4- ja NF4-rivit ovat teoreettista puhdasta 4-bittisyyttä: 4 bittiä painoa kohti eikä mitään muuta. Todelliset 4-bittiset muodot kantavat päällään lohkoskaaloja ja minimiarvoja, joten ne päätyvät korkeammalle. 70B-malli Q4_K_M-tasolla on noin 42 GB, ei 35. Alempana oleva VRAM-taulukko käyttää sen sijaan todellisia kertoimia.

Kvantisointi ei kutista mallin älykkyyttä. Se kutistaa niiden desimaalien määrää, joihin malli tallentaa älykkyytensä. Ja jos maksat API-inferenssistä tokenia kohden, LLM-API-laskun pienentäminen alkaa usein siitä, että ajat kvantisoidun mallin itse.

Seitsemän kvantisointimenetelmää rinnakkain

Alla olevat seitsemän menetelmää kattavat jokaisen tuotantokelpoisen polun LLM:n kvantisointiin vuonna 2026. Kaksi on vain GPU:lle (GPTQ, AWQ), yksi toimii kaikkialla (GGUF), yksi kvantisoi lataushetkellä (BitsandBytes), kaksi tähtää suuren läpimenon tarjoiluun (SmoothQuant, FP8) ja yksi on PyTorch-natiivi (TorchAO). Oikea valinta riippuu laitteistostasi, ei siitä, mikä menetelmä saa korkeimmat pisteet tulostaululla.

GPTQ kvantisoi kerros kerrallaan käyttäen käänteistä Hessian-matriisia jakamaan pyöristysvirheen jäljelle jäävien painojen kesken. Se tarvitsee kalibrointijoukon ja GPU:n. GPTQ-paperi raportoi 175B-mallin kvantisoinnista 3-4 bittiin noin 4 GPU-tunnissa.

AWQ tunnistaa noin 1 prosenttia painoista, joilla on eniten merkitystä (merkittävät painot, jotka löydetään aktivaatioiden suuruuksista), ja skaalaa ne suojaamaan niitä pyöristykseltä. AWQ-paperi (MLSys 2024 -konferenssin paras paperi) raportoi yli 3-kertaisesta nopeutuksesta HuggingFacen FP16-toteutukseen nähden sekä pöytäkone- että mobiili-GPU:illa.

GGUF on tiedostomuoto, ei algoritmi. Sen sisällä oleva algoritmi on k-quant-lohkomalli llama.cpp PR #1684:stä. Se on ainoa tässä listassa oleva menetelmä, joka toimii CPU:lla, mikä tekee siitä paikallisen inferenssin oletusvalinnan. Katso kvantisoitavat avoimen painoarvon mallit, niin tiedät, mitä sille syöttää.

BitsandBytes kvantisoi latauksen yhteydessä eikä etukäteen. NF4 (4-bittinen NormalFloat) on sen tunnusomainen muoto, ja se on QLoRA-hienosäädön selkäranka. Kalibrointijoukkoa ei tarvita.

SmoothQuant siirtää aktivaatiopoikkeamat painoihin, jotta molemmat voidaan ajaa INT8-tasolla. Paperi raportoi jopa 1,56-kertaisesta nopeutuksesta ja 2-kertaisesta muistin vähenemisestä, ja se tähtää läpimenoon suuren erän tarjoilussa, jossa W4A16-menetelmät jättävät suorituskykyä pöydälle.

FP8 (W8A8) on natiivi polku H100- ja B200-GPU:illa. Lähes häviötön 8-bittisenä, ei kalibrointipäänvaivaa, ja vLLM tukee sitä suoraan.

TorchAO on PyTorchin oma kvantisointikirjasto, joka on rakennettu toimimaan torch.compile-komennon kanssa. Jos putkesi on jo PyTorch-pohjainen, se on kitkattomin vaihtoehto.

Todellisia kysymyksiä on vain kaksi: pyöriikö menetelmä laitteistossasi, ja voitko elää sen maksaman laadun kanssa?

Mitä julkaistut benchmarkit oikeasti osoittavat?

Julkaistut benchmarkit kertovat 4-bittisen kvantisoinnin maksavan 1-2 prosenttia perpleksisyydestä 7B-mallilla ja 6-bittisen maksavan alle 0,1 prosenttia. Nämä luvut ovat peräisin llama.cpp PR #1684:stä (2023), ja ne mittasivat llama.cpp:n ylläpitäjät yhdellä 7B-mallilla RTX 4080 -kortilla. Ne ovat kvantisointialan siteeratuimmat luvut, ja ne ovat todellisia. Ne ovat myös n = 1.

Lähde: llama.cpp PR #1684 (2023). 7B-malli, RTX 4080, mittaajina llama.cpp:n ylläpitäjät. n = 1 malli.

Huomio bittiä/paino-sarakkeesta: nuo ovat kunkin k-quant-perustyypin nimelliskertoimia, ja _K-sekoitukset nostavat todellista kerrointa. Q2_K on hyvä esimerkki. Kun artikkelin oma kaava ajetaan nimellisarvolla 2,5625 ja 6,74B-parametrisella mallilla, tulokseksi saa ~2,0 GB, mutta rivi raportoi 2,67 GB:n tiedoston, josta takaisinlaskettuna saadaan ~3,4 bittiä painoa kohti. Loput tästä artikkelista käyttävät todellisia kertoimia, jotka on johdettu näistä tiedostokoista.

GPU-menetelmien luvut tulevat suoraan papereista. GPTQ raportoi FP16:sta mitatuista loppupään inferenssinopeutuksista, jotka ovat suunnilleen 3,25x A100-kortilla ja ~4,5x A6000-kortilla, 175B-mallin kvantisoiduttua 3-4 bittiin noin 4 GPU-tunnissa. AWQ raportoi "yli 3-kertaisesta nopeutuksesta Huggingfacen FP16-toteutukseen nähden sekä pöytäkone- että mobiili-GPU:illa" sekä ensimmäisestä 70B Llama-2-käyttöönotosta mobiili-GPU:lla TinyChatin kautta. Lainoamme paperin sanamuotoja sen sijaan, että muotoilisimme luvun uudelleen väärän tarkkuuden antavaksi.

Tämän artikkelin oma panos on laskutoimitus. Painojen muistitarve noudattaa kaavaa: painot (GB) ≈ parametrit (B) × bittiä painoa kohti ÷ 8. Koukku on siinä, minkä bittiä-painoa-kohti-luvun kaavaan syöttää. PR #1684 julkaisee perus-k-quant-tyypin kertoimen (Q4_K = 4,5), ja _S/_M/_L-sekoitukset asettuvat tuon peruskertoimen yläpuolelle, koska ne antavat lisäbittejä attention- ja feed-forward-tensoreille. Joten johdimme todelliset kertoimet PR:n itsensä julkaisemista tiedostokoista 7B-mallilla, joka on todellisuudessa 6,74B-parametrinen: Q2_K 2,67 GB:lla takaisinlaskettuna ~3,4 bpw, Q4_K_S 3,56 GB:lla ~4,5, Q6_K 5,15 GB:lla ~6,6. Q4_K_M päätyy lähelle 4,8:aa.

Se muuttaa otsikkolukua. 70B-malli Q4_K_M-tasolla: 70 × 4,8 ÷ 8 = 42 GB. Useimmat artikkelit sanovat 35 GB. Ne käyttävät 4,0 bpw:tä ja ohittavat lohkoskaalojen lisätilan kokonaan. Ristiintarkistus vie yhden klikkauksen: Llama-3.3-70B-Instruct-Q4_K_M.gguf toimitetaan 42,5 GB:n kokoisena HuggingFacessa, yhtä lailla bartowskin, lmstudio-communityn ja second-staten repoissa. Laskimme alla olevan VRAM-taulukon jokaisen solun uudelleen tällä perusteella.

Meidän tulkintamme näistä luvuista: perpleksisyyskuilu Q6_K:n (5,9110) ja F16:n (5,9066) välillä on 0,0044, mikä on pienempi kuin kuilu saman perusmallin kahden eri hienosäädön välillä. Siksi neuvo "käytä vain Q4_K_M:ää tai Q5_K_M:ää" kestää kosketuksen todellisen laitteiston kanssa. Ms/token-sarake osoittaa myös, ettei Q2_K osta mitään nopeusetua Q4_K_S:ään nähden (molemmat 15,5 ms/token), mutta maksaa 0,75 perpleksisyyttä. Q2_K on taulukon huonoin vaihtokauppa.

Mitä luvut eivät kerro: wikitext-perpleksisyys ei ole sama asia kuin laatu sinun prompteillasi. Yksi malli yhdellä GPU:lla on n = 1. Nopeusluvut riippuvat batch-koosta. Käsittele näitä suuntaa-antavina, ei yleispätevinä.

6-bittinen kvantisointi päätyy noin 0,1 prosentin sisällä täystarkkuusmallin perpleksisyydestä. Pakkaus on lähes ilmaista tuolla tasolla.

GPTQ vai AWQ: valinta kahden GPU-menetelmän välillä

GPTQ ja AWQ tuottavat molemmat 4-bittisiä GPU-tallennuspisteitä kalibrointijoukosta, ja molemmat ovat hyvin tuettuja vLLM:ssä. Ero on siinä, miten ne käsittelevät pyöristysvirhettä. GPTQ jakaa sen jäljelle jäävien painojen kesken käänteisen Hessian-matriisin avulla. AWQ suojaa 1 prosentin painoista, jotka aktivaatiot merkitsevät tärkeiksi. Molemmat toimivat. Valinta koskee tarjoilutapaasi.

GPTQ toimii kerros kerrallaan. Jokaisessa kerroksessa se kvantisoi yhden painon kerrallaan ja säätää sitten kyseisen kerroksen jäljelle jääviä painoja kompensoimaan juuri tekemäänsä pyöristystä. Säätö käyttää toisen kertaluvun tietoa Hessian-matriisista, minkä vuoksi se tarvitsee kalibrointijoukon laskettavakseen. Tulos on vahva batch-inferenssissä, jossa läpimeno merkitsee enemmän kuin tokenikohtainen viive.

AWQ lähestyy asiaa eri kulmasta. Se tunnistaa merkittävät painot tarkastelemalla aktivaatioiden suuruuksia kalibrointijoukossa, suunnilleen kanavien yläprosentin. Nuo painot saavat kanavakohtaisen skaalauksen, joka pitää ne korkeamman tarkkuuden alueella pyöristyksen aikana. Kalibrointijoukko voi olla pienempi kuin GPTQ:n, ja AWQ ylisovittaa siihen vähemmän, koska se suojaa rakenteellisia piirteitä eikä sovita itseään tiettyihin syötteisiin. Paperi raportoi vahvoista tuloksista viiveherkässä tarjoilussa.

Valitse GPTQ, jos: ajat batch-inferenssiä GPU:lla, sinulla on domainiasi vastaava hyvä kalibrointijoukko ja läpimeno on mittarisi.

Valitse AWQ, jos: tarjoilet yhden käyttäjän pyyntöjä pienellä viiveellä, haluat pienemmän kalibrointijoukon tai otat käyttöön reuna- tai mobiili-GPU:illa.

# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

Jos olet valitsemassa myös tarjoilumoottorien välillä, vLLM verrattuna SGLangiin käsittelee tuon päätöksen erikseen.

GGUF ja K-Quants: mitä Q4_K_M oikeasti tarkoittaa

GGUF on tiedostomuoto, ei kvantisointialgoritmi. GGUF-spesifikaatio määrittelee säilön mallin painoille, metadatalle ja tokenisaattoridatalle. GGUF-tiedoston sisällä oleva kvantisointialgoritmi on k-quant- (tai i-quant-) lohkomalli llama.cpp PR #1684:stä. Säilön sekoittaminen algoritmiin on alan yleisin virhe, ja se johtaa kysymyksiin kuten "kumpi on parempi, GGUF vai GPTQ?", jotka eivät oikein aukea.

Nimeämisjärjestelmä avautuu seuraavasti. Q tarkoittaa k-quant-lohkomallia; IQ tarkoittaa importance-matriisiin perustuvaa i-quantia (uudempi muunnelma, joka käyttää tärkeys­matriisia paremman laadun saavuttamiseen samalla bittisyvyydellä). Numero on nimellinen bittisyvyys. _K merkitsee k-quant-perhettä verrattuna vanhoihin muotoihin kuten Q4_0. _S, _M, _L määräävät, mitkä tensoriryhmät saavat lisäbittejä: small, medium, large. Korkeampi pääte tarkoittaa, että enemmän bittejä kohdennetaan tärkeimpiin attention- ja feed-forward-tensoreihin.

Todelliset kertoimet, takaisinlaskettuina PR #1684:ssä julkaistuista 7B-mallin (6,74B-parametrisen) tiedostokoista, ei perustyypin luvuista. Legacy-rivit ovat tarkkoja rakenteensa puolesta: Q4_0-lohko on 32 painoa 4 bitillä plus yksi FP16-skaala, mikä on 4,5 bittiä painoa kohti, ja Q8_0 on 32 painoa 8 bitillä plus FP16-skaala, mikä on 8,5. PR vahvistaa sen listaamalla 7B-mallin Q4_0- ja Q4_K_S-tiedostot samaan 3,56 GB:n kokoon.

Q4_K_M ei ole 4 bittiä painoa kohti. Se on noin 4,8. Lohkoskaalojen ja minimiarvojen on asuttava jossain, ja _M-sekoitus kuluttaa sitten lisäbittejä attention- ja feed-forward-tensoreihin, mikä on täsmälleen syy siihen, miksi Q4_K_M asettuu Q4_K_S:n yläpuolelle ja Q3_K_M Q3_K_S:n yläpuolelle sen sijaan, että vastaisi sitä.

Miksi GGUF toimii siellä, missä GPTQ ei pysty: se tukee CPU-inferenssiä ja kerrosten offloadausta GPU:n VRAM-muistin ja järjestelmämuistin välillä. 32B-malli, joka ei mahdu kokonaan GPU:llesi, voi toimia puolet kerroksistaan offloadattuina, hitaasti mutta toimivasti. GPTQ:lla ei ole CPU-polkua.

# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

Oletko uusi paikallisille malleille? Aloita ensimmäisen paikallisen mallin käynnistämisestä ennen minkään kvantisointia. Ja jos haluat selainkäyttöliittymän, Open WebUI Ollaman päälle vie noin kymmenen minuuttia. HuggingFacen GGUF-dokumentaatio selittää, miten Hub esittelee kvanttitason nimeämisen.

BitsandBytes, Marlin, SmoothQuant ja TorchAO

Nämä neljä kattavat jäljelle jäävät tuotantopolut. Mikään niistä ei ole "parempi GPTQ". Ne ratkaisevat eri ongelmia.

BitsandBytes kvantisoi lataushetkellä, ei etukäteen. Osoitat sen FP16-tallennuspisteeseen, ja se muuntaa lennossa NF4:ksi tai FP4:ksi. Ei kalibrointijoukkoa, ei offline-vaihetta. Sen tunnetuin ansio on QLoRA: 4-bittinen jäädytetty perusmalli, jonka päälle koulutetaan LoRA-sovittimet, mikä tekee 65B-mallin hienosäädöstä mahdollisen yhdellä GPU:lla 48 gigatavun VRAM-muistissa. QLoRA on koulutustekniikka, ei inferenssitekniikka, mutta se on syy siihen, miksi useimmat törmäävät BitsandBytesiin ensimmäisenä.

Marlin ei ole kvantisointimenetelmä. Se on INT4xFP16-sekatarkkuus-GEMM-ydin, joka tekee olemassa olevista 4-bittisistä tallennuspisteistä nopeampia kohtuullisilla batch-koilla. Marlin-paperi raportoi nopeutuksista A100- ja H100-korteilla. Jos tarjoilupinossasi on sille tuki, otat sen käyttöön jo kvantisoidussa mallissa. Et "kvantisoi Marlinilla".

SmoothQuant siirtää aktivaatiopoikkeamat painoihin kanavakohtaisen skaalauskertoimen avulla, mikä tekee W8A8:sta (sekä painot että aktivaatiot INT8-tasolla) käyttökelpoisen. Paperi tähtää suuren erän tarjoiluun, jossa W4A16-menetelmät jättävät läpimenoa pöydälle. Jos tarjoilet satoja samanaikaisia pyyntöjä, tämä on oikea siirto.

TorchAO on PyTorch-natiivi kvantisointi, joka toimii torch.compile-komennon kanssa. Ei ulkoisia riippuvuuksia, ei muodon muunnosta. Jos inferenssiputkesi on jo PyTorch-pohjainen, se on vähäkitkaisin vaihtoehto. Embedding-mallien paikalliseen ajamiseen Ollama-polku on yleensä yksinkertaisempi, mutta TorchAO sopii räätälöityihin PyTorch-pinoihin.

Kuinka paljon VRAM-muistia kvantisoitu malli tarvitsee?

Kaava on painot (GB) ≈ parametrit (B) × bittiä painoa kohti ÷ 8. 70B-malli Q4_K_M-tasolla: 70 × 4,8 ÷ 8 = 42,0 GB. Alla olevat kertoimet ovat todellisia, takaisinlaskettuina tiedostokoista, jotka llama.cpp PR #1684 julkaisee, eikä perustyypin luvuista, koska _M-sekoitukset kulkevat aina perus-k-quant-kertoimensa yläpuolella. Laskimme uudelleen sen sijaan, että olisimme kopioineet tavallisen 4,0-bpw-oikotien.

Laskettu todellisista biteistä painoa kohti: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Johdettu PR #1684:n 7B-mallin (6,74B-parametrisen) tiedostokoista ja ristiintarkistettu sitten julkaistua 70B-koostetta vasten: Llama-3.3-70B-Instruct-Q4_K_M.gguf on 42,5 GB HuggingFacessa, kun tässä ennustetaan 42,0 GB.

Rehellinen varaus: tämä koskee vain painoja. KV-välimuisti, kontekstin pituus ja kehyksen lisätila tulevat päälle. KV-välimuisti skaalautuu kontekstin pituuden ja batch-koon mukaan. 32k-kontekstin istunto 70B-mallilla voi lisätä useita gigatavuja. Painotaulukko on lattia, ei budjetti. Konteksti-ikkunasi vuokraa myös VRAM-muistia. Katso koko kuva mallikohtaisista VRAM-vaatimuksista yksityiskohtaisesti.

Mitä kvantisointimenetelmää sinun kannattaa käyttää?

Laitteistosi päättää ennen mieltymyksiäsi. Menetelmä, joka ei pyöri GPU:llasi, ei ole valinta, vaan toive. Alla oleva taulukko yhdistää yleiset kokoonpanot menetelmään, joka todella toimii niillä, perustuen yllä käsiteltyihin laitteistorajoitteisiin ja laatuvaihtokauppoihin.

Useimmille kuluttajalaitteistolla toimiville lukijoille valmiiksi kvantisoitu Q4_K_M- tai Q5_K_M-GGUF on oikea vastaus. Nouda se HuggingFacesta, aja sitä Ollamassa tai llama.cpp:ssä ja lopeta optimointi. Laatuero Q4_K_M:n ja Q5_K_M:n välillä on riittävän pieni, että valinta kannattaa tehdä sen mukaan, mahtuuko tiedosto, eikä perpleksisyystaulukon perusteella. Kaikki sen tuolla puolen on optimointia optimoinnin itsensä vuoksi, ja se kannattaa vasta, kun olet vahvistanut mallin todella ratkaisevan ongelmasi Q4-tasolla.

Opas työkaluista, jotka oikeasti ajavat näitä malleja paikallisesti kattaa tarjoilupuolet, kun olet valinnut kvanttitason.

Viisi tapaa, joilla kvantisointi menee pieleen

Kvantisointivirheet ovat lähes aina asetusten ongelmia, eivät menetelmän ongelmia. Nämä viisi ilmaantuvat jatkuvasti.

1. Kalibrointijoukko ei vastaa domainiasi. GPTQ ja AWQ sovittavat itsensä molemmat kalibrointidataan. Jos kalibrointi tehdään Wikipedialla ja käyttöönotto lääketieteellisillä litteroinneilla, kvantisoitu malli suoriutuu heikommin tokeneista, joita se ei koskaan nähnyt. Korjaus: käytä kalibrointijoukkoa, joka on otettu todellisesta syötejakaumastasi; jopa 128 näytettä auttaa.

2. Ryhmäkoko asetettu liian suureksi. GPTQ:n ryhmäkoko määrää, kuinka monta painoa jakaa yhden skaalauksen. 128 on standardi. 256 tai 512 säästää laskentaa kvantisoinnin aikana, mutta osuu laatujyrkänteeseen pienemmillä malleilla. Korjaus: pysy arvossa 128, ellet ole vahvistanut laadun pitävän omilla prompteillasi.

3. Odotat Q2_K:n olevan käyttökelpoinen. PR #1684:n datan mukaan Q2_K maksaa ~0,87 perpleksisyyttä verrattuna F16:een eikä osta nopeusetua Q4_K_S:ään nähden (molemmat 15,5 ms/token 7B-benchmarkissa). Saat pienemmän tiedoston ja huonomman tuloksen ilman viivehyötyä. Korjaus: Q4_K_S on lattia, ellei tiedostokoko ole kova rajoite.

4. Benchmarkkaat wikitext-perpleksisyydellä omien promptiesi sijaan. Perpleksisyys on kielimallinnuksen mittari. Se ei mittaa, noudattaako malli järjestelmäpromptiasi, muotoileeko se JSON:in oikein tai hallitseeko se domainisi sanaston. Korjaus: aja 20-30 todellista promptiasi sekä kvantisoidun että kvantisoimattoman mallin läpi ja vertaa tuloksia.

5. Sekoitat GGUF-säilön sen sisällä olevaan kvantisointialgoritmiin. Tämä johtaa vertailuun "GGUF vs GPTQ" ikään kuin ne olisivat sama kategoria. Eivät ole. GGUF on tiedostomuoto. Sen sisällä oleva k-quant-malli on algoritmi. Korjaus: vertaa k-quant-tasoja (Q4_K_M vs Q5_K_M), älä tiedostomuotoja.

Usein kysytyt kysymykset

Mitä on LLM-kvantisointi?

LLM-kvantisointi pienentää mallin painojen numeerista tarkkuutta, tyypillisesti 16-bittisestä liukuluvusta 4- tai 8-bittisiin kokonaislukuihin. Tämä leikkaa muistinkäyttöä ja nopeuttaa inferenssiä vähentämällä kaistanleveyttä. 70B-malli putoaa 140 gigatavusta noin 42 gigatavuun 4-bittisenä. Laatuhinta on yleensä 1-2 prosenttia perpleksisyydestä 4-bittisenä, vähemmän 6-bittisenä.

Heikentääkö kvantisointi mallin tarkkuutta?

Kyllä, mutta vähemmän kuin useimmat odottavat. llama.cpp PR #1684:n benchmarkien mukaan Q4_K_S 7B-mallilla maksaa noin 2 prosenttia perpleksisyydestä verrattuna F16:een, ja Q6_K maksaa alle 0,1 prosenttia. Käytännön vaikutus todellisiin promptteihin on usein pienempi kuin perpleksisyysluku antaa ymmärtää, erityisesti Q4_K_M-tasolla ja siitä ylöspäin.

Onko GPTQ vai AWQ parempi?

Kumpikaan ei ole yleisesti parempi. GPTQ käyttää käänteiseen Hessian-matriisiin perustuvaa virheen jakoa ja sopii batch-inferenssiin GPU:lla. AWQ suojaa merkittäviä painoja aktivaatiotietoisella skaalauksella ja sopii viiveherkkään tarjoiluun. AWQ tarvitsee pienemmän kalibrointijoukon ja ylisovittaa siihen vähemmän. Jos tarjoilet yhden käyttäjän pyyntöjä pienellä viiveellä, aloita AWQ:sta.

Mitä Q4_K_M tarkoittaa?

Q4_K_M on k-quant-GGUF-kvantisointitaso. "Q4" tarkoittaa nimellistä 4-bittistä syvyyttä, "K" merkitsee k-quant-lohkomallia (verrattuna vanhaan Q4_0:aan) ja "M" tarkoittaa mediumia: attention- ja feed-forward-tensorit saavat lisäbittejä. Todellinen bittimäärä painoa kohti on noin 4,8, ei 4,0, koska lohkoskaalat ja minimiarvot tuovat lisätilaa ja medium-sekoitus kuluttaa vielä lisää päälle.

Voiko kvantisoidun mallin ajaa CPU:lla?

Kyllä, mutta vain GGUF:n kautta. GPTQ ja AWQ ovat vain GPU:lle tarkoitettuja muotoja. GGUF:n k-quant-mallit toimivat CPU:lla llama.cpp:n tai Ollaman kautta ja tukevat kerrosten offloadausta GPU:n VRAM-muistin ja järjestelmämuistin välillä. Q4_K_M on CPU:n vakiokvantti. Odota hitaampaa tokenien tuotantoa kuin GPU:lla, mutta toimivaa inferenssiä.

Mikä on ero GGUF:n ja GGML:n välillä?

GGML on vanhempi tensorikirjasto ja tiedostomuoto, jota llama.cpp alun perin käytti. GGUF korvasi sen elokuussa 2023 joustavampana säilömuotona, jolla on parempi metadatatuki. GGUF-tiedostoja ovat ne, joita lataat HuggingFacesta nykyään. GGML-tiedostot ovat vanhentuneita eikä niitä juuri enää jaella.

Kannattaako malli kvantisoida itse vai ladata valmiiksi kvantisoitu?

Lataa ensin valmiiksi kvantisoitu. llama.cpp- ja HuggingFace-yhteisöt ovat jo kvantisoineet useimmat suositut mallit jokaiselle tasolle. Itse kvantisointi on järkevää vain, jos tarvitset domainillesi tietyn kalibrointijoukon tai jos mallistasi ei ole olemassa valmiiksi kvantisoitua versiota.

Milloin kannattaa käyttää kvantisointia pienemmän mallin sijaan?

Käytä kvantisointia, kun tarvitset suuremman mallin kyvykkyyttä mutta et saa sitä mahtumaan muistiin. Kvantisoitu 70B-malli suoriutuu yleensä paremmin kuin kvantisoimaton 13B-malli monimutkaisissa päättelytehtävissä. Käytä sen sijaan pienempää mallia, kun viive on rajoite, koska pienemmät mallit tuottavat tokeneita nopeammin kvantisoinnista riippumatta.

Mikä on ero kvantisoinnin ja tislauksen välillä?

Kvantisointi pienentää olemassa olevan mallin painojen numeerista tarkkuutta. Tislaus kouluttaa pienemmän mallin jäljittelemään suurempaa, jolloin syntyy aidosti erilainen (pienempi) arkkitehtuuri. Kvantisointi säilyttää alkuperäisen mallin arkkitehtuurin ja on periaatteessa palautuva. Tislaus luo uuden mallin ja vaatii oman koulutusajon.

Lyhyt versio: kvantisointi on tapa sovittaa haluamasi malli käytössäsi olevaan laitteistoon. Useimmille kuluttaja-GPU:illa tai Apple Siliconilla toimiville valmiiksi kvantisoitu, HuggingFacesta noudettu Q4_K_M-GGUF on koko ratkaisu. GPTQ ja AWQ ovat GPU-tarjoilun vastaukset. FP8 ja SmoothQuant ovat tuotannon läpimenon vastaukset. Kaikki muu on optimointia sen jälkeen, kun olet vahvistanut mallin toimivan.

Jos olet päättämässä, mitä ajat omalla palvelimellasi, ja haluat toisen mielipiteen laitteiston ja menetelmän yhdistelmästä, keskustelemme mielellämme.