Lokale KI ist kein Spielzeug mehr. ChatGPT ohne Cloud ist sie trotzdem nicht

Dokumente gelangen in eine kompakte Maschine mit einem neuronalen Netz und verlassen sie als strukturierte Daten.

Ein Unternehmen darf bestimmte Daten nicht an einen externen Dienst schicken. Es besitzt Berichte, Akten oder interne Dokumente, die klassifiziert, zusammengefasst oder in strukturierte Informationen überführt werden sollen. Immer häufiger stellt sich dieselbe Frage: Können wir ein KI-Modell auf einem eigenen Rechner installieren und die Arbeit dort erledigen?

Die ehrliche Antwort ist unbequemer. Für eine klar begrenzte Aufgabe —Dokumente klassifizieren, Felder extrahieren oder eine erste Zusammenfassung erstellen— kann sie ja lauten. Für ein „privates ChatGPT“, das auf einem gewöhnlichen Laptop fast alles mit derselben Qualität und Geschwindigkeit erledigt, lautet sie meistens nein.

Zwischen diesen Extremen liegt ein Bereich, der schnell wächst. Ein lokal ausgeführtes Modell ist nicht automatisch gut genug, schnell genug oder rechtskonform. Für einen praktischen Nutzen ist heute aber auch keine Labormaschine mehr zwingend nötig.

Modelle, die vor Kurzem noch riesig wirkten, passen quantisiert auf eine Consumer-GPU. Andere Modelle mit vier bis zwölf Milliarden Parametern erledigen auf einem Laptop klar abgegrenzte Dokumentenaufgaben mit echtem geschäftlichem Wert.

Zwei von Apple im August angekündigte Rechner zeigen die Spannweite des Begriffs besonders deutlich. Der Mac mini mit M6 bietet bis zu 32 GB Unified Memory; der Mac Studio mit M5 Ultra bis zu 512 GB und 1,2 TB/s Speicherbandbreite. Der eine deckt kleine und mittlere Modelle ab, der andere kann Gewichte mit Hunderten Milliarden Parametern im Speicher halten. Der Vergleich zeigt, warum „führt KI lokal aus“ noch keine ausreichende Beschreibung für eine Architekturentscheidung ist.

Die Frage lautet nicht mehr, ob KI lokal laufen kann. Sie lautet: Welche Aufgabe, mit welcher Fehlerquote, auf welchen Daten und in welcher Geschwindigkeit?

Was lokale Modellausführung tatsächlich bedeutet

Beim Training lernt ein Modell Millionen oder Milliarden numerischer Werte, die Gewichte genannt werden. Sie sind das Ergebnis des Lernens: kleine numerische Anpassungen, die zusammen bestimmen, wie das Modell auf eine Eingabe reagiert. Das Training eines allgemeinen Modells benötigt weiterhin enorme Infrastruktur. Inferenz ist etwas anderes: Die bereits gelernten Gewichte werden geladen und verwendet, ohne das Modell erneut zu trainieren.

Wird ein Open-Weight-Modell heruntergeladen und mit llama.cpp, Ollama oder LM Studio geöffnet, kann die Inferenz vollständig auf dem eigenen Gerät stattfinden. Der Text muss nicht an die Server des Modellentwicklers gesendet werden. Für einen Test ähnelt das der Installation einer Anwendung: Programm laden, Modell auswählen, loslegen.

Unter lokal werden allerdings häufig drei verschiedene Betriebsformen zusammengefasst:

  • On-Device: Das Modell läuft auf Laptop oder Smartphone einer Person.
  • On-Premises: Es läuft auf einem Server unter Kontrolle der Organisation.
  • Private Cloud: Die Infrastruktur ist entfernt, aber isoliert und wird unter den Bedingungen des Unternehmens betrieben.

Alle drei können den Versand an eine öffentliche API vermeiden, bieten aber nicht dieselben Garantien. Eine lokale Anwendung kann Verläufe speichern, Komponenten nachladen, Telemetrie senden oder Ordner in ein externes Backup synchronisieren. Das Modell kann im Büro stehen, während OCR, Vektordatenbank oder Observability weiterhin außerhalb betrieben werden.

