Echtzeit-Spracherkennung unter 200 ms: Ein Architekturleitfaden

Echtzeit-Speech-to-Text (STT) transkribiert Audio aktiv, während eine Person spricht, und gibt deren Worte innerhalb weniger hundert Millisekunden als Text zurück. Eine niedrige STT-Latenz zu halten, ist jedoch ebenso ein Architekturproblem wie ein Modellproblem. Entwickler müssen Transport, Chunking, Endpunkt-Erkennung und den Erfassungspfad planen, da jeder davon zur Latenz beiträgt. Ineffizienz in nur einem dieser Bereiche kann Ihr Budget von 200 ms sprengen.

Dieser Leitfaden bietet ein praktisches System, mit dem Sie Echtzeit-Speech-to-Text-Pipelines von der Transportschicht an aufbauen können. Im Mittelpunkt steht Scribe v2 Realtime, das Teiltranskriptionen bei einer Modelllatenz von etwa 150 ms erzeugt, mehr als 90 Sprachen unterstützt, PCM-Audio (8 kHz–48 kHz) und μ-law akzeptiert sowie Voice Activity Detection und eine manuelle Commit-Steuerung zur Segmentfinalisierung bereitstellt.

Wir zeigen, wie Audio den Server erreicht, wie sich Hypothesen zu festgeschriebenem Text entwickeln, welche Kosten In-Stream-Features verursachen und wie Sie Audio korrekt erfassen und weiterleiten.

Zusammenfassung

• Echtzeit-Speech-to-Text-Systeme erfordern architektonische Feinabstimmung, damit die Latenz in der gesamten Pipeline niedrig bleibt.
• WebSocket ist für die meisten Pipelines die richtige Standardwahl, während WebRTC zwar mehrere Vorteile bietet, aber komplexer ist.
• Voice Activity Detection übernimmt die freihändige Segmentierung. Der manuelle Commit gibt Ihrer Anwendung die Möglichkeit einzugreifen, wenn sie weiß, dass ein Sprecherzug beendet ist.
• Partials sind vorläufig, Finals sind festgeschrieben. Sie sollten daher unterschiedlich dargestellt werden. 
• Kleine PCM-Chunks von etwa 100 ms minimieren die Latenz bis zum ersten Partial.

WebSocket vs. WebRTC für Echtzeit-Speech-to-Text

Bevor eine Transkription erfolgt, muss Audio von der Quelle zum Erkenner gelangen. Der gewählte Kanal legt die Latenzuntergrenze für alles Nachgelagerte fest. Es gibt zwei praktikable Optionen, um Audio zur Transkriptionsebene zu übertragen.

WebSocket ist ein langlebiger, geordneter, zuverlässiger und bidirektionaler Kanal über TCP. Sie öffnen eine Verbindung, senden binäre Audioframes und lesen Transkriptereignisse aus. Er ist auf Client- und Serverseite unkompliziert, passiert Unternehmens-Proxys und Firewalls, die HTTPS bereits zulassen, und wird von jeder Browser- und Serverlaufzeit unterstützt. 

Die Einschränkung von WebSocket ist die Nutzung von TCP. Geht ein Paket verloren, überträgt TCP es erneut und hält spätere Daten zurück, bis die Lücke geschlossen ist. Bei guten Netzwerkbedingungen fällt das nicht auf. Bei Paketverlust führt es zu Head-of-Line-Blocking: einer kurzen Unterbrechung, bei der sich Audio anstaut und anschließend gebündelt eintrifft.

WebRTC wurde für Echtzeitmedien entwickelt. Es überträgt Medien über UDP (via SRTP), sodass ein verlorenes Paket den Stream nicht anhält; die Pipeline läuft weiter. Es umfasst einen Jitter-Buffer, der Schwankungen bei Paketankunftszeiten abfedert, handelt NAT-Traversal über ICE/STUN/TURN aus, damit Peers hinter Routern eine Verbindung herstellen können, und bringt eigene Mechanismen für Audioerfassung und -codierung mit. 

Für Clients ohne direkte Verbindung benötigen Sie in der Regel TURN-Server. Außerdem muss die Serverseite einen Medienstrom terminieren, statt einen Byte-Stream zu lesen.

