KI-System-Engineering: Architektur, Latenz und lokale Modelle

Wie ein KI-System für sprachbasierte Interaktion mit Sub-Agenten vollständig lokal auf einer RTX 6000 Pro betrieben wird – und welche Architekturentscheidungen Latenz und Zuverlässigkeit bestimmen.

Wir wollten eine einfache Frage beantworten:

Lässt sich ein Voice-Agent mit Wissens/Datenbankzugriff vollständig lokal auf einer einzelnen professionellen GPU betreiben? Und wie schlägt sich ein solches System im Vergleich zu spezialisierten kommerziellen Voice-Plattformen?

Ein Voice-Agent ist ein KI-System, das Sprache zuverlässig erkennen, innerhalb kurzer Zeit antworten, natürlich klingen und gleichzeitig auf externe Informationen zugreifen muss. Fehler sind unmittelbar wahrnehmbar: Ein falsch verstandener Name, eine vertauschte Ziffer oder eine mehrsekündige Pause reichen aus, um den Gesprächsfluss zu unterbrechen.

Es sind in diesem Fall also genau die Punkte zu beachten, bei denen lokale Modelle oft das Nachsehen haben: Genauigkeit und Geschwindigkeit. Zwar sind starke offene Modelle wie Qwen3-235B-A22B oder Kimi K3 verfügbar, aber selbst mit großen Servern ist die Geschwindigkeit (Eingabe/Ausgabe Tokens-per-Second) oft nicht ausreichend, um damit einen Voice-Agenten sinnvoll zu bauen.

In vielen Anwendungsfällen sind unserer Meinung nach solch mächtige Modelle aber gar nicht notwendig. Eine Terminbuchung kann ein deutlich kleineres und „dümmeres“ Modell ebenso gut entgegennehmen. Auch das Durchsuchen großer Datenmengen wie Benutzerhandbüchern oder FAQs ist für kleinere Modelle heutzutage kein Problem mehr – insbesondere dann, wenn diese gut orchestriert sind und Verifikationsschritte mögliche Schwächen ausgleichen.

Im Folgenden testen wir, ob sich durch die Orchestrierung fokussierter LLM-Anwendungen und gezielter Verifikationsschritte ein KI-System bauen lässt, das angenehme sprachbasierte Konversationen ermöglicht und sowohl bei Qualität als auch Geschwindigkeit mit kommerziellen Lösungen vergleichbar ist. Der Voice-Agent als konkrete Ausprägung dieses Systems besteht aus verschiedenen Komponenten wie Voice Activity Detection (VAD), Turn Detection, Speech-to-Text, einem Hauptagenten, mehreren Sub-Agenten und Text-to-Speech. Der gesamte Aufbau läuft vollständig auf einer Workstation mit einer NVIDIA RTX 6000 Pro. Vergleichbare Hardware kann auch bei Infrastruktur-Anbietern wie Hetzner gemietet werden.

Warum ein Voice-Agent ein schwieriger Testfall ist

Ein Voice-Agent ist ein besonders anspruchsvoller Testfall für ein KI-System, da er drei Anforderungen verbindet, die bereits einzeln anspruchsvoll sind.

1. Fehler werden unmittelbar wahrgenommen

Bei einem Chatbot kann ein Nutzer einen unklaren Satz noch einmal lesen. In einem Gespräch fällt jeder Fehler sofort auf.

Besonders kritisch sind:

• Eigennamen,
• Telefonnummern,
• Buchungs- und Kundennummern,
• Datumsangaben,
• Adressen,
• kurze Antworten wie „ja“, „nein“ oder „genau“.

Eine Transkription kann sprachlich plausibel und trotzdem für den konkreten Vorgang unbrauchbar sein. Zwischen den Referenznummern 100587 und 100578 besteht semantisch kaum ein Unterschied, operativ aber ein erheblicher.

2. Die Antwort muss schnell beginnen

Nach dem Ende einer Nutzeräußerung durchläuft das System mehrere Schritte:

1. Es muss erkennen, dass der Nutzer tatsächlich fertig gesprochen hat.
2. Das Audiosignal muss transkribiert werden.
3. Die Eingabe muss interpretiert werden.
4. Eine Antwort muss erzeugt werden.
5. Die Antwort muss in Sprache umgewandelt werden.