Lokale Inferenz beschreibt den Ausführungsort des Modells, nicht den gesamten Weg der Daten.

Dass ein Modell läuft, macht den Prozess noch nicht tragfähig

Für einen konkreten Prozess sind drei unterschiedliche Fragen zu beantworten:

  1. Passen Modell und realer Kontext in die kontrollierte Infrastruktur?
  2. Sind Latenz und Parallelität für das erwartete Arbeitsvolumen akzeptabel?
  3. Erfüllt das Ergebnis die festgelegte Qualitäts- und Fehlerschwelle?

Nur die erste Frage lässt sich aus dem Speicherbedarf ableiten. Sie beweist, dass das Modell geladen werden kann, nicht dass der Prozess nützlich ist.

Die erste Frage lässt sich abschätzen. Ein Modell mit 27 Milliarden Parametern belegt ungefähr 54 GB, wenn für jedes Gewicht 16 Bit —16 Binärziffern— reserviert werden. Quantisierung spart Platz, indem diese Werte mit weniger Detail dargestellt werden. Das ähnelt dem Runden von Millionen Zahlen: Das Modell wird kleiner und verliert dafür etwas Genauigkeit. Bei 4 Bit sinkt der theoretische Wert auf etwa 13,5 GB; reale Datei und Ausführung benötigen etwas mehr.

Qwen 3.8 27B zeigt diese Verschiebung deutlich. Die Originalgewichte belegen 55,6 GB. Eine von Simon Willison verwendete Q4-Version —mit ungefähr vier Bit pro Gewicht quantisiert— ist etwa 17 GB groß und kann auf persönlicher Hardware Bilder analysieren, Code erzeugen und andere Tools um Aktionen bitten. Das heißt nicht, dass 17 GB Gesamtspeicher genügen: Anwendung, Betriebssystem, Zwischenberechnungen und Kontext brauchen ebenfalls Platz.

Das Kontextfenster verdient besondere Aufmerksamkeit. Es bezeichnet die Textmenge, die das Modell beim Antworten im Blick behalten kann, gemessen in Tokens: Wortfragmenten, in die es den Text zerlegt. Ein Modell kann 128.000 oder 256.000 Tokens angeben und sie auf einem Laptop dennoch nicht sinnvoll nutzen. Mit der Unterhaltung muss es mehr Speicher für diese Fragmente reservieren und braucht länger, um die gesamte Eingabe einzulesen. Der maximale Kontext im Datenblatt ist nicht der operative Kontext des Systems.

Latenz und die Fähigkeit, mehrere Anfragen zu bedienen, hängen stark von der Speicherbandbreite ab. Die Kapazität entscheidet, ob die Gewichte hineinpassen; die Bandbreite, wie schnell der Prozessor sie lesen kann. Das ist der Unterschied zwischen der Größe eines Bücherregals und der Geschwindigkeit, mit der sich Bücher daraus holen lassen. Während der Generierung muss ein großer Teil der Gewichte immer wieder bewegt werden. Deshalb antwortet eine GPU mit schnellem Speicher meist deutlich schneller als eine CPU, auch wenn beide genug Kapazität haben. Der Unified Memory von Apple Silicon und einigen AMD-Prozessoren lässt CPU und GPU denselben Pool teilen. Eine dedizierte NVIDIA-GPU ist häufig schneller, aber durch ihren eigenen Speicher, den VRAM, begrenzt.

llama.cpp kann ein Modell auch zwischen CPU und GPU aufteilen. Das ist für einen Versuch nützlich; das Nachladen aus dem RAM über den Bus kann die Geschwindigkeit jedoch so stark reduzieren, dass das Ergebnis für einen interaktiven oder parallelen Prozess nicht mehr aussagekräftig ist.

Diese Größen helfen festzulegen, welche Art von Versuch in einer Umgebung sinnvoll sein kann:

Im Umfeld verfügbarer SpeicherQuantisierte Modelle, die meist hineinpassenWas sich damit evaluieren lässt
16 GB ohne dedizierte GPU2B–8B; 12B mit engen EinstellungenKlassifikation, einfache Extraktion und die Machbarkeit eines Offline-Ablaufs. Lange Dokumente können auf CPU langsam sein.
32 GB RAM oder Unified Memory8B–14B komfortabel; 20B–27B mit KompromissenQualität auf echten Dokumenten, RAG —vor der Antwort relevante Passagen aus der eigenen Dokumentation suchen— und strukturierte Ausgaben bei begrenzter Parallelität.
GPU mit 12–16 GB VRAM8B–14B vollständig auf GPU; einige MoE um 20BInteraktive Latenz und moderater Kontext. 27B braucht meist stärkere Quantisierung oder CPU-Offload.
GPU mit 24 GB VRAM20B–32B in 4 BitOb eine leistungsfähigere Klasse die Fehler genug reduziert, um Latenz und Betriebskosten zu rechtfertigen.
64–128 GB Unified Memory oder mehrere GPUs70B und einige größere MoE mit aggressiver QuantisierungRobustheit, Kontext und komplexe Aufgaben in dedizierter Infrastruktur, mit stark architekturabhängiger Leistung.
192–512 GB Unified Memory oder Multi-GPU-ServerModelle über 100B und große quantisierte MoEEine technische Workstation-Grenze, kein Ausgangspunkt für die Gestaltung eines Unternehmensprozesses.

Kompakte Rechner mit 128 GB Unified Memory wie NVIDIA DGX Spark oder Systeme mit Ryzen AI Max+ 395 können deutlich größere Modelle laden. NVIDIA nennt bis zu 200B Parameter, AMD hat 128B-Modelle gezeigt. Das belegt Speicherkapazität, nicht automatisch eine interaktive Erfahrung: Ein 100B-Modell zu laden und es den ganzen Tag nutzen zu wollen sind zwei verschiedene Probleme.

Apples neue Baureihe hilft ebenfalls, Kapazität und Geschwindigkeit zu trennen. Der Mac mini M6 bietet bis zu 32 GB und 170 GB/s; der M5 Pro im selben Format erreicht 64 GB und 307 GB/s. Der Mac Studio M5 Ultra steigt auf 512 GB und 1,2 TB/s. Ein neuerer Chip hebt die physische Grenze nicht auf: Wenn die Gewichte nicht hineinpassen, passen sie nicht hinein. Apple kündigte die Geräte am 25. August 2026 an und liefert sie ab dem 22. September aus. Die M5-Ultra-Werte sind daher bislang Herstellerangaben und keine unabhängige Nutzererfahrung.

Dieselbe Fähigkeit benötigt immer weniger Infrastruktur

Die Parameterzahl allein misst Intelligenz längst nicht mehr ausreichend. Qualität und Zusammensetzung der Daten, Architektur, Post-Training, Reinforcement Learning und zusätzlicher Rechenaufwand für schwierige Anfragen spielen ebenfalls eine Rolle.

Auch die Modellgeneration zählt. Der Stanford AI Index nennt einen anschaulichen Vergleich: 2022 hatte das kleinste Modell mit mehr als 60 Prozent in MMLU 540B Parameter. 2024 erreichte Phi-3 Mini denselben Wert mit 3,8B – 142-mal weniger. MMLU bildet keine echte Unternehmensarbeit ab, die Verschiebung der Grenze ist dennoch erheblich.

Epoch AI schätzt, dass algorithmische Fortschritte den Rechenaufwand für ein bestimmtes Leistungsniveau vortrainierter Sprachmodelle ungefähr alle acht Monate halbierten. Die Unsicherheit ist groß und ein erheblicher Teil des Fortschritts stammt weiterhin aus mehr Daten und Rechenleistung. Trotzdem erklärt das, warum ein aktuelles 8B-Modell kaum mit einem 8B-Modell von vor zwei Jahren vergleichbar ist.

Effizienz entsteht auf mehreren Wegen:

  • bessere Daten und besseres Post-Training holen mehr aus jedem Parameter;
  • Quantisierung reduziert Speicher und Bandbreite, mit je nach Modell und Aufgabe unterschiedlichem Qualitätsverlust;
  • Mixture-of-Experts-Architekturen teilen das Modell in spezialisierte Gruppen und nutzen pro Token nur einige davon, obwohl alle geladen bleiben müssen;
  • spekulative Dekodierung lässt einen günstigeren Mechanismus mehrere Tokens vorschlagen, die das Hauptmodell prüft;
  • Programme zur Modellausführung nutzen GPUs, Unified Memory und NPUs besser; NPUs sind Chips, die KI-Operationen beschleunigen;
  • spezialisierte Modelle verzichten auf Universalität und lösen eine einzelne Funktion mit weniger Ressourcen.

