Was wir beim Einrichten eines lokalen LLM über eine Telefonleitung gelernt haben

Jede verwaltete Sprach-KI-Plattform rechnet minutengenau ab. Das klingt vernünftig, bis man eine solche Plattform in einer Support-Hotline einsetzt und sie ihre Arbeit aufnimmt – denn die Belohnung für einen guten Mitarbeiter besteht darin, mehr Anrufe anzunehmen, und die Belohnung für mehr angenommene Anrufe ist eine höhere Rechnung. Je besser die Leistung, desto höher die Kosten. Bei einer Support-Hotline, die genau dazu da ist, das Anrufaufkommen aufzufangen, ist das der falsche Anreiz, sich dafür zu entscheiden.

Wir haben Vocale entwickelt, um die Telefonleitung eines Unternehmens zu bedienen: Es nimmt den Anruf beim ersten Klingeln entgegen, antwortet anhand der firmeneigenen Handbücher und Richtlinien und eröffnet ein Support-Ticket, wenn die ehrliche Antwort lautet, dass sich jemand darum kümmern muss. Schon früh haben wir eine Entscheidung getroffen, die alles danach geprägt hat. Die Plattform bietet zwei Engines hinter einem Produkt. In der gehosteten Stufe stammen Spracherkennung, Schlussfolgerung und Sprachsynthese von einer API eines Drittanbieters, und jede Minute wird abgerechnet. In der selbst gehosteten Stufe laufen alle drei Komponenten auf einer GPU, die das Unternehmen selbst kontrolliert; keine Audio- oder Dokumentendaten verlassen das Gebäude, und ein Anruf kostet lediglich Strom.

Beide Stufen verhalten sich aus Sicht des Anrufers identisch. Der Weg dorthin war der interessante Teil, und das haben wir dabei gelernt.

Was tatsächlich im Kreislauf ist

Ein Sprachagent ist kein Chatbot, an den man einfach ein Mikrofon angeflanscht hat. Ein Gesprächswechsel ist eine Kette, und jedes Glied verursacht eine Verzögerung, die ein Mensch hören kann.

Das Audio gelangt über WebRTC in einen LiveKit-Raum. Die Sprachaktivitätserkennung (wir verwenden Silero) ermittelt, wann der Anrufer tatsächlich zu sprechen begonnen und aufgehört hat. Das gepufferte Audio wird an Faster-Whisper weitergeleitet und kommt als Transkript zurück. Dieser Gesprächsabschnitt wird in Postgres geschrieben, anschließend werden der Chat-Kontext und der Verlauf an das Sprachmodell weitergeleitet, bei dem es sich auf unserer selbst gehosteten Ebene um Qwen3-8B handelt, das von vLLM bereitgestellt wird. Die Tokens werden zurückgestreamt, normalisiert und zu ganzen Sätzen zusammengefasst; erst dann erreichen sie XTTS-v2, das sie als Audio-Frames rendert, die über WebRTC zurückgesendet werden.

Vier Modelle, ein Datenbank-Schreibvorgang und ein Hin- und Rücklauf – alles innerhalb der Pause, die ein Anrufer toleriert, bevor er in die Stille hinein „Hallo?“ sagt.

Diese Kette lokal auszuführen, ist nicht der schwierige Teil. Sie lokal in Gesprächsgeschwindigkeit auf Hardware auszuführen, die ein mittelständisches Unternehmen tatsächlich anschaffen würde – darin liegt die technische Herausforderung.

Lektion eins: Unterbrechungen sind ein Produktmerkmal, kein Ausnahmefall

Anrufer reden den Agenten in den Wind. Das tun sie ständig, und sie tun es in dem Moment, in dem sie genug gehört haben – was normalerweise nach etwa sechs Wörtern einer zwanzig Wörter langen Antwort der Fall ist. Ein Mitarbeiter, der weiterredet, klingt so gestört, dass es schwer ist, das wieder in den Griff zu bekommen, denn der menschliche Instinkt ist es, lauter zu sprechen, und nun sprechen zwei Parteien gleichzeitig in ein System hinein, das keinem von beiden zuhört.

Das Abschalten des ausgehenden Tons ist die offensichtliche Hälfte. Die Hälfte, die leicht übersehen wird, ist das Transkript. Wenn die eigene Aufzeichnung des Agenten immer noch den vollständigen Satz enthält, den er sagen wollte, setzt sich das Gespräch auf der Grundlage eines Anrufs fort, der nie stattgefunden hat. Stellt man eine Folgefrage zu „der zweiten Option, die Sie erwähnt haben“, wird der Agent selbstbewusst etwas beantworten, das der Anrufer nie gehört hat.

