Sprachassistent bauen: In 1–2 Wochen zum lauffähigen Prototyp – Cloud oder Self-Hosted, aus der Erfahrung beider Wege

Wie man einen Voice Assistant baut

Die kurze Antwort

Um einen funktionierenden Voice Assistant zu bauen, entscheidest du zuerst, ob du den Cloud-Pfad (ElevenLabs + LLM-Anbieter deiner Wahl), den selbst gehosteten Pfad (Parakeet + LiveKit + Kokoro + Ollama) – oder etwas dazwischen brauchst. Die Antwort hängt von Datensensibilität, Kosten über 12-24 Monate, Compliance und dem CO₂-Footprint ab, den dein Projekt rechtfertigen kann. Beide Pfade nutzen dieselben drei Komponenten (Speech-to-Text, Sprachmodell, Text-to-Speech) und denselben Tool-Calling-Layer (über MCP oder das LiveKit Agent Framework). Dieser Layer lässt den Assistenten tatsächlich handeln – ein Telefonat buchen, eine Datenbank abfragen, einen Workflow auslösen – statt nur zurückzusprechen. Die Pfade unterscheiden sich darin, wo das Audio hingeht, was es im großen Maßstab kostet und wie natürlich die resultierende Stimme klingt. Viele Projekte starten mit dem Cloud-Pfad, um das Konzept in 1-2 Wochen zu validieren, und migrieren dann zu Self-Hosting, sobald der Use Case bewiesen ist.

Was das in der Praxis bedeutet

Ein Voice Assistant ist eine Kette aus drei Komponenten, die Daten in wenigen Sekunden untereinander weitergeben:

  1. Speech-to-Text (STT): Die nutzende Person spricht, die STT-Komponente transkribiert das Audio in Text. Das ist die Grundlage – wenn STT die Person falsch versteht, kann downstream nichts mehr gerettet werden. Die Qualität hängt von der Sprache, der Fähigkeit des Modells, den Akzent zu verarbeiten, Hintergrundgeräuschen und domänenspezifischem Vokabular ab.

  2. Sprachmodell (LLM): Der transkribierte Text geht an ein Sprachmodell, das die Absicht versteht und eine schriftliche Antwort generiert. Das ist dieselbe Technologie-Familie, die hinter ChatGPT oder Claude steht. Entscheidend: Das LLM ist es, was den Assistant zu einem Gesprächspartner und nicht zu einer Suchmaske macht – es kann Kontext über Turns hinweg halten, seine Antwort verfeinern und Tools aufrufen.

  3. Text-to-Speech (TTS): Die schriftliche Antwort geht an eine TTS-Komponente, die das gesprochene Audio erzeugt, das die Nutzer:innen hören. Die Qualität hier entscheidet, ob der Assistant glaubwürdig oder roboterhaft klingt. Für Projekte im Gesundheitswesen, in der Barrierefreiheit oder im öffentlichen Sektor beeinflusst die Sprachnatürlichkeit direkt, ob dem System vertraut wird.

Jede dieser Komponenten kann in der Cloud (du rufst eine API auf, das Audio verlässt deine Infrastruktur) oder selbst gehostet (die Komponente läuft auf deinem eigenen Server, das Audio verlässt nichts) laufen. Du kannst mischen: Cloud-STT + selbst gehostetes LLM, oder jede andere Kombination. Jede Cloud-Komponente ist ein API-Aufruf mit laufenden Kosten und externem Datenfluss. Selbst gehostete Komponenten erfordern Vorab-Aufwand, verursachen aber keine laufenden Kosten und die Audiodaten bleiben bei dir.

Streaming Audio ist die eine Zutat, die du nicht weglassen kannst. Eine zwei-seitige Gesprächsinteraktion braucht ein System, das Audio kontinuierlich streamt, statt vollständige Äußerungen hin und her zu reichen. Ohne Streaming fühlt sich das Gespräch wie eine langsame Turn-Taking-Übung an. Mit Streaming kann der Agent sich an den Gesprächsfluss der Nutzer:innen anpassen, Unterbrechungen, Pausen und Tempowechsel natürlich handhaben. Bau Streaming ab Tag eins ein, nicht als Nachrüstung.

Zentrale Bestandteile

STT – Speech to Text icon

STT – Speech to Text

  • Parakeet, Whisper, Moonshine für Self-Hosting
  • Cloud-STT für schnelles Prototyping
  • Qualität abhängig von der Fähigkeit des Modells, Sprache, Akzent und Fachvokabular zu verarbeiten

LLM – Sprachmodell icon

LLM – Sprachmodell

  • GPT-4 / GPT-4o via Microsoft AI Foundry für den Cloud-Pfad
  • Selbst gehostetes Llama, Mistral oder Gemma via Ollama für den souveränen Pfad
  • In Kombination mit einem Live-Streaming-Server ermöglicht es kontextbewusstes Turn-Taking

TTS – Text to Speech icon

TTS – Text to Speech

  • Cloud-TTS wie ElevenLabs für die heute natürlichste Sprachqualität
  • Selbst gehostetes Kokoro, Piper oder Coqui für Souveränität (schließt die Qualitätslücke)
  • Sprachqualität beeinflusst direkt das Vertrauen in vielen Domänen, besonders im Gesundheitswesen, in der Barrierefreiheit und im öffentlichen Sektor

Ergebnisse

Cloud-Pfad: 1-2 Wochen zum MVP icon

Cloud-Pfad: 1-2 Wochen zum MVP

API-Keys, Widget einbetten, lauffähigen Prototyp schnell ausliefern – ideal zur Konzept-Validierung

