Gemini 3.8 Live für $0,023/Min: Google unterbietet klassische Voice-AI-Stacks

Google hat Gemini 3.8 Live am 15. September zu einem Preis von $0,005 pro Minute für Audio-Input und $0,018 pro Minute für Output veröffentlicht. Das ergibt $0,023 pro Minute bidirektionaler Konversation – oder rund $1,38 pro Stunde Live-Voice-Agent-Zeit, bevor Tool-Call-Latenz, Streaming-Infrastruktur oder Telefonie-Egress hinzukommen. Für alle, die heute einen kaskadierten Speech-to-Text-plus-LLM-plus-Text-to-Speech-Pipeline betreiben, ist das die Zahl, an der man sich dieses Quartal messen lassen muss.

Was passiert ist

Wie blog.google berichtete, hat Google DeepMind drei neue Audio-Modelle in die Gemini API und Google AI Studio eingebracht: Gemini 3.8 Live, Gemini 3.8 Live Extended Thinking und – einen Monat früher veröffentlicht – Gemini 3.5 Transcribe. Der Beitrag wurde von Alisa Fortin, Produktmanagerin bei DeepMind, und Thor Schaeff vom DevX-Technologieteam verfasst.

Die wichtigsten Funktionen: 3.8 Live ist ein natives Speech-to-Speech-Modell, das Aufgaben ausführen kann, während es einen Dialog führt. Die Extended-Thinking-Variante ergänzt konfigurierbares Hintergrunddenken für mehrstufige Anfragen und belegt laut Google derzeit Platz 1 auf dem Speech-to-Speech-Leaderboard von Artificial Analysis. Die Sprachabdeckung umfasst 97+ Sprachen für die Live-Modelle und 85+ für Transcribe. 3.5 Transcribe erzielt eine durchschnittliche Word Error Rate (WER) von 4,0 % im Streaming-Modus und 2,6 % im Non-Streaming-Modus, mit benutzerdefinierter Vokabular-Gewichtung für bis zu 1.000 Begriffe und einem Smart-Modus, der Füllwörter entfernt.

Der Vertrieb ist gezielt gestaltet. Die Live-Modelle werden über die Live API mit benannten Integrationspartnern ausgeliefert, die die Media-Plane übernehmen: Agora, Fishjam, LiveKit, LangChain, Pipecat, Vercel und Vision Agents. Transcribe ist auch über die Interactions API erreichbar, die Audiodateien bis zu einer Stunde mit strukturierten Zeitstempeln und Sprecher-Labels akzeptiert. Google rundete die Ankündigung ab, indem es den Launch mit drei benachbarten Modellen verknüpfte, die bereits in der API verfügbar sind: Gemini 3.5 Live Translate (70+ Sprachen, Speech-to-Speech), Gemini 3.1 Flash TTS und Lyria 3.5 für Musikgenerierung.

Technische Architektur

Die zentrale architektonische Aussage lautet: 3.8 Live ist nativer Speech-to-Speech, kein Kaskaden-Ansatz. Ein klassischer Voice-Agent-Stack sieht so aus: Audio rein, ASR-Modell, LLM, TTS-Modell, Audio raus. Jeder Sprung addiert Latenz (typischerweise 150 bis 400 ms pro Stufe im Produktionsbetrieb) und jeder Sprung verliert Informationen: Prosodie, Zögerlichkeit, Code-Switching-Signale, Hintergrundgeräusche. Ein natives Speech-to-Speech-Modell fasst diese Stufen in einem einzigen Forward-Pass zusammen – deshalb kann die Extended-Thinking-Variante „seinen Fortschritt kommentieren", während im Hintergrund Schlussfolgerungen gezogen werden, anstatt auf eine Textrunde zu warten.

