Lokales LLM für Business-Texte auswählen: 12 Setups im Test

Wählen Sie das größte dichte Modell (Dense), das Ihre Hardware überhaupt ausführen kann, und testen Sie es an Ihren eigenen Aufgaben, bevor Sie ihm vertrauen. Das ist die kurze Antwort aus unserem Benchmark vom Oktober 2026, bei dem wir 12 lokale Modellkonfigurationen über Ollama auf einem Laptop mit 8-GB-GPU getestet und jede Ausgabe gegen eine Referenzantwort bewertet haben. Googles Gemma 4 31B gewann mit 48 von 55 Punkten. Die Tricks, die mehr Qualität zum Nulltarif versprechen (quantisierungsbewusste Builds, 8-Bit-Gewichte, ein Denkmodus), änderten das Ergebnis nicht, und der Denkmodus verschlechterte die Fakten sogar.

Die Einschätzung von Rogue AI: Lassen Sie bei Geschäftstexten ein lokales Modell entwerfen und jemand anderen prüfen. Es liest lange Eingaben und schreibt den ersten Entwurf; ein stärkeres Modell oder ein Mensch prüft jeden Fakt, bevor etwas das Haus verlässt. Dieser Leitfaden beschreibt die Methode, die Zahlen und die Setup-Fehler, die uns einen Tag kosteten. Für die grundsätzliche Entscheidung zwischen Eigenbetrieb und Einkauf beginnen Sie mit unserem Vergleich von selbst gehosteter KI und Cloud-APIs.

Wie wählt man ein lokales LLM für Geschäftstexte aus?

Entscheiden Sie anhand eigener Aufgaben, bewertet gegen Antworten, denen Sie vertrauen, nicht anhand öffentlicher Ranglisten. Wir haben sechs feste Aufgaben aus der Praxis erstellt: eine kurze Faktfrage zur Wohnsitz- und Steuerregistrierung in einem kleinen EU-Land (fünf Punkte, minus eins pro erfundenem Fakt), zwei Englisch-Deutsch-Übersetzungen, eine Aktienanalyse nur mit den bereitgestellten Zahlen eines fiktiven Unternehmens, eine Zusammenfassung eines langen Sicherheitsartikels und eine deutsche Antwort an einen Recruiter. Für jede Aufgabe gibt es eine im Voraus geschriebene Referenzantwort. Ein Frontier-Modell bewertete jede lokale Ausgabe anhand dieser Referenz; ein zweiter KI-Richter bewertete die erste Runde blind und kam zum gleichen Ranking, wenn auch mit niedrigeren Gesamtwerten. Die Testläufe erfolgen über ein Skript, immer ein Modell nach dem anderen, sodass jedes Modell die gesamte Maschine nutzt.

Zwei Regeln machten die Ergebnisse nutzbar. Erfundene Fakten kosteten Punkte, da eine flüssig formulierte falsche Antwort der teuerste Fehler in Geschäftstexten ist. Die Geschwindigkeit wurde aufgezeichnet, aber nie gegen die Qualität aufgewogen: Ein Entwurf, der zwei Minuten braucht, während Sie etwas anderes erledigen, ist in Ordnung. Die allgemeine Evaluationsmethode dahinter wird in unserem LLM-Evaluierungs-Praxisleitfaden ausführlich behandelt.

Welche lokalen Modelle wurden getestet und wie haben sie abgeschnitten?

Sechs der zwölf Konfigurationen sind in der Tabelle; die anderen sechs waren ein zweites dichtes Modell, ein reiner Deutschtest eines mittelgroßen Modells und vier Varianten von Gemma 4, die unten beschrieben werden. Die Zeiten stammen aus unserem Log auf einem Laptop und variieren auf Ihrer Hardware. Die Punktzahlen sind entscheidend: Das dichte 31B-Modell lieferte alle fünf Fakten korrekt, während die meisten anderen Fristen, Behörden und Schwellenwerte erfanden. Der schlimmste Fehler war glm-4.7-flash, das behauptete, EU-Bürger seien von der Einkommensteuer befreit. gpt-oss:20b las einen Discounted-Cashflow-Wert verkehrt herum und bezeichnete ihn als „Upside”. Beide Antworten lasen sich flüssig, was sie schwer erkennbar macht.

