3CX, NVIDIA Spark und Voicekit = Agentic AI ohne Cloud

[_voiper]

Hallo zusammen,

lokale Sprachmodelle sind für uns ein essenzieller Bestandteil souveräner KI. Daten sollen nur dann das Haus verlassen, wenn unbedingt notwendig.

Aus diesem Grund haben wir 3CX mittels internem Trunk an das Voicekit-Framework gekoppelt, das wiederum auf einem NVIDIA DGX Spark läuft, den wir ohnehin im Einsatz haben.

Das Ganze funktioniert so:

Sprach-Pipeline des Voicebots – Stufe / Modell

1. Spracherkennung (STT): NVIDIA Parakeet
2. Turn-Detection/Endpointing: LiveKit Multilingual Turn Detector
3. Dialog-LLM: Qwen3-Coder-Next (int4-AutoRound-Quantisierung, via vLLM)
4. Sprachsynthese (TTS): Qwen3-TTS-12Hz-1.7B-Base

Ablauf: Anrufer-Audio → Parakeet (STT) → Turn Detector erkennt Sprech-Ende
→ Qwen3-Coder-Next formuliert die Antwort → Qwen3-TTS erzeugt die Sprachausgabe.

Schön ist, daß mit dieser Lösung gleich mehrere Sprachen abdeckt und der Qwen3-Coder-Next stabil genug ist für einen stabilen Workflow.

Mit dieser Lösung sind die Möglichkeiten zur Automatisierung praktisch unendlich und es besteht keinerlei Abhängigkeit von externen Anbietern. In der Praxis bewährt sich das System bereits Tag für Tag.

Dies als kleine Inspiration zum Thema "3CX und Künstliche Intelligenz".

Viele Grüße

 

[fxbastler]

Erste Fragen dazu:

1. Läuft das flüssig genug?
2. Wie viele Token schafft die Kombination?
3. Wie ist die Auslastung im Normalbetrieb - wenn man das denn an irgend etwas festmachen kann?

 

[_voiper]

1. Das läuft flüssig, auch wenn die Antwortlatenz noch geringfügig besser sein dürfte (derzeit max. 2 Sek.). Wir haben allerdings das System für Smalltalk geöffnet, um Kunden zu inspirieren. Das kostet im Einzelfall etwas Zeit.

2. Die „Denk"-Geschwindigkeit des Bots liegt bei rund 72 Tokens/s. Eine typische Telefon-Antwort (ca. 40–60 Tokens, „ein bis drei Sätze") ist damit in unter einer Sekunde fertig generiert. Für die gefühlte Antwortzeit am Telefon ist der LLM-Decode nicht der Flaschenhals — die dominieren eher das STT-Endpointing (MIN_EOU/MAX_EOU) und die TTS-ttfb (~0,4–0,7 s, gelegentlich Tail-Spikes). Der LLM ist mit ~72 tok/s schnell genug, dass Sprechen kontinuierlich nachgefüttert wird.

Das sind Einzelanfrage-Werte (ein Anruf = ein Stream). Bei mehreren gleichzeitigen Anrufen teilt sich der Durchsatz je nach vLLM-Batching, aber pro Telefonleitung bleibt die Erfahrung ~70 tok/s.

3. Auslastung im Normalbetrieb

- Leerlauf: 0 % GPU, ~12 W. Der Betrieb ist stoßweise (bursty): Das LLM rechnet nur während eines Bot-Turns (~40–60
Tokens, <1 s), dann ~15–20 s Stille/Zuhören/TTS. Pro Anruf liegt die LLM-Auslastung damit bei grob 5–7 % Duty-Cycle.
- Reale Latenzen pro Turn (heutige Anrufe, geloggt):

┌─────────────────────────────┬────────┬────────────────────┐
│ Metrik │ Ø │ max │
├─────────────────────────────┼────────┼────────────────────┤
│ EOU (Endpointing-Wartezeit) │ 0,30 s │ 1,20 s (gedeckelt) │
├─────────────────────────────┼────────┼────────────────────┤
│ LLM ttft │ 0,37 s │ 1,36 s │
├─────────────────────────────┼────────┼────────────────────┤
│ TTS ttfb │ 0,81 s │ 6,28 s │
└─────────────────────────────┴────────┴────────────────────┘

Kann der Spark 2–3 Anrufe konstant bedienen? — Gemessen

Gleichzeitige LLM-Streams (Decode-Rate pro Stream):

