Ich will ein lokales LLM betreiben: Welchen Server soll ich kaufen?

1. Mit dem Modell anfangen, nicht mit der Kiste

Das Modell muss in schnellen Speicher passen: den VRAM einer GPU oder den Unified Memory eines Mac oder eines AMD- oder NVIDIA-Superchips. Die Gewichte brauchen Parameter mal Bytes pro Parameter: zwei Bytes bei 16 Bit, eines bei 8 Bit, ein halbes bei 4 Bit. Dazu kommen rund 20 Prozent für den KV-Cache bei normaler Kontextlänge. Das ergibt etwa 5 GB für ein Modell mit 8 Milliarden Parametern in 4 Bit, 19 GB für 32B, 42 GB für 70B und 84 GB für 70B in 8 Bit. Mixture-of-Experts-Modelle sind die Falle: Pro Token arbeiten nur wenige Experten, aber alle müssen im Speicher liegen. Ein Modell mit rund 428 Milliarden Parametern braucht deshalb selbst in 4 Bit etwa 257 GB.

Die zweite Zahl ist die Speicherbandbreite. Für jedes Token liest ein dichtes Modell alle Gewichte einmal, Bandbreite geteilt durch die Grösse der Gewichte ist also eine harte Obergrenze für das Tempo eines einzelnen Nutzers. Ein 70B-Modell in 4 Bit hat rund 35 GB Gewichte: Bei 1'792 GB/s liegt diese Grenze bei etwa 50 Tokens pro Sekunde, bei 273 GB/s unter 8. Reale Werte sind tiefer, aber das Verhältnis zwischen den Maschinen bleibt, und es erklärt die meisten Unterschiede, über die Sie lesen werden.

Die dritte Zahl ist Parallelität. Zehn Menschen, die gleichzeitig fragen, brauchen zehn KV-Caches und eine Serving-Engine, die ihre Anfragen bündelt. Genau hier trennen sich Team-Server und persönliche Maschine.

2. Für eine bis fünf Personen: eine leise Maschine mit viel Speicher

Vier Optionen dominieren Ende 2026 den Schreibtisch, und sie gewichten Speicher und Tempo unterschiedlich.

Der Mac Studio mit M5 Max bietet bis zu 128 GB Unified Memory und 460 bis 614 GB/s; mit M5 Ultra sind es bis zu 512 GB und 1,2 TB/s, bei einer maximalen Dauerleistung, die Apple mit 480 W angibt. Das ist der einfachste Weg, ein sehr grosses Modell auf den Schreibtisch zu bringen, und er ist leise. MLX, llama.cpp, Ollama und LM Studio laufen darauf gut.

NVIDIAs DGX Spark steckt den GB10-Superchip mit 128 GB Unified Memory in eine kleine Box. NVIDIA nennt bis zu 1 PetaFLOP FP4-Leistung und Modelle bis 200 Milliarden Parameter, dazu kommt der volle CUDA-Software-Stack. Die Bandbreite von 273 GB/s ist die Grenze bei grossen dichten Modellen, stark ist die Box für Entwicklung, Fine-Tuning-Versuche und Mixture-of-Experts-Modelle.

Mini-PCs mit AMDs Ryzen AI Max+ 395 teilen bis zu 128 GB LPDDR5x-8000 zwischen CPU und der Radeon-8060S-Grafik mit 40 Kernen, bei konfigurierbaren 45 bis 120 W. Das ist der günstigste Weg zu viel Speicher, llama.cpp, LM Studio und Ollama laufen darauf.

Eine Workstation mit dedizierter GPU ist pro Nutzer am schnellsten: Die RTX PRO 6000 Blackwell bringt 96 GB ECC-GDDR7 mit 1'792 GB/s bei 600 W, die Consumer-Karte RTX 5090 hat 32 GB bei 575 W Gesamtgrafikleistung. Dazu kommen vLLM und alles, was zuerst für CUDA gebaut wird.

# Single user on a desktop: Ollama with an OpenAI-compatible endpoint
ollama pull qwen3:32b
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen3:32b", "messages": [{"role": "user", "content": "Hello"}]}'

