DeepSeek V4.1 Flash + Eleven v3 im Vergleich mit Full-Duplex-Sprachsystemen: So lassen sich die Architekturen vergleichen

Die eigentliche Entscheidung: Architektur statt Modellwettbewerb

Bei der Wahl zwischen einer Kette aus automatischer Spracherkennung (ASR), einem Textmodell und Sprachsynthese und einem Full-Duplex-Sprachmodell werden nicht zwei austauschbare Modelle miteinander verglichen. Es geht um Systeme mit unterschiedlichen Komponenten, Schnittstellen und Interaktionsweisen. Die erste Architektur trennt einzelne Aufgaben; die zweite kann Audio innerhalb einer integrierten Sprachinteraktion empfangen und ausgeben. Entscheidend sollte sein, wie sich die vollständige Lösung in einem konkreten Gespräch verhält.

Eine modulare Kette kann DeepSeek V4.1 Flash als Antwortgenerator, einen ASR-Dienst zur Umwandlung eingehender Sprache in Text und Eleven v3 zur Umwandlung der Textantwort in Sprache kombinieren. Zusätzlich benötigt sie eine Koordinierungsschicht: Sie muss Gesprächswechsel verwalten, den Kontext erhalten, den Zeitpunkt für Anfragen festlegen und Werkzeuge einbinden. Verzögert sich eine dieser Komponenten oder fällt sie aus, beeinträchtigt das die Nutzererfahrung – selbst wenn die übrigen Teile einwandfrei funktionieren.

Als Full-Duplex-Alternativen lassen sich GPT-Live 1 und Gemini 3.8 Live prüfen, sofern das Team Zugriff auf die relevanten Schnittstellen hat und die getesteten Versionen festlegt. OpenAI beschreibt GPT-Live 1 als Full-Duplex-Modell, während Google Gemini 3.8 Live als Modell für Audio in Echtzeit dokumentiert. Diese Beschreibungen begründen, warum die Modelle als Kandidaten in Frage kommen; sie beweisen jedoch nicht, dass sie für einen bestimmten Anwendungsfall besser geeignet sind.

Die überprüfbare These lautet nicht, dass eine Architektur grundsätzlich überlegen ist. Eine modulare Lösung kann mehr Kontrolle über die Auswahl und den Austausch von Komponenten bieten; eine integrierte Lösung kann bestimmte Übergänge zwischen Diensten vermeiden. Das Ergebnis hängt von Aufgabe, Implementierung, Netzwerk, Sprache, Zugangsbedingungen und den Kriterien ab, nach denen ein Gespräch als erfolgreich bewertet wird.

Was die einzelnen Komponenten leisten

DeepSeek V4.1 Flash übernimmt in der modularen Kette die Rolle des Textantwortgenerators. Die API-Dokumentation beschreibt eine Chat-Schnittstelle, die Textstreaming und Werkzeugaufrufe unterstützt. In einer Anwendung kann das Modell den transkribierten Text, den Kontext und die Anweisungen erhalten und eine Antwort oder eine strukturierte Anforderung an ein Werkzeug zurückgeben. Die Anwendung muss diesen Ablauf selbst umsetzen: Ein Werkzeugaufruf ist für sich genommen weder die Ausführung des Werkzeugs noch ein abgeschlossenes Sprachgespräch.

Im Änderungsprotokoll kündigte DeepSeek V4.1 Flash und die Kennung `deepseek-flash` an und erwähnte außerdem eine vorübergehende Weiterleitung einiger früherer Aliasnamen. Für einen reproduzierbaren Test sollten daher die verwendete Kennung, das Datum, die Umgebung und alle relevanten Einstellungen festgehalten werden. Ohne Prüfung des tatsächlich angesprochenen Dienstes zum Testzeitpunkt sollte aus einem Alias keine dauerhafte Modellidentität abgeleitet werden.

Dass die Dokumentation DeepSeek V4.1 Flash native visuelle Fähigkeiten zuschreibt, belegt nicht, dass das Modell eingehendes oder ausgehendes Audio für Gespräche unterstützt. Der Leitfaden zu visuellen Fähigkeiten behandelt Bildmodalitäten. In der hier vorgeschlagenen Architektur muss eingehendes Audio daher über ein ASR-System verarbeitet werden, sofern nicht ein anderer kompatibler Weg dokumentiert und evaluiert wird. Visuelle Fähigkeiten als Beleg für Audiounterstützung anzuführen, würde unterschiedliche Modalitäten verwechseln.

