AWS har lanceret OpenAI-kompatibel API-support på Amazon SageMaker AI realtids-endpoints. Det omfatter en /openai/v1-sti, streaming og tidsbegrænsede bearer-tokens, plus et GitHub-notebook med deployment og kald. Ifølge AWS’ blog kan klienter som OpenAI SDK, LangChain og Strands Agents pege på et SageMaker-endpoint ved primært at skifte base-URL. Ingen SigV4 i klienten.

Kernen er enkel: routing sker på endpoint-navn i URL’en, og platformen returnerer svar uændret fra containeren. Jeres infrastruktur taler OpenAI-protokol – uden en ekstra proxy i midten.

Hvorfor det er relevant nu

Bruger I allerede OpenAI SDK, LangChain eller Strands, kan I ofte genbruge klientkoden. Skift base-URL, udsted et bearer-token, kør. Det sænker time-to-production og reducerer lock-in, fordi I kan teste og drifte i egen konto uden at omskrive app-logik.

Snilld: Vi flyttede et lille LangChain-agentflow hos en kunde på under en time. Det meste handlede om en stram security group, ikke kode.

Hvad AWS konkret har tændt for

SageMaker AI eksponerer /openai/v1 på realtids-endpoints, accepterer Chat Completions-requests og understøtter streaming. AWS beskriver, at routing sker via endpoint-navn i URL’en, og at svar returneres uændret fra containeren – inkl. streaming-format. Konsekvensen er klar: containeren skal levere OpenAI-kompatibelt output, som klienten forventer. Se AWS-bloggens afsnit “Overview”.

AWS angiver også, at OpenAI-kompatible endpoints er slået til for alle SageMaker AI-endpoints og inference components, der bruger de almindelige SageMaker AI-API’er og SDK’er.

Autentifikation med tidsbegrænsede tokens

Klienterne bruger tidsbegrænsede bearer-tokens i Authorization-headeren. Ifølge AWS-bloggens afsnit “Authentication with bearer tokens” genererer SageMaker Python SDK tokens, der kan være gyldige i op til 12 timer, baseret på jeres eksisterende AWS-legitimationsoplysninger. Notebooket viser generate_token-kaldet eksplicit.

from sagemaker.core.token_generator import generate_token
from datetime import timedelta

# Notebooket demonstrerer samme mønster
token = generate_token(region="eu-west-1", expiry=timedelta(minutes=5))

Det fjerner friktionen for frameworks, der ikke taler SigV4. Men tokens udløber, og læk giver kortvarig adgang. Hold TTL kort i produktion og automatisér rotation via secrets-store eller CI/CD.

Implementeringen i praksis

I skal bruge: en AWS-konto med rettigheder til at oprette SageMaker AI-endpoints, SageMaker Python SDK, OpenAI Python SDK, en model i S3 (AWS nævner fx Qwen3-4B) og relevante IAM-roller. AWS’ GitHub-notebook viser deployment og invoke-flow trin for trin.

Et typisk flow i fem trin: 1) Upload modelartefakter til S3 og beskriv container/inference-spec. 2) Opret endpoint – eller brug inference components for flere modeller bag ét endpoint. 3) Generér bearer-token via sagemaker.core.token_generator.generate_token. 4) Sæt OpenAI-klientens base_url til jeres regions /openai/v1-sti med endpoint-navn. 5) Send en Chat Completions-request og slå streaming til, hvis appen bruger det. Notebooket demonstrerer både deployment og kald.

Hvad “as is” svar betyder i praksis

Når platformen returnerer containerens svar uændret, får I fuld kontrol – og ansvaret med den. Streaming skal være OpenAI-kompatible server-sent events. Feltnavne og JSON-struktur skal være præcise. Test med de klientbiblioteker, I faktisk bruger (OpenAI SDK, LangChain), ikke kun curl.

IAM-tilladelser i minimum

AWS fremhæver disse handlinger som påkrævede for kald via bearer-tokens:

• sagemaker:CallWithBearerToken
• sagemaker:InvokeEndpoint

Minimalt policy-eksempel, klar til copy-paste:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sagemaker:CallWithBearerToken",
        "sagemaker:InvokeEndpoint"
      ],
      "Resource": "arn:aws:sagemaker:REGION:ACCOUNT_ID:endpoint/ENDPOINT_NAME"
    }
  ]
}

Udvid som nødvendigt til token-issuer og deployment-roller, men start småt og eksplicit.

En konkret mini-migration

Snilld: Reproducerbar kernenedslag for et LangChain-chatflow:

# 1) Generér kortlivet token
from sagemaker.core.token_generator import generate_token
from datetime import timedelta
token = generate_token(region="eu-west-1", expiry=timedelta(minutes=5))

# 2) Peg OpenAI-klienten på SageMaker
from openai import OpenAI
client = OpenAI(
    base_url="https://eu-west-1.sagemaker.aws/openai/v1",
    api_key=token
)

# 3) Kør Chat Completions (med streaming hvis ønsket)
with client.chat.completions.stream(model="ENDPOINT_NAME", messages=[{"role":"user","content":"Hej"}]) as stream:
    for event in stream:  # SSE-chunks
        pass

Det meste af tidsforbruget gik på netværk og skalering, ikke kode.

Drift, latency og omkostning

