Ollama hosten op een VPS: veilig en zelfbeheerd

Wat u bouwt

Een enkel open-weight taalmodel dat draait op een server in uw eigen beheer, benaderbaar via een HTTP API en, indien gewenst, een chatpagina in uw browser. Ollama is de component die het model downloadt, in het geheugen laadt en verzoeken afhandelt op http://127.0.0.1:11434. De installatie vereist slechts één commando. De complexe aspecten bevinden zich elders: het selecteren van een model dat uw VPS daadwerkelijk in het RAM kan vasthouden, en het voorkomen dat u per ongeluk een niet-geauthenticeerde inference-server publiceert naar het gehele internet.

Eerst twee belangrijke waarschuwingen. Een VPS die alleen op CPU draait, voert kleine modellen traag uit, en er is geen ingebouwde authenticatie voor de API aanwezig. Beide punten worden hieronder in detail behandeld, aangezien dit de gebieden zijn waar gebruikers vaak tegen problemen aanlopen.

De realiteit van dimensionering in cijfers

Het geheugengebruik van een model is ongeveer gelijk aan de bestandsgrootte, plus ongeveer een gigabyte aan runtime-overhead, plus extra ruimte voor het contextvenster. De standaard-tags van de meeste populaire Ollama-modellen, waaronder llama3.2:3b, llama3.1:8b en mistral:7b, zijn 4-bit gekwantiseerd (gelabeld als Q4_K_M). Dit kost ongeveer een halve gigabyte aan RAM per miljard parameters. Niet elke standaard is Q4: zeer kleine modellen zoals smollm2:135m worden geleverd in 16-bit. Controleer daarom de kwantisatielijn op de bibliotheekpagina van een model voordat u gaat rekenen. De berekening is eenvoudig en bepaalt alles. Die laatste term stelt u zelf in: het verhogen van num_ctx boven de kleine standaardwaarde van Ollama creëert ruimte voor langere prompts, maar vergroot de KV-cache in het RAM. Bepaal daarom de contextlengte voordat u beoordeelt of een model past.

Een 3B-model zoals llama3.2:3b is een download van ~2 GB en vereist ongeveer 4 GB vrij RAM om te draaien. Een 7B- of 8B-model zoals mistral:7b of llama3.1:8b is ~5 GB op schijf en vereist ongeveer 8 GB RAM, waarbij 16 GB comfortabeler is. Een 13B- of 14B-model vereist ongeveer 16 GB. Alles in het bereik van 30B tot 70B vereist een server met veel RAM of, realistischerwijs, een GPU. Op een CPU-gebaseerde VPS past het ofwel niet, of het antwoordt zo traag dat het onbruikbaar is.

Dan de snelheid, want dit is het onderdeel dat mensen onderschatten. CPU-inferentie wordt beperkt door geheugenbandbreedte, niet door kloksnelheid, en een gedeelde vCPU-VPS heeft een bescheiden bandbreedte. Verwacht snelheden van enkele tot lage dubbele cijfers aan tokens per seconde: een 7-8B Q4-model haalt wellicht 4 tot 10 tokens per seconde, een 3B-model 10 tot 25. Een GPU is ongeveer een orde van grootte sneller. Dit zijn bewust ruwe cijfers; de eerlijke methode is om uw eigen server te meten, wat in de onderstaande run-stap wordt uitgelegd. Vertrouw op uw eval rate, niet op een getal in een artikel, inclusief dit artikel.

De praktische conclusie: kleine gekwantiseerde modellen op een CPU zijn oprecht nuttig voor het opstellen, samenvatten en classificeren van teksten, mits u het tempo accepteert. Voor alles wat groter of sneller moet zijn, moet u budgetteren voor een GPU-instantie. Als u liever ziet hoe deze berekening van begin tot eind wordt toegepast op een specifiek model, behandelt het draaien van Nemotron 3.5 Lightning op een VPS welke tag u moet ophalen, het RAM dat het daadwerkelijk nodig heeft en of een CPU-only configuratie voldoet.

Om een specifiek model af te wegen tegen een specifieke server, schat u hier het geheugengebruik:

Ollama installeren

