Voice-AI-Leistung, Parallelität und Kapazitätsplanung

Hinweis zum Umfang. Ein Kapazitätsergebnis gilt ausschließlich für die getestete Arbeitslast, das Modell, die Sprache, Hardware, Software und Bereitstellungskonfiguration. Dieser Leitfaden beschreibt eine Messmethode und nennt keine allgemeingültige Zahl von Anrufen pro GPU.

Wichtige Erkenntnisse

• Messen Sie für die Nutzererfahrung vom Ende der Äußerung bis zum ersten abspielbaren Audio und bewahren Sie Komponentenzeitstempel für die Diagnose auf.
• Führen Sie Lasttests mit produktionsnahen Ankunftsraten, Sitzungsverhalten sowie Text- und Audiodauern durch. Eine Schleife mit fester Parallelität ersetzt kein Ankunftsmodell.
• Definieren Sie die nutzbare Kapazität als die höchste getestete Last, die noch alle Latenz-, Fehler-, Warteschlangen- und Wiederherstellungsziele erfüllt.
• Behandeln Sie p99, Echtzeitfaktor und GPU-Auslastung als Nachweise mit klar benanntem Geltungsbereich und nicht als eigenständige Kapazitätsversprechen.
• Berechnen Sie Kosten anhand der getesteten nutzbaren Kapazität einschließlich fehlgeschlagener und abgebrochener Anfragen und nicht anhand eines theoretischen Spitzendurchsatzes.

Zuletzt aktualisiert im August 2026. Hier werden keine KugelAudio-Hardwarekapazitäts- oder Latenzergebnisse angegeben.

Welche Latenz erlebt ein Nutzer von Voice AI tatsächlich?

Nutzer erleben die Zeit vom Ende ihrer Äußerung bis zum Beginn einer sinnvollen Wiedergabe. Je nach Anwendung umfasst sie Turnerkennung, Transkription, Anwendungslogik, Ausgabe des Sprachmodells, Textnormalisierung, TTS, Netzwerkübertragung, Decodierung und Wiedergabepuffer. Die reine Modellinferenzzeit bildet dieses Erlebnis nicht ab.

Instrumentieren Sie einen Trace mit monotonen Zeitstempeln an folgenden Grenzen:

user turn end
-> transcript ready
-> first stable text sent to TTS
-> TTS request admitted
-> synthesis starts
-> first audio byte received
-> enough valid audio is decoded and buffered
-> playback starts
-> synthesis completes or is cancelled

Benennen Sie eine Metrik nach ihren Endpunkten. Die TTS-Zeit bis zum ersten Audio (TTFA) kann beispielsweise von der Annahme einer Anfrage bis zum ersten Audioblock reichen; die nutzerseitige Zeit bis zum ersten abspielbaren Audio dagegen vom Ende des Turns bis zum Wiedergabestart. Das erste Netzwerkbyte kann nur ein Header oder Teil-Frame sein und ist nicht automatisch abspielbar. Erfassen Sie Clientregion, Wiederverwendung der Verbindung, Codec, Abtastrate und Regel für den Wiedergabepuffer gemeinsam mit dem Ergebnis.

Der Leitfaden zu Streaming und Chunking von KugelAudio erläutert, wie serverseitiges Chunking und das Flush-Verhalten des Clients die TTFA beeinflussen. Der vollständige Anwendungspfad muss dennoch gesondert gemessen werden.

Geeignet für: Führen Sie diese Fälle als getrennt benannte Szenarien aus. Werden Kaltstarts, Lastspitzen und gleichmäßiger Verkehr in einem einzigen Ergebnis zusammengefasst, bleibt die Ursache eines langsamen Perzentils verborgen.

Wie sollte ein Kapazitätstest die Produktivlast modellieren?

Beginnen Sie mit einem versionierten Arbeitslastmanifest und nicht mit einer beliebigen Zahl von Anfragen. Erfassen Sie:

• Ankunftsrate von Sitzungen und Verteilung von Lastspitzen;
• gleichzeitige Anrufe, Turns pro Sitzung und Denkzeit zwischen den Turns;
• Verteilung von Textlängen, Sprachen, Stimmen und Normalisierung;
• Dauer, Format und Abtastrate des generierten Audios;
• Streaming-Chunk- und Flush-Verhalten;
• Wiederverwendung von Verbindungen, Wiederverbindungen, Fristen und Wiederholungsversuche;
• Unterbrechungen, Abbruchzeitpunkte und abgebrochene Sitzungen;
• Noisy-Neighbor- oder Batch-Last auf denselben Abhängigkeiten.

