In den letzten achtzehn Monaten hat sich die häufigste Frage unserer Enterprise-Kunden umgekehrt. Sie lautet nicht mehr „Können wir generative KI einsetzen?“, sondern deutlich spezifischer: „Können wir diese Dokumente verarbeiten, ohne dass sie unseren Perimeter verlassen?“.
Die Frage ist legitim, und sie hat heute für einen erheblichen Teil der Anwendungsfälle eine technisch solide Antwort. Möglich gemacht haben das drei Faktoren zusammen: kompakte Modelle, die endlich brauchbar sind, ein Tooling, das so weit gereift ist, dass ein gewöhnliches IT-Team es betreiben kann, und ein wachsender regulatorischer Druck (GDPR, AI Act, NIS2, branchenspezifische Anforderungen im Gesundheits- und Finanzsektor), der die Datengrenze zu einem Governance-Thema macht, nicht zu einer Frage technischer Vorlieben. Dieser Artikel versucht, das Signal vom Rauschen zu trennen.
Destillation und Quantisierung — ohne Mythologie
Die Zugänglichkeit lokaler Modelle beruht auf zwei unterschiedlichen, oft verwechselten Techniken. Die Destillation trainiert ein kompaktes „Schülermodell“ darauf, das Verhalten eines viel größeren „Lehrermodells“ zu reproduzieren: keine verlustfreie Kompression, sondern ein selektiver Kompetenztransfer. Das Ergebnis verhält sich deutlich besser, als die Größe vermuten ließe — bleibt aber ein Modell mit 3–8 Milliarden Parametern. Die Quantisierung reduziert dagegen die numerische Präzision der Gewichte, typischerweise von 16 auf 4–5 Bit (Formate wie GGUF): Der Speicherbedarf sinkt auf rund ein Viertel, bei marginalen Einbußen in den meisten Anwendungs-Tasks.
Was selten gesagt wird: Der Qualitätsverlust ist nicht gleichmäßig verteilt. Eng umrissene, überprüfbare Tasks — Entitätsextraktion, Klassifikation, extraktive Zusammenfassung, Datennormalisierung — halten sehr gut stand; langes mehrstufiges Schlussfolgern und Analysen über sehr große Kontexte fallen deutlich ab. Die gestalterische Konsequenz ist einfach: Man entwirft für den Task, nicht für den Benchmark. Ein 7B-Modell, das drei definierte Anwendungsfälle gut löst, ist mehr wert als ein Generalist, der zwanzig mittelmäßig löst.
Der minimale Stack — und was fast immer fehlt
Die Runtime. Ollama hat sich als De-facto-Standard für die lokale Ausführung etabliert: Es verwaltet Download, Versionen und die Bereitstellung der Modelle per API, mit einer Erfahrung, die an Docker erinnert — exzellent für Einzelnutzer und Piloten; für Multi-User-Serverszenarien sollte man von Anfang an durchsatzorientierte Runtimes wie vLLM in Betracht ziehen, denn in der Produktion ist der Engpass nicht der Speicher, sondern die gleichzeitigen Anfragen.
Der Kontext. Ein lokales Modell kennt das Unternehmen von sich aus nicht: Es braucht eine Retrieval-Schicht, die Dokumente, Wikis und Tickets indexiert und dem Modell die relevanten Passagen übergibt. Leichtgewichtige Implementierungen wie LightRAG machen diese Schicht ohne schwere Infrastruktur zugänglich. Und es lohnt sich, hier deutlich zu sein: In den meisten Dokumentenprojekten hängt die Qualität mehr vom Retrieval ab als vom Modell — wir haben ausführlich darüber geschrieben, und es ist dieselbe Lektion, die uns unsere eigene Plattform gelehrt hat, die genau auf diesen Komponenten aufbaut: Ollama, vLLM, LightRAG.
Die Anpassung. Werkzeuge wie Unsloth haben das Fine-Tuning mit LoRA/QLoRA-Techniken auf bescheidener Hardware praktikabel gemacht. Der operative Rat lautet jedoch, es als dritte Option zu betrachten, nicht als erste: zuerst der Prompt, dann das Retrieval — und nur wenn beide messbar scheitern, führt man ein Artefakt ein, das versioniert und bei jedem Wechsel des Basismodells neu erprobt werden muss.
Was in den Tutorials fehlt. Zwischen einem Proof of Concept und einem Unternehmenssystem liegt eine Schicht, die in den Anleitungen nicht vorkommt: Identität und Berechtigungen (der Index muss die Berechtigungen des Nutzers respektieren), Logging, kontinuierliche Qualitätsbewertung, ein Prozess für Modell-Updates. Genau hier konzentriert sich der größte Teil der realen Kosten.
Drei Szenarien, in denen lokale KI wirklich funktioniert
1 · Vor-Triage von Dokumenten mit vertraulichen Daten. Verträge, HR-Akten, klinische Dokumentation, Versicherungsvorgänge. Das Modell entscheidet nicht: Es extrahiert, klassifiziert, markiert auffällige Klauseln und bereitet die Arbeit für einen menschlichen Prüfer vor. Der Wert liegt in der eingesparten Lesezeit; das Risiko bleibt begrenzt, weil der Output stets überprüft wird.
2 · Semantische Suche im internen Wissensbestand. Protokolle, technische Dokumentation, Ticket-Historie: Abfragen in natürlicher Sprache über Archive, die niemand mehr per Ordnerstruktur durchdringen kann. Auch hier leistet das Retrieval die Hauptarbeit; das Modell fasst zusammen.
3 · Entwicklungsassistenz in isolierten Umgebungen. Verteidigung, kritische Infrastrukturen, zertifizierte Umgebungen: Der proprietäre Code verlässt das Repository nicht, und oft existiert schlicht keine Verbindung nach außen. Hier ist lokale KI keine Optimierung — sie ist die einzige Option.
Hinzu kommt ein viertes, wachsendes Szenario: der Betrieb am Edge — Baustellen, Anlagen, entlegene Standorte —, wo die Konnektivität intermittierend ist und Zuverlässigkeit mehr zählt als die marginale Qualität der Antwort.
Wo sich lokale KI nicht lohnt
Ehrlichkeit an diesem Punkt unterscheidet eine technische Bewertung von einer Marketingkampagne. Ausgedehntes Schlussfolgern — komplexe vergleichende Analysen, Synthesen über Dutzende heterogener Dokumente, Text in redaktioneller Qualität — bleibt das Terrain der Frontier-Modelle, und diese Lücke schließt keine Quantisierung. Nicht dimensionierte Multi-User-Lasten: Ein Modell, das auf dem Laptop in zwei Sekunden antwortet, kann bei zehn gleichzeitigen Anfragen zwanzig brauchen; dimensioniert wird nach dem Durchsatz, nicht nach dem Speicher. Und die versteckten Gesamtkosten: Ein nicht aktualisiertes lokales Modell ist technische Schuld — es braucht regelmäßige Neubewertungen, Regressionstests und jemanden, der sich darum kümmert. Unterhalb einer gewissen Volumenschwelle bleibt die API deutlich günstiger als der Eigenbetrieb.
Hardware dimensionieren: Faustregeln
- Faustregel: Für ein auf 4 Bit quantisiertes Modell beträgt der benötigte Speicher in GB etwa die Milliarden Parameter × 0,6 — plus Platz für das Kontextfenster.
- Apple Silicon: Der einheitliche Speicher hilft — mit 16 GB lassen sich 7–8B-Modelle betreiben, mit 32–64 GB geht es hinauf bis 14–32B.
- Dedizierte GPU: 8–12 GB VRAM decken die Klasse 7–8B bei interaktiver Geschwindigkeit gut ab.
- Nur CPU: geeignet für nächtliche Batch-Verarbeitung, deutlich weniger für synchrone Interaktion.
- Gemeinsamer Server: Eine GPU mit 24–48 GB bedient etwa zehn gleichzeitige Nutzer auf 7–8B-Modellen. Ab zwanzig Personen ist das fast immer effizienter — auch im Betrieb — als die Installation auf jedem Endpoint.
Drei Fragen zur Entscheidung (und die Architektur, die daraus folgt)
Drei Fragen, in dieser Reihenfolge: Dürfen die Daten den Perimeter verlassen? (eine organisatorische Frage, bevor sie eine technische ist); Ist der Task eng umrissen und überprüfbar? (wer nicht sagen kann, was eine korrekte Antwort ist, dem rettet keine Infrastruktur das Projekt); Rechtfertigt das Volumen die Infrastruktur? (unterhalb bestimmter Schwellen ist die API die rationale Wahl).
In den meisten Fällen ist die Antwort nicht binär, und die sinnvollste Architektur ist hybrid: eine Routing-Schicht, die Anfragen mit vertraulichen Daten an das lokale Modell leitet — im dedizierten Perimeter — und alles Übrige an die Cloud, mit expliziten, nachvollziehbaren Richtlinien. Die Datensouveränität wird zu einer Eigenschaft des Systems, nicht zu einem funktionalen Verzicht.
Ein Einführungsfahrplan in 90 Tagen
Wochen 1–3 · Perimeter. Datenklassifizierung und Auswahl von zwei realen Anwendungsfällen, jeweils mit einem fachlichen Ansprechpartner. Wochen 4–8 · Praxistest. Ein funktionierender Prototyp und vor allem ein Evaluationsset: 30–50 reale Fälle mit der erwarteten Antwort — die am meisten unterschätzte Investition, die eine Erfolgsmessung von einem Eindruck unterscheidet. Wochen 9–12 · Pilot. Freigabe für 10–20 Nutzer, Metriken, dokumentierte Entscheidung: ausweiten, korrigieren oder stoppen.
Fazit
Lokale KI ersetzt die Cloud nicht und ist keine Universalantwort. Sie löst elegant eine klar definierte Klasse von Problemen: Die Daten dürfen sich nicht bewegen, der Task ist eng umrissen, Überprüfbarkeit zählt mehr als Brillanz. Für diese Klasse — die in regulierten Organisationen alles andere als marginal ist — ist die Technologie reif, läuft auf Hardware, die oft schon im Haus ist, und lässt sich in einem Quartal mit überschaubarem Aufwand bewerten. Der Rest ist, wie immer, eine Frage der Architektur: Wenn Sie sie mit einem Mindestmaß an Ernsthaftigkeit angehen wollen, sprechen wir darüber.