Ist die Modellgröße wichtiger als Quantisierung oder Denkmodus?

Bei unseren Aufgaben ja. Der Wechsel vom 26B-Mixture-of-Experts-Modell zum dichten 31B-Modell steigerte die Gesamtpunktzahl von 45,5 auf 48 von 55 und den Faktenwert von 3,5 auf 5. Alles andere, was wir mit derselben Modellfamilie versuchten, half nicht:

• Quantisierungsbewusster 31B-Build: 4 von 5 bei den Fakten statt 5 und langsamer, mit 66 bis 300 Sekunden pro Aufgabe.
• 26B bei 8-Bit (Q8): 4 von 5 bei den Fakten; die deutsche Antwort nutzte eine Standard-Füllphrase.
• 26B mit Denkmodus: 3 von 5 bei den Fakten. Der Denkschritt produzierte zwei falsche Zahlen.
• Quantisierungsbewusstes 26B: 2,5 von 5, plus ein deutsches Nicht-Wort.

Unser Fazit, in der Benchmark-Datei notiert: Größe steigert die Qualität, QAT, Q8 und Denkmodus tun es nicht. Dies ist ein Ergebnis für sechs Aufgaben, kein allgemeines Gesetz.

Wie schnell ist ein 31B-Modell auf einer 8-GB-GPU?

Rechnen Sie mit 2,3 bis 4,5 Token pro Sekunde. Die Datei von Gemma 4 31B ist in Ollama bei Q4_K_M 20,4 GB groß, sodass auf einer 8-GB-Karte der Großteil des Modells aus dem Systemspeicher läuft. Unser Log zeigt 2,3 bis 4,5 Token pro Sekunde und 45 bis 160 Sekunden pro Aufgabe. Für Chat scheidet es damit aus, für Stapelarbeit ist es ideal: Zusammenfassungen, Übersetzungen und erste Entwürfe, die laufen, während Sie nicht am Schreibtisch sitzen. Google listet das 31B-Modell mit 30,7 Milliarden Parametern und einem 256K-Kontextfenster unter der Apache-2.0-Lizenz. Die kommerzielle Nutzung ist also nicht das Hindernis, der Speicher schon.

Behalten Sie ein kleines Spezialmodell für alles Interaktive. Unser internes Tool zum Lesen von Belegen testete ebenfalls das 31B-Modell: 11 von 12 Belegen korrekt bei einem Median von 149 Sekunden, gegenüber 12 von 12 in 6,5 Sekunden mit dem bereits genutzten 7B-Vision-Modell. Das kleine Modell blieb im Einsatz.

Sollte man Ollama nativ oder in Docker ausführen?

Auf einem Windows-Laptop nativ. Wir haben unseren Modellserver bewusst aus dem Container auf den Host verschoben. Unserer Erfahrung nach war der GPU-Passthrough über WSL2 unzuverlässig, Modelle luden etwa zehnmal langsamer und der Speicher blieb in der WSL-VM hängen. Container erreichen den nativen Server weiterhin über die Docker-Host-Adresse. Auf Linux-Servern fällt die Abwägung anders aus; diesen Fall behandelt unser Docker-KI-Deployment-Produktionsleitfaden. Egal, wofür Sie sich entscheiden, halten Sie den Modell-Port auf dem Loopback; unsere Notizen zur Absicherung selbst gehosteter KI-Infrastruktur erklären, warum.

Welche Einstellungen legen ein lokales LLM still lahm?

Drei Standardwerte haben uns echte Zeit gekostet. Keiner davon meldet einen Fehler.

Kontextfenster

Die Dokumentation zur Kontextlänge von Ollama besagt, dass Maschinen mit weniger als 24 GiB VRAM standardmäßig einen 4k-Kontext erhalten. Bei einem langen Dokument rutscht der Anfang des Prompts, oft die Systemanweisungen, aus dem Fenster. Setzen Sie num_ctx pro Anfrage, wie in den Ollama-FAQs beschrieben, dimensioniert auf die Eingabe plus Platz für die Antwort.

Timeouts

