Llama 3.3 70B lokal hosten: Anleitung für Unternehmen

Warum Llama 3.3 70B lokal hosten?

Meta hat Llama 3.3 70B Instruct im Dezember 2024 veröffentlicht. Das Modell ist textbasiert, mehrsprachig (Deutsch gehört zu den offiziell unterstützten Sprachen) und verarbeitet ein Kontextfenster von 128.000 Tokens. Seitdem sind neuere offene Modelle erschienen, etwa aus den Familien Llama 4, Qwen, Mistral und DeepSeek. Llama 3.3 70B bleibt dennoch ein verbreiteter, gut dokumentierter Standard: Es ist ein klassisches dichtes Modell ohne Mixture-of-Experts-Komplexität, alle gängigen Inferenz-Engines unterstützen es stabil, und es gibt zahlreiche geprüfte Quantisierungen. Eine Einordnung der Alternativen finden Sie im Open-Source-LLM-Vergleich 2026.

Die Gründe für den Eigenbetrieb:

• Datenhoheit: Prompts und Dokumente verlassen Ihre Infrastruktur nicht.
• Planbare Kosten: Feste Serverkosten statt nutzungsabhängiger Token-Abrechnung.
• Kontrolle: Sie bestimmen Modellversion, Updates und Systemprompts – keine unangekündigten Modelländerungen.
• Anpassbarkeit: Fine-Tuning mit LoRA oder QLoRA auf eigenen Daten ist möglich.

Zur Lizenz: Llama 3.3 steht unter der Llama 3.3 Community License. Sie erlaubt die kommerzielle Nutzung, enthält aber Bedingungen, etwa eine Acceptable Use Policy, Hinweispflichten („Built with Llama“) und eine Sonderregel für sehr große Plattformen. Lassen Sie die Lizenz vor dem Produktiveinsatz von Ihrer Rechtsabteilung prüfen.

Hardware-Anforderungen: VRAM je Quantisierung

Der VRAM-Bedarf ergibt sich im Kern aus Parameterzahl mal Bytes pro Parameter. Hinzu kommt der KV-Cache, der mit Kontextlänge und Zahl gleichzeitiger Anfragen wächst. Die folgenden Werte sind Richtwerte:

Für den produktiven Betrieb mit mehreren Nutzern ist eine GPU mit 96 GB VRAM wie die NVIDIA RTX PRO 6000 Blackwell der pragmatische Weg: In 4 Bit bleibt reichlich Platz für KV-Cache und parallele Anfragen, in FP8 läuft das Modell mit höherer Genauigkeit auf einer Karte. Die Blackwell-Architektur unterstützt FP8 nativ. Kleinere Karten mit 20 GB wie die RTX 4000 SFF Ada sind für 70B-Modelle nicht sinnvoll; selbst zwei davon reichen für eine 4-Bit-Variante mit brauchbarem Kontext kaum aus. Sie eignen sich dagegen gut für Modelle bis etwa 14B Parameter oder für Embedding-Modelle.

Welche Quantisierung? AWQ in 4 Bit bietet in der Praxis einen guten Kompromiss aus Qualität und Speicherbedarf. FP8 liegt qualitativ näher an der vollen Präzision und ist auf aktuellen GPUs sehr effizient. Testen Sie beide Varianten mit Ihren realen Aufgaben, bevor Sie sich festlegen.

Schritt für Schritt: Deployment mit vLLM

vLLM ist der verbreitetste Inferenz-Server für den Produktivbetrieb. Er bietet Continuous Batching, effizientes KV-Cache-Management und eine OpenAI-kompatible API.

1. Voraussetzungen schaffen. Aktueller NVIDIA-Treiber, Docker mit NVIDIA Container Toolkit, ausreichend schneller Speicher für die Modelldateien.

2. Modellzugang einrichten. Die offiziellen Gewichte liegen auf Hugging Face unter meta-llama/Llama-3.3-70B-Instruct und erfordern die Annahme der Lizenz sowie ein Zugriffstoken. Für 4 Bit oder FP8 verwenden Sie ein vorquantisiertes Checkpoint aus einer vertrauenswürdigen Quelle.

3. Server starten. Ein vereinfachtes Beispiel:

docker run --gpus all -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HF_TOKEN=<Ihr-Token> \
  vllm/vllm-openai:latest \
  --model <pfad-oder-repo-des-awq-checkpoints> \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

vLLM erkennt die Quantisierung in der Regel aus der Modellkonfiguration. Mit --max-model-len begrenzen Sie die Kontextlänge und damit den KV-Cache; die vollen 128.000 Tokens benötigen deutlich mehr Speicher.

4. Anbindung testen. Der Server stellt unter /v1/chat/completions eine OpenAI-kompatible Schnittstelle bereit. Bestehende Werkzeuge wie LangChain, Open WebUI oder eigene Anwendungen lassen sich meist nur durch Änderung der Basis-URL anbinden.

Alternative Ollama: Für Tests und Einzelplatz-Szenarien ist Ollama einfacher (ollama run llama3.3:70b, standardmäßig 4-Bit-Quantisierung mit rund 43 GB). Für viele gleichzeitige Nutzer ist vLLM in der Regel performanter. Einen Vergleich finden Sie unter vLLM vs. Ollama vs. TGI.

Performance und Betrieb

• Kontextlänge bewusst wählen: Die meisten Unternehmensanfragen kommen mit 8.000 bis 32.000 Tokens aus. Längere Kontexte kosten Speicher und Durchsatz.
• Prefix Caching aktivieren: Wiederkehrende Systemprompts werden zwischengespeichert, das senkt die Latenz.
• Monitoring: GPU-Auslastung, Speicher, Tokens pro Sekunde und Warteschlangenlänge überwachen. vLLM liefert dafür Prometheus-Metriken.
• Absicherung: Den Inferenz-Server nie direkt ins Internet stellen. Davor gehören Authentifizierung, Rate Limiting und idealerweise ein Gateway mit PII-Maskierung und Audit-Trail.
• Updates: Treiber, CUDA, vLLM und Modellversionen kontrolliert und mit Regressionstests aktualisieren.

Häufige Fehler sind zu knapp bemessener VRAM, unrealistisch lange Kontextfenster, eine offen erreichbare API ohne Authentifizierung und fehlende Tests nach Updates.

Selbst betreiben oder Managed Service?

Der Eigenbetrieb erfordert GPU-Know-how, Rechenzentrumsfläche und Bereitschaft für den laufenden Betrieb. Bei Verdacloud erhalten Sie Llama 3.3 70B oder ein anderes offenes Modell vorkonfiguriert auf der Verda GPU L (NVIDIA RTX PRO 6000 Blackwell, 96 GB) – als Managed KI-Server oder als Komplettpaket Local LLM & Secure Gateway, betrieben in ISO-27001-zertifizierten Rechenzentren in Bayern und Sachsen, inklusive Monitoring, Updates und Backups. Die Konditionen finden Sie auf der Preisseite.