DienstenAITechnisch

Inference, onder de motorkap.

Hoe de API, de kaarten en het netwerk in elkaar zitten.

Deze pagina is voor wie de integratie bouwt. Welke endpoints er zijn, hoe we modellen kwantiseren, wat dedicated precies isoleert, en langs welke vier wegen je verkeer bij het model komt.

Plan een kennismaking Liever de beknopte versie? →

Chat, embeddings, transcriptieStreaming en tool callingGeen logging van promptsTLS, WireGuard, cross-connect, VRFVerwerking in BIT-2C, Ede

Compatibel is niet hetzelfde als identiek.

Onze API volgt het OpenAI-schema voor chat completions, embeddings en audiotranscriptie, met streaming en tool calling. Je bestaande client werkt na het wijzigen van de basis-URL. Wat niet hetzelfde is: de modellen erachter zijn open modellen tot ruwweg 30 miljard parameters, de context is wat het model aankan, en parameters die alleen voor een specifiek cloudmodel bestaan, negeren we. Dat zeggen we liever vooraf dan dat je het in productie ontdekt.

Wat je krijgt

Endpoint en sleutels

Een endpoint per omgeving en sleutels per toepassing, die we op je verzoek vervangen of intrekken. Bij dedicated een endpoint dat alleen in jouw VRF bestaat, als je dat wilt.

Modelselectie met versies

Elke modelnaam wijst naar een vaste versie en kwantisatie. Een nieuwe versie krijgt een nieuwe naam; jij kiest wanneer je overstapt.

Verbruik en limieten

Tokens per model en per sleutel, en limieten die we met je instellen, zodat een loop in een script geen verrassing wordt.

Afspraken op papier

Geen training, geen opslag van prompts: in het addendum bij je contract en schriftelijk bevestigd in de verwerkersovereenkomst.

De code om te beginnen staat hieronder; de rest bespreek je met een engineer, niet met een ticketformulier.

Hands-on

Twee regels wijzigen, de rest blijft staan.

Een chat completion tegen ons endpoint, met streaming aan. Het enige dat anders is dan bij een cloud-API: de basis-URL en de modelnaam.

Verzoek

# Bestaande OpenAI-client, alleen de base_url wijzigt
from openai import OpenAI

client = OpenAI(
    base_url="https://inference.example.nl/v1",
    api_key="sk-…",
)

reply = client.chat.completions.create(
    model="mistral-small-3.2",
    messages=[{"role": "user",
               "content": "Vat deze offerte samen in drie zinnen."}],
    stream=True,
)

Antwoord

$ curl -s https://inference.example.nl/v1/models \
    -H "Authorization: Bearer $API_KEY" | jq -r '.data[].id'
mistral-small-3.2
gemma-3-27b
gpt-oss-20b
eurollm-9b
multilingual-e5-large
whisper-large-v3

$ curl -s https://inference.example.nl/v1/embeddings \
    -H "Authorization: Bearer $API_KEY" \
    -d '{"model": "multilingual-e5-large", "input": "Wat is colocatie?"}' \
    | jq '.data[0].embedding | length'
1024

Embeddings en transcriptie gaan via dezelfde client; alleen het pad en het model verschillen.

Onder de motorkap

Wat er tussen je verzoek en het antwoord zit.

Zeven dingen die je wilt weten voordat je erop bouwt.

API: Chat, embeddings, transcriptie, streaming
Chat completions met streaming, tool calling en JSON-output, embeddings voor RAG en audiotranscriptie. Dezelfde paden en velden als het OpenAI-schema; parameters die alleen voor een specifiek cloudmodel bestaan, worden genegeerd.
Kwantisatie: Minder bits, gemeten kwaliteit
Modellen draaien waar dat zinvol is in een gekwantiseerde variant, zodat context en doorvoer op de kaart passen. Per model staat erbij welke variant het is. Wil je volle precisie op dedicated, dan rekenen we uit wat dat kost aan context en snelheid.
Isolatie: Dedicated is echt dedicated
Bij dedicated draait je model op kaarten die aan niemand anders zijn toegewezen, in een eigen proces met eigen geheugen. Geen gedeelde batch met andere klanten, dus ook geen gedeelde wachtrij en geen gedeelde KV-cache.
Logging: Prompts worden niet gelogd
De inference-laag logt metadata: tijdstip, model, aantal tokens, latency, statuscode. De inhoud van prompts en antwoorden wordt niet weggeschreven, ook niet in debug-logs. Dit is de technische kant van wat in het addendum staat.
Meting: Stroom per kaart en per server
Het verbruik van de GPU's en de server wordt gemeten, toegerekend naar tokens bij gedeeld en naar je kaarten bij dedicated, en aangevuld met het aandeel van het datacenter via de PUE van onze hal. Op aanvraag in een maandrapport.
Onderhoud: Updates in een onderhoudsvenster
Modelversies, drivers en de inference-laag updaten we in een onderhoudsvenster dat we vooraf aankondigen. Een nieuwe modelversie krijgt een nieuwe naam naast de oude; jij bepaalt wanneer je client overstapt.
MCP: Gereedschap in je eigen omgeving
Het model kan MCP-tools aanroepen die in je eigen omgeving draaien, bijvoorbeeld tegen de API van een FortiGate of UniFi Dream Machine Pro. Standaard alleen-lezen met een eigen, intrekbaar account; een wijziging alleen na goedkeuring van een mens. Het verkeer kan volledig over een cross-connect of privé-VRF lopen.

