Eén AI-leverancier die zijn prijzen verhoogt of een model offline haalt, kan je operatie platleggen. Ik laat je een dunne routerlaag bouwen met open-weight achtervang en budgetbewaking, zodat je nooit aan één aanbieder vastzit.
Je hele bedrijf draait inmiddels op AI van een handjevol leveranciers. De factuurassistent, de klantenservicebot, de code-completion in je editor, allemaal hangen ze aan één of twee API’s van OpenAI of Anthropic. Dat werkt prima, tot het niet meer werkt: een prijsverhoging, een model dat zonder aankondiging verdwijnt, of een exportregel die een model van de ene op de andere dag offline haalt. Dan staat een deel van je operatie stil en heb je geen knop om op te drukken.
Deze gids is voor de ondernemer of het technische team dat AI serieus gebruikt en niet afhankelijk wil zijn van de grillen van één aanbieder. Ik laat je stap voor stap een leverancier-onafhankelijke AI-stack bouwen: een dunne routerlaag tussen jouw applicaties en de modellen, met open-weight modellen als achtervang en budgetbewaking die ingrijpt voordat de rekening ontspoort. Geen big-bang migratie, maar een laag die je er vandaag onder schuift en morgen uitbreidt. Dat dit geen theoretisch risico is, blijkt uit Nadella’s oproep om je eigen AI-stack te bouwen in plaats van te leunen op een paar modellen en uit de simpele logica dat je eigenaar moet blijven van je software in plaats van vendor lock-in te accepteren.
Wat je nodig hebt
Voordat je begint, leg je dit klaar. Niets exotisch, het meeste heb je al.
- Een overzicht van waar je nu AI gebruikt. Welke apps, welke leverancier, welk model, hoeveel verbruik per maand. Zonder dit beeld stuur je blind.
- Een plek om een gateway te draaien. Een kleine VPS of een container die je zelf beheert. De gateway is dun, een paar honderd MB geheugen volstaat om te beginnen.
- API-sleutels van je huidige aanbieder(s). Die blijven gewoon in gebruik, ze gaan alleen achter de router zitten.
- Een Postgres-database. LiteLLM bewaart daarin de verbruikslogs en de virtuele sleutels (zie stap 4). Een gratis of goedkope managed Postgres is genoeg.
- Optioneel, maar aanbevolen: een machine om een open-weight model lokaal te draaien. Met Ollama draai je een model als Qwen, DeepSeek of Mistral op je eigen hardware. Dit mag later; je kunt eerst een tweede cloudaanbieder als achtervang gebruiken.
De stappen
Je bouwt een model-router: een dunne gateway tussen je apps en de AI-modellen, zodat je met één regel configuratie van leverancier kunt wisselen zonder je code aan te raken. Je inventariseert je AI-gebruik, zet LiteLLM als proxy neer, stelt open-weight fallbacks in via Ollama, koppelt budgetbewaking en test de failover.
Werk deze vijf stappen in volgorde af:
Stap 1: Breng in kaart waar je AI gebruikt
Inventariseer eerst. Maak een simpele tabel: per applicatie of automatisering noteer je de leverancier, het model, het maandelijkse tokenverbruik en hoe kritisch het is. Markeer wat stilvalt als die ene API eruit ligt. Dat zijn je prioriteiten. Heb je hier geen cijfers van, dan levert de router in stap 4 ze vanzelf, maar een eerste schatting helpt je kiezen waar je begint. Begin met één concreet, belangrijk gebruik (bijvoorbeeld je klantenservicebot), niet met alles tegelijk.
Stap 2: Zet een model-router (AI-gateway) neer
Installeer LiteLLM als proxy. LiteLLM is een open-source AI-gateway die meer dan 100 LLM-providers achter één OpenAI-compatibele interface zet: OpenAI, Anthropic, Gemini, Azure, Bedrock en lokale modellen. Je apps praten straks alleen nog met de gateway, niet meer rechtstreeks met een leverancier.
Installeren en starten:
pip install 'litellm[proxy]'
litellm --config config.yaml
De proxy luistert standaard op poort 4000. In een config.yaml definieer je je modellen onder een eigen naam, zodat je apps een neutrale naam aanroepen in plaats van een merknaam:
model_list:
- model_name: tekst-generatie # de naam die je apps aanroepen
litellm_params:
model: openai/gpt-5.5
api_key: os.environ/OPENAI_API_KEY
In je applicaties verander je nu alleen de base_url van de OpenAI-client naar http://localhost:4000 en je gebruikt het model tekst-generatie. Vanaf nu bepaalt de gateway, niet je code, welk model er achter die naam draait.
Stap 3: Stel open-weight fallbacks in
Voeg een achtervang toe. Het hele punt van de stack is dat een tweede model het overneemt als de eerste faalt. Draai daarvoor een open-weight model lokaal met Ollama, dat een OpenAI-compatibel endpoint aanbiedt op http://localhost:11434:
ollama pull qwen3
ollama serve
Voeg het model toe aan je config.yaml en koppel het als fallback. Let op de router_settings: daarin zeg je dat een mislukte aanroep van tekst-generatie automatisch naar het lokale model gaat.
model_list:
- model_name: tekst-generatie
litellm_params:
model: openai/gpt-5.5
api_key: os.environ/OPENAI_API_KEY
- model_name: tekst-generatie-lokaal
litellm_params:
model: ollama/qwen3
api_base: http://localhost:11434
router_settings:
fallbacks: [{"tekst-generatie": ["tekst-generatie-lokaal"]}]
num_retries: 3
request_timeout: 30
Falt de primaire aanbieder (een time-out, een 429, een model dat verdwijnt), dan beantwoordt je eigen machine de aanvraag. Welk open-weight model je kiest, hangt af van de taak; de keuze is groot nu bedrijven uitwijken naar open source en goedkopere modellen. Voor code is Kimi K2.7-Code, dat Moonshot AI uitbracht voor een fractie van wat OpenAI en Anthropic per token rekenen, een serieuze achtervang. Lokaal draaien heeft gevolgen voor beheer en privacy die ik uitwerk in mijn afweging wanneer self-hosted wint van de cloud en wanneer niet.
Stap 4: Koppel budgetmonitoring
Zet een plafond op je verbruik. LiteLLM logt elke aanroep met tokens en kosten in zijn database en kan harde budgetten afdwingen per sleutel, per gebruiker en per team. Zet eerst een limiet op de hele proxy:
litellm_settings:
max_budget: 200 # harde maandlimiet voor de proxy, in dollar
budget_duration: 30d
Geef vervolgens elke app een eigen virtuele sleutel met een eigen budget, zodat één doorgeslagen automatisering niet je hele rekening opmaakt. LiteLLM houdt het verbruik per sleutel bij en grijpt in bij het ingestelde max_budget:
curl http://localhost:4000/key/generate \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-d '{"models": ["tekst-generatie"], "max_budget": 50, "budget_duration": "30d"}'
Nu zie je in één dashboard wat elke toepassing kost en zit er een rem op. Dit is dezelfde discipline waarmee je je AI-rekening in toom houdt nu agenten de tokenkosten omhoogjagen, maar dan afgedwongen in plaats van gehoopt.
Stap 5: Test de failover en zet het in productie
Forceer een storing voordat de echte komt. Zet tijdelijk een ongeldige API-sleutel voor je primaire model, stuur een verzoek naar de gateway en controleer dat het antwoord van je lokale fallback komt. Vergelijk de kwaliteit: een fallback is zelden één-op-één hetzelfde. Test je belangrijkste prompts daarom expliciet tegen het achtervangmodel en stel ze waar nodig bij. Pas als de failover schoon werkt en je budgetlimieten staan, leid je je productieverkeer via de gateway. Houd de eerste dagen je verbruikslogs in de gaten.
Valkuilen
Een router lost veel op, maar introduceert ook nieuwe aandachtspunten. Deze zie ik het vaakst misgaan.
- De gateway wordt een single point of failure én een doelwit. Alles loopt er nu doorheen, dus een lek raakt alles. Dit is geen hypothetisch risico: er waren drie LiteLLM-lekken die gewone gebruikers admin-rechten op de AI-gateway gaven. Pin een vaste, gepatchte versie, zet de proxy nooit open op het publieke internet, en draai hem achter authenticatie. Plan updates in.
- Een fallback is niet zomaar inwisselbaar. Contextlengte, tool-calling en gevoeligheid voor je prompt verschillen per model. Reken niet op identieke output; test en accepteer dat de achtervang een tandje minder kan zijn. Beter een wat soberder antwoord dan geen antwoord.
- Niet elk model spreekt elke functie. Function calling, structured output of vision werken niet overal hetzelfde. Gebruik je die features, controleer dan of je fallback ze ondersteunt, anders faalt de failover juist op je belangrijkste verzoeken.
- Een hard budgetplafond zonder waarschuwing legt productie stil. Stel naast de harde limiet ook een alert op een lager bedrag in, zodat je ingrijpt voordat de rem dichtklapt. Een dichte kraan midden in werktijd is zelf een storing.
- Routeren naar meerdere aanbieders verspreidt je data. Weet bij elke route waar je klantdata heen gaat. Voor gevoelige verwerking houd je die bewust op je eigen, lokale model. Hetzelfde geldt voor een RAG-chatbot die antwoorden baseert op je eigen documenten: ook daar wil je gevoelige data niet via een derde laten lopen.
Kant-en-klaar vs. maatwerk
Niet iedereen hoeft dit zelf te hosten. De eerlijke afweging zit tussen snelheid, controle en wie je data ziet.
| Aanpak | Wat het is | Voor wie | Let op |
|---|---|---|---|
| Managed router (bijv. OpenRouter) | Een gehoste gateway; je stuurt verkeer naar hun endpoint | Snel willen starten zonder eigen beheer | Je verlegt je lock-in naar de router en je data loopt via een derde partij |
| Self-hosted LiteLLM | Open-source gateway op je eigen server | Teams die controle, privacy en eigen budgetten willen | Je beheert updates en security zelf (zie de valkuilen) |
| Maatwerk in je eigen code | Routerlogica en orkestratie in je eigen applicatie | Specifieke eisen, eigen agent-orkestratie | Het meeste werk, maar ook de meeste grip |
Kant-en-klaar is verleidelijk omdat je in een uur draait, maar je ruilt je afhankelijkheid van een modelleverancier dan in voor afhankelijkheid van een routerleverancier. Self-hosted LiteLLM is voor de meeste bedrijven de gulden middenweg: open source, op je eigen server, met je data binnenboord. Wil je een laag boven meerdere agenten in plaats van alleen modellen, kijk dan naar Databricks Omnigent, een open-source meta-harness die op 13 juni uitkwam als één orchestratielaag boven al je AI-agenten. En twijfel je principieel tussen zelf bouwen en inkopen, dan legt mijn afwegingskader voor software bouwen of kopen uit hoe je die keuze structureert zonder je op een onderbuikgevoel te baseren.
Aan de slag
De stack hierboven is bewust dun: een router, een fallback, een budget. Dat is genoeg om nooit meer wakker te liggen van één leverancier die zijn voorwaarden verandert. Het lastige zit niet in de installatie, maar in de keuzes eromheen: welke modellen passen bij welke taak, hoe streng zet je je budgetten, en hoe houd je de gateway veilig zonder dat je team er fulltime mee bezig is.
