Wie OpenAI skalierbare Voice-AI mit niedriger Latenz bereitstellt

 (openai.com)
3 Punkte von GN⁺ 7 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • OpenAI hat das interne Paket-Routing in eine Relay- + Transceiver-Struktur umgestaltet, um für mehr als 900 Millionen wöchentlich aktive Nutzer natürliche Sprachgespräche bereitzustellen und dabei das standardmäßige WebRTC-Verhalten beizubehalten
  • WebRTC standardisiert ICE, DTLS/SRTP, Codec-Aushandlung, RTCP-Qualitätssteuerung, Echounterdrückung und Jitter-Pufferung und eignet sich damit für die Verarbeitung kontinuierlicher Audio-Streams mit niedriger Latenz zwischen Browsern, mobilen Apps und Servern
  • Da die meisten OpenAI-Sitzungen 1:1-Sitzungen sind, in denen ein Nutzer mit einem Modell oder eine Anwendung mit einem Echtzeit-Agenten spricht, war das Transceiver-Modell in Bezug auf Latenz und Skalierbarkeit besser geeignet als ein auf Mehrparteiengespräche ausgelegtes SFU
  • Das WebRTC-Modell mit einem UDP-Port pro Sitzung, wenn es auf Kubernetes betrieben wird, verkompliziert große öffentliche Portbereiche, Load-Balancer-Konfigurationen, Health Checks, Firewall-Richtlinien und die Sicherheit von Rollouts, sodass eine kleine, feste UDP-Oberfläche benötigt wurde
  • Das Relay findet anhand des ICE ufrag im ersten STUN-Paket den zuständigen Transceiver und leitet weiter, während der Transceiver ICE, DTLS, SRTP und den Sitzungslebenszyklus besitzt und so Standard-WebRTC-Kompatibilität zusammen mit einem weltweit nahen Ingress-Pfad aufrechterhält

Anforderungen an Voice-AI mit niedriger Latenz

  • Voice-AI wirkt natürlich, wenn sich ein Gespräch mit Sprechgeschwindigkeit bewegt, und Netzwerklatenz zeigt sich sofort durch unangenehme Pausen, abgeschnittene Unterbrechungen und verspätete Reaktionen auf Unterbrechungen
  • In OpenAIs Größenordnung sind weltweite Erreichbarkeit für mehr als 900 Millionen wöchentlich aktive Nutzer, ein schneller Verbindungsaufbau, bei dem man direkt nach Sitzungsbeginn sprechen kann, niedrige und stabile Media-Round-Trip-Zeiten sowie geringer Jitter und Paketverlust erforderlich
  • ChatGPT Voice, die Realtime API, Agenten in konversationellen Workflows und alle Modelle, die Audio verarbeiten müssen, während der Nutzer spricht, sind von diesen Latenzeigenschaften betroffen
  • OpenAI hat den WebRTC-Stack in eine getrennte Relay- + Transceiver-Architektur umgestaltet, um das interne Paket-Routing zu ändern und zugleich das standardmäßige WebRTC-Verhalten auf Client-Seite beizubehalten

Warum WebRTC gewählt wurde

  • WebRTC ist ein offener Standard zum Übertragen von Audio, Video und Daten mit niedriger Latenz zwischen Browsern, mobilen Apps und Servern und eignet sich auch als Grundlage für Echtzeitsysteme im Client-Server-Modell
  • WebRTC standardisiert den Verbindungsaufbau und NAT-Traversal über ICE, verschlüsselte Übertragung über DTLS/SRTP, Codec-Aushandlung, RTCP-Qualitätssteuerung sowie Client-Funktionen wie Echounterdrückung und Jitter-Pufferung
  • Ohne WebRTC müsste jeder Client Verbindungsaufbau in NAT-Umgebungen, Medienverschlüsselung, Codec-Aushandlung und den Umgang mit Netzwerkänderungen selbst lösen
  • Eine für AI-Produkte wichtige Eigenschaft ist, dass Audio als kontinuierlicher Stream ankommt, sodass Transkription, Inferenz, Tool-Aufrufe und Spracherzeugung beginnen können, ohne auf das Ende des vollständigen Uploads des Nutzers zu warten
  • Genau dieser Unterschied trennt Systeme, die sich dialogorientiert anfühlen, von solchen, die wie Push-to-Talk wirken
  • OpenAI baut auf dem WebRTC-Ökosystem mit ausgereiften Open-Source-Implementierungen und Standardisierungsarbeit auf und konnte dank der Grundlagenarbeit von Justin Uberti und Sean DuBois auf bewährter Medieninfrastruktur aufsetzen, statt Low-Level-Transport, Verschlüsselung und Congestion Control neu zu entwickeln

