Self-hosted LLM-wrappers verkopen als B2B-oplossing
De markt voor eenvoudige SaaS-schillen rond commerciële AI-API's is verzadigd geraakt door dalende API-tarieven, standaardinterfaces en toenemende concurrentie. Wie een generieke interface bovenop een publieke model-API plaatst en per token factureert, ziet de operationele marges gestaag verdampen. Tegelijkertijd ontstaat er in de zakelijke B2B-markt een duidelijke en kapitaalkrachtige vraag naar software die taalmodellen niet via publieke cloudaanbieders ontsluit, maar binnen de eigen gecontroleerde infrastructuur van de klant draait. Bedrijven in sectoren zoals juridische dienstverlening, accountancy, financiële analyse, gezondheidszorg en lokale overheden worstelen met strikte compliance-regels, geheimhoudingsplichten en gegevensbescherming.
Deze organisaties zoeken naar manieren om interne documentstromen te doorzoeken, vertrouwelijke contracten te analyseren, offertes samen te stellen of klantinformatie te verwerken zonder dat er ook maar één token naar servers in het buitenland lekt. Het bouwen en verkopen van zogeheten self-hosted LLM-wrappers biedt softwareontwikkelaars en systeemintegrators een schaalbaar alternatief voor traditionele SaaS-abonnementen. Door een afgebakende applicatielaag te leveren die direct integreert met lokale inferentie-engines, verschuift de commerciële waardepropositie van token-wederverkoop naar softwarelicenties, maatwerkinrichting en periodieke beheerovereenkomsten. In dit artikel analyseren we de technische architectuur, de hardware-inrichting, meetbare prestaties, enterprise RAG, compliance-kaders en de structurele operationele valkuilen van dit softwaremodel.
De verschuiving van cloud-SaaS naar self-hosted architectuur
Waar vroege AI-toepassingen leunden op directe HTTP-aanroepen naar gecentraliseerde modelaanbieders, eist de zakelijke markt in 2026 volledige zeggenschap over dataflows en verwerkingslocaties. Een self-hosted wrapper is functioneel een complete software-suite: het bundelt authenticatie, rolgebaseerd toegangsbeheer, documentparsing, vectorindexering, query-routering en contextbeheer, maar delegeert de daadwerkelijke modelinferentie aan lokale hardware of een private cloudomgeving van de klant zelf. Deze opzet elimineert externe API-sleutels, voorkomt datalekken via centrale telemetry en garandeert dat invoerdata nooit gebruikt wordt voor modeltraining door derden.
Voor softwarebouwers verandert hiermee het inkomstenmodel fundamenteel. Zoals eerder geduid in het overzicht over monetisatie voor indie developers, verdampt de marge op pure API-wederverkoop doordat modelaanbieders elkaar beconcurreren met bodemprijzen. De werkelijke commerciële waarde verplaatst zich naar de integratielaag: robuuste software die naadloos aansluit op bestaande Active Directory-omgevingen, SQL-databases, lokale documentarchieven en interne bedrijfssoftware. Bedrijven betalen niet voor de ruwe rekenkracht, maar voor de veilige ontsluiting en de zekerheid dat hun intellectueel eigendom binnen de eigen firewall blijft.
De technische realisatie vereist een strikte scheiding tussen drie kernlagen: de presentatielaag (web-UI of desktop client), de orkestratie- en applicatiebackend, en de runtime-omgeving waarin het open-weight model draait. Deze ontkoppeling zorgt ervoor dat de software flexibel mee kan schalen. Wanneer een klant besluit over te stappen van een compact kantoorwerkstation naar een geclusterde private cloudomgeving, hoeft uitsluitend het endpoint van de modelengine te worden gewijzigd zonder dat de applicatiecode aangepast hoeft te worden.
Hardwarevereisten, kwantisatie en inferentie-engines
Een doorslaggevende factor bij de verkoop van on-premises oplossingen is de benodigde hardware-investering. Zakelijke beslissers haken af wanneer voor een eenvoudige administratieve assistent tienduizenden euro's aan gespecialiseerde datacenter-GPU's aangeschaft moeten worden. Dankzij moderne kwantisatietechnieken zoals GGUF, AWQ en FP8 kunnen open-weight modellen met 8 tot 70 miljard parameters draaien op relatief betaalbare werkstations of gehuurde dedicated servers.
In de praktijk steunt de wrapper vaak op geavanceerde inferentie-backends zoals vLLM, llama.cpp of Aphrodite Engine. Wie de ontwikkelingen volgt rondom lokale LLM's en modelservers, ziet dat engines met continue batching en PagedAttention een aanzienlijk hogere doorvoersnelheid leveren bij gelijktijdige gebruikersvragen dan traditionele sequentiële REST-servers. Onderstaande matrix toont geteste configuraties die representatief zijn voor hedendaagse B2B-implementaties:
| Doelgroep / Werkbelasting | Modelklasse & Precisie | Minimale Hardware | Aanbevolen Backend | Verwachte Prestatie |
|---|---|---|---|---|
| Klein kantoor (1-10 gebruikers) | 8B - 14B (GGUF Q4_K_M / Q8_0) | 1x RTX 4090 (24GB VRAM) of Mac Studio (M2/M3 Max 64GB) | llama.cpp / Ollama | 25-50 tokens/sec single stream |
| Middenbedrijf (10-50 gebruikers) | 14B - 32B (AWQ 4-bit / FP8) | 2x RTX 4090 of 1x RTX 6000 Ada (48GB) | vLLM (PagedAttention) | 80-160 tokens/sec geaggregeerd |
| Enterprise (50+ gebruikers) | 70B Q4/FP8 of MoE (bijv. Mixtral) | 2x tot 4x H100 / A100 (80GB SXM) | vLLM met Tensor Parallelism | 250+ tokens/sec batch throughput |
Bij het dimensioneren van de hardware moet niet alleen naar het modelgewicht worden gekeken, maar nadrukkelijk ook naar het geheugenbeslag van de KV-cache (Key-Value cache). Bij lange documentcontexten van 32k tot 64k tokens groeit het VRAM-gebruik per actieve gebruiker exponentieel. Als een kantoor tien gelijktijdige documentanalyses draait, kan de KV-cache meer videogeheugen opeisen dan het model zelf. Een professionele self-hosted wrapper moet daarom voorzien zijn van strikte VRAM-toewijzingslimieten en dynamische wachtrijmechanismen om servercrashes door out-of-memory fouten te voorkomen.
Latency, throughput en meetmethodes in zakelijke omgevingen
Bij zakelijke implementaties volstaat het niet om te claimen dat het systeem snel aanvoelt. Bedrijven sturen op duidelijke prestatie-indicatoren (SLA's) die bepalen of een workflow rendabel is. Om de prestaties van een self-hosted LLM-wrapper objectief vast te stellen, hanteren we drie gestandaardiseerde meeteenheden:
1. Time to First Token (TTFT): De tijd tussen het verzenden van de gebruikersvraag inclusief documentcontext en het verschijnen van het allereerste gegenereerde woord. TTFT weerspiegelt hoe snel de inferentie-engine de prompt en de RAG-context kan verwerken (de zogeheten prefill-fase). Een acceptabele TTFT voor interactief kantoorgebruik ligt onder de 1200 milliseconden bij een context van 4000 tokens.
2. Time Per Output Token (TPOT): De gemiddelde tijd die nodig is om elk opeenvolgend token te genereren (de decodeerfase). Dit bepaalt de waargenomen leessnelheid. Voor menselijke interactie is een snelheid van 20 tot 30 tokens per seconde per individuele gebruiker wenselijk, wat overeenkomt met een TPOT van 33 tot 50 milliseconden.
3. Geaggregeerde batch-doorvoer (Tokens per seconde per dollar): Bij achtergrondtaken, zoals het 's nachts indexeren en samenvatten van honderden binnengekomen processtukken, telt niet de individuele reactietijd, maar het totale aantal verwerkte tokens per minuut over alle actieve GPU-kernen.
Om deze statistieken betrouwbaar te meten, integreert de applicatielaag een benchmarking-module die synthetische prompts van variërende lengtes (1k, 4k, 16k tokens) met verschillende niveaus van gelijktijdigheid afvuurt op de lokale backend. Hierdoor krijgt de IT-afdeling van de klant direct inzicht in de piekbelasting en kunnen eventuele knelpunten in PCIe-bandbreedte of VRAM tijdig worden gesignaleerd.
Beveiliging, isolatie en sandboxing van integraties
Wanneer een LLM-wrapper meer doet dan platte tekst genereren — bijvoorbeeld wanneer het systeem SQL-databases raadpleegt, bestandsconversies uitvoert of code-snippets evalueert — ontstaan er aanzienlijke beveiligingsrisico's. B2B-klanten verlangen harde architecturale garanties dat een autonoom handelend model geen ongeautoriseerde wijzigingen kan aanbrengen in het bedrijfsnetwerk of toegang kan forceren tot afgeschermde netwerksegmenten.
Strikte software-isolatie is daarom een absolute vereiste. In het artikel over sandboxing van LLM-tools met Docker wordt uitgebreid ingegaan op het isoleren van runtime-omgevingen via read-only bestandssystemen, geheugenplafonds en ontkoppelde virtuele netwerken. Zonder deze scheiding kan een kwaadwillende prompt-injectie (bijvoorbeeld verborgen in een geïmporteerd PDF-bestand) de modeltool instrueren om interne host-bestanden uit te lezen of ongeautoriseerde netwerkpakketten te versturen.
# Productie-opzet: Docker Compose met strikte netwerkscheiding
services:
inference-engine:
image: vllm/vllm-openai:latest
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
environment:
- MODEL=/models/qwen-2.5-32b-instruct-awq
- MAX_MODEL_LEN=16384
- GPU_MEMORY_UTILIZATION=0.90
- DISABLE_LOG_REQUESTS=true
volumes:
- /opt/models:/models:ro
networks:
- internal-backend
restart: unless-stopped
b2b-wrapper-core:
image: registry.klantdomein.intern/b2b-wrapper:v2.1
environment:
- OPENAI_API_BASE=http://inference-engine:8000/v1
- DATABASE_URL=postgresql://app:dbpass@db:5432/appdb
- VECTOR_STORE_HOST=vector-db
- AUDIT_LOG_ENABLED=true
depends_on:
- inference-engine
- db
- vector-db
networks:
- internal-backend
- dmz-ingress
ports:
- "127.0.0.1:8080:8080"
restart: unless-stopped
vector-db:
image: qdrant/qdrant:latest
volumes:
- /opt/qdrant_data:/qdrant/storage
networks:
- internal-backend
restart: unless-stopped
db:
image: postgres:16-alpine
environment:
- POSTGRES_DB=appdb
- POSTGRES_PASSWORD=dbpass
volumes:
- /opt/postgres_data:/var/lib/postgresql/data
networks:
- internal-backend
restart: unless-stopped
networks:
internal-backend:
internal: true
dmz-ingress:
driver: bridge
In het bovenstaande configuratiemodel heeft de inferentie-engine met het model geen enkele fysieke of virtuele route naar het externe internet. De centrale backend fungeert als strikte poortwachter: alle interacties worden gefilterd, invoerdata wordt gevalideerd en alle dataopslag blijft binnen geïsoleerde volumes die uitsluitend toegankelijk zijn voor de geautoriseerde componenten van de stack.
Enterprise RAG en rolgebaseerde datatoegang (RBAC)
Een lege gebruikersinterface over een taalmodel heeft voor zakelijke afnemers beperkte waarde. De daadwerkelijke operationele efficiëntie ontstaat wanneer het model direct gekoppeld wordt aan de interne kennisbank van de organisatie via Retrieval-Augmented Generation (RAG). In een zakelijke context brengt dit echter complexe vraagstukken met zich mee rondom autorisatie en bestandsstructuren.
Het grootste gevaar bij standaard RAG-implementaties is het lekken van informatie tussen afdelingen (privilege escalation via search). Als een medewerker van de klantenservice een algemene zoekvraag stelt, mag het systeem onder geen beding tekstfragmenten ophalen uit geheime directieverslagen of salarisoverzichten die toevallig in dezelfde vectordatabase staan geïndexeerd. Een volwassen B2B-wrapper implementeert daarom metadata-filtering op chunkniveau: elk tekstfragment in de vectordatabase wordt gekoppeld aan de Access Control Lists (ACL's) van het bronsysteem (zoals SharePoint of lokale netwerkschijven). Vóórdat de vectordatabase de nearest-neighbor zoekactie uitvoert, wordt een hard filter toegepast op de gebruikersrechten van de actieve sessie.
Bovendien vereist zakelijke documentparsing robuuste extractiemethodes. Juridische contracten, jaarrekeningen en technische dossiers bevatten complexe tabellen, paginanummering, voetnoten en lay-outs met meerdere kolommen. Eenvoudige tekstextractietools hakken tabellen vaak willekeurig doormidden, waardoor de relationele samenhang tussen cijfers verloren gaat. Een hoogwaardige wrapper gebruikt geavanceerde parsing-engines (zoals lay-out-aware OCR-modellen) die tabellen converteren naar gestructureerde Markdown-tabellen voordat ze in de context worden geplaatst, zodat het taalmodel nauwkeurig kan redeneren over kwantitatieve gegevens.
Compliance, AVG en de AI Act als verkoopargument
De strenge handhaving van de Algemene Verordening Gegevensbescherming (AVG) en de introductie van de Europese AI Act zijn voor veel bedrijven de belangrijkste redenen om externe cloud-API's categorisch af te wijzen. Bedrijven riskeren aanzienlijke boetes en reputatieschade wanneer persoonsgegevens of bedrijfsgeheimen zonder expliciete grondslag naar buitenlandse serverparken worden verstuurd.
Wie de juridische kaders wil doorgronden, vindt in de analyse over AI-modellen en privacy onder de AVG de specifieke vereisten rond gegevensminimalisatie, doelbeperking en het verwerken van bijzondere categorieën persoonsgegevens. Bij een self-hosted implementatie blijft de dataverwerking volledig binnen de juridische en fysieke controle van de klant. Er is geen sprake van internationale gegevensoverdracht (zoals data-export naar de VS onder het Data Privacy Framework), en er hoeven geen complexe keten-verwerkersovereenkomsten met derden te worden afgesloten.
Daarnaast vereist de AI Act dat zakelijke AI-systemen transparant en controleerbaar zijn. Een zakelijke self-hosted wrapper voorziet daarom in een cryptografisch beveiligd auditlogboek. Elk verzoek wordt vastgelegd met een unieke transactie-ID, het tijdstip, het geanonimiseerde gebruikersaccount, de gehanteerde prompt-sjablonen en de specifieke documentreferenties die door het model zijn geraadpleegd. Zo kan de compliance officer van de klant bij een interne audit exact aantonen op basis van welke bronnen een besluit of samenvatting tot stand is gekomen.
Commerciële modellen: Licenties, implementatie en SLA's
Het verkopen van self-hosted software vereist een ander financieel model dan reguliere cloud-SaaS. Omdat de klant zelf de hardware aanschaft of de private cloudinstantie financiert, vallen de variabele tokenkosten voor de softwareleverancier weg naar nul. Dit elimineert het risico dat intensieve gebruikers de winstmarge van de softwareontwikkelaar opeten, maar vergt duidelijke afspraken over licentiehandhaving en support.
In de praktijk hanteren succesvolle softwareverkopers een combinatie van drie inkomstenstromen:
1. Periodieke softwarelicentie (Core + Seat Model): Een vast jaarbedrag voor het gebruik van de wrapper-software op een serverinstantie, gecombineerd met een staffel op basis van het aantal actieve gebruikersaccounts. Omdat zakelijke systemen vaak draaien in air-gapped of afgeschermde netwerken zonder internettoegang, werkt de licentievalidatie meestal via cryptografisch ondertekende licentiesleutels met een vaste verloopdatum in plaats van online activatieservers.
2. Eenmalige implementatie en inrichting (CapEx): Het installeren van de softwarestack, het configureren van de lokale GPU-drivers, het koppelen van de bedrijfsdatabronnen en het kalibreren van de vectorindexering. Dit dekt de directe ontwikkel- en consultancy-uren en zorgt voor een aanzienlijke cashflow bij aanvang van het traject.
3. Managed Maintenance SLA (OpEx): Het operationeel houden van de stack, het doorvoeren van beveiligingspatches op de onderliggende containers, en het periodiek evalueren en upgraden van het open-weight model wanneer er krachtigere open modellen beschikbaar komen. Veel bedrijven hebben geen gespecialiseerde AI-engineers in dienst en besteden het technisch beheer van de modellenlaag graag uit via een vast maandelijks onderhoudscontract.
Operationele risico's, modeldrift en hardwarebeheer
Het hosten en beheren van lokale AI-infrastructuur brengt specifieke technische uitdagingen met zich mee die bij publieke clouddiensten door de provider worden geabstraheerd. Een transparante communicatie over deze beperkingen voorkomt frictie tijdens het beheerproces.
Een voornaam risico is geheugendegradatie en VRAM-fragmentatie bij langdurig actieve modelservers. Wanneer verschillende gebruikers wisselende contextgroottes opvragen, kan het videogeheugen na verloop van tijd gefragmenteerd raken, waardoor nieuwe verzoeken onterecht worden geweigerd. De applicatielaag moet daarom geautomatiseerde periodieke health-checks uitvoeren en de worker-processen zo nodig gecontroleerd herstarten tijdens daluren.
Daarnaast is er het fenomeen van modeldrift bij updates. Waar commerciële API-aanbieders achter de schermen wijzigingen doorvoeren die prompts onverwacht kunnen breken, heeft de beheerder van een self-hosted stack zelf de controle over upgrades. Dit brengt echter de verplichting met zich mee om modelupdates grondig te testen. Een nieuw 32B-model kan op algemene benchmarks superieur scoren, maar slechter presteren op specifieke Nederlandse juridische vaktermen. Het inrichten van een geautomatiseerde regressietest met een vaste set bedrijfsspecifieke prompts is noodzakelijk vóórdat een modelupgrade in productie wordt genomen.
Tot slot moeten organisaties rekening houden met fysieke hardware-uitval. Consumenten-GPU's die continu onder hoge belasting draaien in een kantoorruimte zonder professionele koeling hebben een beperktere levensduur dan datacenter-hardware met redundante voedingen en constante klimaatbeheersing. Het adviseren van de juiste hardware-opstelling en het inbouwen van failover-mechanismen naar een secundair werkstation behoort tot de standaardverantwoordelijkheid van een professionele integrator.
Conclusie: Bouwen voor digitale soevereiniteit
Het verkopen van self-hosted LLM-wrappers aan zakelijke klanten is een volwaardige software-discipline die veel verder gaat dan het aanbieden van een grafische schil. De werkelijke commerciële kracht ligt in het wegnemen van enterprise-zorgen rondom gegevensbescherming, geheimhouding en wetgeving door middel van solide engineering: robuuste containerisatie, fijnmazig rolgebaseerd toegangsbeheer, betrouwbare documentparsing en voorspelbare hardware-architectuur.
Voor organisaties die gebonden zijn aan strikte privacy-eisen of strategische autonomie eisen over hun bedrijfskennis, weegt de eenmalige investering in een eigen lokale stack ruimschoots op tegen de structurele risico's en compliance-problemen van externe cloud-API's. Ontwikkelaars die deze enterprise-behoeften vertalen naar een stabiel, modulair en privacy-zeker softwarepakket creëren een duurzame B2B-propositie met hoge klantwaarde en gezonde marges.