Eleven v3 erfüllt eine andere Aufgabe: Es ist ein Text-zu-Sprache-Modell. Es erhält Text und erzeugt daraus Sprache. Es ersetzt weder das Modell, das entscheidet, was geantwortet wird, noch die Spracherkennung, die die Äußerungen des Nutzers interpretiert. Die Dokumentation des Anbieters weist außerdem darauf hin, dass das beschriebene Modell nicht für Gespräche in Echtzeit vorgesehen ist. Vor einem Vergleich muss deshalb geprüft werden, welches konkrete Produkt und welche Schnittstelle eingesetzt werden. Es darf nicht vorausgesetzt werden, dass sich damit dieselbe inkrementelle Interaktion wie mit einer Full-Duplex-Sprachschnittstelle umsetzen lässt.

Auch die Full-Duplex-Architektur sollte nicht als undurchsichtige Blackbox behandelt werden. Das Team muss Modell und Schnittstelle festlegen, verstehen, wie Werkzeuge verwaltet werden, und die Bedingungen des Dienstes dokumentieren. GPT-Live 1 wird als Full-Duplex-Modell beschrieben und unterstützt die Delegation an einen Backend-Agenten sowie an Werkzeuge; Gemini 3.8 Live ist als Audio-zu-Audio-Option mit Echtzeit-Interaktionsfunktionen dokumentiert. Welche Funktionen tatsächlich verfügbar sind, kann von der Schnittstelle und den jeweils geltenden Bedingungen abhängen. Diese müssen bei der Vorbereitung des Tests überprüft werden.

Konfigurationen vor dem Test festlegen

Der Vergleich sollte mit zwei dokumentierten Konfigurationen beginnen, nicht mit Produktnamen. Die erste ist die modulare Kette: Audioaufnahme, ASR, Gesprächssteuerung, DeepSeek V4.1 Flash, optionale Werkzeugausführung und Eleven v3 für die gesprochene Antwort. Die zweite ist eine ausgewählte Full-Duplex-Konfiguration. Werden zwei Full-Duplex-Modelle getestet, gilt jedes als eigene Konfiguration und benötigt ein separates Datenblatt.

Halten Sie Modellkennungen, Schnittstelle, gegebenenfalls Region oder Zugangsbedingungen, veränderbare Parameter, Testdatum und Versionen der Client-Software fest. Dokumentieren Sie bei der modularen Kette außerdem den ASR-Anbieter und dessen Version, die Regeln zur Aufteilung des Textes in Abschnitte, Abbruchregeln und den Synthesemodus. Beim Full-Duplex-System sollten Sie festhalten, wie Daten gesendet und empfangen werden, wie Werkzeuge aktiviert werden und welche Einschränkungen gelten. Ist ein Detail weder in der Dokumentation bestätigt noch in der beobachteten Konfiguration eindeutig feststellbar, kennzeichnen Sie es als unbekannt, anstatt die Lücke mit einer Annahme zu füllen.

Verwenden Sie für alle Systeme denselben Aufgabenkorpus und dieselben funktionalen Anweisungen. Für jeden Testlauf sollte dieselbe Audiodatei oder Aufnahme verwendet werden, mit kontrollierten Pegeln und vergleichbaren Bedingungen. Zwingen Sie ein System nicht dazu, ein Format auszugeben, das seine Schnittstelle nicht unterstützt: Beschreiben Sie die Unterschiede und bewerten Sie den tatsächlich vorgesehenen Bereitstellungsablauf. So vermeiden Sie einen künstlichen Wettbewerb zwischen inkompatiblen Implementierungen.

Ein gemeinsames Protokoll für Gespräche, Unterbrechungen und Werkzeuge

Der Testsatz sollte kurze Aufgaben und mehrteilige Gespräche enthalten. Kombinieren Sie Fragen mit bekannten Antworten, Anweisungen mit Einschränkungen, Anfragen, die ein Werkzeug erfordern, und mehrdeutige Anliegen, bei denen eine Rückfrage sinnvoll wäre. Fügen Sie Eigennamen, Mengen, Datumsangaben und laut ausgesprochene Zahlen hinzu. Solche Elemente machen Fehler sichtbar, die bei einer Prüfung, die nur flüssig klingende Antworten bewertet, möglicherweise übersehen werden.

Berücksichtigen Sie unterschiedliche Sprechbedingungen: verschiedene für die Zielgruppe relevante Akzente, verschiedene Sprechgeschwindigkeiten, Pausen, Selbstkorrekturen und realistische Geräuschpegel. Gehen Sie nicht davon aus, dass eine Auswahl an Akzenten alle Sprecher repräsentiert. Beschreiben Sie, wer die Aufnahmen erstellt hat, wie das Audio gewonnen wurde und welche Grenzen die Stichprobe hat. Um Robustheit zu bewerten, wiederholen Sie den Test mit denselben Audioaufnahmen unter vergleichbaren Bedingungen und nicht mit einem anderen Satz für jeden Anbieter.

