GPT-Live-Full-Duplex-API: Architektur für Sprachagenten

Ein Sprachagent, der erst nach einer Sprechpause mit dem Denken beginnt, kann zwar schnell reagieren und trotzdem roboterhaft wirken. GPT-Live geht dieses Problem auf Architekturebene an: Das System hört kontinuierlich zu und spricht gleichzeitig, während Suche, Tools und aufwendigere Schlussfolgerungen parallel zum Audiopfad laufen – nicht innerhalb davon. Das sorgt für natürlichere Gespräche, macht den Betrieb aber deutlich anspruchsvoller.

Die GPT-Live-Full-Duplex-Architektur in einer Minute

GPT-Live ist nicht einfach ein schnellerer Speech-to-Speech-Endpunkt. OpenAI beschreibt das System als Full-Duplex-Sprachlösung, die eingehendes Audio verarbeitet, während sie bereits Audio ausgibt, mehrmals pro Sekunde Interaktionsentscheidungen trifft und aufwendigere Aufgaben an ein Frontier-Modell delegiert. Laut dem Engineering-Beitrag von OpenAI basiert die Architektur auf gestreamter Inferenz, einer zustandsbehafteten Unterhaltung, WebRTC als Transport und asynchronen Vorgängen außerhalb des Medienpfads.

Das praktische Schichtenmodell sieht so aus:

Die entscheidende Veränderung betrifft die Kontrolle über die Zeit. Bei einem klassischen Sprachagenten wartet die Anwendung auf einen Nutzerbeitrag, schickt ihn an ein Modell und spielt anschließend die Antwort ab. In der GPT-Live-Architektur bleibt die Sprachsitzung aktiv, während mehrere Arten von Arbeit gleichzeitig laufen.

Die alte Annahme strikt getrennter Gesprächsrunden gehört in den Hintergrund

Kaskadierte Sprachsysteme führen Speech-to-Text, Sprachmodell und Text-to-Speech nacheinander aus. Native Speech-to-Speech-Modelle reduzieren einige dieser Übergaben. Trotzdem kann ein separater Voice-Activity-Detector weiterhin entscheiden, ob der Nutzer fertig gesprochen hat, bevor die Inferenz startet. Eine kurze Denkpause kann dann wie das Ende eines Gesprächsbeitrags wirken, während Hintergrundgeräusche als neuer Beitrag interpretiert werden.

GPT-Live verlagert dieses Timing-Problem in das Sprachmodell. Es kann weiter zuhören, während es spricht, Unterbrechungen erkennen, pausieren, fortfahren oder eine kurze Bestätigung geben. Gesprächsgrenzen verschwinden dadurch nicht überall. Sie dürfen den laufenden Audiopfad nur nicht mehr blockieren.

Was GPT-Live am laufenden Audiopfad verändert

Kontinuierliche Inferenz statt Gesprächsfreigabe nach Sprechpause

In einer Full-Duplex-Sitzung sind Ein- und Ausgabe Streams und keine abwechselnden Audio-Blöcke. Das Modell kann neue Sprache empfangen, während die vorherige Antwort noch ausgegeben wird. Es entscheidet selbst, ob das eingehende Audio eine echte Unterbrechung, eine kurze Bestätigung oder lediglich ein Hintergrundgeräusch ist.

Das verändert die Logik auf Clientseite. Ein Client muss Audio-Events gleichzeitig senden, empfangen, abbrechen und ersetzen können. Eine einzelne Abstraktion wie await response() passt schlecht zu diesem Verhalten, weil sie gerade die wichtigen Ereignisse verbirgt: Sprechen begonnen, Assistenten-Audio gestartet, Unterbrechung erkannt, Tool angefordert, Antwort abgebrochen und Sitzung beendet.

Signale der Spracherkennung sollten trotzdem für UI, Analytics und Sicherheitsfunktionen erhalten bleiben. Der Architekturfehler besteht darin, VAD als alleinige Instanz darüber entscheiden zu lassen, wann die Modellinferenz starten darf.

Medienpfad schlank halten, aufwendige Arbeit auslagern