Hier der Kompromiss auf einen Blick:

Für die meisten Anwendungsfälle ist WebSocket die richtige Wahl. Nutzen Sie es, wenn Ihre Clients über eine stabile Verbindung verfügen und Sie den Erfassungspfad kontrollieren: Server-zu-Server-Pipelines, Desktop-Apps, Browser-Apps über Breitband und die meisten Contact-Center-Backends, bei denen Audio bereits auf anderem Weg an Ihrem Server ankommt. 

Wählen Sie WebRTC, wenn Sie direkt von Endgeräten in unzuverlässigen Mobilfunknetzen erfassen, bereits einen WebRTC-Stack für Zwei-Wege-Audio betreiben – etwa für einen Voice Agent, der auch zurückspricht – oder wenn verlusttolerantes Echtzeitverhalten wichtiger ist als eine einfache Implementierung.

Im weiteren Verlauf dieses Leitfadens verwenden wir WebSocket als Transport für die Verbindung zum Erkenner, weil die Komponenten dadurch sichtbar bleiben und dies für die meisten Teams der richtige Ausgangspunkt ist. Nichts davon ist spezifisch für WebSocket: Sie können später eine WebRTC-Medienverbindung davorschalten, das Audio auf dem Server in PCM dekodieren und dieselben Chunks in die Pipeline weiterleiten.

Partials und finale Transkripte: Zwischenergebnisse erklärt

Ein Echtzeit-Erkenner wartet nicht auf einen vollständigen Satz, bevor er Ergebnisse ausgibt. Stattdessen liefert er fortlaufend Vermutungen, die mit weiterem Audio präziser werden, und schreibt sie dann fest. Das Verständnis dieses Unterschieds trennt ein lebendig wirkendes Transkript von einem, das fehlerhaft wirkt. 

Eine partielle (vorläufige) Hypothese ist die beste Einschätzung des Modells auf Basis des bisher empfangenen Audios. Partials sind absichtlich instabil. Mit weiterem Audio überarbeitet das Modell frühere Wörter: Aus „Ich möchte“ kann „Ich möchte zwei Tickets“ werden, wenn späterer Kontext die Mehrdeutigkeit auflöst. Sie treffen schnell ein – das beschreibt die Latenz von etwa 150 ms – und sind dafür gedacht, überschrieben zu werden.

Eine finale Hypothese ist ein festgeschriebenes Segment, das sich nicht mehr ändert. Sobald ein Segment finalisiert ist, fährt der Erkenner fort, und nachfolgende Hypothesen beschreiben späteres Audio. Finals speichern Sie dauerhaft, senden sie an ein LLM oder legen sie als Transkript ab.

Die Unterscheidung zwischen Partials und Finals bestimmt drei Aspekte, die Sie falsch umsetzen werden, wenn Sie sie vermischen:

• Nutzererlebnis: Die Anzeige von Partials lässt ein Transkript live wirken: Nutzer sehen Wörter erscheinen, während sie sprechen. Das bestätigt, dass das Mikrofon funktioniert und das System zuhört.
• Endpunkt-Erkennung: Partials liefern ein kontinuierliches Signal für Sprachaktivität. Zusammen mit VAD können Sie damit entscheiden, wann der Sprecher tatsächlich aufgehört hat.
• Nachgelagertes Timing: In einer Voice-Agent-Pipeline folgen auf eingehendes Audio Speech to Text, dann ein LLM, dann Text to Speech und schließlich ausgehendes Audio. Sie können auf Basis von Partials spekulative Arbeit beginnen und sie bei Finals bestätigen. Das verkürzt die wahrgenommene Antwortzeit, kann aber gelegentlich dazu führen, dass spekulative Arbeit verworfen wird.

Stellen Sie Partials und Finals unterschiedlich dar. Ein einfaches, effektives Muster besteht darin, eine einzelne veränderbare „aktuelle Zeile“ an das neueste Partial zu binden und sie bei Eintreffen eines Finals in ein Transkript einzufügen, das nur ergänzt wird:

type TranscriptState = {
  committed: string[]; // finalized segments, never rewritten
  current: string;     // latest partial, overwritten on each update
};