Verwenden Sie nach Möglichkeit bereinigte Verteilungen aus dem Produktivbetrieb. Andernfalls veröffentlichen Sie Textkorpus oder deterministischen Generator, Zufalls-Seed und Verteilungsparameter. Speichern Sie einen Hash des Korpus und die Version des Lastgenerators, damit spätere Durchläufe dieselbe Arbeit verwenden.

Wählen Sie das Modell des Lastgenerators bewusst. Ein Closed-Loop-Generator wartet auf eine Antwort, bevor er die nächste Anfrage sendet. Wird der Dienst langsamer, erzeugt er dadurch weniger Last und kann eine Überlastung verbergen. Das Modell ist dennoch passend, wenn eine feste aktive Parallelität selbst die Produktivbedingung darstellt. Ein Open-Loop-Generator plant Ankünfte unabhängig vom Abschluss vorheriger Antworten. Der Leitfaden zu Lasttests von Google Cloud erläutert diesen Unterschied. Bei einem Anrufprodukt sollten Sitzungen nach einem Ankunftsmodell beginnen und innerhalb der Sitzung realistisches Turn-Timing beibehalten. Berichten Sie geplante und tatsächlich gesendete Last, weil ein überlasteter Lastgenerator den Test ungültig macht.

Führen Sie Kalt- und Warmtests getrennt aus. Definieren Sie genau, was „kalt“ bedeutet, etwa ein neues Replikat mit noch nicht geladenem Modell, und erfassen Sie jede Startphase. Beenden Sie bei einem Warmtest zunächst die festgelegte Aufwärmphase und starten Sie die Messung erst, wenn Durchsatz, Warteschlange und Ressourcensignale eine vorab definierte Stabilitätsregel erfüllen. Mischen Sie die erste Anfrage weder in ein warmes Perzentil noch verwerfen Sie sie, ohne das Kaltergebnis auszuweisen.

Wie hängen Parallelität, Little's Law und Echtzeitfaktor zusammen?

„Gleichzeitige Anrufe“ kann offene Sockets, aktive Sitzungen, wartende Anfragen oder Streams bezeichnen, die gerade Audio erzeugen. Weisen Sie diese Größen getrennt aus. Aktive Generierung verbraucht Inferenzressourcen, Wartezeit erhöht die Latenz und belegt Dienstressourcen, und inaktive Anrufende benötigen weiterhin Verbindungen und Speicher.

Für ein stabiles System setzt Little's Law langfristige Durchschnittswerte in Beziehung:

L = lambda * W

L       average work in the measured system
lambda  effective throughput per second
W       average time each item spends in that system, in seconds

Verwenden Sie Little's Law als Plausibilitätsprüfung und erste Schätzung der Arbeitslast. Es prognostiziert weder Tail-Latenz noch maximalen Durchsatz oder erforderliche Reservekapazität. Definieren Sie für alle drei Größen dieselbe Systemgrenze, zählen Sie abgeschlossene statt ungeprüft angebotener Arbeit und wenden Sie die Beziehung nicht auf Zeitfenster mit weiter wachsender Warteschlange an.

Der Echtzeitfaktor (RTF) beantwortet eine andere Frage:

RTF  = synthesis elapsed time / generated audio duration
RTFx = generated audio duration / synthesis elapsed time = 1 / RTF

Ein niedrigerer RTF ist schneller, ein höherer RTFx ebenfalls. Die TTS-Performance-Dokumentation von NVIDIA verwendet RTFx und veröffentlicht Testeingaben, parallele Streams und Iterationen. Geben Sie verwendete Konvention und Zeitgrenze an. Ein reiner Compute-RTF schließt Warteschlangen- und Netzwerkzeit aus, ein Ende-zu-Ende-RTF nicht. Beide erfassen nicht die Zeit bis zum ersten abspielbaren Audio; berichten Sie daher zusätzlich TTFA und Lücken zwischen Audioblöcken. Ein Single-Stream-RTF unter eins belegt außerdem keine unbegrenzte Parallelität eines interaktiven Dienstes.

