Lokale KI: Kleines Modell trifft großes Cloud-Modell

Ich vergleiche fünf Sprachmodelle auf einem schmalen, aber sauber definierten Test-Set. Aufgabe: vier Klassen aus dem Mail-Eingang eines kleinen Betriebs strukturiert extrahieren. Projektanfrage, Rechnung, Bewerbung, Bestandskunden-Anfrage. Vierzehn anonymisierte Mails als Fixtures, fünf Modelle, fünf Durchläufe pro Modell, siebzig Calls insgesamt.

Ergebnis vorne: Ein 12-Milliarden-Parameter-Modell trifft auf diesen vierzehn Mails so gut wie ein 70-Milliarden-Parameter-Modell. Auch dann, wenn ich das 12B lokal in 4-Bit-Quantisierung auf einer normalen CPU laufen lasse. Ohne Cloud, ohne API-Schlüssel, ohne Verarbeiter-Vertrag.

Dieser Artikel beschreibt, was ich gemessen habe, was die Messung nicht beweist, und was sich daraus für Architektur-Entscheidungen ableiten lässt. Ein zweiter Teil liefert inzwischen die GPU-Werte nach.

Cloud-Lauf

Die Cloud-Baseline läuft über OVH AI Endpoints. Fünf Modelle, jedes Modell fünfmal über die vierzehn Fixtures, zusammen siebzig Calls.

Modell	Treffer	Halluzinationen	Schema-Brüche	Latenz gesamt	Kosten
Mistral-Nemo 12B	14/14	0	0	39 s	$0,0010
gpt-oss 20B	14/14	0	0	51 s	$0,0013
Llama 3.3 70B (Baseline)	13/14*	0	0	–	–
Llama 3.1 8B	13/14	0	1	–	–
Qwen 3.5 9B	unbrauchbar	–	–	–	–

*Der angebliche eine Treffer beim 70B-Modell ist ein False Positive der Substring-Heuristik im Test-Code, kein Modell-Fehler. Heißt: 70B erreicht in der Sache 14/14, der Test hat einmal falsch markiert.

Latenz und Kosten habe ich nur dort gemessen, wo ein Modell durchgängig 14/14 lieferte. Bei Schema-Brüchen ist der Vergleich nicht aussagekräftig.

Zwei Beobachtungen zählen mehr als die Zahlen.

Erstens: Qwen 3.5 9B ist unbrauchbar, obwohl die Treffer-Quote auf den ersten Blick mithalten würde. Das Modell ist auf “denken vor antworten” trainiert und schreibt seinen Reasoning-Prozess vor die eigentliche Antwort, statt ihn separat zu halten. Damit landet Prosa im JSON-Output und sprengt das Schema. Für eine Pipeline, die nachgelagert strukturierte Felder weiterverarbeitet, ist das ein hartes Aus, unabhängig von der semantischen Qualität.

Zweitens: Llama 3.1 8B liefert einen echten Schema-Bruch. Nicht halluziniert, sondern strukturell daneben. Ab der 12-Milliarden-Klasse stabilisiert sich das. Größere Modelle bringen bei dieser Aufgabe semantisch nichts dazu, kosten aber mehr Latenz und mehr API-Geld.

Wichtig: Vierzehn Fixtures sind ein kleines Test-Set. Ich schreibe deshalb “14/14 auf diesem Set”, nicht “99 % Genauigkeit”. Eine Prozent-Aussage wäre auf dieser Basis Augenwischerei.

Lokal-Lauf

Den 12B-Schritt habe ich danach lokal wiederholt. Ollama, Mistral-Nemo 12B in 4-Bit-Quantisierung (Format Q4_K_M, der gängige Sweetspot für lokale Inferenz), etwa 7,5 GB Modell auf der Platte. CPU-Only, kein GPU-Fallback.

Ergebnis: 14/14 Treffer, null Halluzinationen, null Schema-Brüche. Gleiches Ergebnis wie das Modell in der Cloud, gleiches Ergebnis wie die 70B-Baseline.

Was das nicht heißt: dass die 4-Bit-Quantisierung verlustfrei ist. Was es heißt: dass auf vierzehn Fixtures der Q4-Drop nicht messbar war. Bei tausend Fixtures, bei feindlichen Eingaben, bei einer anderen Domäne kann das Bild ganz anders aussehen. Das ist keine Universal-Aussage, sondern eine Aussage über dieses Test-Set.

Die Latenz ist die andere Seite. 244 Sekunden pro Mail auf der CPU. Das ist kein Tagesbetrieb, das ist ein Beleg, dass das Modell läuft. Eine Aussage über GPU-Praxis liefert ein folgender Blog.

Nebenbei wird der Datenschutz-Teil deutlich entspannter: keine Cloud-Verarbeiter-Kette, kein Drittland-Transfer, kein Streit über AVV-Klauseln. Die juristischen Details bleiben trotzdem Aufgabe von Kunde und Anwalt.

Architektur

Das Mess-Setup lebt in einem internen Java-Repo, das ich nicht öffentlich machen werde. Die Strukturen sind aber generisch genug, um sie hier zu skizzieren.

