Open-Weight LLM-varianten, formaten en quantization

Viacheslav Dubrov

2025-05-11 · Bijgewerkt 2026-08-16 · 9 min · Modelengineering

Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Namen zoals Model-32B-A3B-Instruct-AWQ zien er compact uit omdat ze verschillende onafhankelijke keuzes combineren: family en size, architectuur, training role en quantization. Een repository kan die weights als geshardde Safetensors verpakken, terwijl een community-conversie van hetzelfde checkpoint verschijnt als Q4_K_M.gguf.

Die labels behoren niet tot dezelfde categorie: GPTQ en AWQ zijn quantization-methoden, GGUF is een container en runtime-ecosysteem, en MoE is een architectuur. Door de lagen afzonderlijk te lezen, wordt de keuze van een download eenvoudiger.

Wanneer je kiest tussen een Q4_K_M.gguf-download voor lokale inference en een AWQ Safetensors-repository voor GPU-serving, begin je met het checkpoint-gedrag en de architectuur die je taak vereist. Controleer daarna of de numerieke representatie, package-layout en target runtime passen bij de beschikbare hardware, memory en serving-constraints.

TL;DR. Selecteer een checkpoint op basis van task quality, licentie, taal, context en interface-gedrag. Selecteer daarna een runtime die de architectuur ondersteunt. Kies pas vervolgens een weight-representation en quantization die passen bij de gemeten memory en latency. GPTQ en AWQ zijn quantization-methoden, Safetensors en GGUF zijn containers, en MoE is een architectuur. Een MoE-label garandeert niet dat alle weights in het geheugen voor “active parameters” passen.

Bekijk voor de compacte deploymentkeuze LLM Quantization Formats.

Lees een model artifact in zes lagen

Training provenance annoteert deze lagen in plaats van een extra artifact-laag toe te voegen. Zo beschrijft distilled hoe gedrag is overgedragen, niet de role van het checkpoint. Een checkpoint kan tegelijk distilled, instruction-tuned, reasoning-tuned en MoE zijn.

Het label “open-source” vereist een aparte controle. Als een model alleen downloadbare weights publiceert, mag je niet aannemen dat de licentie aan een open-source-definitie voldoet of jouw use case toestaat. Lees de model card en licentie voordat je architectuur- of benchmarkvergelijkingen maakt.

Training-role-labels beschrijven gedrag, geen capability-garanties

Base

Een base-checkpoint is voornamelijk getraind voor next-token prediction. Het is bruikbaar voor continued pretraining, gecontroleerd onderzoek of adaptation wanneer je zelf het instruction-gedrag wilt bepalen. Het kan een prompt aanvullen in plaats van deze te beantwoorden.

Neem niet aan dat elke fine-tune vanaf base moet starten. Een instruct-checkpoint kan een betere initialization zijn wanneer het bestaande gedrag aansluit bij het doel. Controleer met je evaluation dat het bestaande gedrag het nieuwe objective niet tegenwerkt.

Instruct of chat

Deze checkpoints hebben post-training gekregen om instruction following en conversatie te verbeteren. De exacte recipe kan supervised fine-tuning, preference optimization, reinforcement learning, distillation of een combinatie daarvan bevatten. Het is niet noodzakelijk supervised fine-tuning gevolgd door RLHF.

Gebruik een instruct-checkpoint als eerste assistant-baseline. Controleer de chat template, het ondersteunde tool-call-format, het gedrag voor system messages en de refusal characteristics. “Instruct” alleen garandeert geen betrouwbare JSON of tool use.

Reasoning-tuned

Reasoning-georiënteerde checkpoints zijn geoptimaliseerd op taken of trajectories die multi-step problem solving belonen. Sommige tonen reasoning text, sommige scheiden die via een serving parser en sommige tonen alleen een antwoord. Langere generation garandeert geen faithful reasoning of minder hallucinations.

Gebruik er een wanneer het de moeilijke evaluation slices verbetert na correctie voor output tokens, latency en verification. Routine-extractie of classification kan trager worden zonder beter te worden.

Distilled

Distillation draagt gedrag van een teacher of door een teacher gegenereerde data over naar een ander model. De student kan kleiner, even groot of structureel anders zijn. Er bestaat geen stabiele regel zoals “70–80% quality bij half de size”: de behouden quality hangt af van de teacher, data, objective, student capacity en evaluation.

Behandel Distill als provenance over de training en benchmark het vervolgens zoals elk ander checkpoint.

Welk label moet elke selectiestap beïnvloeden? Deze map houdt training role, training provenance en architectuur gescheiden. De map rangschikt modeltypes niet.