Architekturentscheidung für Transceiver statt SFU

  • Wann eine SFU passt

    • Eine SFU ist ein Medienserver, der die WebRTC-Streams jedes Teilnehmers entgegennimmt und selektiv an andere Teilnehmer weiterleitet
    • Im SFU-Modell wird für jeden Teilnehmer eine eigene WebRTC-Verbindung terminiert, und auch die AI tritt als weiterer Teilnehmer der Sitzung bei
    • Für Produkte, die inhärent mehrere Teilnehmer haben, etwa Gruppengespräche, Klassenräume oder kollaborative Meetings, kann eine SFU gut passen
    • Audio-Codecs, RTCP-Nachrichten, Data Channels, Aufzeichnung und Richtlinien pro Stream lassen sich an einer Stelle bündeln
    • Auch in Client-zu-AI-Produkten ist dies oft ein naheliegender Ausgangspunkt, da sich Signalverarbeitung, Medien-Routing, Aufzeichnung, Observability sowie künftige Erweiterungen wie Übergabe an Menschen oder das Hinzufügen weiterer Teilnehmer in einem System wiederverwenden lassen

  • OpenAIs Workload

    • Die meisten OpenAI-Sitzungen sind 1:1-Sitzungen, in denen ein Nutzer mit einem Modell oder eine Anwendung mit einem Echtzeit-Agenten spricht
    • Da diese Verkehrsform auf die Latenz jeder einzelnen Gesprächsrunde empfindlich reagiert, wurde das Transceiver-Modell gewählt
    • Im Transceiver-Modell terminiert ein WebRTC-Edge-Service die Client-Verbindung und übersetzt Medien und Ereignisse anschließend in ein einfaches internes Protokoll für Modellinferenz, Transkription, Spracherzeugung, Tool-Nutzung und Orchestrierung
    • Der Transceiver ist der einzige Service, der den Zustand der WebRTC-Sitzung besitzt, einschließlich ICE-Connectivity-Checks, DTLS-Handshake, SRTP-Schlüsseln und Sitzungslebenszyklus
    • Wenn sich der Sitzungszustand an einer Stelle befindet, ist die Besitzverantwortung für Sitzungen leichter verständlich, und Backend-Services können wie normale Services skalieren, statt sich wie WebRTC-Peers zu verhalten

