📈SEO

Lokale KI-Modelle

Nicht jede KI muss in die Cloud. Wann lokale Modelle mit Ollama die richtige Wahl sind, was die Hardware können muss und wo die Qualitätsgrenzen liegen.

FDT
FJ Design Team
KI & Automatisierung
15. Juli 20268 Min.

Wenn die Daten das Haus nicht verlassen dürfen

Eine Steuerkanzlei möchte eingehende Belege automatisch vorsortieren und Mandantenschreiben zusammenfassen lassen. Die Testläufe mit einem Cloud-Modell verlaufen vielversprechend, dann meldet sich der Datenschutzbeauftragte: Mandantendaten, Gehaltsabrechnungen und Kontoauszüge an einen externen KI-Dienst zu senden, sei ohne Weiteres nicht vertretbar, unabhängig davon, wie gut die Auftragsverarbeitungsverträge formuliert sind. Das Projekt scheint tot, bis in einer Besprechung jemand die entscheidende Frage stellt: Muss die KI überhaupt in der Cloud laufen, oder geht das auch bei uns im Haus?

Die Antwort lautet immer öfter: nein. Leistungsfähige Sprachmodelle mit offenen Gewichten, also Modelle, deren trainierte Parameter frei heruntergeladen werden dürfen, haben in den letzten Jahren enorm aufgeholt. Werkzeuge wie Ollama machen den Betrieb auf eigener Hardware so einfach wie die Installation eines gewöhnlichen Programms: Software installieren, Modell mit einem Befehl herunterladen, und wenige Minuten später beantwortet ein Sprachmodell Anfragen auf dem eigenen Rechner oder Server, über eine lokale Programmierschnittstelle, die sich fast wie die der großen Cloud-Anbieter anspricht. Kein Datenpaket verlässt dabei das Haus, keine Zeile Text, kein Dokument, keine Metadaten, und genau das verändert die Ausgangslage vieler Projekte grundlegend. Für viele mittelständische Szenarien ist das keine Notlösung, sondern eine bewusste Architekturentscheidung, allerdings eine mit klaren Voraussetzungen und ehrlichen Kompromissen, die man kennen sollte.

Wann lokal die richtige Wahl ist

Der häufigste Grund für lokale Modelle ist der Datenschutz im weitesten Sinne. Wenn Berufsgeheimnisse im Spiel sind, wie bei Kanzleien, Arztpraxen oder Steuerberatern, wenn Betriebsgeheimnisse wie Konstruktionsdaten und Kalkulationen verarbeitet werden oder wenn Compliance-Vorgaben und Kundenverträge die Weitergabe von Daten an Dritte untersagen, ist ein Modell, das vollständig im eigenen Netz läuft, die einfachste Antwort auf viele schwierige Fragen. Statt seitenlanger Prüfungen von Auftragsverarbeitung, Drittlandtransfer und Unterauftragnehmern lautet das Argument schlicht: Die Daten verlassen das Haus nicht.

Der zweite Grund ist Unabhängigkeit vom Internet. Produktionsumgebungen ohne zuverlässige Anbindung, Systeme auf Maschinen und Fahrzeugen oder schlicht der Wunsch, bei einem Ausfall des Cloud-Anbieters arbeitsfähig zu bleiben, sprechen für den Offline-Betrieb. Ein lokales Modell kennt keine Störung beim Anbieter, keine Drosselung und keine plötzliche Abkündigung einer Modellversion, es läuft, bis Sie es abschalten. Diese Planbarkeit hat auch eine strategische Seite: Wer seine Prozesse auf ein konkretes Cloud-Modell aufgebaut hat, ist von den Produktentscheidungen des Anbieters abhängig, von Preisänderungen bis zur Einstellung ganzer Modellreihen. Ein lokal gespeichertes Modell mit offenen Gewichten kann Ihnen dagegen niemand nachträglich wegnehmen oder verändern, es bleibt exakt so reproduzierbar, wie Sie es abgenommen haben, was auch für Dokumentations- und Nachweispflichten ein angenehmer Nebeneffekt ist.

Der dritte Grund ist wirtschaftlicher Natur: kalkulierbare Kosten bei hohem Durchsatz. Cloud-Modelle rechnen pro verarbeiteter Textmenge ab, was bei kleinen Volumina günstig und flexibel ist. Wer aber täglich zehntausende Dokumente klassifiziert, Texte anonymisiert oder Protokolle zusammenfasst, zahlt Monat für Monat weiter, und die Rechnung wächst mit dem Erfolg. Eine einmal angeschaffte Maschine mit passender Grafikkarte verursacht dagegen fixe Kosten plus Strom, egal ob sie tausend oder eine Million Anfragen verarbeitet. Ab einem gewissen Volumen kippt die Rechnung zugunsten der eigenen Hardware, vor allem bei gleichförmigen Massenaufgaben, die kein Spitzenmodell erfordern.

