OpenAI Beschreibt WebRTC-Architektur für Low-Latency-Voice-AI auf globaler Skala

InfoQ Homepage News OpenAI Beschreibt WebRTC-Architektur für Low-Latency-Voice-AI auf globaler Skala Architecture & Design Portable by Design: Data Mobility & Recovery Patterns für Multi-Cloud-Systeme (Webinar 21. Mai) OpenAI Beschreibt WebRTC-Architektur für Low-Latency-Voice-AI auf globaler Skala 20. Mai 2026 2 min read von Eran Stiller Schreibe für InfoQ Fördere deine Neugier. Hilfe 550k+ globalen Senior-Entwicklern jeden Monat auf dem Laufenden zu bleiben. Kontakt aufnehmen Höre dieses Artikel - 0:00 Audio bereit zum Abspielen Dein Browser unterstützt nicht das Audio-Element. 0:00 0:00 Normal 1.25x 1.5x Gefällt dir Lesezeichen OpenAI hat kürzlich beschrieben, wie sie WebRTC für Low-Latency-Voice-AI auf globaler Skala angepasst hat . Die neue Architektur hat einen konventionellen Medienterminierungsmuster durch einen Relay-Transceiver-Design ersetzt, das besser zu Kubernetes und Cloud-Lastbalancern geeignet ist. Sie hält WebRTC Sitzungsstatus in einem dedizierten Transceiver-Schicht, während sie leichte Relais verwendet, um die öffentliche UDP-Exposition zu reduzieren und die Medienrouting nahe an die Benutzer zu halten. In dem Artikel erklären Yi Zhang und William McDonald, Mitglieder des technischen Personals von OpenAI, dass globale Reichweite, schnelle Verbindungsaufbau und stabile Medienrundtrittzeiten die Hauptbeschränkungen hinter dem Wechsel waren. Die Mannschaft hat mehrere Ansätze zur Exposition von Mediensitzungen bewertet, jede mit unterschiedlichen operativen Vorteilen. Die erste Alternative war die direkte per-Sitzung-UDP-Exposition, die den konventionellen WebRTC-Modell erhalten bleibt. Allerdings schiebt sie die operative Komplexität in den Infrastrukturlayer, insbesondere in Kubernetes-Umgebungen, wo große öffentliche Portbereiche schwer zu managen sind. Die Zuweisung von eindeutigen Ports pro Server vereinfacht einige Routingentscheidungen, aber lässt die Betreiber mit der Portplanung, ungleichmäßiger Auslastung und brüchigerer Auslieferungsmuster zu kämpfen. Option 1: Der SFU-Ansatz beinhaltet AI als WebRTC-Teilnehmer ( source ) Relay -style Relais waren auch eine plausible Option, aber sie führen einen schwereren Zwischenhändler in den Medienpfad ein und lösen ein breiteres Problem als OpenAI für die überwiegend 1:1-Modell-zu-Benutzer-Sitzungen benötigte. OpenAI hat stattdessen beschlossen, die Verantwortlichkeiten zwischen zwei Schichten zu teilen. Ein leichtes Relais akzeptiert eingehende Pakete und sendet sie weiter, während ein separater Transceiver alle staatlichen WebRTC-Maschinen besitzt, einschließlich ICE Verhandlungen, DTLS Handshakes, SRTP Verschlüsselung und den Gesamtsitzungslebenszyklus. Option 2: Der tranceiver-Ansatz unterbricht WebRTC am Rand und konvertiert in einen Backend-Protokoll ( source ) Diese Trennung bedeutet, dass das Relais einfach, schnell und in der Regel ohne Zustand bleiben kann, während der Transceiver der einzige Komponente ist, der den vollständigen Protokoll versteht. Das hält die Komplexität konzentriert in einem einzigen Ort anstatt sie in Backend-Diensten oder in benutzerdefiniertem Clientverhalten zu duplizieren. "Der beste Ort, um Komplexität hinzuzufügen, ist in einer dünnen Routing-Schicht, nicht in jedem Backend-Dienst und nicht in benutzerdefiniertem Clientverhalten," behaupten die Autoren. Relay statelessly sendet Pakete an den Transceiver ( source ) WebRTC ist eine gängige Wahl für reale Zeit-AI-Ladungen. Neben der Übermittlung von Medien zu niedriger Latenz bietet es auch NAT-Traversierung, verschlüsselten Transport, Kodierungsnegotiation, Jitter-Buffering und Audiofunktionen wie Echo-Abstimmung auf Browsern und mobilen Plattformen. STUN ist Teil dieser Grundlage, indem es Endpunkte hilft, zu erkennen, wie sie in der Netzwerk erscheinen, und ICE während der Verbindungsprüfungen unterstützt. Viele Teams setzen sich auf selektive Forwarding-Einheiten, oder SFUs, weil sie die Medienrouting und -Politik für Multi-Teilnehmer-Systeme zentralisieren. Allerdings sind die Aufgaben von OpenAI hauptsächlich 1:1-Sitzungen zwischen einem Benutzer und einem Modell, was ein Transceiver-Design besser passt als das Modell als Teilnehmer in einer Konferenzarchitektur zu behandeln. Der Artikel fügt Infrastrukturdetails zu OpenAIs breiterem Echtzeit-Voice-Push hinzu, der bereits in Produkten wie ChatGPT-Voice und der Realtime-API verfügbar ist. Für Architekten, die interaktive Mediensysteme bauen, ist der interessanteste Muster die Dekomposition selbst: das Protokollverhalten bei der Routing-Schicht erhalten