Erste Implementierung und die Grenzen in Kubernetes

  • OpenAIs erste Implementierung war ein einzelner Go-Service auf Basis von Pion, der sowohl Signalisierung als auch Medien-Terminierung übernahm
  • Dieser Transceiver-Service treibt ChatGPT Voice, den WebRTC-Endpunkt der Realtime API und mehrere Forschungsprojekte an
  • Im Betrieb verarbeitet der Transceiver im Bereich Signaling SDP-Aushandlung, Codec-Auswahl, ICE-Anmeldedaten und Sitzungsaufbau
  • Im Bereich Media terminiert er die nachgelagerte WebRTC-Verbindung und hält eine vorgelagerte Verbindung zu Backend-Services für Inferenz und Orchestrierung aufrecht
  • OpenAI wollte diesen Service auf Kubernetes betreiben, sodass er mit Nachfrageschwankungen horizontal skaliert und zwischen Hosts verschoben werden kann
  • Das bestehende WebRTC-Modell mit einem Port pro Sitzung passte nicht gut in Kubernetes-Umgebungen, da große öffentliche UDP-Portbereiche exponiert, abgesichert und betrieben werden mussten
  • Bei hoher Gleichzeitigkeit bedeutet ein Port pro Sitzung, dass ein sehr großer UDP-Portbereich exponiert und verwaltet werden muss
  • Cloud-Load-Balancer und Kubernetes-Services sind nicht darauf ausgelegt, pro Service Zehntausende öffentliche UDP-Ports vorauszusetzen, und mit zunehmendem Portbereich werden Load-Balancer-Konfiguration, Health Checks, Firewall-Richtlinien und die Sicherheit von Rollouts immer komplexer
  • Große UDP-Portbereiche sind auch aus Sicherheitssicht nachteilig, weil sie die von außen erreichbare Angriffsfläche vergrößern und die Prüfung von Netzwerkrichtlinien erschweren
  • In Kubernetes werden Pods fortlaufend hinzugefügt, entfernt und neu geplant; wenn jeder Pod große und stabile Portbereiche reservieren und veröffentlichen muss, leidet die Elastizität

Probleme mit Einzelport und Sitzungsbesitz

  • Viele WebRTC-Systeme verwenden einen einzelnen UDP-Port pro Server und Multiplexing auf Anwendungsebene, um die Anzahl der Ports zu reduzieren
  • Ein Einzelport-Design pro Server reduziert zwar die Portzahl, erzeugt aber ein zweites Problem: Die Besitzverantwortung für jede Sitzung muss über die gesamte Flotte hinweg erhalten bleiben
  • ICE und DTLS sind zustandsbehaftete Protokolle, daher muss der Prozess, der eine Sitzung erstellt hat, weiterhin die Pakete dieser Sitzung erhalten, um Connectivity-Checks zu validieren, den DTLS-Handshake abzuschließen, SRTP zu entschlüsseln und spätere Sitzungsänderungen wie ICE-Restarts zu verarbeiten
  • Wenn Pakete derselben Sitzung bei einem anderen Prozess ankommen, kann der Verbindungsaufbau fehlschlagen oder das Medium beschädigt werden
  • OpenAIs Ziel war es, nur eine kleine, feste UDP-Oberfläche gegenüber dem öffentlichen Internet offenzulegen und trotzdem alle Pakete an den Transceiver zu leiten, dem die jeweilige WebRTC-Sitzung gehört

  • Betrachtete Ansätze

    • Eindeutige IP:Port-Kombination pro Sitzung bietet einen direkten Client-Server-Medienpfad ohne Forwarding-Schicht im Datenpfad, benötigt aber einen öffentlichen UDP-Port pro Sitzung und passt mit großen Portbereichen nicht gut zu Kubernetes, Cloud-Load-Balancern und Sicherheitsanforderungen
    • Eindeutige IP:Port-Kombination pro Server hat gegenüber sitzungsweiser Exposition eine viel kleinere öffentliche UDP-Grundfläche, und ein gemeinsam genutzter Socket kann viele Sitzungen multiplexen, aber in einer gemeinsam load-balanced Flotte kann das erste Paket bei der falschen Instanz landen, sodass ein deterministischer Weg zum tatsächlich zuständigen Prozess nötig ist
    • TURN Relay verlangt nur, dass der Client die Adresse und den Port des TURN-Relays erreichen kann, und erlaubt zentrale Richtlinien am Edge, aber TURN-Allokationen fügen zusätzliche Round Trips beim Setup hinzu, und das Verschieben oder Wiederherstellen von Allokationen zwischen TURN-Servern bleibt schwierig
    • OpenAIs Struktur aus stateless forwarder + stateful terminator, also Relay + Transceiver, hält die öffentliche UDP-Grundfläche klein und lässt den Transceiver die vollständige WebRTC-Sitzung besitzen, fügt aber einen zusätzlichen Forwarding-Hop hinzu, bevor Medien den zuständigen Transceiver erreichen, und erfordert enge Abstimmung zwischen Relay und Transceiver