Hardware: was realistisch nötig ist

Die zentrale Größe beim Betrieb lokaler Modelle ist der Speicher, in den das Modell geladen wird, idealerweise der Grafikspeicher (VRAM) einer GPU, ersatzweise der Arbeitsspeicher des Systems. Als grobe Faustregel für gängige, komprimierte Modellvarianten, sogenannte quantisierte Modelle, bei denen die Genauigkeit der Parameter zugunsten des Speicherbedarfs reduziert wird: Ein kleines Modell mit rund 7 bis 8 Milliarden Parametern begnügt sich mit etwa 5 bis 8 Gigabyte Speicher und läuft damit auf einem besseren Business-Notebook oder einem Mac mit 16 Gigabyte RAM ordentlich. Mittlere Modelle mit 20 bis 30 Milliarden Parametern wollen grob 16 bis 24 Gigabyte sehen, hier wird eine dedizierte Grafikkarte oder ein Mac mit viel gemeinsamem Speicher sinnvoll. Die großen offenen Modelle mit 70 Milliarden Parametern und mehr verlangen 40 Gigabyte aufwärts und damit Workstation- oder Server-Hardware, oft mit mehreren GPUs.

Neben dem Speicher zählt die Geschwindigkeit: Auf reiner CPU laufen kleinere Modelle zwar, aber spürbar zäh, für flüssiges Arbeiten und erst recht für mehrere gleichzeitige Nutzer führt an einer GPU kaum ein Weg vorbei. Für erste Gehversuche gilt trotzdem: Sie brauchen keinen Serverschrank. Ein vorhandener Rechner mit 16 Gigabyte RAM reicht, um mit Ollama und einem kleinen Modell realistisch zu erproben, ob die Qualität für Ihren Anwendungsfall genügt. Erst wenn das bejaht ist, lohnt die Investition in dedizierte Hardware, dimensioniert am tatsächlichen Bedarf statt am Maximalausbau.

#

Betrieb ist mehr als Installation

Wer vom Experiment in den Teambetrieb wechselt, übernimmt Aufgaben, die beim Cloud-Anbieter unsichtbar miterledigt werden. Ein lokaler Modellserver braucht einen Verantwortlichen: Jemand muss Updates von Ollama und den Modellen einspielen, den Speicherplatz im Blick behalten, die Maschine in die Datensicherung und das Monitoring aufnehmen und regeln, wer im Netzwerk auf die Schnittstelle zugreifen darf. Gerade der letzte Punkt wird gern übersehen: Eine offene, unauthentifizierte Modell-Schnittstelle im Firmennetz ist ein Einfallstor, also gehört davor ein Zugriffsschutz, etwa ein vorgeschalteter Proxy mit Schlüsselverwaltung. Auch die Modellwahl selbst ist Pflege: Die offene Modelllandschaft entwickelt sich schnell, und ein halbjährlicher Vergleichslauf mit den eigenen Testfällen zeigt, ob ein neueres Modell bei gleichem Speicherbedarf spürbar mehr leistet. Nichts davon ist Raketentechnik, aber es ist laufender Aufwand, der in die ehrliche Kostenrechnung gehört, neben Anschaffung und Strom.

Der ehrliche Blick auf die Qualität

So erfreulich die Fortschritte offener Modelle sind, ein nüchterner Vergleich gehört dazu: Die großen Cloud-Modelle der führenden Anbieter sind den lokal betreibbaren Modellen in der Spitze weiterhin überlegen, besonders bei komplexem mehrstufigem Schlussfolgern, bei anspruchsvollen Programmieraufgaben, bei sehr langen Dokumenten und in Randsprachen. Ein 8-Milliarden-Parameter-Modell auf Ihrem Notebook wird einem Frontier-Modell aus der Cloud nicht das Wasser reichen, und wer das erwartet, wird enttäuscht.

Die entscheidende Frage ist aber nicht, ob das lokale Modell das beste verfügbare ist, sondern ob es für die konkrete Aufgabe gut genug ist. Und da fällt die Antwort oft überraschend positiv aus: Texte klassifizieren, Informationen aus strukturierten Dokumenten ziehen, E-Mails zusammenfassen, Formulierungen glätten, Inhalte übersetzen, all das erledigen mittelgroße offene Modelle heute auf einem Niveau, das für viele Geschäftsprozesse völlig ausreicht. Je enger und klarer die Aufgabe umrissen ist, desto kleiner darf das Modell sein. Wichtig ist, diese Eignung nicht zu raten, sondern zu messen: mit einem kleinen Satz repräsentativer Testfälle, den man gegen das lokale und ein Cloud-Modell laufen lässt und ehrlich vergleicht. Manchmal zeigt der Test, dass die Cloud nötig ist, oft genug zeigt er das Gegenteil.