MoE-Modelle verursachen ein weiteres Missverständnis. gpt-oss-20b besitzt insgesamt 21B Parameter, nutzt für jedes Token aber nur rund 3,6B. Es arbeitet jeweils mit einem Teil des Modells, muss aber das gesamte Modell im Speicher halten: Die quantisierte Gewichtsdatei belegt weiterhin 12,8 GB, OpenAI nennt etwa 16 GB Systemspeicher als Minimum. Für Gemma 4 26B A4B gilt dasselbe: 4B werden pro Token genutzt, aber alle 26B müssen geladen bleiben, damit das System schnell die beteiligten Gruppen auswählen kann.

Welche Aufgaben einen Test wert sind

Benchmarks, standardisierte Tests zum Vergleich von Modellen, helfen beim Aussortieren und zeigen Fortschritte. Sie beantworten schlechter, ob ein System zwanzig Felder aus unseren Berichten korrekt extrahiert, über 10.000 Dokumente hinweg dasselbe Ausgabeformat einhält oder sich enthält, wenn eine Information fehlt.

Die praktische Grenze ist ungleichmäßig:

Ungefähre ModellklasseSinnvolle Aufgaben für einen TestZu messende Risiken
2B–4BKlassifikation, Umformulierung, einfache Extraktion, Autovervollständigung, lokale Befehle und sehr wiederholbare AufgabenLange Anweisungen, Mehrdeutigkeit, mehrstufiges Denken und Genauigkeit über lange Dokumente
8B–14BZusammenfassungen, strukturierte Extraktion, Entwürfe, RAG, Fragen zu Dokumentation, Analyseskripte und einfache VisionLange Tool-Abläufe, seltene Ausnahmen und Entscheidungen mit verlässlichem Expertenwissen
20B–32BKompetenter Allzweckassistent, Code in begrenzten Repositories, Vision, Tools und mehrstufige AnalyseLang laufende Agenten, Geschwindigkeit auf bescheidener Hardware und Zuverlässigkeit der besten Hosted-Systeme
70B oder mehrMehr Robustheit bei offenen, komplexen AufgabenKosten, Latenz, Betrieb und weiterhin überzeugend formulierte Fehler

Diese Bereiche überschneiden sich. Ein für eine Klassifikation angepasstes 4B-Modell kann ein allgemeines 27B schlagen. Ein großes Modell mit ungeeigneter Quantisierung, falschem Chat-Template oder zu wenig Kontext kann schlechter sein als ein gut betriebenes kleines Modell.

Aktuelle Modelle helfen, diese Bereiche zu verankern; sie ersetzen die Evaluation nicht.

Gemma 4 12B benötigt laut Google etwa 6,7 GB für Q4-Gewichte, bevor Kontext und Runtime hinzukommen. Es akzeptiert Text, Bild und Audio; Google zeigt lokale Dateianalyse auf einem Rechner mit 16 GB. Das belegt, dass ein multimodaler Prototyp auf gängiger Hardware Platz findet. Es belegt nicht, dass er unser Schema, unsere Tools und unsere Ausnahmen zuverlässig beherrscht.

gpt-oss-20b passt in ungefähr 16 GB, verarbeitet nur Text und ist auf Reasoning, strukturierte Ausgaben und Tools ausgerichtet. Seine MoE-Architektur ist für die Gesamtgröße relativ rechenleicht. Für kontrollierte Prozesse kann es attraktiv sein, braucht aber eine Integration, die die Tools tatsächlich implementiert. Die Gewichte allein fügen keine Suche, Codeausführung oder Dateizugriffe hinzu.