Er zijn twee schone methoden. Het officiële script is het eenvoudigst op een kale VPS:

curl -fsSL https://ollama.com/install.sh | sh

Dit maakt een systeemgebruiker genaamd ollama aan, installeert het binaire bestand naar /usr/local/bin/ollama en registreert een systemd-service genaamd ollama.service die bij het opstarten wordt geactiveerd en bindt aan 127.0.0.1:11434. Controleer of deze actief is:

systemctl status ollama
ollama --version

Als u al met Docker werkt, gebruik dan de container:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

Let op het 127.0.0.1:-voorvoegsel bij de poorttoewijzing. Dit bindt de poort uitsluitend aan localhost. Het gebruik van -p 11434:11434 in plaats daarvan publiceert de poort op alle interfaces; dit is de fout waarvoor in de beveiligingssectie wordt gewaarschuwd. Kies één installatiemethode; voer het script en de container niet tegelijkertijd uit, anders strijden twee processen om dezelfde poort.

Uw eerste model ophalen en uitvoeren

ollama pull llama3.2:3b
ollama run llama3.2:3b

pull downloadt de modellagen naar de schijf (ongeveer 2 GB voor dit model). run laadt deze in het geheugen en opent een >>>-prompt. Stel een vraag. Het genereren van het eerste token kan enkele seconden duren terwijl de gewichten van de schijf naar het RAM worden geladen; daarna wordt het antwoord gestreamd. Typ /bye om de chat te verlaten; Ollama blijft op de achtergrond actief.

Bekijk wat er geladen is en hoe het in het geheugen past:

ollama ps

De kolom PROCESSOR geeft de feitelijke status weer. 100% CPU betekent dat er geen GPU wordt gebruikt, wat de oorzaak is van de traagheid. Meet de werkelijke snelheid met de verbose-vlag:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

De regel eval rate die aan het einde wordt afgedrukt, toont het aantal tokens per seconde op deze hardware. Dit is het getal waarop u uw planning moet baseren.

Waar modellen worden opgeslagen en hoeveel schijfruimte u moet aanschaffen

Modellen die door het script zijn geïnstalleerd en als service worden uitgevoerd, bevinden zich in de home-directory van de gebruiker ollama:

sudo du -sh /usr/share/ollama/.ollama/models

Wanneer u ze interactief als uw eigen gebruiker uitvoert, staan ze in ~/.ollama/models. In de container bevinden ze zich in het named volume ollama. Dit is van belang omdat gekwantiseerde gewichten snel oplopen: een 3B-model is ~2 GB, een 7-8B-model is ~5 GB en een 14B-model is ~9 GB. Als u vier modellen downloadt om ze te vergelijken, heeft u ongemerkt 20 GB verbruikt. Bepaal de schijfgrootte op basis van de modellen die u wilt bewaren en verwijder de rest met ollama rm <model>. Als op dezelfde VPS al een applicatie draait die veel ruimte in beslag neemt, zoals PhotoPrism of Immich met een fotobibliotheek, trek dit dan eerst af van de vrije ruimte en beschouw het restant als uw werkelijke budget voor modellen.

Draai het als een service die u beheert

Het installatiescript heeft ollama.service al geregistreerd, waardoor het na een herstart automatisch opstart zonder extra werk. De instelling die het overwegen waard is, is hoe lang een model in het geheugen blijft, en bij sommige configuraties het bind-adres. Beide plaatst u in een systemd drop-in, zodat een upgrade van Ollama deze niet overschrijft:

sudo systemctl edit ollama.service

Voeg dit toe onder de [Service]-header die de editor u toont:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE bepaalt hoe lang een model in het geheugen blijft na het laatste verzoek (standaard 5 minuten). Verhoog deze waarde op een systeem dat u de hele dag bevraagt om te voorkomen dat de gewichten telkens opnieuw worden geladen; stel het in op 0 op een systeem met beperkt geheugen om RAM direct vrij te maken zodra een verzoek is voltooid. Als u wilt dat een model voor onbepaalde tijd in het geheugen blijft in plaats van voor een vast venster, behandelt een Ollama-model permanent geladen houden het keep_alive-veld per verzoek en hoe u de gewichten direct na een herstart weer warm kunt hebben in plaats van bij het eerste trage verzoek. systemctl edit herlaadt de unit-bestanden voor u, dus herstart de service om de wijziging toe te passen:

sudo systemctl restart ollama

Het belangrijkste beveiligingspunt

Standaard bindt Ollama aan 127.0.0.1:11434, waardoor alleen processen op de VPS zelf de service kunnen bereiken. Deze standaardinstelling is correct. Behoud deze.

De API heeft geen authenticatie. Geen enkele. Er is geen API-sleutel, geen login en geen rate limit. De enige allow-list die aanwezig is, OLLAMA_ORIGINS, controleert alleen welke browser-origins de API mogen aanroepen (CORS); dit doet niets om curl of een script op een andere machine tegen te houden. Iedereen die poort 11434 kan bereiken, kan elk model uitvoeren dat u heeft binnengehaald, nieuwe modellen downloaden, ze verwijderen en uw CPU of GPU voor onbepaalde tijd volledig belasten. Scanners zoals Shodan indexeren duizenden open Ollama-instanties, en een blootgestelde instantie wordt binnen enkele uren gevonden en misbruikt.

Dit is dus de enige fout die u nooit mag maken: stel OLLAMA_HOST=0.0.0.0 niet in en open poort 11434 niet in uw firewall. Dat stelt een niet-geauthenticeerde inference-server bloot aan het gehele internet. Geen enkele configuratie maakt een rauwe 11434-op-0.0.0.0 veilig, omdat geen van de gedocumenteerde instellingen van Ollama authenticatie toevoegt aan de lokale API, en een origin allow-list is geen login. Dit is een regel die specifiek geldt voor deze service, geen verbod op het ooit openen van een poort: een zelfgehoste RustDesk-relay voor remote desktop moet publiek verkeer accepteren om zijn werk te kunnen doen, en dat rechtvaardigt het door eigen sleutelgebaseerde authenticatie en een korte, gedocumenteerde lijst met poorten te gebruiken, wat precies is wat Ollama niet heeft.

Er zijn drie veilige manieren om het model vanaf een andere locatie dan de server zelf te bereiken:

• Houd het lokaal. Als de enige aanroeper een ander programma op dezelfde VPS is, een cron-script, een bot, of een MCP-server die uw tools met het model verbindt, laat de bind dan op 127.0.0.1 staan en laat dat programma http://127.0.0.1:11434 aanroepen. Niets is blootgesteld en er is verder niets nodig.
• Bereik het via een privétunnel. Plaats de VPS op een WireGuard VPN die u zelf host, stel OLLAMA_HOST in op het tunneladres (bijvoorbeeld 10.8.0.1, niet 0.0.0.0), en alleen VPN-peers kunnen verbinding maken. Het publieke internet ziet nog steeds niets op poort 11434.
• Plaats een authenticerende reverse proxy ervoor. Beëindig TLS en vereis een wachtwoord of token bij nginx, Traefik of Caddy, en proxy vervolgens naar 127.0.0.1:11434. Ollama behoudt zijn localhost-bind; de proxy is het enige dat luistert op de publieke poort. Dit is dezelfde opzet als het plaatsen van een Let's Encrypt-certificaat op nginx voor een lokale service.

De reverse-proxy-optie is precies wat de chat-UI u hierna biedt, inclusief een echte login.

Een chat-UI toevoegen met Open WebUI, achter TLS

Open WebUI is een zelfgehoste chatinterface. Draai deze in Docker en laat deze verwijzen naar de lokale Ollama:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

De --network=host-vlag is het belangrijke detail op een Linux VPS. Deze plaatst de container in de netwerk-namespace van de host, waardoor 127.0.0.1 binnen de container de eigen loopback van de host is en de container Ollama bereikt op 127.0.0.1:11434 zonder dat Ollama op een andere interface hoeft te luisteren. Het bridge-netwerk-recept dat u elders zult zien, --add-host=host.docker.internal:host-gateway met OLLAMA_BASE_URL=http://host.docker.internal:11434, werkt hier niet: die naam resolve naar de Docker-bridge-gateway, en een service die op 127.0.0.1 op de host is gebonden, is niet bereikbaar via de bridge. Open WebUI blijft daarom hangen met de melding dat het geen verbinding kan maken met Ollama.

