Lokale Spracherkennung in .NET mit Whisper.net: Erste Schritte

Diktierfunktionen sind in Consumer-Apps längst Standard, aber sobald ich mit Kunden über die Integration in eigene .NET-Anwendungen spreche, taucht fast immer dieselbe Frage auf: Muss das zwingend über eine Cloud-API laufen? Für viele Anwendungsfälle – interne Notizen, Kundengespräche, Diktate mit personenbezogenen Daten – lautet die Antwort: nein. Mit Whisper.net, einem .NET-Wrapper um OpenAIs Whisper-Modell (genauer: um dessen C++-Portierung whisper.cpp), läuft die komplette Spracherkennung lokal auf dem Gerät. Keine Audiodaten verlassen den Rechner, kein API-Schlüssel, keine laufenden Kosten pro Minute.

Für die Praxis direkt vorweg: Es gibt kein pauschal bestes Whisper-Modell, sondern eine Empfehlung je nach Hardware. Auf x64-Geräten mit Vulkan- oder CUDA-Beschleunigung liefert turbo-q8_0 das beste Verhältnis aus Tempo und Genauigkeit. Ohne Grafikbeschleunigung bleiben small-q8_0 oder, auf schwacher CPU, base-q8_0/tiny-q8_0 die praxistauglichen Alternativen.

🔐 Datenschutz ernst nehmen: Lokale Verarbeitung ist ein wichtiger Baustein, ersetzt aber kein Gesamtkonzept – welche Risiken KI-Systeme grundsätzlich mitbringen und wie Sie sie einordnen, beschreibe ich in meinem Überblick zu KI-Sicherheit.

Die Zahlen in diesem Artikel stammen nicht aus einem Benchmark-Paper, sondern aus eigenen Messungen. Im Zuge einer Eigenentwicklung – einem lokalen Diktier-Werkzeug – habe ich 17 Whisper-Fassungen aus sechs Modellfamilien gegen einen selbst erstellten Referenzkorpus getestet: 61 vorgelesene Aufnahmen mit bekanntem Wortlaut, gemessen auf einem ThinkPad mit integrierter AMD-Grafik. Vorgelesenes ist nicht Diktiertes – Füllwörter, Versprecher und Denkpausen fehlen, und sauber phrasierter Lesetext ist für jedes Spracherkennungsmodell der leichtere Fall. Die absoluten Fehlerraten weiter unten fallen dadurch günstiger aus, als Sie sie bei freiem Diktat erwarten dürfen; für den Vergleich der Fassungen untereinander ist das unschädlich, weil alle gleichermaßen profitieren – und genau darum geht es hier. Dieser Artikel ist kein Vergleichstest für „das beste Modell“, sondern das Entscheidungs-Framework, das aus diesen Messungen entstanden ist – plus das nötige Setup, um selbst loszulegen.

Setup: Whisper.net in einem .NET-Projekt einrichten

Whisper.net ist ein schlanker .NET-Wrapper um whisper.cpp, die C/C++-Portierung von OpenAIs Whisper-Modell. Sie brauchen mindestens zwei NuGet-Pakete: das Hauptpaket Whisper.net und ein Runtime-Paket, das die passende native Inferenz-Engine für Ihre Zielplattform mitbringt.

• CPU, jede Plattform: Whisper.net.Runtime
• AMD-/Intel-GPU über Vulkan: Whisper.net.Runtime.Vulkan (nur x64 – für Windows on ARM gibt es kein Vulkan-Paket)
• NVIDIA-GPU, CUDA 13: Whisper.net.Runtime.Cuda
• NVIDIA-GPU, CUDA 12: Whisper.net.Runtime.Cuda12

dotnet add package Whisper.net
dotnet add package Whisper.net.Runtime.Vulkan
# Mehrere Runtime-Pakete sind erlaubt und werden zur Laufzeit automatisch gewählt

Sie müssen sich nicht auf ein Paket festlegen: Whisper.net erlaubt mehrere Runtime-Pakete im selben Projekt und wählt beim Start automatisch das beste verfügbare – in der Reihenfolge CUDA, CUDA 12, Vulkan, CoreML, OpenVINO, CPU. Wer auf gemischte Hardware ausliefert, nimmt deshalb Whisper.net.Runtime als Rückfallebene zusätzlich zum GPU-Paket.