Die eingebaute fetch-Funktion von Node nutzt undici, dessen Client-Dokumentation das headersTimeout standardmäßig auf 300e3 Millisekunden setzt. Ollama sendet bei stream: false keine Header, bis die gesamte Antwort fertig ist. Jede lokale Antwort, die länger als fünf Minuten dauerte, schlug also mit einem einfachen „fetch failed” fehl, unabhängig von unseren eigenen Timeouts. Die Lösung ist stream: true: Ollama schickt dann die Header mit dem ersten Token, und der Client liest die Antwort Zeile für Zeile. Eine Anfrage, die noch in der Warteschlange von Ollama steht, bekommt ebenfalls keine Header. Deshalb rufen unsere Skripte Ollama über das schlichte http-Modul von Node auf, dessen Client kein solches Limit setzt.

Parallele Jobs

Die Ollama-FAQs listen OLLAMA_NUM_PARALLEL mit einem Standardwert von 1 und einer Warteschlange von bis zu 512 Anfragen. Mehrere gleichzeitig aufgerufene Skripte warten daher in der Reihe, und wer das Limit erhöht, zahlt mit Speicher: Der Verbrauch wächst mit parallelen Anfragen mal Kontextlänge. Wir serialisieren unsere Jobs mit einer Lock-Datei, da ein 31B-Modell plus langer Kontext auf einem Laptop keinen Spielraum lässt.

Lohnt sich das Fine-Tuning eines lokalen Modells?

Nicht zuerst. Wir haben einen kleinen LoRA-Adapter (Rang 8, 440 Beispiele) für Gemma 4 31B auf zwei kostenlosen Cloud-T4-GPUs trainiert und ihn über llama.cpp gegen das Basismodell getestet, da der Adapter nicht in Ollama geladen werden konnte. Ergebnis: 47 gegen 47 von 55. Die deutsche Wortwahl verbesserte sich leicht, mit weniger Anglizismen, aber die Fakten wurden etwas schlechter. Wir behielten das Basismodell. Unser LoRA-Fine-Tuning-Praxisleitfaden erklärt die Technik; unser Ergebnis spricht dafür, erst bessere Trainingsdaten zu sammeln, vor allem korrigierte Entwürfe, bevor Sie Zeit in weiteres Training stecken.

Wie nutzt man ein lokales LLM sicher in einem Schreibworkflow?

Lassen Sie es die Menge erledigen und das Urteil bei Menschen oder einem stärkeren Modell. Unsere Aufteilung:

• Lokales Modell: liest lange Eingaben (Logs, Kontoauszüge, ausgelesene Webseiten) und liefert den Kern; schreibt erste Entwürfe und deutsche Übersetzungen.
• Frontier-Modell oder Mensch: entscheidet, editiert, prüft jede Zahl und jeden Namen gegen die Quelle und gibt alles frei, was veröffentlicht oder versendet wird.
• Jede Korrektur speichern wir als Trainingspaar, sodass das nächste Fine-Tuning aus echten Korrekturen lernt statt aus generischen Daten.

Warum das wichtig ist

Ein lokales Modell verwandelt das Lesen langer Texte und erste Entwürfe von Kosten pro Token in Stromkosten und hält die Eingaben auf Ihrer eigenen Maschine. Der Haken: Gerade die scheinbar günstigsten Optionen, kleine Modelle und geschickte Quantisierung, erfinden am meisten. Der sichere Weg für ein Team ist aus unserer Sicht langweilig: das größte dichte Modell, das in die Hardware passt, ein Benchmark eigener Aufgaben und ein Reviewer für jeden Fakt. Wenn Sie noch entscheiden, ob Sie KI überhaupt im Haus betreiben sollen, schlüsselt unser privates KI-Pilotprojekt die ersten Wochen auf.

Weiterführende Lektüre

• Selbst gehostete KI vs. Cloud-APIs zu Kosten, Datenschutz und Kontrolle.
• LLM-Evaluierung in der Produktion zum Aufbau eines aussagekräftigen Testsets.
• LoRA-Fine-Tuning, ein Praxisleitfaden für den Fall, dass Sie die Daten haben.
• Selbst gehostete KI-Infrastruktur absichern, bevor der Modellserver ins Netzwerk geht.
• Docker-KI-Deployment in der Produktion für das serverseitige Setup.