Lad os være ærlige. Det her har manglet. AWS bekræfter, at SageMaker AI fra november 2025 giver native bidirectional streaming til real-time inference. Samtidig viser de et konkret workflow med vLLMs Realtime API og Mistrals Voxtral‑Mini‑4B‑Realtime‑2602, der kører som fuldt managed speech‑to‑text. Det er ikke bare endnu en demo. Det gør drift langt mere praktisk.
Hvorfor nu? Fordi request‑response bryder sammen, når du skal transskribere samtaler, mens de sker. Ingen gider vente på fuld upload, før teksten tikker ind. Vi har siddet med headsets i et møderum i Aarhus og målt den klæge forsinkelse. Den dræber flowet. Bidirectional streaming er medicinen.
Hvad er nyt, kort fortalt
SageMaker AI får en HTTP\/2‑baseret bidirectional streaming‑forbindelse på port 8443, der holder en vedvarende kanal åben. Klienten kan strømme lyd ind, mens transkription flyder tilbage. vLLM leverer WebSocket‑enden via et \/v1\/realtime‑endpoint i containeren. AWS’ eksempel viser Mistrals Voxtral‑Mini‑4B‑Realtime‑2602 deployeret i en vLLM‑container, så du står med en managed realtids STT‑tjeneste.
Pointen er, at AWS håndterer protokoloversættelsen mellem HTTP\/2 event stream udadtil og WebSocket ind mod containeren. Du slipper for at bygge broen selv. Det er stærkt til POC. Men det skjuler også driftsspecifik adfærd, du bør kende før produktion.
Sådan spiller protokollerne sammen
Klienten opretter en persistent HTTP\/2‑forbindelse til SageMaker‑endpointet. Inde i AWS lander trafikken som en WebSocket i vLLMs Realtime API. Audio pakkes typisk som base64‑enkodede PCM16‑chunks, ofte 16 kHz mono. Tokens flyder tilbage løbende. Et kredsløb i begge retninger uden at lukke forbindelsen.
Vi har set teams fejle i detaljerne. For store audio‑chunks giver jitter; for små chunks øger overhead. Find jeres sweet spot. Start med 20–40 ms pr. chunk, mål, justér. Husk også resampling. Vi fik mono ud, men indgangslyden var 48 kHz stereo fra en lidt for ivrig softphone. Det blev grimt, før vi normaliserede det.
Model og serving, hvor latency faktisk barberes
vLLM er bygget til høj gennemløb og effektiv hukommelse. Continuous batching og avanceret scheduling holder GPU’en varm, så du ikke betaler i latenstid for hver forespørgsel. I realtidskonteksten hjælper en teknik, AWS fremhæver: piecewise CUDA graph execution. Mindre kernel‑launch overhead, mere tid på selve inferensen. Resultatet er lavere per‑token‑latency.
Deployment‑eksemplet med Voxtral‑Mini‑4B‑Realtime‑2602 er praktisk, fordi modellen er kompakt og designet til streaming. Vi testede vLLM i et POC‑miljø og så klar throughput‑gevinst med continuous batching og paged attention. Men en faldgrube dukkede op: tuning af CUDA 13.x og driverstacken, før piecewise‑opsætningen er stabil. Ikke en blocker, bare et punkt på to‑do.
Arkitekturvalg, ikke kun smag
Du kan køre fuldt managed endpoint i SageMaker. Det er hurtigt at komme i gang. Netværksmæssigt får du typisk region‑rundtur, som i Norden kan være fornuftig, men ikke altid sub‑200 ms end‑to‑end. Hybrid eller edge giver lavere latency og mere kontrol, men koster styring og drift. Vores praksis: vælg managed til generiske scenarier; gå hybrid, når data, latency eller jurisdiktion kræver det.
Backpressure er en nøglebeslutning. Når klienten taler hurtigere, end serveren kan tygge—hvad sker der så? SageMaker håndterer forbindelser og health checks, men detaljer om backpressure‑politik og retry‑semantik er ikke fuldt dokumenteret offentligt. Test det. Simulér netværkstab, send bursts, drop pakker. Vi blev i tvivl under et testforløb, da to samtidige streams fik forskellig behandling ved spikes.
State management under streaming
Kontinuerlig streaming er ikke bare en lang request. Du har speaker turns, delvise hypoteser og end‑of‑segment‑signaler. Hvor lægger du state, hvis forbindelsen blinker? I containeren, i en session‑cache, i en ekstern store. Vi har haft held med en session‑token i metadata og letvægts‑state i Redis, så vi kan genskabe konteksten efter et kort udfald.
Hold også øje med autoscaling. Skalering på aktive forbindelser og GPU‑udnyttelse giver mere retvisende skalering end klassiske request‑tællere. Ellers skalerer I for sent—eller for dyrt.
Drift og observability, hvad måler vi egentlig
Glem gennemsnitlig responstid. Mål i stedet: per‑token‑latency, jitter, stream‑drop‑rate, reconnect‑tid og fejlrate per minut under burst. Tilføj GPU‑telemetri: SM‑utilization, memory‑pressure, kernel‑launch‑count. Vi har en dashboard‑sektion, der hedder “Dead air”, som tracker pauser over 300 ms i tokenstrømmen. Den har reddet os flere gange.
Opskalering. Når flere streams rammer samme GPU, skal continuous batching holde dig flydende. Men der er en grænse. Planlæg load‑tests med stigende samtidige streams pr. GPU. Mange spørger os: hvor mange kan vi klemme ind? AWS‑posten giver ikke tal, og vLLM‑docs varierer efter model. Start konservativt, 10–30 samtidige, og mål. Beslut bagefter.
Failover og retry på den kedelige dag
Byg en retry‑matrice: transportfejl, container‑restart, modelfejl. Hvad prøver klienten først? Hvad holder serveren i live? Simple ting virker: exponential backoff, hurtig reattach til samme session og en fallback til batch‑mode, hvis realtid dør i 10 sekunder. Når en operatør sidder i et call og skærmen fryser, er enkelt bedre end smart.
Vi blev ramt af en tilsyneladende ufarlig TLS‑ciphersuite‑mismatch, som kun viste sig på en ældre VDI i et kundecenter. Den slags er grunden til, at transportlaget skal have lige så meget kærlighed som modellen.
Compliance og sikkerhed uden pynt
Data flyder fra klient til AWS via HTTP\/2 på 8443, og internt til containeren som WebSocket. Kryptering på transportlaget er selvskrevet. Logging er sværere. Sørg for, at audio og transkript‑logs er skilt ad, at PII maskereres tidligt, og at retention matcher domænets krav. For sundhed, jura, finans kan en ren managed‑løsning være fin, hvis aftaler og region dækker. Ellers er on‑prem eller VPC‑isolation vejen.
Risiko ved managed containers: Bekvemmelighed kan betyde mindre kontrol over, hvilke biblioteker og drivere der ligger under motorhjelmen. Gå infrastrukturen efter i sømmene. Version‑pin CUDA, dokumentér driverkrav, og hav en plan for reproducerbare builds—også hvis AWS skifter base‑image.
Domænespecifik vs. foundation
På papiret kan en generalist klare det meste. I praksis snubler de ofte på fagsprog. Et nyere eksempel fra VentureBeat viser, at Cortis Symphony for Speech‑to‑Text slår generalister markant på medicinsk terminologi med lavere WER. Det taler for specialiserede modeller i regulerede domæner.
Strategien bliver tostrenget: Brug en kompakt, hurtig realtidsmodel til samtalen. Og skift eventuelt til en tungere, domænespecifik model for efterredigering eller kvalitetssikring i baggrunden. Ja, to pass øger kompleksiteten. Til gengæld får du kvalitet uden at ødelægge realtidsoplevelsen.
Omkostninger og TCO, uden gas
vLLM er effektiv på GPU‑udnyttelse. Det kan spare mange kroner per time, især når continuous batching rammer rigtigt. Men SageMaker managed drift lægger et lag af bekvem overhead. Vægten tipper efter jeres profil: spidsbelastning et par timer om dagen eller flad aktivitet 24\/7.
De hårde tal mangler i AWS‑bloggen. Ingen standardiserede benchmarks for per‑token‑latency eller streams per GPU i SageMaker‑miljøet. Rådet er prosaisk: lav egne målinger, offentliggør dem internt, og lad økonomien styre arkitekturvalget—ikke omvendt.
Implementeringscheckliste, kort men brugbar
Her er en praktisk rute fra POC til drift. Ikke alt, bare det vigtigste.
- Protokoller: vælg HTTP\/2 -> WebSocket via SageMaker, bekræft TLS og ciphers på jeres klienter.
- Audio: standardisér til 16 kHz mono PCM16, definér chunk‑størrelser og max jitter.
- Model: start med Voxtral‑Mini‑4B‑Realtime‑2602 eller tilsvarende, pin GPU‑drivere og CUDA 13.x.
- Metrics: per‑token‑latency, jitter, drop‑rate, reconnect‑tid, GPU‑utilization. Sæt hårde SLO’er.
- Load‑test: simuler 10–500 samtidige streams, variér chunk‑størrelser og netværkstab.
- Backpressure: dokumentér politikker, test bursts, implementér client‑side pacing.
- Compliance: PII‑maskering ved indløb, regionsvalg, logging‑hygiejne, retention‑regler.
- Failover: exponential backoff, session‑reattach, batch‑fallback hvis stream dør.
- Drift: autoscaling på aktive streams, health checks, container cold‑start‑tid.
Konkrete risici og fallback, som vi faktisk har set
Netværksproblemer: Wi‑Fi med høj jitter slår alt i stykker. Overvej lokal buffer på klienten og lille præ‑fetch af modelstate. Kromatiske audioformater: en blanding af 44.1 kHz, 48 kHz, stereo og variable bitrater. Løs det ved kilden. Resample ensartet før afsendelse.
Modelregressioner: et tilsyneladende mindre versionshop i containeren kan sænke nøjagtigheden. Frys versionsnumre. Kør A\/B mod referenceaudio hver nat. Og hold en fallback‑sti åben, fx en hybrid on‑device ASR på edge for nødfunktionalitet, hvis cloud‑streamen fejler.
Små case‑vinkler, der fortjener opfølgning
Kontaktcentre: kortere sagsløsningstid gennem sub‑sekunds per‑token‑feedback, mere præcis realtidsanalyse. Sundhed: sammenlign domænespecifik STT mod generalist på akutte journalnotater. Drift: TCO‑studie af vLLM continuous batching ved varierende samtidighed.
Og en sidste: dansk sprogperformance. Vi mangler stadig bredt publicerede benchmarks for både voxtral‑typer og kliniske modeller. Det bør måles på åbne datasæt—også med accent og baggrundsstøj. Gerne fra en travl reception en tirsdag kl. 9.12. Lyden af ringeklokke i baggrunden. Den slags virkelighed.
Kilder og verifikation
Tre kilder bærer de centrale påstande. AWS’ blogindlæg beskriver, at SageMaker AI fra november 2025 understøtter bidirectional streaming for real-time inference, at forbindelsen er HTTP\/2 på port 8443, og at de i eksemplet deployer Voxtral‑Mini‑4B‑Realtime‑2602 via vLLM med WebSocket \/v1\/realtime. vLLM’s officielle site dokumenterer Realtime API, den OpenAI‑kompatible API, continuous batching og performance‑optimeringer. VentureBeat‑artiklen om Cortis Symphony viser værdien af domænespecifikke STT‑modeller med lav WER i medicinsk kontekst.
Hvor kilderne halter: AWS‑bloggen deler ikke hårde tal for per‑token‑latency eller streams pr. GPU i SageMaker. Også backpressure‑ og retry‑detaljer i protocol‑bridgen er ikke fuldt belyst. Det kalder på egne tests og gerne svar fra AWS og vLLM‑teamet.
Åbne spørgsmål, vi vil have svar på
Hvad er den anbefalede backpressure‑strategi i SageMakers HTTP\/2 ↔ WebSocket‑bro? Hvor hurtigt kan forbindelser genoprettes uden at tabe state? Hvilke reference‑konfigurationer af CUDA 13.x og drivere anbefaler vLLM‑holdet til piecewise CUDA graph execution i produktion?
Og økonomien: hvordan prissættes vedvarende streaming minute‑for‑minute, inklusive eventuelle gateway‑omkostninger? Uden et klart priseksempel bliver TCO‑sammenligningen hurtigt teoretisk.
Hvad betyder det i praksis i morgen
Tre skridt, jordnært. Ét, byg en lille POC med én model i én region og 24–48 timers stresstest. To, mål på streaming‑metrics og GPU‑telemetri, ikke på gennemsnitlig responstid. Tre, planlæg for compliance og fallback fra dag ét. Realtid er ubarmhjertig—forskellen mærkes først, når man sidder med det i hænderne.