Når inference kører på egne GPU-instanser, skifter ansvaret. Latens kan falde, når data og brugere er i samme region (og evt. samme VPC). Til gengæld ejer I autoscaling, warm pools og cold starts. I betaler for instanser, ikke pr. token. Mulighed og risiko i samme pakke.

Start med få målepunkter: p95/p99-latens, stabilitet på SSE-streams over 1–2 minutter, og pris pr. 1.000 svar for både kold og varm drift. Aktivér SageMaker endpoint-metrics (invocations, model-latens, fejlrate) og korrelér med applikationslogs for at finde flaskehalse.

Faldgruber vi ser i felten

Netværk: private VPC-endpoints kræver egress/NAT/VPC endpoints eller en proxy for at nå /openai/v1 udefra. Vi oplevede en firewall, der klippede SSE efter 30 sekunder. Det lignede model-problem, men var netværk.

SigV4 er ude af klienten, men ikke af jeres platform. IAM-politikkerne skal være stramme, og kortlivede tokens skal logges og roteres. En lille issuer-service i platformlaget sparer tid senere.

Kompatibilitet er fin, men test features

AWS dokumenterer Chat Completions. Hvis I bruger udvidelser, så smoke-test dem:

• Function calling/tool-calls med længere kontekster
• Lange streaming-sessioner og afbrudshåndtering
• Eventuelle ikke-chat endpoints i jeres kode

Brug notebooket som skelet: byt model og prompts, sæt stream=True, og log event-rækkefølgen i klienten.

Multi-model og governance

Inference components giver flere modeller bag ét endpoint. Stærkt – men kræver styring: hvem må pege på hvilke komponenter, hvordan versionsstyrer I, og hvordan ruller I tilbage ved kvalitetsfald. Ellers ender I med en sen Slack-tråd og en uheldig routing.

To korte cases

Snilld: Case 1 – Et e-handels-team med et agentisk returflow i LangChain. De ville styre omkostning og holde data i egen VPC. Vi pegede agenten mod et SageMaker-endpoint på g5.xlarge og beholdt streaming. Integrationen var minimal. Det rigtige arbejde lå i autoscaling og at holde GPU’en varm. Billigere om natten, dyrere i spidsen – mere kontrol.

Snilld: Case 2 – En B2B-virksomhed med en finetunet Mistral til supportmakroer. De havde allerede en gateway, der talte OpenAI-protokol. Med bearer-tokens kom SageMaker på som ekstra backend uden SigV4-tilpasninger. Compliance sagde ja til “egen konto, audit-logs, kortvarige tokens” – med alarmer på fejlkald og lange svartider.

Hvad ledelser bør gøre

Kort og målbart:

• PoC 2 uger – Ejer: Eng lead. Scope: ét chatflow med streaming. Mål: p95 < 800 ms ved varm drift, <2% SSE-afbrydelser.
• Cost baseline 30 dage – Ejer: FinOps/MLOps. Scope: 2 instanstyper. Mål: pris pr. 1.000 svar (kold/varm) og break-even mod nuværende løsning.
• Governance-light – Ejer: Platform. Scope: modelkatalog, RBAC til endpoints, simpel rollback-proces. Mål: audit-log på 100% af kald.

Snilld anbefaler en FDE-lignende indsats første uge: én ingeniør tæt på jeres CI/CD, der får token-issuer, routing og observability på plads. Det flytter nålen hurtigere end tre statusmøder.

Tjekliste til teamet

• Deploy et test-endpoint via AWS’ GitHub-notebook.
• Sæt en token-issuer op med kort TTL, rotation og audit-logs.
• Kør latency- og stabilitetstests inkl. SSE i 1–2 minutter.
• Mål pris pr. 1.000 svar ved realistisk trafik (kold/varm drift).
• Aktivér endpoint-metrics, korrelations-id’er og fejlkoder i klienten.
• Etabler en enkel modelregistry med versionsnavne og adgangsroller.

Huller vi holder øje med

Vi mangler åbne benchmarks for latency/throughput på tværs af instanstyper og agent-workloads. AWS beskriver ikke en fuld opskrift på token-rotation/TTL under høj load. Vi vil også have klarhed over SigV4-kanttilfælde i administrative kald. Og tredjeparts-kompatibilitet er bred, men test nichefunktioner før I lover leverance.

Hvis streaming hakker, kig først på VPC-egress eller L7-proxy. Vi har hørt det som en knitren i højttaleren, men set det i firewall-reglerne.

Konklusion

AWS har leveret noget brugbart: en OpenAI-kompatibel sti på SageMaker AI, streaming og tidsbegrænsede tokens. For mange teams er vejen til produktion kort, uden at rive kodebasen op. Gevinsten i fleksibilitet og kontrol er reel – men kræver disciplin i drift og sikkerhed.

Vores råd: prøv det på et smalt flow, mål det hele, og få token-issuer og observability på plads tidligt. Forskellen mærker man først, når man sidder med det.

Kilder

• AWS blogindlæg: Announcing OpenAI-compatible API support for Amazon SageMaker AI endpoints – funktionalitet, /openai/v1, streaming, bearer-tokens (inkl. “Authentication with bearer tokens”), routing og dækning af endpoints og inference components.
• GitHub-notebook: sagemaker-inference-openai-api.ipynb – deployment og invocation, inkl. generate_token-eksempel.
• Snilld-manualbrief – vurderinger af time-to-production, vendor lock-in og praktiske implementeringsområder.