De Transformers chat-template-documentatie legt uit waarom het exacte message-format van een instruction-tuned model belangrijk is. In het oorspronkelijke knowledge-distillation-paper dragen Hinton, Vinyals en Dean gedrag over naar een student zonder een vaste quality-ratio te claimen. Het Switch Transformer-paper beschrijft één ontwerp voor sparse expert-routing. Een specifieke MoE-family kan tokens anders routen; de model card blijft daarom leidend.

Architectuurlabels beschrijven execution

Dense models

De meeste parameters nemen deel aan de forward pass van elke token. Het aantal parameters is een ruwe indicatie van de weight storage. Runtime-memory omvat ook KV cache, activations of workspace, allocator-overhead en soms gedupliceerde of gesharde state.

Mixture of Experts

Een MoE-layer routeert elke token naar een subset van expert feed-forward-networks. Namen zoals A3B betekenen vaak dat ongeveer drie miljard parameters per token actief zijn, maar naming conventions zijn family-specifiek. Lees de model card voor total parameters, active parameters, het aantal experts en het routing-design.

Het aantal active parameters beschrijft routed compute, niet de plaatsing van weights. vLLM expert parallelism shardt expert-layers bijvoorbeeld over expert-parallel ranks en leidt de expert allocation per rank af uit het totale aantal experts. Andere runtimes kunnen weights anders plaatsen of offloaden. Een model met 30B total en 3B active past daarom niet automatisch zoals een dense 3B-model.

Runtime-support is eveneens architectuur-specifiek. Controleer de model implementation, expert-parallel- of tensor-parallel-support, quantization-kernels en maximale context voordat je downloadt.

Containers en quantization zijn verschillende lagen

Safetensors

Safetensors is een safe tensor serialization format dat vaak wordt gebruikt in Hugging Face-repositories. Een model kan meerdere .safetensors-shards bevatten, plus configuration-, tokenizer- en generation-files. Die tensors kunnen BF16/FP16 zijn of vooraf gequantized met een methode zoals GPTQ of AWQ.

De extensie alleen zegt niets over precision of runtime-compatibility. Inspecteer config.json, de quantization configuration, de model card, de tensor dtype en de runtime-documentatie.

GGUF

GGUF verpakt tensors en metadata voor het ggml/llama.cpp-ecosysteem. llama.cpp laadt GGUF en ondersteunt backends zoals Metal, CUDA, HIP, Vulkan en CPU-paths. Model architecture en conversion quality bepalen nog steeds de compatibility.

GGUF is een container. De container kan high-precision of gequantized tensors bevatten. Multimodale models hebben mogelijk ook een afzonderlijk projector- of encoder-file nodig. “Eén GGUF-file bevat alles” is geen universele regel.

GPTQ en AWQ

GPTQ en AWQ zijn post-training weight-quantization-methoden, geen file extensions. Hun artifacts gebruiken vaak Safetensors plus method-specific configuration. Serving engines hebben kernels nodig die compatibel zijn met de methode, bit width, group size, model architecture en hardware.

Geen van beide methoden is universeel de beste wat quality betreft. Calibration data, implementation, kernel path en task zijn van belang. Runtime-support verandert; verifieer daarom het exacte artifact tegen de versie die je vastlegt. Bekijk naast die keuze de officiële pagina’s voor Transformers quantization en vLLM quantization.

Hardware alleen kan de container niet bepalen. Kies eerst een runtime die de architectuur en serving-interface ondersteunt. Gebruik daarna de artifact-layout en quantization path die deze runtime documenteert.

Het llama.cpp-project vereist bijvoorbeeld GGUF en documenteert meerdere hardware-backends. De GGUF-specificatie definieert een container voor tensors en metadata. Transformers laadt quantization-methoden daarentegen via backend-specifieke configuration, zoals beschreven in de quantization workflow. Geen van deze bronnen belooft dat een overeenkomende extensie elke architectuur ondersteunt of op elk device goed draait.

Quantization-math is een ondergrens, geen capacity planning

Voor $P$ weight-parameters met $b$ bits is de raw weight storage ongeveer:

Een 13B-model met nominale four-bit weights begint dus rond 6,5 GB. Het draait niet noodzakelijk in 6,5 GB. Scales, zero points, tensors met hogere precision, embeddings, metadata, runtime-buffers, KV cache en fragmentation voegen memory toe.

Context en concurrency kunnen het verschil tussen “laadt” en “serveert” domineren. Meet de peak memory met de werkelijke maximale sequence, batch policy, cache dtype en parallelism.

Quantization kan memory reduceren en soms speed verbeteren, maar low-bit-kernels kunnen ook trager zijn op niet-ondersteunde hardware. Vergelijk task quality en end-to-end throughput, niet alleen de file size. Zie de llama.cpp quantization guide voor runtime-specifieke recipes.