Het nadeel van host-networking is dat Open WebUI nu op poort 8080 van de host luistert op elke interface; elke -p-mapping wordt genegeerd en Docker geeft hiervoor een waarschuwing. Sluit daarom 8080 af op zowel de host als de firewall van de provider en laat de TLS-reverse-proxy de enige publieke ingang zijn. Bij het eerste bezoek vraagt Open WebUI u om een beheerdersaccount aan te maken; dat account is uw authenticatielaag, dus kies een sterk wachtwoord.

Om de chat vanaf uw laptop via HTTPS te openen, plaatst u een TLS-reverse-proxy voor 127.0.0.1:8080. Als u al meerdere Docker-apps op de server routeert, is Traefik met automatische TLS voor meerdere apps de meest overzichtelijke oplossing: één label-blok geeft het certificaat uit en routeert chat.example.com naar Open WebUI. Diezelfde label-per-app-routering is wat elke andere browser-frontend op de server zal gebruiken, of het nu gaat om een statusdashboard of iets speelsers zoals Halcyon, dat een Jellyfin-bibliotheek presenteert als een videotheek uit de jaren 90, elk op een eigen hostnaam achter een eigen login. De regel uit de beveiligingssectie blijft van kracht: de proxy beheert de publieke poort en de login, terwijl Ollama op localhost blijft en de eigen 8080 van Open WebUI achter de firewall blijft.

Gebruik het OpenAI-compatibele eindpunt in uw code

Ollama ondersteunt een subset van de OpenAI chat API op /v1, waardoor de meeste OpenAI-clientbibliotheken werken na het aanpassen van twee zaken: de base URL en een willekeurige API-sleutel.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

De api_key is vereist door de clientbibliotheek, maar wordt door Ollama genegeerd; elke willekeurige string volstaat dus. model moet een modelnaam zijn die u reeds heeft binnengehaald; een onbekende naam resulteert in een 404-foutmelding met model 'x' not found. Een eenvoudige curl-aanroep werkt op dezelfde manier:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

Op deze wijze koppelt u het model ook aan agent- en editor-tools. Als u al op de server ontwikkelt, kan een lokaal model scripts en plugins ondersteunen, naast Claude Code draaiend op de VPS binnen tmux. Hierdoor houdt u goedkoop, privaat conceptwerk buiten een betaalde API, terwijl het zware redeneerwerk wordt uitgevoerd door een gehost model.

Foutmodi, met de exacte tekst die u zult zien

Het proces wordt "Killed" tijdens het genereren. U start een groot model en de terminal toont Killed, of het serverlogboek (journalctl -u ollama) toont een regel die begint met llama-server process has terminated. Dit is de formulering in Ollama 0.40.7, gecontroleerd op 21 oktober 2026; oudere releases toonden llama runner process has terminated: signal: killed. De Linux OOM-killer heeft het proces beëindigd omdat het model meer RAM nodig had dan beschikbaar is. Bevestig de oorzaak met sudo dmesg | grep -i oom, waar u een regel ziet zoals Out of memory: Killed process .... De oplossing is een kleiner of sterker gekwantiseerd model, llama3.2:3b in plaats van een 13B, of het toevoegen van swap zodat een belasting die net boven het fysieke RAM uitkomt langzaam doorgaat in plaats van te crashen. Swap verandert een directe crash in een traag antwoord; het maakt een 70B-model niet bruikbaar op 4 GB. De beëindiging is stil tenzij u de terminal in de gaten houdt. Op een server die u op afstand beheert, kunt u een OnFailure=-unit koppelen aan ollama.service die berichten stuurt naar een ntfy-server die u zelf host voor pushmeldingen. Zo wordt u direct op de hoogte gesteld wanneer het proces stopt, in plaats van dat u dit pas bij de volgende aanvraag ontdekt.