Die Architektur Relay + Transceiver

  • Die von OpenAI eingesetzte Struktur trennt Paket-Routing und Protokoll-Terminierung
  • Das Signaling erreicht für den Sitzungsaufbau den Transceiver, während Medien zunächst beim Relay eintreffen
  • Das Relay ist eine leichtgewichtige UDP-Forwarding-Schicht mit kleiner öffentlicher Grundfläche, der Transceiver dahinter ist ein zustandsbehafteter WebRTC-Endpunkt
  • Das Relay entschlüsselt Medien nicht, führt keine ICE-State-Machine aus und beteiligt sich nicht an der Codec-Aushandlung
  • Das Relay liest nur so viele Paket-Metadaten, wie nötig sind, um das Ziel auszuwählen, und leitet das Paket an den Transceiver weiter, dem die Sitzung gehört
  • Der Transceiver sieht weiterhin einen normalen WebRTC-Ablauf und besitzt den gesamten Protokollzustand
  • Aus Sicht des Clients ändert sich die WebRTC-Sitzung nicht

Routing des ersten Pakets und Nutzung von ICE ufrag

  • Der Kern dieser Struktur ist, dass das Relay das erste Client-Paket direkt im Paketpfad routet
  • Für WebRTC-Sitzungen gibt es bereits einen protokollnativen Routing-Hook: das ICE username fragment, also ufrag
  • Das ufrag ist ein kurzer Identifikator, der beim Sitzungsaufbau ausgetauscht und in STUN-Connectivity-Checks erneut mitgeführt wird
  • OpenAI erzeugt das serverseitige ufrag so, dass es genügend Routing-Metadaten enthält, damit das Relay den Ziel-Cluster und den zuständigen Transceiver ableiten kann
  • Während des Signalings weist der Transceiver den Sitzungszustand zu und gibt in der SDP-Antwort eine gemeinsam genutzte Relay-VIP und einen UDP-Port zurück
  • Die VIP ist eine virtuelle IP-Adresse vor der Relay-Flotte und liefert dem Client zusammen mit dem Port auch hinter mehreren Relay-Instanzen ein einzelnes stabiles Ziel wie 203.0.113.10:3478
  • Das erste Paket im Medienpfad des Clients ist meist ein STUN-Binding-Request, und ICE verwendet dieses Paket, um zu prüfen, ob Pakete die angekündigte Adresse erreichen können
  • Das Relay parst das erste STUN-Paket nur so weit, dass es das serverseitige ufrag lesen, den Routing-Hinweis decodieren und das Paket an den zuständigen Transceiver weiterleiten kann
  • Jeder Transceiver empfängt nicht über einen Socket pro Sitzung, sondern über einen gemeinsam genutzten UDP-Socket, also einen an eine interne IP:Port-Kombination gebundenen Betriebssystem-Endpunkt
  • Sobald das Relay eine Sitzung vom Client-Quell-IP:Port zum Ziel des Transceivers erzeugt hat, laufen spätere DTLS-, RTP- und RTCP-Pakete innerhalb dieser Sitzung, ohne das ufrag erneut decodieren zu müssen
  • Der Zustand im Relay bleibt minimal und umfasst nur eine In-Memory-Sitzung für Paket-Forwarding, Monitoring-Zähler sowie Timer für Sitzungsablauf und Bereinigung
  • Wenn ein Relay neu startet und seine Sitzungen verliert, kann das nächste STUN-Paket die Sitzung mithilfe des ufrag-Routing-Hinweises neu aufbauen
  • Sobald der Pfad steht, speichert ein Redis-Cache das Mapping <Client-IP + Port, Transceiver-IP + Port>, sodass eine frühere Wiederherstellung auch vor dem nächsten STUN-Paket möglich ist