Nicht die Laufzeit eines einzelnen Modells, sondern die Summe dieser Schritte bestimmt die wahrgenommene Reaktionszeit.

3. Der Agent benötigt externes Wissen

Ein praktisch nutzbarer Agent soll nicht nur allgemeine Antworten erzeugen. Er muss beispielsweise:

• den Anrufer identifizieren,
• Kundendaten nachschlagen,
• Dokumente durchsuchen,
• Preise oder Verfügbarkeiten abrufen,
• strukturierte Einträge aktualisieren oder prüfen.

Diese Zugriffe benötigen Zeit. Werden sie direkt in den Antwortpfad eingebaut, erhöht sich die Latenz bei jedem betroffenen Turn.

Der Aufbau

Das KI-System besteht aus einer Sprachpipeline mit mehreren spezialisierten Komponenten sowie zusätzlichen Verarbeitungspfaden für Datenzugriff und Kontextanreicherung.

flowchart LR
    Mic["Browser<br/>Mikrofon"] --> VAD["Silero VAD<br/>Sprachaktivität"]
    VAD --> STT1["Voxtral-Small-24B<br/>kontextbewusst"]
    VAD --> STT2["Parakeet-TDT-0.6B<br/>kontextunabhängig"]
    STT1 --> EOT["EOT-LLM<br/>Turn-Ende und Merge"]
    STT2 --> EOT
    EOT --> Filter["Halluzinations-<br/>filter"]
    Filter --> LLM["Gemma-4-26B-A4B<br/>Hauptagent"]
    LLM --> TTS["TTS-Vorverarbeitung<br/>und VoxCPM2"]
    TTS --> Out["Browser<br/>Lautsprecher"]

    subgraph Sub["Asynchrone Sub-Agenten"]
        direction LR
        SA1["Identität"]
        SA2["Wissensdokumente"]
        SA3["Strukturierte Daten"]
    end

    LLM -. "asynchron" .-> Sub
    Sub -. "Systemkontext<br/>(nächster Turn)" .-> LLM

Von links nach rechts übernimmt das System folgende Aufgaben:

• Silero VAD erkennt Sprachaktivität und segmentiert das Audiosignal.
• Voxtral-Small-24B transkribiert die Äußerung unter Einbeziehung des bisherigen Gesprächsverlaufs.
• Parakeet-TDT-0.6B erstellt parallel eine kontextunabhängige Transkription.
• Ein End-of-Turn-Modell entscheidet, ob die Äußerung abgeschlossen ist, und führt die beiden Transkripte zusammen.
• Ein Halluzinationsfilter entfernt typische Artefakte der Spracherkennung.
• Gemma-4-26B-A4B erzeugt die Antwort des Agenten.
• Eine TTS-Vorverarbeitung normalisiert Zahlen, Datumsangaben und Kennungen.
• VoxCPM2 erzeugt das Audiosignal.

Der wesentliche Teil des KI-Systems liegt jedoch nicht allein in dieser Pipeline. Zusätzlich teilen wir die Verarbeitung in einen synchronen Hauptpfad und mehrere asynchrone Verarbeitungspfade auf.

Der synchrone Pfad

Der Hauptagent befindet sich im kritischen Pfad. Jede zusätzliche Millisekunde seiner Verarbeitung wirkt sich unmittelbar auf die Antwortzeit aus.

Deshalb soll dieser Pfad nur die Aufgaben übernehmen, die für die unmittelbare Fortführung des Gesprächs erforderlich sind. Er interpretiert die aktuelle Äußerung, berücksichtigt den bereits verfügbaren Kontext und formuliert eine Antwort.

Aufwendige Dokumentensuche, Datenbankabfragen oder Identitätsauflösung werden nach Möglichkeit nicht synchron ausgeführt.

Diese Einschränkung ist eine bewusste Architekturentscheidung. Wird jede Informationsbeschaffung in den synchronen Pfad gelegt, muss der Nutzer bei jeder Antwort auf die Summe aller beteiligten Komponenten warten.

Der synchrone Pfad ist daher nicht dafür optimiert, jede denkbare Frage sofort vollständig zu beantworten. Er ist zunächst dafür optimiert, das Gespräch stabil und ohne unnötige Pausen fortzuführen.

Asynchrone Sub-Agenten

Neben dem Hauptagenten arbeiten mehrere asynchrone Sub-Agenten. Sie werden durch jede Nutzeräußerung ausgelöst, blockieren aber die aktuelle Antwort nicht.