Testen Sie Unterbrechungen ausdrücklich. Bitten Sie das System beispielsweise um eine längere Antwort und unterbrechen Sie die Wiedergabe mit einer Korrektur oder einer anderen Frage. Halten Sie fest, ob das System aufhört zu sprechen, wie lange das dauert, ob es die neue Anweisung berücksichtigt und ob es den Gesprächskontext angemessen wieder aufnimmt. Aus einer isolierten Messung der Textgenerierung oder Sprachsynthese lässt sich nicht ableiten, ob Unterbrechungen korrekt behandelt werden.

Verwenden Sie für Werkzeuge eine Aufgabe mit überprüfbarem Ergebnis sowie einen kontrollierten Dienst oder Datensatz. Messen Sie, ob das Modell korrekt entscheidet, dass ein Werkzeug benötigt wird, ob es gültige Argumente übermittelt, ob das System den vorgesehenen Vorgang ausführt und ob sich das Ergebnis in der abschließenden Antwort wiederfindet. Trennen Sie Modellfehler von Backend-Fehlern; andernfalls könnte ein externer Fehler fälschlich der Generierung zugeschrieben werden.

Wiederholen Sie die Tests oft genug, um Schwankungen zu erkennen. Berichten Sie neben der Anzahl der Durchläufe und den Testbedingungen den Median und die Latenzperzentile. Stellen Sie einen einzelnen Durchlauf nicht als allgemeines Ergebnis dar. Ein kleiner Test garantiert außerdem kein gleiches Verhalten unter Last, in einer anderen Region oder in einer anderen Sprache; auf diese Grenzen sollte in den Schlussfolgerungen hingewiesen werden.

Die Nutzererfahrung durchgängig messen

Definieren Sie präzise die Zeit bis zum ersten hörbaren Audio (TTFA), zum Beispiel als Zeitspanne vom Ende des Nutzerbeitrags bis zum ersten Antwortabschnitt, den eine Person hören kann. Wenn die Nutzer bereits sprechen können, während das System zuhört, sollten Sie außerdem den Beginn der Audioaufnahme und die zu einer Unterbrechung gehörenden Zeitstempel erfassen. Das Kriterium muss für alle Konfigurationen identisch und messbar sein. Dokumentieren Sie, wie das erste Audiosignal erkannt und wie die Uhrzeit synchronisiert wird.

Messen Sie zusätzlich die Zeit bis zur vollständigen Antwort und gegebenenfalls die Dauer von Pausen und überlappenden Gesprächsbeiträgen. Die Latenz eines Modells ist nicht gleich der Latenz des gesamten Ablaufs. In einer modularen Kette können Spracherkennung, Textgenerierung, Koordination und Synthese jeweils Zeit beanspruchen; außerdem wirken sich Netzwerk, Puffer und Werkzeugausführung aus. Die Dokumentation von ElevenLabs unterscheidet zwischen Inferenzlatenz und TTFA und erläutert den kumulativen Effekt in einer ASR–LLM–TTS-Kette. Diese Unterscheidung spricht dafür, das System im tatsächlichen Betrieb zu messen, statt die Gesamtdauer aus einem Teilwert abzuleiten.

Halten Sie gesondert fest, wann ein Werkzeugaufruf beginnt, wann er endet und wie lange es dauert, bis eine hörbare Antwort mit dem Ergebnis vorliegt. Notieren Sie Verbindungsfehler, Dienstbegrenzungen, erneute Versuche, leere Antworten und Abbrüche separat. Für die Quote korrekt behandelter Unterbrechungen müssen Sie vorher definieren, was als Erfolg gilt: Das Beenden der Audioausgabe, das Erkennen des neuen Gesprächsbeitrags und das Antworten auf die korrigierte Anweisung können unterschiedliche Kriterien sein.

Die Ergebnisauswertung benötigt eine von den Zeitmessungen getrennte Bewertungsrubrik. Prüfen Sie sachliche Richtigkeit, Einhaltung der Anweisungen, Verständlichkeit sowie die Aussprache von Namen und Zahlen. Bewerten Sie die Natürlichkeit der Stimme nach Möglichkeit blind: Die Personen, die die Stimme beurteilen, sollten nicht wissen, von welcher Konfiguration sie erzeugt wurde. Vermischen Sie Natürlichkeit und Korrektheit nicht. Eine überzeugend klingende Stimme kann eine falsche Antwort klar aussprechen.

Kosten, Komplexität und Fehlerquellen

