GGUF-formaat: een complete gids voor lokale LLM-inferentie

Wat is GGUF?

GGUF, kort voor GGML Unified Format, is een binair bestandsformaat dat modelgewichten, tokenizervoorraad, architectuurmetadata en kwantisatie-informatie verpakt in één draagbaar bestand voor inferentie met GGML-gebaseerde runtimes, met name llama.cpp.

GGUF lost een LLM-uitrolprobleem op. Veel modelformaten vereisen dat gebruikers meerdere bestanden bij elkaar houden, waaronder modelgewichten, tokenizerbestanden, configuratiebestanden en architectuurspecifieke laadcode. GGUF vereenvoudigt dit door het modelfile grotendeels zelfbeschrijvend te maken.

Een GGUF-bestand bevat doorgaans:

• Modeltensors
• Gekwantiseerde of niet-gekwantiseerde gewichten
• Tokenizerwoordenlijst
• Tokenizerconfiguratie
• Metadata over modelarchitectuur
• Context-lengte-instellingen
• Embedding-dimensies
• Aantal attention-heads
• RoPE-configuratie
• Tensornamen, -vormen en datatypen

Het kernidee is dat het bestand zichzelf beschrijft. De runtime kan de metadata uitlezen, de architectuur begrijpen, de tokenizer laden en de tensors mappen zonder te vertrouwen op een aparte config.json of tokenizer-map.

Dit betekent niet dat elk GGUF-bestand universeel en voor altijd compatibel is met elke runtime. De runtime moet nog steeds de modelarchitectuur en tensortypen ondersteunen die in het bestand worden gebruikt. Maar GGUF maakt die compatibiliteit veel eenvoudiger dan oudere formaten, omdat het bestand veel meer gestructureerde informatie bevat.

Vier bepalende kenmerken van GGUF zijn:

1. Uitrol met één bestand
2. Ondersteuning voor memory mapping voor efficiënt laden
3. Uitbreidbare getypeerde key-value-metadata
4. Ondersteuning voor veel kwantisatietypen, van agressieve low-bitformaten tot volledige precisie

GGUF werd in 2023 geïntroduceerd als onderdeel van het llama.cpp- en GGML-ecosysteem. Het is nu het dominante formaat voor het distribueren van gekwantiseerde lokale LLM’s op Hugging Face.

GGUF vs. GGML

Het GGML (Georgi Gerganov Machine Learning)-formaat was de voorganger van GGUF. Het was belangrijk omdat het hielp om vroege lokale inferentie mogelijk te maken. Maar het had praktische beperkingen toen het ecosysteem verder groeide dan de oorspronkelijke LLaMA-modellen.

Veelvoorkomende pijnpunten van GGML waren onder andere:

• Minder flexibele afhandeling van metadata
• Meer architectuurspecifieke aannames bij het laden
• Tokenizer- en configuratieafhandeling die minder self-contained was
• Moeilijker uit te breiden naarmate nieuwe modelfamilies verschenen

GGUF pakte die beperkingen aan met een gestructureerder formaat. Het introduceerde getypeerde metadata, betere tokenizer-embeddings en een duidelijkere bestandsindeling. Dit maakte het voor llama.cpp en aanverwante tools eenvoudiger om meer architecturen te ondersteunen zonder de laadpijplijn voortdurend te moeten herontwerpen.

Voor gebruikers is het belangrijke verschil simpel: GGUF is het moderne formaat. Als je vandaag modellen downloadt, moet je bijna altijd GGUF kiezen in plaats van oudere GGML-bestanden.

GGUF vs. GPTQ en AWQ

In je onderzoek naar de bestandsformaten ben je vast GGUF, GPTQ (Generative Post-Training Quantization) en AWQ (Activation-Aware Weight Quantization) tegengekomen. Ik zie ze vaak samen besproken worden omdat alle drie worden gebruikt om LLM-inferentie efficiënter te maken. Toch zijn het geen identieke categorieën.