Fünf Funktionen sind für Entwicklungsteams bei der Evaluierung relevant. Asynchrones Function Calling ermöglicht es dem Modell, weiterhin Audio an den Nutzer zu streamen, während ein Tool Call im Hintergrund läuft – das ist der größte einzelne UX-Defekt aktueller Voice Agents (die unangenehme Stille, während der LLM auf eine Datenbankabfrage wartet). Visual Context Grounding akzeptiert Live-Bildinput zusammen mit Audio. Alphanumerische Präzision wird explizit für Bestätigungscodes und Vorgangsnummern hervorgehoben – ein klares Signal für das Segment, das Google anvisiert: Contact Center. Inkrementelle Content-Updates fügen strukturierte Daten mitten in die Audio-Antwort ein. Konfigurierbares Thinking bei der Extended-Thinking-Variante ist der Hebel, den Entwickler nutzen werden, um Latenz gegen Denk-Tiefe abzuwägen.

Auf der Transkriptionsseite ist die WER von 2,6 % im Non-Streaming-Modus die Zahl, die Branchenerwartungen neu setzt. Zum Vergleich: Menschliche Transkribenten erzielen bei konversationalem Englisch typischerweise 4 bis 5 %. Der Streaming-Wert von 4,0 % ist für Echtzeit-Untertitel und Call-Center-Analysen relevanter, da Streaming-WER normalerweise 1 bis 2 Prozentpunkte schlechter ist als im Batch-Betrieb. Die benutzerdefinierte Vokabular-Gewichtung mit 1.000 Begriffen ist eine bedeutsame Obergrenze, obwohl Google nicht offenlegt, ob die Gewichtung die allgemeine Erkennungsgenauigkeit beeinträchtigt, wenn die Liste stark belastet ist – und genau das ist der Fehlermodus, den Teams im Produktionsbetrieb tatsächlich erleben. Noch unklar ist, wie empfindlich die WER auf verrauschtes Telefonieaudio (8-kHz-Schmalband) reagiert, und die Quelle schlüsselt die WER nicht nach Sprache für die 85+ unterstützten Sprachen auf.

Wer unter Druck gerät

Am stärksten exponiert sind eigenständige Echtzeit-Transkriptionsanbieter, deren gesamter Wettbewerbsvorteil auf Streaming-ASR-Genauigkeit basiert. Wenn ein Hyperscaler 4,0 % Streaming-WER als universelle API ausliefert, ist der Preisdruck auf spezialisierte ASR-Anbieter eindeutig. In den nächsten zwei Quartalen werden deren Verkaufsgespräche voraussichtlich von Genauigkeits-Benchmarks zu Compliance, On-Premises-Deployment und branchenspezifischen Vokabularen wechseln, bei denen die 1.000-Begriffe-Liste nicht ausreicht.

Zweite Gruppe: Entwickler kaskadierter Voice-Agent-Frameworks. Die benannten Live-API-Partner (LiveKit, Pipecat, Vercel, Agora, Fishjam, LangChain, Vision Agents) sind als Media-Plane- und Orchestrierungsschichten positioniert, nicht als Modellanbieter. Das ist eine überlebensfähige Position. Framework-Projekte, die versuchten, die ASR-zu-LLM-zu-TTS-Orchestrierung selbst zu gestalten, haben nun einen Wettbewerber, dessen Latenz-Floor sie nicht erreichen können – weil sie immer noch für drei Netzwerk-Hops zahlen, während 3.8 Live für einen zahlt.

Dritte Gruppe: iGaming- und Fintech-Voice-Verifikations-Workflows. Alphanumerische Präzision bei Bestätigungscodes und Vorgangsnummern zeigt, dass Google direkt auf KYC-Callbacks, Einzahlungsbestätigungen und Support-Triage zielt. Die 97+ Sprachabdeckung ist hier relevant, weil genau das die Workflows sind, bei denen ein europäischer Betreiber Kunden in fünfzehn Regionen bedient und keine fünfzehn separaten ASR-Verträge möchte.

