Ollama im Keller, vLLM im Serverraum – lokale KI im Unternehmen

Wie betreibt ein Unternehmen Open-Weights-Modelle auf eigener Hardware und bietet sie über eine OpenAI-kompatible API an? Der Vortrag zeigt den Weg von Ollama und LM Studio für lokales Entwickeln bis zu vLLM als zentralem Serving-Dienst für viele Nutzer.
Themen: Open Weights und Modellnamen, Dense vs. MoE, Quantisierung (FP8/FP4), Continuous Batching, Benchmarks auf dem NVIDIA DGX Spark (GB10, 128 GB Unified Memory) sowie der Betrieb mit Hugging Face, Docker und den wichtigsten vLLM-Startparametern.

https://www.linkedin.com/in/marco-wagner-551562b2

Transcript

1. Ollama im Keller, vLLM im Serverraum Lokale KI im Unternehmen Open Weights · eigene Hardware · OpenAI-compatible API
2. KURZ ZU MIR Warum ich lokale Modelle betreibe Senior IT Systems Manager bei PrismaLife AG Ich treibe technische KI-Themen im Unternehmen voran: Open WebUI, lokaler Modellbetrieb und praxistaugliche Integration. Organisator der .NET User Group Rheintal
3. DIE ANFORDERUNG Gesundheits- und Personendaten haben einen anderen Datenpfad. Wir sind Lebensversicherung. Sensible Daten sollen nicht unkontrolliert an externe KI-Dienste in den USA gesendet werden. Lokale KI ist für uns keine Modellpräferenz. Sie ist eine Betriebsanforderung.
4. MOZILLA-BERICHT Wenn offene Modelle so nah an Frontier Labs liegen: Was können wir selbst betreiben?
5. DER VERGLEICH HAT SICH VERSCHOBEN Benchmarks mit grain of salt: Sie sind Hinweise, keine allgemeingültige Rangliste. Entscheidend ist: Open Weights werden heute an Frontier-Modellen gemessen.
6. DIE KONSEQUENZ Was können wir selbst betreiben? Model Weights herunterladen, auf eigener Hardware ausführen und Anwendungen über eine bekannte API anbinden.
7. BEGRIFFE SAUBER HALTEN Open Weights ist nicht automatisch Open Source Frage ans Publikum Warum nennen wir diese Modelle Open Weights und nicht Open Source? Weil die Weights veröffentlicht werden, nicht automatisch die Trainingsdaten, deren Herkunft, die Datenpipeline und der vollständige Trainingsprozess. Das ist auch ein Rechtsrisiko: Ohne offen nachvollziehbare Quellen können Urheberrechts- und Lizenzfragen nicht abschließend geprüft werden. 01 02 03 Open Weights Lizenz Open Source Gewichte herunterladen und selbst ausführen. Nutzung, Weitergabe und Einschränkungen einzeln prüfen. Source Code und offene Rechte sind eine zusätzliche Frage.
8. HUGGING FACE / AUSWAHL Viele Modelle. Zwei Größenordnungen. Hersteller Modell Lizenz Weights BF16, ca. Weights FP4, ca. Alibaba Cloud Qwen3.6-35B-A3B Apache-2.0 70 GB 18 GB Alibaba Cloud Qwen3.8-27B Apache-2.0 54 GB 14 GB Google Gemma 4 31B Apache-2.0 62 GB 16 GB Google Gemma 4 26B-A4B Apache-2.0 52 GB 13 GB DeepSeek DeepSeek-V4.1-Flash MIT 1.1 TB 276 GB Grobe Weight-Größen: FP4 benötigt wegen Skalen und Metadaten mehr als exakt vier Bit pro Parameter. Nicht der gesamte VRAM-Bedarf: KV Cache, Vision Encoder, Runtime-Overhead und Reserven kommen hinzu. A3B / A4B: drei bzw. vier Milliarden aktive Parameter pro Token, nicht die Zahl geladener Parameter. Frage ans Publikum: Warum veröffentlicht Google Gemma als Open Weights, OpenAI und Anthropic ihre Modelle nicht? Google verkauft vor allem die Schienen: Cloud, TPUs und Infrastruktur rund um Gemma. Für OpenAI und Anthropic sind die KI-Modelle selbst das primäre Produkt.
9. EIN MODELLNAME, VIELE INFORMATIONEN Qwen3.6-35B-A3B-NVFP4 Qwen - 3.6 - 35B - A3B - NVFP4 Qwen 3.6 35B A3B Modellfamilie Generation Gesamtparameter Aktive Parameter Die Modellreihe. Versions- bzw. Parameter über alle Experts Bei MoE pro Token aktivierte Generationsangabe. hinweg. Parameter. NVFP4 Quantisierung NVIDIA-optimiertes FP4Format.
10. ANDERES PACKAGING, ANDERE AUSSAGE Qwen3.6-35B-A3B-Instruct-Q4_K_M.gguf Qwen3.6-35B-A3B - Instruct - Q4_K_M - gguf Qwen3.6-35B-A3B Instruct Q4_K_M gguf Modell und MoEGröße AnweisungsFinetuning Quantisierungsvariante Dateiformat Eine konkrete GGUF- Ein Modellformat für lokale Familie, Gesamtgröße und Für Chat und das Befolgen von Quantisierungsvariante. Inferenz, kein aktive MoE-Parameter. Anweisungen trainiert. Gleitkommaformat.
11. VOM GEWICHT ZUR ZAHL Quantisierung: FP8 zu FP4 Eine Gewichtszahl +1.2345 Ein Float speichert Vorzeichen, Größenordnung und Präzision. FP8 s e e e m FP4 m m m verdichten Genug Bits für feinere Abstufungen. s e m m Weniger Bits pro Gewicht, gröbere Abstufungen. Vereinfachte Darstellung: kein vollständiges IEEE- oder NVIDIA-Formatschema. VRAM Throughput Qualität weniger Speicher pro Gewicht kann steigen, abhängig von Hardware und Kernel Trade-off hängt von Modell und Quantisierung ab FP4 als Sweet Spot Für geeignete Modelle und aktuelle NVIDIA-Hardware oft ein sehr guter Kompromiss aus Modellgröße und Qualität.
12. INTEGRATION Der Wechsel ist kleiner als gedacht. 01 02 03 Client vLLM Eigene GPU SDK oder interne Anwendung -> OpenAI-compatible endpoint -> Die Antwort geht auf demselben Pfad zurück. Weights und Verarbeitung intern
13. MODELLARCHITEKTUR Dense vs. Mixture of Experts 1 5 2 6 Dense Mixture of Experts Token Token 3 7 Router 4 1 2 3 4 5 6 7 8 8 Jedes Token nutzt alle Gewichtsblöcke dieser Schicht. Der Router aktiviert zwei von acht Experts. Warum MoE? Mehr Modellkapazität, ohne für jedes Token alle Experts zu aktivieren. Wichtig: Die gesamten Weights müssen trotzdem in den VRAM passen. MoE spart aktive Rechenarbeit, nicht automatisch Speicher.
14. HARDWARE VRAM ist die harte Grenze. Modellgröße Quantisierung Wie viele Weights müssen in den Speicher? Wie viel Präzision kann der Use Case abgeben? Context Window Parallelität KV Cache braucht ebenfalls VRAM. Mehr gleichzeitige Nutzer brauchen Reserven.
15. PRAXIS Was ich mit dem DGX Spark gelernt habe 01 Teuer, aber mit den richtigen Use Cases ist der ROI schnell da. 02 Standardgerät statt Eigenbau: klarer Betriebspfad und Skalierbarkeit in eine größere Umgebung. 03 Viel Speicher für Kontext und mehrere Nutzer, aber begrenzte Speicherbandbreite.
16. PRAXIS DGX Spark: 32 parallele Anfragen sind der Sweet Spot 1 Anfrage 32 Anfragen 64 Anfragen 79 tok/s 432 tok/s 439 tok/s 111 ms bis zur ersten 468 ms bis zur ersten 7,6 s bis zur ersten Antwort (TTFT) Antwort (TTFT) Antwort (TTFT) Bei 64: Der Durchsatz steigt kaum noch, die erste Antwort kommt aber viel später. Qwen 3.6-35B-A3B MoE · DGX Spark GB10 mit 128 GB Unified Memory · Betriebsbaseline mit 256 erzeugten Tokens pro Anfrage.
17. LOKALER EINSTIEG Drei Werkzeuge, drei Einsatzorte Wofür? Ollama LM Studio vLLM Primärer Zweck Lokales Entwickeln Desktop-Exploration Zentraler Serving-Betrieb Zielgruppe Entwickler:innen Technische Fachanwender:innen Plattform- und Infra-Team Mehrnutzerbetrieb Begrenzt Nicht der Fokus Kernanwendungsfall API-Integration Einfach Vorhanden OpenAI-compatible, produktionsnah Hardware-Auslastung Unkompliziert Desktop-orientiert Batching, Throughput, Scheduler Ollama und LM Studio sind gute Werkzeuge für ihren Platz. vLLM, wenn daraus ein geteilter Unternehmensdienst wird.
18. SERVING Warum vLLM im Serverraum Request A Request B Request C Request D Continuous Batching GPU Antworten gehen wieder an den passenden Client.
19. BETRIEB Aus Modellgewichten wird ein Dienst. Download · Container · Serving
20. BETRIEB / 01 Hugging Face: erst authentifizieren, dann herunterladen export HF_TOKEN="..." huggingface-cli download \ Qwen/Qwen3.6-35B-A3B-NVFP4 \ --local-dir ./aeon-model Gated Models: Zugriff im Hugging-Face-Modellkatalog bestätigen. Das Token bleibt außerhalb von Shell-Historie und Folien.
21. BETRIEB / 02 Der vLLM-Startparameter docker run -d --name qwen --gpus all --ipc=host -p 8000:8000 \ --restart unless-stopped \ -e HF_TOKEN="$HF_TOKEN" \ -e VLLM_API_KEY="$PL_VLLM_APIKEY" \ -v ./aeon-model:/model:ro \ -v ./aeon-drafter:/drafter:ro \ -v ./vllm-cache:/root/.cache/vllm \ --entrypoint vllm \ ghcr.io/aeon-7/aeon-vllm-ultimate:latest \ serve /model --served-model-name qwen3 --host 0.0.0.0 --port 8000 \ --api-key "$PL_VLLM_APIKEY" \ --quantization compressed-tensors --max-model-len 262144 \ --max-num-seqs 64 --max-num-batched-tokens 16384 \ --gpu-memory-utilization 0.85 --enable-chunked-prefill \ --enable-prefix-caching --trust-remote-code \ --limit-mm-per-prompt '{"image":4,"video":2}' \ --enable-auto-tool-choice --tool-call-parser qwen3_coder \ --reasoning-parser qwen3 --attention-backend flash_attn \ --speculative-config '{"method":"dflash","model":"/drafter","num_speculative_tokens":11}' Wichtig: Die Variablennamen sind Teil der Folie, die Werte bleiben im Environment.
22. BETRIEB / 03 Die Parameter, die Kapazität bestimmen --max-model-len --gpu-memory-utilization Maximale Kontextlänge. Bestimmt mit, wie viel KV Cache und VRAM reserviert wird. VRAM-Budget für vLLM. Reserve für Treiber und andere Prozesse einplanen. --max-num-seqs --max-num-batched-tokens Obergrenze paralleler Sequenzen. Mehr Parallelität braucht mehr KV Cache. Token-Budget pro Scheduler-Schritt. Steuert den Throughput-/Latenz-Trade-off. --enable-prefix-caching --speculative-config Gemeinsame Prompt-Präfixe wiederverwenden, Ein kleines Drafter-Modell schlägt Tokens vor; etwa System Prompts oder RAG-Kontext. das Zielmodell prüft sie schneller.
23. LIVE DEMO Live im internen System mit lokalem Modell.
24. PRAXIS Meine Use Cases Systemmigrationen analysieren Große Datenmengen zwischen Systemen vergleichen, strukturieren und für die Migration auswerten. Browser-Erweiterung für Zusammenfassungen und RAG Ein Plugin für die bestehende Weboberfläche fasst Inhalte zusammen und beantwortet Fragen aus internen Quellen. Open WebUI als interner Wissenszugang Interne Dokumente sicher durchsuchen und mit lokal betriebenen Modellen nutzbar machen.
25. ZUM MITNEHMEN Lokale KI ist kein Modell-Download. Sie ist eine Infrastrukturentscheidung. Modell und Lizenz Quantisierung und VRAM Serving und Mehrnutzerlast Datenpfad und Evaluierung