OpenAIs Engineering-Beitrag trennt den dedizierten Audiopfad von der Anwendungslogik. Das Audio läuft direkt zwischen Client und Sprachmodell, während Tool-Aufrufe, Richtlinienprüfungen, Persistenz und Backend-Operationen über eine asynchrone Grenze abgewickelt werden.

Diese Trennung schafft eine klare Regel: Eine langsame CRM-Abfrage darf ihre eigene Antwort verzögern, aber nicht verhindern, dass Audio-Frames rechtzeitig eintreffen. WebRTC stellt den latenzarmen Medientransport bereit. Anwendungsdienste sollten nicht synchron zwischen jedem Mikrofon-Frame und dem Modell liegen.

Während eine delegierte Aufgabe läuft, kann die Sprachschicht kurz reagieren. Füllsätze sind aber kein Ersatz für einen begrenzten, kontrollierten Job. Für jedes Tool braucht es Fristen, Abbruchregeln und einen sicheren Ergebnisstatus.

Delegation trennt Reaktionsgeschwindigkeit und Modellintelligenz

GPT-Live kann Suche, aufwendigere Schlussfolgerungen oder komplexe Aufgaben an ein Frontier-Modell delegieren. In den Launch- und Engineering-Beiträgen nennt OpenAI GPT-5.5 als delegiertes Modell zum Start. Das Sprachmodell bleibt für die unmittelbare Interaktion zuständig; das Frontier-Modell übernimmt Aufgaben, die schlecht in einen latenzarmen Sprachdialog passen.

In einer produktiven Implementierung sollte Delegation als eigener Ablauf behandelt werden:

1. Erkennen, dass die Anfrage Suche, Schlussfolgerungen oder ein Tool benötigt.
2. Bestätigen oder pausieren, ohne den Medienpfad zu blockieren.
3. Den Hintergrundjob mit dem relevanten Gesprächskontext starten.
4. Den Job abbrechen, wenn der Nutzer das Thema wechselt oder die Sitzung beendet.
5. Das Ergebnis in der Anwendung validieren.
6. Ein kompaktes Ergebnis in die laufende Sitzung zurückgeben.

Eine vorab initialisierte Inferenzsitzung, stabile Session-Affinität und zwischengespeicherter Kontext können die Zeit bis zu einer brauchbaren Ausgabe verkürzen. Das Ende-zu-Ende-Budget umfasst Routing, Prompt-Verarbeitung, Modellinferenz, Tool-Aufrufe und jede einzelne Runde zwischen Modell und Tool – nicht nur die Latenz der Modell-Tokens.

Zustandsbehaftete Sitzungen brauchen eine zweite Architektur

Ein längeres Sprachgespräch ist keine Abfolge wegwerfbarer Anfragen. Der Kontext wächst, Modell-Worker wechseln und die Sitzung muss möglicherweise kompaktiert werden. OpenAI beschreibt, wie eine Ersatzinstanz aufgewärmt, mit dem aktuellen Kontext vorbefüllt und erst nach ihrer Bereitschaft aktiviert wird. So bleibt der Infrastrukturwechsel für den Anrufer unhörbar.

Die Kompaktierung des Kontexts erzeugt ein ähnliches Problem. Wenn frühere Gesprächsbeiträge zusammengefasst werden, verändert sich der Kontext, auf dem der Key-Value-Cache des Modells basiert. Diesen Cache im Vordergrund neu aufzubauen, würde eine Pause erzeugen. Robuster ist es, den Kontext parallel zu komprimieren, eine Ersatzinstanz vorzubereiten und die alte Instanz so lange weiterlaufen zu lassen, bis die Übergabe möglich ist.

Der Sitzungsstatus eines Sprachagenten-Backends sollte deshalb mehr umfassen als nur ein Transkript:

• Aktueller Audio- und Antwortstatus
• Aktive Tool-Aufrufe und Abbruch-Token
• Affinität zu Modellinstanz oder Worker
• Vorläufige und endgültige Nachrichten
• Status der Kontextkompaktierung
• Status für Wiederverbindung und Wiederherstellung
• Sicherheits- und Bestätigungsstatus

Der API-Vertrag ist ein Ereignissystem, kein Frage-Antwort-Ablauf