Wie viele Belege stützen ein Latenzperzentil?

Geben Sie neben jedem Perzentil die Anzahl der Beobachtungen, die Testdauer, die Anzahl der Wiederholungen, die Quantilmethode und die Histogrammbereiche an. Bei nur 100 erfolgreichen Beobachtungen wird p99 je nach Schätzer durch etwa eine Tail-Beobachtung bestimmt. Dabei handelt es sich um eine Beschreibung einer kleinen Stichprobe, nicht um eine stabile Verpflichtung. Google Cloud warnt in seiner Anleitung zur Latenzmetrik auch davor, dass p99 mit geringem Volumen einfach die langsamste Anfrage sein kann.

Eine allgemeingültige Stichprobengröße gibt es nicht. Definieren Sie vorab die akzeptable Unsicherheit und wählen Sie Testdauer und unabhängige Wiederholungen passend zur Schwankung des Datenverkehrs. Reicht ein Durchlauf nicht für eine belastbare Tail-Schätzung, berichten Sie ein niedrigeres Perzentil oder den Anteil der Anfragen unter einem festgelegten Latenzschwellenwert. Definieren Sie die Grundgesamtheit des Perzentils ausdrücklich. Weisen Sie Zeitüberschreitungen, Ablehnungen und Abbrüche als Ergebnisse aus und nehmen Sie sie in den Nenner der Erfolgsquote aller Versuche auf.

Bewahren Sie nach Möglichkeit Rohereignisse und für den Betrieb zusammenführbare Histogramme auf. Das Metrikdatenmodell von OpenTelemetry beschreibt die Histogrammaggregation. Legen Sie Bucket-Grenzen um die Entscheidungsschwellen der Anwendung. Mitteln Sie keine bereits berechneten Perzentile einzelner Instanzen; die Histogramm-Hinweise von Prometheus erklären, weshalb das ungültig ist.

Wie sollte sich ein Sprachdienst bei Überlastung verhalten?

Überlastung muss begrenzt und sichtbar sein. Legen Sie Annahmegrenzen anhand der Interaktionsfrist und der gemessenen Dienstkapazität fest. Kann eine Anfrage nicht rechtzeitig beginnen, lehnen Sie sie ausdrücklich ab oder leiten Sie sie weiter, statt sie in eine unbegrenzte Warteschlange aufzunehmen. Eine kurze Lastspitze darf weder zu minutenlanger veralteter Sprachausgabe führen noch Speicher bis zum Ausfall belegen.

Testen Sie den kompletten Zyklus:

1. Eine stabile Ausgangslast mit bekannter angebotener Rate festlegen.
2. einen versionierten Burst anwenden oder ein Replikat entfernen;
3. Annahmen, Ablehnungen, Alter der Warteschlange, Latenz und aktive Arbeit beobachten.
4. Ausgewählte Streams abbrechen und prüfen, ob ihre Rechenarbeit endet.
5. Fehler beziehungsweise Lastspitze beenden.
6. Prüfen, ob sich die Warteschlange leert und alle Signale in den Ausgangsbereich zurückkehren.
7. Prüfen, ob angenommene Streams weder vermischt noch dupliziert oder abgeschnitten wurden.

Wiederholen Sie eine Anfrage nur, wenn die verbleibende Interaktionsfrist einen weiteren Versuch erlaubt. Begrenzen Sie Versuche und verwenden Sie Backoff mit Jitter; synchronisierte Wiederholungen können eine neue Lastspitze verursachen. Der Google-SRE-Leitfaden zu kaskadierenden Fehlern verbindet realistische Kapazitätstests, kurze Warteschlangen, frühe Ablehnung und kontrollierte Wiederholungsversuche. Ein Ersatzweg kann eine vorab genehmigte Ansage, ein getrennt bereitgestellter Dienst oder die Übergabe an einen Menschen sein, muss aber ebenfalls unter Last getestet werden.

Wie sollten Autoscaling und GPU-Telemetrie getestet werden?

