Ghid de cuantizare LLM: 7 metode comparate (cu cifrele din benchmark-uri)

Ghid de cuantizare LLM: 7 metode comparate (cu cifrele din benchmark-uri)

Llama 3.3 70B în FP16 are nevoie de 140 GB doar pentru greutăți. Două H100-uri. La Q4_K_M, același model încape în aproximativ 42 GB, adică un RTX A6000 second-hand luat de pe eBay. Această diferență este întregul motiv pentru care există cuantizarea LLM, iar alegerea metodei greșite te costă fie calitate vizibilă, fie VRAM pe care nu îl ai.

Acest ghid de cuantizare LLM compară cele 7 metode care contează în 2026, cu fiecare cifră urmărită până la o sursă publicată.

Idei esențiale

• Cuantizarea schimbă memorie și lățime de bandă pe o pierdere de calitate măsurabilă, de obicei mică.
• GPTQ și AWQ sunt orientate spre GPU; GGUF este formatul care rulează și pe CPU.
• Q4_K_M ajunge la aproape 4,8 biți per greutate, nu 4. Denumirea ascunde costul suplimentar.
• Cuantizarea pe 6 biți rămâne la ~0,1% de perplexitatea FP16, conform PR-ului k-quants din llama.cpp.

Ce face, de fapt, cuantizarea LLM cu modelul tău?

Cuantizarea LLM stochează greutățile modelului la o precizie numerică mai mică, reducând memoria și lățimea de bandă cu prețul erorilor de rotunjire. Un model de 70B parametri scade de la 140 GB în FP16 la aproximativ 42 GB pe 4 biți. Inteligența rămâne; zecimalele dispar. Fiecare metodă din acest ghid este o variantă a acestui compromis.

Scara preciziei coboară de la FP32 (32 biți) prin FP16 și BF16 (16 biți fiecare), apoi INT8, apoi INT4. Fiecare treaptă înjumătățește octeții per parametru. Standardul IEEE 754 definește formatele de virgulă mobilă; lucrarea lui Mark Horowitz din 2014, "Computing's Energy Problem", a arătat de ce mutarea acelor octeți, nu aritmetica asupra lor, domină costul energetic. Acesta este motivul fizic pentru care cuantizarea accelerează inferența.

Doi parametri fac cuantizarea să funcționeze: un factor de scalare (multiplicatorul care mapează intervalul de întregi înapoi la valori reale) și un punct de zero (întregul care reprezintă 0.0). Cuantizarea simetrică centrează intervalul pe zero și omite punctul de zero; cuantizarea asimetrică îl decalează pentru a folosi întregul interval de întregi atunci când greutățile se grupează departe de zero.

Greutățile se cuantizează curat pentru că sunt statice și distribuite normal. Activările, nu. Activările outlier, uneori de 100x peste mediană, explodează eroarea de rotunjire dacă le cuantizezi naiv. Această asimetrie explică de ce majoritatea metodelor de aici cuantizează doar greutățile (W4A16) și lasă activările în FP16.

Cuantizarea post-antrenament (PTQ) convertește un model terminat, după antrenare. Antrenarea conștientă de cuantizare (QAT) simulează rotunjirea în timpul antrenării, ca modelul să se adapteze. Tot ce e în acest articol este PTQ. QAT costă mai mult calcul și o rulare de antrenare; este o decizie separată.

Rândurile INT4 și NF4 sunt teoretice, 4 biți puri: 4 biți per greutate și nimic altceva. Formatele reale pe 4 biți poartă scale și minime de bloc pe deasupra, deci ajung mai sus. Un model 70B la Q4_K_M are aproximativ 42 GB, nu 35. Tabelul de VRAM de mai jos folosește ratele efective.

Cuantizarea nu micșorează inteligența modelului. Micșorează numărul de zecimale în care stochează acea inteligență. Iar dacă plătești per token pentru inferență API, reducerea facturii la API-ul LLM începe adesea cu rularea unui model cuantizat pe cont propriu.

Cele 7 metode de cuantizare, una lângă alta

Cele șapte metode de mai jos acoperă fiecare cale de producție pentru cuantizarea unui LLM în 2026. Două sunt exclusiv GPU (GPTQ, AWQ), una rulează oriunde (GGUF), una cuantizează la încărcare (BitsandBytes), două țintesc servirea cu debit ridicat (SmoothQuant, FP8), iar una este nativă PyTorch (TorchAO). Alegerea potrivită depinde de hardware-ul tău, nu de metoda cu cel mai mare scor într-un clasament.

