Kapazität, Kosten und Ausfälle vor dem Start abnehmen

20 parallele Gespräche sind das Produktionsziel, 30 die geplante Spitzenreserve. Zwei konfigurierte Worker, ein 30-Kanal-SIP-Vertrag und erfolgreiche Mocktests beweisen diese Kapazität nicht. Die nachfolgende Abnahme benötigt eigene LiveKit-/Carrier-/STT-/TTS-/LLM-Zugänge, autorisierte Testteilnehmer bzw. einen geeigneten SIP-Audiolastgenerator und tatsächliche Messwerte.

Vorbedingungen

Kontrolliere /api/voice/status, MariaDB-/Redis-Erreichbarkeit, beide Worker, Providerkonkurrenzlimits und die erlaubten Trunk-/Kanal-/Arbeitsbereichbindungen. Halte Ansprechpartner, Abbruchmöglichkeit und reale Testminutenkosten fest. Es wird kein Lastgenerator beim Deployment automatisch gestartet.

Standard: maximal 30 aktive Voiceleases global, 20 je Arbeitsbereich, 15 Jobslots je Worker. Für einen 30er-Test verteile die Teilnehmer daher auf mindestens zwei ausdrücklich freigegebene Arbeitsbereiche, etwa 20+10. Eine zweite API-Keykopie hebt kein Anbieter-Projektlimit auf. Deepgram-Projekt-/Regionslimits

Verwende veröffentlichte Agentstände und freigegebene Testnummern mit bestätigter Einwilligung. Eine SIP-Verbindung ohne gesprochenes/gestreamtes Audio misst lediglich Signalisierung. Jeder simulierte Teilnehmer muss mehrere reale Turns einschließlich Unterbrechungen, Wissensfragen und einem sicheren Tooltest durchlaufen.

Messprotokoll und Zielschwellen

Lege pro Lauf Zeitpunkt, Software-/Imageversionen, Modell-/Stimm-/Regionauswahl, Hostdaten, Teilnehmerzahl und Laufdauer fest. Speichere Messwerte pro Turn und Call mit pseudonymen IDs; aktiviere keine Gesprächsaufnahme allein für den Test.

Messung	Vorgeschlagenes Abnahmeziel
20 aktive Anrufe	mindestens 15 Minuten ohne Prozessabsturz; ≥100 gemessene Antwortturns
30er-Spitzenreserve	mindestens 10 Minuten; Überlast wird kontrolliert abgewiesen statt unbeschränkt gestartet
Ende Nutzeräußerung → erstes hörbares Agentaudio	p95 ≤1,5 s, p99 ≤2,5 s bei einfachen FAQ-Turns
Unterbrechung	p95 ≤0,5 s bis Agentaudio stoppt; kein dauerhaftes Übersprechen
Audio	keine wiederholten Aussetzer, abgeschnittenen Antworten oder stummen verbundenen Calls
Mandanten-/Toolschutz	0 fremde Wissenszugriffe, Trunkzugriffe oder Credentialverwendungen
Schreibende Tools	0 unbeabsichtigte doppelte Aktionen; unklare Zustände werden nicht automatisch wiederholt
Kapazitätsbuchhaltung	nach Callende/Leaseablauf keine dauerhaft verlorenen Kapazitätsslots
Daten und Nutzung	keine fehlenden Gesprächsabschlüsse; erneute kumulative Metriken werden nicht doppelt berechnet

Diese Zahlen sind Betreiber-Zielschwellen, keine gemessenen Werte oder Anbieter-SLAs. Komplexe CRM-/Kalenderanfragen erhalten ein eigenes Budget und werden nicht mit einfachen FAQ-Antworten vermischt.

Stufenweise durchführen

1. Ein Gespräch: Inbound, Outbound, Browseraudio, veröffentlichte Wissensantwort und ein ausdrücklich zugelassenes lesendes Tool prüfen.
2. Fünf Gespräche: zehn Minuten, unterschiedliche Sprecher/Sprachen, kurze und lange Pausen, Unterbrechungen, Callende.
3. 20 Gespräche: mindestens 15 Minuten, alle Anrufe mit echtem Audio, zeitweise gleichzeitige Sprecherenden. Warmup und kalte Provider-/DGX-Starts getrennt erfassen.
4. 30 Gespräche: 20+10 Arbeitsbereiche, Reservetest mit anschließender kontrollierter zusätzlicher Ablehnung. API-Ratenlimits nicht einfach deaktivieren; Anrufe geplant aufbauen und länger halten oder einen autorisierten Carrier-/LiveKit-Testweg verwenden.
5. Dauerlauf: definierte reale Testminuten über einen längeren Zeitraum, Outboxzustellung, Datenbankwachstum, Speicher und offene Sessions prüfen.

Prometheus/Grafana prüfen HTTP- und Workerendpunkte; daraus allein lässt sich Audioqualität nicht ableiten. Verwende die tatsächlichen SDK-Metriken/LiveKit-Sessiondaten für STT-Ende, LLM-TTFT, TTS-TTFB und hörbaren Audiostart. Ein im SDK gemessener LLM-Tokenzeitpunkt ist nicht identisch mit dem Zeitpunkt beim Telefonhörer.

Ausfälle kontrolliert testen

