Guide till LLM-kvantisering: 7 metoder jämförda (med benchmarksiffrorna)

Guide till LLM-kvantisering: 7 metoder jämförda (med benchmarksiffrorna)

Llama 3.3 70B i FP16 kräver 140 GB bara för vikterna. Två H100. Med Q4_K_M får samma modell plats på ungefär 42 GB, vilket motsvarar ett begagnat RTX A6000 från eBay. Det gapet är hela anledningen till att LLM-kvantisering finns, och väljer du fel metod betalar du antingen med synlig kvalitet eller med VRAM du inte har.

Den här guiden till LLM-kvantisering jämför de 7 metoder som spelar roll 2026, med varje siffra spårbar till en publicerad källa.

Det viktigaste

• Kvantisering byter minne och bandbredd mot en mätbar, oftast liten, kvalitetsförlust.
• GPTQ och AWQ är GPU-först; GGUF är formatet som även kör på CPU.
• Q4_K_M landar nära 4,8 bitar per vikt, inte 4. Namnet döljer overheaden.
• 6-bitars kvantisering ligger inom ~0,1 % från FP16-perplexity enligt llama.cpp:s k-quants-PR.

Vad gör LLM-kvantisering egentligen med din modell?

LLM-kvantisering lagrar modellens vikter med lägre numerisk precision, vilket krymper minne och bandbredd till priset av avrundningsfel. En modell på 70B parametrar sjunker från 140 GB i FP16 till ungefär 42 GB vid 4 bitar. Intelligensen finns kvar; decimalerna försvinner. Varje metod i den här guiden är en variant av den avvägningen.

Precisionsskalan går från FP32 (32 bitar) ner genom FP16 och BF16 (16 bitar vardera), sedan INT8 och INT4. Varje steg halverar antalet byte per parameter. IEEE 754-standarden definierar flyttalsformaten; Mark Horowitz artikel från 2014, "Computing's Energy Problem", visade varför det är flytten av dessa byte, inte beräkningarna på dem, som dominerar energikostnaden. Det är den fysiska anledningen till att kvantisering snabbar upp inferens.

Två parametrar får kvantiseringen att fungera: en skalfaktor (en multiplikator som mappar tillbaka heltalsintervallet till reella värden) och en nollpunkt (det heltal som representerar 0,0). Symmetrisk kvantisering centrerar intervallet kring noll och hoppar över nollpunkten; asymmetrisk kvantisering förskjuter det för att utnyttja hela heltalsintervallet när vikterna samlas långt från noll.

Vikter kvantiserar rent eftersom de är statiska och normalfördelade. Aktiveringar gör det inte. Avvikande aktiveringar, ibland 100 gånger medianen, spränger avrundningsfelet om du kvantiserar dem naivt. Den asymmetrin är anledningen till att de flesta metoder här bara kvantiserar vikter (W4A16) och lämnar aktiveringarna i FP16.

Post-training quantization (PTQ) konverterar en färdig modell efter träning. Quantization-aware training (QAT) simulerar avrundning under träningen så att modellen anpassar sig. Allt i det här inlägget är PTQ. QAT kostar mer beräkning och en träningskörning; det är ett separat beslut.

INT4- och NF4-raderna är teoretisk ren 4-bit: 4 bitar per vikt och ingenting annat. Riktiga 4-bitarsformat bär blockskalor och min-värden ovanpå, så de landar högre. En 70B-modell i Q4_K_M är ungefär 42 GB, inte 35. VRAM-tabellen längre ner använder de effektiva talen i stället.

Kvantisering krymper inte modellens intelligens. Den krymper antalet decimaler som intelligensen lagras i. Och om du betalar per token för API-inferens börjar sänkningen av din LLM-API-faktura ofta med att du kör en kvantiserad modell själv.

De 7 kvantiseringsmetoderna, sida vid sida

De sju metoderna nedan täcker varje produktionsväg för kvantisering av en LLM 2026. Två är rena GPU-metoder (GPTQ, AWQ), en kör överallt (GGUF), en kvantiserar vid inläsning (BitsandBytes), två siktar på serving med hög genomströmning (SmoothQuant, FP8) och en är PyTorch-native (TorchAO). Rätt val beror på din hårdvara, inte på vilken metod som toppar någon topplista.