┌──────────┬────────────┬────────────┬────────────┐
│ Parallel │ pro Stream │ aggregiert │ GPU │
├──────────┼────────────┼────────────┼────────────┤
│ 1 │ 69,9 tok/s │ 58 tok/s │ 96 %, 46 W │
├──────────┼────────────┼────────────┼────────────┤
│ 2 │ 63,2 tok/s │ 123 tok/s │ 96 %, 37 W │
├──────────┼────────────┼────────────┼────────────┤
│ 3 │ ~50 tok/s │ 122 tok/s │ 96 %, 40 W │
└──────────┴────────────┴────────────┴────────────┘

LLM-seitig: ja, locker. Selbst im Worst Case (alle 3 decodieren gleichzeitig) bleiben ~50 tok/s pro Anruf — eine
Telefon-Antwort (~50 Tokens) ist damit weiter in ~1 s fertig. Und weil Anrufe stoßweise sind, decodieren 2–3 Calls
fast nie gleichzeitig; die effektive LLM-Parallelität liegt meist bei 0–1.

Der vorstehende Spike bei TTS ttfb war ein Artefakt beim Smalltalk und wurde bereits gefixt. Der Normalwert beträgt 0,5-0,9 s

Insgesamt sind die Antwortzeiten mit Menschen vergleichbar, in Smalltalk-Einzelfällen etwas höher. Aber das ist wie gesagt bei uns ein "Goodie" für die Anrufer.

Wichtige Einordnung zur GPU-Zahl: Der Spark (Asus GB10) zeigt schon bei einem Stream 96 % — der Workload ist
speicherbandbreiten-limitiert (Unified LPDDR5X), nicht rechen- oder leistungsgebunden (nur 37–46 W von deutlich mehr
Budget). Deshalb sinkt die Einzelrate bei Parallelität (70→63→50), während der Aggregatdurchsatz bei ~122 tok/s
plateaut — die drei Modelle teilen sich denselben Speicherbus.

Der reale Flaschenhals: TTS, nicht LLM

Die geloggte TTS-ttfb hat schon jetzt (überwiegend Einzelanrufe) einen Ausreißer auf 6,28 s bei Ø 0,81 s — das ist das
bekannte Tail-Verhalten des 1.7B-TTS. Da alle drei Modelle sich die Speicherbandbreite teilen, ist genau die TTS-ttfb
das, was bei 2–3 gleichzeitig aktiven Anrufen zuerst reißt — nicht der LLM-Decode.

Fazit: Ja, 2–3 parallele Anrufe schafft der Spark bei praktisch konstanter LLM-Geschwindigkeit. Ob sie sich auch
flüssig anfühlen, entscheidet die TTS-ttfb unter echter Gleichlast. Das müsste getestet werden.

 

[fxbastler]

Danke für die Werte und die Einschätzung, gut zu wissen.

der Workload ist
speicherbandbreiten-limitiert (Unified LPDDR5X)

Ja, das ist ein bekanntes Problem. Daher hat 3CX seine Empfehlung dahingehend geändert ein System mit ausreichend Graka Rechenleistung und viel Speicher und per HBM angebunden zu nutzen. Der Preis ist halt ein anderer.

 

[_voiper]

Ich würde sagen, daß dieses Setup für max. 6 Kanäle ausreichend ist, wobei der Sweetspot bei 4 Kanälen liegen dürfte. Alles darüber hinaus bedarf schnellerem RAM. Mit 1-2 NVIDIA Blackwell 6000 dürfte man ein ganzes Stück weiter kommen. In diesem Zusammenhang könnte Apple nächstes Jahr noch für Überraschungen gut sein. Andererseits ist der NVIDIA-Stack solide und bestens unterstützt.

 

[fxbastler]

Mit 1-2 NVIDIA Blackwell 6000 dürfte man ein ganzes Stück weiter kommen.

Ich denke mit einer allein kommt man schon auf ein Mehrfaches an Faktor ggb. der DGX Spark Maschine. Wir haben noch keinen echten Anreiz gefunden die 10k pro Karte plus die 'Kleinigkeiten' ringsrum dafür auszugeben um damit zu spielen.

 

[_voiper]

Es ist auch ein guter Werbeträger und Innovationsflag. Und wenn ihr euren Workflow damit noch weiter optimieren könnt ist das vielleicht auch ein zusätzlicher Grund zur Einführung.

Aber klar: Nur für Telefonie lohnt sich das erst ab einer gewissen Größe des Unternehmens. Für uns ist es auch eher ein Zusatznutzen zur lokalen KI. Das Coder-LLM verwenden wir zum Programmieren und Steuern.

Insofern würde ich beim Thema "Lokale KI" grunsätzlich zum Einstieg raten, um eigene Erfahrungen zu sammeln. Und das geht halt nur mit eigener KI-Hardware.