Modell herunterladen und transkribieren – hier am Beispiel der Turbo-Fassung, 8-Bit-quantisiert:

using Whisper.net;
using Whisper.net.Ggml;

// Modell einmalig herunterladen, danach lokal wiederverwenden
var modelFileName = "ggml-large-v3-turbo-q8_0.bin";
if (!File.Exists(modelFileName))
{
    using var modelStream = await WhisperGgmlDownloader.Default
        .GetGgmlModelAsync(GgmlType.LargeV3Turbo, QuantizationType.Q8_0);
    using var fileWriter = File.OpenWrite(modelFileName);
    await modelStream.CopyToAsync(fileWriter);
}

using var whisperFactory = WhisperFactory.FromPath(modelFileName);

using var processor = whisperFactory.CreateBuilder()
    .WithLanguage("de")
    .Build();

using var audioStream = File.OpenRead("diktat.wav"); // 16 kHz WAV

await foreach (var segment in processor.ProcessAsync(audioStream))
{
    Console.WriteLine($"{segment.Start} -> {segment.End}: {segment.Text}");
}

Drei Praxishinweise, die mir in eigenen Projekten Zeit gespart hätten:

• Audioformat: Whisper.net erwartet eine WAV-Datei mit 16 kHz Abtastrate – bei jeder anderen Rate fliegt eine Ausnahme. Mehrkanaliges Audio ist unkritisch, Whisper.net mittelt die Kanäle selbst; andere Container wie MP3 oder M4A müssen Sie vorher konvertieren, etwa mit NAudio.
• Kaltstart: Die allererste Inferenz nach dem Prozessstart kostet unter Vulkan in meinen Messungen rund 3 Sekunden zusätzlich gegenüber späteren Aufrufen. Wärmen Sie das Modell deshalb beim Programmstart mit einem kurzen Stille-Sample vor, statt Nutzer beim ersten echten Diktat warten zu lassen.
• Streaming: ProcessAsync liefert die Segmente als IAsyncEnumerable – bei längeren Aufnahmen können Sie den Text also schon während der Verarbeitung anzeigen, statt auf das vollständige Ergebnis zu warten.

🚀 Frisches .NET-Fundament: Wer ohnehin aktualisiert: Whisper.net läuft auf jeder aktuellen .NET-Version, und ein frisches Fundament erspart Ihnen Kompatibilitätsfragen beim Einbinden nativer Runtime-Pakete – mehr dazu in meinem Überblick zu den Top-Features von .NET 10.

Geprüft mit Whisper.net 1.9.1 auf .NET 10, Stand September 2026. Die Zuordnung der CUDA-Pakete ist versionsabhängig – Whisper.net.Runtime.Cuda setzt CUDA Toolkit 13.0.1 oder höher voraus, für ältere Treiber gibt es Whisper.net.Runtime.Cuda12 (CUDA Toolkit 12.4.1 oder höher). Für alle Runtime-Pakete gelten laut Dokumentation dieselben Grundvoraussetzungen:

• x86/x64: CPU mit AVX, AVX2, FMA, F16C (sonst Whisper.net.Runtime.NoAvx)
• ARM64: keine CPU-Anforderung
• Windows: mindestens Windows 11 / Windows Server 2022, Visual C++ Redistributable (VS 2022)
• Linux: libstdc++6, glibc 2.31 oder neuer

Der Modellkatalog: sechs Familien, siebzehn Fassungen

Whisper gibt es nicht als ein Modell, sondern als Familie von Modellgrößen: tiny, base, small, medium, large-v3 und die schnellere Variante turbo. Jede Familie liegt zusätzlich in mehreren Quantisierungsstufen vor (dazu gleich mehr) – macht die 17 Fassungen, die ich im Zuge meiner Eigenentwicklung in den Katalog aufgenommen habe. Whisper.net kann darüber hinaus weitere Fassungen laden, etwa englischsprachige Sondermodelle oder ältere large-Versionen; alle Modelle liegen im GGML-Format vor, das whisper.cpp verwendet.

