Worin lokale KI 2026 wirklich gut ist, und worin sie weiter patzt

Jemand hat meinen Beitrag über lokale Modelle, die aufgeholt haben gelesen und mir eine vernünftige Frage gemailt: aufgeholt worin genau?

Berechtigte Frage. Und es ist die, die niemand beantwortet, denn "der Abstand beträgt vier Monate" ist eine Schlagzeile und "hier ist die Aufgabenliste" ist Arbeit.

Hier ist also die Aufgabenliste. Kein Bauchgefühl, kein Leaderboard-Screenshot. Eine Spalte mit Dingen, die ich ohne Nachdenken einem Modell auf meiner eigenen Hardware gebe, eine Spalte mit Dingen, die weiterhin an eine Frontier-API gehen, und die Belege dafür, warum jeder Punkt dort steht, wo er steht. Die nützliche Version von lokalen LLM-Anwendungsfällen ist keine Ideenliste. Es ist eine Sortierregel.

Die Spalte, die funktioniert, ist größer, als du denkst

Fangen wir mit Sprache an, denn das ist der sauberste Fall. Im Open ASR Leaderboard erreicht NVIDIAs Parakeet TDT 0.6B v3 über die acht Benchmark-Sätze im Schnitt eine Wortfehlerrate von 6,34%. Whisper large-v3 liegt im Schnitt bei rund 7,4%. Das bessere Modell ist das kleinere, es ist eine Datei mit 0,6 Milliarden Parametern, und es läuft auf einem Laptop. Es gibt keine Variante dieser Aufgabe, bei der eine API zu bezahlen die technisch bessere Wahl wäre. Transkription hat die Cloud verlassen, und niemand hat ein Memo geschickt.

Bei Embeddings ist es dieselbe Geschichte. Die Qwen3-Embedding-Familie hat mit 70,58 Platz eins im mehrsprachigen MTEB-Leaderboard geholt, und eine englische Momentaufnahme vom Januar 2026 hatte sie mit 70,6 weiterhin auf eins. Googles EmbeddingGemma hat 308 Millionen Parameter und liegt auf Rang 13 von 93, mit 0,033 Abstand zur Spitze. Deine semantische Suche, dein RAG-Retrieval, dein "finde mir das ähnliche Support-Ticket": Das ist ein gelöstes lokales Problem, und zwar seit einer Weile.

Dann die Masse an Textarbeit. Klassifikation und Weiterleitung. Strukturierte Extraktion aus Rechnungen, Verträgen und E-Mails. Zusammenfassung. Umformulierung im Tonfall. Übersetzung für den internen Gebrauch, wo niemandes Ruf an der Formulierung hängt. Codevervollständigung bei Mustern, die das Modell tausendmal gesehen hat. Das sind die Aufgaben, bei denen ein 4B- oder 8B-Modell die Arbeit macht und die Fehlerquote niedrig genug ist, um darum herum zu konstruieren.

Was diese gemeinsam haben, lohnt sich zu benennen, denn es ist die eigentliche Regel. Alles, was das Modell braucht, steht im Prompt, und es gibt genau einen Sprung von Eingabe zu Ausgabe. Kein Weltwissen, das es schon haben muss. Keine Entscheidungskette, in der Schritt vier davon abhängt, dass Schritt drei gut gegangen ist. Gib ihm das Dokument, frag nach den Feldern, bekomm die Felder.

Das deckt ehrlich gesagt den größten Teil der KI-Arbeit ab, die ich für Kunden tatsächlich baue. Nicht die Demo-Arbeit. Die Mengenarbeit.

Die Spalte, die weiterhin patzt

Die andere Spalte beginnt dort, wo die Kette lang wird.

Das habe ich im vorherigen Beitrag beschrieben: dreißig Tool-Aufrufe tief in einer echten Codebasis fing das lokale Modell an, selbstbewusst eine Datei zu bearbeiten, die nicht im Projekt war. Das ist kein Einzelfall. Es ist die dokumentierte Form des Problems. Der Titel des Papers, zu dem ich immer wieder zurückkomme, lautet Don't Adapt Small Language Models for Tools; Adapt Tool Schemas to the Models, und es fand, dass das Umbenennen von Tool-Bestandteilen auf das, was das Modell im Vortraining gesehen hat, Schema-Fehlausrichtungsfehler um 80% gesenkt und die Werte in MetaTool und RoTBench um bis zu 17% verbessert hat. Lies das rückwärts: Ein großer Teil des Tool-Versagens kleiner Modelle ist kein Denkversagen, sondern das Modell, das deine Namenskonvention nicht wiedererkennt. Was ermutigend und für alle, die das Modell beschuldigt haben, leicht demütigend ist.

Agentische Arbeit über lange Horizonte sitzt in dieser Spalte. Ebenso alles, was aktuelles Weltwissen erfordert, offensichtlich, denn die Gewichte wurden vor Monaten eingefroren, und ein lokales Modell hat keine Ahnung, was letzte Woche passiert ist, außer du sagst es ihm. Ebenso komplexes Schließen unter mehreren Nebenbedingungen. Und ebenso die Synthese über großen Kontext, was unten einen eigenen Absatz verdient, weil die Zahlen dort wirklich alarmierend sind.

