Die Frage, ob man Sprachmodelle in der Cloud nutzt oder selbst betreibt, wird in vielen Häusern zuerst als Datenschutzfrage gestellt: Dürfen Verträge, Personalakten oder Konstruktionsdaten in einen fremden Dienst? Wer sie mit Nein beantwortet, landet bei offenen Modellen auf eigener Hardware. Werkzeuge wie Ollama haben das in den vergangenen Jahren so einfach gemacht, dass ein Modell auf einem Arbeitsplatzrechner in wenigen Minuten läuft. Für den Einsatz im Unternehmen stellt sich danach die zweite Frage: Welche Hardware trägt das Modell, wenn nicht einer, sondern zwanzig Menschen damit arbeiten?
Die Faustregel
Ein Sprachmodell antwortet schnell, wenn es vollständig im Speicher der Grafikkarte liegt. Wie viel Speicher das ist, hängt vor allem von zwei Größen ab: der Zahl der Parameter, angegeben in Milliarden, und der Genauigkeit, mit der jeder Parameter gespeichert wird. Hugging Face formuliert in seinem Leitfaden zur Optimierung großer Sprachmodelle eine Faustregel: Ein Modell mit X Milliarden Parametern braucht in 16-Bit-Genauigkeit rund 2 × X Gigabyte Grafikspeicher für die Gewichte. Ein Modell mit acht Milliarden Parametern also rund 16 GB, eines mit siebzig Milliarden rund 140 GB.
Die gute Nachricht folgt im selben Leitfaden: Gewichte lassen sich auf 8 oder 4 Bit verringern, ohne dass die Leistung deutlich sinkt. Im Beispiel von Hugging Face braucht ein Modell mit rund 15 Milliarden Parametern in voller 16-Bit-Genauigkeit rund 32 GB, in 8 Bit rund 15 GB und in 4 Bit gut 9 GB. Für die meisten lokalen Einsätze ist eine 4-Bit-Fassung deshalb ein guter Ausgangspunkt.
Was die Faustregel nicht enthält
Die Gewichte sind nur ein Teil des Bedarfs. Während das Modell arbeitet, braucht es zusätzlich Speicher für die Eingabe und das bisher Erzeugte, den sogenannten Key-Value-Cache. Er wächst mit der Länge der Eingaben. Hugging Face zeigt am selben Beispiel, dass dieser Speicher bei langen Eingaben rund die Hälfte dessen erreichen kann, was die Gewichte selbst brauchen. Wer also lange Verträge oder ganze Handbücher in das Modell gibt, braucht deutlich mehr als die reine Faustregel.
Und dann kommen die Nutzer. Jede laufende Anfrage braucht ihren eigenen Kontextspeicher. Arbeiten fünf Personen gleichzeitig mit langen Dokumenten, liegt dieser Speicher mehrfach im Grafikspeicher. Wie oft das tatsächlich gleichzeitig geschieht, hängt vom Arbeitsalltag ab – und genau hier beginnt die Planung, die sich nicht aus einer Faustregel ablesen lässt.
Drei typische Größenordnungen
- Ein kleines Modell mit rund acht Milliarden Parametern in 4 Bit: Die Gewichte brauchen nach der Faustregel und dem Beispiel nur wenige Gigabyte. Für Zusammenfassungen und einfache Fragen an eigene Dokumente reicht eine einzelne Karte mit mittlerem Speicher – auch für mehrere Nutzer.
- Ein mittleres Modell mit rund dreißig Milliarden Parametern in 4 Bit: Die Gewichte allein liegen im Bereich von zwanzig Gigabyte. Mit Kontext und mehreren Nutzern wird eine Karte mit großem Speicher nötig.
- Ein großes Modell mit siebzig Milliarden Parametern und mehr: Auch in 4 Bit braucht es mehrere Dutzend Gigabyte nur für die Gewichte. Für den gleichzeitigen Betrieb mit mehreren Nutzern ist ein Server mit mehreren Karten oder einer Karte mit sehr großem Speicher nötig.
Speicher entscheidet ob, Rechenleistung wie schnell
Passt ein Modell nicht vollständig in den Grafikspeicher, lässt es sich oft trotzdem betreiben, indem ein Teil in den Arbeitsspeicher des Rechners ausgelagert wird. Dann antwortet es aber spürbar langsamer, weil die Daten ständig zwischen beiden Speichern hin und her müssen. Für einen Versuch am Arbeitsplatz ist das in Ordnung, für ein Werkzeug, mit dem zwanzig Menschen täglich arbeiten sollen, nicht. Die erste Planungsfrage ist deshalb immer: Passt das Modell mit seinem Kontext vollständig in den Grafikspeicher?
Die zweite Frage ist die Geschwindigkeit. Sie hängt von der Rechenleistung der Karte und davon ab, wie viele Anfragen gleichzeitig bearbeitet werden. Hier gibt es keine einfache Faustregel; sie lässt sich nur mit dem eigenen Modell und typischen Anfragen messen. Ein kurzer Test mit echten Aufgaben aus dem Haus ist deshalb vor jeder Anschaffung der verlässlichste Weg.
Dazu kommt ein Punkt, der in Kalkulationen oft fehlt: Der Server läuft nicht für sich. Er braucht Betrieb, Updates, eine Sicherung der Konfiguration und jemanden, der merkt, wenn er langsamer wird. Diese laufende Arbeit gehört in die Entscheidung zwischen eigener Hardware und Mietserver ebenso wie die Anschaffung.
Erst die Aufgabe, dann die Hardware
Der häufigste Planungsfehler ist, mit dem größten Modell anzufangen. Für viele Aufgaben im Unternehmen – Fragen an eigene Handbücher, Zusammenfassungen, Entwürfe für Standardschreiben – reichen kleinere Modelle, besonders wenn sie mit den eigenen Dokumenten verbunden sind. Wer zuerst die Aufgabe beschreibt, mit zwei, drei Modellgrößen an echten Beispielen testet und dann die Hardware bemisst, kauft selten zu groß.
Unser GPU-Rechner bildet genau diese Überlegung ab: Modellgröße, Genauigkeit, Länge der Eingaben und gleichzeitige Nutzer. Für die Gewichte rechnet er nach der Faustregel und dem Beispiel von Hugging Face, für Kontext und Nutzer mit Zuschlägen, die er offen als Annahme ausweist. Das Ergebnis ist eine Größenordnung für die Planung, kein Ersatz für einen Test mit dem eigenen Anwendungsfall.
Und eines bleibt bei aller Technik: Ein lokales Modell schützt die Daten nur so gut wie der Server, auf dem es läuft, und die Rechte, mit denen es auf Dokumente zugreift. Die Seite zum eigenen KI-Server beschreibt, wie Betrieb, Zugriff und Protokollierung zusammengehören.
Verwandte Themen: Wer hier weiterdenkt, liest bei KI-Server, KI-Agenten und KI Datenschutz weiter.
Im Text erwähnt
Quellen
- Hugging Face: Optimizing LLMs for Speed and Memory · Hugging Face
- Hugging Face: Quantization – Überblick · Hugging Face
- Ollama – lokale Sprachmodelle ausführen (Projektseite) · Ollama