GPTQ kvantiserar lager för lager med inversa hessianen för att fördela om avrundningsfelet över återstående vikter. Det kräver ett kalibreringsset och en GPU. GPTQ-artikeln rapporterar kvantisering av en 175B-modell till 3-4 bitar på ungefär 4 GPU-timmar.

AWQ identifierar de ~1 % av vikterna som betyder mest (salienta vikter, hittade via aktiveringarnas magnitud) och skalar dem för att skydda dem mot avrundning. AWQ-artikeln (bästa artikel på MLSys 2024) rapporterar mer än 3x speedup jämfört med HuggingFaces FP16-implementation, på både desktop- och mobil-GPU:er.

GGUF är ett filformat, inte en algoritm. Algoritmen inuti är k-quant-blockschemat från llama.cpp PR #1684. Det är den enda metoden här som kör på CPU, vilket gör den till standardvalet för lokal inferens. Se öppna modeller värda att kvantisera för vad du ska mata den med.

BitsandBytes kvantiserar vid inläsning i stället för i förväg. NF4 (4-bit NormalFloat) är dess signaturformat, och det är ryggraden i QLoRA-finetuning. Inget kalibreringsset behövs.

SmoothQuant flyttar aktiveringsavvikare in i vikterna så att båda kan köras i INT8. Artikeln rapporterar upp till 1,56x speedup och 2x minnesminskning, och siktar på genomströmning i serving med stora batcher, där W4A16-metoder lämnar prestanda på bordet.

FP8 (W8A8) är den native vägen på H100- och B200-GPU:er. Nära förlustfri vid 8 bitar, inget kalibreringshuvudbry, och vLLM stöder det direkt.

TorchAO är PyTorchs eget kvantiseringsbibliotek, byggt för att fungera med torch.compile. Om din pipeline redan är PyTorch är det minsta motståndets lag.

Det finns bara två verkliga frågor: kan din hårdvara köra den, och kan du leva med kvaliteten den kostar?

Vad visar de publicerade benchmarksen egentligen?

Publicerade benchmarks säger att 4-bitars kvantisering kostar 1-2 % perplexity på en 7B-modell, och att 6 bitar kostar under 0,1 %. Siffrorna kommer från llama.cpp PR #1684 (2023), uppmätta av llama.cpp-utvecklarna på en enda 7B-modell på ett RTX 4080. Det är de mest citerade siffrorna i kvantiseringsvärlden, och de är verkliga. De är också n = 1.

Källa: llama.cpp PR #1684 (2023). 7B-modell, RTX 4080, uppmätt av llama.cpp-utvecklarna. n = 1 modell.

En not om kolumnen bitar/vikt: det är de nominella talen för bas-k-quant-typen, och _K-mixarna höjer det effektiva talet. Q2_K är ett exempel. Kör inläggets egen formel på det nominella 2,5625 och en modell på 6,74B parametrar så får du ~2,0 GB, men raden rapporterar en fil på 2,67 GB, vilket baklänges ger ~3,4 bitar per vikt. Resten av inlägget använder de effektiva talen, härledda ur dessa filstorlekar.

Siffrorna för GPU-metoderna kommer direkt från artiklarna. GPTQ rapporterar end-to-end-speeduper mot FP16 på ungefär 3,25x på ett A100 och ~4,5x på ett A6000, med en 175B-modell kvantiserad till 3-4 bitar på ungefär 4 GPU-timmar. AWQ rapporterar "more than 3x speedup over the Huggingface FP16 implementation on both desktop and mobile GPUs", plus den första 70B Llama-2-driftsättningen på ett mobil-GPU via TinyChat. Vi citerar artikelns ordalydelse i stället för att parafrasera en siffra till falsk precision.

Det ursprungliga bidraget här är aritmetik. Minnet för vikter följer: vikter (GB) ≈ parametrar (B) × bitar per vikt ÷ 8. Haken är vilket bitar-per-vikt-tal du matar in. PR #1684 publicerar talet för bas-k-quant-typen (Q4_K = 4,5), och _S/_M/_L-mixarna ligger ovanför det bastalet eftersom de ger extra bitar till attention- och feed-forward-tensorerna. Så vi härledde de effektiva talen från filstorlekarna som PR:et självt publicerar, på en 7B-modell som egentligen är 6,74B parametrar: Q2_K på 2,67 GB ger baklänges ~3,4 bpw, Q4_K_S på 3,56 GB ~4,5, Q6_K på 5,15 GB ~6,6. Q4_K_M landar nära 4,8.