Decodeer GGUF-quantizationnamen zorgvuldig

In llama.cpp benoemt Q4_K_M een quantization-recipe op file-niveau, niet één tensor-type dat overal wordt toegepast. De llama-quantize-options bieden Q4_K_M als selecteerbaar type en beschrijven --pure als het uitschakelen van K-quant-mixtures. De quantizer-implementation gebruikt Q4_K als default voor dit recipe en past andere types toe op bepaalde tensor-categorieën. Behandel het suffix als een llama.cpp-recipenaam, niet als een portable specificatie van bit width.

De huidige llama.cpp-quantizationdocumentatie laat ook zien dat recipes kunnen variëren per architectuur en tensorcategorie. Een importance matrix kan bepalen welke weights meer precision behouden.

Vermijd universele claims dat Q4_K_M niet van BF16 te onderscheiden is of dat een groter Q3-model altijd beter is dan een kleiner Q8-model. Gebruik een kleine ladder voor het exacte checkpoint:

1. high-precision of trusted reference-artifact
2. één kandidaat dicht bij de memorylimiet
3. één kleiner kandidaat met meer headroom

Voer op alle drie dezelfde prompts, structured-output-checks, long-context-cases en latency-tests uit.

Een selection workflow die nieuwe formaten doorstaat

1. Leg het task-contract vast

Definieer taal, modality, context length, tool- of schema-interface, safety constraints, license requirements en evaluation slices. Vergelijk checkpoints in een representatie die nauwkeurig genoeg is, zodat quantization de eerste ronde niet bepaalt.

2. Selecteer het checkpoint

Kies het kleinste checkpoint dat de niet-onderhandelbare quality- en behavior-gates haalt. Noteer de exacte repository en revision, tokenizer, chat template en eventueel vereiste reasoning parser.

3. Selecteer de runtime

Controleer architecture support, hardware-backend, parallelism, quantization-kernels, structured output, adapters en operational interface. Voor lokale GGUF-inference is llama.cpp de reference runtime. Vergelijk voor GPU-serving actuele versies van vLLM, TGI, Transformers of gespecialiseerde engines met het daadwerkelijke artifact.

4. Stel een gemeten memory budget vast

Neem weights, KV cache, runtime-workspace, verwachte concurrency en headroom voor het operating system of co-located processes op. Dat een file in RAM of VRAM past, is noodzakelijk maar niet voldoende.

5. Kies en valideer een representation

Geef de voorkeur aan artifacts van de publisher met gedocumenteerde calibration en provenance. Leg bij een community-conversie de source revision, converter revision, quantization recipe, calibration- of importance-data en hashes vast.

6. Benchmark de release unit

Meet task quality, schema/tool-call-correctheid, time to first token, output throughput, peak memory en failures bij de target context en concurrency. Herhaal dit na elke wijziging van checkpoint, runtime, kernel of quantization-setting.

Uitgewerkte naam

Stel dat een repository deze naam heeft:

Acme-32B-A3B-Instruct-AWQ

Lees dit als een reeks vragen:

• Acme: welke family, licentie en revision?
• 32B: total weights of een andere publisher-convention?
• A3B: hoe definieert deze family active parameters?
• Instruct: welke post-training-recipe en chat template?
• AWQ: welke bit width, group size, calibration en ondersteunde kernels?
• repository-files: Safetensors-shards, configs, tokenizer en custom code?
• target runtime: ondersteunt de vastgelegde versie deze exacte architectuur en quantization?

De naam is een index naar de documentatie, geen complete deployment-specificatie.

Conclusie

Modelselectie wordt minder verwarrend zodra labels niet langer dezelfde categorie delen. Training role vertelt welk gedrag is geoptimaliseerd. Architectuur vertelt hoe computation is georganiseerd. Quantization vertelt hoe bepaalde tensors zijn benaderd, containers hoe artifacts zijn opgeslagen en runtimes wat efficiënt op je hardware wordt uitgevoerd.

Kies in die volgorde, bewaar exacte provenance en laat één task evaluation de release-artifacts vergelijken. Een vertrouwd suffix bewijst niet dat het model past, snel draait of het benodigde gedrag behoudt.

Referenties

• Transformers chat templates - Message-formatting voor base en instruction-tuned causal language models.
• Distilling the Knowledge in a Neural Network - Het oorspronkelijke distillation-paper van Hinton, Vinyals en Dean.
• Switch Transformers - De sparse expert-routing-architectuur van Fedus, Zoph en Shazeer.
• GGUF specification en llama.cpp quantization guide
• Hugging Face Transformers quantization concepts
• GPTQ paper
• AWQ paper
• vLLM quantization documentation