Wat is Ollama? Lokale LLM's in productie draaien voor teams

Wat is Ollama?

Ollama is een open-source runtime voor het uitvoeren van LLM's op je eigen infrastructuur, of dat nu een laptop, een on-premises GPU-box of een private cloud-instance is. Je downloadt een open-weight model zoals Llama, Mistral of Qwen, en Ollama serveert het lokaal achter een HTTP-endpoint. Cruciaal is dat dit endpoint een OpenAI-compatibele API gebruikt, zodat code die is geschreven voor de OpenAI SDK kan communiceren met een lokaal Ollama-model door alleen de base URL aan te passen.

Teams kiezen om een paar duidelijke redenen voor Ollama:

• Privacy. Het model draait op hardware die je zelf beheert, dus prompts en outputs verlaten nooit je omgeving.
• Offline en air-gapped gebruik. Geen afhankelijkheid van een gehoste provider of het openbare internet.
• Kosten. Open-weight modellen op je eigen hardware voorkomen API-kosten per token.
• Eenvoud. Een model operationeel krijgen vereist slechts één commando.

Ollama werkt het beste wanneer

• Je snelle lokale inference wilt tijdens de ontwikkeling.
• Je open-weight modellen draait op hardware die je bezit.
• Data je omgeving niet mag verlaten om privacy- of compliance-redenen.
• Je een OpenAI-compatibel endpoint nodig hebt zonder zwaardere serving-infrastructuur op te zetten.

Ollama vs vLLM: Welke moeten teams gebruiken?

De meest voorkomende vergelijking is Ollama versus vLLM, omdat beide OpenAI-compatibele API's bieden en beide open-weight modellen self-hosten. Ze zijn echter geoptimaliseerd voor verschillende doeleinden.

De eerlijke samenvatting is dat Ollama de eenvoudigste manier is om een model voor één persoon te draaien, en vLLM is gebouwd om veel gelijktijdige gebruikers te bedienen met een hoge throughput. Veel teams gebruiken beide: Ollama voor lokale ontwikkeling en vLLM voor productie. Het goede nieuws is dat omdat beide OpenAI-compatibel zijn, wat je ook standaardiseert achter dezelfde gateway geplaatst kan worden, en je er zelfs tussen kunt routen.

Waar Ollama tekortschiet voor teams

Ollama doet zijn werk goed, maar het uitrollen voor een organisatie brengt tekortkomingen aan het licht die buiten de scope vallen.

• Geen gedeeld toegangsbeheer. Een kaal Ollama-endpoint heeft geen ingebouwd idee van welk team of welke gebruiker welk model mag aanroepen.
• Geen kostentoewijzing. Er is geen overzicht van het verbruik per team of per applicatie, omdat Ollama requests afhandelt zonder ze te meten op basis van de eigenaar.
• Geen guardrails. Prompts en outputs worden niet gecontroleerd op PII, geheimen of injection-pogingen.
• Geen routing of fallback. Als één model of box uitvalt, is er niets om naar uit te wijken (failover), en er is geen manier om verschillende requests naar verschillende modellen te sturen.
• Gecentraliseerde vs. gefragmenteerde endpoints. Elke Ollama-instance is een eigen URL, waardoor applicaties endpoints hardcoden en hun portabiliteit verliezen.

Dit zijn precies de zaken waar een gateway voor is ontworpen, en het is de manier waarop je een lokale model runner omzet in infrastructuur voor teams.

Hoe je Ollama voor teams draait met TrueFoundry

TrueFoundry behandelt een Ollama-server als een self-hosted model. Je verbindt het met de AI Gateway door de endpoint-URL en authenticatiegegevens op te geven. Zodra het is geregistreerd, verschijnt het in de modelcatalogus van de gateway naast cloudproviders, waarbij alle gateway-functies worden toegepast: routing, guardrails, rate limiting, kostentracking en observabiliteit. Ollama wordt hier expliciet ondersteund omdat het een OpenAI-compatibele API biedt, het formaat waar de gateway het beste mee werkt.

Je registreert het model onder AI Gateway, daarna Models en vervolgens Self Hosted Models. Je geeft het een naam, een model-ID, de URL van je Ollama-server en het type model server, optioneel met authenticatie. Vanaf dat moment stoppen applicaties en agents met communiceren met een kaal localhost-endpoint en roepen ze in plaats daarvan de gateway aan via één uniforme API:

Die enkele verandering maakt Ollama bruikbaar voor een team:

• Toegangsbeheer. Verleen specifieke gebruikers, teams of virtuele accounts toegang tot het door Ollama ondersteunde model, en niets anders.
• Kostentracking en rate limits. Bekijk het verbruik per team en applicatie, en stel limieten in voordat de kosten oplopen.
• Guardrails. Voer PII-, geheimen- en prompt-injection-checks uit op verkeer van en naar het lokale model.
• Routing en fallback. Plaats Ollama en een gehost model achter één virtuele modelnaam, zodat je kunt uitwijken (failover) of verkeer kunt splitsen zonder de applicatiecode aan te raken.

Omdat de gateway provider-agnostisch en OpenAI-compatibel is voor meer dan 1.000 modellen, kun je een lokaal Ollama-model ook combineren met een vLLM-deployment en cloud-API's onder dezelfde interface. Dit sluit direct aan op portabiliteit van AI-agents. En aangezien TrueFoundry binnen je eigen VPC draait, blijft de privacy waarvoor je in de eerste plaats voor Ollama koos, end-to-end behouden.

Conclusie

Ollama is de snelste manier om een model lokaal te laten draaien, en qua privacy en kosten is het moeilijk te overtreffen. Het is simpelweg niet gebouwd als infrastructuur voor teams; dat is waar toegangsbeheer, kosteninzicht, guardrails en routing om de hoek komen kijken. Verbind Ollama als een self-hosted model met de AI Gateway en het behoudt zijn privacy en lage kosten, terwijl het alles krijgt wat een team nodig heeft om het in productie te laten draaien.

Ontdek hoe TrueFoundry van lokale modellen beheerde, team-ready infrastructuur maakt. Boek een demo of start gratis.