Qwen 3.8 27B ist eine nützliche Referenz für die Klasse 20B–32B. Es ist multimodal, steht unter Apache 2.0 und passt mit einer Quantisierung von etwa 17 GB auf eine 24-GB-GPU oder in ausreichend Unified Memory. In Willisons Tests untersuchte es ein Repository, baute und testete ein Hilfsprogramm, lokalisierte Objekte in Bildern und steuerte einen Coding-Agenten, mit 15 bis 30 Tokens pro Sekunde —ein Maß dafür, wie schnell die Antwort erscheint, nicht für ihre Intelligenz. Das zeigt reale Fähigkeit; die Prozesszuverlässigkeit muss weiterhin an den eigenen Fällen gemessen werden.

DeepSeek V4 Flash zeigt das andere Extrem: eine technische Demonstration, die von sehr bestimmter Hardware, Quantisierung und Runtime abhängt. Es ist ein MoE mit insgesamt 284B Parametern, etwa 13B aktiven Parametern pro Token und einem angekündigten Kontextfenster von einer Million Tokens. Eine experimentelle MLX-Quantisierung mit 2,44 Bit belegt 92,8 GB und erreichte bei kurzem Kontext auf einem MacBook Pro M5 Max mit 128 GB etwa 32 bis 36 Tokens pro Sekunde, allerdings mit spürbarem Qualitätsverlust gegenüber dem gehosteten Modell. Varianten nahe vier Bit liegen bei ungefähr 150 bis 170 GB. Das ist kein lokales Standardmodell, sondern ein Beleg dafür, wie weit eine Workstation heute reichen kann.

Die beiden Beispiele stehen für unterschiedliche Entscheidungen, die der Begriff „lokale KI“ leicht miteinander vermischt.

Auch die Community-Rückmeldungen sind aufschlussreich. Einige Nutzer berichten von Abläufen mit Dutzenden Tool-Aufrufen auf einer RTX 3090. Andere sehen das Modell eher auf dem Niveau eines guten Hosted-Modells der Mittelklasse als bei den Frontier-Systemen und finden relevante Fehler im erzeugten Code. Diese Streuung entsteht gerade durch unterschiedliche Aufgaben, Prompts, Quantisierungen, Runtimes und Tools, die eine eigene Evaluation festlegen muss.

Für ein Unternehmen zählt am Ende nur eine eigene Testsuite mit echten Fällen, einschließlich seltener Fälle und teurer Fehler.

Beispiel: Medizinische Berichte innerhalb der Organisation analysieren

Angenommen, das Ziel ist keine Diagnose, sondern die Umwandlung heterogener Berichte in überprüfbare Felder: Datum, Fachgebiet, Medikamente, durchgeführte Untersuchungen und erwähnte Vorgeschichte.

Ein Prototyp kann einen PDF-Upload in eine lokale Anwendung mit anschließender Zusammenfassung bieten. Ein operatives System muss Verantwortlichkeiten trennen. Zuerst wandelt OCR Seiten, die nur als Bild vorliegen, in Text um; anschließend liefert das Modell die Felder als JSON, ein strukturiertes Format, das der Rest der Software lesen und prüfen kann:

Dokument
   ↓
lokale OCR und Textextraktion
   ↓
lokales Modell → JSON + Belegstellen für jedes Feld
   ↓
deterministische Prüfungen
   ↓
menschliche Prüfung von Fehlern und Zweifelsfällen
   ↓
führendes System der Organisation

Das System muss dem Modell erlauben, bei fehlenden Angaben null zurückzugeben, und Belegstellen verlangen. Daten, Codes und Formate werden anschließend mit konventionellen Regeln validiert, die bei denselben Daten immer dasselbe Ergebnis liefern. Zweifelsfälle gelangen über externe Prüfungen zur Revision, nicht allein aufgrund der Sicherheit, mit der das Modell antwortet. Eine repräsentative Stichprobe misst Präzision und insbesondere False Negatives: Informationen, die im Bericht standen, aber vom System nicht erkannt wurden.

Bei stabilem Schema und vorhersehbaren Dokumenten kann ein 8B- oder 12B-Modell genügen. 27B kann komplexe Anweisungen und Ausnahmen besser bearbeiten, reduziert aber Geschwindigkeit und Parallelität. Die Infrastruktur zu dimensionieren, bevor die Fehlertoleranz bekannt ist, kehrt die richtige Reihenfolge um: Zuerst den tolerierbaren Fehler festlegen, dann das kleinste Modell testen, das ihn einhält.

