Lokale Sprachmodelle erklärt: was Open-Weight-Modelle können und was sie verlangen

01

Was ist ein lokales Sprachmodell, und was läuft dabei im eigenen Haus?

Ein lokales Sprachmodell besteht aus einer Datei mit trainierten Gewichten und einer Laufzeitumgebung, die daraus Antworten berechnet. Beide laufen auf Hardware, die Sie kontrollieren, im eigenen Rechenzentrum oder bei einem Hoster Ihrer Wahl. Anfragen, Dokumente und Antworten verlassen diese Umgebung nicht. Von außen kommen nur Modell- und Software-Updates, wenn Sie sie holen.

Ein großes Sprachmodell ist im Kern eine sehr große Menge gelernter Zahlen, der Gewichte. Eine Laufzeitumgebung lädt sie in den Speicher einer GPU, zerlegt Anfragen in Token und berechnet die Antwort Token für Token. "Lokal" beschreibt deshalb keine Modelleigenschaft, sondern eine Architekturentscheidung: Wo liegen Gewichte, Laufzeit, Anfragen und Protokolle, und wer entscheidet über Änderungen?

Ob lokal oder Cloud besser passt, entscheidet sich an Datenlage, Last und gewünschter Kontrolle, wie On-Premise vs. Cloud-LLM ausführt. Wie das Modell in ein Wissenssystem mit Suche, Rechten und Pflege eingebettet wird, zeigt Wissensmanagement mit KI.

02

Sind Open-Weight-Modelle dasselbe wie Open Source?

Nein. Offene Gewichte bedeuten nur, dass die Parameter heruntergeladen werden können. Die Open Source AI Definition der Open Source Initiative verlangt zusätzlich die Freiheiten, das System zu nutzen, zu untersuchen, zu verändern und weiterzugeben, dazu den vollständigen Code sowie ausführliche Informationen über die Trainingsdaten. Ein Modell mit offenen Gewichten kann das erfüllen, muss es aber nicht.

Die Open Source Initiative hat ihre Definition für Open Source AI in Version 1.0 am 28. Oktober 2024 veröffentlicht (OSI, 2024). Sie überträgt die bekannten Freiheiten freier Software auf KI-Systeme: nutzen für jeden Zweck ohne Erlaubnis, untersuchen, verändern, auch in der Ausgabe, und weitergeben. Dafür verlangt sie drei Bestandteile: Informationen über die Trainingsdaten, die so detailliert sind, dass eine fachkundige Person ein im Wesentlichen gleichwertiges System bauen kann, den vollständigen Code für Training und Betrieb und die Modellparameter. Die Trainingsdaten selbst müssen nicht veröffentlicht werden.

Für den Betrieb zählt zunächst, dass die Gewichte vorliegen. Für Beschaffung und Compliance zählt der Lizenztext der konkreten Modellversion, denn manche Lizenzen knüpfen Bedingungen an Einsatzzweck, Nutzerzahl oder Veränderungen. Welche Klauseln vor einem Test geklärt werden sollten, beschreibt LLM-Vergleich und Modellauswahl. Eine Einordnung verbreiteter offener Modelle für deutsche Texte bietet der Beitrag Open-Weight-Modell fürs deutsche B2B.

03

Was ist Quantisierung, und was kostet sie an Qualität?

Quantisierung speichert die Gewichte eines Modells mit weniger Bits, etwa mit 8 oder 4 statt 16 Bit je Wert. Der Speicherbedarf der Gewichte sinkt dadurch auf die Hälfte oder ein Viertel, die Antworten kommen oft schneller. Der Qualitätsverlust ist bei moderater Stufe klein, wächst bei starker Kompression und trifft Sprachen und schwierige Aufgaben unterschiedlich stark.

Jedes Gewicht ist eine Kommazahl, im Training meist mit 16 Bit gespeichert. Quantisierung bildet diese Werte auf ein gröberes Raster ab, 256 Stufen bei 8 Bit oder 16 Stufen bei 4 Bit, und speichert je Gruppe von Gewichten einen Skalierungsfaktor, mit dem sich die Größenordnung zurückrechnen lässt. Die eigentliche Arbeit der Verfahren besteht darin, das Raster so zu legen, dass die für das Ergebnis wichtigen Werte wenig verlieren.

Die Forschung zeigt, wie weit das trägt. LLM.int8() (Dettmers et al., NeurIPS 2022) halbiert den Speicherbedarf für die Inferenz, indem wenige Ausreißer-Dimensionen in 16 Bit verbleiben, laut Paper ohne Genauigkeitsverlust bei Modellen bis 175 Milliarden Parametern. GPTQ und AWQ gehen weiter und drücken Gewichte nach dem Training auf wenige Bit, AWQ schützt dabei gezielt die wenigen besonders wichtigen Gewichte.

Für Anwendungen jenseits des Englischen ist eine vierte Arbeit wichtig. Marchisio et al. (EMNLP 2024) fanden, dass automatische Messungen den Schaden durch Quantisierung unterschätzen, dass Sprachen mit nicht-lateinischer Schrift am stärksten leiden und dass schwierige Aufgaben wie mathematisches Schließen schneller nachlassen als einfache. Englische Kennzahlen eines quantisierten Modells ersetzen deshalb keinen Test an deutschen Fachtexten mit menschlicher Stichprobe.