Det ändrar rubriksiffran. En 70B-modell i Q4_K_M: 70 × 4,8 ÷ 8 = 42 GB. De flesta inlägg säger 35 GB. De använder 4,0 bpw och hoppar helt över blockskale-overheaden. Korskontrollen tar ett klick: Llama-3.3-70B-Instruct-Q4_K_M.gguf levereras på 42,5 GB på HuggingFace, i alla tre repos: bartowski, lmstudio-community och second-state. Vi räknade om varje cell i VRAM-tabellen nedan på den grunden.

Vår läsning av siffrorna: perplexity-gapet mellan Q6_K (5,9110) och F16 (5,9066) är 0,0044, vilket är mindre än gapet mellan två olika finetunes av samma basmodell. Därför är "kör bara Q4_K_M eller Q5_K_M" rådet som överlever kontakt med riktig hårdvara. Kolumnen ms/token visar också att Q2_K inte köper någon hastighet jämfört med Q4_K_S (båda 15,5 ms/token) samtidigt som det kostar 0,75 perplexity. Q2_K är den sämsta affären i tabellen.

Vad siffrorna inte säger dig: wikitext-perplexity är inte samma sak som kvalitet på dina prompter. En modell på ett GPU är n = 1. Hastighetssiffror beror på batchstorlek. Behandla dem som riktningsgivande, inte universella.

Sex-bitars kvantisering landar inom ungefär 0,1 % från fullprecisionsmodellens perplexity. På den nivån är komprimeringen nästan gratis.

GPTQ vs AWQ: välja mellan de två GPU-metoderna

GPTQ och AWQ producerar båda 4-bitars GPU-checkpoints från ett kalibreringsset, och båda stöds väl i vLLM. Skillnaden är hur de hanterar avrundningsfel. GPTQ fördelar om det över återstående vikter med inversa hessianen. AWQ skyddar den 1 % av vikterna som aktiveringarna pekar ut som viktiga. Båda fungerar. Valet handlar om ditt serving-mönster.

GPTQ arbetar lager för lager. För varje lager kvantiserar det en vikt i taget och justerar sedan återstående vikter i lagret för att kompensera för avrundningen det nyss gjorde. Justeringen använder andrahandsinformation från hessianmatrisen, vilket är anledningen till att det behöver ett kalibreringsset för att beräknas. Resultatet är starkt för batch-inferens där genomströmning betyder mer än latens per token.

AWQ tar en annan vinkel. Det identifierar salienta vikter genom att titta på aktiveringsmagnituder över kalibreringssetet, ungefär den översta 1 % av kanalerna. De vikterna får en skalfaktor per kanal som håller dem i ett högre precisionsintervall under avrundningen. Kalibreringssetet kan vara mindre än GPTQ:s, och AWQ överanpassar mindre till det eftersom det skyddar strukturella drag i stället för att anpassa sig till specifika indata. Artikeln rapporterar starka resultat för latenskänslig serving.

Välj GPTQ om: du kör batch-inferens på GPU, har ett bra kalibreringsset som matchar din domän och genomströmning är nyckeltalet.

Välj AWQ om: du servar enanvändarbegäranden med låg latens, vill ha ett mindre kalibreringsset eller driftsätter på edge-/mobil-GPU:er.

# 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

Om du också väljer mellan servingmotorer täcker vLLM mot SGLang det beslutet separat.

GGUF och K-quants: vad Q4_K_M egentligen betyder

GGUF är ett filformat, inte en kvantiseringsalgoritm. GGUF-specen definierar en behållare för modellvikter, metadata och tokenizerdata. Kvantiseringsalgoritmen inuti en GGUF-fil är k-quant- (eller i-quant-) blockschemat från llama.cpp PR #1684. Att blanda ihop behållaren med algoritmen är det vanligaste misstaget i den här världen, och det leder till frågor som "vilket är bäst, GGUF eller GPTQ?" som inte riktigt håller.