flowchart TB
    Turn["Nutzer-Turn · Transkript"] --> Tap["Sub-Agenten-Verteiler"]
    Tap ==> L1["Hauptagent<br/><b>synchron</b>"]
    Tap -. asynchron .-> L2["Sub-Agent · Identität<br/>Anrufer erkennen"]
    Tap -. asynchron .-> L3["Sub-Agent · Wissensdokumente<br/>Passagen abrufen"]
    Tap -. asynchron .-> L4["Sub-Agent · Strukturierte Daten<br/>Einträge nachschlagen"]
    L1 ==> Reply["Antwort → TTS"]
    L2 -.->|"Systemkontext"| Next(("nächster<br/>Turn"))
    L3 -.->|"Systemkontext"| Next
    L4 -.->|"Systemkontext"| Next

Jeder Sub-Agent hat einen klar abgegrenzten Zweck. Je nach Anwendungsfall können auch noch weitere Sub-Agenten aufgenommen werden. Da sie asynchron arbeiten, beeinflussen sie die Antwortzeit des Hauptagenten nicht.

Identität

Dieser Sub-Agent versucht, das Gegenüber anhand der im Gespräch genannten Informationen gegenüber einem CRM-System zu identifizieren. Dazu können beispielsweise Name, Telefonnummer oder Referenznummer verwendet werden.

Nach erfolgreicher Zuordnung werden die relevanten Stammdaten in den Kontext des Hauptagenten eingefügt.

Wissensdokumente

Dieser Sub-Agent durchsucht eine Dokumentensammlung und ermittelt Passagen, die zur aktuellen Nutzeräußerung passen.

Das Ergebnis besteht nicht unmittelbar aus einer Antwort an den Nutzer. Stattdessen werden die gefundenen Informationen als zusätzlicher Systemkontext für die folgenden Turns bereitgestellt.

Strukturierte Daten

Dieser Sub-Agent greift auf strukturierte Bestände zu, beispielsweise auf:

• Preise,
• Verfügbarkeiten,
• Kundeninformationen,
• Buchungen,
• Produkte,
• oder andere fachliche Datensätze.

Auch hier wird das Ergebnis zunächst dem Hauptagenten zur Verfügung gestellt, anstatt direkt ausgegeben zu werden.

Latenz hinter dem Gesprächsrhythmus

Das asynchrone Muster nutzt eine Eigenschaft natürlicher Gespräche: Während der Hauptagent antwortet, hört der Nutzer zu. Anschließend vergeht weitere Zeit, bis er seine nächste Äußerung formuliert.

Dieses Zeitfenster kann für die Informationsbeschaffung genutzt werden.

sequenceDiagram
    participant U as Nutzer
    participant P as Hauptagent
    participant A as Sub-Agenten

    U->>P: Turn N
    P-->>A: Sub-Agenten starten
    P->>U: unmittelbare Antwort
    Note over A: Datenzugriffe laufen,<br/>während der Hauptagent spricht
    A-->>P: zusätzlicher Systemkontext
    U->>P: Turn N+1
    Note over P: Antwort nutzt den<br/>angereicherten Kontext
    P->>U: kontextreichere Antwort

Die Informationsbeschaffung wird dadurch nicht schneller. Ein Teil ihrer Laufzeit liegt jedoch außerhalb des kritischen Antwortpfads.

Der Hauptagent kann beispielsweise zunächst bestätigen, dass er eine Anfrage verstanden hat. Während diese Antwort gesprochen wird, können im Hintergrund Identität und zugehörige Daten ermittelt werden. Beim nächsten Turn stehen diese Informationen bereits zur Verfügung.

Wo asynchrone Verarbeitung nicht ausreicht

Das Muster funktioniert nicht für jede Anfrage.

Fragt ein Nutzer unmittelbar nach einem Preis, einer Verfügbarkeit oder einem konkreten Kontostand, kann eine korrekte Antwort vom Ergebnis einer Datenabfrage abhängen. In diesem Fall lässt sich die Informationsbeschaffung nicht einfach auf den nächsten Turn verschieben.

Für wissenskritische Turns kann der Hauptagent dann auch explizit Sub-Agenten aufrufen und auf deren Antwort warten. Die Architektur entfernt Retrieval daher nicht grundsätzlich aus dem kritischen Pfad. Sie reduziert die Zahl der Fälle aber drastisch, in denen es dort zwingend stattfinden muss.