Ollama weigert het model te laden. De aanvraag mislukt direct met een foutmelding in plaats van te crashen, en het serverlogboek registreert model is too large for system memory (Ollama 0.40.7, gecontroleerd op 21 oktober 2026). Oudere releases toonden Error: model requires more system memory (X GiB) than is available (Y GiB) direct bij de prompt. Dit is de beleefde versie van de bovenstaande crash: Ollama heeft de berekening uitgevoerd en is gestopt in plaats van de OOM-killer het werk te laten doen. Kies een model waarvan de vereiste onder uw vrije RAM-geheugen ligt (controleer dit met free -h), verklein de contextlengte of stap over naar een grotere VPS. Geen enkele vlag zorgt ervoor dat het model past; het geheugen is fysiek beperkt.

Het eerste token duurt erg lang, daarna gaat het goed. Een koud model geeft vijf tot dertig seconden geen output en streamt daarna normaal. Die pauze is het laden van de gewichten vanaf de schijf naar het RAM voor de eerste keer, en trage opslag verergert dit. Eenmaal geladen blijft het model in het geheugen voor de duur van OLLAMA_KEEP_ALIVE, waardoor de tweede prompt direct wordt beantwoord. Als die eerste laadtijd een time-out in het aanroeppad overschrijdt, krijgt u een foutmelding in plaats van een traag antwoord. Het achterhalen welke laag de context deadline exceeded rapporteert vertelt u of de client, de proxy of de belasting zelf ongeduldig werd. Verhoog die waarde als de pauzes storend zijn en gebruik ollama ps om te zien of een model momenteel geladen is.

Alles is simpelweg traag. Tien tokens per seconde of minder, zonder enige foutmelding. Dit is CPU-inferentie die precies doet wat CPU-inferentie doet. ollama ps toont 100% CPU, wat betekent dat er geen GPU aanwezig is. Dit is geen bug en geen instelling verandert een CPU in een GPU, omdat de belangrijkste beperking de geheugenbandbreedte is. Eén instelling is echter het testen waard op een VM: Ollama kiest het aantal threads op basis van de fysieke cores die het detecteert, en een hypervisor kan deze onjuist rapporteren. Probeer in een ollama run --verbose-sessie /set parameter num_thread 4 (of uw vCPU-aantal), voer dezelfde prompt opnieuw uit en behoud de waarde die de beste eval rate geeft. Gebruik daarnaast een kleiner model, accepteer de snelheid of stap over naar een GPU-instantie, en meet uw werkelijke snelheid met --verbose voordat u besluit dat er iets kapot is. Wanneer het wachten wordt veroorzaakt door de lengte van het antwoord in plaats van de snelheid, zorgt het beperken van het antwoord met num_predict ervoor dat een model dat graag uitweidt geen minuten besteedt aan tokens die u toch niet ging lezen.

Connection refused vanaf een andere machine. Vanaf uw laptop toont een actuele curl (8.23.0, gecontroleerd op 21 oktober 2026) curl: (7) Failed to connect to <ip>:11434 after <n> ms: Could not connect to server, en de curl 8.5.0 die Ubuntu 24.04 meelevert toont curl: (7) Failed to connect to <ip> port 11434 after <n> ms: Couldn't connect to server. De woorden "Connection refused" verschijnen alleen als u -v toevoegt, in een regel die connect to <ip> port 11434 from ... failed: Connection refused leest. Dit werkt zoals ontworpen: Ollama luistert alleen op localhost. "Los dit niet op" door te binden aan 0.0.0.0, wat precies de blootstellingsfout is die hierboven wordt beschreven. Benader het model via de VPN of via de authenticerende proxy.

U heeft 11434 blootgesteld aan het internet. Als u OLLAMA_HOST=0.0.0.0 heeft ingesteld, de firewall heeft geopend en nu model-pulls ziet die u niet bent gestart of de CPU op 100% ziet door onbekende clients, dan bent u gevonden en misbruikt. Dit is de belangrijkste fout, geen randgeval. Bind opnieuw aan 127.0.0.1 of het VPN-adres, sluit 11434 in de firewall en plaats authenticatie ervoor. Ga ervan uit dat alles wat bereikbaar was op dat adres terwijl het openstond, door vreemden is bevraagd.

Back-ups en upgrades