Namnschemat avkodas så här. Q betyder k-quant-blockschema; IQ betyder importance-matrix-i-quant (en nyare variant som använder en viktmatris för bättre kvalitet vid samma bitdjup). Siffran är det nominella bitdjupet. _K markerar k-quant-familjen mot legacy-format som Q4_0. _S, _M, _L styr vilka tensorgrupper som får extra bitar: small, medium, large. Högre suffix betyder fler bitar till de attention- och feed-forward-tensorer som betyder mest.

Effektiva tal, baklänges lösta ur filstorlekarna för 7B (6,74B parametrar) som publicerats i PR #1684, inte bastypens siffror. Legacy-raderna är exakta per konstruktion: ett Q4_0-block är 32 vikter på 4 bitar plus en FP16-skala, vilket blir 4,5 bitar per vikt, och Q8_0 är 32 vikter på 8 bitar plus en FP16-skala, vilket blir 8,5. PR:et bekräftar det och listar 7B-filerna Q4_0 och Q4_K_S på samma 3,56 GB.

Q4_K_M är inte 4 bitar per vikt. Det är ungefär 4,8. Blockskalorna och min-värdena måste bo någonstans, och _M-mixen spenderar sedan extra bitar på attention- och feed-forward-tensorerna, vilket är precis varför Q4_K_M ligger över Q4_K_S och Q3_K_M ligger över Q3_K_S i stället för att matcha det.

Varför GGUF kör där GPTQ inte kan: det stöder CPU-inferens och lager-offloading mellan GPU-VRAM och system-RAM. En 32B-modell som inte får plats helt på ditt GPU kan köras med hälften av lagren offloadade, långsamt men funktionellt. GPTQ har ingen CPU-väg.

# 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

Ny på lokala modeller? Börja med att få din första lokala modell att köra innan du kvantiserar något. Och om du vill ha ett webbläsar-UI tar Open WebUI ovanpå Ollama ungefär tio minuter. HuggingFaces GGUF-dokumentation förklarar hur Hubben exponerar namngivningen av quant-typer.

BitsandBytes, Marlin, SmoothQuant och TorchAO

Dessa fyra täcker återstående produktionsvägar. Ingen är ett "bättre GPTQ". De löser olika problem.

BitsandBytes kvantiserar vid inläsning, inte i förväg. Du pekar det mot en FP16-checkpoint så konverterar det i flykten till NF4 eller FP4. Inget kalibreringsset, inget offlinesteg. Dess främsta merit är QLoRA: en 4-bitars frusen basmodell med LoRA-adaptrar tränade ovanpå, vilket gör finetuning av en 65B-modell på ett enda GPU möjlig på 48 GB VRAM. QLoRA är en träningsteknik, inte en inferensteknik, men det är anledningen till att de flesta stöter på BitsandBytes först.

Marlin är inte en kvantiseringsmetod. Det är en INT4xFP16 mixed-precision GEMM-kernel som gör befintliga 4-bitars checkpoints snabbare vid måttliga batchstorlekar. Marlin-artikeln rapporterar speeduper på A100 och H100. Om din servingstack stöder det aktiverar du det på en redan kvantiserad modell. Man "kvantiserar inte med Marlin".

SmoothQuant flyttar aktiveringsavvikare in i vikterna via en skalfaktor per kanal, vilket gör W8A8 (både vikter och aktiveringar i INT8) livsdugligt. Artikeln siktar på serving med stora batcher där W4A16-metoder lämnar genomströmning på bordet. Servar du hundratals samtidiga begäranden är det här draget.

TorchAO är PyTorch-native-kvantisering som fungerar med torch.compile. Inga externa beroenden, ingen formatkonvertering. Om din inferenspipeline redan är PyTorch är det det friktionsfriaste alternativet. För att köra embeddingmodeller lokalt är Ollama-vägen oftast enklare, men TorchAO passar egna PyTorch-stackar.

Hur mycket VRAM behöver en kvantiserad modell?

Formeln är vikter (GB) ≈ parametrar (B) × bitar per vikt ÷ 8. En 70B-modell i Q4_K_M: 70 × 4,8 ÷ 8 = 42,0 GB. Talen nedan är effektiva, baklänges lösta ur filstorlekarna som llama.cpp PR #1684 publicerar, inte ur bastypens siffror, eftersom _M-mixarna alltid ligger över sin bas-k-quant-nivå. Vi räknade om i stället för att kopiera den vanliga 4,0-bpw-genvägen.