const onPartial = (s: TranscriptState, text: string): TranscriptState =>
  ({ ...s, current: text });

const onFinal = (s: TranscriptState, text: string): TranscriptState =>
  ({ committed: [...s.committed, text], current: "" });

Stellen Sie festgeschriebenen Text visuell als stabil und den aktuellen Text heller oder kursiv dar, damit Nutzer verstehen, dass er sich noch ändern kann.

Endpunkt-Erkennung und Voice Activity Detection (VAD)

Zu wissen, was gesagt wurde, ist nur die halbe Miete. Ein Erkenner muss auch wissen, wann ein Gedanke beendet ist. Diese Entscheidung bestimmt, wann Sie ein Segment finalisieren und wann das System bei einem Agenten zu antworten beginnt. 

Die Endpunkt-Erkennung entscheidet, ob eine Äußerung beendet ist. Eine zu frühe Finalisierung unterbricht Nutzer mitten im Satz. Eine zu späte Finalisierung lässt einen Agenten schweigen, obwohl der Nutzer eindeutig fertig ist.

Scribe v2 Realtime bietet zwei sich ergänzende Mechanismen:

• Voice Activity Detection segmentiert Audio anhand von Stille: Der Erkenner erkennt, wann Sprache in anhaltende Stille übergeht, und nutzt diese Grenze, um ein Segment automatisch zu finalisieren. VAD ist die richtige Standardwahl für dialogorientierte Oberflächen, weil sie sich an den natürlichen Sprachrhythmus anpasst, ohne dass Sie Zeitabläufe manuell verfolgen müssen.
• Manuelle Commit-Steuerung: Die manuelle Commit-Steuerung lässt Ihre Anwendung unabhängig von Stille entscheiden, wann das aktuelle Segment finalisiert wird. Sie senden ein Commit-Signal, der Erkenner schließt das aktuelle Segment und gibt ein Final aus. Das ist das richtige Werkzeug, wenn Ihre Anwendung bereits weiß, dass der Sprecherzug beendet ist: beim Loslassen einer Push-to-Talk-Taste, bei einer „Senden“-Aktion oder durch eine externe Sprecherwechselrichtlinie.

Beide lassen sich gut kombinieren. Ein typischer Voice Agent nutzt VAD für den freihändigen Betrieb und stellt den manuellen Commit als Überschreibung bereit. So wird ein Nutzer, der zum Nachdenken pausiert, nicht unterbrochen, während ein Nutzer, der eine Taste antippt, sofort eine Segmentgrenze erhält.

Der Stille-Schwellenwert ist ein echter Kompromiss, für den es keinen universell richtigen Wert gibt:

• Ein kurzes Timeout nach Sprachende – etwa Finalisierung nach ca. 200–400 ms Stille – lässt das System reaktionsschnell wirken. Es unterbricht jedoch auch Nutzer, die auf natürliche Weise zwischen Satzteilen pausieren, teilt einen Gedanken in mehrere Segmente und kann bei einem Agenten eine voreilige Antwort auslösen.
• Ein langes Timeout – etwa 800–1200 ms – toleriert natürliche Pausen und erhält Äußerungen als Ganzes, führt aber zu einer merklichen Verzögerung, bevor das System reagiert.

Es gibt hier keine globale Konstante. Stimmen Sie den Schwellenwert auf die Interaktion ab:

• Diktieren und Notizen erlauben längere Pausen, weil Nutzer mitten im Satz nachdenken. Bevorzugen Sie längere Timeouts und setzen Sie auf VAD.
• Befehls- und transaktionsorientierte Agenten profitieren von kürzeren Timeouts plus manuellem Commit, weil Sprecherzüge kurz und eindeutig sind.
• Mehrsprachige Sprecher oder Nichtmuttersprachler pausieren häufiger. Planen Sie daher mehr Stille ein, bevor Sie finalisieren.

Mit diesen Hinweisen können Sie ein wirksames System zur Endpunkt-Erkennung aufbauen und sich Echtzeit-Speech-to-Text annähern.

In-Stream-Features: Spracherkennung und Sprecherdiarisierung