Der ehrliche Vorbehalt: Der Abstand bei agentischer Arbeit schrumpft schneller, als ich erwartet hatte. GLM-5.2 führt inzwischen die Open-Weight-Ergebnisse bei SWE-bench Pro und Terminal-Bench 2.1 an, und das Muster über BFCLv3, tau-2-bench und MCP-Universe hinweg ist, dass offene Modelle besser als vor einem Jahr über die Trainingsverteilung hinaus verallgemeinern. Bei offener Langhorizont-Planung liegen die geschlossenen Modelle weiterhin knapp vorn. Aber "knapp vorn" ist ein anderer Satz als der, den ich 2025 geschrieben hätte.

Wo die Linie nach Modellgröße verläuft

Die meisten Ratgeber zu lokalen LLM-Anwendungsfällen überspringen diesen Teil, was seltsam ist, denn die Größenfrage hat eine sauberere Antwort als die Aufgabenfrage. Speicherarithmetik hat keine Meinungen.

Bei Q4 braucht ein 7B- bis 8B-Modell 4 bis 6 GB, was heißt, dass 8 GB VRAM oder ein Basis-Mac es betreibt. Diese Klasse macht Klassifikation, Extraktion, Umformulierung, Weiterleitung und kurze Zusammenfassungen. Sie macht keine anhaltende Tool-Nutzung, und ich würde so eines unbeaufsichtigt nicht vor einen Kunden stellen.

Die 20B-Klasse ist derzeit der Sweet Spot, und das ist nicht knapp. gpt-oss-20b liefert einen 12,8-GiB-Checkpoint und läuft in rund 16 GB, also einer RTX 4080, einer 4090 oder einem Mac mit 24 GB. Es wurde außerdem mit einem Chat-Schema gebaut, das um Tool-Aufrufe herum entworfen ist, und man spürt das. Auf dieser Stufe hört ein lokales Modell auf, ein Text-Werkzeug zu sein, und wird zu etwas, das du in eine Pipeline hängen kannst.

Dann will 32B bei Q4 rund 20 GB, und 70B will 40 GB und mehr, realistisch 48 bis 96 GB, wenn du Kontextreserve willst. Die 120B-Klasse ist gleichzeitig interessant und teuer: gpt-oss-120b aktiviert pro Token nur rund 5B Parameter und läuft deswegen schnell, aber du hältst trotzdem alle 117B Gewichte im Speicher. Sagen wir 60 bis 65 GB auf einer Karte. Das ist eine H100 oder eine Workstation-Karte mit 96 GB, und ab da führst du ein sehr anderes Gespräch über Geld, das ich mit mir selbst schon in der Break-even-Rechnung zu lokaler Hardware geführt habe.

Eines erwischt Leute ständig: Die Gewichte sind nicht die Rechnung. Bei 128K Kontext kann der KV-Cache zweistellige Gigabytes obendrauf legen, in einem durchgerechneten Beispiel rund 29% des Gesamtspeichers. Jede VRAM-Tabelle, die du online findest, nennt dir das Modell bei kurzem Kontext. Kalkulier den Cache ein, sonst kippt dein schönes 20B-Setup beim ersten langen Dokument.

Quantisierung, ehrlich

Die Community-Linie lautet, Q4 sei kostenlos und Q8 sei für Leute mit Geld zum Verbrennen. Das stimmt ungefähr, mit einer Ausnahme, die für genau das, was die meisten bauen wollen, enorm zählt.

Die Durchschnitte stützen die Community: Q8 zeigt rund 0,1% Verlust bei MMLU, Q4 rund 1,2%, und Q4_K_M landet bei 95 bis 97% der FP16-Qualität für grob 35% des VRAM. Gut. Nimm das Q4.

Aber Durchschnitte verbergen die Form. Die auf der ICML veröffentlichte ACBench-Arbeit, Can Compressed LLMs Truly Act?, hat Kompression gezielt gegen agentische Fähigkeit statt gegen Perplexität geprüft, über 12 Aufgaben und 15 Modelle. Ihr Befund: 4-Bit-Quantisierung erhält Workflow-Generierung und Tool-Nutzung mit nur 1 bis 3% Einbuße, verschlechtert aber die Genauigkeit in realen Anwendungen um 10 bis 15%. Gleiche Quantisierung. Gleiches Modell. Zehnmal der Schaden, je nachdem, was du gefragt hast.

Das ist der ganze Punkt dieses Beitrags in einem Ergebnis. "Reicht Q4" hat keine Antwort, bevor du sagst, wofür genau. Extraktion und Klassifikation: Nimm das Q4 und denk nicht drüber nach. Alles, wo das Modell einen Plan über Schritte hinweg im Kopf behalten muss: Nimm Q8, wenn du es halten kannst, und geh mit der Haltung ran, zu messen statt anzunehmen. Eine separate Signal-Rausch-Analyse fand, dass 4 Bit die Leistung über Aufgabentypen hinweg weitgehend erhält und 3 Bit der Punkt ist, an dem wissensintensive und schlussfolgernde Aufgaben zerfallen, 3 Bit ist also eine falsche Sparsamkeit, egal was die Dateigröße sagt.

