Unsloth als fine-tuning factory — waarom je lokale AI-stack een aparte trainingslaag nodig heeft

De meeste organisaties die lokaal AI-modellen gaan draaien, maken dezelfde fout: ze zoeken één tool die alles doet. Inference, training, chat-UI, modelbeheer : het liefst in één pakket. Unsloth lijkt dat te beloven. Een web UI waarmee je modellen zoekt, downloadt, draait, traint en exporteert. Het klinkt als de heilige graal.

Het is het niet.

Unsloth is een uitzonderlijk goede fine-tuning tool. Maar het is géén inference-platform, géén modelrouter, en géén governance-laag. En de AGPL-licentie op de Studio-UI maakt het een juridisch risico zodra je verder gaat dan intern experimenteren.

De kunst is om Unsloth precies daar in te zetten waar het uitblinkt. De rest laat je aan gespecialiseerde tools over.

Wat Unsloth wél is

Unsloth begon eind 2023 als een library die LoRA- en QLoRA-training 2x sneller maakte met tot 70% minder VRAM. Dat is het nog steeds. Maar inmiddels is het uitgegroeid tot een compleet platform met twee gezichten:

Unsloth Core (Apache 2.0) : de code-first library. Je schrijft Python, draait notebooks, hebt volledige controle over je training pipeline.

Unsloth Studio (AGPL-3.0) : de web UI. Zoek modellen, maak datasets van PDF/CSV/DOCX via "Data Recipes", train met een paar klikken, exporteer naar GGUF of safetensors.

De repository telt 65.500 stars, bijna 6.000 forks, en meer dan 5.400 commits. Er zitten 1.351 open issues en 230 open pull requests in . Teken van een extreem actief project, maar ook van operationele ruis. De laatste release (CUDA 13.3) is van 31 mei 2026.

De founders, Daniel en Michael Han, bouwen fulltime aan Unsloth vanuit San Francisco en Sydney. Geen VC-funding, geen Crunchbase-profiel, geen TechCrunch-aankondigingen. Pure open-source groei. Dat is opmerkelijk voor een project van deze omvang . Dat roept de vraag op wat het monetisatiemodel gaat worden. De AGPL op Studio is waarschijnlijk het antwoord: enterprise-licenties voor wie de copyleft-verplichtingen wil vermijden.

Het architectuurprobleem

De verleiding is groot om Unsloth Studio als centrale hub neer te zetten. Model downloaden, trainen, en direct via de ingebouwde inference-API beschikbaar stellen aan je applicaties. Eén tool, één endpoint.

Dat werkt voor een hobbyproject op je laptop. Voor een professionele setup : zeker in een gereguleerde omgeving : is het een architectuurfout.

De reden is simpel: inference en training hebben fundamenteel verschillende eisen. Inference vraagt om lage latency, hoge beschikbaarheid, load balancing, fallback-routes, en API-gateway policies. Training vraagt om maximale GPU-bezetting, reproduceerbare pipelines, en isolatie van productie-workloads. Een tool die beide probeert te doen, wordt in geen van beide uitstekend.

De juiste architectuur splitst deze verantwoordelijkheden:

• Trainingslaag: Unsloth Core/Studio . LoRA, QLoRA, RL-training, datasetvoorbereiding, export naar GGUF/safetensors
• Runtime-laag: llama.cpp, Ollama, vLLM, of SGLang . Elk geoptimaliseerd voor hun inference-patroon
• Routeringslaag: LiteLLM . Centrale API-gateway met fallback, rate limiting, cost tracking
• Orchestratielaag: agent-frameworks die bovenop de routering opereren

Unsloth exporteert. De runtime draait. De router verdeelt. Die scheiding is niet academisch . Het is het verschil tussen een setup die schaalt en een setup die omvalt zodra er twee teams tegelijk iets willen.

Waarom je wél een fine-tuning factory nodig hebt

De vraag "wanneer heb ik fine-tuning nodig?" wordt vaak verkeerd gesteld. Het antwoord is niet "als het standaardmodel niet goed genoeg is". Het antwoord is: als je organisatie domeinspecifieke kennis heeft die niet in de trainingsdata van publieke modellen zit.

Voor Nederlandse overheidsorganisaties is dat bijna per definitie het geval. Denk aan:

• Beleidsdocumenten met sectorspecifieke terminologie (NORA, BIO2, NIS2)
• Aanbestedingsprocedures met eigen formats en beoordelingscriteria
• Compliance-vragen die kennis van de Nederlandse wet- en regelgeving vereisen
• Interne architectuurbeslissingen die niet in openbare documentatie staan

Een generiek model van 70 miljard parameters kent deze context niet. Een kleiner model van 7 miljard parameters, gefinetuned op jouw documenten, kan verrassend accuraat zijn . Draait lokaal op een workstation in plaats van in de cloud.

Unsloth maakt deze aanpak praktisch haalbaar. Je pakt een compact model . Qwen Coder, Gemma, of Llama . Traint een LoRA-adapter op je eigen documentatie, en exporteert naar GGUF voor lokaal gebruik. Geen data die het pand verlaat, geen API-kosten per token, en volledige controle over modelversies.

De vier governance-risico's

1. AGPL-licentie

Unsloth Core is Apache 2.0 . Daar zit je goed. Maar Unsloth Studio valt onder AGPL-3.0. Dat betekent: zodra iemand via het netwerk toegang heeft tot jouw Unsloth-installatie (en dat is bij een web UI het hele punt), moet je de volledige broncode van alle afgeleide werken beschikbaar stellen onder dezelfde licentie.

