NVIDIA har løftet sløret for NemotronLabs VoiceChat 11B, en åben, 11‑milliarders end‑to‑end model til realtids fuld‑duplex tale. Ifølge den primære offentliggørelse måles glat turn‑taking til 448 ms på Full‑Duplex‑Bench 1.0, og modellen kan kalde værktøjer live via en særskilt <TOOLCALL>‑kanal uden at stoppe samtalen. Vægtene og en container er offentlige under en permissiv licens, men checkpointet er udtrykkeligt mærket “research only”, ikke produktion. Der er heller ikke nogen hosted API.
En samlet model, der både lytter og taler samtidig, reducerer orkestrering og API‑hop og muliggør nye interaktioner i bil, butik og kontaktcentre. Men der er forbehold. Deployment kræver én GPU med cirka 80 GB VRAM på x86_64 Linux, og repo’et beskriver fejltilstande, man skal tage højde for.
Hvad der faktisk er nyt
VoiceChat 11B samler streaming tale‑forståelse og tale‑generering i ét netværk i stedet for at kæde ASR, LLM og TTS. Det skærer grænseflader, buffere og overleverings‑ventetid væk — derfor lavere end‑til‑ende latenstid og enklere drift. Til gengæld mister man modularitetens fordele, som uafhængig fejlfinding og simple fallbacks (fx skift til robust ASR ved lav SNR).
Hvad 448 ms og 1.00 take‑over egentlig betyder
Tallet er fra laboratorieforhold. Uafhængig verifikation af Full‑Duplex‑Bench 1.0 er ikke refereret. I praksis påvirker netværksjitter, Bluetooth‑mikrofoner og støj (fx i bil) oplevelsen. Indtil tredjepart gentager målingerne, bør 448 ms og 1,00 take‑over ved 480 ms læses som bedste fald under kontrollerede forhold.
Tool‑calling uden død luft
En særskilt udgangskanal til værktøjskald lader modellen udlede et <TOOLCALL>‑blok, hvorefter integrationen svarer med <TOOL_RESPONSE>. Agenten kan holde linjen varm med on‑hold‑sætninger, så brugeren ikke oplever stilstand. Repo’et angiver begrænsninger: anbefalet maks fem tools pr. session, svaghed ved parallellitet, og ingen afbrydelse mens et tool kører. System‑prompter og tool‑svar skal være TTS‑egnede. Det stiller krav til design: idempotens, timeouts og rensning af svar fra dag ét.
Deployment i virkeligheden
“Deployable for pilots, not for production.” Formuleringen går igen — og giver mening operationelt. Der er ingen hosted API, og ingen kendt tredjeparts inference‑udbyder kører modellen. Kravet er én GPU med ~80 GB VRAM (A100, H100, RTX 6000 Pro eller B200 nævnes) samt x86_64 Linux. Det er realistisk for universiteter, R&D‑enheder og AI‑native startups, men mindre for teams med stramme compliance‑krav uden en særskilt forsøgsbane.
Fejltilstande man ikke må overse
Repo’et dokumenterer: ca. to minutters audiokontekstloft med risiko for ikke‑genopretteligt vrøvl, runaway self‑talk efter et turn, samt droppede ord i brugertranskriptionen. I domæner med lav fejltolerance (kontaktcenter, finans, sundhed) ændrer det risikoprofilen. Sessioner bør afkortes, og automatiske resets planlægges — ellers ender man i ustabile samtaler.
Arkitekturen og træningen, så vidt den er beskrevet
Modellen beskrives som en hybrid Mamba\/Transformer: Fast Conformer‑encoder (fra Nemotron‑Speech‑Streaming‑En‑0.6b) til 16 kHz‑lyd, Nemotron Nano v2 som LLM‑rygrad, og en NVIDIA TTS‑decoder\/codec, der gengiver 22,05 kHz talesvar. Der er særskilt outputvej til tool‑skript, og outputtet omfatter agents tale, agents tekst og løbende brugertranskription.
Træningen opgives til ~550.000 timer på tværs af rigtige og syntetiske korpora og bygger videre på SALM‑Duplex og Audio Flamingo 3. Uden detaljeret datasheet er domænedækning, sprogvarianter, støjtyper, de‑identifikation og bias‑risiko uafklarede — totalmængden alene giver ikke det fulde billede.
Ydelsestal ud over latenstid
Ud over 448 ms rapporteres: på Full‑Duplex‑Bench 1.0 en TOR på 0,82 for glat turn‑taking ved 448 ms, 1,00 for brugerafbrud ved 480 ms, og pause‑håndterings‑TOR på 0,153 (syntetisk) og 0,255 (Candor) — lavere er bedre. På AU Harness BFCL‑v3 for talebaseret tool‑calling rapporteres 56,1% i gennemsnit, med bedre score på simple cases end parallelle. Modellen skulle rangere som nr. 2 blandt åbne fuld‑duplex‑modeller på VoiceBench og på Full‑Duplex‑Bench 1.0. Alt dette er fra den primære kilde; uafhængige replikationer er ikke refereret.
Licens, adgang og governance
Vægte og container er offentlige under en permissiv licens, men checkpointet er mærket research‑only. Adgang er bred, anvendelse snævrere. R&D‑hold kan teste, mens produktionsbrug bør afvente juridisk afklaring og\/eller en produktionsklar release.
Governance er nødvendig: GDPR‑håndtering af stemme og tekst, logning og retention‑politikker, indholdsfiltrering før kundesystemer. Tool‑kanalen bør sandboxes stramt, og on‑hold‑tekster betragtes som brugerrettet kommunikation med dertilhørende krav.
Hvad det ændrer i praksis for teams
En samlet model fjerner klasser af race conditions og reducerer latenstid ved at undgå ASR > LLM > TTS‑kæden. Men den fjerner også simple fallback‑punkter: du kan ikke blot bytte ASR ved lav SNR uden modelswap. Uden hosted API ligger drift, monitorering, alarmer og security‑ops hos teamet. Man skal kunne profilere duplex‑latenstid, måle barge‑in og detektere self‑talk‑mønstre.
Sådan kører man en realistisk pilot
Minimum: en 80 GB‑klasse GPU på Linux, repo‑containeren, en lav‑latens lydstack og et test‑harness, der måler ende‑til‑ende duplex‑latenstid over rigtige netværk. Indsæt en proxy mellem model og tools, der håndterer idempotens, timeouts og syntaksvalidering af <TOOLCALL> og <TOOL_RESPONSE>.
Sikkerhedsbarrierer: stemme‑ratebegrænsning, automatisk session‑reset efter 90–110 sekunders aktiv lyd for at undgå kontekstmætning, overvågning for droppede ord og self‑talk. On‑hold‑linjer skal være korte, præcise og reversible, så agenten kan rulle tilbage, hvis et tool fejler.
Hvor skal man starte, og hvor skal man lade være
Start med ikke‑kritiske flows: produkt‑FAQ, bookingforespørgsler uden transaktion eller intern support med lav risikoprofil. Vent med finansielle godkendelser, medicinske råd og alt, der kræver ubrydelig audit‑kæde. Lad tredjepartsbenchmarks lande, før man går efter højrisiko‑kanaler.
Test under støj: in‑car, højtalertelefon, åbent kontor. Hvis barge‑in ikke holder her, holder præmissen ikke.
Konsekvenser for markedet
Åbne fuld‑duplex‑vægte med lav latenstid favoriserer AI‑native startups, R&D‑labs og universiteter. GPU‑cloud‑udbydere får et konkret use case. Hosted voice‑API‑spillere presses af kunder, der vil eje hele stakken for at jagte latenstid og tool‑calling uden dead air. Der er stadig plads til udbydere, der kan levere driftssikre, monitorerede, compliance‑klare tjenester — ikke alle kan eller vil drive en 80 GB‑model selv. Men nogle virksomheder bør afvente dokumenteret håndtering af fejltilstande i produktion.
Skepsis der er værd at lytte til
Skeptikere vil pege på: mulig overoptimisme i 448 ms‑tallet uden realistiske støj‑ og netværkstests; fravær af uafhængig verifikation af rangeringer og TOR‑tal; og at tool‑kanalen udvider angrebsfladen, hvis <TOOL_RESPONSE> kan manipuleres. Yderligere beviser, der vil flytte vurderingen: reproducerbare målinger, mitigations for self‑talk og kontekstloft, samt klare licensvilkår.
Hvor står beslutningstageren i dag
Kør en kontrolleret pilot — ikke en stor implementering. Verificér duplex‑latenstid og barge‑in under realistiske forhold. Afdæk GPU‑adgang tidligt, og få juridisk vurdering af research‑only‑mærkningen, før noget vendes mod kunder. Og hav en exit‑strategi, hvis fejltilstande optræder midt i testen.
Forskellen mærkes, når man forsøger at afbryde — og agenten faktisk tier stille på det rigtige millisekund.
