--- title: "Cue Turn Detection: Telefonnummern, Benchmarks und Grenzen" canonical: https://wavect.io/de/blog/cue-turn-detection-phone-numbers/ language: de description: "Pype Cue v1 für KI-Telefonassistenten: Telefonnummern ohne verfrühte Unterbrechung, mehrsprachige Benchmarks, Smart Turn, Eigenbetrieb und Abnahmetests." image: "https://wavect.io/img/blog/headers/header_cue-turn-detection-phone-numbers.png" author: ["Kevin Riedl"] published: "2026-10-15" updated: "2026-10-15" reviewed: "2026-10-15" --- # Cue Turn Detection: Telefonnummern, Benchmarks und Grenzen [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 14 Min Lesezeit · 15. Okt. 2026 Zuletzt geprüft 15. Oktober 2026 [**Weiter**](/de/blog/phonely-alma-voice-llm-review/) TL;DR Cue v1 ist Pype AIs Turn-Detection-System mit offenen Gewichten. Der veröffentlichte Benchmark kombiniert ein Gemma-4-E4B-Textentscheidungsmodell mit Smart-Turn-v3.2-Audioscores. Das ist für strukturierte Gespräche interessant, belegt aber keine exakte Telefonnummernerfassung. Entscheidend sind richtig bestätigte Nummern, Korrekturen, sprachspezifische Ergebnisse und Latenzen unter Spitzenlast. Eine Telefonnummer ist kein Satz. Jemand nennt ein paar Ziffern, überlegt kurz und spricht weiter. Ein KI-Telefonassistent, der diese Pause als Gesprächsende interpretiert, kann die Nummer verlieren, noch bevor sein Sprachmodell sinnvoll zum Einsatz kommt. **Cue v1 ist ein Turn-Detection-System mit offenen Modellgewichten von Pype AI. Es entscheidet, ob ein Anrufer fertig gesprochen hat und ob er den Assistenten unterbrechen möchte.** Die veröffentlichte Auswertung kombiniert ein feinabgestimmtes Gemma-4-E4B-Modell für Textentscheidungen mit dem Audioscore von Pipecats Smart Turn v3.2. Die Cue-Gewichte enthalten nur die Textkomponente, nicht die gesamte Sprachpipeline. Das stellt die [Modellbeschreibung von Pype](https://huggingface.co/Pype/cue-v1) klar. Interessant ist das für strukturierte Gespräche, besonders beim Erfassen von Telefonnummern. Für ein Unternehmen zählt aber mehr: **Erfasst der Assistent die richtige, bestätigte Nummer, ohne dem Anrufer ins Wort zu fallen?** ## Was hat Pype mit Cue v1 veröffentlicht? Laut [Veröffentlichungsdaten von Pype](https://github.com/PYPE-AI-MAIN/cue-v1/blob/7919e712801e4b93f8de4dd1577fd908510005db/CITATION.cff) erschien Cue 1.0.0 am **12. Oktober 2026**. Dieser Artikel wurde am **15. Oktober 2026** geprüft. Cue stammt von Pype, nicht von Wavect. Der [Ankündigungsbeitrag mit Demonstration](https://www.linkedin.com/posts/dhruv-mehra_were-launching-cue-a-multilingual-turn-activity-7515619513384574976-Hyww) zeigt Pausen beim Diktieren von Telefonnummern und thematisiert mehrsprachige Gespräche. Das erklärt das Problem anschaulich, misst aber nicht kontrolliert die Erfassungsgenauigkeit. Dieser Artikel analysiert veröffentlichte Unterlagen und schlägt einen Prüfplan vor. Wir haben weder einen Cue-Produktivbetrieb durchgeführt noch die Inferenzbenchmarks unabhängig reproduziert. Cue liegt zwischen dem Erkennen von Wörtern und der Entscheidung zu antworten. Spracherkennung, Rufnummernprüfung, Sprachausgabe und das Speichern des Kundendatensatzes bleiben eigenständige Aufgaben. Die angrenzenden Komponenten behandeln unser [Review zu Streaming-Spracherkennung](/de/blog/nvidia-nemotron-3-5-asr-production-review/) und unser [Phonely-Alma-Review für Telefonagenten](/de/blog/phonely-alma-voice-llm-review/). ## Warum unterbrechen KI-Telefonassistenten beim Diktieren von Nummern? Ein beispielhafter Gesprächsverlauf: > Assistent: „Unter welcher Nummer können wir Sie zurückrufen?“Anrufer: „Plus vier drei...“Assistent: „Danke. Und Ihre E-Mail-Adresse?“Anrufer: „Ich bin noch nicht fertig.“ Dafür muss die Transkription nicht falsch sein. Das System kann die Ziffern korrekt erkannt und trotzdem den Redebeitrag zu früh beendet haben. **Voice Activity Detection, kurz VAD, erkennt, ob gesprochen wird. Automatic Speech Recognition, kurz ASR, wandelt Sprache in Text um. End-of-Turn Detection entscheidet, ob der Redebeitrag abgeschlossen ist. Barge-in Handling regelt, was passiert, wenn der Anrufer während der Assistentenantwort spricht.** Diese Aufgaben gehören nicht in einen einzigen pauschalen Stille-Timer. Die [LiveKit-Dokumentation zur Gesprächssteuerung](https://docs.livekit.io/agents/logic/turns/turn-detector/) erläutert ihr Zusammenspiel. Ein längerer Timeout schützt Denkpausen, verzögert aber auch tatsächlich vollständige Antworten. Werden Unterbrechungen abgeschaltet, sinken womöglich falsche Abbrüche. Dafür können Anrufer Fehler nicht mehr rechtzeitig korrigieren. Sinnvoll ist eine Unterscheidung zwischen Zögern, Abschluss, Zuhörsignal und Einwand. Cue ist nicht das erste Modell für diese Aufgabe. LiveKit beschrieb bereits im Dezember 2025 [Verbesserungen für strukturierte Angaben und mehrsprachige Sprecherwechsel](https://livekit.com/blog/improved-end-of-turn-model-cuts-voice-ai-interruptions-39), darunter Telefonnummern. Entscheidend ist, ob Cues nachvollziehbare Kombination zum eigenen Ablauf passt, nicht ob das Problem zuvor unbekannt war. ## Wie verbindet Cue Gesprächskontext und Audio? Das [Cue-Repository](https://github.com/PYPE-AI-MAIN/cue-v1/blob/7919e712801e4b93f8de4dd1577fd908510005db/README.md) beschreibt zwei Entscheidungen. Bei einer Pause erhält die Textkomponente Gesprächskontext und bewertet vier Zustände. Während der Assistent spricht, unterscheidet ein weiterer Prompt zwischen einer echten Unterbrechung und einem Zuhörsignal. | Entscheidung | Zustand | Beabsichtigte Bedeutung | | --- | --- | --- | | Anrufer pausiert | DONE | Der Redebeitrag ist vollständig. | | Anrufer pausiert | LIKELY_DONE | Wahrscheinlich vollständig, aber nicht eindeutig. | | Anrufer pausiert | MID_THOUGHT | Satz oder strukturierte Antwort sind noch unvollständig. | | Anrufer pausiert | HOLDING | Der Sprecher braucht Zeit zum Nachdenken. | | Anrufer spricht gleichzeitig | STOP | Für Korrektur, Frage oder Einwand anhalten. | | Anrufer spricht gleichzeitig | CONTINUE | Ein Zuhörsignal erfordert keinen Abbruch. | Pipecats [Smart-Turn-Modell](https://huggingface.co/pipecat-ai/smart-turn-v3) untersucht separat die Audiowellenform. Es ist ein audiobasierter semantischer Turn-Detektor, nicht bloß ein Timer. Cue ergänzt expliziten Textkontext, etwa die zuvor gestellte Frage und bereits genannte Zifferngruppen. Die veröffentlichte Kombination für Anrufer-Agenten-Gespräche lautet: ``` text_end = P(DONE) + P(LIKELY_DONE) combined_end_score = text_end * sqrt(audio_end_score) ``` Ein Schwellenwert entscheidet anschließend über das Gesprächsende. Dieser kombinierte Score **beweist weder die Vollständigkeit noch die Richtigkeit einer Telefonnummer**. Durch die Formel wird er auch nicht automatisch zu einer kalibrierten Wahrscheinlichkeit für den Produktivbetrieb. Zwei Details im [Quellcode des Cue-Clients](https://github.com/PYPE-AI-MAIN/cue-v1/blob/7919e712801e4b93f8de4dd1577fd908510005db/cue/client.py) sind wichtig. Das Modell erzeugt ein Antworttoken und liest die Log-Wahrscheinlichkeiten der Optionen aus, statt einen Absatz zu schreiben. Fehlen diese Werte, kann der Client auf den ausgegebenen Buchstaben zurückfallen und ihm die gesamte Wahrscheinlichkeitsmasse zuweisen. Eine erfolgreiche HTTP-Anfrage kann damit eine veränderte Bewertungslogik verdecken. Prüft deshalb die unverarbeitete Serverantwort, nicht nur das zurückgegebene Dictionary. Außerdem kombiniert `with_voice(...)` lediglich übergebene Scores. Die Funktion lädt weder Smart Turn noch verarbeitet sie Mikrofon-Audio. Der separate Helfer `wait(...)` verwendet eine andere Wartezeitstrategie und entspricht nicht der Schwellenwertlogik des kombinierten Benchmarks. ## Cue, Smart Turn und LiveKit im Benchmark Pype berichtet die folgenden Werte mit LiveKits eot-bench. **Es handelt sich um Messungen des Herausgebers, nicht um einen Wavect-Benchmark oder eine unabhängig bestätigte Ranglistenempfehlung.** | System | Verzögerung bis zur Gesprächsende-Entscheidung bei 5 % Fehlunterbrechungsbudget | Fehlunterbrechungen bei 600 ms Verzögerungsbudget | | --- | --- | --- | | LiveKit turn-detector v1, gehostet | 543 ms | 4,5 % | | Baton v1 | 577 ms | 4,8 % | | Soniox stt-rt-preview | 647 ms | 5,5 % | | Cue v1, Text plus Smart Turn v3.2 | 719 ms | 7,5 % | | Cue-Textkomponente allein | 750 ms | 7,8 % | | Smart Turn v3.2 allein | 1.051 ms | 14,8 % | Quelle: [Pypes veröffentlichte Ergebnisse und Einschränkungen](https://github.com/PYPE-AI-MAIN/cue-v1/blob/7919e712801e4b93f8de4dd1577fd908510005db/RESULTS.md), Englisch, 400 Anruferbeiträge. Die Spalten bilden **getrennt abgestimmte Betriebspunkte** ab, nicht zwei Kennzahlen derselben unveränderten Produktivkonfiguration. Beim 5-Prozent-Budget entscheidet Cue laut Tabelle 332 ms früher als Smart Turn, aber 176 ms später als das gehostete LiveKit-Modell. Das sind Rechenergebnisse aus diesen Messwerten, keine Zusagen für Kundengespräche. „Hier besser als Smart Turn“ ist belegt. „Bester Turn-Detektor“ nicht. Die [eot-bench-Methodik](https://github.com/livekit/eot-bench) misst den Entscheidungszeitpunkt nach dem tatsächlichen Ende des Redebeitrags. Sie misst weder GPU-Inferenzzeit noch die gesamte Wartezeit bis zur hörbaren Antwort. Standardmäßig wird eine Transkriptverzögerung von 500 ms angenommen. Schwellenwerte, minimale Aktionsverzögerungen und Timeouts werden systematisch variiert. Auch bei der Trennung von Entwicklung und Test ist Genauigkeit nötig. Laut Pype wurde das Modell nicht auf Benchmark-Gesprächen trainiert. Allerdings dienten 150 englische Benchmark-Beiträge zur Entwicklung von Prompt und Kombinationsformel. Die Haupttabelle umfasst alle 400 Beiträge. Sie vollständig als unangetasteten Testsatz zu bezeichnen, wäre zu weitgehend. ## Funktioniert Cue auf Deutsch, Chinesisch und bei Sprachwechseln gleich gut? **Nein. Mehrsprachige Evaluation ist ein Anhaltspunkt, keine Garantie für jede Sprache, jeden Akzent oder jeden Sprachwechsel.** Pype evaluiert 14 Sprachen: Arabisch, Chinesisch, Niederländisch, Englisch, Französisch, Deutsch, Hindi, Indonesisch, Italienisch, Japanisch, Koreanisch, Portugiesisch, Spanisch und Türkisch. | Sprache | Cue-Verzögerung bei 5 % Fehlunterbrechungsbudget | Veröffentlichter Rang für Sprache und Betriebspunkt | | --- | --- | --- | | Englisch | 719 ms | 4 von 13 | | Deutsch | 786 ms | 3 von 11 | | Spanisch | 792 ms | 2 von 11 | | Chinesisch | 838 ms | 2 von 9 | | Portugiesisch | 681 ms | 1 von 11 | | Arabisch | 815 ms | 6 von 9 | Das sind ausgewählte Zeilen derselben Pype-Auswertung. Platz eins für Portugiesisch gilt für diesen Betriebspunkt, nicht für jede Kennzahl. Außerdem werden je Sprache unterschiedlich viele Systeme verglichen. Der englische Prompt bleibt gleich. Die Vorverarbeitung ist jedoch nicht vollständig identisch: Bei Sprachen mit häufig fehlender Interpunktion neutralisiert Pype das Merkmal zum Transkriptende. Der öffentliche [eot-bench-Datensatz](https://huggingface.co/datasets/livekit/eot-bench-data) enthält Mensch-Agent-Gesprächsbeiträge mit Audio- und Textkontext. Er ist kein spezieller Test zur mehrsprachigen Telefonnummernerfassung. Ein österreichisches Unternehmen sollte mit den tatsächlichen Akzenten, Zifferngruppierungen und Wechseln ins Englische seiner Anrufer testen. Verwendet die Ausgabe der produktiven Spracherkennung, keine manuell korrigierten Transkripte. Wir fanden keinen veröffentlichten Cue-Nachweis für die Genauigkeit von Sprachwechseln innerhalb eines Anrufs oder für exakt erfasste Telefonnummern. ## Erkennt Cue den Unterschied zwischen „okay“ und „eigentlich nein“? Beim Vorlesen der Nummer ist diese Unterscheidung entscheidend. „Okay“ kann lediglich „Ich höre zu“ heißen. Ein kurzes „Nein“ kann dagegen die Nummer ungültig machen, die der Assistent gerade speichern will. Pype nennt **98,9 % Genauigkeit für STOP gegenüber CONTINUE auf 90 zurückgehaltenen synthetischen Fragen**. Das sind keine 98,9 % Zuverlässigkeit in mehrsprachigen Produktivgesprächen. Die Ergebnisse nennen auch einen Fehlerfall: „hmm, actually no“ kann als CONTINUE gelten, bis weitere Informationen eintreffen. Für das Training wurden 310 von einem LLM geschriebene Gespräche verwendet. Pype veröffentlicht eine [Trainingsspezifikation](https://github.com/PYPE-AI-MAIN/cue-v1/blob/7919e712801e4b93f8de4dd1577fd908510005db/training/SPEC.md) und Skripte, aber nicht die Gespräche selbst. Offene Gewichte erleichtern Betrieb und Untersuchung. Sie machen nicht automatisch jede Trainingsaussage mit den veröffentlichten Materialien reproduzierbar. Unsere Empfehlung: Korrekturen als eigenständige Sicherheitsbedingung im Erfassungsablauf behandeln. Mit neuen Wörtern erneut entscheiden, einen ausstehenden Speichervorgang bei einem erkannten Einwand aussetzen und prüfen, ob STOP tatsächlich gepufferte Sprachausgabe beendet. Ein korrekter Klassifikator stoppt kein Audio, das die Telefonieschicht weiter abspielt. ## Wie sollte ein Ablauf zur Telefonnummernerfassung Cue einsetzen? **Cue entscheidet über Zuhören und Sprechen. Die Anwendung entscheidet, was gespeichert werden darf.** Diese Trennung empfehlen wir unabhängig vom konkreten Turn-Detektor. Zuerst muss die begonnene Nummer über Pausen hinweg erhalten bleiben. Die Frage des Assistenten und frühere Zifferngruppen gehören zum Kontext. Überschreibt den Entwurf nicht bei jedem ASR-Fragment. Eine verspätete Endpunktentscheidung darf auch keine neuere Transkriptversion abschließen. Danach werden gesprochene Ziffern verarbeitet und länderspezifisch normalisiert. Eine geeignete Rufnummernbibliothek prüft plausibles Format und Länge. Eine globale Zehn-Ziffern-Regel ist ungeeignet. Selbst ein gültiges Format beweist nicht, dass die Nummer dem Anrufer gehört oder von ihm so gemeint war. Anschließend wird die normalisierte Nummer verständlich vorgelesen. Vor dem Speichern ist eine ausdrückliche, zum Ablauf passende Bestätigung erforderlich. Ein Zuhörgeräusch ist keine Freigabe für einen Feldeintrag. Eine Korrektur ersetzt den betroffenen Entwurf und macht die vorige Bestätigung ungültig. Erst dann wird der bestätigte Wert gespeichert. Wiederholte Anfragen dürfen bei Timeouts keine doppelten Datensätze erzeugen. Bei mehrfach gescheiterter Erfassung braucht es eine Tastatureingabe am Telefon, einen sicheren Texteingabekanal oder menschliche Hilfe. Speichert Audio und Transkripte sparsam, statt echte Rufnummern für bequemes Debugging überall zu protokollieren. Das ist unser vorgeschlagenes Kontrolldesign, keine von Cue mitgelieferte Funktion. Sein Ergebnis ist ein richtiges, bestätigtes Datenfeld, nicht nur eine schnellere Entscheidung über eine Pause. ## Wie lässt sich Cue lokal prüfen, ohne Demo und Integration zu verwechseln? Pype stellt eine GGUF-Datei und einen LoRA-Adapter bereit. Der [Lizenzhinweis der Veröffentlichung](https://github.com/PYPE-AI-MAIN/cue-v1/blob/7919e712801e4b93f8de4dd1577fd908510005db/NOTICE) nennt Apache-2.0 für Gewichte, Adapter, Prompts und Dokumentation von Cue. Für die separate Smart-Turn-Abhängigkeit gilt BSD-2-Clause. Ein technischer Funktionstest benötigt eine Python-Umgebung und einen GPU-fähigen `llama-server`-Build mit Gemma-4-Unterstützung. Dieses Shell-Beispiel für macOS/Linux fixiert den geprüften Client-Quellstand. Es ist **keine vollständig versionsfixierte Produktivumgebung** und wurde für dieses Review nicht ausgeführt. ``` git clone https://github.com/PYPE-AI-MAIN/cue-v1.git cd cue-v1 git checkout 7919e712801e4b93f8de4dd1577fd908510005db python3 -m venv .venv . .venv/bin/activate python -m pip install -e . huggingface_hub hf download Pype/cue-v1 cue-v1-q8_0.gguf --local-dir models llama-server -m models/cue-v1-q8_0.gguf -c 8192 -np 4 -ngl 999 \ --jinja --host 127.0.0.1 --port 8090 ``` Die [Hugging-Face-CLI-Dokumentation](https://huggingface.co/docs/huggingface_hub/guides/cli) beschreibt `hf download` und die Option `--revision`. Erfasst Modellrevision und Datei-Prüfsumme und fixiert beide vor einem kontrollierten Vergleich. Für einen lokalen Test sollte der [llama.cpp-Server](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md) nur über Loopback erreichbar sein. Ein ungeschützter Inferenzport gehört nicht ins öffentliche Internet. In einem zweiten Terminal ins Repository wechseln, dieselbe Umgebung aktivieren und `python examples/quickstart.py` ausführen. Das prüft die Textentscheidungsschnittstelle. Für das veröffentlichte kombinierte System fehlen noch Smart Turn v3.2, zeitlich abgestimmte Audio- und Transkripteingaben sowie die eigene Schwellenwertlogik. Vor echten Anrufen braucht es außerdem Antwortfristen, die Ablehnung veralteter Ergebnisse und eine begrenzte Rückfallstrategie. ## Wie viele Anrufe schafft eine GPU? **Entscheidungen pro Sekunde sind nicht gleichzeitige Anrufe.** Pypes T4-Messungen nennen ungefähr 13 Entscheidungen pro Sekunde. Der Median steigt von 79 ms bei einer laufenden Anfrage auf 364 ms bei vier und 1.220 ms bei sechzehn. Das misst den Inferenzbetrieb, anders als die vorherige Endpointing-Tabelle. Pypes Kapazitätsschätzung unterstellt etwa sechs Entscheidungen je Anruferbeitrag und sechs Beiträge pro Minute. Daraus folgen 0,6 Entscheidungen pro Sekunde und Anruf. Zwanzig aktive Anrufe benötigen durchschnittlich zwölf Entscheidungen pro Sekunde und liegen damit bereits nahe am angegebenen Durchsatz. Diese Rechnung belegt nicht, dass zwanzig Anrufer gleichzeitig pausieren können und jede Entscheidung unter 200 ms vorliegt. Prüft Lastspitzen, nicht zwischengespeicherte Prompts und die tatsächliche Promptlänge. Maßgeblich für die Zulassungsgrenze sind hohe Latenzperzentile, nicht nur mittlere Auslastung. Die ungefähr 0,0005 US-Dollar pro Gesprächsminute des Herausgebers sind eine GPU-Umlage unter seinen Annahmen, kein Komplettpreis für einen Sprachagenten. ASR, TTS, Telefonie, Ablaufsteuerung, Monitoring, freie Kapazität und Betreuung kommen hinzu. Vergleicht deshalb die [Kosten pro abgenommener KI-Aktion](/de/blog/ai-agent-cost-per-action-2026/). ## Welche Abnahmetests braucht die Telefonnummernerfassung? Die folgende Matrix ist ein **Prüfvorschlag, kein nachgewiesenes Cue-Ergebnis**. Erstellt freigegebene oder synthetische Testfälle für jede unterstützte Sprache. Haltet zusätzliche Fälle zur Abstimmung getrennt. | Test | Variation | Erwartetes Verhalten | | --- | --- | --- | | 1. Zifferngruppen | Kurze und lange Pausen zwischen Gruppen | Keine verfrühte Antwort, keine verlorene Gruppe. | | 2. Nummernformate | Landesvorwahl, führende Null, Durchwahl | Richtig normalisieren, keine Ziffern erfinden. | | 3. Gesprochene Formen | „Doppelt“, Zahlengruppen, Wörter oder Ziffern | Dieselbe beabsichtigte normalisierte Nummer. | | 4. Sprachwechsel | Wechsel innerhalb derselben Nummer | Vollständige Erfassung oder klare Rückfrage. | | 5. ASR-Revision | Neuere Transkription ändert eine Ziffer | Veraltete Ergebnisse bestätigen keinen alten Wert. | | 6. Korrektur | Nach einer Pause wird eine Gruppe ersetzt | Entwurf aktualisieren und neu bestätigen. | | 7. Zuhörsignal | „Okay“ während des Vorlesens | Keine versehentliche Bestätigung oder unnötiger Neustart. | | 8. Kurzer Einwand | „Nein“ oder „eigentlich nein“ beim Vorlesen | Audio abbrechen und Speichern aussetzen. | | 9. Hintergrundsprache | Andere Person, Geräusch, Echo | Keine unbegründete Feldänderung oder Bestätigung. | | 10. Lange Stille | Nachdenken oder Verbindungsabbruch | Begrenzte Wartezeit und verständliche Fortsetzung. | | 11. Lastspitze | Viele Anrufe pausieren gleichzeitig | Antwortfristen und sichere Rückfallstrategie einhalten. | | 12. Schreibfehler | CRM-Timeout nach der Bestätigung | Zustand abgleichen, keine doppelten Datensätze. | Legt die Hauptkennzahl vor dem Test fest: **Erfolg beim Erstversuch = Versuche mit exakt beabsichtigter, ausdrücklich bestätigter Nummer ohne Neustart des Diktierens / alle geeigneten Erstversuche**. Berichtet späteren Erfassungserfolg, falsche Speichervorgänge, Unterbrechungen, Korrekturschleifen und Abbrüche separat. Wertet nach Sprache und Gesprächsbedingung aus. Messt die Entscheidung nach Gesprächsende, die hörbare Antwort und die Zeit vom Einwand bis zum Audiostopp getrennt, jeweils einschließlich P95. Vergleicht Bestandssystem, Cue nur mit Text und Cue als Kombination nach derselben Abnahmeregel. Schwellenwerte werden auf Entwicklungsfällen festgelegt und für den zurückgehaltenen Test eingefroren. ## Wann lohnt sich Cue? Cue ist einen Versuch wert, wenn strukturierte Antworten zu früh abgeschnitten werden, mehrsprachige Anrufer relevant sind und das Team eine kombinierte Text-Audio-Entscheidungspipeline betreiben kann. Weniger überzeugend ist ein ungeprüfter Austausch in einem funktionierenden System oder der Versuch, mangelhafte Spracherkennung damit zu umgehen. Wavects [KI-Integration und Engineering](/de/services/artificial-intelligence/) verbindet solche Komponenten zu kontrollierten Geschäftsabläufen. Die [Twinsoft-AI-Fallstudie](/de/case-studies/twinsoft-ai/) zeigt angrenzende Umsetzungserfahrung, keinen Cue-Einsatz. Unsere [QA-Checkliste vor dem Softwarelaunch](/de/software-development-guide/software-qa-checklist-before-launch/) behandelt die umfassendere Freigabe. Bringt ein bereinigtes Beispiel einer gescheiterten Nummernerfassung und das gewünschte Kundendatenformat mit, um [euren Sprachagenten-Ablauf mit Wavect zu besprechen](/de/contact/). Das Ziel ist nicht ein Modell, das früher spricht. Es ist ein Assistent, der lange genug zuhört, Korrekturen zulässt und das richtige Ergebnis speichert. ## Häufige Fragen zu Cue Turn Detection ### Was ist Cue Turn Detection? Cue v1 ist ein System mit offenen Modellgewichten von Pype AI. Es erkennt das Ende eines Redebeitrags und bewertet Unterbrechungen. Die veröffentlichte Kombination nutzt ein feinabgestimmtes Gemma-4-E4B-Textmodell und Smart-Turn-v3.2-Audioscores. Die Cue-Gewichte enthalten nur die Textkomponente. ### Löst Cue die Erfassung von Telefonnummern? Cue adressiert ein relevantes Timing-Problem. Die geprüften öffentlichen Unterlagen belegen aber keine exakte Telefonnummernerfassung. Ein Produktivablauf benötigt weiterhin Spracherkennung, länderspezifische Normalisierung, Korrekturbehandlung, ausdrückliche Bestätigung und kontrolliertes Speichern. ### Ist Cue besser als Smart Turn oder LiveKit? Pypes englischer eot-bench-Lauf nennt bei 5 % Fehlunterbrechungsbudget 719 ms für Cue, 1.051 ms für Smart Turn v3.2 und 543 ms für LiveKits gehostetes v1. Das sind Anbieterwerte bestimmter Betriebspunkte, keine allgemeine Rangfolge und keine vollständige hörbare Antwortlatenz. ### Unterstützt Cue Deutsch und Chinesisch? Pype evaluiert 14 Sprachen, darunter Deutsch und Chinesisch. Die gemeldeten Verzögerungen bei 5 % Fehlunterbrechungsbudget betragen 786 ms beziehungsweise 838 ms. Damit ist die Genauigkeit für einzelne Akzente, Rufnummernformate oder Sprachwechsel innerhalb eines Anrufs nicht belegt. ### Sind die Cue-Gewichte Open Source? Pypes Lizenzhinweis nennt Apache-2.0 für Gewichte, Adapter, Prompts und Dokumentation von Cue. Smart Turn ist eine separate BSD-2-Clause-Abhängigkeit. Die generierten Trainingsgespräche sind nicht veröffentlicht. Offene Gewichte machen deshalb nicht den gesamten Trainingsprozess reproduzierbar. ### Lässt sich Cue lokal mit llama.cpp betreiben? Pype stellt eine GGUF-Datei und einen Client für kompatible Inferenzserver bereit. Lokale Textentscheidungen sind noch nicht das vollständig getestete Kombinationssystem. Dafür braucht es Smart-Turn-Scores, synchronisierte Eingaben und eine geprüfte Strategie. Log-Wahrscheinlichkeiten und Antwortfristen müssen kontrolliert werden. ### Schafft eine T4 zwanzig parallele Cue-Anrufe? Pypes Schätzung hängt von den angenommenen Entscheidungen und Redebeiträgen pro Minute ab. Der angegebene Durchsatz liegt bei etwa 13 Entscheidungen pro Sekunde, während Anfragelatenzen bei Parallelität steigen. Zwanzig Anrufe garantieren keine Entscheidungen unter 200 ms bei gleichzeitigen Pausen. Lastspitzen müssen getestet werden. Modelle und Infrastruktur ## Weiterlesen Modellauswahl, Inferenzkosten, lokaler Betrieb, Kompression und Serving-Architektur. [Hier starten**LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen**](/de/blog/self-hosting-llms-eu-cost/) - [Google SAM heißt jetzt Agent Mesh: MCP-Tools vernetzen](/de/blog/google-sam-agent-mesh-mcp-tools/) - [EdgeQuake: PostgreSQL-GraphRAG als MCP-Gedächtnis für Agenten](/de/blog/edgequake-postgresql-graphrag-mcp-agent-memory/) - [BitNet auf der CPU: 2B4T, RAM-Bedarf und die 100B-Angabe](/de/blog/bitnet-cpu-llm-ram-requirements/) - [SuperPenguin: KI-Kosten pro PR, Kunde und Feature](/de/blog/superpenguin-ai-roi-cost-per-pr-customer/) - [Claude Dashboards + Motion: Von KPIs zum Video](/de/blog/claude-dashboards-motion-product-kpi-video/) [Nächster Artikel**Google SAM heißt jetzt Agent Mesh: MCP-Tools vernetzen**](/de/blog/google-sam-agent-mesh-mcp-tools/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 14 Min Lesezeit · 15. Okt. 2026 Zuletzt geprüft 15. Oktober 2026 [**Weiter**](/de/blog/phonely-alma-voice-llm-review/)