Toegang

Vier wegen naar het model.

Het endpoint staat in BIT-2C in Ede. Hoe je verkeer daar komt, kies je per toepassing; de vier wegen kunnen naast elkaar bestaan.

01Internet
TLS over het publieke internet
Het eenvoudigst: een HTTPS-endpoint met een sleutel. Je verkeer gaat versleuteld over internet, maar het gaat wél over internet. Geschikt om te beginnen en voor toepassingen zonder gevoelige inhoud.
02WireGuard
Een tunnel naar je eigen omgeving
Een WireGuard-tunnel tussen je omgeving en ons netwerk, zodat het endpoint niet publiek bereikbaar is en alleen jouw peers erbij kunnen. Het verkeer gaat nog steeds over internet, maar het endpoint staat er niet meer open.
03Cross-connect
Je servers in hetzelfde datacenter
Je servers in colocatie bij ons in BIT, met een cross-connect naar de inference. Model, vectordatabase en applicatie in hetzelfde gebouw; het verkeer gaat niet over het internet en er zijn geen egress-kosten.
04Privé-VRF
Over ons EVPN-netwerk, vanaf je andere locaties
Een privé-VRF op onze EVPN-VXLAN-fabric, gerouteerd naar het endpoint. Zo bereik je het model vanuit je rack in een ander BIT-datacenter of op een van onze corelocaties, zonder dat het verkeer ons eigen netwerk verlaat.

Zo werken wij

Van sleutel tot productie.

Intake en modelkeuze
Taak, data, verwachte tokens per dag en de latency die je nodig hebt. Daaruit volgt een model, een kwantisatie en de keuze tussen gedeeld en dedicated.
Addendum en verwerkersovereenkomst
Verwerkersovereenkomst en het addendum over training en opslag, getekend voordat er productiedata naar het endpoint gaat.
Toegang inrichten
TLS-sleutel, WireGuard-peer, cross-connect of VRF. Bij een VRF lopen we de routering met je na en testen we vanaf jouw kant.
Productie
Limieten instellen, verbruik zichtbaar maken, en een engineer die je belt als er een modelversie verandert.

Een proefopstelling op de gedeelde capaciteit, met testdata, kan voordat je tekent.

Voor wie

Deze pagina is voor je als je:

De integratie zelf bouwt en wilt weten wat compatibel precies betekent
Een RAG-pipeline ontwerpt en embeddings en het chatmodel in één omgeving wilt
Moet kunnen uitleggen wat er gelogd wordt en wat niet
Het verkeer via een VRF of cross-connect wilt laten lopen en niet over internet

Waarom Xyphen IT

Gebouwd door netwerkmensen.

EVPN-VXLAN-fabric en privé-VRF's zijn ons dagelijks werk, geen extra optie
Eigen DDoS-filtering op de edge, ook voor je endpoint als dat publiek bereikbaar is
Corelocaties in NorthC en Nikhef, rackspace in alle BIT-datacenters in Ede
Een engineer aan de lijn, ook over kwantisatie en context

Inference is bij ons een dienst op het netwerk, niet een losse cloud ernaast.

Een vraag over de API of het netwerk?

Bel of mail een engineer. Wil je een voorstel, vertel dan je taak en je verwachte verbruik; je krijgt een opzet met model, vorm en toegang.

Plan een kennismaking of bel 085 303 9420