Voor interne experimenten is dit beheersbaar. Voor productiegebruik waarbij je Unsloth integreert in een dienst die je aanbiedt aan klanten, is het een serieus juridisch risico. De mitigatie is eenvoudig: gebruik Unsloth Core voor alles wat richting productie gaat, en behandel Studio als lab-tool.

2. Supply chain

De standaard installatie-instructie is curl -fsSL https://unsloth.ai/install.sh | sh. Voor een tool die directe GPU-toegang heeft en willekeurige Python-code uitvoert, is dit onverantwoord. Er is geen package signing, geen checksum-verificatie, geen reproduceerbare build.

De juiste aanpak:

git clone https://github.com/unslothai/unsloth
cd unsloth
git checkout <gepinde-release>
./install.sh --local
pip freeze > requirements.lock
git rev-parse HEAD > UNSLOTH_COMMIT.lock

Voor BIO2-compliant gebruik is daarnaast een air-gapped installatieprocedure nodig. Geen enkele security officer tekent af op een curl | sh naar het internet.

3. Data governance

De Data Recipes-functionaliteit bouwt datasets uit PDF, CSV, DOCX. Dat is krachtig . En een DPIA-trigger. Waar gaan die bestanden heen? Is er telemetrie? Worden uploads lokaal verwerkt of raakt er iets een externe API?

Voor organisaties die persoonsgegevens verwerken: geen training op productiedata zonder voorafgaande classificatie, juridische grondslag, en herleidbaarheidscontrole. En documenteer elk model met een model card : herkomst van de data, gebruikte base model, training parameters, evaluatieresultaten.

4. AMD-track is experimenteel

Unsloth ondersteunt AMD via ROCm, maar met beperkingen. Studio ondersteunt alleen "Chat + Data" op AMD; training vereist Unsloth Core. De AMD-installatie vereist ROCm-compatible PyTorch met specifieke wheels. Voor RDNA4/R9700-hardware geldt: kansrijk, maar behandel het als experimentele track, niet als productie-aanname.

De NVIDIA-ondersteuning is aanzienlijk volwassener . RTX 30/40/50, Blackwell, en DGX zijn eersteklas burgers in het Unsloth-ecosysteem.

Implementatie in drie fasen

Fase 1: Lab-validatie

Doel: Unsloth geïsoleerd testen zonder bestaande inference-stack te raken.

mkdir -p ~/ai-lab/unsloth
cd ~/ai-lab/unsloth
uv venv unsloth_env --python 3.13
source unsloth_env/bin/activate
uv pip install unsloth --torch-backend=auto

Acceptatiecriteria: installatie reproduceerbaar, GPU zichtbaar (CUDA/ROCm/MLX), eerste LoRA-run op een klein model (Qwen of Gemma) slaagt, export naar GGUF werkt, en inference buiten Unsloth via Ollama of llama.cpp werkt.

Fase 2: Model-factory pipeline

Doel: domeinspecifieke adapters maken. Kandidaatmodellen: Qwen Coder voor code-review en documentatie-analyse, Gemma voor governancesamenvattingen, Llama voor algemene assistentie, EmbeddingGemma voor domein-embeddings.

Datasetbronnen: beleidsdocumenten, compliance-checklists, aanbestedingsformats, prompts die je organisatie consistent gebruikt. Niet: productiedata, persoonsgegevens, secrets, API keys.

Fase 3: Governance en evaluatie

Meet niet alleen training loss. Meet taakprestatie:

• Slaagpercentage op echte evaluatiecases
• Hallucinatiefrequentie bij governance- en securityvragen
• Token-efficiëntie (bruikbaar in agent-loops)
• Regressie op baseline (het getunede model mag niet slechter zijn op algemene taken dan het origineel)
• VRAM-gebruik bij inference
• Volledige licentietraceerbaarheid van model, adapter, en trainingsdata

Niet doen

• Unsloth als centrale runtime gebruiken. Daar zijn LiteLLM, vLLM, en Ollama beter in.
• Studio direct op het netwerk publiceren zonder authenticatie en reverse proxy.
• De nightly branch als standaard gebruiken in een productieomgeving.
• Performanceclaims van de README overnemen zonder lokale benchmarks : een paper uit 2026 (Chronicals) toonde aan dat een Unsloth-benchmark geen echte training uitvoerde door nul-gradientnormen. Dat maakt Unsloth niet slecht, maar wel: valideer claims zelf.
• AGPL-componenten ongemarkeerd integreren in commerciële workflows.

Wel doen

• Core installeren in een geïsoleerde venv of container
• Eerste test met een klein model voor snelle feedback
• Export naar GGUF en safetensors testen als onderdeel van je pipeline
• Adaptertraining inzetten voor domeinspecifieke taken
• AMD apart benchmarken, los van je stabiele NVIDIA-stack
• Elke wijziging aan de trainingspipeline vastleggen in een change-log

De bottom line

Unsloth is geen vervanging voor je inference-stack. Het is een accelerator voor je trainingspipeline. De meeste waarde ontstaat in de combinatie: Unsloth produceert gespecialiseerde modellen, je runtime-laag serveert ze, en je governance-laag houdt toezicht op herkomst, licentie, en prestatie.

Voor Nederlandse organisaties die soevereine AI serieus nemen . Lokaal, controleerbaar, en compliant . Is dat geen luxe. Het is de enige architectuur die schaalt zonder je juridische of operationele basis te ondermijnen.

---

Dit artikel is onderdeel van een reeks over AI-engineering governance. Eerder verschenen: de beveiligingsrisico's van lokale LLM-webinterfaces en cloudsoevereiniteit onder de CLOUD Act.