04

Wie viel Grafikspeicher braucht ein lokales Modell?

Der Grafikspeicher muss drei Posten aufnehmen: die Gewichte, deren Größe sich aus Parameterzahl mal Bytes je Parameter ergibt, den Zwischenspeicher für Schlüssel und Werte (KV-Cache), der mit Kontextlänge und Zahl gleichzeitiger Anfragen wächst, und einen Aufschlag für die Laufzeit. Bei langen Kontexten und vielen Nutzern übersteigt der KV-Cache schnell die Gewichte selbst.

Die folgende Rechnung nutzt ein hypothetisches Modell, damit die Zahlen nicht mit einer Modellversion veralten. Die Annahmen sind ausdrücklich genannt, sodass Sie sie durch die Werte aus der Konfigurationsdatei Ihres Kandidaten ersetzen können. Ein Gigabyte meint hier eine Milliarde Byte.

• Parameter: 30 Milliarden
• Schichten: 64
• Schlüssel-Wert-Köpfe: 8 mit je 128 Dimensionen (gruppierte Aufmerksamkeit, siehe unten)
• KV-Cache: 16 Bit, also 2 Byte je Wert
• Gewichte: quantisiert auf effektiv 4,5 Bit je Parameter, das halbe Bit deckt Skalierungsfaktoren ab
• Laufzeitaufschlag: pauschal 2 GB für Aktivierungen und Verwaltung

Gewichte     = Parameter x Bits je Parameter / 8
             = 30.000.000.000 x 4,5 / 8            = ca. 16,9 GB

KV je Token  = 2 (Schluessel und Wert) x Schichten x KV-Koepfe x Kopfdimension x Bytes
             = 2 x 64 x 8 x 128 x 2                 = 262.144 Byte, ca. 0,26 MB

KV gesamt    = KV je Token x Kontextlaenge x gleichzeitige Anfragen
             = 262.144 x 8.000 x 4                  = ca. 8,4 GB

Summe        = Gewichte + KV gesamt + Laufzeitaufschlag
             = 16,9 + 8,4 + 2                       = ca. 27 GB

Zwei Einsichten folgen daraus. Erstens verdoppelt eine doppelte Kontextlänge oder Parallelität den KV-Cache, während die Gewichte gleich bleiben. Zweitens rechnet die Architektur mit: Gruppierte Aufmerksamkeit (Grouped-Query Attention, Ainslie et al., EMNLP 2023) teilt Schlüssel und Werte auf weniger Köpfe auf, verkleinert den Cache entsprechend und erreicht laut Paper eine Qualität nahe an voller Mehrkopf-Aufmerksamkeit. Zahl der Schichten und der KV-Köpfe stehen in der Konfigurationsdatei jedes Modells.

Welche Hardwareklassen zu welchen Modellgrößen passen, ordnet Lokales LLM im Unternehmen: Hardware, Kosten, Realität ein.

05

Wie wird ein lokales Modell für Anwendungen bereitgestellt?

Ein lokales Modell wird über einen Inferenz-Server bereitgestellt, der Anfragen annimmt, mehrere gleichzeitig bündelt und die Antwort Token für Token zurückstreamt. Anwendungen sprechen ihn über eine HTTP-Schnittstelle an, verbreitet ist ein Format, das zu gängigen Chat-Schnittstellen gehosteter Dienste kompatibel ist. So lässt sich das Modell austauschen, ohne die Anwendung umzuschreiben.

Die beiden Rechenphasen belasten die Hardware unterschiedlich. Beim Vorbefüllen verarbeitet das Modell den gesamten Kontext parallel, das bestimmt die Wartezeit bis zum ersten Token. Beim Erzeugen entsteht jedes weitere Token einzeln, und jeder Schritt greift erneut auf Gewichte und wachsenden Cache zu. Ein Server, der viele Anfragen in gemeinsamen Durchgängen bündelt, nutzt die GPU dabei deutlich besser als einer, der sie nacheinander abarbeitet.

Wie viel Speicher verloren geht, hängt an der Verwaltung des KV-Caches. PagedAttention (Kwon et al., SOSP 2023) verwaltet ihn in Blöcken nach dem Vorbild der virtuellen Speicherverwaltung in Betriebssystemen, erreicht laut Paper nahezu keinen Verschnitt und steigert den Durchsatz verbreiteter Modelle bei gleicher Latenz auf das Zwei- bis Vierfache. Der daraus entstandene Server vLLM bietet laut Dokumentation Endpunkte, die mit der Chat-Completions-Schnittstelle von OpenAI kompatibel sind.

GGUF ist laut Spezifikation des GGML-Projekts ein Binärformat, das Tensoren und Metadaten in einer einzigen Datei ablegt und für schnelles Laden, auch per Speicherabbildung, ausgelegt ist. Für den Betrieb mit vielen Nutzern zählen dagegen Bündelung, Cache-Verwaltung und Überwachung.

