Large Language Models auf eigener Hardware betreiben

Letztes Jahr habe ich 4.200 $ in ein lokales Inferenz-System investiert, das ein 70B-Parametermodell mit vernünftiger Geschwindigkeit ausführen kann. Ein Kollege sah sich mein Setup an und stellte die naheliegende Frage: „Warum nicht einfach die API nutzen? Das sind ja etwa acht Jahre API-Guthaben.“ Mit der Rechnung hatte er nicht unrecht. Bei der Abwägung lag er aber falsch.

Large Language Models lokal zu betreiben war früher die Domäne von Forschungslaboren mit Rack-Servern voller GPUs. Das hat sich schnell geändert. Consumer-Hardware, Quantisierungsverfahren und optimierte Inferenz-Engines bringen 70B+-Modelle heute in Reichweite engagierter Hobbyisten und kleiner Teams. Geräte wie die Tinybox gehen noch weiter – speziell entwickelte Hardware, die 120B-Parametermodelle offline ausführt, ganz ohne Cloud.

Aber „möglich“ und „praktikabel“ sind zwei verschiedene Dinge. Schauen wir uns an, was es tatsächlich braucht, um große Modelle lokal zu betreiben, wann das sinnvoll ist und wann du mit einer API besser fährst.

Warum überhaupt lokal betreiben?

Das API-Modell – Daten an einen Cloud-Anbieter schicken und Ergebnisse zurückbekommen – funktioniert für die meisten Anwendungsfälle gut. Es ist einfacher, bei geringen Volumina pro Anfrage günstiger, und du hast immer Zugriff auf die neuesten Modelle. Warum sollte sich dann überhaupt jemand die Mühe mit lokaler Inferenz machen?

• Datenschutz und Compliance. Manche Daten dürfen das eigene Netzwerk nicht verlassen. Patientenakten, Rechtsdokumente, proprietärer Code, Finanzdaten – regulierte Branchen haben oft harte Vorgaben zur Datenhaltung. Patientendaten an einen API-Endpunkt zu schicken, selbst an einen verschlüsselten, kann gegen HIPAA verstoßen. Lokale Inferenz hält alles on-premises.
• Latenz. API-Aufrufe bedeuten Netzwerk-Roundtrips, mögliche Wartezeiten in Warteschlangen und Rate Limits. Lokale Inferenz hat keine Netzwerklatenz, und du stehst nie in einer Schlange. Bei interaktiven Anwendungen – Echtzeit-Coding-Assistenten, On-Device-Übersetzung, Sprachschnittstellen – ist der Unterschied zwischen 50 ms und 500 ms der Unterschied zwischen „reaktionsschnell“ und „träge“.
• Kosten im großen Maßstab. Die API-Preise richten sich nach Tokens. Bei geringen Volumina ist das vernachlässigbar, bei hohen Volumina summiert es sich gnadenlos. Ein Team, das viele Code-Reviews, Dokumentenanalysen oder Batch-Verarbeitungen fährt, kann monatlich schnell Tausende Dollar an API-Kosten verbrennen. Lokale Hardware hat dagegen feste Kosten – einmal bezahlt, ist Inferenz praktisch kostenlos.
• Verfügbarkeit. Cloud-APIs fallen aus. Rate Limits werden eingeführt. Preise ändern sich ohne Vorankündigung. Modelle werden abgekündigt. Wenn dein Produkt von einer Drittanbieter-API abhängt, bist du den Geschäftsentscheidungen anderer ausgeliefert. Lokale Inferenz sorgt dafür, dass deine Fähigkeiten nicht verschwinden, nur weil auf einem fremden Server gerade ein schlechter Tag ist.
• Freiheit beim Experimentieren. API-Anbieter haben Nutzungsrichtlinien und entscheiden, was du mit dem Modell tun darfst und was nicht. Lokale Modelle kennen solche Einschränkungen nicht – du kannst sie feintunen, modifizieren, für beliebige Zwecke einsetzen und so oft ausführen, wie du willst.

Die Hardware-Realität