Streaming-Erkennung kann mehr als nur Wörter erzeugen. Jedes zusätzliche angeforderte Signal beeinflusst jedoch Latenz und Stabilität. Als Faustregel gilt: Aktivieren Sie nur, was das Live-Erlebnis benötigt, und verschieben Sie alles andere auf einen Batch-Durchlauf.

Die automatische Spracherkennung ermöglicht Scribe v2 Realtime, die gesprochene Sprache aus mehr als 90 unterstützten Sprachen zu identifizieren, ohne dass Sie sie vorab angeben müssen. Dafür benötigt das Modell eine kurze Audiosequenz, um eine sichere Entscheidung zu treffen. Die ersten Partials eines Streams können daher weniger stabil sein, während sich die Sprache festlegt. Wenn Sie die Sprache bereits kennen, beseitigt ihre Angabe diese Mehrdeutigkeit und sorgt meist für stabilere frühe Partials.

Sprecherdiarisierung ordnet Sprache unterschiedlichen Sprechern zu und erkennt, wer was gesagt hat. Bei der Batch-Transkription ist das vergleichsweise einfach, weil das Modell die gesamte Datei sieht. Beim Streaming ist es schwieriger: Der Erkenner muss anhand des bisher verfügbaren Audios eine Sprecherbezeichnung zuweisen. Eine für frühes Audio vergebene Bezeichnung muss möglicherweise überarbeitet werden, sobald mehr von dieser Stimme zu hören ist. Behandeln Sie Sprecherbezeichnungen im Streaming wie partiellen Text: vorläufig, bis das Segment finalisiert ist.

Timing auf Wortebene und Entitätskontext folgen derselben Logik. Je mehr Metadaten pro Token Sie anfordern, desto mehr müssen sowohl Modell als auch Datenübertragung verarbeiten. Für die meisten Echtzeit-UIs benötigen Sie nur Text und Segmentgrenzen live; die detaillierten Metadaten können Sie auf einen Batch-Durchlauf nach dem Anruf mit Scribe v2 verschieben.

Audioformate für Streaming: PCM und μ-law

Transport- und Erkennungslogik erhalten die meiste Aufmerksamkeit. Ein überraschend großer Anteil realer Fehler entsteht jedoch eine Schicht tiefer – bei der Codierung und Aufteilung des Audios in Chunks. Das richtige Format und die richtige Chunk-Größe sind die kostengünstigste Möglichkeit, die Speech-to-Text-Latenz zu verbessern.

PCM (linear, 16-Bit vorzeichenbehaftet, Little-Endian) ist das richtige Format, wenn Sie die Erfassung kontrollieren. Höhere Abtastraten enthalten mehr akustische Details: 16 kHz ist die übliche Untergrenze für Spracherkennung und meist ausreichend; 8 kHz entspricht Telefonqualität und verliert hochfrequente Inhalte. Verwenden Sie die Rate, die zu Ihrer Quelle passt. Das Hochsamplen von Telefonieaudio mit 8 kHz auf 48 kHz bringt keinen Vorteil, weil die Informationen nicht wiederhergestellt werden können.

μ-law mit 8 kHz ist das Telefonieformat. Wenn Sie Anrufe von einem Anbieter wie Twilio aufnehmen, kommt das Audio als μ-law mit 8 kHz an. Sie sollten es in diesem Format weiterleiten, statt es zweimal zu transkodieren. Das passende Quellformat vermeidet Resampling-Artefakte und einen unnötigen Konvertierungsschritt.

Die Chunk-Größe beeinflusst die wahrgenommene Latenz am direktesten. Sie senden Audio in Chunks, und der Erkenner erzeugt Partials, sobald Chunks eintreffen. Kleinere Chunks bedeuten häufigere Updates und eine geringere Latenz bis zum ersten Partial; größere Chunks bedeuten weniger Nachrichten und etwas mehr Kontext pro Inferenz. Ein praktikabler Bereich liegt bei 20–250 ms Audio pro Chunk. Als konkreter Anhaltspunkt: Bei mono PCM mit 16 kHz und 16 Bit entspricht eine Sekunde Audio 32.000 Byte, ein Chunk von 100 ms also etwa 3.200 Byte.

