2025-05-11 · Bijgewerkt 2026-07-15

[!NOTE] Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Open-Weight LLM Varianten, Quantization, en formaten: instructies geven, MoE, GGUF, GPTQ, en AWQ

Naamwoorden zoals Model-32B-A3B-Instruct-AWQ Het ziet er complex uit omdat ze meerdere onafhankelijke beslissingen met elkaar combineren: familie en grootte, architectuur, trainingsrol, en quantization. Een repository kan deze weights verpakken als gesplitste Safetensors, terwijl een door de gemeenschap gemaakte conversie van dezelfde checkpoint er als volgt uitziet Q4_K_M.gguf.

Die labels vallen niet onder dezelfde categorie: GPTQ en AWQ zijn quantization methoden, GGUF is een container en runtime een ecosysteem, terwijl MoE een architectuur betreft. Door de verschillende lagen apart te bekijken, wordt de keuze bij het downloaden aanzienlijk eenvoudiger.

Kort samengevat. Kies een checkpoint op basis van taakkwaliteit, licentie, taal, context en interfacegedrag. Vervolgens kies je een runtime die zijn architectuur ondersteunt. Pas daarna kun je een weight representatie en een quantization kiezen die passen bij de gemeten geheugencapaciteit en latency. GPTQ en AWQ zijn quantization methoden, Safetensors en GGUF zijn containers, terwijl MoE een architectuur is – geen garantie dat alle weights in het ‘actieve parameter’-geheugen passen.

Lees een model-artefact in zes lagen

Deze lagen zijn niet onderling exclusief. Een checkpoint kan tegelijkertijd worden gezuiverd, op instructies worden afgestemd, reasoning-gericht worden aangepast en MoE worden toegepast.

“Open-source” vereist eveneens zorgvuldige behandeling. Veel te downloaden models zijn open-weight onder licenties die niet voldoen aan de definitie van open source of waarbij gebruikbeperkingen gelden. Lees altijd het model-kaartje en de licentie voordat u architectuurontwerpen of benchmark-vergelijkingen uitvoert.

Labels voor trainingrollen beschrijven gedrag, niet garanties met betrekking tot capaciteiten

Basis

Een basis checkpoint wordt voornamelijk getraind voor de voorspelling van het volgende token. Hij is nuttig voor voortgezette pretraining, gecontroleerd onderzoek, of voor aanpassingen wanneer je het gedrag van de instructie zelf wilt bepalen. In plaats van erop te antwoorden, kan hij een prompt voltooien.

Veronderstel niet dat elke fine-tuning altijd moet beginnen bij de base-versie. Een instructie checkpoint vormt vaak een betere initiële instelling wanneer het huidige gedrag al overeenkomt met de gewenste resultaten en uw evaluatie bevestigt dat dit geen negatieve invloed heeft op het nieuwe doel.

Instructeren of chatten

Deze checkpoints ontvangen post-training met als doel de instructieopvolging en conversatie te verbeteren. Het exacte recept kan bestaan uit gecontroleerde fine-tuning, optimalisatie van voorkeuren, reinforcement learning, distillatie of combinaties daarvan—niet per se klassieke SFT gecombineerd met RLHF.

Gebruik een instructie checkpoint als uitgangspunt voor de eerste assistent. Bevestig diens chattemplate, ondersteunde toolcall-formaat, gedrag bij systeemberichten en kenmerken van weigeringen. Alleen het geven van instructies garandeert geen betrouwbare JSON of tool use.

Reasoning-getuned

Reasoning-gerichte checkpoints zijn geoptimaliseerd voor taken of trajecten waarbij meervoudige stappen nodig zijn om een probleem op te lossen. Sommige genereren reasoning-tekst direct, andere scheiden deze via een serving-parser, en weer andere leveren uitsluitend een antwoord op. Een langere generatie garandeert geen nauwkeuriger reasoning-resultaat of minder hallucinations.

Neem er één aan wanneer dit de kritieke delen verbetert die van belang zijn na verwerking van de uitvoer tokens, latency en de validatie. Regelmatige extractie of classificatie kan trager worden zonder dat de kwaliteit daardoor toeneemt.

Geconcentreerd

Distillatie overdraagt het gedrag van een ‘teacher’ of van door deze gegenereerde gegevens naar een andere model. De ‘student’ kan kleiner zijn, even groot, of structureel verschillend. Er bestaat geen vaste regel als ‘70–80% kwaliteit bij de helft van de omvang’: de behouden kwaliteit hangt af van de ‘teacher’, de gegevens, het doel, de capaciteit van de ‘student’ en de evaluatie.

behandelen Distill Als broninformatie met betrekking tot de training kan benchmark worden behandeld zoals elke andere checkpoint.

Architectuurnummers geven de uitvoering weer

Dichte models

