Natives STT vs. Deepgram: Welche Sprach-Engine wählen?

Als ich TAMSIV startete, lief die gesamte Spracherkennung über Deepgram. Ein exzellenter Cloud-Dienst, präzise, schnell. Das Deutsche? Tadellos. Regionale Akzente? Werden verarbeitet. Automatische Interpunktion? Perfekt. Es gab nur ein Detail: Jede transkribierte Audiosekunde hatte einen Preis. Und wenn deine App vollständig auf Sprache basiert, steigt dieser Preis schnell.

Ich musste also eine strategische Entscheidung treffen: Entweder behalte ich Deepgram für alle bei und gebe die Kosten an die Abonnements weiter, oder ich finde eine kostenlose Alternative für den Free-Plan und reserviere Deepgram für zahlende Nutzer. Ich habe mich für die zweite Option entschieden. Hier ist, wie ich eine duale Architektur aus nativem STT + Deepgram aufgebaut habe und was ich beim Vergleich der beiden unter realen Bedingungen gelernt habe.

Wichtige Erkenntnisse:
- Natives STT (Google/Apple) ist kostenlos, lokal und ausreichend für kurze Diktate
- Deepgram ist weiterhin überlegen in der Genauigkeit, besonders bei Lärm und Akzenten
- Eine duale Architektur ermöglicht einen tragfähigen kostenlosen Plan, ohne die Premium-Qualität zu opfern
- Die Frontend-Abstraktion sorgt dafür, dass die Komponenten nicht wissen, welche Engine läuft
- Die Wahl zwischen nativem STT und Cloud ist vom Admin ohne App-Update konfigurierbar

Warum ist Spracherkennung in einer Produktivitäts-App so zentral?

TAMSIV ist keine klassische Produktivitäts-App, in der du Listen tippst. Es ist eine App, in der du sprichst. Du diktierst eine Aufgabe, ein Memo, ein Ereignis. Der Sprachassistent versteht, was du sagst, erstellt das Element und antwortet dir. Alles läuft über Sprache.

Das bedeutet, dass die Qualität der Transkription die Erfahrung direkt beeinflusst. Wenn das STT "Brot kaufen" falsch versteht und "Bad kaufen" transkribiert, verliert der Benutzer das Vertrauen. Wenn die Interpunktion fehlt, wird das Memo zu einem unleserlichen Textblock. STT ist kein Gadget – es ist die Grundlage der gesamten Benutzererfahrung.

Deshalb habe ich viel Zeit damit verbracht, die gesamte Sprachpipeline sorgfältig aufzubauen. STT ist der erste Schritt in der Kette: Audio → STT → Text → LLM → Function Calling → TTS → Audio. Wenn der erste Schritt fehlschlägt, bricht alles andere zusammen.

Wie funktioniert natives STT auf Android und iOS?

Jedes moderne Smartphone verfügt über eine Spracherkennungs-Engine. Auf Android ist es der SpeechRecognizer von Google. Auf iOS ist es das Speech framework von Apple. Diese Engines sind in das Betriebssystem integriert und funktionieren lokal – keine Daten verlassen das Telefon.

Die Vorteile sind klar:

• Kostenlos: Keine Kosten pro Sekunde, keine Anfragelimits, keine Überraschungsrechnung.
• Lokal: Sprachdaten bleiben auf dem Gerät. Perfekt für den Datenschutz.
• Schnell: Keine Netzwerklatenz. Die Transkription beginnt nahezu sofort.
• Offline: Funktioniert auch ohne Internetverbindung (mit heruntergeladenen Modellen).

Aber es gibt Grenzen. Natives STT ist nicht für professionelle Anwendungsfälle konzipiert. Die Interpunktion fehlt oft oder ist ungenau. Die Genauigkeit nimmt in einer lauten Umgebung erheblich ab. Und für Deutsch mit Akzenten (z.B. Schweizerdeutsch, Österreichisch) variieren die Ergebnisse stark.

Was bietet Deepgram zusätzlich?

Deepgram ist ein spezialisierter Cloud-STT-Dienst. Sein Nova-2-Modell wurde auf Milliarden Stunden Audio trainiert und bietet eine bemerkenswerte Genauigkeit. Hier ist, was es vom nativen STT unterscheidet:

• Automatische Interpunktion: Sätze werden korrekt interpunktiert, was Memos sofort lesbar macht.
• VAD (Voice Activity Detection): Deepgram erkennt, wann du sprichst und wann du eine Pause machst. Keine Transkription von Umgebungsgeräuschen.
• Streaming WebSocket: Audio wird in Echtzeit über WebSocket, Wort für Wort, transkribiert. Der Benutzer sieht sein Diktat nach und nach erscheinen.
• Native Mehrsprachigkeit: Deutsch, auch mit Akzenten, wird gut unterstützt.
• Intelligentes Endpointing: Deepgram weiß, wann du aufgehört hast zu sprechen, was die LLM-Verarbeitung zum richtigen Zeitpunkt auslöst.