Mikrofoneingaben im Browser erfassen

Im Browser ist die richtige Lösung die Web-Audio API mit einem AudioWorklet. Das Worklet läuft im Audio-Rendering-Thread, empfängt Audio in kleinen Frames und ist nicht wie das ältere ScriptProcessorNode von Rucklern im Main Thread betroffen. Seine Aufgabe ist es, die nativen Float-Samples des Browsers in 16-Bit-PCM zu konvertieren und an den Main Thread zu übergeben, der sie über WebSocket weiterleitet.

Der Kern des Worklet-Prozessors ist die Float-zu-PCM-Konvertierung:

// pcm-worklet.ts - registered via audioContext.audioWorklet.addModule()
class PCMWorklet extends AudioWorkletProcessor {
  process(inputs: Float32Array[][]) {
    const channel = inputs[0]?.[0]; // mono; Float32, range [-1, 1]
    if (!channel) return true;
    const pcm = new Int16Array(channel.length);
    for (let i = 0; i < channel.length; i++) {
      const s = Math.max(-1, Math.min(1, channel[i]));
      pcm[i] = s < 0 ? s * 0x8000 : s * 0x7fff;
    }
    // Transfer the buffer to the main thread without copying.
    this.port.postMessage(pcm.buffer, [pcm.buffer]);
    return true;
  }
}
registerProcessor("pcm-worklet", PCMWorklet);

Die Pipeline im Code

Die Pipeline besteht aus drei Komponenten: einem Browser-Client, der das Mikrofon erfasst und PCM an Ihren Server streamt; einem Node-Server, der Audio an Scribe v2 Realtime weiterleitet und Transkripte zurücksendet; und einem skriptfähigen Client, der PCM aus einer Datei oder Telefonie-Bridge streamt.

Der Server leitet weiter, statt den Erkenner direkt im Browser bereitzustellen – aus einem wichtigen Grund: Ihr ElevenLabs API-Key ist geheim und darf nie im clientseitigen Code erscheinen. Der Server verwahrt den Key. Falls der Browser dennoch direkt mit dem Erkenner kommunizieren muss, erstellen Sie serverseitig ein kurzlebiges Einmal-Token und geben Sie dieses statt des API-Keys an den Client weiter.

Browser-Client

Der Client öffnet einen WebSocket zu Ihrem Server, erfasst das Mikrofon über das oben genannte Worklet und leitet jeden PCM-Frame weiter, sobald er erzeugt wird. Eingehende Ereignisse – bereits vom Server in { type, text } normalisiert – steuern den zuvor beschriebenen Partial-/Final-Status:

// client.ts - runs in the browser. ws is an open WebSocket to your server.
const audioContext = new AudioContext({ sampleRate: 16000 });
await audioContext.audioWorklet.addModule("pcm-worklet.js");

const mediaStream = await navigator.mediaDevices.getUserMedia({
  audio: { channelCount: 1, echoCancellation: true, noiseSuppression: true },
});

const source = audioContext.createMediaStreamSource(mediaStream);
const worklet = new AudioWorkletNode(audioContext, "pcm-worklet");

// Forward each PCM frame to the server the moment it is produced.
worklet.port.onmessage = (e: MessageEvent<ArrayBuffer>) => {
  if (ws.readyState === WebSocket.OPEN) ws.send(e.data);
};
source.connect(worklet);

// Manual commit: tell the server to finalize the current segment.
const commit = () => ws.send(JSON.stringify({ type: "commit" }));

Server-Relay

Der Server öffnet pro Client eine Erkennerverbindung, behält den API-Key auf dem Server, leitet binäres PCM direkt weiter und normalisiert Erkennerereignisse in das stabile Format { type, text }, das der Client verarbeitet:

// server.ts - Node, using the `ws` library. ELEVENLABS_API_KEY and the
// recognizer URL come from the environment; see the Speech to Text reference
// for the exact path and query parameters.
import { WebSocketServer, WebSocket } from "ws";