Beräknat från effektiva bitar per vikt: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Härlett ur filstorlekarna för 7B (6,74B parametrar) i PR #1684, sedan korskontrollerat mot ett publicerat 70B-bygge: Llama-3.3-70B-Instruct-Q4_K_M.gguf är 42,5 GB på HuggingFace, mot här förutsagda 42,0 GB.

Den ärliga brasklappen: det här är bara vikter. KV-cache, kontextlängd och framework-overhead tillkommer. KV-cachen skalar med kontextlängd och batchstorlek. En session med 32k kontext på en 70B-modell kan lägga till flera GB. Vikttabellen är golvet, inte budgeten. Ditt kontextfönster hyr också VRAM. För hela bilden, se VRAM-krav per modell i detalj.

Vilken kvantiseringsmetod ska du använda?

Din hårdvara bestämmer före dina preferenser. En metod som inte kör på ditt GPU är inte ett val, det är en önskan. Tabellen nedan kopplar vanliga setuper till metoden som faktiskt fungerar för dem, utifrån hårdvarubegränsningarna och kvalitetsavvägningarna ovan.

För de flesta läsare på konsumenthårdvara är en färdigkvantiserad Q4_K_M- eller Q5_K_M-GGUF rätt svar. Hämta den från HuggingFace, kör den i Ollama eller llama.cpp och sluta optimera. Kvalitetsskillnaden mellan Q4_K_M och Q5_K_M är liten nog att du bör välja utifrån om filen får plats, inte utifrån en perplexity-tabell. Allt utöver det är optimering för optimeringens egen skull, och det är bara värt att göra när du har bekräftat att modellen faktiskt löser ditt problem vid Q4.

Guiden om verktygen som faktiskt kör dessa modeller lokalt täcker serving-sidan när du har valt en quant-nivå.

Fem sätt som kvantisering går fel

Kvantiseringsfel är nästan alltid konfigurationsproblem, inte metodproblem. Dessa fem dyker upp ständigt.

1. Kalibreringssetet matchar inte din domän. GPTQ och AWQ anpassar sig båda till kalibreringsdatan. Om du kalibrerar på Wikipedia och driftsätter på medicinska transkript presterar den kvantiserade modellen sämre på de tokens den aldrig såg. Lösning: använd ett kalibreringsset draget från din faktiska indatadistribution, även 128 sampel hjälper.

2. Grupstorleken är för stor. GPTQ:s grupstorlek styr hur många vikter som delar en skalfaktor. 128 är standard. 256 eller 512 sparar beräkning under kvantiseringen men kör in i en kvalitetsvägg på mindre modeller. Lösning: stanna på 128 om du inte har bekräftat att kvaliteten håller på dina prompter.

3. Att förvänta sig att Q2_K är användbar. Enligt data från PR #1684 kostar Q2_K ~0,87 perplexity mot F16 och köper ingen hastighet jämfört med Q4_K_S (båda 15,5 ms/token på 7B-benchmarket). Du får en mindre fil och sämre utdata utan latensvinst. Lösning: Q4_K_S är golvet om inte filstorleken är ett hårt krav.

4. Benchmarka på wikitext-perplexity i stället för dina egna prompter. Perplexity är ett språkmodelleringsmått. Det mäter inte om modellen följer din systemprompt, formaterar JSON korrekt eller hanterar din domäns vokabulär. Lösning: kör 20-30 av dina riktiga prompter genom både den kvantiserade och okvantiserade modellen och jämför utdata.

5. Att blanda ihop GGUF-behållaren med kvantiseringsalgoritmen inuti. Det leder till att jämföra "GGUF vs GPTQ" som om de vore samma kategori. Det är de inte. GGUF är ett filformat. K-quant-schemat inuti är algoritmen. Lösning: jämför k-quant-nivåer (Q4_K_M vs Q5_K_M), inte filformat.

Vanliga frågor

Vad är LLM-kvantisering?