Global Relay und ein naher Eintrittspfad

  • Nachdem die öffentliche UDP-Oberfläche auf eine kleine und stabile Menge von Adressen und Ports reduziert worden war, konnte OpenAI dasselbe Relay-Muster weltweit ausrollen
  • Global Relay ist eine geografisch verteilte Flotte von Relay-Ingress-Punkten, die dasselbe Paket-Forwarding-Verhalten implementieren
  • Ein breit verteilter geografischer Ingress sorgt dafür, dass die Pakete des Nutzers über ein geografisch und netzwerktopologisch nahes Relay in das OpenAI-Netzwerk gelangen, statt zunächst bis in eine entfernte Region über das öffentliche Internet zu laufen, und verkürzt so den ersten Hop vom Client zu OpenAI
  • Das senkt Latenz, Jitter und vermeidbare Verlust-Bursts, bevor der Traffic das Backbone erreicht
  • OpenAI nutzt im Signaling Cloudflare-Geo- und Proximity-Steering, damit die anfängliche HTTP- oder WebSocket-Anfrage einen nahegelegenen Transceiver-Cluster erreicht
  • Der Anfragekontext bestimmt den Sitzungsstandort und den Global-Relay-Ingress-Punkt, der dem Client angekündigt wird
  • Die SDP-Antwort liefert die Global-Relay-Adresse, und das ufrag enthält genügend Informationen, damit Global Relay die Medien an den vorgesehenen Cluster und das Relay sie an den Ziel-Transceiver routen kann
  • Durch die Kombination aus geo-gesteuertem Signaling und Global Relay liegen sowohl Setup als auch Medien auf einem nahen Eintrittspfad, während die Sitzung dennoch an einen einzelnen Transceiver gebunden bleibt
  • Diese Struktur verkürzt die Round-Trip-Zeit für Signaling und die ersten ICE-Connectivity-Checks und reduziert damit direkt die Wartezeit, bis der Nutzer zu sprechen beginnen kann

Implementierung des Relays

  • Der Relay-Service wurde in Go geschrieben und bewusst eng im Umfang gehalten
  • Unter Linux nimmt der Kernel-Netzwerkstack UDP-Pakete von der Netzwerkschnittstelle entgegen und liefert sie an einen Socket aus; das Relay ist ein normaler Go-Prozess im Userspace, der Paket-Header vom Socket liest
  • Das Relay aktualisiert eine kleine Menge Flow-State und leitet Pakete weiter, ohne WebRTC zu terminieren
  • OpenAI hat kein Kernel-Bypass-Framework verwendet, bei dem ein Userspace-Prozess Netzwerk-Queues zur Steigerung der Paket-Rate direkt pollt, da dies die betriebliche Komplexität erhöht hätte

  • Zentrale Designentscheidungen

    • Keine Protokoll-Terminierung: Das Relay parst nur STUN-Header und ufrag und behandelt spätere DTLS-, RTP- und RTCP-Pakete mithilfe gecachter Zustände als undurchsichtige Pakete
    • Kurzlebiger Zustand: Für Flow-State und Observability wird eine kleine In-Memory-Map mit kurzem Timeout vom Client-Addressraum zum Ziel des Transceivers geführt
    • Horizontale Skalierbarkeit: Mehrere Relay-Instanzen laufen parallel hinter einem Load Balancer; da der Relay-Zustand kein harter WebRTC-Zustand ist, führen Neustarts nur zu geringem Traffic-Verlust und schneller Wiederherstellung von Flows

  • Maßnahmen zur Effizienzsteigerung

    • SO_REUSEPORT ist eine Linux-Socket-Option, mit der mehrere Relay-Worker auf derselben Maschine an denselben UDP-Port binden können; der Kernel verteilt eingehende Pakete auf die Worker und vermeidet so einen Flaschenhals in einer einzelnen Read-Loop
    • runtime.LockOSThread bindet jede UDP-lesende Goroutine an einen bestimmten OS-Thread
    • Wenn SO_REUSEPORT und Thread-Pinning zusammen eingesetzt werden, bleiben Pakete desselben Flows tendenziell auf demselben CPU-Core, was die Cache-Lokalität verbessert und Context Switching reduziert
    • Vorab allokierte Buffer und minimale Kopiervorgänge senken Parsing- und Allokations-Overhead und helfen dabei, Garbage Collection in Go zu vermeiden
    • Diese Implementierung konnte OpenAIs globalen Echtzeit-Medienverkehr mit einer vergleichsweise kleinen Relay-Grundfläche verarbeiten, sodass OpenAI auf einen Kernel-Bypass-Pfad verzichtete und ein einfacheres Design beibehielt