Autoscaling reagiert erst, nachdem sich die Nachfrage verändert hat. Messen Sie die vollständige Skalierungsverzögerung: Metrikerfassung, Entscheidung, Scheduling, Verfügbarkeit des Images, Laden des Modells, Zustandsprüfungen und Aufwärmen. Zugangskontrolle und Reservekapazität müssen Anfragen währenddessen schützen. Testen Sie neben Scale-up auch Scale-down, Connection Draining, Rolling Updates und ein mögliches Pendeln der Skalierung.

Kubernetes dokumentiert benutzerdefinierte und externe Metriken sowie Stabilisierungsregeln im Leitfaden zum Horizontal Pod Autoscaler. Ein allgemeines CPU-Ziel ist für GPU-TTS nicht automatisch geeignet. Alter der Warteschlange, angenommene aktive Arbeit und ein Sättigungssignal reagieren möglicherweise direkter. Verwenden Sie aber nur aktuelle, begrenzte Metriken, die anhand der nutzerseitigen Latenz validiert wurden.

GPU-Auslastungs-, Speicher-, Temperatur-, Strom- und Hardwarefehlerzähler erklären, warum sich ein Ergebnis geändert hat. Sie definieren nicht die nutzbare Kapazität. Korrelieren Sie sie mit der Wartezeit in der Warteschlange, der Synthesezeit, dem ersten abspielbaren Audio, dem Abschluss und Fehlern. Die Data Center GPU Manager-Dokumentation von NVIDIA beschreibt die verfügbaren Gesundheits- und Telemetriefunktionen. Notieren Sie den Metriknamen, das Stichprobenintervall, die Hardware- und Exporterversion, anstatt ein einzelnes „GPU-Prozent“-Diagramm zu melden.

Wie verwandeln Sie Ergebnisse in Replikate und Kosten?

Steigern Sie für jedes Modell und jeden Arbeitslastmix die angebotene Last schrittweise und wiederholen Sie Tests an der Grenze. Die nutzbare Kapazität pro Replikat ist die höchste getestete Rate, bei der alle vorab festgelegten Kriterien für Latenz, Fehler, Warteschlangenstabilität und Wiederherstellung erfüllt werden. Prüfen Sie anschließend mehrere Replikate: Routing, Verbindungsaffinität sowie gemeinsame Abhängigkeiten für Normalisierung, Speicherung und Steuerungsebene können lineare Skalierung verhindern.

Eine erste Planungseinschätzung lautet:

replicas = ceiling(forecast peak offered rate / validated per-replica rate)

Das ist noch nicht die endgültige Zahl für die Bereitstellung. Ergänzen Sie Kapazität für das gewählte Ausfallszenario, Wartung, Prognosefehler und Startverzögerung und testen Sie diese Topologie erneut. Die Reserve ist eine Geschäfts- und Zuverlässigkeitsentscheidung und kein allgemeingültiger Prozentsatz. Google SRE empfiehlt im Leitfaden zur Kapazitätsplanung Nachfrageprognosen und regelmäßige Lasttests, um Rohressourcen mit der Dienstkapazität in Beziehung zu setzen.

Vergleichen Sie die Wirtschaftlichkeit nur bei identischen Leistungszielen:

cost per delivered audio hour =
  total deployment cost during the window / successful playable audio hours

cost per 1,000 completed interactions =
  total deployment cost during the window / completed interactions * 1,000

Berücksichtigen Sie Rechenleistung, inaktive Replikate, Orchestrierung, Lizenzen und zurechenbare Netzwerkkosten. Fehlgeschlagene, abgelehnte und abgebrochene Arbeit bleibt im Zähler, damit Verschwendung sichtbar ist. Veröffentlichen Sie Auslastung und Preisdatum. Ein günstigeres Ergebnis bei Sättigung, das die Latenzziele verfehlt, ist kein wirtschaftlicher nutzbares System.

Was muss ein reproduzierbarer Kapazitätsbericht enthalten?

Ein Bericht sollte Arbeitslastmanifest und Korpus-Hash, Version und Topologie des Lastgenerators, Client- und Serverregionen, Zeitquelle, Modell-, Stimm-, Normalisierungs- und Bereitstellungsversionen, Hardware, Treiber und Energiemodus, Konfiguration von Replikaten, Batches und Warteschlangen, Aufwärm- und Messfenster, Rohdaten oder zusammenführbare Latenzverteilungen, angebotene, angenommene, abgelehnte und abgeschlossene Arbeit, Dauer der Audioausgabe, sämtliche Fehler- und Abbruchklassen, Ressourcentraces sowie den zeitlichen Verlauf von Überlastung und Erholung enthalten.