new WebSocketServer({ port: 8080 }).on("connection", (client) => {
  // The API key stays on the server, never on the wire to the browser.
  const recognizer = new WebSocket(process.env.RECOGNIZER_WSS_URL!, {
    headers: { "xi-api-key": process.env.ELEVENLABS_API_KEY! },
  });

  // Browser -> recognizer: forward binary PCM, translate control messages.
  client.on("message", (data, isBinary) => {
    if (recognizer.readyState !== WebSocket.OPEN) return;
    if (isBinary) recognizer.send(data); // raw PCM bytes
    else if (JSON.parse(data.toString()).type === "commit")
      recognizer.send(sendCommit());
  });

  // Recognizer -> browser: normalize events into a stable shape.
  recognizer.on("message", (raw) => {
    const event = parseRecognizerEvent(raw.toString());
    if (event && client.readyState === WebSocket.OPEN)
      client.send(JSON.stringify(event));
  });

  // ... open handshake, queueing pre-open audio, and teardown on close/error
});

Alles Endpunkt-spezifische ist auf die beiden Adapterfunktionen unten begrenzt. Ersetzen Sie die Feldnamen durch die exakten Namen aus der Speech-to-Text-Referenz; der Rest der Pipeline bleibt unverändert:

// The single place that knows the recognizer's wire format.
const sendCommit = (): string => JSON.stringify({ type: "commit" });

type NormalizedEvent =
  | { type: "partial"; text: string }
  | { type: "final"; text: string }
  | { type: "vad"; speaking: boolean };

function parseRecognizerEvent(raw: string): NormalizedEvent | null {
  const msg = JSON.parse(raw);
  if (msg.is_final === true || msg.type === "final")
    return { type: "final", text: msg.text ?? "" };
  if (msg.type === "vad") return { type: "vad", speaking: !!msg.speaking };
  if (typeof msg.text === "string")
    return { type: "partial", text: msg.text };
  return null;
}

Skriptfähiger Backend-Client

Für Backend-Pipelines und den unten beschriebenen Benchmark funktioniert dieselbe Erkennerverbindung auch ohne Browser: Lesen Sie PCM aus einer beliebigen Quelle, takten Sie es im Echtzeit-Chunk-Rhythmus und lesen Sie Ereignisse zurück. API-Key und URL stammen wie auf dem Server aus der Umgebung.

// stream-stt.ts - pace ~100ms chunks at real time, then commit the tail.
const SAMPLE_RATE = 16000, CHUNK_MS = 100;
const CHUNK_BYTES = (SAMPLE_RATE * 2 * CHUNK_MS) / 1000; // 3200 bytes
const ws = new WebSocket(process.env.RECOGNIZER_WSS_URL!, {
  headers: { "xi-api-key": process.env.ELEVENLABS_API_KEY! },
});

// Send: walk the PCM buffer in 100ms chunks, sleeping between to mimic a
// live source. For audio that already arrives in real time, drop the sleep.
async function sendAudio(pcm: Buffer) {
  for (let off = 0; off < pcm.length; off += CHUNK_BYTES) {
    ws.send(pcm.subarray(off, off + CHUNK_BYTES));
    await new Promise((r) => setTimeout(r, CHUNK_MS));
  }
  ws.send(JSON.stringify({ type: "commit" })); // finalize the trailing segment
}

// Receive: print partials in place, append finals.
ws.on("message", (raw) => {
  const e = parseRecognizerEvent(raw.toString());
  if (e?.type === "final") console.log(`[final]   ${e.text}`);
  else if (e?.type === "partial") process.stdout.write(`[partial] ${e.text}\r`);
});

Speech-to-Text-Latenz und Word Error Rate benchmarken

Latenz und Word Error Rate variieren je nach Sprecher, Sprache, akustischen Bedingungen, Audiolänge, Netzwerkpfad zur nächstgelegenen Region jedes Anbieters und aktueller Auslastung des jeweiligen Dienstes. 

Ein Ergebnis, das von einem Laptop in einer Stadt gemessen wurde, lässt sich nicht auf Ihre Produktionsflotte in einer anderen übertragen. Führen Sie den Testaufbau auf Infrastruktur aus, die Ihrer Produktion ähnelt, mit Audio, das Ihren echten Eingaben ähnelt, und berichten Sie Bereiche und Verteilungen statt einzelner Werte.