3. Für ein Team: ein NVIDIA-Server und vLLM

Sobald zwanzig Menschen ein Modell teilen, lautet die Frage nicht mehr "passt es", sondern "bleibt es schnell, wenn zehn gleichzeitig fragen". Das ist die Aufgabe einer Serving-Engine mit Continuous Batching und paged KV-Speicher, und vLLM ist auf NVIDIA-Hardware die Referenz. Sie macht aus einer GPU einen gemeinsamen Dienst mit OpenAI-kompatibler API, sodass jedes Tool, das mit OpenAI spricht, stattdessen mit Ihrem Server reden kann.

Für ein Team von rund zwanzig Personen plane ich meist einen Rack-Server mit einer oder zwei Rechenzentrums-GPUs. Die L40S hat 48 GB ECC-GDDR6 mit 864 GB/s und maximal 350 W, die RTX PRO 6000 Blackwell verdoppelt den Speicher auf 96 GB. Mit 96 GB passt ein 70B-Modell in 4 Bit mit viel Platz für parallele KV-Caches, mit 48 GB sind Sie in der 30B-Klasse oder brauchen zwei Karten. Kaufen Sie den Server bei einem Hersteller, von dem Sie schnell Ersatzteile bekommen, mit redundanten Netzteilen, ECC-Arbeitsspeicher, Remote-Management-Controller und schnellen NVMe-Laufwerken für die Modelldateien.

Llama.cpp ist hervorragend für eine Person und für ungewöhnliche Hardware; für viele gleichzeitige Nutzer hält das Batching von vLLM die Antworten schnell. Das Video unten vergleicht die beiden gut.

4. Für grosse Modelle und viele Nutzer: Multi-GPU mit NVLink

Offene Modelle der Spitzenklasse und grosse Mixture-of-Experts-Modelle brauchen Hunderte Gigabyte schnellen Speicher, verteilt auf GPUs, die schnell miteinander sprechen. Die H200 hat 141 GB HBM3e mit 4,8 TB/s und bis zu 700 W pro GPU; acht davon ergeben über ein Terabyte. NVIDIAs DGX B200 vereint acht B200-GPUs zu 1'440 GB HBM3e mit 64 TB/s Gesamtbandbreite, bei maximal rund 14,3 kW für das System. Dazwischen liegt die DGX Station, eine Maschine für unter den Schreibtisch mit GB300-Superchip und 748 GB kohärentem Speicher, davon 252 GB HBM3e.

In dieser Grösse ist der Server das kleinere Projekt. Stromanschlüsse, Kühlung, Rack-Platz, ein Ersatzteilplan und jemand, der das betreiben kann, zählen so viel wie die GPUs. vLLM verteilt ein Modell per Tensor-Parallelität auf mehrere GPUs, bei Mixture-of-Experts-Modellen zusätzlich per Expert-Parallelität; mein Artikel zu MiniMax M3 zeigt, was das für den Betrieb eines Modells der 400B-Klasse bedeutet.

5. Erst mieten, dann kaufen

Vor jedem Kauf mache ich einen zweiwöchigen Pilot auf gemieteten GPUs: mit dem geplanten Modell, Ihren echten Prompts und der erwarteten Nutzerzahl. AWS bietet H100-Instanzen in der P5-Familie an, Azure die ND-H100-v5-Serie, und Google Cloud veröffentlicht seine GPU-Preise pro Region. Ein Pilot beantwortet die Fragen, die kein Datenblatt beantwortet: Reicht das 32B-Modell, oder braucht es wirklich 70B? Wie lang sind Ihre Kontexte? Wie viele Menschen nutzen es um neun Uhr morgens?

Kaufen lohnt sich, wenn die Nutzung stetig und planbar ist, wenn Daten Ihr Haus nicht verlassen dürfen oder wenn das Netz air-gapped ist und Mieten schlicht keine Option ist. Vergleichen Sie die Gesamtkosten über drei Jahre inklusive Strom, Kühlung, Support und der Stunden für den Betrieb mit dem Stundenpreis für die Stunden, die Sie wirklich nutzen würden. Preise ändern sich monatlich, nehmen Sie also die aktuellen Zahlen von den Herstellerseiten statt aus einem Artikel, auch nicht aus diesem.