GGUF is primair een bestandsformaat en uitrolcontainer. Het ondersteunt veel kwantisatietypen en wordt nauw geassocieerd met lokale inferentie in de stijl van llama.cpp.

GPTQ en AWQ zijn kwantisatiemethoden en ecosystemen die vaak worden gebruikt voor GPU-geoptimaliseerde inferentie, vooral op NVIDIA-hardware via frameworks zoals Transformers, ExLlama, AutoGPTQ en vLLM-werkstromen.

Als je doel maximale compatibiliteit is op laptops, desktops, Apple Silicon en gemengde hardware, is GGUF meestal de veiligere keuze.

Als je doel maximale throughput is op dedicated NVIDIA-inferentieservers, kunnen GPTQ, AWQ, FP8 of andere GPU-geoptimaliseerde servingformaten geschikter zijn.

Waarom GGUF gebruiken?

GGUF werd populair omdat het praktische uitrolproblemen oplost. Ik merk ook dat het enorm handig is bij lokale uitrol zonder alle opzetrompslomp.

Lokale LLM’s draaien betekende vroeger gefragmenteerde tooling, grote ongecomprimeerde gewichten, incompatibele modelformaten en ingewikkelde set-upstappen. GGUF kan nu een groot deel van die workflow standaardiseren.

In plaats van te denken aan veel losse bestanden en laadscripts, kunnen gebruikers zich focussen op het selecteren van het juiste model, een kwantisatieniveau kiezen en inferentie draaien.

Modellen lokaal draaien

Met GGUF kun je LLM’s op je eigen machine draaien. Dit betekent:

• Geen kosten per token via een API
• Geen afhankelijkheid van een gehoste inferentieprovider
• Geen prompts naar een externe API sturen
• Offline inferentie is mogelijk nadat het model is gedownload

Dit is vooral nuttig voor privacygevoelige workflows. Ontwikkelaars willen mogelijk geen eigendomsrechtelijke code, interne documenten, klantgegevens of vertrouwelijke prompts naar een externe API sturen.

Lokale inferentie is niet automatisch veilig op zichzelf. Je moet je machine, logs, applicaties en toegangsbeheer nog steeds goed regelen. Maar GGUF maakt private, lokale uitrol veel toegankelijker.

Voor hands-on oefenen met lokaal modellen draaien, bekijk onze tutorials over Mistral Medium 3.5 serven met SGLang, DeepSeek V4 Flash lokaal draaien, het efficiënte Bonsai 1-bit-model op een oude laptop draaien, en MiniMax M2 lokaal draaien als code-assistent.

Hardwareflexibiliteit

GGUF is nuttig omdat het werkt op veel verschillende hardwareconfiguraties.

Afhankelijk van de runtime en backend kunnen GGUF-modellen draaien op:

• Alleen-CPU-machines
• NVIDIA-GPU’s via CUDA
• Apple Silicon via Metal
• AMD-GPU’s via HIP of Vulkan
• Intel-GPU’s via SYCL of Vulkan
• Sommige ARM- en mobiele omgevingen

Die flexibiliteit is een belangrijke reden waarom llama.cpp invloedrijk werd. Het is niet alleen ontworpen voor high-end server-GPU’s. Het is ontworpen om lokale inferentie mogelijk te maken op een brede reeks hardware.

Een Mac-gebruiker kan bijvoorbeeld vertrouwen op Metal-versnelling, terwijl een Linux-desktopgebruiker CUDA of Vulkan gebruikt. Een gebruiker met alleen CPU kan nog steeds kleinere gekwantiseerde modellen draaien, al zal de generatie trager zijn.

Brede ecosysteemondersteuning

GGUF wordt ondersteund door veel tools voor lokale inferentie. Voorbeelden zijn:

• llama.cpp voor command-line en server-inferentie
• Ollama voor CLI-first modelbeheer en API-toegang
• LM Studio voor een desktop-GUI
• GPT4All voor privacygerichte lokale chat
• KoboldCpp voor lokale roleplay- en tekstgeneratieworkflows
• Jan en Open WebUI voor lokale AI-interfaces