Die einzigen relevanten Latenz- und Genauigkeitswerte sind jene, die Sie mit Ihrem eigenen Audio auf produktionsähnlicher Infrastruktur messen. Hier erfahren Sie, wie Sie die Speech-to-Text-Latenz benchmarken.

Was Sie bei der Speech-to-Text-Latenz messen sollten

Im Folgenden finden Sie die wichtigsten Metriken, die Sie beim Benchmarking der Echtzeit-Speech-to-Text-Latenz messen sollten:

• Zeit bis zum ersten Partial: Von der Übertragung des ersten Audio-Chunks bis zum Empfang des ersten nicht leeren Partials.
• Verzögerung von Partial zu Final: Vom letzten Audio-Chunk einer Äußerung bis zur finalen Hypothese.
• Word Error Rate (WER): WER des finalisierten Transkripts im Vergleich zu einer menschlichen Referenz, für alle Systeme identisch berechnet.
• Stabilitätsänderungen: Wie viele Partials vor der Finalisierung neu geschrieben werden. Diese Metrik zeigt näherungsweise, wie stark sich die Live-UI sichtbar verändert.

Kontrollvariablen

Um unzuverlässige Daten zu vermeiden, sollten Sie mehrere Kontrollvariablen in Ihr Experiment aufnehmen, damit alles konsistent bleibt.

Dies sind die wichtigsten Kontrollvariablen für das Benchmarking der Speech-to-Text-Latenz:

• Identisches Audio: Verwenden Sie für jedes System dieselben Dateien, dieselbe Abtastrate und dieselbe Codierung.
• Identische Taktung: Streamen Sie jedes System im selben Echtzeit-Chunk-Rhythmus, beispielsweise in Chunks von 100 ms.
• Wiederholen und Verteilungen berichten: Führen Sie jede Datei über den Tag verteilt mehrfach aus; berichten Sie Median und Randbereich (p50/p95).
• Identische Referenzen und Bewertung: Normalisieren Sie Text vor der WER-Berechnung auf dieselbe Weise, etwa Groß- und Kleinschreibung, Zeichensetzung und Zahlen.
• Region und Netzwerk offenlegen: Geben Sie an, wo der Testaufbau lief und wie der Pfad zu jedem Anbieter verlief.

Wenn Sie all diese Elemente konstant halten, erhalten Sie präzisere Metriken.

Grundgerüst für den Testaufbau

Der Messkern nimmt einen Anbieteradapter und erfasst Zeit bis zum ersten Partial, Finalisierungsverzögerung und Änderungen an Partials:

// benchmark.ts - measurement core; one StreamFn adapter per provider.
type StreamFn = (
  audioPath: string,
  onEvent: (kind: "partial" | "final", text: string) => void,
  result: RunResult
) => Promise<void>; // adapter sets result.lastChunkSentAt on the final chunk

interface RunResult {
  firstPartialMs?: number;
  finalLagMs?: number;
  hypothesis: string;
  partialEdits: number;
  lastChunkSentAt: number;
  startedAt: number;
}

async function measure(streamFn: StreamFn, audioPath: string): Promise<RunResult> {
  const result: RunResult = {
    hypothesis: "", partialEdits: 0, lastChunkSentAt: 0,
    startedAt: performance.now(),
  };
  let prevPartial = "";

  await streamFn(audioPath, (kind, text) => {
    const now = performance.now();
    if (kind === "partial") {
      if (text && result.firstPartialMs === undefined)
        result.firstPartialMs = now - result.startedAt;
      if (text !== prevPartial) { result.partialEdits++; prevPartial = text; }
    } else { // final
      result.hypothesis = result.hypothesis ? `${result.hypothesis} ${text}` : text;
      if (result.lastChunkSentAt)
        result.finalLagMs = now - result.lastChunkSentAt;
    }
  }, result);

  return result;
}