Full Duplex verändert das interne Protokoll, selbst wenn die externe API später vertraute SDK-Methoden anbietet. Die Anwendung muss Ereignisse, die häufig in einen Topf geworfen werden, ausdrücklich unterscheiden:

GPT-Live kann kontinuierlich arbeiten. Der Rest des Produkts braucht trotzdem Nachrichten für UI, Analytics und Sicherheitssysteme. OpenAI beschreibt eine spekulative Ansicht, die bei eintreffenden Transkripten überarbeitet werden kann, sowie einen maßgeblichen Datensatz, der später finalisiert wird. Das ist ein sinnvolles Muster: Reaktionsschnelle Untertitel anzeigen, aber kein vorläufiges Transkript als unveränderliche Tatsache behandeln.

Was Teams für Sprachagenten neu entwerfen müssen

Medienadapter und Agenten-Orchestrierung trennen

Provider-spezifischen Transport und Event-Handling sollte ein Adapter kapseln. Die Anwendung verarbeitet stattdessen normalisierte Ereignisse wie user_audio_started, assistant_interrupted, tool_requested, confirmation_required und response_completed.

Modell-ID, Stimme, Prompts, Tool-Schemata und Kostenlimits gehören in die Konfiguration. Das ist nicht nur eine Absicherung für spätere Migrationen. So kann ein Team heute ein dokumentiertes Realtime-Modell testen und gleichzeitig ein klares Ziel für die GPT-Live-Semantik bewahren.

Bei Tools gilt: Das Modell macht einen Vorschlag, die Anwendung validiert ihn. Zahlungen, Kontoänderungen, Kündigungen, Adressänderungen, medizinische Triage, Finanzaktionen und Identitätsprozesse brauchen Bestätigungsregeln außerhalb der gesprochenen Sicherheit des Modells.

Den Transport danach auswählen, wo das Audio kontrolliert wird

WebRTC passt besonders gut zu Browser- und Mobile-Clients, die Audio direkt aufnehmen und wiedergeben. WebSocket kann für serverseitig gesteuerte Medienpipelines weiterhin sinnvoll sein. Teams sollten aber nicht davon ausgehen, dass jedes Realtime-Modell über jeden Transport dieselbe Sitzungsstruktur unterstützt.

Ein Integrationsproblem in OpenClaw dokumentiert den praktischen Fehlerfall: Als gpt-live-1 wie eine gewöhnliche GA-Realtime-WebSocket-Sitzung behandelt wurde, kam eine invalid_model-Antwort zurück. Der vorgeschlagene GPT-Live-Browser-Ablauf nutzte dagegen eine eigene WebRTC-Sitzungsstruktur. Das Problem ist ein Implementierungsbericht und kein API-Vertrag von OpenAI. Es bestätigt aber die Designregel: Modellfamilie erkennen und den unterstützten Sitzungstyp ausdrücklich aushandeln.

Rechtzeitig zugestellte Frames messen, nicht nur Token-Latenz

OpenAIs Engineering-Beitrag berichtet, dass sich in Produktionstests eine unterstützende Stream-Komponente füllte, bevor die GPU-Kapazität ausgeschöpft war. Die relevante Kapazitätsgröße waren nachhaltig gleichzeitig betreibbare Sitzungen mit pünktlicher Frame-Zustellung – nicht die Zahl der Anfragen pro GPU.

Mindestens diese Werte sollten erfasst werden:

• Verspätete und verlorene Audio-Frames
• Zeit bis zum ersten abspielbaren Audio
• Zeit zwischen Unterbrechung und Stopp
• Gleichzeitige Sitzungen nach Region
• Wiederverbindungen und doppelte Tool-Aufrufe
• Abschlusszeit delegierter Aufgaben
• Quoten für Tool-Timeouts und Abbrüche
• Korrekturen vom vorläufigen zum endgültigen Transkript
• Abgebrochene Sitzungen und Kosten pro Sitzung

Auch die Natürlichkeit hat eine Steuerungsseite. In einem Kontext schätzen echte Nutzer Unterbrechungen und kurze Bestätigungen, in einem anderen empfinden sie dasselbe Verhalten als störend. Ein früher Nutzerbericht brachte das Risiko unverblümt auf den Punkt: „It's literally cutting her off constantly lmao“ (@AutismCapital). Das sollte als Hinweis dienen, die Barge-in-Regeln anhand echter Gespräche und nicht anhand von Demo-Skripten zu justieren.