Die Kosten? Etwa 0,0043 $ pro Minute Audio-Streaming. Das scheint wenig, aber für eine Sprach-App, bei der jede Interaktion 10 bis 30 Sekunden dauert, summiert sich das bei Hunderten aktiven Benutzern schnell.

Wie habe ich die duale Architektur in TAMSIV konzipiert?

Das Ziel war klar: zwei austauschbare STT-Engines anbieten, ohne dass der Code der Benutzeroberfläche wissen muss, welche läuft. Das Muster ist das der Abstraktion – eine gemeinsame Schnittstelle, zwei Implementierungen.

Auf der Frontend-Seite (React Native) stelle ich eine einheitliche Schnittstelle bereit:

// Gemeinsame Schnittstelle
interface STTEngine {
  start(): void;
  stop(): void;
  onResult(callback: (text: string) => void): void;
  onError(callback: (error: Error) => void): void;
}

// Zwei Implementierungen
class NativeSTTEngine implements STTEngine { ... }
class DeepgramSTTEngine implements STTEngine { ... }

Die Wahl der Engine wird durch zwei Faktoren bestimmt:

1. Der Plan des Benutzers: Free → nativ, Pro/Team → Deepgram (konfigurierbar).
2. Die Admin-Konfiguration: Über die Tabelle app_config in Supabase kann ich eine Engine für alle Benutzer erzwingen. Nützlich für A/B-Tests oder bei Problemen mit einem Anbieter.

Die UI-Komponenten (das Diktiergerät, der Konversationsbildschirm) wissen nicht, welche Engine läuft. Sie rufen start(), stop() auf und erhalten Text. Dies ist das Prinzip der einzelnen Verantwortung, angewendet auf die Sprachpipeline.

Was sind die Ergebnisse des Vergleichs unter realen Bedingungen?

Ich habe beide Engines in drei konkreten Szenarien getestet, mit dem gleichen diktierten Inhalt auf Deutsch:

Szenario	Natives STT	Deepgram
Ruhige Umgebung	~92%	~98%
Hintergrundgeräusche (Café, Straße)	~75%	~94%
Deutsch mit Akzenten	~80%	~95%
Schnelles Diktat (>150 Wörter/Min)	~70%	~93%

Das Urteil ist eindeutig: Deepgram ist in allen Szenarien objektiv überlegen. Der Unterschied wird besonders in lauten Umgebungen und bei Akzenten deutlich. Die automatische Interpunktion von Deepgram ist ein enormer Vorteil für Sprachmemos – ein Memo ohne Interpunktion ist ein mühsam zu lesender Textblock.

Aber – und das ist die wichtige Nuance – für das Diktieren einer kurzen Aufgabe ("Morgen früh Milch kaufen") ist natives STT ausreichend. In einer ruhigen Umgebung funktionieren 92% Genauigkeit bei einem Satz von 5 Wörtern. Der Benutzer kann den Text nach der Spracherstellung immer noch bearbeiten.

Wie dient diese Architektur dem Wirtschaftsmodell?

Die duale Architektur ist nicht nur eine technische Meisterleistung – sie ist eine Geschäftsentscheidung. Sie ermöglicht drei Dinge:

1. Ein tragfähiger Free-Plan: Der kostenlose Benutzer kann Sprache nutzen, ohne dass es mich etwas an STT kostet. Die Kosten sind null, da die Verarbeitung lokal erfolgt.
2. Ein Argument für Premium: "Möchtest du eine bessere Genauigkeit, besonders bei Lärm? Wechsle zu Pro." Der Benutzer, der das native STT ausprobiert hat und Besseres möchte, hat einen konkreten Grund zu zahlen. Das ist dasselbe Prinzip, das ich bei den RevenueCat-Abonnements anwende.
3. Ein Sicherheits-Fallback: Wenn Deepgram ausfällt (was vorkommt), kann ich alle Benutzer auf das native STT umstellen, indem ich einen Wert in app_config ändere. Kein App-Update erforderlich. Das ist dasselbe Fallback-Muster, das ich für das LLM über OpenRouter verwende.

Was sind die technischen Schwierigkeiten bei der Integration von nativem STT in React Native?

Die Integration von nativem STT in React Native ist nicht trivial. Hier sind die Probleme, auf die ich gestoßen bin:

• Unterschiedliche Android/iOS APIs: Der Android SpeechRecognizer und das iOS Speech Framework haben völlig unterschiedliche APIs. Die von mir verwendete React Native Bibliothek abstrahiert einen Teil dieser Unterschiede, aber nicht alles.
• Lifecycle-Management: Auf Android muss der SpeechRecognizer korrekt bereinigt werden, wenn die App in den Hintergrund wechselt. Andernfalls hört er weiter zu und verbraucht Batterie. Ich musste Listener für den AppState hinzufügen, um dies zu verwalten.
• Sicherheits-Timeout: Das native STT kann unbegrenzt im Zustand "listening" stecken bleiben. Ich habe einen Timeout von 30 Sekunden hinzugefügt (dasselbe Muster wie im AudioPlayerService) mit automatischer Bereinigung.
• Kein zuverlässiges Streaming: Im Gegensatz zu Deepgram, das Wörter nach und nach sendet, liefert das native STT Teilergebnisse, die widersprüchlich sein können. Ich musste ein Debounce implementieren, um das "Flackern" des angezeigten Textes zu vermeiden.

Wie konfiguriert man die STT-Auswahl remote ohne Bereitstellung?

Einer der Vorteile dieser Architektur ist die Remote-Konfigurierbarkeit. In Supabase habe ich eine Tabelle app_config, die globale Anwendungsparameter speichert. Die Wahl der STT-Engine ist einer davon.

Wenn die App startet, liest sie die Konfiguration aus Supabase (oder aus dem Cache, dank des ContentCacheService). Wenn die Konfiguration "nativ für alle" besagt, verwenden sogar Pro-Benutzer das native STT. Dies ist in mehreren Fällen nützlich:

• Deepgram-Ausfall: Sofortiges Umschalten ohne Update.
• A/B-Tests: Vergleich der Retentionsmetriken zwischen den beiden Engines bei einer Benutzergruppe.
• Temporäre Kostenreduzierung: Wenn das Cloud-Budget in einem bestimmten Monat knapp ist, kann ich Deepgram vorübergehend deaktivieren.

Das Admin-Dashboard zeigt die Nutzungsmetriken pro STT-Engine an, was fundierte Entscheidungen ermöglicht.

Wie sieht die Zukunft des STT in mobilen Apps aus?

Die Landschaft des STT entwickelt sich schnell. Whisper von OpenAI hat hochwertige Open-Source-STT-Modelle demokratisiert. Projekte wie whisper.cpp ermöglichen es, Whisper direkt auf mobilen Geräten auszuführen, mit einer Qualität, die Deepgram nahekommt und null Cloud-Kosten verursacht.

Ich verfolge diese Entwicklung genau. An dem Tag, an dem ein Whisper-Modell auf einem Standard-Smartphone mit deutscher Unterstützung in Echtzeit gut genug läuft, wird Cloud-STT für alle optional. In der Zwischenzeit ist die von mir implementierte duale Architektur perfekt positioniert, um eine dritte Engine zu integrieren, ohne die UI-Komponenten zu berühren.

FAQ

Funktioniert natives STT offline?

Ja, vorausgesetzt, das Sprachmodell ist auf dem Gerät heruntergeladen. Auf Android bietet Google den Download von Sprachmodellen in den Einstellungen an. Auf iOS sind die Modelle in der Regel bereits vorhanden. Die Offline-Qualität ist etwas geringer als die Online-Version.

Ist Deepgram der beste Cloud-STT-Dienst?

Deepgram Nova-2 gehört zu den besten in Bezug auf Preis-Leistungs-Verhältnis. Google Cloud Speech-to-Text und AWS Transcribe sind ernstzunehmende Alternativen. Ich habe Deepgram wegen seiner nativen WebSocket-API und seiner sekundengenauen Abrechnung (nicht minutengenau) gewählt.

Kann der Benutzer seine STT-Engine selbst wählen?

Derzeit ist die Wahl an den Plan gebunden (Free = nativ, Pro = Deepgram). Langfristig plane ich, einen Schalter in den Einstellungen hinzuzufügen, damit Pro-Benutzer das native STT wählen können, wenn sie die lokale Vertraulichkeit bevorzugen.

Wie werden andere Sprachen als Deutsch verwaltet?

TAMSIV unterstützt 6 Sprachen. Sowohl natives STT als auch Deepgram unterstützen diese Sprachen. Die Spracherkennung basiert auf den App-Einstellungen (keine automatische Erkennung), was Verwechslungen zwischen ähnlichen Sprachen vermeidet.

Verbraucht natives STT viel Batterie?

Weniger als Cloud-STT, da keine Netzwerkübertragung stattfindet. Aber die lokale Verarbeitung nutzt den Prozessor des Telefons. Bei einem kurzen Diktat (30 Sekunden) ist der Einfluss vernachlässigbar. Bei einem langen Diktat (5+ Minuten) kann natives STT mehr Batterie verbrauchen als die Cloud, da der Prozessor kontinuierlich läuft.