Die Word Error Rate ist eine standardmäßige Levenshtein-Distanz auf Token-Ebene über normalisierten Text. Schreiben Sie Referenz und Hypothese in Kleinschreibung und entfernen Sie in beiden identisch die Zeichensetzung, bevor Sie sie berechnen. Andernfalls messen Sie Ihren Normalisierer statt des Modells. Führen Sie diese Messung in einer Schleife aus, die jede Datei pro Anbieter etwa zehnmal ausführt, und berichten Sie die mediane Zeit bis zum ersten Partial sowie die mediane WER (p50/p95), da ein einzelnes Sample stark von Netzwerkschwankungen geprägt ist.

Damit der Test läuft, benötigen Sie zwei Dinge. Erstens schreiben Sie pro System einen StreamFn-Adapter. Der skriptfähige Client oben ist bereits einer; Adapter für andere Systeme folgen demselben Vertrag (audioPath, onEvent, result) und setzen result.lastChunkSentAt, wenn der letzte Audio-Chunk gesendet wird. Zweitens laden Sie Ihre Audiodateien und Referenzen und rufen die Messungen dafür auf. Führen Sie den Test auf einem Rechner aus, der Ihre Bereitstellung repräsentiert, mit Audio, das Ihre Nutzer repräsentiert. So erhalten Sie einen reproduzierbaren Vergleich.

Zusammenfassung: So erreichen Sie Echtzeit-Speech-to-Text 

In diesem Artikel haben wir viele Architekturänderungen behandelt, mit denen Sie Ihr System schrittweise verbessern und sich Echtzeit-Speech-to-Text annähern können.

Ein produktives Echtzeit-STT-System hängt von einigen zentralen Entscheidungen ab:

• Transport: Wählen Sie WebSocket für Einfachheit und kontrollierte Netzwerke und WebRTC, wenn Sie Verlusttoleranz benötigen und von Endgeräten erfassen.
• Partials und Finals: Behandeln Sie Partials als vorläufig und Finals als festgeschrieben. Stellen Sie sie unterschiedlich dar, damit Nutzer dem Live-Text vertrauen.
• Endpunkt-Erkennung: Nutzen Sie VAD für die freihändige Segmentierung, den manuellen Commit als Überschreibung und stimmen Sie den Stille-Schwellenwert auf die Interaktion ab, nicht auf eine Konstante.
• In-Stream-Features: Aktivieren Sie In-Stream-Features nur dort, wo das Live-Erlebnis sie benötigt, und verschieben Sie den Rest auf einen Batch-Durchlauf mit Scribe v2.
• Audioformat: Erfassen Sie kleine PCM-Frames, senden Sie Chunks von etwa 100 ms und verwenden Sie für Telefonie das Quellformat.
• Benchmarking: Stellen Sie die Regler für Genauigkeit und Latenz empirisch anhand Ihres eigenen Audios und Ihrer Zielmetrik ein.
• API-Sicherheit: Bewahren Sie Ihren API-Key auf dem Server auf oder erstellen Sie Einmal-Tokens für direkte Client-Verbindungen.

Wenn Sie erfahren möchten, wie Sie die Latenz eines Voice Agents optimieren, haben wir dazu ebenfalls einen Leitfaden erstellt.

Echtzeit-Speech-to-Text-Systeme mit Scribe v2 Realtime entwickeln

Scribe v2 Realtime erzeugt Partials bei einer Modelllatenz von etwa 150 ms. Ob Ihre Nutzer diesen Wert oder eine höhere Latenz erleben, hängt von der Architektur darum herum ab – und diesen Teil kontrollieren Sie. Mit den Strategien aus diesem Artikel bauen Sie eine verbesserte Pipeline-Architektur auf, die Latenz reduziert und das Kundenerlebnis verbessert. 

Wenn Sie tiefer einsteigen möchten, entdecken Sie die Übersicht der Speech-to-Text-Funktionen, lesen Sie unsere Modellreferenz mit der vollständigen Liste von Funktionen und Sprachen und besuchen Sie die Produktseiten für Echtzeit: Echtzeit-Speech-to-Text-API und Echtzeit-Speech-to-Text.

Wenn Sie bereit sind, erstellen Sie ein kostenloses ElevenLabs-Konto und streamen Sie noch heute Ihr erstes Transkript.

FAQ zur Echtzeit-Speech-to-Text-Latenz