Die grundlegende Einschränkung bei der LLM-Inferenz ist der Speicher, nicht die Rechenleistung. Die Parameter eines Modells müssen in den Speicher (GPU-VRAM oder Arbeitsspeicher), bevor du überhaupt etwas damit anfangen kannst. Ein 70B-Parametermodell in 16-Bit-Gleitkomma braucht etwa 140 GB Speicher. Das ist mehr, als jede einzelne Consumer-GPU bietet.

Hier verändert Quantisierung das Spiel. Wenn du die Präzision der Modellgewichte von 16 Bit auf 8 Bit, 4 Bit oder sogar 2 Bit reduzierst, sinkt der Speicherbedarf deutlich:

Memory requirements for a 70B parameter model:
FP16 (full precision):  ~140 GB  → requires multiple A100s
INT8 (8-bit quant):     ~70 GB   → requires 2x RTX 4090 (48GB total)
Q4_K_M (4-bit quant):   ~40 GB   → fits on 2x RTX 3090 or 1x A6000
Q2_K (2-bit quant):     ~25 GB   → fits on 1x RTX 4090 (24GB)
For a 120B parameter model:
FP16:                   ~240 GB  → enterprise GPU territory
INT8:                   ~120 GB  → 5x RTX 4090 or purpose-built device
Q4_K_M:                 ~70 GB   → 3x RTX 4090
Q2_K:                   ~40 GB   → 2x RTX 4090

4-Bit-Quantisierung (Q4_K_M im llama.cpp-Ökosystem) ist aktuell der Sweet Spot. Der Qualitätsverlust ist messbar, für den praktischen Einsatz aber meist akzeptabel – die meisten Leute können Q4-Ausgaben in Blindtests nicht von voller Präzision unterscheiden. 2-Bit-Quantisierung wirkt sich spürbar auf die Qualität aus, besonders bei schlussfolgerungsintensiven Aufgaben, funktioniert aber noch für einfachere Anwendungen wie Textklassifikation oder Zusammenfassungen.

Consumer-Hardware-Builds

Wenn du dir ein eigenes lokales Inferenz-Setup bauen willst, hast du drei grundlegende Wege, die jeweils unterschiedliche Preis-Leistungs-Profile haben.

Der Einzel-GPU-Weg

Eine RTX 4090 (24 GB VRAM, ca. 1.600 $) kann 4-Bit-quantisierte Modelle bis etwa 30B Parameter problemlos ausführen oder 70B-Modelle mit aggressiver 2-Bit-Quantisierung. Für die meisten 7B–13B-Modelle ist sie überdimensioniert – du bekommst über 40 Tokens pro Sekunde, schneller als die meisten Menschen lesen können. Das ist der einfachste Weg: GPU kaufen, llama.cpp oder Ollama installieren, loslegen.

Der Multi-GPU-Weg

Zwei oder mehr GPUs erlauben es, ein Modell auf mehrere Geräte zu verteilen (Tensor Parallelism). Zwei RTX 3090 (zusammen 48 GB VRAM, ca. 2.200 $ gebraucht) können 4-Bit-70B-Modelle bequem ausführen. Der Haken: Du brauchst ein Mainboard mit genügend PCIe-Lanes und Platz für mehrere voll ausgewachsene GPUs. Der Luftstrom wird zum echten Thema – zwei 350-W-GPUs im selben Gehäuse erzeugen ordentlich Hitze.

Der Weg mit einheitlichem Speicher

Apple-Silicon-Macs mit großem Unified Memory sind eine überraschend brauchbare Option. Ein M2 Ultra mit 192 GB Unified Memory kann ein 70B-Modell in voller Präzision komplett im Speicher halten. Die Inferenzgeschwindigkeit ist langsamer als bei dedizierten GPUs – vielleicht 10–15 Tokens pro Sekunde bei einem 70B-Modell –, aber die Einfachheit ist kaum zu schlagen. Keine Treiberprobleme, keine Multi-GPU-Konfiguration, kein Wärmemanagement. Einfach ein Mac Studio auf dem Schreibtisch, der ein 70B-Modell laufen lässt.

