Lokale taalmodellen en een eigen AI-omgeving
Soms mogen gegevens echt niet naar een externe AI-aanbieder. Dan komen de modellen naar uw data: op uw eigen GPU's of in een afgeschermde omgeving, net zo makkelijk te gebruiken als een openbare API.
Vertel over uw projectHet probleem
Open modellen zijn goed genoeg geworden voor veel zakelijke taken, maar ze goed draaien is een vak apart. GPU's zijn duur, een model dat geladen is maar niets doet houdt toch geheugen bezet, en iedereen wil toegang vanuit zijn eigen tools.
Zonder gedeelde opzet doet iedereen zijn eigen experimenten, belanden API-sleutels in scripts en weet niemand wat er gebruikt wordt of wat het kost.
Hoe ik het aanpak
De juiste modellen kiezen
We testen open modellen op uw eigen taken en kiezen het kleinste model dat het werk goed doet.
Eén API voor alles
Een OpenAI-compatibele gateway voor alle modellen, lokaal en extern, met een sleutel per gebruiker of applicatie.
De hardware slim gebruiken
Modellen starten als ze nodig zijn en stoppen als ze niets doen, en een wachtrij verdeelt de GPU's over trainingsjobs en modelservers.
Logging en limieten
Gebruik per gebruiker en applicatie, bestedingslimieten voor externe aanbieders, en caching waar dat helpt.
De tools koppelen
Chatomgevingen, codeerassistenten en uw eigen applicaties praten allemaal met hetzelfde endpoint.
Waar u op moet letten
- Zelf hosten is niet automatisch goedkoper. Bij een laag volume is een Europese aanbieder met een verwerkersovereenkomst vaak voordeliger.
- Een gateway bewaart de sleutels tot alles. Behandel hem als kritieke infrastructuur: zet versies vast, beperk sleutels en volg beveiligingsmeldingen.
- Open modellen verschillen sterk per taak en per taal. Zijn uw documenten Nederlands, test dan in het Nederlands.
Vergelijkbare projecten
Lokale taalmodellen, alleen als het team ze nodig heeft
Het team wilde taalmodellen gebruiken zonder data naar een externe aanbieder te sturen. Maar een model op een lokale GPU houdt een groot deel van het GPU-geheugen bezet, ook als niemand het gebruikt. Nu heeft het team één API voor alle lokale modellen. Een agent op elke GPU-machine start een model bij het eerste verzoek en stopt het na een uur zonder verzoeken. Dan is de GPU weer vrij voor ander werk.
- Eén OpenAI-compatibele API voor alle lokale modellen, waar teamleden hun chat- en codeertools aan koppelen.
- Een dashboard toont welke modellen draaien, en beheerders kunnen elk model starten en stoppen.
- De modellen draaien op GPU-machines die het bedrijf al heeft. Er gaat geen data naar een externe aanbieder.
- Verzoek uit een chat- of codeertool
- Gedeelde API
- Model starten als dat nodig is
- Antwoord van het lokale model
Een eigen AI-werkomgeving met meerdere agents
Het team wilde AI-assistenten die geen gegevens naar een openbare chatapp sturen. Nu is er een zelf gehoste chatomgeving met gespecialiseerde agents, plus een aparte API-laag die het gebruik logt en antwoorden in een cache bewaart.
- Een zelf gehoste chatomgeving met agents voor verschillende taken.
- Een API-laag tussen de agents en de modelaanbieders die het gebruik logt en antwoorden cachet.
- Alles draait op infrastructuur die de klant al had.
- Vragen en documenten van het team
- Gespecialiseerde agents
- Laag voor logs en cache
- Antwoorden in de eigen omgeving van de klant
Een wachtrij voor gedeelde GPU-machines
Een team van engineers en onderzoekers deelde een handvol GPU-machines en sprak in een groepschat af wie welke machine kreeg. Nu zet iedereen een Docker-job in een wachtrij, die de job start op een machine met vrije capaciteit. Een webinterface toont de wachtrij, de logs en hoe druk elke GPU is.
- Jobs worden verdeeld op basis van het GPU-geheugen dat ze nodig hebben, zodat kleine jobs een GPU kunnen delen en er minder GPU-tijd verloren gaat.
- Elke job draait als de persoon die hem heeft ingediend en kan alleen bij de mappen die de regels toestaan.
- Gebruikers kunnen een shell openen in hun job. Een job kan ook een modelserver starten voor andere jobs; die stopt zodra die jobs klaar zijn.
- Ook coding agents kunnen jobs indienen en resultaten lezen, via een MCP-server.
- Docker-job van een teamlidVrije capaciteit per machine
- Machine kiezen
- Job draaien als de eigenaar
- Logs en GPU-gebruik in de webinterface
Veelgestelde vragen
Welke hardware hebben we nodig?
Dat hangt af van de modellen en het volume. Kleinere modellen draaien op één workstation-GPU; grotere hebben server-GPU's of een private cloud nodig. Dat bepalen we na tests op uw eigen taken.
Kunnen we lokale en externe modellen combineren?
Ja. Eén gateway kan gevoelig werk naar lokale modellen sturen en de rest naar een externe aanbieder.
Wie onderhoudt het?
Ik kan het opzetten en met documentatie overdragen aan uw team, of het voor u blijven beheren.