LLM-kvantisering minskar den numeriska precisionen i en modells vikter, typiskt från 16-bitars flyttal till 4- eller 8-bitars heltal. Det sänker minnesanvändningen och snabbar upp inferensen genom att minska bandbredden. En 70B-modell sjunker från 140 GB till ungefär 42 GB vid 4 bitar. Kvalitetskostnaden är oftast 1-2 % perplexity vid 4 bitar, mindre vid 6 bitar.

Minskar kvantisering en modells noggrannhet?

Ja, men mindre än de flesta tror. Enligt benchmarksen i llama.cpp PR #1684 kostar Q4_K_S på en 7B-modell ungefär 2 % perplexity mot F16, och Q6_K kostar under 0,1 %. Den praktiska effekten på riktiga prompter är ofta mindre än perplexity-siffran antyder, särskilt från Q4_K_M och uppåt.

Är GPTQ eller AWQ bäst?

Ingen är universellt bättre. GPTQ använder felomfördelning med inversa hessianen och passar batch-inferens på GPU. AWQ skyddar salienta vikter via aktiveringsmedveten skalning och passar latenskänslig serving. AWQ behöver ett mindre kalibreringsset och överanpassar mindre till det. Om du servar enanvändarbegäranden med låg latens, börja med AWQ.

Vad betyder Q4_K_M?

Q4_K_M är en k-quant-kvantiseringsnivå i GGUF. "Q4" betyder nominellt 4-bitars djup, "K" markerar k-quant-blockschemat (mot legacy Q4_0) och "M" betyder medium: attention- och feed-forward-tensorer får extra bitar. Effektivt antal bitar per vikt är ungefär 4,8, inte 4,0, eftersom blockskalor och min-värden lägger till overhead och medium-mixen spenderar mer ovanpå.

Kan jag köra en kvantiserad modell på en CPU?

Ja, men bara via GGUF. GPTQ och AWQ är rena GPU-format. GGUF:s k-quant-modeller kör på CPU genom llama.cpp eller Ollama och stöder lager-offloading mellan GPU-VRAM och system-RAM. Q4_K_M är standard-quanten för CPU. Räkna med långsammare tokengenerering än på GPU, men funktionell inferens.

Vad är skillnaden mellan GGUF och GGML?

GGML är det äldre tensorbiblioteket och filformatet som llama.cpp ursprungligen använde. GGUF ersatte det i augusti 2023 som ett flexiblare behållarformat med bättre metastöd. GGUF-filer är det du laddar ner från HuggingFace idag. GGML-filer är legacy och distribueras knappt längre.

Ska jag kvantisera en modell själv eller ladda ner en färdigkvantiserad?

Ladda ner en färdigkvantiserad först. Communityna kring llama.cpp och HuggingFace har redan kvantiserat de flesta populära modeller på varje nivå. Att kvantisera själv är bara meningsfullt om du behöver ett specifikt kalibreringsset för din domän, eller om det inte finns någon färdigkvantiserad version av din modell.

När ska jag använda kvantisering i stället för en mindre modell?

Använd kvantisering när du behöver den större modellens förmåga men inte får plats med den i minnet. En kvantiserad 70B-modell slår i regel en okvantiserad 13B-modell på komplexa resonemangsuppgifter. Använd en mindre modell i stället när latens är begränsningen, eftersom mindre modeller genererar tokens snabbare oavsett kvantisering.

Vad är skillnaden mellan kvantisering och distillering?

Kvantisering minskar den numeriska precisionen i en befintlig modells vikter. Distillering tränar en mindre modell att imitera en större, vilket ger en genuint annorlunda (mindre) arkitektur. Kvantisering bevarar originalmodellens arkitektur och är i princip reversibel. Distillering skapar en ny modell och kräver en träningskörning.

Den korta versionen: kvantisering är hur du får in modellen du vill ha i hårdvaran du har. För de flesta på konsument-GPU:er eller Apple Silicon är en färdigkvantiserad Q4_K_M-GGUF från HuggingFace hela lösningen. GPTQ och AWQ är svaren för GPU-serving. FP8 och SmoothQuant är svaren för produktionsserving med hög genomströmning. Allt annat är optimering efter att du har bekräftat att modellen fungerar.

Om du bestämmer vad du ska självhosta och vill ha en second opinion om hårdvara-metod-kombinationen, pratar vi gärna.