Ergebnisse und Erkenntnisse

  • Diese Architektur ermöglicht es, WebRTC-Medien in Kubernetes auszuführen, ohne Tausende von UDP-Ports offenzulegen
  • Eine kleine, feste UDP-Oberfläche vereinfacht Sicherheit und Load Balancing und erlaubt es der Infrastruktur zu skalieren, ohne große öffentliche Portbereiche reservieren zu müssen
  • Das Design bewahrt das standardmäßige WebRTC-Verhalten auf Client-Seite und bestätigt, dass für OpenAIs Workload ein SFU-loses Design als Standard angemessen war
  • Die meisten Sitzungen sind Point-to-Point, latenzempfindlich und lassen sich leichter skalieren, wenn Inferenz-Services nicht wie WebRTC-Peers agieren müssen
  • Es war besser geeignet, die Komplexität in eine dünne Routing-Schicht zu legen statt in alle Backend-Services oder in benutzerdefiniertes Client-Verhalten
  • Durch das Codieren von Routing-Metadaten in protokollnativen Feldern gewann OpenAI deterministisches Routing des ersten Pakets, eine kleine öffentliche UDP-Grundfläche und die Flexibilität, Ingress weltweit nahe an den Nutzern zu platzieren

  • Besonders wichtige Entscheidungen

    • Protokollsemantik am Edge bewahren: Der Client verwendet weiterhin Standard-WebRTC, sodass Interoperabilität mit Browsern und mobilen Geräten erhalten bleibt
    • Schwierigen Sitzungszustand an einer Stelle halten: Der Transceiver besitzt ICE, DTLS, SRTP und den Sitzungslebenszyklus, während das Relay nur Pakete weiterleitet
    • Für Routing Informationen nutzen, die im Setup bereits vorhanden sind: Das ICE-ufrag liefert einen Hook für das Routing des ersten Pakets ohne Abhängigkeit von Lookups im Hot Path
    • Optimierung des Common Case statt Kernel-Bypass: Eine eng zugeschnittene Go-Implementierung mit sorgfältigem Einsatz von SO_REUSEPORT, Thread-Pinning und parsingarmem, allokationsarmem Design war für OpenAIs Workload ausreichend
    • Echtzeit-Voice-AI funktioniert nur dann gut, wenn die Infrastruktur Latenz unsichtbar macht, und OpenAI entschied sich dafür, die Art der WebRTC-Bereitstellung zu ändern, ohne das von Clients erwartete WebRTC-Verhalten zu verändern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 7 시간 전