GPTQ cuantizează strat cu strat folosind hessiana inversă pentru a redistribui eroarea de rotunjire între greutățile rămase. Are nevoie de un set de calibrare și de un GPU. Lucrarea GPTQ raportează cuantizarea unui model 175B la 3-4 biți în aproximativ 4 ore-GPU.

AWQ identifică ~1% dintre greutățile care contează cel mai mult (greutăți saliente, găsite din magnitudinile activărilor) și le scalează pentru a le proteja de rotunjire. Lucrarea AWQ (cel mai bun paper MLSys 2024) raportează o accelerare de peste 3x față de implementarea FP16 HuggingFace, atât pe GPU-uri desktop, cât și mobile.

GGUF este un format de fișier, nu un algoritm. Algoritmul din interior este schema de blocuri k-quant din llama.cpp PR #1684. Este singura metodă de aici care rulează pe CPU, ceea ce o face alegerea implicită pentru inferența locală. Vezi modele open-weight care merită cuantizate pentru ce să-i dai să ruleze.

BitsandBytes cuantizează la încărcare, nu din timp. NF4 (4-bit NormalFloat) este formatul său emblematic și coloana vertebrală a fine-tuning-ului QLoRA. Nu e nevoie de set de calibrare.

SmoothQuant mută outlier-ele activărilor în greutăți, astfel încât ambele să ruleze la INT8. Lucrarea raportează o accelerare de până la 1,56x și o reducere de 2x a memoriei și țintește debitul în servirea cu loturi mari, unde metodele W4A16 lasă performanță pe masă.

FP8 (W8A8) este calea nativă pe GPU-urile H100 și B200. Aproape lossless la 8 biți, fără bătăi de cap cu calibrarea, iar vLLM îl suportă direct.

TorchAO este biblioteca proprie de cuantizare a PyTorch, construită să lucreze cu torch.compile. Dacă pipeline-ul tău este deja PyTorch, este calea cu cea mai mică frecare.

Există doar două întrebări reale: hardware-ul tău o rulează și poți trăi cu costul de calitate?

Ce arată, de fapt, benchmark-urile publicate?

Benchmark-urile publicate spun că cuantizarea pe 4 biți costă 1-2% perplexitate pe un model 7B, iar cea pe 6 biți sub 0,1%. Cifrele vin din llama.cpp PR #1684 (2023), măsurate de maintainer-ii llama.cpp pe un singur model 7B, pe un RTX 4080. Sunt cele mai citate cifre din spațiul cuantizării și sunt reale. Sunt și n = 1.

Sursă: llama.cpp PR #1684 (2023). Model 7B, RTX 4080, măsurat de maintainer-ii llama.cpp. n = 1 model.

O notă despre coloana biți/greutate: acestea sunt ratele nominale pentru tipul k-quant de bază, iar mixurile _K ridică rata efectivă. Q2_K este un exemplu. Aplică formula din articol peste valoarea nominală 2,5625 și un model de 6,74B parametri și obții ~2,0 GB, dar rândul raportează un fișier de 2,67 GB, ceea ce se rezolvă invers la ~3,4 biți per greutate. Restul articolului folosește ratele efective, derivate din aceste dimensiuni de fișier.

Cifrele metodelor GPU vin direct din lucrări. GPTQ raportează accelerări de inferență end-to-end față de FP16 de aproximativ 3,25x pe A100 și ~4,5x pe A6000, cu un model 175B cuantizat la 3-4 biți în circa 4 ore-GPU. AWQ raportează „o accelerare de peste 3x față de implementarea FP16 HuggingFace, atât pe GPU-uri desktop, cât și mobile", plus prima implementare Llama-2 70B pe un GPU mobil prin TinyChat. Cităm formularea lucrării în loc să parafrazăm o cifră într-o falsă precizie.

Contribuția originală de aici este aritmetica. Memoria pentru greutăți urmează: weights (GB) ≈ params (B) × bits per weight ÷ 8. Capcana este ce număr de biți-per-greutate îi dai. PR #1684 publică rata pentru tipul k-quant de bază (Q4_K = 4,5), iar mixurile _S/_M/_L stau deasupra acelei rate de bază pentru că alocă biți suplimentari tensorilor de atenție și feed-forward. Așa că am derivat ratele efective din dimensiunile de fișier publicate chiar de PR, pe un model 7B care are de fapt 6,74B parametri: Q2_K la 2,67 GB se rezolvă invers la ~3,4 bpw, Q4_K_S la 3,56 GB la ~4,5, Q6_K la 5,15 GB la ~6,6. Q4_K_M ajunge la aproape 4,8.