Er is weinig status te verliezen. De modellen kunnen opnieuw worden gedownload, dus de enige zaken die het back-uppen waard zijn, zijn het datavolume van Open WebUI, accounts, chatgeschiedenis, instellingen en eventuele door u geschreven systemd drop-ins. Maak een back-up van het volume met een tijdelijke container:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

Upgrade Ollama door het installatiescript opnieuw uit te voeren; upgrade Open WebUI met docker pull ghcr.io/open-webui/open-webui:main, gevolgd door het opnieuw aanmaken van de container. Een opmerking over schijfruimte voor de 0.40-reeks: Ollama 0.40.2 begon op de achtergrond met het upgraden van modellen die met eerdere versies waren binnengehaald en bewaart de originele kopieën als back-up. Deze nemen extra schijfruimte in beslag totdat ze worden verwijderd. Versie 0.40.3 (11 oktober 2026) heeft die achtergrondupgrade gepauzeerd. Controleer df -h na een upgrade en lees de release notes voor het commando dat deze back-ups verwijdert. Pin niets voor de lange termijn: zowel de modelkwaliteit als de runtime ontwikkelen zich snel. Lees daarom de release notes en voer zelf benchmarks uit op uw eigen systeem in plaats van te vertrouwen op de cijfers van het vorige kwartaal.

FAQ

Kan ik daadwerkelijk een LLM draaien op een VPS zonder GPU?

Ja, binnen bepaalde grenzen. Kleine gekwantiseerde modellen in de range van 3B tot 8B draaien op een CPU en zijn bruikbaar voor het opstellen van teksten, samenvatten en classificatie, zij het langzaam, met een snelheid van enkele tot tientallen tokens per seconde op een gedeelde vCPU. Alles vanaf 13B is extreem traag of past simpelweg niet in het RAM. Voor echte snelheid of grotere modellen heeft u een GPU-instantie nodig.

Hoeveel RAM heeft elk model nodig?

Een ruwe vuistregel voor de 4-bit (Q4) tags die de meeste populaire modellen standaard gebruiken: ongeveer 0,5 GB RAM per miljard parameters voor de gewichten, plus ongeveer 1 GB overhead en wat extra ruimte voor de context. Een 3B-model vereist dus ongeveer 4 GB vrije ruimte, een 7-8B-model ongeveer 8 GB en een 14B-model ongeveer 16 GB. Controleer uw beschikbare geheugen met free -h en houd rekening met het besturingssysteem en andere processen op de server.

Is de Ollama API beveiligd met authenticatie?

Nee. Ollama heeft geen ingebouwde authenticatie, API-sleutels of rate limiting; iedereen die poort 11434 kan bereiken, heeft volledige controle. De instelling OLLAMA_ORIGINS beperkt alleen welke browser-origins de API mogen aanroepen, niet wie er verbinding kan maken. Dit is precies de reden waarom de service standaard bindt aan 127.0.0.1 en waarom u poort 11434 nooit direct mag blootstellen aan 0.0.0.0 op het internet. Benader de service lokaal, via een privé-VPN of via een reverse proxy die een inlogprocedure toevoegt.

Hoe voeg ik een web-chatinterface toe?

Draai Open WebUI in Docker met --network=host zodat het de loopback van de host deelt en de lokale Ollama-instantie bereikt op http://127.0.0.1:11434. Plaats vervolgens een TLS-reverse proxy voor poort 8080 voor toegang vanaf uw laptop. Houd 8080 gesloten in de firewall, zodat de proxy de enige publieke ingang is. Het beheerdersaccount van Open WebUI voorziet in de inlogfunctionaliteit; het wachtwoord stelt u in bij de eerste keer opstarten.

Hoe roep ik het model aan vanuit mijn eigen applicatie?

Gebruik het OpenAI-compatibele eindpunt op http://127.0.0.1:11434/v1. Wijs elke OpenAI SDK naar die basis-URL, geef een willekeurige string op als API-sleutel (aangezien deze wordt genegeerd) en stel model in op de naam van een model dat u heeft binnengehaald. Bestaande OpenAI-code werkt doorgaans zonder wijzigingen, afgezien van de basis-URL en de sleutel.