Gemessen habe ich alle 17 gegen den erwähnten Referenzkorpus, ausgewertet über zwei Kennzahlen: die Wortfehlerrate (Word Error Rate, WER) – der Anteil falsch erkannter Wörter gegenüber der bekannten Vorlage – und die Begriffstreue, den Anteil korrekt erkannter Fach- und Eigennamen aus einer vorab festgelegten Liste (Produktnamen, Fachbegriffe aus meinem eigenen Arbeitsumfeld). Für den direkten Vergleich zweier Fassungen nutze ich zusätzlich einen paarweisen Vergleich: Bei jeder der 61 Aufnahmen vergleiche ich, welche Fassung weniger Wortfehler macht. Aufnahmen, bei denen beide gleich viele Fehler haben, fallen aus der Wertung – sie sagen nichts darüber, welche Fassung besser ist. Der p-Wert gibt dabei an, wie wahrscheinlich ein solches Übergewicht durch reinen Zufall entstanden wäre – ab p < 0,05 gilt der Unterschied als statistisch abgesichert:

Familie	gelistete Fassung	WER	Begriffstreue	Größe
large-v3	q5_0	5,3 %	89,8 %	1031 MB
turbo	q8_0	5,9 %	83,0 %	834 MB
medium	q5_0	7,3 %	81,8 %	514 MB
small	q8_0	13,1 %	67,0 %	252 MB
base	q5_1	23,2 %	53,4 %	57 MB
tiny	q8_0	38,1 %	35,2 %	42 MB

Angegeben ist jeweils die Fassung, die ich innerhalb der Familie als Referenz führe. Das ist nicht zwingend der rechnerisch beste Einzelwert und keine Vorwegnahme der Geräte-Empfehlung weiter unten (dazu die Entscheidungstabelle). Bei turbo etwa wäre q5_0 mit 5,8 % WER bei 547 MB minimal besser und kleiner als das hier gelistete q8_0 (5,9 % / 834 MB). Der Unterschied ist statistisch nicht unterscheidbar (2:2 bei 57 gleich genauen Aufnahmen). Sobald ein Fachwörterbuch aktiv ist, dreht sich das Bild aber zugunsten von q8 (siehe unten). Auch die unquantisierten Fassungen bringen hier keinen belastbaren Vorteil – dazu mehr im nächsten Abschnitt zur Quantisierung.

Interessanter als die einzelne Fehlerrate ist das Verhältnis zwischen den Sprüngen. Von tiny zu small sinkt die Fehlerrate um rund 25 Prozentpunkte – der mit Abstand größte Gewinn im gesamten Feld, für vergleichsweise wenig zusätzliche Rechenzeit. Von small zu turbo halbiert sich die Fehlerrate noch einmal, für rund zwei Sekunden mehr Verarbeitungszeit. Darüber, bei large-v3, wird es teuer: rund 47 % mehr Zeit für gerade einmal 0,6 Prozentpunkte WER. (Alle Zeitangaben stammen aus einem sequenziellen Durchlauf auf einem Gerät und sind Größenordnungen, keine Laborwerte.) Der Vorteil von large-v3 liegt praktisch ausschließlich bei Fachbegriffen: 89,8 % gegenüber 83,0 % Begriffstreue bei turbo.

Eine Fassung sticht dabei negativ heraus: medium. In meinem Vergleich unterliegt medium-q8_0 dem gleich großen turbo-q8_0 (785 gegen 834 MB) in 22 von 29 unterschiedlichen Fällen – statistisch signifikant (p = 0,008); auch die kleinere, hier gelistete q5_0-Fassung verliert (21 von 29, p = 0,02). Ich lösche keine Modelle aus dem Katalog, aber einen Anwendungsfall, den keine andere Fassung besser abdeckt, habe ich für medium nicht gefunden. Bleibt im Sortiment, ohne Empfehlung.