Wenn also Sprache erkannt wird, stoppen wir den Ton und kürzen dann den gespeicherten Beitrag des Agenten auf das, was tatsächlich laut ausgesprochen wurde. Das Gespräch wird ausgehend von dem Anruf fortgesetzt, den der Anrufer erlebt hat, nicht von dem, den das System geplant hatte.

Lektion zwei: Man kann die Latenz nicht beseitigen, also muss man sie füllen

Wenn eine Frage eine Tatsache erfordert, durchsucht der Agent die indexierten Dokumente, bevor er antwortet. Diese Suche dauert lange genug, um als unterbrochene Verbindung wahrgenommen zu werden. Stille bei einem Telefonat ist nicht neutral. Sie ist beunruhigend.

Wir fügen nach etwa einer halben Sekunde eine kurze, natürliche Füllphrase ein und brechen sie ab, sobald das Abrufen der Informationen zuerst erfolgt. Es ist ein kleines Verhaltensdetail mit enormer Wirkung: Es verschafft dem Abruf die benötigte Zeit, und keine dieser Sekunden wird vom Anrufer als Funkstille wahrgenommen.

Dies ist auf der selbst gehosteten Ebene umso wichtiger, nicht weniger. Ein lokales Modell auf einer einzelnen GPU weist andere Latenzcharakteristika auf als die API eines Hyperscalers, und diese sind nicht durchweg schlechter. Sie sind lediglich anders verteilt. Indem wir das Gespräch so gestalteten, dass es variable Latenzen toleriert, konnten wir den Ausführungsort der Modelle ändern, ohne das Nutzererlebnis des Agenten zu beeinträchtigen.

Lektion drei: Geschriebener Text wird nicht vorgelesen

Geldbeträge, Datumsangaben als Ziffern, Uhrzeiten, Abkürzungen, Produktcodes. All das ist auf einem Bildschirm in Ordnung, in gesprochener Form jedoch falsch. Geben Sie einem Sprachmodell „1.250,00 bis zum 15.03.“ ein, und Sie werden etwas hören, das noch nie ein Mensch laut ausgesprochen hat.

Wir haben eine Normalisierungsschicht zwischen dem Sprachmodell und dem Sprachausgabemodell eingefügt, die Beträge, Datumsangaben, Uhrzeiten und Abkürzungen je nach Sprache in ihre gesprochene Form umschreibt, bevor sie die Synthese erreichen. Vocale läuft in sechs Sprachen, und diese Schicht ist sprachspezifisch, da sich die Regeln tatsächlich unterscheiden. Es gibt keine Abkürzung, bei der man den Code einmal für Englisch schreibt und dann übersetzt.

Dies ist die am wenigsten glamouröse Komponente im System und eine derjenigen, die den größten Einfluss darauf hat, ob der Agent wie ein Mensch oder wie ein Telefonmenü klingt.

Lektion vier: VRAM ist die Obergrenze, nicht die Rechenleistung

Das ist der Punkt, der uns am meisten überrascht hat und der die Dimensionierung der Hardware am stärksten beeinflusst.

Eine Live-Sprach-Sitzung hält ihre Modelle für die Dauer des Anrufs im Videospeicher. Die Parallelität wird daher durch den VRAM begrenzt, nicht durch den reinen Durchsatz. Man kann eine Karte mit reichlich Rechenleistung haben, die dennoch keinen weiteren Anruf annehmen kann, weil es keinen Platz mehr für die Modelle gibt.

Schlimmer noch: Wenn man das Framework standardmäßig GPUs bündeln lässt, landen Sprach- und Sprachverarbeitungsaufgaben auf derselben Karte und behindern sich gegenseitig. Das Symptom ist kein Fehler. Es ist ein Gespräch, das unter Last langsamer wird, ohne dass eine einzelne Komponente dafür verantwortlich ist. Wir planen nun Sitzungen pro Karte ein und verteilen die Arbeitslast explizit auf die Karten.

Wenn Sie eine selbst gehostete Bereitstellung planen, sollten Sie zunächst die Anzahl der gleichzeitigen Aufrufe im Hinblick auf den Grafikspeicher berechnen. Alles andere ergibt sich aus dieser Zahl.