De meeste parameters nemen deel aan de forward pass van elke token. Het aantal parameters is een ruwe indicatie voor de opslagruimte die nodig is voor weight, maar het runtime geheugen omvat tevens KV cache, activations of het werkgebied, de overhead van de allocator, en soms gecopieerde of gesplitste toestanden.

Mengeling van experts

Een MoE-laag leidt elke token naar een deelverzameling van expert feed-forward netwerken. Naamwoorden als A3B Meestal zijn er ongeveer drie miljard actieve parameters per token, maar de benoemingsconventies verschillen per familie. Lees de kaart met model voor informatie over het totale aantal parameters, de actieve parameters, het aantal experts en de routing-ontwerpprincipes.

Actieve parameters beschrijven voornamelijk de rekenwerkzaamheden. Tenzij runtime experts aflevert, hebben alle experts weights nog steeds opslag nodig, meestal geheugen op de apparaten binnen de serving-topologie. Een model met een totaal van 30 miljard parameters en 3 miljard actieve parameters past niet automatisch als een dichte model.

De ondersteuning voor Runtime is eveneens afhankelijk van de architectuur. Controleer de implementatie van model, of er sprake is van expert-parallelle of tensor-parallelle ondersteuning, quantization kernels, en de maximale contextgrootte voordat u iets downloadt.

Containers en quantization vormen verschillende lagen

Safetensors

Safetensors is een veilige serialisatievorm voor tensors die veel wordt gebruikt in Hugging Face-repositories. Een model kan meerdere hebben .safetensors Shards, samen met de configuratie, tokenizer en de generatiebestanden. Deze tensors kunnen BF16/FP16 worden of vooraf gekwantiseerd met methoden zoals GPTQ of AWQ.

Alleen de extensie geeft geen informatie over de nauwkeurigheid of de compatibiliteit met runtime. Controleer dit. config.json, quantization-configuratie, model-kaart, tensor-dtype en runtime-documentatie.

GGUF

GGUF Pakketten die tensors en metadata bevatten voor het ggml/llama.cpp-ecosysteem. llama.cpp Het vereist GGUF en ondersteunt backends, inclusief Metal, CUDA, HIP, Vulkan en CPU-paden. De Model-architectuur en de kwaliteit van de conversie bepalen nog steeds de compatibiliteit.

GGUF is een container. Het kan hoge-precisietensors of gecomprimeerde tensors bevatten. Multimodale models-data hebben mogelijk ook een aparte projector- of encoderbestand nodig; de regel dat “één GGUF-bestand alles bevat” geldt niet voor alle gevallen.

GPTQ en AWQ

GPTQ en AWQ zijn post-training weight-quantization-methoden, en geen bestandsextensies. Hun outputbestanden maken meestal gebruik van Safetensors gecombineerd met configuratieparameters die specifiek zijn voor de desbetreffende methode. Serving-engines hebben nood aan kernels die compatibel is met de methode, de bitbreedte, de groepsgrootte, de model-architectuur en de benodigde hardware.

Geen van beide methoden levert automatisch de beste kwaliteit op. Calibration data, de implementatie, het kernel pad en de specifieke taak spelen een belangrijke rol. Current Transformers, TGI en vLLM ondersteunen verschillende quantization backends configuraties, maar hun matrices kunnen veranderen; controleer daarom altijd de vastgelegde runtime waarden in plaats van te vertrouwen op statische tabellen uit blogs.

Quantization De wiskundige waarde vormt een ondergrens, geen maximale capaciteit planning

Voor (P) weight parameters met (b) bits is de ruwe weight opslag ongeveer:

[ \text{weight bytes} \approx \frac{P \times b}{8} ]

Een 13B model met een nominale vierbitige weights begint dus rond de 6,5 GB. Het zal niet per se binnen die 6,5 GB draaien. Schalen, nulpunten, tensors met hogere precisie, embeddings, metadata, runtime buffers, KV cache en fragmentatie zorgen voor extra geheugenverbruik.

Context en gelijktijdigheid kunnen de verschillen tussen “loads” en “serves” bepalen. Meet het piekmemorygebruik aan de hand van de werkelijke maximale sequentie, batchbeleid, cache-dtypen en parallelisme.

Quantization kan de geheugengebruik verminderen en soms de snelheid verbeteren, maar een lage-bitversie van kernels kan op onondersteunde hardware ook trager presteren. Vergelijk de kwaliteit van de taak en de end-to-end throughput—niet alleen de bestandsgrootte.

Decode GGUF quantization kies de namen zorgvuldig

In Q4_K_M:

• Q4 Dit duidt op een vierbitige quantization-familie; niet iedere tensor heeft noodzakelijkerwijs precies vier bits. K identificeert het K-quant-schema. M Het identificeert een gemengde receptie die verschillende tensortypen gebruikt voor de geselecteerde weights. Dit betekent niet “middelgrote blokgrootte”.