Asta schimbă cifra din titlu. Un model 70B la Q4_K_M: 70 × 4,8 ÷ 8 = 42 GB. Majoritatea articolelor spun 35 GB. Folosesc 4,0 bpw și sar complet peste costul scalelor de bloc. Verificarea durează un clic: Llama-3.3-70B-Instruct-Q4_K_M.gguf vine la 42,5 GB pe HuggingFace, deopotrivă în repo-urile bartowski, lmstudio-community și second-state. Am recalculat fiecare celulă din tabelul de VRAM de mai jos pe această bază.

Interpretarea noastră a acestor cifre: diferența de perplexitate între Q6_K (5,9110) și F16 (5,9066) este 0,0044, mai mică decât diferența între două fine-tune-uri diferite ale aceluiași model de bază. De aceea „folosește pur și simplu Q4_K_M sau Q5_K_M" este sfatul care supraviețuiește contactului cu hardware-ul real. Coloana ms/token arată și că Q2_K nu cumpără nicio viteză față de Q4_K_S (ambele 15,5 ms/token), în timp ce costă 0,75 perplexitate. Q2_K este cel mai prost compromis din tabel.

Ce nu-ți spun cifrele: perplexitatea pe wikitext nu este același lucru cu calitatea pe prompturile tale. Un model pe un GPU este n = 1. Cifrele de viteză depind de batch size. Tratează-le ca orientative, nu universale.

Cuantizarea pe 6 biți ajunge la aproximativ 0,1% din perplexitatea modelului full-precision. Compresia este aproape gratuită la acel nivel.

GPTQ vs AWQ: alegerea între cele două metode GPU

GPTQ și AWQ produc ambele checkpoint-uri GPU pe 4 biți dintr-un set de calibrare și ambele sunt bine suportate în vLLM. Diferența este cum tratează eroarea de rotunjire. GPTQ o redistribuie între greutățile rămase folosind hessiana inversă. AWQ protejează 1% dintre greutățile pe care activările le marchează ca importante. Ambele funcționează. Alegerea ține de tiparul tău de servire.

GPTQ lucrează strat cu strat. Pentru fiecare strat, cuantizează câte o greutate, apoi ajustează greutățile rămase din acel strat pentru a compensa rotunjirea tocmai făcută. Ajustarea folosește informații de ordinul doi din matricea hessiană, de aceea are nevoie de un set de calibrare pentru calcul. Rezultatul este puternic pentru inferența pe loturi, unde debitul contează mai mult decât latența per token.

AWQ abordează problema altfel. Identifică greutățile saliente privind magnitudinile activărilor pe setul de calibrare, aproximativ 1% dintre canale. Acele greutăți primesc un factor de scalare per canal care le ține într-un interval de precizie mai înaltă la rotunjire. Setul de calibrare poate fi mai mic decât al GPTQ, iar AWQ se suprapotrivește mai puțin pe el, pentru că protejează trăsături structurale în loc să se potrivească pe intrări specifice. Lucrarea raportează rezultate puternice pe servirea sensibilă la latență.

Alege GPTQ dacă: faci inferență pe loturi pe GPU, ai un set de calibrare bun potrivit domeniului tău, iar debitul este metrica.

Alege AWQ dacă: servești cereri single-user cu latență mică, vrei un set de calibrare mai mic sau implementezi pe GPU-uri edge/mobile.

# 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

Dacă alegi și între motoarele de servire, vLLM comparat cu SGLang acoperă acea decizie separat.

GGUF și K-Quants: ce înseamnă, de fapt, Q4_K_M

GGUF este un format de fișier, nu un algoritm de cuantizare. Specificația GGUF definește un container pentru greutățile modelului, metadate și datele tokenizerului. Algoritmul de cuantizare dintr-un fișier GGUF este schema de blocuri k-quant (sau i-quant) din llama.cpp PR #1684. A confunda containerul cu algoritmul este cea mai frecventă greșeală din acest spațiu și duce la întrebări precum „care e mai bun, GGUF sau GPTQ?", care nu prea au sens.