Dit is belangrijk omdat gebruikers niet vastzitten aan één interface. Hetzelfde algemene modelformaat kan in verschillende workflows worden gebruikt.

Een ontwikkelaar kan een model benchmarken met llama.cpp, ermee chatten in LM Studio, het serven via Ollama en het koppelen aan een browser-UI via Open WebUI.

Hugging Face-distributie

Hugging Face is uitgegroeid tot een belangrijk distributiepunt voor GGUF-modellen.

Bron: Hugging Face

Veel populaire open-weight-modellen krijgen kort na release door de community geüploade GGUF-varianten. Deze repositories bevatten vaak meerdere kwantisatie-opties zodat gebruikers een model kunnen kiezen dat bij hun hardware past.

Veelvoorkomende uploadvarianten zijn onder meer:

• Q4_K_M
• Q5_K_M
• Q6_K
• Q8_0
• IQ4_XS
• IQ3_M
• IQ2_XXS

Dit betekent dat handmatige conversie vaak niet nodig is. Voor de populairste modellen heeft iemand in de community al GGUF-bestanden gemaakt voor gangbare kwantisatieniveaus.

Granulaire controle over grootte en kwaliteit

GGUF geeft gebruikers fijnmazige controle over de afweging tussen grootte en kwaliteit. Je kunt kiezen voor:

• Kleinere kwantisaties voor machines met weinig geheugen
• Middenklasse kwantisaties voor gebalanceerd dagelijks gebruik
• Kwantisaties met meer bits voor coderen, redeneren of gestructureerde output
• Volledige of bijna volledige precisie wanneer geheugen geen beperking is

Deze flexibiliteit is een van de grootste voordelen van het formaat. In plaats van één vaste uitroltarget laat GGUF gebruikers dezelfde modelfamilie aanpassen aan veel hardwaretiers.

Hoe werkt GGUF?

Een GGUF-bestand is georganiseerd in drie hoofdonderdelen:

1. Header
2. Metadata en tensorinformatie
3. Tensordata

De exacte structuur is gedefinieerd door de GGUF-specificatie. Het belangrijkste idee is dat metadata en tensorinformatie vóór de ruwe tensordata verschijnen, zodat een runtime kan begrijpen wat er geladen gaat worden.

De header

De header identificeert het bestand als GGUF en vertelt de runtime hoe de rest van het bestand te parsen. Het bevat:

• Magic number voor GGUF
• Formaatversie
• Aantal tensors
• Aantal metadata key-value-paren

Moderne GGUF-bestanden gebruiken vaak GGUF-versie 3.

Inferentie-engines controleren eerst het magic number. Als het bestand niet begint met de verwachte GGUF-identifier, kan de runtime het afwijzen voordat er wordt geprobeerd tensors te parsen of geheugen toe te wijzen.

Dit is een simpele maar belangrijke stap voor veiligheid en betrouwbaarheid. Het voorkomt dat een runtime per ongeluk een niet-verwant binair bestand als model behandelt.

Metadata key-value-paren

GGUF-metadata is een getypeerde key-value-store. Deze metadata kan het volgende beschrijven:

• Algemene modelinformatie
• Architectuurfamilie
• Contextlengte
• Embedding-grootte
• Aantal lagen
• Aantal attention-heads
• RoPE-parameters
• Tokenizerwoordenlijst
• Speciale tokens
• Kwantisatie-informatie

Keys zijn meestal van een namespace voorzien. Voorbeelden zijn:

• general.architecture
• general.alignment
• llama.context_length
• tokenizer.ggml.tokens

Namespacing is belangrijk omdat het GGUF in staat stelt veel architecturen te ondersteunen zonder het hele bestandsformaat te wijzigen. Een model uit de LLaMA-familie kan llama.*-keys gebruiken, terwijl andere modelfamilies hun eigen architectuurspecifieke metadata kunnen gebruiken.