De huidige llama.cpp De documentatie van quantization geeft aan dat recepten kunnen verschillen afhankelijk van de architectuur en de tensorcategorie. Een belangrijkheidsmatrix kan bovendien helpen bepalen welke weights meer precisie moeten behouden.

Vermeed algemene beweringen die Q4_K_M is niet te onderscheiden van BF16, of dat een groter Q3 model altijd beter presteert dan een kleiner Q8 model. Gebruik een kleine ladder voor de exacte checkpoint:

1. een referentiemodel met hoge precisie of betrouwbaarheid
2. één kandidaat die dicht bij het geheugenlimiet ligt
3. één kleinere kandidaat met meer beschikbare ruimte

Voer dezelfde prompts-, gestructureerde uitvoercontroles, gevallen met lange contexten en latency-tests uit op alle drie.

Een selectie workflow die overleeft bij nieuwe formaten

1. Corrigeer het taakcontract

Definieer de taal, modaliteit, contextlengte, tool- of schema-interface, veiligheidsbeperkingen, licentievereisten en evaluatiesneden. Vergelijk checkpoints in een representatie die voldoende nauwkeurig is om te voorkomen dat quantization de eerste ronde beslist.

2. Kies de checkpoint

Kies het kleinste checkpoint dat voldoet aan de onverhandelbare kwaliteits- en gedragsnormen. Noteer de exacte repository en revisie, tokenizer, de chattemplate, evenals eventuele vereiste reasoning parsers.

3. Kies de runtime

Controleer de ondersteuning van de architectuur, de hardware backend, paralleliteit, quantization kernels, structured output, adapters en de operationele interface. Voor lokale GGUF inference, llama.cpp De referentie is runtime. Voor GPU serving dient men de huidige vLLM, TGI, Transformers of gespecialiseerde engines te vergelijken met het daadwerkelijke artefact.

4. Stel een gemeten geheugenbudget in

Neem rekening met het weights-, KV cache- en runtime-werkruimte, de gewenste gelijktijdigheid en de beschikbare capaciteit voor het besturingssysteem of gelijktijdig uitgevoerde processen. Het is noodzakelijk dat een bestand past in het RAM-geheugen of in VRAM, maar dit is nog niet voldoende.

5. Kies en valideer een representatie

Geef de voorkeur aan door de uitgever verstrekte artefacten die voorzien zijn van gedocumenteerde calibration-informatie en duidelijke herkomstgegevens. Mocht u een conversie uit de gemeenschap gebruiken, noteer dan de bronversie, de versie van de converter, het quantization-recept, de calibration-gegevens of belangrijke metrics, evenals de hashes.

6. Benchmark de release-eenheid

Meet de kwaliteit van de taak, de correctheid van het schema en de toolcalls, de tijd tot het eerste token, de uitvoer throughput, het maximale geheugenverbruik, evenals eventuele fouten in de gewenste context en onder bepaalde parallelle omstandigheden. Voer opnieuw een meting uit nadat er wijzigingen zijn aangebracht in de instellingen voor checkpoint, runtime, kernel of quantization.

Gewerkte naam

Stel dat een repository de volgende naam heeft:

Acme-32B-A3B-Instruct-AWQ

Lees het als een reeks vragen:

• Acme: Welke familie, licentie en revisie? 32B: het totale aantal weights of een andere conventie van de uitgever? A3B:Hoe definieert deze familie de actieve parameters? Instruct: Welk post-training recept en chattemplate? AWQ: Welke bitbreedte, groepgrootte, calibration, en ondersteunde kernels?
• Repository-bestanden: Safetensors-shards, configuraties, tokenizer, en aangepaste code?
• Doel runtime: ondersteunt de vastgezette versie deze specifieke architectuur en quantization?

Deze naam is een index naar de documentatie, en geen volledige specificatie van deployment.

Conclusie

De Model selectie wordt minder verwarrend zodra de labels geen gemeenschappelijke categorie meer delen. De trainingsrol geeft aan welk gedrag is geoptimaliseerd. De architectuur laat zien hoe de berekeningen zijn georganiseerd. Quantization informeert over de manier waarop bepaalde tensors zijn benaderd. Containers maken duidelijk hoe artefacten worden opgeslagen. Runtimes bepalen wat efficiënt kan worden uitgevoerd op uw hardware.

Kies in die volgorde, behoud de exacte oorsprong, en laat één taakevaluatie de releasedelen met elkaar vergelijken. Het feit dat een bekend suffix wordt gebruikt, is geen bewijs dat model geschikt is, snel draait, of het gewenste gedrag behoudt.

Referenties

• GGUF specificatie en llama.cpp quantization handleiding
• Hugging Face Transformatoren quantization concepten
• GPTQ artikel
• AWQ artikel
• vLLM quantization documentatie