Was sich nicht ändert

Das Grundprinzip bleibt unverändert. Auf beiden Ebenen antwortet der Agent auf der Grundlage der vom Unternehmen hochgeladenen Dokumente und nicht aus dem Speicher des Modells: Eine Frage, die eine Tatsache erfordert, löst eine Suche aus, und die Antwort wird aus den gefundenen Ergebnissen zusammengestellt. Wenn nichts Relevantes gefunden wird, ist es die richtige Antwort – und genau die, die der Agent gibt –, dies mitzuteilen und anzubieten, ein Ticket zu erstellen. Ein kleineres lokales Modell ist kein Freibrief für mehr „Halluzinationen“, denn das Modell ist ohnehin nicht die Quelle der Wahrheit. Die Informationsgewinnung ist es.

Auch die Übergabe ändert sich nicht. Wenn der Agent nicht weiterhelfen kann, erfasst er das Thema, den Ansprechpartner und die Priorität, während der Anrufer noch in der Leitung ist, legt das Ticket an und fügt das Gesprächsprotokoll bei.

Das ist der Sinn dahinter, beide Ebenen auf ein einheitliches Verhalten auszurichten. Der Wechsel zwischen ihnen ist eine Konfigurationsangelegenheit, kein Neuaufbau.

Welches Modell sollten Sie also betreiben?

Ganz ehrlich: Beginnen Sie mit dem gehosteten Modell.

Die gehostete Ebene ist der schnellste Weg, um herauszufinden, ob ein Agent in Ihrer Leitung überhaupt nützlich ist, und das ist eine Produktfrage, keine Infrastrukturfrage. Unsere eigene Konsole hat die Kosten auf etwa sechs Cent pro Gesprächsminute ermittelt. Für ein Unternehmen, das täglich ein paar Dutzend Anrufe entgegennimmt, ist dies nicht der Posten, der zuerst optimiert werden sollte.

Das Selbsthosting macht sich ab zwei Schwellenwerten bezahlt, und es handelt sich dabei um unterschiedliche Schwellenwerte.

Der erste ist das Volumen. Die gemessenen Kosten skalieren mit der Nutzung, die Hardwarekosten hingegen nicht; daher gibt es einen Übergangspunkt, ab dem die GPU einfach günstiger ist. Wo dieser Punkt liegt, hängt von Ihrem Anrufvolumen ab, und Sie sollten ihn messen, anstatt ihn anzunehmen. Vocale misst die Kosten pro Modell und pro Organisation genau aus diesem Grund: Die Wahl zwischen einer API und einer Karte sollte eine Entscheidung sein, die auf Zahlen basiert, und kein Streitpunkt.

Der zweite Schwellenwert hat nichts mit Geld zu tun. Manche Unternehmen dürfen aufgrund behördlicher Auflagen, Kundenverträge oder interner Richtlinien keine Anrufaufzeichnungen, Transkripte oder interne Dokumente an Dritte weitergeben. Für sie ist die lokale Variante keine Optimierung. Es ist die einzige Version dieses Produkts, die überhaupt existieren darf, und kein Minutenpreis macht die gehostete Variante akzeptabel.

Diese beiden Schwellenwerte sollten bei der Bewertung eines Anbieters von Sprach-KI unbedingt getrennt betrachtet werden. Eine Plattform, die ausschließlich eine nach Verbrauch abgerechnete Inferenz anbietet, hat stillschweigend entschieden, dass der zweite Schwellenwert für Sie nicht gilt.

Die Kurzfassung

Lokale Inferenz in einer Support-Hotline ist heute praktikabel. Die Modelle sind gut genug, und die Tools (vLLM, Faster-Whisper, XTTS-v2, LiveKit) sind so ausgereift, dass die Pipeline kein Risiko darstellt.

Die Risiken sind diejenigen, die niemand in Demos zeigt: unterbrochen zu werden, während des Nachdenkens präsent zu klingen, Zahlen wie ein Mensch laut vorzulesen und zu wissen, wie viele Gespräche tatsächlich auf eine Karte passen. Wenn man diese Punkte richtig hinbekommt, wird die Wahl zwischen einer gehosteten API und der eigenen GPU zu dem, was sie schon immer hätte sein sollen: nämlich ein Posten im Budget und keine Einschränkung dessen, was man entwickeln darf.

• Local LLM
• Voice AI
• Self-hosted
• RAG
• vLLM
• LiveKit
• Support automation