OpenAI hat am 4. Mai Details zur Audio-KI-Infrastruktur veröffentlicht – um Sprach-KI-Dienste zu unterstützen, die auf 900 Millionen wöchentlich aktive Nutzer (Weekly Active Users) ausgelegt sind. Das Team hat dafür den WebRTC-Stack neu entworfen und die Medienstrecke von der traditionellen Architektur „ein Port pro Session“ auf ein dünnes, in Go geschriebenes Relay umgestellt. Außerdem wurden alle WebRTC-Session-Status in einen Dienst namens „transceiver“ gebündelt. In einem offiziellen Blogbeitrag erklärt OpenAI, dass diese Architektur zugleich den ChatGPT-Voice-Modus, die Realtime API und mehrere Forschungsprojekte unterstützt. Für jedes Team, das an Sprach-KI-Engineering arbeitet, ist dieses Vorhaben eine seltene technische Literatur darüber, „wie man Sprach-KI im globalen Maßstab zum Laufen bringt“.
Drei technische Grenzen: Traditionelles WebRTC stößt bei OpenAI-Skala überall an Grenzen
Das OpenAI-Engineering-Team nennt im Beitrag drei Einschränkungen, die sich nach der Skalierung gegenseitig „in die Quere kommen“:
Die herkömmliche Art des Media-Terminations „eine Session, ein Port“ (per-session port termination) ist für OpenAI-Infrastruktur nicht geeignet – wenn jede Woche 900 Millionen Nutzer möglicherweise gleichzeitig Voice-Sessions starten und jede Session jeweils einen eigenen Port belegt, würde das die Netzwerkressourcen aufbrauchen
Zustandsbehaftete ICE- (Interactive Connectivity Establishment) und DTLS- (Datagram Transport Layer Security) Sitzungen, die eine stabile Zuständigkeit (Owner) erfordern – in einem verteilten System wird es extrem kompliziert, wenn Session-Status zwischen mehreren Diensten aufgeteilt werden, da Fehlertoleranz und Migration dadurch stark erschwert werden
Globale Routen müssen eine niedrige Latenz beim ersten Hop (first-hop latency) aufrechterhalten – das „natürliche“ Gefühl von Voice-KI hängt von flüssigem Turn-taking (Wechsel der Sprecher-/Dialogrolle) ab; wenn der erste Hop über 100 ms liegt, wirkt es deutlich ruckelig
OpenAIs Anforderungen sind ebenfalls klar: globale Reichweite (Abdeckung von 900 Millionen+ Nutzern), schnelle Session-Erstellung (Nutzer können sofort sprechen), sowie eine niedrige und stabile Media-Round-trip-Time (inklusive niedrigem Jitter und Paketverlust).
Lösung: dünnes Go-Relay + zentraler transceiver-Dienst
Die Architektur von OpenAI ist in zwei Ebenen unterteilt:
Relay-Ebene – in Go geschrieben, bewusst so einfach wie möglich umgesetzt. Ein normaler Go-Prozess: Er liest aus einem Socket die Paket-Header, aktualisiert nur wenige Verkehrs-/Flow-Status, leitet Pakete weiter und beendet WebRTC nicht. Das ist der Schlüssel dafür, dass das Relay horizontal skalierbar ist – es muss keinen vollständigen WebRTC-Status vorhalten, Relays sind untereinander ohne Schmerzen austauschbar, und ein Single Point of Failure unterbricht nicht die gesamte Session.
Transceiver-Ebene – der einzige Dienst, der den WebRTC-Session-Status besitzt. Er beinhaltet ICE-Verbindungschecks, DTLS-Handshake, SRTP-Verschlüsselungsschlüssel und das Management des Session-Lebenszyklus. Indem diese Zustände auf einen Dienst konzentriert werden, lässt sich die Zuständigkeit einer Session besser nachvollziehen; Backend-Dienste können sich wie „normale“ Services skalieren lassen, ohne jeweils selbst WebRTC-Peers sein zu müssen.
Der raffinierte Punkt dieses Designs liegt darin, dass „die zustandsbehafteten Teile“ und „die zustandslosen Teile“ streng getrennt werden. Das Relay ist eine zustandslose Datenebene (die sich massenhaft replizieren lässt), der transceiver ist eine zustandsbehaftete Kontrollebene (wenige, aber vollständig zustandsbasierte Instanzen). Diese Schichtung ermöglicht es OpenAI, nach Bedarf horizontal zu skalieren, ohne sich vor einer Explosion der Anzahl an WebRTC-Verbindungen fürchten zu müssen.
Warum Go: Entscheidungslogik für Voice-KI-Engineering
OpenAI erklärt in dem Artikel ausdrücklich, dass das Relay in Go geschrieben wird und bewusst „schmal“ gehalten ist. Die dahinterliegende technische Logik:
Go-Goroutinen werden für IO-lastige Aufgaben wie „tausende bis zehntausende Verbindungen pro Port“ nativerweise unterstützt; eine komplexe Event-Loop ist nicht nötig
Das net-Paket der Standardbibliothek kann UDP-Pakete direkt lesen, ohne C-Bibliotheken binden zu müssen
Nach dem Kompilieren entsteht eine einzelne statische Binary; Deployment, Containerisierung und Cross-Architektur (x86/ARM) sind einfach
Das Memory-Management von Go ist gut für „viele kurzlebige Objekte“ (jedes Paket muss geparst werden), und die GC-Pausenzeiten sind kontrollierbar
Das erklärt auch, warum die Durchdringung von Go in modernen Infrastruktur-Layern (Cloudflare, Tailscale, HashiCorp etc.) weiter steigt – nicht weil „Go irgendeiner Sprache überlegen ist“, sondern weil Go in IO-lastigen, horizontal skalierbaren Infrastruktur-Szenarien „am direktesten“ zu implementieren ist.
Cloudflare im Abgleich: Realtime Voice AI im Wettbewerb
Auch Cloudflare veröffentlichte zu derselben Zeit (Anfang Mai) einen technischen Blogbeitrag mit dem Titel „Cloudflare ist der beste Ort, um Echtzeit-Voice-Agenten zu bauen“, und stellte dabei eine eigene Lösung gegenüber OpenAI. Die Wege beider Seiten unterscheiden sich:
OpenAI: selbstgebaute WebRTC-Relay-/transceiver-Stacks, ohne Abhängigkeit von Dritten; auch die Medieneinbindung wird in den eigenen Technikstack aufgenommen
Cloudflare: WebRTC-Medienservices als Erweiterung der eigenen Workers-Plattform; für Entwickler „One-Stop“-Infrastruktur
Für mittelgroße bis kleinere AI-Anwendungs-Teams ist der Cloudflare-Weg praktischer – direkt APIs nutzen, ohne selbst WebRTC-Infrastruktur zu bauen. Für Teams im OpenAI-Maßstab ist Selbstbau jedoch ein Muss – externe Services können SLA, Preismodell und geografische Verteilung nicht vollständig so abbilden, wie es nötig wäre.
Ausblick: transceiver Open-Source, Größenordnung der Realtime API, Reaktionen der Wettbewerber
Die wichtigsten Beobachtungspunkte der nächsten Phase:
Ob OpenAI die transceiver-/relay-Anteile open-sourced – Wettbewerber wie Anthropic, Google und xAI bauen ebenfalls eigene Voice-Stacks; falls OpenAI open-sourced, könnte das zur Branchen-Standardreferenz werden
Abrechnung und Skalierung der Realtime API – aktuell basiert das vor allem auf der Subskribtion, die durch ChatGPT abgedeckt wird; wenn die API-Einnahmen wachsen, wird sie dann zu einer eigenständigen Produktlinie
Entsprechungen bei Anthropic und Google – Claude und Gemini unterstützen bereits Voice, aber im Vergleich zu OpenAI gibt es bei Latenz und Skalierung noch Unterschiede; wird diese technische Offenlegung ihre weitere Engineering-Nachverfolgung beschleunigen?
Für AI-Anwendungsentwickler in Taiwan ist Voice-KI im zweiten Halbjahr 2026 eine entscheidende Schlacht – Anwendungsfälle wie Kundenservice, Bildung, Fahrzeug und IoT benötigen dialogfähige Gespräche mit geringer Latenz. Die technische Offenlegung von OpenAI ist diesmal eine der wichtigsten Referenzen, um zu entscheiden: „Soll man den Voice-Stack selbst bauen oder eine Drittanbieter-API nutzen?“
Dieser Artikel zur Neuorganisation des WebRTC-Voice-Stacks von OpenAI: 900 Mio. wöchentliche aktive Nutzer, Relay als Kern von Go; zuerst erschienen bei 鏈新聞 ABMedia.