Schema de denumire se decodifică astfel. Q înseamnă schema de blocuri k-quant; IQ înseamnă i-quant cu matrice de importanță (o variantă mai nouă care folosește o matrice de importanță pentru calitate mai bună la aceeași adâncime de biți). Numărul este adâncimea nominală de biți. _K marchează familia k-quant față de formatele moștenite precum Q4_0. _S, _M, _L controlează ce grupuri de tensori primesc biți suplimentari: small, medium, large. Sufixul mai înalt înseamnă mai mulți biți alocați tensorilor de atenție și feed-forward care contează cel mai mult.

Rate efective, rezolvate invers din dimensiunile de fișier 7B (6,74B parametri) publicate în PR #1684, nu cifrele tipului de bază. Rândurile moștenite sunt exacte prin construcție: un bloc Q4_0 are 32 de greutăți pe 4 biți plus o scală FP16, adică 4,5 biți per greutate, iar Q8_0 are 32 de greutăți pe 8 biți plus o scală FP16, adică 8,5. PR-ul coroborează, listând fișierele 7B Q4_0 și Q4_K_S la același 3,56 GB.

Q4_K_M nu are 4 biți per greutate. Are aproximativ 4,8. Scalele și minimele de bloc trebuie să stea undeva, iar mixul _M cheltuie apoi biți suplimentari pe tensorii de atenție și feed-forward, exact de ce Q4_K_M stă deasupra Q4_K_S și Q3_K_M deasupra Q3_K_S în loc să-l egaleze.

De ce GGUF rulează unde GPTQ nu poate: suportă inferență CPU și offload de straturi între VRAM-ul GPU și RAM-ul sistemului. Un model 32B care nu încape complet pe GPU poate rula cu jumătate din straturi offload-ate, lent, dar funcțional. GPTQ nu are cale CPU.

# 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

Ești nou în modelele locale? Începe cu pornirea primului tău model local înainte să cuantizezi ceva. Iar dacă vrei o interfață în browser, Open WebUI peste Ollama durează cam zece minute. Documentația GGUF HuggingFace explică cum expune Hub denumirile tipurilor de cuantizare.

BitsandBytes, Marlin, SmoothQuant și TorchAO

Aceste patru acoperă căile de producție rămase. Niciuna nu este un „GPTQ mai bun". Rezolvă probleme diferite.

BitsandBytes cuantizează la momentul încărcării, nu dinainte. Îl îndrepți spre un checkpoint FP16 și convertește pe loc la NF4 sau FP4. Fără set de calibrare, fără pas offline. Principala sa realizare este QLoRA: un model de bază înghețat pe 4 biți cu adaptoare LoRA antrenate deasupra, ceea ce face fine-tuning-ul pe un singur GPU al unui model 65B posibil pe 48 GB de VRAM. QLoRA este o tehnică de antrenare, nu de inferență, dar este motivul pentru care majoritatea întâlnesc BitsandBytes prima dată.

Marlin nu este o metodă de cuantizare. Este un kernel GEMM cu precizie mixtă INT4xFP16 care face checkpoint-urile existente pe 4 biți mai rapide la batch size-uri moderate. Lucrarea Marlin raportează accelerări pe A100 și H100. Dacă stack-ul tău de servire îl suportă, îl activezi pe un model deja cuantizat. Nu „cuantizezi cu Marlin".

SmoothQuant mută outlier-ele activărilor în greutăți printr-un factor de scalare per canal, făcând W8A8 (greutăți și activări, ambele la INT8) viabil. Lucrarea țintește servirea cu loturi mari, unde metodele W4A16 lasă debit pe masă. Dacă servești sute de cereri concurente, aceasta este mișcarea.

TorchAO este cuantizarea nativă PyTorch care lucrează cu torch.compile. Fără dependențe externe, fără conversie de format. Dacă pipeline-ul tău de inferență este deja PyTorch, este opțiunea cu cea mai mică frecare. Pentru rularea locală a modelelor de embedding, calea Ollama este de obicei mai simplă, dar TorchAO se potrivește stack-urilor PyTorch personalizate.

De cât VRAM are nevoie un model cuantizat?

Formula este weights (GB) ≈ params (B) × bits per weight ÷ 8. Un model 70B la Q4_K_M: 70 × 4,8 ÷ 8 = 42,0 GB. Ratele de mai jos sunt efective, rezolvate invers din dimensiunile de fișier publicate de llama.cpp PR #1684, nu din numerele tipului de bază, pentru că mixurile _M rulează mereu peste rata k-quant de bază. Am recalculat în loc să copiem scurtătura obișnuită de 4,0 bpw.