Dit is een van de redenen waarom GGUF zich goed aanpaste aan modellen buiten de oorspronkelijke LLaMA-familie, zoals architecturen als Qwen, Mistral, Gemma, DeepSeek, Phi en anderen.

Tensorinformatie en tensordata

Na de metadata slaat het bestand tensorinformatie en tensordata op.

Tensorinformatie beschrijft:

• Tensornaam
• Vorm
• Datatype
• Offset naar de tensordata-sectie

De tensordata-sectie bevat de daadwerkelijke modelgewichten. Deze gewichten kunnen worden opgeslagen in volledige precisie of in een van de door GGUF ondersteunde gekwantiseerde tensortypen.

GGUF gebruikt een uitlijningswaarde die in metadata is gedefinieerd, vaak general.alignment. Veel GGUF-bestanden gebruiken 32-byte alignment, maar de juiste manier om dit te beschrijven is dat alignment door metadata wordt bepaald in plaats van permanent hard gecodeerd.

Uitlijning is belangrijk omdat het runtimes in staat stelt tensorblokken efficiënt te benaderen.

Memory mapping

Een van de praktische voordelen van GGUF is memory mapping, vaak mmap genoemd.

Met memory mapping kan het besturingssysteem het modelfile in het virtuele geheugen mappen in plaats van de runtime te dwingen het hele bestand vooraf in RAM te kopiëren.

Dit kan het opstarten van het model veel sneller laten aanvoelen, vooral op SSD’s. Het stelt het besturingssysteem ook in staat om modeldata in en uit te pagineren wanneer nodig.

Maar memory mapping is geen magie. Het model heeft nog steeds voldoende praktische geheugenbandbreedte en beschikbare RAM of VRAM nodig om goed te draaien. Als je systeem constant vanaf disk moet pagineren, kan inferentie traag worden.

Een betere manier om over mmap te denken is:

• Het verbetert laadefficiëntie
• Het vermindert onnodige kopieën
• Het laat het OS het pagineren beheren
• Het elimineert niet de geheugenvereisten van inferentie

GGUF-kwantisatietypen begrijpen

Kwantisatie comprimeert modelgewichten naar representaties met lagere precisie.

In plaats van elk gewicht als een 16-bits floating-pointwaarde op te slaan, slaat een gekwantiseerd model benaderde waarden op met minder bits. Dit verkleint de bestandsgrootte, het RAM- en VRAM-gebruik en de druk op de geheugenbandbreedte.

Het belangrijkste inzicht is dat veel neurale netwerkgewichten tijdens inferentie geen volledige floating-pointprecisie nodig hebben. Een zorgvuldig gekwantiseerd model kan veel van het oorspronkelijke gedrag behouden en toch drastisch kleiner worden.

Naamgeving van GGUF-kwantisatie

GGUF-kwantisatienamen volgen meestal dit patroon:

• Q betekent gekwantiseerd
• Het getal suggereert het geschatte aantal bits per gewicht
• K verwijst naar de k-quant-familie
• S, M en L betekenen meestal small, medium en large varianten

Voorbeelden zijn:

• Q4_K_M
• Q5_K_M
• Q6_K
• Q8_0

De naam is een nuttige leidraad, maar is niet altijd een exacte weergave van de totale bestandsgrootte. De werkelijke grootte hangt af van tensormix, architectuur, metadata, tokenizeromvang en of sommige tensors op hogere precisie blijven.

Veelvoorkomende GGUF-kwantisatietypen

Deze getallen zijn schattingen voor 7B-klasse dichte modellen. Nieuwere architecturen, mixture-of-experts-modellen, grotere tokenizers en andere tensorindelingen kunnen de werkelijke bestandsgrootte veranderen.

In de praktijk werd Q4_K_M een populaire standaard omdat het een sterke balans biedt tussen grootte en kwaliteit. Veel gebruikers vinden het goed genoeg voor algemene chat, samenvatten, herschrijven en verkennend lokaal AI-werk.