• DGX/Heimnetz aus: Nur lokalen LLM oder DGX-VPN stoppen. Der Cloudpfad muss neue Antwortturns übernehmen; kein wiederholter bereits ausgegebener Antwortanfang. Danach Rückkehr prüfen.
• Ein Worker beendet: Calls des anderen Workers weiter beobachten. Bereits aktive Jobs werden nicht garantiert verlustfrei auf einen anderen Prozess übertragen. Prüfe kontrolliertes Ende, neue Dispatches, verbleibende Kapazität und Freigabe veralteter Leases nach maximaler Laufzeit/TTL.
• Redis nicht erreichbar: Keine unbeschränkt ungezählte Livefreigabe. Wiederanlauf muss die gemeinsame Kapazitätsprüfung wiederherstellen.
• STT/TTS/LLM Fehler oder 429: Verständlicher Abbruch/Fallback, keine erfundene erfolgreiche Toolbuchung und keine ungeprüften Doppelanrufe.
• Datenbankausfall: Kontrollierter Fehler, kein Erfolg ohne gespeichertes Ergebnis; anschließender Wiederanlauf prüfen.
• Ungültige Bindung: Fremden Kanal/Trunk/Toolkey/Webhook-Endpunkt gezielt anfragen und die Ablehnung im jeweiligen eigenen Testbereich belegen.

Ein einzelner Host bleibt ein gemeinsamer Ausfallpunkt. Für einen Verfügbarkeitsanspruch musst du Worker auf getrennten Hosts, Datenbank-/Netzwerkredundanz und ausreichend verbleibende Job-/Providerkapazität zusätzlich auslegen und testen. Die anfängliche Zwei-Container-Konfiguration liefert keine 99,9%-Zusage.

Nutzung und Kosten abgleichen

GET /api/usage und /api/usage/export stellen die gespeicherte Nutzung bereit. Trage in AIHUB_USAGE_PRICING deine tatsächlichen aktuellen Vertragspreise ein: Telefonie/Audio/STT/TTS pro Minute, gegebenenfalls TTS pro Zeichen sowie LLM-Input-/Cached-/Outputtoken und deinen Verkaufspreis. Alle Werte sind Dezimalwerte in EUR; es werden keine marktüblichen Fantasietarife vorausgesetzt.

Der Konfigurationsvertrag ist:

JSON-Feld	Einheit
currency	ausschließlich EUR
telephony_per_minute_eur	EUR pro gemessener Gesprächsminute
audio_platform_per_minute_eur	EUR pro gemessener Gesprächsminute für die Medienplattform
stt_per_minute_eur	EUR pro vom SDK gemessener STT-Audiominute
tts_per_minute_eur	EUR pro vom SDK gemessener TTS-Audiominute
tts_per_million_characters_eur	EUR pro 1 Mio. TTS-Zeichen
llm_input_per_million_eur	EUR pro 1 Mio. ungecachter LLM-Eingabetokens
llm_cached_input_per_million_eur	EUR pro 1 Mio. gecachter LLM-Eingabetokens
llm_output_per_million_eur	EUR pro 1 Mio. LLM-Ausgabetokens
sell_per_minute_eur	dein Verkaufspreis pro Gesprächsminute

Einträge sind nichtnegative JSON-Zahlen. Trage ausschließlich tatsächlich geltende Preisbestandteile ein: Wird TTS nur pro Zeichen berechnet, lasse tts_per_minute_eur weg, damit kein zweiter Preisbestandteil addiert wird. In der .env.production muss das ganze JSON in einfachen äußeren Anführungszeichen stehen, etwa AIHUB_USAGE_PRICING='{"currency":"EUR"}' vor der eigentlichen Preisergänzung. Fehlende Kostenfelder liefern keine vollständige Kostenschätzung; 0 bedeutet einen bewusst kostenlosen Preisbestandteil.

Die aktuelle Kalkulation verwendet einen gemeinsamen Betreiberpreissatz pro Sitzung; sie ist keine unterschiedliche Modellabrechnung für DGX-/Cloud-/Fallbacktokens. Preise werden bei Sitzungsanlage als Snapshot gespeichert. Ändere die Betreiberumgebung und erzeuge die App neu, damit neue Calls die neuen Preise erhalten; bestehende Sessions behalten ihren Snapshot.

Der Gesprächsminuten-/Token-/Zeichenabgleich muss zu den Providerrechnungen passen. Kumulative erneute Workerereignisse dürfen nicht erneut voll verrechnet werden. Beachte Einheiten, Mindestabrechnung, gerundete Carrierintervalle, Fehlanrufe, Cachepreise und weitere Kontogebühren. SIHub-Nutzungsschätzungen sind kein automatisch ausgestellter Rechnungsbeleg und keine garantierte Übereinstimmung mit jedem Anbieter-Abrechnungssystem.

Freigabe erst, wenn ein datiertes Protokoll mit gemessenen Ergebnissen, offenen Abweichungen und verantwortlicher Entscheidung vorliegt. Ein Statusfeld „Ziel 20/Reserve 30“ wird dadurch nicht rückwirkend zum automatischen Nachweis. Bei fehlenden Zugangsdaten lautet der korrekte Stand „Abnahme noch ausstehend“.