Eine Einschränkung gilt unabhängig vom gewählten Modell: Sehr kurze Diktate – zwei bis drei Wörter – sind selbst mit den besten Fassungen die schwächste Stelle. In meinem Korpus lag die Fehlerrate bei kurzen Passagen bei 27–31 %, selbst bei large-v3 und turbo, während lange Diktate (34–45 Sekunden) auf 2,3–3,2 % fielen. Whisper braucht Kontext, um Wörter zu disambiguieren – aus „Termin absagen“ wurde in einem Fall „Absurd.“. Wenn Ihre Anwendung eher auf kurze Sprachbefehle als auf freies Diktat setzt, lohnt sich der Schritt über turbo hinaus nicht mehr – ab dieser Größe bringt ein größeres Modell dort nichts. Ein Fachwörterbuch per Prompt-Priming hilft dort ebenfalls kaum: Bei den 5-Bit-Fassungen hat ein 32-Begriffe-Prompt die kurzen Passagen in meinen Messungen sogar verschlechtert (turbo-q5 von 27 auf 38 % Fehlerrate); bei den hier empfohlenen 8-Bit-Fassungen blieb es neutral bis leicht besser (mehr dazu im nächsten Abschnitt). Tragfähiger ist, die Anwendung auf einen festen Satz erlaubter Befehle einzugrenzen und das Erkannte dagegen abzugleichen.

Quantisierung erklärt: Was q5 und q8 wirklich bedeuten

Jede Modellfamilie liegt in mehreren Quantisierungsstufen vor, erkennbar am Suffix im Dateinamen wie -q5_0 oder -q8_0. Quantisierung reduziert die Bit-Breite der Modellgewichte, üblicherweise von 16- oder 32-Bit-Gleitkommazahlen auf 8 Bit (q8) oder 5 Bit (q5). Das Modell wird dadurch vor allem kleiner. Ob die Inferenz dadurch auch spürbar schneller wird, lässt sich aus meinen Messungen nicht sauber ablesen – die Fassungen einer Familie liefen dabei nacheinander auf demselben Gerät, das sich währenddessen erwärmte, was Zeitvergleiche innerhalb einer Familie verzerrt. Verlassen können Sie sich auf den Größenvorteil: Das ist der Hebel, der bei der Quantisierung wirklich zählt.

Die verbreitete Annahme lautet: Aggressivere Quantisierung kostet Genauigkeit, q5 ist also ein Kompromiss gegenüber q8. In meiner Messung stimmt das nicht. Im paarweisen Vergleich über alle 61 Aufnahmen ist in keiner der Familien, die ich in beiden Stufen gemessen habe, q8 nachweisbar besser als q5 – bei turbo etwa steht es 2:2 bei 57 gleich genauen Aufnahmen (p = 1,00). Von large-v3 habe ich keine 8-Bit-Fassung gemessen, sondern nur die unquantisierte und die 5-Bit-Version: Im Katalog von ggerganov/whisper.cpp, meiner ursprünglichen Modellquelle, gibt es keine 8-Bit-Fassung von large-v3 – über den hier gezeigten Whisper.net-Downloader wäre sie zwar ladbar, getestet habe ich sie aber nicht. Bei turbo und medium liefern q5 und q8 zudem in rund drei Vierteln der Aufnahmen buchstabengleiche Transkripte und in über 90 % gleich viele Wortfehler – der Unterschied liegt praktisch im Rauschen. Ein Hinweis zur Methodik: Zählt man nur abweichende Transkripte statt tatsächlich schlechtere, wirkt ein Modell schnell unterlegen, obwohl es nur anders ist.

Praktische Konsequenz: Quantisierung ist bei Whisper der Standard-Hebel für die Dateigröße, ohne spürbaren Qualitätskompromiss. Theoretisch kann Quantisierung nur verlieren – mit 61 Aufnahmen lässt sich ein Verlust aber nicht nachweisen. Das ist nicht dasselbe wie „kein Verlust“, reicht für die Praxisentscheidung aber aus: Unquantisierte Fassungen sind gegenüber den quantisierten in der Fehlerrate nirgends nachweisbar besser – bei rund doppelter Größe gegenüber der 8-Bit- und zwei- bis dreifacher Größe gegenüber der 5-Bit-Fassung. Bei der Begriffstreue liegen sie in einzelnen Familien um rund einen Prozentpunkt vorn; das ist unter der Auflösung meines 61-Aufnahmen-Korpus und rechtfertigt den Aufpreis nicht. Ich lade grundsätzlich die 8-Bit-Fassung, es sei denn, die 5-Bit-Version spart noch einmal spürbar Platz auf einer speicherknappen Zielplattform.