Zwei weitere Stellschrauben verschieben die Qualitätsgrenze zu Ihren Gunsten. Erstens die Aufgabenzerlegung: Statt einem kleinen Modell eine komplexe Gesamtaufgabe zu stellen, zerlegt man sie in einfache Einzelschritte, erst klassifizieren, dann extrahieren, dann formulieren, und jeder Schritt liegt wieder komfortabel im Können des Modells. Zweitens die Anbindung eigener Wissensquellen: Ein lokales Modell, das relevante Dokumentauszüge mitgeliefert bekommt, statt aus dem Gedächtnis antworten zu müssen, wirkt schnell deutlich kompetenter, denn die Schwäche kleiner Modelle liegt eher im Weltwissen als im Umgang mit vorgelegtem Text. Beide Techniken kosten nichts außer Konzeptarbeit und holen aus bescheidener Hardware erstaunlich viel heraus.

Das hybride Muster: lokal anonymisieren, Cloud nutzen

Besonders elegant ist eine Kombination beider Welten, die sich in der Praxis bewährt hat: Ein lokales Modell übernimmt die datenschutzkritische Vorarbeit, die eigentliche Schwerstarbeit erledigt danach ein leistungsfähiges Cloud-Modell, das aber nur noch bereinigte Daten zu sehen bekommt. Konkret: Das lokale Modell liest das Originaldokument und ersetzt alle personenbezogenen und sensiblen Angaben durch Platzhalter, aus "Herr Michael Berger, Kontonummer DE89..." wird "PERSON1, KONTO1". Diese anonymisierte Fassung geht an die Cloud-KI, die daraus etwa eine fundierte Analyse oder einen komplexen Antwortentwurf erstellt. Zum Schluss setzt Ihr System die Platzhalter lokal wieder in die Originalwerte zurück, die Zuordnungstabelle hat das Haus nie verlassen.

Dieses Muster verbindet das Beste beider Seiten: die Vertraulichkeit der lokalen Verarbeitung mit der Qualität der großen Modelle, und es hält die Cloud-Kosten klein, weil nur das anspruchsvolle Teilstück dorthin wandert. Es eignet sich für Kanzleien ebenso wie für Personalabteilungen oder den Kundenservice mit sensiblen Vorgängen, und es lässt sich schrittweise einführen: Man startet mit einer Dokumentklasse, misst die Erkennungsquote der Anonymisierung an von Hand geprüften Beispielen und weitet den Einsatz erst aus, wenn die Quote überzeugt. Wichtig bleibt Sorgfalt bei der Anonymisierung selbst: Auch sie sollte mit Testfällen geprüft werden, denn ein übersehener Name im Fließtext untergräbt das ganze Konzept, und für besonders heikle Daten empfiehlt sich eine zusätzliche regelbasierte Prüfschicht hinter dem Modell.

Fazit: Standortfrage mit klaren Kriterien

Lokale KI-Modelle sind erwachsen geworden. Wo Daten das Haus nicht verlassen dürfen, wo offline gearbeitet wird oder wo hoher Durchsatz die Token-Rechnung explodieren ließe, sind sie die richtige Wahl, sofern die Aufgabe zur realistischen Qualität mittelgroßer Modelle passt. Für die Spitzenklasse an Denkleistung bleibt die Cloud gesetzt, und hybride Muster wie die lokale Anonymisierung schlagen die Brücke zwischen beiden Welten. Drei nächste Schritte: Installieren Sie Ollama auf einem vorhandenen Rechner und testen Sie ein kleines Modell mit zehn echten, unkritischen Beispielaufgaben aus Ihrem Alltag. Klären Sie parallel mit Datenschutz und Compliance, welche Ihrer KI-Anwendungsfälle zwingend lokale Verarbeitung erfordern. Und rechnen Sie für Ihre volumenstärkste KI-Aufgabe einmal ehrlich Cloud-Kosten gegen Hardware-Invest. Wenn Sie dabei einen Sparringspartner brauchen: FJ Design unterstützt Unternehmen bei Auswahl, Aufbau und Absicherung solcher KI-Architekturen.

Lokale KIOllamaDatenschutzOpen-Source-ModelleOn-PremiseCompliance
Teilen:

Fragen zu diesem Thema?

Lassen Sie uns gemeinsam besprechen, wie wir diese Strategien für Ihr Unternehmen umsetzen können.

Kostenlos beraten lassen