Q5_K_M en Q6_K zijn vaak betere keuzes voor zwaardere workloads, zoals coderen of meerstaps instructie-opvolging

De reden is simpel: deze taken zijn gevoeliger voor kleine kwaliteitsdegradatie.

K-quants vs. I-quants

K-quants zijn de veelgebruikte kwantisatiefamilie achter formaten zoals Q4_K_M, Q5_K_M en Q6_K.

Ze gebruiken gegroepeerde kwantisatieschema’s met schaalinformatie die helpt om modelgedrag te behouden terwijl de geheugeneisen dalen. Ze zijn populair omdat ze betrouwbaar zijn, breed ondersteund en gemakkelijk te vinden in community-GGUF-releases.

I-quants, vaak geschreven als IQ-formaten, zijn nieuwere kwantisatietypen zoals:

• IQ4_XS
• IQ3_M
• IQ2_XXS
• IQ1_S

I-quants zijn ontworpen om betere kwaliteit te bereiken bij zeer kleine groottes. Ze kunnen technieken gebruiken zoals importance-aware kwantisatie en niet-lineaire kwantisatie-codeboeken. Sommige werkstromen gebruiken een importance-matrix, vaak imatrix genoemd, om belangrijkere gewichten beter te behouden tijdens kwantisatie.

De keerzijde is complexiteit. I-quants kunnen uitstekende resultaten leveren qua verhouding tussen grootte en kwaliteit, vooral bij zeer lage bitrates, maar ze vereisen mogelijk zorgvuldiger kwantisatieworkflows en runtime-ondersteuning.

Voor de meeste beginners blijven K-quants het eenvoudigste startpunt.

Een kwantisatieniveau kiezen voor jouw hardware

De volgende tabel geeft praktische startpunten. Beschouw dit als vuistregels, geen strikte garanties. Contextlengte, overhead van het besturingssysteem, GPU-offloading, KV-cachegrootte en de specifieke modelarchitectuur kunnen allemaal de geheugenvereisten veranderen.

Algemene vuistregels:

• Gebruik Q4_K_M als veilige standaard voor de meeste lokale inferentie.
• Gebruik Q5_K_M wanneer kwaliteit zwaarder weegt dan elke gigabyte besparen.
• Gebruik Q6_K of Q8_0 wanneer geheugen beschikbaar is en je meer getrouwheid wilt.
• Vermijd Q2_K voor serieuze werkzaamheden, tenzij je extreme geheugenkrapte test.
• Laat extra geheugen vrij voor de KV-cache, vooral bij lange contextvensters.

De KV-cache wordt makkelijk over het hoofd gezien. Een model kan in RAM passen bij een korte contextlengte maar vastlopen of vertragen bij een veel langere context, omdat de cache meegroeit met de sequentielengte.

Het GGUF-ecosysteem

De adoptie van GGUF wordt net zozeer gedreven door tooling als door het formaat zelf.

Een formaat wordt pas nuttig wanneer gebruikers eenvoudig modellen kunnen downloaden, draaien, inspecteren, converteren en serven. GGUF profiteert van een sterk ecosysteem met command-line tools, desktop-apps, API’s en gehoste modelrepositories.

1. llama.cpp

llama.cpp is de oorspronkelijke en belangrijkste GGUF-runtime. Het is een lichtgewicht C/C++-inferentie-engine, gemaakt door Georgi Gerganov en onderhouden door de GGML-community. Het hoofddoel is efficiënte LLM-inferentie met minimale set-up op veel hardwareplatforms.

Moderne llama.cpp ondersteunt veel backends, waaronder:

• CPU
• CUDA voor NVIDIA-GPU’s
• Metal voor Apple-apparaten
• Vulkan
• HIP voor AMD-GPU’s via ROCm
• SYCL voor Intel-GPU’s
• OpenCL in geselecteerde omgevingen
• Andere gespecialiseerde backends zoals CANN, OpenVINO en WebGPU, afhankelijk van platformondersteuning