Das Beispiel zeigt auch: Datenschutz hängt nicht nur vom LLM ab. OCR, temporärer Speicher, Logs, Oberfläche, Backups und Zielsystem müssen ebenfalls geprüft werden.

Lokale Ausführung reduziert eine Exposition, schafft aber keine Rechtsausnahme

Bleiben Daten in kontrollierter Infrastruktur, sinkt ein wesentliches Risiko: die Übergabe an einen Dritten. Die französische CNIL empfiehlt bei personenbezogenen Daten oder sensiblen Dokumenten, sichere und spezialisierte lokale Lösungen zu erwägen. Sie sagt nicht, dass eine lokale Installation Compliance erledigt.

Personenbezogene Daten bleiben personenbezogene Daten, auch ohne Internet. Die Organisation benötigt weiterhin einen bestimmten Zweck, eine Rechtsgrundlage, Datenminimierung, Aufbewahrungsfristen, Zugriffskontrollen, Sicherheit und Verfahren für Betroffenenrechte. Gesundheitsdaten fallen zusätzlich unter die besonderen Kategorien des Artikels 9 DSGVO. Abhängig von Umfang, Risiko und Nutzung kann eine Datenschutz-Folgenabschätzung erforderlich sein.

Drei rechtliche Ebenen sind zu trennen:

  1. Modelllizenz. Herunterladbare Gewichte sind nicht bedingungslos. Qwen 3.8 und Gemma 4 verwenden Apache 2.0; gpt-oss kombiniert Apache 2.0 mit einer Nutzungsrichtlinie. Andere Modelle haben Community-Lizenzen, Weitergabebeschränkungen oder Verbotskataloge. Eine Quantisierung von Dritten muss die passende Lizenz erhalten und dokumentieren.
  2. Schutz der Eingabedaten. Die DSGVO richtet sich nach Zweck und Verarbeitung, nicht nach dem Herstellungsland der GPU. Verläufe, Embeddings —numerische Darstellungen von Dokumenten, die für ihre Suche verwendet werden— und Protokolle von Anweisungen können ebenfalls personenbezogene Daten enthalten.
  3. Regulierung von System und Einsatz. Der AI Act klassifiziert nach vorgesehenem Zweck. Dokumente zur Unterstützung eines Menschen zusammenzufassen ist nicht dasselbe wie eine Behandlung zu empfehlen oder Medizinsoftware zu sein. Medizinprodukte, Sicherheitskomponenten oder Systeme in bestimmten Entscheidungen können Hochrisiko- und sektorspezifischen Pflichten unterliegen.

Auch die Ausnahme für bestimmte freie und quelloffene Software ist keine allgemeine Erlaubnis. Verbotene, hochriskante oder transparenzpflichtige Systeme werden nicht gleichermaßen ausgenommen.

Bei medizinischen, arbeitsrechtlichen, finanziellen oder juristischen Anwendungen muss die Prüfung das gesamte System und seinen Zweck erfassen. Nicht nur „Welche Lizenz hat Qwen?“, sondern „Welche Entscheidung trifft unser Prozess, mit welchen Daten, und wer trägt die Verantwortung?“.

Heruntergeladene Gewichte sind kein Produktionssystem

Ein Chatfenster zu öffnen ist einfach. Die Arbeit danach ist es nicht.

Ein Unternehmen braucht je nach Fall Authentifizierung, Nutzerrechte, Verschlüsselung, Netzwerkisolation, Secret-Management, Warteschlangen, Limits, auditierbare Spuren, Modellupdates, Regressionstests und Rollback. Teilen mehrere Personen eine Workstation, muss auch Parallelität dimensioniert werden: Eine Maschine, die eine Unterhaltung gut bedient, kann bei zehn einbrechen.

Open-Weight-Modelle bringen meist weniger Produkt mit. ChatGPT ist nicht nur eine Gewichtsdatei, sondern enthält Suche, Tools, Filter, Ausführungsumgebung, Kontextverwaltung, Infrastruktur und Updates. Lokal muss jemand diese Teile auswählen, bauen und betreiben.