6. Was ich kaufen würde, nach Szenario

Ein Entwickler, der einen privaten Coding-Assistenten und Platz zum Experimentieren will: ein Mac Studio mit 64 bis 128 GB, ein Ryzen-AI-Max+-395-Mini-PC mit 128 GB oder ein PC mit RTX 5090, wenn Tempo wichtiger ist als Modellgrösse. Ollama oder LM Studio, und der Endpunkt direkt im Editor.

Ein Team von rund zwanzig Personen, das einen privaten Chat und Suche über eigene Dokumente will: ein Rack-Server mit einer oder zwei RTX PRO 6000 oder zwei L40S, vLLM, ein Modell zwischen 30B und 70B in 4 oder 8 Bit und ein Gateway davor. Dazu eine zweite, kleinere Maschine, um neue Modellversionen zu testen, bevor sie alle erreichen.

Ein reguliertes Unternehmen oder ein Air-Gap-Netz: zwei identische Server statt eines grösseren, damit ein Ausfall oder ein Update den Dienst nie stoppt, ECC überall, redundante Stromversorgung, Remote-Management in einem eigenen Netz und eine Offline-Modellregistry mit geprüften Hashes. Meine Artikel zu lokalen LLMs für sensible Daten und zu lokalen LLMs im Air-Gap-Netz behandeln die Sicherheitsseite im Detail.

7. Von der Kiste zum Dienst an einem Nachmittag

Das Setup ist auf jeder Stufe gleich. Installieren Sie ein Ubuntu-LTS-Release, den NVIDIA-Treiber, CUDA und das NVIDIA Container Toolkit, damit Container die GPUs nutzen können. Kopieren Sie die Modelldateien auf die lokale NVMe und starten Sie vLLM, das eine OpenAI-kompatible API im internen Netz anbietet. Davor kommt ein Gateway wie LiteLLM für Schlüssel, Kontingente und Routing, angebunden an Ihr Single Sign-on, und es wird protokolliert, wer was gefragt hat. Eine Chat-Oberfläche wie Open WebUI gibt allen ein vertrautes Frontend, und Ihre Anwendungen und die Dokumentensuche sprechen mit demselben Gateway.

Das Diagramm nach diesem Schritt zeigt den ganzen Weg von der Hardware zu den Nutzern, dazu die drei Hardware-Stufen nebeneinander.

# Team server: vLLM with an OpenAI-compatible API on port 8000
# (NVIDIA driver and Container Toolkit installed, model files in /srv/models)
docker run -d --name vllm --gpus all -p 8000:8000 \
  -v /srv/models:/models \
  vllm/vllm-openai:latest \
  --model /models/Qwen2.5-32B-Instruct-AWQ \
  --max-model-len 16384

# Smoke test from the gateway host
curl http://gpu-server:8000/v1/models

8. Betreiben wie jeden anderen Produktivdienst

Ein lokales Modell ist ein Dienst und braucht, was jeder Dienst braucht. NVIDIAs DCGM Exporter liefert GPU-Auslastung, Speicher, Temperatur und Fehler an Prometheus, und ein Grafana-Dashboard neben Latenz und Fehlerraten des Gateways zeigt Ihnen, wann Menschen zu warten beginnen. Alarmieren Sie bei fast vollem GPU-Speicher, bei Wartezeit in der Queue und bei Hardwarefehlern, nicht nur, ob der Prozess läuft.

Halten Sie die Konfiguration in Git, patchen Sie Betriebssystem und Treiber nach Plan, testen Sie jedes neue Modell vor dem Wechsel gegen einen festen Satz eigener Fragen, und schreiben Sie auf, wie Sie auf die zweite Maschine umschalten. Dann ist die Hardware-Frage für die nächsten drei Jahre beantwortet, und das Gespräch kann sich dem widmen, was Ihr Team darauf baut.