Doppelte Spracherkennung

Ein zentraler Fehlerbereich des KI-Systems liegt in der Verarbeitung von Namen, Zahlen und Kennungen durch die Spracherkennung.

Der naheliegende Ansatz besteht darin, der Spracherkennung den bisherigen Gesprächsverlauf als Kontext zu geben. Wenn bereits über eine bestimmte Person, Buchung oder Referenz gesprochen wurde, kann dieser Kontext die Transkription verbessern.

Voxtral-Small-24B erhält deshalb Informationen aus dem bisherigen Gespräch. Dadurch kann das Modell bekannte Begriffe und zuvor genannte Werte konsistenter transkribieren.

Der Kontext führt jedoch zu einem zweiten Fehlerprofil.

Ein Modell, das die vorherige Frage kennt, besitzt eine Erwartung darüber, welche Antwort folgen könnte. Bei undeutlichem oder sehr kurzem Audio kann es diese erwartete Antwort ergänzen, obwohl sie nicht tatsächlich gesprochen wurde.

Ein längeres „ähm“ nach der Frage nach einer Buchungsnummer kann unter ungünstigen Bedingungen zu einer plausibel wirkenden, aber erfundenen Nummer werden.

Für einen Voice-Agenten ist dies problematischer als ein gewöhnlicher Transkriptionsfehler. Das Ergebnis ist syntaktisch korrekt, passt zum Gespräch und kann deshalb von nachfolgenden Komponenten nur schwer als Fehler erkannt werden.

Ein zweites Modell als Gegenprobe

Aus diesem Grund hört Parakeet-TDT-0.6B parallel mit.

Dieses Modell erhält weder einen Prompt noch den bisherigen Gesprächsverlauf. Es soll möglichst wörtlich erfassen, was im aktuellen Audiosignal vorhanden ist.

Bei längeren Äußerungen bildet die kontextbewusste Transkription die Grundlage. Das zweite Modell wird verwendet, um den tatsächlichen Wortlaut abzusichern.

Bei sehr kurzen Äußerungen wie „ja“, „nein“ oder „genau“ wird lediglich die kontextunabhängige Transkription verwendet. In diesen Fällen enthält das Audiosignal nur wenig Information, während der Gesprächskontext eine starke Erwartung erzeugt. Genau dort ist die Gefahr kontextbedingter Ergänzungen besonders hoch.

Turn-Ende und Transkript-Merge

Ein weiteres Sprachmodell übernimmt zwei zusammenhängende Aufgaben.

Zunächst erweitert es die Turn Detection des VADs und entscheidet, ob der Nutzer seine Äußerung beendet hat. Eine kurze Pause bedeutet nicht zwingend das Ende eines Turns. Sie kann auch eine Denkpause innerhalb eines Satzes sein.

Wird die Äußerung als unvollständig bewertet, bleibt das Audio gepuffert. Das nächste Segment wird hinzugefügt, bevor eine erneute Transkription erfolgt. Dadurch erhält der Hauptagent nicht versehentlich einen halben Satz als vollständige Eingabe.

Im selben Aufruf werden anschließend die beiden Transkripte zusammengeführt. Ein akustisch unsicheres „Multer“ kann beispielsweise zu „Müller“ korrigiert werden, wenn dieser Name bereits im Gespräch etabliert wurde und das Audiosignal die Korrektur unterstützt.

Der Merge-Schritt darf allerdings nicht einfach das plausibelste Transkript erzeugen. Sonst würde das Halluzinationsproblem nur in eine spätere Komponente verschoben.

Besonders bei Zahlen und Identifikatoren sollte das System Informationen, die nur in der kontextbewussten Transkription vorkommen, nicht ungeprüft übernehmen.

Modelle und Hardware

In der lokalen Variante werden alle Komponenten des Aufbaus auf derselben Workstation betrieben (RTX 6000 Pro mit 96 GB VRAM).

Eine Pipeline aus seriellen Abhängigkeiten

Ein Nutzer-Turn besteht nicht aus einem einzigen Modellaufruf.

flowchart LR
    A["2× STT<br/>parallel"] --> B["Turn-Ende und Merge"]
    B --> C["Hauptagent"]
    C --> D["Sprachsynthese"]