Spring AI als gemeinsame Schnittstelle. Ein ChatClient für die Anwendungsschicht, dahinter zwei austauschbare Backends. Eines spricht OVH AI Endpoints, eines spricht Ollama lokal. Schema-Validierung an der Grenze, bevor das Ergebnis weitergereicht wird. Gleiche Fixtures, gleicher Prompt, gleiche Validierung, unterschiedliches Backend.

public interface MailExtractor {
    ExtractionResult classify(MailFixture mail);
}

@Component
class SpringAiMailExtractor implements MailExtractor {

    private final ChatClient chatClient;
    private final SchemaValidator validator;

    public ExtractionResult classify(MailFixture mail) {
        String json = chatClient.prompt()
                .user(promptFor(mail))
                .call()
                .content();
        return validator.parseOrFail(json);
    }
}

Welches Backend hinter dem ChatClient hängt, ist Konfigurations-Sache. Profil cloud gegen Profil local. Die Fachschicht weiß davon nichts. Diese Trennung ist der Grund, warum derselbe Test gegen alle fünf Modelle und gegen den lokalen Ollama-Lauf ohne Code-Änderung läuft.

Was im Artikel bewusst nicht landet: die konkreten Prompts, die Test-Fixtures, der Validator-Code. Der interessante Punkt für eine Architektur-Diskussion ist die Adapter-Linie und die Schema-Validierung an der Grenze, nicht die Implementierung darunter.

Dass derselbe Fixture-Lauf gegen fünf Cloud-Modelle und gegen den lokalen Ollama-Lauf ohne eine Zeile Code-Änderung durchläuft, ist kein Zufall. Es ist die Adapter-Trennung. Wer beim KI-Einbau diese Trennung weglässt, sitzt beim ersten Modellwechsel wieder am Code, statt an der Konfiguration.

Limitationen

Die Mess-Daten oben sind ein Datenpunkt, kein Beweis.

Vierzehn Fixtures sind statistisch klein. Niemand hat versucht, das Modell mit kreativ feindlichen Eingaben zu kippen. Dass 14 von 14 strukturiert sauber rauskommen, sagt nichts darüber, wie sich das Modell bei der hundertsten ungewöhnlichen Mail verhält.

244 Sekunden pro Mail auf der CPU sind kein Tagesbetrieb-Argument. Das war nie der Punkt. Der Punkt war: läuft es überhaupt mit dieser Qualität? Tokens-pro-Sekunde unter realen GPU-Bedingungen liefert der Folge-Blog.

Andere Domänen sind nicht getestet. Vertragsanalyse, Code-Review, Spracherkennung, Bildverarbeitung. Aus einem 14/14-Treffer auf strukturierter Mail-Klassifikation lässt sich nicht ableiten, dass dasselbe Modell auch ein Steuerbescheid auseinander nimmt. Was übertragbar ist, ist die Methode: definiertes Test-Set, gleicher Adapter, gleicher Validator, vergleichbare Mess-Werte. Was nicht übertragbar ist, ist das Ergebnis selbst.

Q4-Quantisierung mag bei vierzehn Mails verlustfrei aussehen. Bei tausend Mails, in einer anderen Domäne oder mit gezielten Edge-Cases kann sich das Bild verschieben. Das ist eine offene Frage, keine geschlossene Antwort.

Eine andere Linie betrifft den Aufgaben-Zuschnitt. Wenn das Ziel ist, Bewerbungen und Rechnungen aus einem Posteingang zu ziehen, muss das Modell nicht die Welt verstehen, sondern nur diesen schmalen Korridor. Rechnungen eines Stammkunden haben in der Regel ein wiederkehrendes Format, Bewerbungen folgen vorhersehbaren Mustern. Je enger der Korridor, desto kleiner darf das Modell sein, ohne dass die Treffer-Quote leidet. Die offene Frage ist nicht “reicht 12B?”, sondern “wie eng kann ich die Aufgabe schneiden?”.

Was die Messung gar nicht abdeckt, ist die Frage einer Lern-Schleife. Heute ist die Pipeline statisch: Prompt, Modell und Validator stehen fest, der Kunde lebt mit dem, was die aktuelle Konfiguration kann. Spannender wäre ein semi-selbstlernender Aufbau. Eine Mail wird nicht erkannt, der Kunde kippt sie in eine Korrektur-Queue, ein größeres Modell prüft im Hintergrund: war der Prompt zu eng, ist das kleine Modell überfordert, oder fehlt nur eine Spielart des Formats? Das System korrigiert daraufhin Prompt-Template oder Modell-Auswahl, der Kunde sieht beim nächsten Mal das richtige Ergebnis. Das ist angedacht, nicht gemessen.

Folge-Blog

Die GPU-Werte sind inzwischen da: Teil 2 misst dasselbe Modell auf einer gebrauchten RTX 3060 und beantwortet die Tempo-Frage, samt der Stellen, an denen kleine lokale Modelle leise falsch werden.

---

Wer eine ähnliche Adapter-Architektur baut oder über Modell-Auswahl pro Schnittstelle nachdenkt, kann sich melden. Kennenlernen, austauschen, gemeinsam weiterdenken.