Self-Hosted: volle Souveränität icon

Self-Hosted: volle Souveränität

alles läuft auf deiner Infrastruktur, Audio verlässt nichts, keine Kosten pro Gespräch

Hybrid-Pfad: validieren dann migrieren icon

Hybrid-Pfad: validieren dann migrieren

die meisten Projekte starten mit Cloud, beweisen den Use Case, migrieren dann zu Self-Hosting bevor sie skalieren

Echtzeit-Konversation

Turn-Taking, Umgang mit Unterbrechungen und natürliche Pausen sind Architekturentscheidungen, nicht Features, die man später draufschraubt

Tool Calling und Aktion

ein Voice Assistant, der tatsächlich handeln kann – Termin buchen, Datenbank abfragen, Workflow auslösen – via MCP oder dem LiveKit Agent Framework

Lust auf ein Vorgespräch? Buche ein Telefonat: Kostenfrei, auf den Punkt.

So funktioniert es

1. Cloud vs. Self-Hosted entscheiden

  • Datensensibilität, erwarteten Maßstab und Compliance kartieren * Kosten über 12-24 Monate modellieren, nicht nur den ersten Monat * Entscheiden, ob Echtzeit-Unterbrechung essentiell ist oder ob Frage-Antwort reicht

2. Den lauffähigen Agent bauen

  • Cloud-Pfad: STT/LLM/TTS-Anbieter wählen, Widget einbetten, in 1-2 Wochen ausliefern * Self-Hosted-Pfad: n8n + Whisper + Ollama + Piper auf Docker deployen, mit deiner Website integrieren * In einer echten akustischen Umgebung mit echten Nutzer:innen testen, nicht in einem stillen Labor

3. Betreiben und skalieren

  • Genauigkeit, Latenz und Gesprächsqualität überwachen * Stimmen, Prompts und Tool Calling gegen echte Gespräche tunen * Von Cloud zu Self-Hosting migrieren, sobald der Use Case validiert ist und der Maßstab beißt

Warum N3XTCODER

Wir bringen ein Jahrzehnt Impact-Tech-Erfahrung und über 160 KI-Projekte seit 2019 mit. Über unseren kostenlosen Kurs AI for Impact haben über 100.000 Menschen gelernt, KI für das Gemeinwohl einzusetzen. Wir machen keine Inspirationstage. Wir machen Scoping-Sessions und Build-Engagements, die in Produktion gehen – so wie wir KI für die folgenden Organisationen ausgeliefert haben:

  • Mother Earth AI – selbst gehosteter Voice Agent für Klimakommunikation, Gewinner des K3-Preises 2023, im Einsatz in Museen und auf "Mutter Erde Telefon"-Raspberry-Pi-Installationen
  • Ein führendes Mitgliedernetzwerk – produktiver RAG-Chatbot, der 1.000+ HumHub-Mitglieder bedient, auf n8n + Qdrant + GPT-4 via Microsoft EU, in vier Sprints geliefert
  • GDV (Gesamtverband der Deutschen Versicherungswirtschaft) – KI-Wissensassistent über zehntausende Policy-Dokumente für 400+ Mitgliedsunternehmen, auf Azure AI Search + GPT-4o via Microsoft AI Foundry. Recherchezeit halbiert, Schatten-KI verhindert, Mitarbeitendenzufriedenheit gesteigert
  • Ein führender deutscher Verband – KI-Mitgliederplattform ("Verbands-GPT") mit Chat-basierter Discovery und klassischen Kategoriefiltern, auf Microsoft AI Foundry + pgvector
  • Eine führende Spendenplattform – KI-E-Mail-Agent mit verpflichtender menschlicher Prüfung im Pilot, auf N8N und Azure OpenAI
  • Standard-Stack: n8n in Berlin, Qdrant oder pgvector für die Vektorsuche, Azure OpenAI / GPT-4o via Microsoft AI Foundry, plus Open-Source-EU-Alternativen wie Mistral, Milvus und selbst gehostete Ollama / Whisper / Piper für souveräne Deployments.

Ehrliche Grenzen

Cloud-TTS schlägt Open-Source-TTS in der Natürlichkeit immer noch. ElevenLabs und ähnliche kommerzielle Dienste produzieren heute die lebensechtesten Stimmen. Open-Source-Tools wie Piper und Coqui holen schnell auf, aber wenn Sprachqualität entscheidend ist, ergibt der Cloud-Pfad mehr Sinn.

Open-Source-Voice-KI in weniger verbreiteten Sprachen ist uneinheitlich. Deutsch, Englisch und Französisch sind sowohl von Whisper als auch von Piper gut unterstützt. Kleinere europäische Sprachen und Dialekte sind uneinheitlicher. Mit deiner echten Zielgruppe testen, bevor du dich festlegst.

Voice-Modelle fressen Energie. Voice-Pipelines sind schwerer als Text-Pipelines. Für Projekte mit einer echten CO₂-Bedingung – wie Mother Earth AI – prägt das die Architekturentscheidung von Tag eins.

Echtzeit-Unterbrechung erfordert WebSocket-artige Architektur. Frage-Antwort-Systeme sind einfacher zu bauen, fühlen sich aber träge an. Wenn dein Use Case natürliches Turn-Taking braucht, designe es von Anfang an.

Häufige Fragen

Bau deinen Voice Assistant mit N3XTCODER

Erzähl uns vom Use Case, der Sprache, der Zielgruppe und den Bedingungen. Wir antworten mit einer vorgeschlagenen Architektur und einem Termin, meist innerhalb eines Werktags.

Simon Stegemann
Co-Founder and CEO

Verwandte Services