Het bevat ook tools voor conversie, kwantisatie, serving, benchmarking en command-line-inferentie. Veelgebruikte tools zijn:

• convert_hf_to_gguf.py
• llama-quantize
• llama-cli
• llama-server
• llama-bench

De commando’s om een basis CPU-CMake-build te maken zijn:

cmake -B build
cmake --build build --config Release

Voor sommige configuraties moeten bepaalde flags aan het eerste van die twee commando’s worden toegevoegd:

• Apple Metal uitschakelen op macOS (standaard ingeschakeld): -DGGML_METAL=OFF
• Vulkan-build: -DGGML_VULKAN=1
• CUDA-build voor NVIDIA-GPU’s: -DGGML_CUDA=ON

Let erop dat de huidige builds GGML_*-CMake-opties gebruiken, zoals GGML_CUDA, GGML_VULKAN en GGML_HIP.

2. Ollama

Ollama is een van de gemakkelijkste manieren om lokale modellen te draaien. Het biedt:

• Een eenvoudige CLI
• Model pulling en beheer
• Een lokale REST-API
• Officiële Python- en JavaScript-bibliotheken
• Integratie met veel lokale AI-frontends

Ollama slaat modellen voor je op en beheert ze, waardoor de gebruiker meestal niet direct met .gguf-bestanden werkt. Toch is Ollama gebouwd rond llama.cpp-compatibele lokale inferentie en kan het ook GGUF-bestanden importeren via een Modelfile-workflow.

Ollama stelt een lokale API beschikbaar op:

http://localhost:11434/api

Twee vaak gebruikte endpoints zijn:

• /api/generate voor promptcompletion
• /api/chat voor chatachtige berichten

Voor beginners is Ollama vaak de snelste weg van nul naar lokale inferentie.

3. LM Studio

Bron: LM Studio

LM Studio is een desktopapplicatie om lokale modellen te ontdekken, te downloaden en mee te chatten. Het is handig voor gebruikers die een grafische interface verkiezen boven command-line-tools.

4. GPT4All

Bron: GPT4All

GPT4All is een andere cross-platform lokale AI-applicatie, gericht op private, lokale chatbot-workflows. Het ondersteunt GGUF-modellen en biedt een beginnersvriendelijke omgeving voor lokale inferentie.

Dankzij deze tools is GGUF toegankelijk voor niet-specialisten. Gebruikers hoeven CMake, tensorindelingen of kwantisatie-internals niet te begrijpen om een lokaal model uit te proberen.

Aan de slag met GGUF-modellen

Er zijn twee praktische manieren om te beginnen:

1. Gebruik Ollama voor de eenvoudigste ervaring.
2. Gebruik llama.cpp direct voor meer controle.

Een model draaien met Ollama

De eenvoudigste workflow is het model downloaden en een interactieve chatsessie starten:

ollama pull llama3.3
ollama run llama3.3

Het model aanroepen vanuit Python met de REST-API:

import requests

payload = {
    "model": "llama3.3",
    "prompt": "Give me three practical use cases for GGUF.",
    "stream": False
}

response = requests.post(
    "http://localhost:11434/api/generate",
    json=payload
)

print(response.json()["response"])

Voor chatachtige applicaties gebruik je /api/chat:

import requests

payload = {
    "model": "llama3.3",
    "messages": [
        {"role": "user", "content": "What is GGUF used for?"}
    ],
    "stream": False
}

response = requests.post(
    "http://localhost:11434/api/chat",
    json=payload
)

print(response.json()["message"]["content"])

Het veld stream: false is belangrijk voor eenvoudige scripts. Zonder dit retourneert Ollama een stream van JSON-objecten in plaats van één definitieve JSON-respons.

Je kunt ook de officiële Python-bibliotheek van Ollama gebruiken:

from ollama import chat

response = chat(
    model="llama3.3",
    messages=[
        {"role": "user", "content": "Explain GGUF quantization simply."}
    ]
)