Calculat din biți-per-greutate efectivi: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Derivat din dimensiunile de fișier 7B (6,74B parametri) din PR #1684, apoi verificat încrucișat cu un build 70B publicat: Llama-3.3-70B-Instruct-Q4_K_M.gguf are 42,5 GB pe HuggingFace, față de 42,0 GB prezis aici.

Avertismentul sincer: acestea sunt doar greutățile. KV cache, lungimea contextului și overhead-ul framework-ului se adaugă deasupra. KV cache-ul scalează cu lungimea contextului și batch size-ul. O sesiune cu context de 32k pe un model 70B poate adăuga câțiva GB. Tabelul greutăților este podeaua, nu bugetul. Fereastra de context închiriază și ea VRAM. Pentru imaginea completă, vezi cerințele de VRAM per model, în detaliu.

Ce metodă de cuantizare ar trebui să folosești?

Hardware-ul tău decide înaintea preferințelor tale. O metodă care nu rulează pe GPU-ul tău nu este o alegere, este o dorință. Tabelul de mai jos mapează configurațiile comune la metoda care chiar funcționează pentru ele, pe baza constrângerilor hardware și a compromisurilor de calitate acoperite mai sus.

Pentru majoritatea cititorilor pe hardware de consum, un GGUF Q4_K_M sau Q5_K_M pre-cuantizat este răspunsul corect. Trage-l de pe HuggingFace, rulează-l în Ollama sau llama.cpp și oprește-te din optimizat. Diferența de calitate între Q4_K_M și Q5_K_M este suficient de mică încât ar trebui să alegi după cum încape fișierul, nu după un tabel de perplexitate. Orice dincolo de asta este optimizare de dragul optimizării și merită făcută doar după ce ai confirmat că modelul chiar îți rezolvă problema la Q4.

Ghidul instrumentelor care chiar rulează aceste modele local acoperă partea de servire după ce ai ales un nivel de cuantizare.

Cinci moduri în care cuantizarea merge prost

Eșecurile de cuantizare sunt aproape mereu probleme de configurare, nu de metodă. Acestea cinci apar constant.

1. Setul de calibrare nu corespunde domeniului tău. GPTQ și AWQ se calibreză ambele pe datele primite. Dacă calibrezi pe Wikipedia și implementezi pe transcrieri medicale, modelul cuantizat subperformează pe tokenurile pe care nu le-a văzut niciodată. Soluție: folosește un set de calibrare extras din distribuția ta reală de intrare, chiar și 128 de eșantioane ajută.

2. Group size prea mare. Group size-ul GPTQ controlează câte greutăți împart un factor de scalare. 128 este standardul. 256 sau 512 economisește calcul la cuantizare, dar lovește un zid de calitate pe modele mai mici. Soluție: rămâi la 128 dacă nu ai confirmat că ține calitatea pe prompturile tale.

3. Așteptarea ca Q2_K să fie utilizabil. Conform datelor din PR #1684, Q2_K costă ~0,87 perplexitate față de F16 și nu cumpără nicio viteză față de Q4_K_S (ambele 15,5 ms/token pe benchmark-ul 7B). Primești un fișier mai mic și un output mai prost, fără câștig de latență. Soluție: Q4_K_S este podeaua, dacă dimensiunea fișierului nu este o constrângere dură.

4. Benchmark pe wikitext în loc de prompturile tale. Perplexitatea este o metrică de modelare a limbii. Nu măsoară dacă modelul îți urmează promptul de sistem, formatează JSON corect sau îți gestionează vocabularul domeniului. Soluție: rulează 20-30 dintre prompturile tale reale prin modelul cuantizat și prin cel necuantizat și compară output-urile.

5. Confuzia dintre containerul GGUF și algoritmul de cuantizare din el. Asta duce la compararea „GGUF vs GPTQ" ca și cum ar fi aceeași categorie. Nu sunt. GGUF este un format de fișier. Schema k-quant din interior este algoritmul. Soluție: compară nivelurile k-quant (Q4_K_M vs Q5_K_M), nu formatele de fișier.

Întrebări frecvente

Ce este cuantizarea LLM?

Cuantizarea LLM reduce precizia numerică a greutăților unui model, de obicei de la virgulă mobilă pe 16 biți la întregi pe 4 sau 8 biți. Asta reduce consumul de memorie și accelerează inferența prin micșorarea lățimii de bandă. Un model 70B scade de la 140 GB la aproximativ 42 GB pe 4 biți. Costul de calitate este de obicei 1-2% perplexitate la 4 biți, mai puțin la 6 biți.