Vierte Gruppe: OpenAIs Realtime API konkurriert nun gegen einen veröffentlichten Leaderboard-Rang und einen konkreten Minutenpreis. Die OpenAI-Dokumentation listet die Realtime-Preise getrennt für Audio-Input- und Output-Token auf, was den direkten Vergleich für Beschaffungsteams umständlich macht. Googles pauschale Minutenpreise sind einfacher in einer Tabelle zu modellieren, und das allein wird RFP-Entscheidungen beeinflussen. Meine Prognose: Innerhalb von 90 Tagen sollte mindestens ein großer Voice-Agent-Anbieter einen öffentlichen Vergleich veröffentlichen, der die 3.8-Live-Latenz mit seiner bestehenden Pipeline vergleicht. Falls nicht, ist davon auszugehen, dass die Zahlen ungünstig ausfallen.

Leitfaden für die KI-Entwicklung

Konkrete Maßnahmen für Entwicklungsverantwortliche diese Woche. Erstens: ein Kostenmodell erstellen. Die durchschnittliche Sitzungslänge des aktuellen Voice Agents nehmen und mit $0,023 pro Minute bidirektionalem Audio multiplizieren. Wenn die bestehende STT-plus-LLM-plus-TTS-Rechnung pro Sitzung mehr als grob das 1,5-Fache dieses Betrags beträgt, gibt es ein Migrationsszenario, das es wert ist, schriftlich festgehalten zu werden. Liegt der Wert darunter, sind die Wechselkosten wahrscheinlich noch nicht gerechtfertigt.

Zweitens: WER am eigenen Audiomaterial benchmarken, nicht an LibriSpeech oder den Marketing-Clips des Anbieters. Der Non-Streaming-Wert von 2,6 % ist ein Durchschnitt über Googles Evaluierungsdatensatz. Call-Center-Audio mit drei gleichzeitig sprechenden Personen auf einer verrauschten Leitung wird diesen Wert nicht erreichen. Ein Korpus von 200 Beispielen aus der Produktion ziehen, durch 3.5 Transcribe über die Interactions API laufen lassen und mit dem bestehenden Anbieter vergleichen.

Drittens: asynchrones Function Calling gegen einen realistischen Tool-Graphen testen. Der Demo-Fall ist einfach; der Produktionsfall ist ein Kunde, der eine Frage stellt, die zwei sequentielle Datenbankabfragen und einen API-Aufruf eines Drittanbieters erfordert. Messen, wie das Modell den Fortschritt kommentiert und ob es halluziniert, während der Tool Call noch aussteht.

Viertens: Wer Agent-Orchestrierung aufbaut, sollte die Live-API-Partnerliste als Signal dafür betrachten, wo Google die Media-Plane ansiedelt. Die Integration mit einem der sieben Partner ist jetzt die risikoärmere Architekturentscheidung als der Aufbau einer eigenen WebRTC-Schicht. MCP-Muster für die Tool-Call-Seite in Betracht ziehen, um nicht an das Function-Calling-Schema eines einzelnen Modellanbieters gebunden zu sein.

Wichtige Erkenntnisse

• Gemini 3.8 Live wird zu $0,023/Min bidirektionalem Audio berechnet ($0,005 Input, $0,018 Output) und setzt einen öffentlichen Benchmark für die Wirtschaftlichkeit kaskadierter Voice-Stacks.
• Gemini 3.5 Transcribe erzielt 2,6 % Non-Streaming-WER und 4,0 % Streaming-WER über 85+ Sprachen und setzt eigenständige Echtzeit-ASR-Anbieter unter Druck.
• Natives Speech-to-Speech mit asynchronem Function Calling löst das Problem der unangenehmen Stille, das kaskadierte Voice Agents während Tool Calls plagt.
• Die Live API startet mit sieben benannten Media-Plane-Partnern, darunter LiveKit, Pipecat und Agora, was Googles bevorzugte Deployment-Topologie signalisiert.
• Offene Fragen, die es zu testen gilt: WER-Verschlechterung bei 8-kHz-Telefonieaudio, Genauigkeits-Trade-off bei nahezu vollständig ausgelasteter custom_vocabulary-Liste (1.000 Begriffe) und WER-Varianz nach Sprache über die 85+ unterstützten Sprachen.