Diese Kontrolle ist Teil des Werts. Eine Version kann fixiert, Netzwerkverkehr verhindert, jeder Aufruf beobachtet und unnötige Funktionalität entfernt werden. Die Kosten verlagern sich jedoch vom Tokenpreis auf Hardware, Strom, Integration, Sicherheit und Betrieb.

Wann es in die Architektur passt

Lokale Inferenz ist meist sinnvoll, wenn mehrere Bedingungen zusammentreffen:

  • Daten sind sensibel oder unterliegen strengen Residenz- und Kontrollanforderungen;
  • die Aufgabe ist klar definiert und mit echten Beispielen messbar;
  • ein lokales Modell erreicht die nötige Qualität, auch wenn es nicht das beste verfügbare Modell ist;
  • das Volumen ist stabil und groß genug, um die Hardware auszulasten;
  • Offline-Betrieb, geringe Netzwerklatenz oder eine fixierte Version haben Wert;
  • die Organisation kann das System und seine Updates betreiben.

Weniger sinnvoll ist es bei sporadischer Nutzung, wenn stets maximale Leistung oder aktuelles Wissen nötig ist oder niemand die Infrastruktur pflegen kann. Eine sauber vertraglich geregelte Enterprise-API kann sicherer sein als ein improvisierter lokaler Server. Physischer Standort ersetzt keine gute Architektur.

Oft entsteht ein hybrides Design. Ein kleines Modell klassifiziert, formuliert oder entfernt identifizierende Informationen lokal. Schwierige Fälle wechseln zu einem größeren Modell in einer privaten Cloud oder, sofern rechtlich möglich, zu einem externen Dienst. Dokumentenabruf bleibt lokal; nur das Nötige wird eskaliert.

Die Entscheidung ist keine ideologische Wahl zwischen Cloud und Souveränität, sondern eine Architekturentscheidung anhand von Risiko, Qualität, Latenz und Gesamtkosten.

Was sich tatsächlich verändert

Der wichtigste Trend ist nicht, dass ein Laptop das beste Modell der Welt ausführt. Frontier-Modelle werden ebenfalls größer, nutzen mehr Rechenarbeit pro Antwort und integrieren Systeme, die kein Laptop nachbilden kann.

Entscheidend ist: Das Leistungsniveau, das einem Unternehmen genügt, passt jedes Jahr in ein kleineres Modell.

Mehr Modelle werden von Anfang an für Geräte entwickelt: wenige aktive Parameter, Quantisierung im Training, kleinere Kontextspeicher und die Vorhersage mehrerer Tokens zugleich. Hersteller erhöhen gemeinsamen Speicher und Bandbreite. Inferenzprogramme nutzen GPU und NPU besser, ohne dass jedes Projekt hardwarespezifische Optimierungen entwickeln muss.

Zudem werden wir weniger generische lokale Chats und mehr unsichtbare Produktfunktionen sehen: Vorfälle klassifizieren, Rechnungsdaten extrahieren, Dokumentation durchsuchen, Antworten vorbereiten oder Meetings transkribieren und ordnen. Ein kleines Modell, das eine Aufgabe vorhersehbar löst, kann wertvoller sein als ein allgemeiner Assistent, der in einer Demo beeindruckt.

Für Unternehmen ist der architektonische Effekt besonders interessant. Ein Teil der Inferenz rückt näher an die Daten und wird zu einer Anwendungsschicht. Größere Modelle bleiben der Eskalationsweg für Ausnahmen – so wie heute nicht jede Verarbeitung an dieselbe Datenbank oder denselben Dienst geht.

Lokale Inferenz beseitigt die schwierigen Probleme der KI nicht. Sie verändert, welches zuerst erscheint. Wir müssen nicht mehr mit der Frage beginnen, ob eine Maschine das Modell ausführen kann. Wir können mit der Frage anfangen, die immer zuerst hätte kommen sollen:

Welchen konkreten Teil des Prozesses sollten wir diesem Modell anvertrauen – und wie erkennen wir, wenn es falsch liegt?

Quellen

Zurück zum Blog