Die M-Serie-Chips erreichen das über die Unified-Memory-Architektur: CPU und GPU teilen sich denselben Speicherpool, daher gibt es keinen Engpass durch das Kopieren von Daten zwischen CPU-RAM und GPU-VRAM. Die Speicherbandbreite ist geringer als bei einer dedizierten GPU-Lösung, weshalb die Inferenz langsamer ist. Dass aber 192 GB adressierbarer Speicher in einem Gerät stecken, das 60 Watt zieht, ist schon beeindruckend.

Speziell entwickelte Inferenz-Geräte

Die neueste Kategorie sind speziell entwickelte Geräte für lokale Inferenz – eigens dafür gebaut, große Modelle effizient auszuführen. Sie wollen das Multi-GPU-Gefrickel lösen: Statt Consumer-GPUs mit Kabelmanagement-Albträumen zusammenzuflicken, bekommst du eine Appliance, die von Grund auf für Inferenz konzipiert ist.

Der Reiz liegt auf der Hand. Du steckst es ein, richtest deine Anwendung darauf aus, und es führt dein Modell aus. Keine Treiberkonflikte, keine CUDA-Versionsverwaltung, kein Thermal Throttling, weil jemand drei GPUs zu eng nebeneinander gesteckt hat. Der Kompromiss sind die Kosten – speziell entwickelte Geräte kosten pro FLOP meist mehr als vergleichbare Consumer-GPUs. Du bezahlst für Integration, Zuverlässigkeit und dafür, dass du keine PCIe-Lane-Zuweisung debuggen musst.

Für kleine Unternehmen, die lokale Inferenz brauchen, aber keine Hardware-Ingenieure im Team haben, machen diese Geräte Sinn. Für Hobbyisten, die gern selbst basteln, bleiben DIY-Multi-GPU-Rigs günstiger und flexibler.

Der Software-Stack

Hardware ist nur die halbe Geschichte. Der Inferenz-Software-Stack hat sich rasant weiterentwickelt, und die richtige Softwareauswahl kann den Durchsatz auf derselben Hardware verdoppeln.

• llama.cpp – Das Schweizer Taschenmesser der lokalen Inferenz. In C/C++ geschrieben, läuft es auf allem von Raspberry Pis bis zu Multi-GPU-Servern. Unterstützt Dutzende Modellarchitekturen und Quantisierungsformate. Nicht immer der schnellste, aber der portabelste und aktiv gepflegt.
• vLLM – Optimiert für Durchsatz auf NVIDIA-GPUs. Nutzt PagedAttention, um den GPU-Speicher effizient zu verwalten, was Batch-Inferenz deutlich verbessert. Wenn du mehrere Nutzer von einer Maschine aus bedienst, ist vLLM meist die beste Wahl.
• Ollama – Der Ansatz „Docker für LLMs“. Verpackt llama.cpp in eine benutzerfreundliche Oberfläche mit einer Modell-Registry. Mit ollama run llama3:70b wird das Modell heruntergeladen, die Quantisierung konfiguriert und der Server gestartet. Hervorragend für den Einstieg, aber weniger konfigurierbar als reines llama.cpp.
• MLX – Apples Machine-Learning-Framework, optimiert für Apple Silicon. Wenn du einen Mac mit M-Serie hast, liefert MLX meist bessere Leistung als llama.cpp, weil es die Unified-Memory-Architektur effektiver nutzt.

# Getting started with Ollama (the easiest path)
# Install: https://ollama.ai
# Run a 7B model (downloads automatically, ~4GB)
$ ollama run mistral
# Run a 70B model (needs ~40GB RAM/VRAM)
$ ollama run llama3:70b-instruct-q4_K_M
# Serve as an API endpoint (OpenAI-compatible)
$ ollama serve
$ curl http://localhost:11434/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "mistral",
"messages": [{"role": "user", "content": "Explain TCP handshakes"}]
}'

Der ehrliche Kostenvergleich

Rechnen wir nach, was wirklich zählt. Angenommen, du betreibst ein 70B-Modell und verarbeitest etwa 1 Million Tokens pro Tag (ungefähr die Analyse von 50–100 Dokumenten oder einige hundert Chat-Unterhaltungen).