Eine Ausnahme gibt es: Sobald Sie Whisper per Prompt-Priming mit einem eigenen Fachwörterbuch füttern, zeigt sich bei turbo ein konsistenter Vorteil für q8 gegenüber q5 – 5:0 in meiner Messung, ohne Gegenfall, wenn auch bei kleinem Stichprobenumfang. Für den Dauerbetrieb mit aktivem Wörterbuch ist q8 damit die robustere Wahl. Das ist an dieser Stelle nur ein Ausblick – Prompt-Priming für bessere Begriffserkennung ist ein eigenes Thema für einen Folgeartikel.

Backend-Wahl: CPU, Vulkan oder CUDA

Die Wortfehlerrate ist praktisch geräteunabhängig – Whisper rechnet deterministisch, dieselbe Modellfassung liefert auf derselben Art von Beschleunigung immer dieselbe Transkription. Über Backends hinweg gilt das nicht ganz: Im Vergleich Vulkan gegen CUDA waren in meinen Messungen 26 von 30 Transkripten zeichengleich, die restlichen Abweichungen ausschließlich bei kurzen, undeutlichen Aufnahmen. Die Verarbeitungszeit dagegen hängt in erster Linie davon ab, ob überhaupt eine Hardwarebeschleunigung zur Verfügung steht – ohne sie entscheidet die CPU.

In meinen Messungen auf einem Notebook mit integrierter AMD-Grafik (Radeon 680M) beschleunigt Vulkan gegenüber reiner CPU-Verarbeitung um Faktor 2,3 (kleine Modelle wie base) bis 6,9 (turbo). Auf dedizierter NVIDIA-Hardware (getestet mit einer RTX 4060) fällt der Sprung gegenüber Vulkan je nach Modellgröße noch einmal unterschiedlich aus – von etwa gleich schnell (tiny) bis rund siebenmal schneller (medium).

Praktisch bedeutet das: Ohne jede Hardwarebeschleunigung ist small die größte Fassung, die noch in einer für interaktives Diktieren brauchbaren Zeit antwortet – rund 4 Sekunden für ein kurzes Diktat (gemessen mit der unquantisierten Fassung, q8_0 selbst habe ich auf reiner CPU nicht separat gemessen); base und tiny sind dort schneller, aber deutlich ungenauer. Turbo fällt auf reiner CPU mit über 20 Sekunden aus dem Alltagsgebrauch. Vulkan ist dabei der pragmatischste Standardweg, solange Sie auf Windows x64 sind – offiziell dokumentiert ist das Runtime-Paket nur dafür (Linux-Binaries liegen zwar mit im Paket, sind aber nicht als unterstützte Plattform ausgewiesen). Es läuft dort auf praktisch jeder halbwegs aktuellen integrierten oder dedizierten GPU, ohne CUDA Toolkit. Dokumentiert ist ein Vulkan Toolkit ab 1.4.321.1; in der Praxis reicht auf Zielrechnern meist ein aktueller Grafiktreiber mit Vulkan-Unterstützung – was tatsächlich vorhanden ist, zeigt vulkaninfo (Teil des Vulkan SDK).

CUDA lohnt sich, wenn ohnehin eine dedizierte NVIDIA-Karte vorhanden ist. Erwarten Sie davon aber nicht automatisch, dass sich damit das größte Modell rechnet: In meinen Messungen auf der RTX 4060 wurde der relative Abstand zwischen large-v3 und turbo sogar größer, nicht kleiner – turbo bleibt auch dort die Standardwahl.

Entscheidungs-Framework: Das passende Modell für Ihr Gerät

Ohne feste Zielhardware ist die Modellwahl ein Ratespiel. Mit ihr wird sie eine einfache Nachschlagetabelle. Aus meinen Messungen leite ich vier Grundtypen ab:

Gerät	Empfehlung	Warum
x64 mit Vulkan oder CUDA	turbo-q8_0	bestes Verhältnis aus Tempo und Genauigkeit
x64 mit starker dedizierter GPU, viele Fachbegriffe	large-v3-q5_0	trifft die meisten Fachbegriffe – Details unten
Ohne Beschleunigung (u. a. ARM64 – dort gibt es kein Vulkan-Paket)	small-q8_0	größte Fassung, die auf reiner CPU noch praxistauglich bleibt
Schwache CPU ohne GPU	base-q8_0 oder tiny-q8_0	schnellste Antwortzeit im Feld, dafür schwächste Qualität