Relevant sind nicht die Kosten einer einzelnen API, sondern die Kosten für ein akzeptables Gespräch. Erfassen Sie für die modulare Kette ASR, Antwortgenerierung, Sprachsynthese, Werkzeuge, zurechenbare Infrastruktur und erneute Versuche. Berücksichtigen Sie fehlgeschlagene Durchläufe und Aufgaben, die nicht abgeschlossen wurden; wenn diese fehlen, erscheinen die Kosten pro Erfolg niedriger als sie sind. Prüfen Sie für jedes Angebot den geltenden Tarif, die abgerechneten Einheiten, die Zugangsbedingungen und das Datum. Ohne diese Angaben lässt sich kein sinnvoller Kostenvergleich ableiten.

Die Modularität bringt zusätzliche Schnittstellen zwischen Komponenten mit sich, die überwacht werden müssen. Eine fehlerhafte Transkription kann zu einer falschen Antwort führen; eine korrekte Antwort kann falsch ausgesprochen werden; eine Unterbrechung kann den Sprachsynthesedienst zu spät erreichen; ein Werkzeug kann erst fertig werden, nachdem der Client den Gesprächsbeitrag bereits abgebrochen hat. Dies sind mögliche Fehlerfälle, die getestet werden sollten. Es sind keine Ergebnisse, die automatisch einem bestimmten Anbieter zugeschrieben werden dürfen.

Auch eine Full-Duplex-Option erfordert Integrations- und Betriebsaufwand. Das Team muss Zugriff, Kontingente, Regionen, Schnittstellen, Werkzeuge, Beobachtbarkeit und Fehlerbehandlung prüfen. Eine Produktbeschreibung legt weder die tatsächlichen Kosten noch die für eine Einführung verfügbare Kapazität allein fest. Die Verfügbarkeit für die Zielgruppe sollte zum Veröffentlichungszeitpunkt geprüft und zusammen mit den Einschränkungen dokumentiert werden.

Zu den Betriebskosten zählt außerdem die Zeit, die für die Diagnose von Fehlern, die Aktualisierung von Komponenten und die Pflege von Messsystemen benötigt wird. Eine modulare Kette ermöglicht es grundsätzlich, eine Komponente auszutauschen, ohne alle anderen zu ersetzen; gleichzeitig müssen Kompatibilität und Zustand zwischen den Komponenten verwaltet werden. Eine integrierte Konfiguration kann einige Koordinationspunkte verringern, macht Tests, Protokollierung und Qualitätskontrollen aber nicht überflüssig. Diese Überlegungen sollten in der tatsächlichen Umgebung überprüft werden.

Ergebnisse auswerten, ohne vorzeitig einen Sieger auszurufen

Erzielt die modulare Kette in einer blinden Bewertung die bevorzugte Stimme, antwortet aber langsamer und behandelt Unterbrechungen schlechter, hängt die Entscheidung davon ab, wie wichtig diese Faktoren für das Produkt sind. Löst sie Aufgaben mit Werkzeugen besser, muss geprüft werden, ob der Vorteil bestehen bleibt, wenn Latenz und Backend-Fehler mitberücksichtigt werden. Erzielt ein Full-Duplex-Modell im Test bessere Zeiten, lässt sich dieses Ergebnis nicht automatisch auf ein anderes Netzwerk, eine andere Sprache, Region oder Auslastung übertragen.

Eine modulare Lösung kommt in Frage, wenn das Team kontrollieren möchte, welches Modell antwortet, welche Stimme die Synthese übernimmt und wie Werkzeuge ausgeführt werden, und bereit ist, die Koordination zu überwachen und zu pflegen. Eine Full-Duplex-Option kann in Betracht gezogen werden, wenn eine integrierte Sprachinteraktion Priorität hat und die verfügbare Konfiguration Anforderungen an Zugang, Qualität und Betrieb erfüllt. Das sind Hypothesen zur Orientierung der Entscheidung, keine Garantie dafür, dass eine Architektur überlegen ist.

Veröffentlichen Sie die genauen Konfigurationen, das Evaluierungsskript, die Metrikdefinitionen, Kostendaten und Ausschlüsse. Geben Sie Schwankungen und negative Ergebnisse an. Ein brauchbarer Vergleich ermöglicht es, den Test zu wiederholen und zu erkennen, welche Komponente einen Unterschied verursacht; eine aggregierte Gesamtbewertung ohne Aufschlüsselung zeigt nicht, ob das Problem bei Transkription, Antwort, Stimme, Gesprächssteuerung, Werkzeugen oder Netzwerk lag.

Mit der verfügbaren Dokumentation lässt sich festlegen, welche Rolle jeder Dienst erfüllt, und ein fairer Test entwerfen. Sie reicht jedoch nicht aus, um im Voraus festzustellen, welche Konfiguration in einer konkreten Implementierung die niedrigste Gesamtlatenz, die höchste Qualität oder die geringsten Kosten bietet. Solche Schlussfolgerungen erfordern Messungen mit eindeutig identifizierten Versionen, geprüften Tarifen und Aufgaben, die der vorgesehenen Nutzung entsprechen.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.