Hacker-News-Kommentare

  • Vielen Dank an OpenAI, dass sie einen Anwendungsfall für Pion, die Bibliothek, an der ich arbeite, vorgestellt haben
    Wenn man sich mit WebRTC nicht gut auskennt, ist das ein ziemlich spannendes Gebiet, und ich arbeite auch an einem Buch, das erklärt, wie es funktioniert: WebRTC for the Curious
    https://github.com/pion/webrtc
    https://webrtcforthecurious.com

    • Ich nutze Pion. Trotzdem frage ich mich, ob OpenAIs Ansatz wirklich nötig war
      Es sah so aus, als hätten sie die Komplexität massiv erhöht, um einen Teil der Voice-AI-Architektur zu verkürzen, der ohnehin schon zu den schnellen gehört. Ein schnelles Modell und eine präzise Sprachaktivitätserkennung (VAD) scheinen viel wichtiger zu sein als das Feintuning der WebRTC-Übertragungszeit
    • Danke, dass du das ganze Buch online gestellt hast
      Ich hatte früher einmal die Idee, über einen WebRTC-Datenkanal Daten aus einer Datenbank per CLI an einen Browser-Client zu schicken, und nachdem ich einen Teil gelesen hatte, wurde mir klar, dass das für meinen Anwendungsfall nicht gut passt. Am Ende habe ich eine zentrale Control Plane und WebSocket verwendet
      Trotzdem scheint es, als könnte man mit der Kombination aus WebRTC-Datenkanal + kopierfreiem Apache Arrow ArrayBuffer + duckdb WASM etwas Interessantes bauen, aber ich habe noch nicht herausgefunden, was genau
    • Etwas anderes, aber ich frage mich, warum ihr die gesamte Codebase im Root-Verzeichnis statt in verschachtelten src-Ordnern ablegt
      Dadurch wird es deutlich schwieriger, zur README zu gelangen

  • Niedrige Latenz ist vom Nutzungserlebnis her eher Schmerz als Vorteil
    Wenn man nur locker sprechen will, macht man als Mensch ganz natürlich kurze Pausen, aber GPT versteht das als „Ich bin fertig“ und beginnt sofort loszuplappern
    Mit zunehmendem Alter brauche ich länger, um die richtigen Wörter zu finden, und solche schnellen Voice-GPTs sind eher nervig als hilfreich. Man muss den ganzen Satz schon im Kopf fertig haben, bevor man spricht, und das fühlt sich überhaupt nicht natürlich an

    • Hier werden zwei verschiedene Ebenen von Latenz vermischt
      Die Latenz im Artikel ist die Übertragungslatenz des Audiostreams selbst, während die Latenz in dieser Situation eher damit zu tun hat, wie schnell innerhalb des Audiostreams mit einer Antwort begonnen wird
    • Das habe ich auch erlebt, und es ist wirklich lästig
      Es entsteht ein Druck, weiterzureden, obwohl man noch nicht fertig gedacht hat, und das fühlt sich ziemlich unnatürlich an. Wenn man gerade nach dem passenden Wort sucht, braucht man die Gelegenheit, es zu finden
      Die Lösung ist meiner Ansicht nach kein Protokoll mit höherer Latenz, sondern ein intelligenterer Umgang mit Pausen. Bei niedriger Latenz kann der Bot sofort aufhören zu sprechen, wenn der Nutzer dazwischengeht
    • In Sprachdialogen weise ich es an, überhaupt nicht zu antworten, bis ich ein bestimmtes Codewort sage, oder nur „Verstanden“ zu sagen
      Perfekt ist das nicht, aber es unterbricht weniger
    • Das hängt eher mit Sprachaktivitätserkennung (VAD) zusammen als mit der im Artikel gemeinten Latenz
    • Schwieriges Problem. Ich ertappe mich dabei, unbewusst Füllwörter einzubauen, damit der Bot nicht dazwischenredet
      Außerdem scheint er den Großteil seiner Intelligenz eher darauf zu verwenden, plausibel zu klingen, statt über das Problem nachzudenken. So etwas wie: „Ja, natürlich. Ich verstehe, warum Sie das möchten …“ Vermutlich liegt das an Zeitlimits und daran, dass Sprachverarbeitung teurer ist. Textantworten investieren mehr Zeit in die eigentliche Aufgabe

  • Mit „mehr als 900 Millionen wöchentlich aktive Nutzer“ ist offensichtlich die gesamte ChatGPT-Nutzerschaft gemeint, und der Anteil davon, der Voice-Funktionen nutzt, dürfte viel kleiner sein
    Solche Zahlen beeinflussen Geschäftsentscheidungen, etwa wie viel Hardware- und Softwareoptimierung man in das Problem steckt

    • Genau. Deshalb wurde wohl der Begriff „reach“ verwendet
      Gemeint ist die Gesamtzahl der Nutzer, die potenziell mit der Funktion in Berührung kommen könnten, unabhängig davon, ob sie sie tatsächlich verwenden

  • Es ist schön, dass sie das teilen, aber man sollte im Kopf behalten, dass OpenAIs Realtime-Audio-Modelle leistungsmäßig noch auf dem Niveau der 4o-Familie sind
    Trotzdem ist das nach wie vor sehr nützlich, und es ist schade, dass es in diesem Bereich keine echte Konkurrenz gibt. Das Erlebnis echter Gespräche hat sehr geholfen, Ideen und Konzepte auszudrücken
    Anders als zum Zeitpunkt des Launchs ist es heute nicht mehr das Frontier-Modell, und das sollte man im Hinterkopf behalten. Falls Sam das sieht: Bitte bringt ein neues Realtime-Audio-Modell heraus

    • Im realtime/voice mode von OpenAI ist der Sprachteil hervorragend, aber im Vergleich zu den neuesten Modellen ziemlich dumm und wiederholt oft dasselbe
      Googles Gemini flash live 3.1 ist besser, besonders über die API. Es unterstützt auch Tool-Calling, lässt sich bei eigener Konfiguration an andere, intelligentere LLMs anschließen, und das Reasoning-Niveau ist einstellbar. Selbst ein hohes Reasoning-Niveau bleibt ausreichend nah an Echtzeit, und Antworten können mit der Google-Suche ergänzt werden. Wenn man bidirektionale Sprache mag, ist das derzeit wahrscheinlich die beste Option, und man kann es in AI Studio ausprobieren

  • Für Leute, die in dieses Feld einsteigen wollen, ist pipecat ein gutes Open-Source-Repository und eine gute Community
    https://github.com/pipecat-ai/pipecat

    • Ich wünschte, ich hätte Pipecat viel früher entdeckt
      Ich habe erst vor ein paar Wochen davon erfahren und baue seit dem Release von Gemma 4 von Grund auf einen vollständig lokal laufenden Sprachassistenten mit Gemma 4 + Kokoro TTS + Whisper: https://github.com/pncnmnp/strawberry
      Das Smart-Turn-Modell von Pipecat ist wirklich gut für Sprachaktivitätserkennung (VAD): https://huggingface.co/pipecat-ai/smart-turn-v3

  • Wenn bessere Modelle erst mehr nachdenken und dann antworten, warte ich gern länger auf die Antwort
    Wichtig ist nur, dass Unterbrechungen gut unterstützt werden, nicht schon nach einer Sekunde Pause losgeredet wird und intelligent erkannt wird, ob ich wirklich fertig bin

  • Vielleicht geht es hier nicht nur um Latenz
    Wenn man Nutzer in der Sprachkonversation hält, bekommt man Trainingsdaten, die man über Text niemals erhalten würde. Vielleicht war das der Grund, sich für einen Transceiver-Ansatz statt für ein SFU zu entscheiden und Mehrparteiengespräche weitgehend zu ignorieren

  • Kann man das so lesen, dass OpenAI jetzt LiveKit nicht mehr für WebRTC/Audio verwendet?

    • Sieht so aus
      Für diese Architektur scheint ein LiveKit-Server nicht wirklich die gewünschte Form zu haben. Die Diskussion über SFUs im Artikel sagt das im Grunde auch. Für Client-SDKs gibt es dort aber viele nützliche Dinge

  • Wenn ein Transceiver mitten im Stream abstürzt, wie wird eine aktive Sitzung wiederhergestellt?
    Stellt das System den Kontext automatisch in einer neuen WebRTC-Sitzung wieder her?

  • Wenn du Freunde finden willst, ist es wahrscheinlich besser, in irgendeiner Form einem Club oder Treffen beizutreten