06

Was verlangt der Betrieb eines lokalen Modells auf Dauer?

Der Dauerbetrieb verlangt vier Dinge: festgehaltene Modell- und Softwareversionen, damit Ergebnisse nachvollziehbar bleiben, Messungen von Latenz, Durchsatz, Speicher und Antwortqualität, einen geprüften Weg für Updates von Modell und Laufzeit und eine Absicherung, denn ein ungeschützter Inferenz-Server ist ein offener Rechendienst im Netz. Diese Arbeit beginnt nach der Installation.

1. Versionen festhalten

   Modelldatei mit Prüfsumme, Laufzeitversion, Quantisierungsstufe und Konfiguration gehören in die Versionsverwaltung. Nur so lässt sich eine veränderte Antwort auf eine Ursache zurückführen.

2. Testsatz pflegen

   Echte Aufgaben mit geprüften Sollergebnissen laufen vor jedem Wechsel von Modell, Quantisierung oder Laufzeit. Wie man sie aufbaut, beschreibt KI-Antworten prüfen.

3. Betrieb messen

   Zeit bis zum ersten Token, Token je Sekunde, Speicherauslastung, Länge der Warteschlange und Fehlerquote zeigen, wann die Hardware an ihre Grenze kommt.

4. Updates bewusst einspielen

   Neue Modellversionen werden in einer Testumgebung gegen den Testsatz geprüft und erst danach übernommen. Sicherheitsupdates der Laufzeit bekommen einen eigenen, kürzeren Weg.

5. Zugriff absichern

   Der Server ist nur intern erreichbar, verlangt Authentifizierung und protokolliert Zugriffe ohne personenbezogene Inhalte. Wer welche Antworten sehen darf, klärt Berechtigungen in KI-Wissenssystemen.

Einen strukturierten Überblick über Risiken und Gegenmaßnahmen im gesamten Lebenszyklus generativer Modelle, von der Planung bis zum Betrieb, gibt das Bundesamt für Sicherheit in der Informationstechnik in der Publikation "Generative KI-Modelle: Chancen und Risiken für Industrie und Behörden" (BSI, 2025).

07

Wann ist ein gehostetes Modell die bessere Wahl?

Ein gehostetes Modell ist die bessere Wahl, wenn die Aufgabe ein Leistungsniveau verlangt, das auf verfügbarer Hardware nicht erreichbar ist, wenn die Last stark schwankt oder selten anfällt, wenn niemand den Betrieb übernehmen kann oder wenn die Daten unkritisch sind. Häufig trägt eine Aufteilung: vertrauliche Aufgaben lokal, unkritische über einen Dienst.

Mischformen und ihre Kriterien vertiefen On-Premise und Offline-LLM und KI mit EU-Datenresidenz. Dass ein gehostetes Spitzenmodell auch kurzfristig vom Markt verschwinden kann, beschreibt ein Signal zur Lektion über operative Kontrolle.

08

Welche verbreiteten Annahmen über lokale Modelle stimmen nicht?

Mehrere verbreitete Annahmen halten einer Prüfung nicht stand: dass offene Gewichte eine freie Lizenz bedeuten, dass das größte passende Modell die sichere Wahl ist, dass Quantisierung nichts kostet, dass lokal automatisch sicher heißt und dass ein installiertes Modell ohne laufende Arbeit auskommt. Jede davon führt zu einer falschen Beschaffung oder zu einem schlecht betreuten System.

Für Modelle, die Werkzeuge aufrufen, gelten zusätzliche Anforderungen, beschrieben in KI-Agenten in der Wissensarbeit.

09

Wie beginnt man mit einem lokalen Sprachmodell?

Man beginnt mit einer eng umrissenen Aufgabe und einem Testsatz aus echten Beispielen, nicht mit der Hardware. Zwei oder drei offene Kandidaten verschiedener Größe laufen gegen diesen Testsatz, zunächst in einer einfachen Laufzeit. Erst wenn Qualität und Speicherrechnung stehen, folgen Server-Laufzeit, Absicherung und die Auswahl passender Hardware.

1. Aufgabe und Datenklasse festlegen: Welche Anfragen, welche Dokumente, welche Vertraulichkeit.
2. Testsatz bauen: Echte Aufgaben mit geprüften Sollergebnissen, schwierige Fälle eingeschlossen, auf Deutsch.
3. Kandidaten vergleichen: Zwei oder drei offene Modelle unterschiedlicher Größe und Quantisierung unter gleichen Bedingungen.
4. Speicher rechnen: Mit den Werten aus der Modellkonfiguration, der Kontextlänge und der erwarteten Parallelität.
5. Betrieb aufsetzen: Server-Laufzeit, Authentifizierung, Kennzahlen, Versionsverwaltung und ein erprobter Rückweg.

iiterate Technologies GmbH entwickelt KI-Anwendungen und Individualsoftware von der Architektur über die Umsetzung bis zum Betrieb, auf Kundeninfrastruktur oder in EU-Hosting, mit Schwerpunkten auf lokalen Sprachmodellen, RAG und der Anbindung an Bestandssysteme (Leistungen).