Die beiden Spracherkenner können parallel ausgeführt werden. Die nachfolgenden Schritte sind jedoch weitgehend seriell:

• Das Merge-Modell benötigt die Transkripte.
• Der Hauptagent benötigt das zusammengeführte Transkript.
• Die Sprachsynthese benötigt zumindest den Anfang der erzeugten Antwort.

Eine Verzögerung in einer frühen Komponente wirkt sich damit auf alle nachfolgenden Schritte aus.

Was lokale Ausführung verändert

Werden die Komponenten auf mehrere externe Anbieter verteilt, entstehen zusätzliche Abhängigkeiten:

• Übertragung von Audiodaten,
• Netzwerk-Roundtrips,
• Warteschlangen beim Anbieter,
• ...

Gut implementierte Cloud-Systeme reduzieren einen Teil dieser Effekte durch persistente Verbindungen, Streaming und regionale Endpunkte. Dennoch bleibt die Laufzeit von mehreren externen Systemen abhängig.

Bei lokaler Ausführung werden Audiosignale, Transkripte und Kontext innerhalb derselben Maschine weitergegeben. Ein Teil der Netzwerkkommunikation entfällt.

Der mögliche Vorteil liegt nicht nur in einer niedrigeren mittleren Latenz. Ebenso relevant ist eine geringere Streuung der Laufzeiten.

Evaluation

Die folgenden Messungen untersuchen vor allem die Latenz der beiden Systemvarianten:

• Zeit vom Sprecherende bis zum ersten hörbaren Antwort-Audio,
• Laufzeiten der einzelnen Pipeline-Komponenten,
• STT- und TTS-Echtzeitfaktor,
• Time-to-first-token des Sprachmodells,
• Laufzeiten der asynchronen Sub-Agenten.

Zwei Konfigurationen

Wir haben zwei Varianten desselben Systems betrachtet:

• Cloud-Baseline: Voxtral-Small über AWS Bedrock, Parakeet über Together AI und Gemma-4-26B über Google Vertex.
• Lokale Variante: Voxtral-Small-24B und Gemma-4-26B-A4B über vLLM sowie Parakeet und VoxCPM2 als lokale HTTP-Dienste. Alle Modelle teilten sich eine NVIDIA RTX 6000 Pro.

Beobachtete Turn-Latenzen

Die folgende Tabelle enthält die direkt beobachteten Wanduhrzeiten der Turns (Median):

Einordnung gegenüber kommerziellen Plattformen

Für eine grobe Einordnung lassen sich die Werte öffentlichen Latenzmessungen gegenüberstellen, die Telnyx zusammengetragen hat (Voice AI agents compared on latency). Der Stack war in dem Test GPT-4.1, Deepgram Nova-3, ElevenLabs Flash.

Zu beachten ist, dass diese Tabelle auf einem anderen Modell-Stack (u.A. GPT-4.1, Deepgram Nova-3, and ElevenLabs Flash) basiert und 50-200ms für SIP Signal beinhaltet.

Was wir aus dem Aufbau lernen

Der Aufbau zeigt exemplarisch, dass die Qualität und Geschwindigkeit eines KI-Systems nicht von einem einzelnen Modell, sondern von der Abstimmung seiner Komponenten und Verarbeitungspfade abhängen.

Entscheidend ist die Aufteilung der Architektur:

• ein möglichst schlanker synchroner Pfad,
• asynchrone Sub-Agenten zur Kontextanreicherung,
• zwei Spracherkenner mit komplementären Fehlerprofilen,
• Verifikation und Zusammenführung der Transkripte,
• gemeinsame Laufzeitsteuerung auf begrenzter Hardware.

Die asynchronen Sub-Agenten nutzen den natürlichen Rhythmus des Gesprächs, um einen Teil der Informationsbeschaffung aus dem kritischen Antwortpfad zu verschieben. Die doppelte Spracherkennung reduziert dagegen das Risiko, dass der Gesprächskontext plausible, aber nicht gesprochene Inhalte erzeugt.

Die Qualität des KI-Systems entsteht aus dem Zusammenspiel von Modellwahl, Vorverarbeitung, Inferenzarchitektur, KV-Caching, Datenzugriff, Verifikation und Laufzeitsteuerung.

Das LLM ist eine wichtige Komponente. Das eigentliche Produkt ist jedoch das System, das um dieses Modell herum gebaut wird.