GPT-Live oder das heutige Realtime-Design?

Im offiziellen OpenAI-Modellkatalog wird GPT-Live 1 inzwischen als Modell für natürliche, ausdrucksstarke Sprachgespräche positioniert. Hervorgehoben wird außerdem der reibungslose Umgang mit Unterbrechungen. Der Katalog ist jedoch nicht dasselbe wie ein vollständiger Integrationsvertrag: Die hier betrachtete separate GPT-Live-API-Seite besteht weiterhin aus einem Benachrichtigungsformular ohne Angaben zu Endpunkten, Raten oder Limits. Vor einer verbindlichen Planung sollten Teams deshalb die aktuelle Entwicklerdokumentation und die Berechtigung für das eigene Konto prüfen.

Die Architektur lohnt sich auch dann, wenn das Modell noch nicht für jedes Konto verfügbar ist. Kontinuierliche Medienverarbeitung, normalisierte Ereignisse, asynchrone Tools und explizite Abbrüche verbessern auch Sprachagenten, die auf einem herkömmlichen Realtime-Modell basieren.

GPT-Live-Full-Duplex-API: Häufige Fragen

Ist GPT-Live dasselbe wie GPT-Realtime?

Nein. OpenAI führt GPT-Live als eigenständige Modellfamilie für Sprachgespräche, während GPT-Realtime zur dokumentierten Realtime-API-Familie gehört. Ähnliche Audiofunktionen bedeuten nicht automatisch identische Sitzungssemantik, Transporte oder Modell-IDs.

Bedeutet Full Duplex, dass das Modell nie wartet?

Nein. Es bedeutet, dass das System gleichzeitig zuhören und sprechen kann. Das Modell kann weiterhin pausieren, schweigen, eine Klärung abwarten oder ein delegiertes Ergebnis zurückhalten, wenn das sicherer oder hilfreicher ist.

Brauchen Entwickler weiterhin VAD?

Ja – für Medien-UX, Analytics, Untertitel und Sicherheitssignale. VAD sollte jedoch nicht die einzige Instanz sein, die das Modell in eine starre Abfolge aus Nutzerbeitrag und Assistentenantwort zwingt.

Welchen Transport sollte ein Sprachagent verwenden?

Den für den jeweiligen Client und das jeweilige Modell unterstützten Transport. WebRTC eignet sich grundsätzlich für direkte Audioverarbeitung im Browser oder auf dem Smartphone; Backend-Medienpipelines können dort, wo es dokumentiert ist, WebSocket verwenden. Aus dem Modellnamen allein lässt sich keine Transport-Unterstützung ableiten.

Was sollte gebaut werden, bevor der Zugang bestätigt ist?

Adapter, normalisiertes Ereignisschema, Tool-Validierung, Abbruchmodell, Kosten-Telemetrie, Fallbacks und die Wiederherstellung langer Sitzungen. Diese Komponenten bleiben nützlich, falls sich der endgültige GPT-Live-API-Vertrag noch ändert.

Die Architektur entscheidet – nicht der Modellname

Die nachhaltige Entscheidung lautet, Sprache nicht länger als Request-Response-Hülle um ein Textmodell zu behandeln. Der Audiopfad muss kontinuierlich verfügbar bleiben, langsame Arbeit gehört hinter asynchrone Grenzen, Unterbrechungen und Abbrüche müssen zentrale Ereignisse sein, und ein Transkript sollte überarbeitet werden können, bevor es zum maßgeblichen Datensatz wird.

Der Zielkonflikt bei GPT-Live ist klar: Natürlichere Überlappungen und Delegation erfordern mehr Zustandsverwaltung, bessere Beobachtbarkeit und weniger Kontrolle durch einfache Gesprächsgrenzen. Teams, die diese Komplexität akzeptieren, können bereits jetzt für den Full-Duplex-Vertrag entwerfen. Wer einen dokumentierten Produktionsendpunkt braucht, sollte mit Realtime starten – und dieselben ereignisgesteuerten Schnittstellen vorsehen.