Die Fehlermodi, die niemand auf ein Leaderboard schreibt

Vier Dinge gehen im Produktivbetrieb kaputt, vor denen keine Benchmark-Spalte warnt.

Strukturierte Ausgabe ist schlechter, als du annimmst. Ein Paper von 2026 zu strukturierter Ausgabe kleiner Modelle hat Llama 3.1-8B, Gemma 2-9B und Qwen 2.5-7B getestet und festgestellt, dass ohne Formatierungshinweise kein Modell überhaupt gültiges JSON produziert hat. Null Prozent. Mit einem minimalen Referenz-Prompt kam Llama auf 44,43% bei GSM8K, Qwen auf 74,30% dort und 0% bei MATH, und Gemma kam auf 0%, weil es sein JSON immer wieder in Markdown-Zäune gepackt hat. Iterative Prompt-Optimierung hat alle auf 84 bis 87% gebracht. Constrained Decoding hat gültige Syntax erzwungen, aber die 3,6- bis 8,2-fache Latenz gekostet, ohne die Ergebnisse verlässlich zu verbessern. Der separate Structured Output Benchmark macht denselben Punkt anders: Schema-Konformität ist hoch, während die Wertegenauigkeit bei Text bei 83% und bei Bildern bei 67,2% endet. Das JSON parst. Die Felder sind falsch.

Beworbener Kontext ist nicht nutzbarer Kontext. NVIDIAs RULER setzt den real nutzbaren Kontext auf 50 bis 65% des beworbenen. Adobes NoLiMa definiert die effektive Länge als den Punkt, an dem ein Modell noch 85% seines Basiswerts hält, und nach diesem Maß fallen die meisten Modelle bei 32K Token unter die Hälfte ihrer Kurzkontext-Leistung. Chroma hat 18 Modelle auf Kontextverfall getestet, und jedes einzelne hat mit wachsender Eingabe nachgelassen. Das ist kein Problem lokaler Modelle, es ist das Problem aller, aber es trifft lokal härter, weil du auf dieses Kontextfenster gezählt hast, um dir mehr Hardware zu sparen.

Anweisungsdrift über lange Eingaben ist die praktische Version derselben Sache. Der System-Prompt, den du geschrieben hast, konkurriert mit 40.000 Token Dokument, und etwa ab zwei Dritteln verliert er. Ich bin aus der anderen Richtung darauf gestoßen, als ich angeschaut habe, wie viel Kontext Tool-Definitionen fressen, bevor du ein Wort tippst.

Stiller Qualitätszusammenbruch. Nichts wirft einen Fehler. Die Ausgabe sieht weiter aus wie eine Ausgabe. Das ist die, die dich erwischt, und die einzige Verteidigung ist, einen Satz bekannt guter Beispiele zurückzuhalten und sie jedes Mal neu laufen zu lassen, wenn du Modell, Quantisierung oder Prompt änderst.

Die Aufteilung, die ich tatsächlich fahren würde

Lokal für Menge, Vertraulichkeit und Latenzempfindlichkeit. API für die schweren zehn Prozent. Das ist das ganze Muster, und die Entscheidungsregel passt in drei Fragen.

Braucht die Aufgabe Wissen, das das Modell nicht im Prompt hat? API. Erfordert sie mehr als etwa drei voneinander abhängige Schritte, die hintereinander klappen müssen? API. Läuft sie tausendfach am Tag auf deinen eigenen Daten mit einem Schema, das du kontrollierst? Lokal, und hör auf, dafür pro Token zu zahlen.

Alles andere ist eine Messung, keine Debatte. Nimm fünfzig echte Beispiele aus deiner eigenen Arbeit, jag sie durch beide und zähl. Das ist ein Vormittag Arbeit und beendet mehr Streit als jedes Leaderboard.

Compliance habe ich hier bewusst weggelassen, denn das ist ein eigener Grund, lokal zu betreiben, und es verdient eine eigene Behandlung. Wenn DSGVO und Datenlokalität dich treiben statt der Fähigkeiten, ist der EU-konforme lokale KI-Stack der Beitrag, den du willst. Und wenn du dich fragst, wie das Setup in der Praxis aussieht, habe ich Claude Code auf ein lokales Modell zu richten von Anfang bis Ende aufgeschrieben.

Was ich dir mitgeben will, ist kleiner als eine Empfehlung. Die meisten, die lokale LLM-Anwendungsfälle bewerten, testen ein Modell an einer schweren Aufgabe, sehen es scheitern und schließen daraus, lokal sei nicht bereit. Die schwere Aufgabe wäre ohnehin gescheitert. Die interessante Frage ist, wie viel von deiner tatsächlichen Arbeitslast langweilig ist, und meiner Erfahrung nach beim Bauen dieses Zeugs für Kunden lautet die Antwort: das meiste.

Wenn du herausfinden willst, auf welcher Seite dieser Linie dein eigenes Projekt liegt, melde dich. Ich sage dir lieber, dass es die API ist, als dir eine Maschine zu verkaufen, die du nicht brauchst.