Cuantizarea reduce acuratețea unui model?

Da, dar mai puțin decât se așteaptă majoritatea. Conform benchmark-urilor din llama.cpp PR #1684, Q4_K_S pe un model 7B costă aproximativ 2% perplexitate față de F16, iar Q6_K sub 0,1%. Impactul practic pe prompturi reale este adesea mai mic decât sugerează cifra de perplexitate, mai ales la Q4_K_M și peste.

GPTQ sau AWQ este mai bun?

Niciunul nu este universal mai bun. GPTQ folosește redistribuirea erorii prin hessiana inversă și se potrivește inferenței GPU pe loturi. AWQ protejează greutățile saliente prin scalare conștientă de activări și se potrivește servirii sensibile la latență. AWQ are nevoie de un set de calibrare mai mic și se suprapotrivește mai puțin pe el. Dacă servești cereri single-user cu latență mică, începe cu AWQ.

Ce înseamnă Q4_K_M?

Q4_K_M este un nivel de cuantizare GGUF k-quant. „Q4" înseamnă adâncime nominală de 4 biți, „K" marchează schema de blocuri k-quant (față de Q4_0 moștenit), iar „M" înseamnă medium: tensorii de atenție și feed-forward primesc biți suplimentari. Biții efectivi per greutate sunt aproximativ 4,8, nu 4,0, pentru că scalele și minimele de bloc adaugă overhead, iar mixul mediu cheltuie și mai mult pe deasupra.

Pot rula un model cuantizat pe CPU?

Da, dar doar prin GGUF. GPTQ și AWQ sunt formate exclusiv GPU. Modelele k-quant GGUF rulează pe CPU prin llama.cpp sau Ollama și suportă offload de straturi între VRAM-ul GPU și RAM-ul sistemului. Q4_K_M este cuantizarea standard pentru CPU. Așteaptă-te la o generare de tokeni mai lentă decât pe GPU, dar la o inferență funcțională.

Care este diferența între GGUF și GGML?

GGML este biblioteca de tensori și formatul de fișier mai vechi pe care llama.cpp le folosea inițial. GGUF l-a înlocuit în august 2023 ca format de container mai flexibil, cu suport mai bun pentru metadate. Fișierele GGUF sunt cele pe care le descarci azi de pe HuggingFace. Fișierele GGML sunt moștenite și rar mai sunt distribuite.

Să cuantizez singur un model sau să descarc unul pre-cuantizat?

Descarcă mai întâi unul pre-cuantizat. Comunitățile llama.cpp și HuggingFace au cuantizat deja majoritatea modelelor populare la fiecare nivel. Să cuantizezi singur are sens doar dacă ai nevoie de un set de calibrare specific pentru domeniul tău sau dacă nu există nicio versiune pre-cuantizată pentru modelul tău.

Când să folosesc cuantizarea în locul unui model mai mic?

Folosește cuantizarea când ai nevoie de capabilitatea modelului mai mare, dar nu încape în memorie. Un model 70B cuantizat depășește în general un model 13B necuantizat pe sarcini complexe de raționament. Folosește în schimb un model mai mic atunci când latența este constrângerea, deoarece modelele mai mici generează tokeni mai rapid indiferent de cuantizare.

Care este diferența între cuantizare și distilare?

Cuantizarea reduce precizia numerică a greutăților unui model existent. Distilarea antrenează un model mai mic să imite unul mai mare, producând o arhitectură cu adevărat diferită (mai mică). Cuantizarea păstrează arhitectura modelului original și este reversibilă în principiu. Distilarea creează un model nou și necesită o rulare de antrenare.

Versiunea scurtă: cuantizarea este modul în care potrivești un model pe care îl vrei în hardware-ul pe care îl ai. Pentru majoritatea oamenilor pe GPU-uri de consum sau Apple Silicon, un GGUF Q4_K_M pre-cuantizat tras de pe HuggingFace este întreaga soluție. GPTQ și AWQ sunt răspunsurile pentru servirea pe GPU. FP8 și SmoothQuant sunt răspunsurile pentru debitul de producție. Orice altceva este optimizare după ce ai confirmat că modelul funcționează.

Dacă decizi ce să auto-găzduiești și vrei o a doua opinie despre împerecherea hardware-metodă, suntem bucuroși să discutăm.