Drei Nuancen zu dieser Tabelle: Erstens trifft large-v3-q5_0 ohne Wörterbuch die meisten Fachbegriffe (89,8 % gegen 83,0 % Begriffstreue bei turbo). Mit einem gepflegten Fachwörterbuch zieht turbo-q8_0 in der Wortfehlerrate gleich (beide 5,2 %) und liegt bei den Begriffen nur noch knapp zurück (92,0 gegen 97,7 %) – bei deutlich weniger Zeitkosten damit meist die günstigere Wahl. Der Rest-Vorsprung von large-v3 betrifft Begriffe, die im Wörterbuch fehlen; dort ist Wörterbuchpflege der billigere Hebel als das größere Modell. Zweitens ein paar Vorbehalte zu den CPU-Zeitwerten:

• Sie stammen aus unquantisierten Testläufen auf einem x64-Notebook (small rund 4, base rund 1,6 Sekunden für ein kurzes Diktat) – die empfohlenen q8-Fassungen selbst habe ich auf reiner CPU nicht separat gemessen.
• Auf Vulkan lag small-q8_0 mit der unquantisierten Fassung gleichauf (1041 gegen 1035 ms), langsamer war die q8-Variante dort in keinem Fall. Zeitvergleiche innerhalb einer Familie sind aus diesem Durchlauf aber ohnehin nicht sauber belastbar (siehe oben).
• Für ARM64 habe ich nur bestätigt, dass es läuft, nicht wie schnell.

Wichtig: Das ist eine Vorauswahl, keine feste Regel. Bis auf medium, für das ich keinen eigenen Anwendungsfall gefunden habe, bleiben alle Fassungen grundsätzlich sinnvoll – welche für Sie passt, entscheidet die Zielmaschine, nicht ein pauschales „bestes Modell“. Auf einem Notebook ohne nutzbare Grafikbeschleunigung ist selbst tiny trotz 38 % Fehlerrate unter Umständen die einzige Fassung, die überhaupt in erträglicher Zeit antwortet – die Alternative ist dort kein besseres Modell, sondern gar kein Diktat.

🧭 Warum diese Tiefe zählt: Gerade bei Nischen-Themen wie diesem entscheidet nicht das Ranking allein, sondern ob eine KI-Suche den Inhalt überhaupt als verlässliche Quelle zitiert – wie das funktioniert, erkläre ich in SEO vs. GEO vs. AIO.

Fazit: Modellwahl ist eine Geräte-Frage, keine Bestenliste

Es gibt kein bestes Whisper-Modell – nur die passende Fassung für Ihre Zielhardware, und die richtige Quantisierungsstufe kostet Sie dabei so gut wie nichts. Whisper.net macht den Einstieg unkompliziert: ein NuGet-Paket, ein Runtime-Paket, wenige Zeilen Code bis zur ersten lokalen Transkription. Der eigentliche Aufwand steckt nicht im Setup, sondern in der bewussten Modellwahl – und genau die lohnt sich, weil sie über flüssiges Diktier-Erlebnis oder Frustration entscheidet.

Mein Rat aus der Praxis: Fangen Sie mit turbo-q8_0 an, wenn eine halbwegs aktuelle GPU zur Verfügung steht, und wechseln Sie erst dann zu einer anderen Fassung, wenn ein konkretes Problem auftaucht – zu langsam, zu viele Fachbegriffe falsch erkannt, oder eine Zielplattform ohne Beschleunigung. Alles Weitere, etwa ein eigenes Fachwörterbuch per Prompt-Priming, baut auf dieser Grundentscheidung auf.

Ihre Erfahrungen sind gefragt!

Setzen Sie bereits lokale Spracherkennung in eigenen .NET-Projekten ein? Haben Sie die Modellwahl schon gegen Ihre eigene Hardware getestet, oder kämpfen Sie noch mit zu langsamer CPU-Verarbeitung? In meinen weiteren .NET-Artikeln finden Sie mehr Praxis-Tipps und Tricks für den Arbeitsalltag.