Für ein lokales LLM ist der Grafikspeicher die Größe, die alles andere bestimmt. Die Faustregel: Ein Modell mit X Milliarden Parametern braucht in FP16 rund 2 × X GB VRAM, quantisiert auf 4 Bit deutlich weniger, und für lange Kontexte kommt der KV-Cache obendrauf. Ein kleines Team kommt mit einer Workstation-GPU oder einem Mac Studio los. Einen GPU-Server braucht ihr erst, wenn viele Leute gleichzeitig Anfragen stellen.
Warum man ein Modell überhaupt im eigenen Haus betreibt, habe ich an anderer Stelle aufgeschrieben. Hier geht es um die praktische Frage danach: Was muss unter dem Tisch oder im Rack stehen, damit das Ding läuft?
Wie rechne ich den Speicherbedarf aus?
Die Rechnung ist banaler, als die Hardware-Diskussionen in Foren vermuten lassen. Hugging Face beschreibt sie in der Transformers-Dokumentation so: Die Gewichte eines Modells mit X Milliarden Parametern brauchen in bfloat16/float16 rund 2 × X GB VRAM (Hugging Face). Ein 7B-Modell landet also bei etwa 14 GB, ein 32B-Modell bei etwa 64 GB.
Quantisierung drückt das stark. Im selben Dokument läuft ein 15B-Modell (OctoCoder) in 4-Bit-Präzision mit „just a bit over 9GB“ (Hugging Face). Für den Chat-Alltag ist 4 Bit in den meisten Fällen der vernünftige Kompromiss. Die Qualität leidet etwas, dafür passt das Modell überhaupt erst auf bezahlbare Hardware.
Der Posten, den fast alle vergessen, ist der KV-Cache. Der wächst mit der Länge der Eingabe und des Chatverlaufs. Im Hugging-Face-Beispiel mit langem Kontext frisst er etwa halb so viel Speicher wie die Modellgewichte selbst (Hugging Face). Wer also plant, ganze Verträge oder lange Handbücher in den Kontext zu kippen, rechnet großzügig nach oben (und testet mit echten Dokumenten, nicht mit „Hallo, wer bist du?“).
Welche Hardware-Klassen gibt es?
Grob gibt es drei Wege. Preise nenne ich bewusst nicht, die ändern sich schneller als dieser Post altert.
| Workstation mit einer GPU | Mac Studio | Server mit Rechenzentrums-GPUs | |
|---|---|---|---|
| Speicher fürs Modell | VRAM der Karte, meist die Engstelle | gemeinsamer Arbeitsspeicher, bis 512 GB | VRAM mehrerer Karten |
| Passt gut für | ein Modell der kleinen bis mittleren Klasse, Einzelplatz oder kleines Team | größere Modelle, wenige gleichzeitige Nutzer | viele parallele Nutzer, produktive Anwendungen |
| Typischer Stack | Ollama | Ollama | vLLM |
| Schwachstelle | Speichergrenze der Karte | Durchsatz bei vielen parallelen Anfragen | Anschaffung, Strom, Betrieb |
Der Mac Studio ist der Außenseiter, der in der Praxis erstaunlich oft passt. Apple Silicon teilt sich den Speicher zwischen CPU und GPU, und aktuell lässt sich der Mac Studio mit M5 Max auf 128 GB und mit M5 Ultra auf 512 GB konfigurieren (Apple). Damit laufen Modelle, für die man sonst mehrere Grafikkarten bräuchte. Beim Durchsatz unter Last hält er mit echten Server-GPUs aber nicht mit.
Zur Einordnung am oberen Ende: OpenAI gibt für gpt-oss-120b eine einzelne 80-GB-GPU an, für gpt-oss-20b reichen 16 GB Speicher (Hugging Face, Modellkarte).
Ollama, vLLM, Open WebUI: welcher Stack?
Ollama ist der Einstieg. Das Projekt steht unter MIT-Lizenz (GitHub), und der Ablauf ist kurz: Modell ziehen, starten, fertig. Wichtig für später: Ollama spricht eine Teilmenge der OpenAI-API (Ollama-Doku). Anwendungen, die ihr heute dagegen baut, müsst ihr beim Umstieg nicht neu schreiben.
vLLM ist die Wahl, wenn aus dem Experiment ein Dienst für die ganze Firma wird. Die Bibliothek ist auf Durchsatz gebaut, verwaltet den KV-Cache mit PagedAttention, bringt ebenfalls einen OpenAI-kompatiblen Server mit und steht unter Apache 2.0 (GitHub). Auf einem Einzelplatz ist das überdimensioniert. Bei zwanzig Leuten, die gleichzeitig tippen, merkt man den Unterschied.
Open WebUI ist das Chat-Frontend, das die meisten davorsetzen: Wissensdatenbanken mit Dokumenten-Upload, Rollen, Gruppen und Rechte pro Modell (Open WebUI Docs). Einen Haken hat es. Seit Version 0.6.6 steht das Projekt unter einer eigenen „Open WebUI License“ mit Branding-Klausel. Das Logo und den Namen dürft ihr nur entfernen, wenn höchstens 50 Endnutzer in 30 Tagen zugreifen oder ihr eine schriftliche Erlaubnis oder eine Enterprise-Lizenz habt (Open WebUI, Lizenz). Für die meisten Mittelständler spielt das keine Rolle. Klassisches Open Source im OSI-Sinn ist es trotzdem nicht mehr, und das sollte man wissen, bevor man es in ein Kundenprojekt einbaut.
Welche Modelle darf ich überhaupt nehmen?
Die Lizenzfrage wird gern übersprungen, weil man ja „nur intern“ testet. Mistral Small 3.1 (Modellkarte), Qwen3-32B (Modellkarte) und gpt-oss (Modellkarte) stehen unter Apache 2.0, damit ist der kommerzielle Einsatz unkompliziert.
Anders bei Llama. Für die multimodalen Modelle von Llama 3.2 und Llama 4 gewährt Meta Personen mit Wohnsitz und Unternehmen mit Hauptsitz in der EU die Nutzungsrechte nicht (Meta, Llama 4 Use Policy). Wer da „mal eben“ ein Llama-Vision-Modell auf den Firmenserver lädt, hat ein Lizenzproblem, noch bevor die erste Anfrage durch ist. Die Datenschutzseite ist davon unabhängig: Auch ein lokales Modell verarbeitet personenbezogene Daten, und die DSGVO bleibt ein Prozess, kein Häkchen.
Klein anfangen, dann messen
Meine Empfehlung ist unspektakulär. Kauft nicht zuerst die große Kiste. Nehmt eine Maschine, die ihr ohnehin habt oder günstig bekommt, installiert Ollama und Open WebUI, ladet ein Apache-lizenziertes Modell in 4 Bit und lasst ein paar Kolleginnen und Kollegen zwei Wochen lang echte Aufgaben damit erledigen. Danach wisst ihr, welche Modellgröße die Qualität bringt, die ihr braucht, wie lang die Kontexte wirklich werden und wie viele Anfragen parallel kommen. Aus diesen drei Zahlen ergibt sich die Hardware fast von selbst.
Wer das Modell später dauerhaft betreiben will, braucht dasselbe wie für jeden anderen Dienst: Updates, Monitoring, Backups der Wissensdatenbank. Das kann eure IT machen oder ihr gebt es als gemanagten Betrieb ab. Wie das Ganze in eine KI-Strategie passt, steht auf der Seite zu lokaler KI.
Ihr wollt wissen, welche Hardware für euren Anwendungsfall reicht, bevor ihr bestellt? Schreib mir — wir rechnen das mit euren echten Dokumenten durch.