Schließen Sie mit Entscheidungen statt Adjektiven: bestandene Last, nicht erfüllte Kriterien, gewählte Replikatzahl, Ausfallreserve, Autoscaling-Grenzen und Auslöser für einen erneuten Test. Der Google-SRE-Leitfaden zu Service-Level-Zielen bietet einen sinnvollen Rahmen, um diese Kriterien aus den Erwartungen der Nutzer abzuleiten.

Für eine vom Kunden betriebene KugelAudio-Bereitstellung dokumentiert der Self-Hosting-Leitfaden die Auslieferung an Kubernetes per Helm-Chart. Eine Garantie für Parallelität auf bestimmter Hardware wird nicht veröffentlicht. Bestimmen Sie die Kapazität für das gewählte Modell, die Hardware und die Arbeitslast mit der beschriebenen Methode.

Was sind die Einschränkungen dieses Leitfadens?

Dieser Artikel führt keinen Benchmark für eine bestimmte GPU, ein Modell, eine Stimme oder Bereitstellung durch und gibt kein allgemeines Ziel für Gesprächslatenz, Warteschlangengröße oder Reservekapazität vor. Diese Entscheidungen hängen von Anrufablauf, Nutzererwartungen, Verkehrsschwankungen, Fehlerstrategie und den Messdaten des tatsächlichen Systems ab.

FAQ

Ist die Zeit bis zum ersten Byte dasselbe wie die Zeit bis zum ersten abspielbaren Audio?

Nein. Das erste Byte kann ein Header oder Teilrahmen sein. Das erste abspielbare Audio ist der Punkt, an dem der Client über gültiges dekodiertes Audio und genügend Puffer verfügt, um mit der Wiedergabe gemäß der deklarierten Player-Richtlinie zu beginnen.

Warum reicht die durchschnittliche Latenz nicht aus?

Ein Durchschnitt verbirgt die Verteilung und sagt nichts über Ausfälle aus. Melden Sie die Anzahl, ausgewählte Perzentile, die Schwellenwert-Erfüllungsrate, Fehler, Zeitüberschreitungen, Ablehnungen und Abbrüche für dasselbe Messfenster.

Wie viele Anrufe kann eine GPU verarbeiten?

Das lässt sich nur mit einem passenden Benchmark bestimmen. Modell, Hardware, Bereitstellung, Text- und Audiodauer, Streaming-Verhalten, Arbeitslastmix und Latenzziel beeinflussen die nutzbare Parallelität.

Reicht RTF unter eins für einen Echtzeit-Voice-Agenten?

Nein. Es zeigt, dass das gemessene Syntheseintervall kürzer war als die generierte Audiodauer. Es werden weder erstes abspielbares Audio, Warteschlangenverzögerung, Endlatenz, Abbruchverhalten noch Multi-Stream-Kapazität ermittelt.

Sollte die GPU-Auslastung Autoscaling auslösen?

Nur wenn Tests zeigen, dass sie bevorstehenden Nutzerdruck früh genug anzeigt. Vergleichen Sie sie mit Alter der Warteschlange, aktiver Generierung, Annahmerate, nutzerseitiger Latenz und der tatsächlichen Zeit, bis ein neues Replikat bereit ist.

Was soll passieren, wenn die Kapazität erschöpft ist?

Nehmen Sie keine Anfragen mehr an, deren Frist nicht eingehalten werden kann. Geben Sie ein eindeutiges Überlastergebnis zurück und aktivieren Sie den getesteten Ersatzweg. Verbergen Sie überschüssige Nachfrage weder in einer unbegrenzten Warteschlange noch in einer sofortigen Wiederholungsschleife.

Wie oft sollten Kapazitätstests wiederholt werden?

Wiederholen Sie sie nach wesentlichen Änderungen am Modell, der Laufzeit, dem Treiber, der Hardware, der Normalisierung, dem Routing, der Autoscaling-Richtlinie oder der Arbeitslast. Führen Sie den Vorgang auch erneut durch, bevor Sie eine Produktionskapazitätsverpflichtung eingehen oder erneuern.