Lokale Modelle im Alltag
Lokale Modelle sind das Lieblingsthema jeder Diskussion über Datenschutz und Kosten. Die Verlockung ist klar: kein Token-Preis, keine Daten, die das Haus verlassen, keine API, die ausfällt. Ich habe mir einen Monat lang angesehen, was davon im Alltag wirklich übrig bleibt – auf einem Apple-Silicon-Mac mit Ollama, mit echten Aufgaben statt Benchmarks.
Die Ausgangslage
Der entscheidende Faktor ist nicht das Modell, sondern der Speicher. Ein Modell muss als Gewichte vollständig in den RAM passen, sonst wird es unbenutzbar langsam. Auf einem Rechner mit 16 GB ist bei grob 8 bis 9 Milliarden Parametern Schluss, wenn das Betriebssystem und ein Browser gleichzeitig laufen sollen. Mit 32 GB kommen 14B-Modelle in Reichweite, mit 64 GB ein 32B-Modell – aber dann ist auch das meiste davon belegt.
Das ist die erste ehrliche Erkenntnis: Lokale Modelle sind eine Speicherfrage, keine Leistungsfrage. Der Chip ist fast immer schnell genug. Der RAM ist es nicht.
Was gut funktioniert
Es gibt eine Reihe von Aufgaben, bei denen lokale Modelle inzwischen ernsthaft mithalten – und zwar genau die, die keine brillante Sprachqualität brauchen, sondern Zuverlässigkeit:
- Extraktion. Namen, Daten, Preise aus unstrukturiertem Text ziehen. Ein 8B-Modell macht das sauber und schnell, bei null laufenden Kosten.
- Klassifizierung. „Welcher Kategorie gehört diese Anfrage zu?" Solche Aufgaben scheitern bei lokalen Modellen praktisch nie – und sie sind genau das, was in Automatisierungen am häufigsten vorkommt.
- Embeddings. Vektorisierung ist ohnehin eine eigene Modellklasse, die lokal laufen sollte. Sie ist mengenmäßig teuer über eine API und qualitativ identisch lokal.
- Kurze Zusammenfassungen. Eine Mail, ein Absatz, ein Ticket auf drei Sätze kürzen. Das ist gut genug, dass der Unterschied zur Cloud nicht auffällt.
Der gemeinsame Nenner: Alles, wo die Antwort eindeutig ist. Wo es eine richtige Lösung gibt, kein Spielraum für Stil.
Wo es auffällt
Und dann ist da die andere Seite. Sobald die Aufgabe verlangt, dass die Formulierung selbst das Produkt ist, wird der Unterschied sichtbar – und zwar schnell:
- Langes, verschachteltes Denken. Ein 8B-Modell verliert bei mehrschrittigen Schlussfolgerungen den Faden. Es klingt selbstbewusst, liegt aber subtil daneben – und der Fehler ist schwerer zu erkennen als ein offensichtlicher.
- Anweisungen über längere Texte. Je länger der Kontext, desto öfter wird eine Anweisung am Anfang schlicht vergessen. Die großen Cloud-Modelle halten da deutlich länger durch.
- Nuancierte Formulierungen. Ton, Zielgruppe, Feingefühl. Ein lokales Modell schreibt korrekt, aber flach. Für einen Blogbeitrag oder eine Kundenmail reicht mir das nicht.
Das Muster ist immer dasselbe: Lokale Modelle scheitern nicht mit Fehlern, sondern mit mittelmäßigen Antworten, die wie richtige aussehen. Das ist die gefährlichere Variante.
Die Zahlen, die ich gemessen habe
Geschwindigkeit ist selten das Problem. Ein 8B-Modell liefert auf einem aktuellen Apple-Silicon-Chip rund 40 bis 50 Token pro Sekunde – das ist für interaktive Nutzung völlig okay. Ein 14B-Modell liegt bei 20 bis 25. Erst bei den großen Modellen, die ohnehin nicht mehr in den Speicher passen, wird es langsam.
Was dagegen wirklich nervt, ist der erste Start. Ein Modell muss erst in den Speicher geladen werden, bevor es antwortet. Das sind je nach Größe 10 bis 30 Sekunden. Für einen einmaligen Aufruf pro Stunde ist das irrelevant, für ein Gefühl von Reaktionsfähigkeit im Alltag nicht.
Wie ich es jetzt aufteile
Nach einem Monat ist meine Grenze klar, und sie deckt sich mit dem, was ich schon länger predige – nur dass ich sie jetzt selbst gemessen habe:
- Lokal: Embeddings, Extraktion, Klassifizierung, kurze Zusammenfassungen. Die Fleißarbeit.
- Cloud: Alles, wo Sprachqualität oder langes Denken zählt. Der Blog, die Beratung, das mehrschrittige Schlussfolgern.
Diese Grenze ist keine Ideologie, sondern eine Kosten- und Qualitätsfrage. Ein 8B-Modell lokal zu betreiben kostet nichts, und für die Hälfte meiner Aufgaben reicht es völlig. Für die andere Hälfte wäre es der falsche Kompromiss – ich spare Token und zahle mit schlechteren Antworten.
Der eigentliche Gewinn des Monats war nicht ein bestimmtes Modell, sondern eine klarere Vorstellung davon, was ich überhaupt brauche. Lokale Modelle sind kein Ersatz für die Cloud. Sie sind ein Werkzeug für den Teil der Arbeit, bei dem die Cloud ohnehin überdimensioniert war.