print(response.message.content)

Een GGUF-bestand draaien met llama.cpp

Als je al een .gguf-bestand hebt, kun je het direct draaien met llama.cpp nadat je het project hebt gebouwd.

Voorbeeld:

./build/bin/llama-cli \
  -m models/model.Q4_K_M.gguf \
  -p "Explain the difference between GGUF and GPTQ." \
  -n 256

Als je GPU-ondersteuning hebt ingeschakeld, kun je lagen naar de GPU offloaden:

./build/bin/llama-cli \
  -m models/model.Q4_K_M.gguf \
  -p "Summarize GGUF in five bullet points." \
  -n 256 \
  -ngl 99

De vlag -ngl bepaalt het aantal lagen dat naar de GPU wordt offload. Een hoge waarde zoals 99 wordt vaak gebruikt om zoveel mogelijk te offloaden, ervan uitgaande dat het model in VRAM past.

Voor API-serving gebruik je llama-server:

./build/bin/llama-server \
  -m models/model.Q4_K_M.gguf \
  -ngl 99 \
  --host 127.0.0.1 \
  --port 8080

Dit geeft je een lokale serverinterface om llama.cpp in applicaties te integreren.

Een Hugging Face-model converteren naar GGUF

De meeste gebruikers hoeven modellen niet handmatig te converteren omdat community-GGUF-releases breed beschikbaar zijn.

Handmatige conversie is echter nuttig wanneer:

• Je je eigen model hebt fijn-afgesteld
• Er nog geen GGUF-versie bestaat
• Je het kwantisatieproces zelf wilt beheren
• Je een specifiek kwantisatietype nodig hebt

Een typische workflow is:

1. Download een Hugging Face-model.
2. Converteer het naar GGUF.
3. Kwantiseer het GGUF-bestand.

Voorbeeld:

huggingface-cli download mistralai/Mistral-7B-Instruct-v0.3 \
  --local-dir mistral-7b

Converteer daarna naar GGUF:

python convert_hf_to_gguf.py mistral-7b \
  --outfile mistral-f16.gguf \
  --outtype f16

Vervolgens kwantiseren:

./build/bin/llama-quantize \
  mistral-f16.gguf \
  mistral-q4_k_m.gguf \
  Q4_K_M

In de huidige llama.cpp-workflows zijn convert_hf_to_gguf.py en llama-quantize de relevante tools. Oudere tutorials kunnen verwijzen naar verouderde conversiescripts of oudere bestandsnamen.

Voordelen en beperkingen van het GGUF-formaat

GGUF is geoptimaliseerd voor praktische lokale inferentie. Het is geen universele vervanger voor elk modelformaat of serving-stack.

Voor CPU-first, Apple Silicon, mixed-hardware en privacygerichte inferentie is GGUF vaak een uitstekende keuze.

Voor NVIDIA-serverdeployment met hoge throughput kunnen andere formaten en engines sneller zijn, afhankelijk van het model, de batchgrootte, de kwantisatiemethode en het servingframework.

Slotgedachten

GGUF maakt lokale LLM-inferentie praktisch door alles wat een runtime nodig heeft (gewichten, tokenizer, metadata, kwantisatie-info) in één draagbaar bestand te verpakken. De echte kracht zit in het ecosysteem eromheen: llama.cpp, Ollama, LM Studio en Hugging Face hebben het tot de standaard gemaakt voor lokale AI-uitrol.

Voor de meeste gebruikers is het pad simpel: installeer Ollama, pull een model en draai het. Q4_K_M is een solide standaard; stap over op Q5_K_M of Q6_K wanneer je beter redeneren of betere code-output nodig hebt en het geheugen hebt om dat te ondersteunen.

Als je dieper wilt duiken in LLM-uitrol, modeloptimalisatie en lokale inferentieworkflows, bekijk dan het career track Associate AI Engineer for Data Scientists of Associate AI Engineer for Developers.