Echtzeit-Spracherkennung unter 200 ms: Ein Architekturleitfaden

Echtzeit-Spracherkennung (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 eine Frage der Architektur wie des Modells. Entwickler müssen Transport, Chunking, End-Pointing und den Erfassungspfad planen, da jeder davon Latenz hinzufügt. Ineffizienz in nur einem dieser Bereiche kann Ihr Budget von 200 ms sprengen.

Dieser Leitfaden bietet ein praxisnahes System zum Aufbau von Echtzeit-Spracherkennungspipelines – von der Transportschicht an. Wir orientieren uns an Scribe v2 Realtime, das Teiltranskriptionen mit etwa 150 ms Modelllatenz erstellt, über 90 Sprachen unterstützt, PCM-Audio (8 kHz–48 kHz) und μ-law akzeptiert sowie Voice Activity Detection und manuelle Commit-Steuerung zur Segmentfinalisierung bietet.

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

Zusammenfassung

• Echtzeit-Spracherkennungssysteme erfordern eine abgestimmte Architektur, damit die Latenz in der gesamten Pipeline niedrig bleibt.
• WebSocket ist für die meisten Pipelines die richtige Standardwahl. WebRTC bietet zwar mehrere Vorteile, ist aber komplexer.
• Voice Activity Detection übernimmt die freihändige Segmentierung. Mit manuellem Commit können Anwendungen eingreifen, wenn sie wissen, 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-Spracherkennung

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

WebSocket ist ein langlebiger, geordneter, zuverlässiger bidirektionaler Kanal über TCP. Sie öffnen eine Verbindung, senden binäre Audioframes und empfangen Transkriptereignisse. Er ist auf Client und Server einfach umzusetzen, durchquert Unternehmensproxys und Firewalls, die HTTPS bereits zulassen, und wird von jeder Browser- und Serverlaufzeit unterstützt.

Die Einschränkung von WebSocket liegt darin, dass es TCP verwendet. 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: Audio staut sich kurz und kommt anschließend gebündelt an.

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

Für Clients ohne direkte Verbindung benötigen Sie in der Regel TURN-Server. Auf Serverseite muss ein Medienstrom terminiert werden, statt einen Bytestrom zu lesen.

Die Abwägung auf einen Blick:

Für die meisten Anwendungsfälle ist WebSocket die richtige Wahl. Verwenden Sie es, wenn Ihre Clients über eine solide 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 Ihren Server erreicht.

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

Der Rest dieses Leitfadens nutzt WebSocket als Transport für die Verbindung zum Erkenner, da die Komponenten dadurch transparent bleiben und dies für die meisten Teams der richtige Einstieg ist. Nichts davon ist spezifisch für WebSocket: Sie können später eine WebRTC-Medienverbindung davor schalten, Audio auf dem Server in PCM decodieren und dieselben Chunks in die Pipeline weiterleiten.

Partials und finale Transkripte: vorläufige Ergebnisse erklärt

Ein Echtzeit-Erkenner wartet nicht auf einen vollständigen Satz, bevor er Text ausgibt. Stattdessen sendet er fortlaufend Vermutungen, die mit weiterem Audio präziser werden, und schreibt sie dann fest. Wer den Unterschied zwischen diesen beiden Zuständen versteht, erstellt ein Transkript, das lebendig statt fehlerhaft wirkt.

Eine partielle (vorläufige) Hypothese ist die beste Schätzung des Modells auf Basis des bisher empfangenen Audios. Partials sind absichtlich instabil. Mit weiterem Audio korrigiert das Modell frühere Wörter: Aus „Ich möchte“ kann „Ich möchte zwei Tickets“ werden, sobald späterer Kontext die Mehrdeutigkeit auflöst. Sie treffen schnell ein – darauf beziehen sich die etwa 150 ms Latenz – und sollen überschrieben 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 beziehen sich auf späteres Audio. Finals speichern Sie dauerhaft, senden sie an ein LLM oder legen sie als Transkript ab.

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

• Nutzererlebnis: Die Anzeige von Partials lässt ein Transkript live wirken: Nutzende sehen Wörter erscheinen, während sie sprechen. Das bestätigt, dass das Mikrofon funktioniert und das System zuhört.
• End-Pointing: Partials liefern ein kontinuierliches Signal für Sprachaktivität. Zusammen mit VAD können Sie damit entscheiden, wann ein Sprecher tatsächlich aufgehört hat.
• Timing nachgelagerter Schritte: In einer Voice-Agent-Pipeline folgen auf eingehendes Audio Speech to Text, 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 reduziert die wahrgenommene Antwortzeit, erfordert aber gelegentlich das Verwerfen spekulativer Arbeit.

Stellen Sie Partials und Finals unterschiedlich dar. Ein einfaches, effektives Muster ist eine einzelne veränderbare „aktuelle Zeile“, die an das neueste Partial gebunden ist und bei einem Final in ein Transkript nur zum Anhängen übernommen 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 als stabil dar und den aktuellen Text heller oder kursiv, damit Nutzende verstehen, dass er sich noch ändern kann.

End-Pointing und Voice Activity Detection (VAD)

Zu wissen, was gesagt wurde, ist nur die halbe Aufgabe. Ein Erkenner muss auch erkennen, wann ein Gedanke beendet ist. Diese Entscheidung bestimmt, wann Sie ein Segment finalisieren und wann ein Agent zu antworten beginnt.

End-Pointing ist die Entscheidung, dass eine Äußerung beendet ist. Eine zu frühe Finalisierung unterbricht Nutzende 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, wenn Sprache in anhaltende Stille übergeht, und nutzt diese Grenze zur automatischen Finalisierung eines Segments. VAD ist die richtige Standardwahl für dialogorientierte Schnittstellen, da sie sich dem natürlichen Sprechrhythmus anpasst, ohne dass Sie Zeitwerte manuell verfolgen müssen.
• Manuelle Commit-Steuerung: Mit der manuellen Commit-Steuerung entscheidet Ihre Anwendung unabhängig von Stille, 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 Regel zur Sprecherwechselsteuerung.

Beide Funktionen lassen sich gut kombinieren. Ein typischer Voice Agent verwendet VAD für die freihändige Bedienung und bietet manuellen Commit als Eingriffsmöglichkeit. So wird ein Nutzer, der zum Nachdenken pausiert, nicht unterbrochen, während ein Nutzer per Tastendruck sofort eine Segmentgrenze setzen kann.

Der Stille-Schwellenwert ist ein echter Zielkonflikt ohne universell richtigen Wert:

• Ein kurzer Timeout nach dem Ende der Sprache – etwa Finalisierung nach 200–400 ms Stille – lässt das System reaktionsschnell wirken. Er unterbricht jedoch auch Nutzende, die zwischen Satzteilen natürlich pausieren, teilt einen Gedanken in mehrere Segmente und löst bei einem Agenten möglicherweise eine verfrühte Antwort aus.
• Ein langer Timeout – etwa 800–1200 ms – toleriert natürliche Pausen und hält Äußerungen zusammen, verursacht aber eine merkliche Verzögerung, bevor das System reagiert.

Es gibt hier keine globale Konstante. Passen Sie den Schwellenwert an die Interaktion an:

• Diktat und Notizen erlauben längere Pausen, da Nutzende mitten im Satz nachdenken. Bevorzugen Sie längere Timeouts und setzen Sie auf VAD.
• Befehlssteuerung und transaktionale Agenten profitieren von kürzeren Timeouts plus manuellem Commit, da Sprecherzüge kurz und klar sind.
• Mehrsprachige Sprecher oder Nichtmuttersprachler pausieren häufiger. Planen Sie daher mehr Stille vor der Finalisierung ein.

Mit diesen Hinweisen bauen Sie ein wirksames End-Pointing-System auf und kommen der Echtzeit-Spracherkennung näher.

In-Stream-Funktionen: 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 in einen Batch-Durchlauf.

Die automatische Spracherkennung ermöglicht Scribe v2 Realtime, die gesprochene Sprache aus mehr als 90 unterstützten Sprachen zu erkennen, ohne dass Sie sie vorab angeben müssen. Dafür benötigt das Modell einen kurzen Audiobereich, um die Sprache sicher zu bestimmen. Die ersten Partials eines Streams können daher weniger stabil sein, während die Sprache ermittelt wird. Wenn Sie die Sprache bereits kennen, beseitigt ihre Angabe diese Mehrdeutigkeit und sorgt meist für stabilere frühe Partials.

Sprecherdiarisierung ordnet Sprache verschiedenen Sprechern zu und erkennt, wer was gesagt hat. Bei der Batch-Transkription ist das vergleichsweise einfach, da das Modell die gesamte Datei sieht. Beim Streaming ist es schwieriger: Der Erkenner muss einen Sprecher-Label nur anhand des bisher verfügbaren Audios vergeben. Ein Label für frühes Audio muss möglicherweise korrigiert werden, sobald mehr von der Stimme dieses Sprechers zu hören ist. Behandeln Sie Sprecher-Labels im Streaming wie partiellen Text: als 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 Modell und Übertragungsweg verarbeiten. Für die meisten Echtzeit-UIs benötigen Sie live nur Text und Segmentgrenzen. Detaillierte Metadaten können Sie mit Scribe v2 in einen Batch-Durchlauf nach dem Gespräch verschieben.

Audioformate für Streaming: PCM und μ-law

Transport- und Erkennungslogik erhalten die meiste Aufmerksamkeit, doch ein überraschend großer Anteil realer Fehler entsteht eine Ebene darunter: bei der Codierung und Chunking des Audios. Das richtige Format und die richtige Chunk-Größe zu wählen, ist die kostengünstigste Maßnahme zur Senkung der Speech-to-Text-Latenz.

PCM (linear, vorzeichenbehaftet mit 16 Bit, Little-Endian) ist das richtige Format, wenn Sie die Erfassung kontrollieren. Höhere Abtastraten enthalten mehr akustische Details: 16 kHz ist der Standard-Mindestwert für Spracherkennung und meist ausreichend; 8 kHz entspricht Telefonqualität und verliert hochfrequente Inhalte. Verwenden Sie die Abtastrate Ihrer Quelle. Ein Upsampling von Telefonieaudio mit 8 kHz auf 48 kHz bringt keinen Vorteil, da die fehlenden Informationen nicht wiederherstellbar sind.

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

Die Chunk-Größe beeinflusst die wahrgenommene Latenz am stärksten. 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 je Inferenz. Ein praxisnaher Bereich liegt bei 20–250 ms Audio pro Chunk. Bei 16-kHz-Mono-PCM mit 16 Bit entspricht eine Sekunde Audio 32.000 Byte. Ein Chunk von 100 ms hat somit etwa 3.200 Byte.

Mikrofoneingaben im Browser erfassen

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

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

// 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 und Transkripte zurückleitet, sowie einem skriptfähigen Client, der PCM aus einer Datei oder einer Telefonie-Bridge streamt.

Der Server leitet Daten weiter, statt den Erkenner direkt im Browser bereitzustellen – aus einem wichtigen Grund: Ihr ElevenLabs API-Key ist geheim und darf niemals im clientseitigen Code erscheinen. Der Server verwahrt den Key. Wenn 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 gezeigte 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-Zustand:

// 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 Verbindung zum Erkenner, 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 Endpunktspezifische ist auf die beiden folgenden Adapterfunktionen beschränkt. 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 folgenden Benchmark funktioniert dieselbe Erkennerverbindung ohne Browser: Lesen Sie PCM aus einer beliebigen Quelle, takten Sie es im Rhythmus der Echtzeit-Chunks und lesen Sie die Ereignisse zurück. API-Key und URL stammen wie beim 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 Wortfehlerrate benchmarken

Latenz und Wortfehlerrate hängen jeweils von Sprecher, Sprache, akustischen Bedingungen, Audiolänge, dem Netzwerkpfad zur nächstgelegenen Region jedes Anbieters und der aktuellen Auslastung jedes Dienstes ab.

Ein Ergebnis, das auf einem Laptop in einer Stadt gemessen wurde, lässt sich nicht auf Ihre Produktionsflotte in einer anderen übertragen. Führen Sie den Test auf Infrastruktur aus, die Ihrer Produktion entspricht, mit Audio, das Ihren tatsächlichen Eingaben ähnelt. Berichten Sie Bereiche und Verteilungen statt einzelner Zahlen.

Relevant sind nur die Latenz- und Genauigkeitswerte, die Sie mit Ihren eigenen Audiodaten auf produktionsnaher Infrastruktur messen. Hier ist ein Leitfaden zum Benchmarking der Speech-to-Text-Latenz.

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

Beim Benchmarking der Latenz von Echtzeit-Spracherkennung sollten Sie vor allem diese Metriken messen:

• 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.
• Wortfehlerrate (WER): WER des finalisierten Transkripts gegenüber einer menschlichen Referenz, für alle Systeme identisch berechnet.
• Stabilitätsänderungen: Wie viele Partials vor der Finalisierung umgeschrieben werden. Diese Kennzahl zeigt, wie stark sich die Live-UI scheinbar verändert.

Kontrollen

Um unzuverlässige Daten zu vermeiden, sollten Sie mehrere Kontrollen in Ihren Test einbauen, damit die Bedingungen konsistent bleiben.

Dies sind die wichtigsten Kontrollen für das Benchmarking der Latenz von Speech to Text:

• Identisches Audio: Verwenden Sie für jedes System dieselben Dateien, dieselbe Abtastrate und dieselbe Codierung.
• Identische Taktung: Streamen Sie jedes System mit derselben Echtzeit-Chunk-Taktung, beispielsweise Chunks von 100 ms.
• Wiederholen und Verteilungen berichten: Führen Sie jede Datei über den Tag hinweg mehrfach aus; berichten Sie Median und Randbereich (p50/p95).
• Identische Referenzen und Bewertung: Normalisieren Sie Text vor der WER-Berechnung auf dieselbe Weise, einschließlich Groß- und Kleinschreibung, Satzzeichen und Zahlen.
• Region und Netzwerk offenlegen: Geben Sie an, wo der Test ausgeführt wurde und welcher Pfad zu jedem Anbieter genutzt wurde.

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

Grundgerüst für den Test

Der Messkern übernimmt einen Anbieteradapter und erfasst die Zeit bis zum ersten Partial, die 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 Wortfehlerrate ist eine standardisierte Levenshtein-Distanz auf Tokenebene über normalisierten Text. Schreiben Sie Referenz und Hypothese beide klein und entfernen Sie Satzzeichen auf identische Weise, 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 verarbeitet, und berichten Sie die mediane Zeit bis zum ersten Partial sowie den medianen WER-Wert (p50/p95), da eine einzelne Stichprobe stark von Netzwerkschwankungen beeinflusst wird.

Damit der Test läuft, benötigen Sie zwei Dinge. Erstens schreiben Sie einen StreamFn-Adapter pro System. Der skriptfähige Client oben ist bereits einer; die 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 Ihrer Bereitstellung entspricht, und mit Audio, das Ihre Nutzenden repräsentiert. So erhalten Sie einen reproduzierbaren Vergleich.

Zusammenfassung: So erreichen Sie Echtzeit-Spracherkennung

In diesem Artikel haben wir viele Architekturentscheidungen behandelt, mit denen Sie Ihr System schrittweise verbessern und sich der Echtzeit-Spracherkennung annähern können.

Ein produktives Echtzeit-STT-System hängt von einer Handvoll Entscheidungen ab:

• Transport: Wählen Sie WebSocket für Einfachheit und kontrollierte Netzwerke, und WebRTC, wenn Sie Verlusttoleranz benötigen und Audio auf Geräten von Endnutzern erfassen.
• Partials und Finals: Behandeln Sie Partials als vorläufig und Finals als festgeschrieben. Stellen Sie sie unterschiedlich dar, damit Nutzende dem Live-Text vertrauen.
• End-Pointing: Verwenden Sie VAD für die freihändige Segmentierung, manuellen Commit als Eingriffsmöglichkeit und passen Sie den Stille-Schwellenwert an die Interaktion statt an eine feste Konstante an.
• In-Stream-Funktionen: Aktivieren Sie In-Stream-Funktionen nur, wenn das Live-Erlebnis sie benötigt, und verschieben Sie den Rest in 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 Ihrer eigenen Audiodaten und 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-Spracherkennungssysteme mit Scribe v2 Realtime entwickeln

Scribe v2 Realtime erzeugt Partials mit etwa 150 ms Modelllatenz. Ob Ihre Nutzenden diesen Wert oder eine höhere Latenz erleben, hängt von der Architektur darum herum ab – und diese liegt in Ihrer Hand. Mit den in diesem Artikel beschriebenen Strategien bauen Sie eine bessere Pipeline-Architektur, die die Latenz senkt und das Kundenerlebnis verbessert.

Vertiefen Sie sich mit der Übersicht zu den Speech-to-Text-Funktionen, lesen Sie unsere Modellreferenz mit der vollständigen Liste der 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 Latenz bei Echtzeit-Spracherkennung