On-Premise-KI ohne teuren Server: Was auf CPU und kleinem Modell wirklich geht

Die Annahme, On-Premise-KI brauche einen teuren Server mit Grafikkarte, hält viele kleinere Träger davon ab, es überhaupt zu versuchen. Für einen häufigen und nützlichen Anwendungsfall stimmt sie nicht: eigene Systeme abfragen, Berichte ziehen, Daten im Haus behalten. Das läuft mit einem kleinen Modell auf einer gewöhnlichen Maschine, sogar ohne Grafikkarte, wenn die Architektur das ausgleicht. Es gibt aber eine klare Grenze, und die zu kennen ist die eigentliche Kompetenz.

Was auf gewöhnlicher Hardware läuft

Ohne Grafikkarte liegen Modellgewichte und Kontext im Arbeitsspeicher. Ein kleines Modell mit 7 bis 8 Milliarden Parametern, auf Q4 quantisiert, belegt rund 5 bis 6 GB. Damit läuft es auf einer 8-GB-Maschine knapp und auf 16 GB bequem. Ein 14B-Modell will etwa 10 GB und mehr Geduld. Beim Tempo auf reiner CPU sind für ein 7-bis-8B-Modell je nach Prozessor grob einige wenige bis rund 15 Token pro Sekunde realistisch. Wie lange eine Antwort dauert, hängt damit vor allem an ihrer Länge: eine kurze, strukturierte Ausgabe wie ein Werkzeugaufruf ist in wenigen Sekunden fertig, ein längerer Fließtext eher in Dutzenden Sekunden. Bei großem Kontext, etwa vielen RAG-Dokumenten, kommt die Zeit hinzu, die Eingabe zu verarbeiten, bevor das erste Token erscheint. Für eine Abfrage vom Typ „zieh mir den Bericht” ist das völlig ausreichend; für ein flüssiges Chat-Gespräch nicht. Genau diese asynchrone, nicht interaktive Nutzung ist der Sweet-Spot der kleinen Hardware.

Der Trick, der ein kleines Modell zuverlässig macht

Ein kleines Modell, das man frei formulieren lässt, produziert bei Werkzeugaufrufen regelmäßig fehlerhafte Ausgaben: ein Feld fehlt, das JSON ist kaputt, der Aufruf ist unbrauchbar. Die Lösung ist nicht ein größeres Modell, sondern erzwungene strukturierte Ausgabe.

Ollama kann die Ausgabe an ein JSON-Schema binden (Feld format), und gibt selbst an, das sei „zuverlässiger und konsistenter als der reine JSON-Modus”. Darunter arbeitet llama.cpp mit einer grammatikgebundenen Dekodierung (GBNF): Bei jedem Schritt werden alle Token, die die vorgegebene Struktur brechen würden, schon vor der Auswahl ausgeschlossen. Eine ungültige Ausgabe wird damit nicht unwahrscheinlicher, sondern unmöglich. Das erspart die Schleife aus Prüfen und Wiederholen und macht kleine Modelle für strukturierte Aufgaben erst brauchbar.

Wie stark dieser Hebel wirkt, zeigt eine Untersuchung von NVIDIA (Mai 2026): Mit grammatikgebundener Dekodierung stieg die durchschnittliche Erfolgsquote kleiner Modelle von 62,5 auf 75,2 Prozent, ein sehr kleines Modell sprang um über 40 Punkte (Quelle). Nicht die Hardware macht hier den Unterschied, sondern die Architektur.

Das Muster: das Modell übersetzt, der Code handelt

Ein tragfähiger Aufbau nutzt das Modell als Übersetzer, nicht als Steuermann. Man definiert dem Modell eine kleine Zahl klar beschriebener Werkzeuge (Funktionsdefinitionen mit JSON-Schema). Das Modell schlägt genau einen strukturierten Aufruf vor, der eigene, deterministische Code prüft ihn und führt ihn aus, etwa gegen die vorhandene ERP- oder Shop-Schnittstelle. Drei Regeln halten das robust:

• Wenige, einfache Werkzeuge. Je enger die Aufgabe je Aufruf, desto zuverlässiger das kleine Modell.
• Zuerst nur lesen. Berichte ziehen ist harmlos; eine falsche Antwort ist prüfbar. Schreibende Vorgänge (etwa eine Buchung anlegen) gehören hinter eine menschliche Bestätigung, nie in einen unbeaufsichtigten Automatismus.
• Temperatur 0 und festes Schema für reproduzierbare Ergebnisse.

Die Planung mehrerer Schritte gehört in den Code, nicht in das Modell.

Die Modellwahl

Unter den kleinen Modellen eignen sich für Werkzeugaufrufe und deutschsprachige Aufgaben vor allem Qwen3 (offen lizenziert, ausdrücklich für Function-Calling ausgelegt, über hundert Sprachen), Llama 3.1 8B und Mistral. Die Richtung deckt sich mit der DSK-Orientierungshilfe zu RAG, die ohnehin ein eher kleineres Modell empfiehlt, das weniger Fakten auswendig speichert. Die Auswahlregel bleibt: das kleinste Modell nehmen, das die eigenen Aufgaben besteht, und an den eigenen Aufgaben testen, nicht an öffentlichen Ranglisten.

Die Grenze, die man kennen muss

Kleine Modelle sind beim Function-Calling messbar schwächer als große. Das Berkeley Function-Calling Leaderboard zeigt das innerhalb einer Modellfamilie deutlich: In der Llama-3.1-Reihe erreicht die 8B-Variante rund 0,76, die 70B-Variante rund 0,85 und die 405B-Variante rund 0,89. Der begleitende Fachaufsatz benennt, wo die Schwäche liegt: Einzelne, klar spezifizierte Aufrufe gelingen zuverlässig, während „Gedächtnis, dynamische Entscheidungen und Schließen über lange Ketten” die offenen Probleme bleiben.

Für die Praxis heißt das: Ein sauber umrissener Werkzeugaufruf nach dem anderen ist solide. Mehrstufige, parallele oder über viele Runden laufende Orchestrierung ist der Punkt, an dem ein kleines Modell abbaut. Wer dorthin muss, hat die Grenze erreicht und braucht entweder einen Menschen in der Schleife oder ein größeres Modell.

Fazit

On-Premise-KI auf bescheidener Hardware ist für eine klar abgegrenzte Klasse von Aufgaben kein Spielzeug, sondern brauchbar, und die Daten verlassen das Haus nicht. Der begrenzende Faktor ist nicht das Grafikkarten-Budget, sondern ob man das Modell strukturell zwingt und die Aufgaben einstufig hält. Das ist eine Architekturfrage, und sie ist bezahlbar.

Quellen

• Ollama, Structured outputs (JSON-Schema, format): Link
• Ollama, Tool support (tools): Link
• llama.cpp, GBNF-Grammatiken: Link
• NVIDIA, Grammar-Constrained Decoding für kleine Modelle, Mai 2026: Link
• Berkeley Function-Calling Leaderboard: Link und Fachaufsatz (PMLR 2025)
• Qwen, Function Calling: Link
• DSK, Orientierungshilfe zu RAG-Systemen, Oktober 2025: PDF