Cloud API (approximate pricing for 70B-class model):
Input:  $0.50 per million tokens
Output: $1.50 per million tokens
Daily cost: ~$2.00
Monthly cost: ~$60
Yearly cost: ~$720
Local inference (2x RTX 4090 build):
Hardware: $4,200 (one-time)
Electricity: ~$30/month (assuming 700W, 8h/day, $0.15/kWh)
Break-even: ~5.5 years
Local inference (Mac Studio M2 Ultra 192GB):
Hardware: $5,800 (one-time)
Electricity: ~$3/month (60W)
Break-even: ~8 years

Bei 1 Million Tokens pro Tag ist die Cloud-API über Jahre günstiger. Doch die Rechnung ändert sich dramatisch, wenn das Volumen steigt. Bei 10 Millionen Tokens pro Tag kosten die APIs 7.200 $ pro Jahr, und die lokale Hardware hat sich nach etwa 7 Monaten amortisiert. Bei 50 Millionen Tokens pro Tag zahlt sich lokale Inferenz in wenigen Wochen aus.

Der Kostenvergleich ignoriert zudem die nicht-finanziellen Faktoren: Datenschutz, Latenz, Verfügbarkeit und Freiheit beim Experimentieren. Wenn eines davon eine Anforderung ist (und nicht nur ein Nice-to-have), wird der finanzielle Vergleich zweitrangig.

Was bei der Quantisierung verloren geht

Quantisierung macht lokale Inferenz für große Modelle überhaupt erst möglich, ist aber nicht kostenlos. Wenn du die Präzision reduzierst, geht Information verloren, und die Verschlechterung ist nicht über alle Aufgaben gleich.

In meinen Tests liefern 4-Bit-quantisierte Modelle bei Textgenerierung, Zusammenfassungen, einfachen Q&A, Übersetzungen und Code-Generierung für gängige Muster praktisch dieselben Ergebnisse wie volle Präzision. Die Verschlechterung zeigt sich bei komplexem mehrstufigem Schlussfolgern, mathematischen Berechnungen, Aufgaben, die präzises Abrufen von Trainingsdaten erfordern, und bei feinsinnigem Befolgen von Anweisungen.

Die praktische Konsequenz: Wenn du ein lokales Modell für Code-Completion, Dokumentenzusammenfassungen oder Konversations-KI nutzt, ist 4-Bit-Quantisierung völlig in Ordnung. Wenn du es für komplexes analytisches Schlussfolgern einsetzt oder es auf feine Genauigkeitsunterschiede ankommt, solltest du sorgfältig testen und eventuell höhere Präzision in Kauf nehmen – dafür braucht man mehr Speicher oder ein kleineres Modell.

Die Entscheidung treffen

Nach einem Jahr mit lokal betriebenen Modellen ist hier mein Entscheidungsrahmen zwischen lokaler und Cloud-Inferenz:

Cloud-APIs nutzen, wenn: du die absolut beste Modellqualität brauchst, dein Volumen gering bis mittel ist, du keine Hardware-Expertise hast, du häufig das Modell wechseln musst oder Latenz nicht kritisch ist (ein paar hundert Millisekunden sind okay).

Lokal betreiben, wenn: deine Daten das Netzwerk nicht verlassen dürfen, du konstant eine Latenz unter 100 ms brauchst, dein Token-Volumen hoch genug ist, um die Hardwarekosten zu rechtfertigen, du ohne Kosten pro Anfrage frei experimentieren willst oder du Inferenz unabhängig von der Verfügbarkeit Dritter brauchst.

Die Landschaft verändert sich schnell. Modelle werden kleiner und effizienter, Quantisierungsverfahren werden besser, und Hardware wird günstiger. Die Schwelle, ab der lokale Inferenz finanziell Sinn ergibt, sinkt jedes Jahr. Wenn es für dich heute keinen Sinn ergibt, könnte es in achtzehn Monaten anders aussehen – und der Software-Stack wird in der Zwischenzeit nur noch einfacher zu benutzen sein.