On-Premise LLM produktiv: von Ollama-Test zu vLLM mit Load Balancing

Pexon Consulting | 10 Min. Lesezeit | 09.06.2026

TL;DR

On-Premise LLM produktiv ist 2026 der typische Pfad nach dem Ollama-Pilot: Ollama ist exzellent für den ersten Test auf dem Laptop oder einer Single-GPU, bricht aber unter produktiver Last. Pexon Consulting baut die Production-Pipeline mit vLLM auf H100- oder L40S-Clustern, mit Load Balancing über Litellm-Proxy, Monitoring und automatischem Failover. Der Übergang von „läuft auf meinem Mac“ zu „100 Konstrukteure nutzen es täglich“ ist eine Engineering-Disziplin, nicht ein Konfigurations-Klick.

Warum Ollama produktiv nicht funktioniert

Wir sehen das Pattern aktuell wöchentlich: Ein IT-Leiter eines Mittelständlers hat mit Ollama auf einer RTX 4090 Qwen 3.5 oder Llama 3.3 zum Laufen gebracht, ist beeindruckt vom Tempo, und denkt, „das skalieren wir jetzt einfach auf eine größere Maschine“. Drei Wochen später sitzt der erste Pilotkunde mit zehn gleichzeitigen Nutzern auf dem Setup und das System fällt unter Last zusammen.

Ollama ist ein hervorragendes Werkzeug für Single-User-Lokalbetrieb. Es lädt das Modell, hält es im VRAM, antwortet schnell für eine Anfrage zur Zeit. Was Ollama nicht macht: PagedAttention, Continuous Batching, dynamische Routing-Entscheidungen über parallele Requests. Das sind die Komponenten, die ein LLM-Server für mehrere parallele Nutzer überhaupt erst tragfähig machen.

Konkret bedeutet das: Bei 20 parallelen Konstrukteur-Sessions liefert Ollama 3-8 Sekunden Antwortzeit, weil jede Session in der Queue warten muss. vLLM auf gleicher Hardware liefert 0,6-1,5 Sekunden, weil parallele Sessions zusammen gebatched und mit PagedAttention effizient durch die GPU geschoben werden. Das ist nicht „ein bisschen schneller“, das ist der Unterschied zwischen „nutzbar“ und „nicht nutzbar“.

Was vLLM in der Praxis macht

vLLM ist seit 2024 die De-Facto-Engine für produktives LLM-Serving auf eigener Hardware. Kernkomponenten:

PagedAttention ist die zentrale Innovation. Statt für jede Session den vollständigen KV-Cache zu reservieren, teilt vLLM den GPU-Speicher in kleine Blöcke, die dynamisch zwischen Sessions wandern. Damit passen 80-120 parallele Sessions auf eine H100, wo Ollama bei 5-8 Sessions schon am Limit ist.

Continuous Batching schaufelt Anfragen, die zu unterschiedlichen Zeiten reinkommen, in den gleichen GPU-Forward-Pass. Statt der „Session 1 fertig, dann Session 2 starten“-Logik laufen alle Sessions parallel auf dem gleichen Forward, sobald sie da sind. Das vervielfacht den Throughput.

OpenAI-kompatible API. vLLM exponiert die gleiche API wie OpenAI. Apps und LiteLLM-Proxies sprechen es transparent an, ohne Code-Änderung.

Tool-Calling-Support ist seit vLLM 0.7 produktiv stabil. Für Modelle wie Qwen 3.5 oder Llama 3.3 funktioniert das mit den richtigen Parser-Flags (typisch --tool-call-parser qwen3_coder oder hermes).

Setup-Befehl für einen produktiven Server:

vllm serve Qwen/Qwen3.5-Medium-122B-A10B 
  --tensor-parallel-size 2 
  --enable-auto-tool-choice 
  --tool-call-parser qwen3_coder 
  --max-model-len 32768 
  --gpu-memory-utilization 0.9 
  --port 8000

Production-Architektur: vLLM-Cluster mit Load Balancing

Single-vLLM auf einer H100 trägt 80-200 parallele Sessions. Für viele Mittelstand-Setups reicht das. Bei größerem Bedarf oder für Hochverfügbarkeit bauen wir einen Cluster.

Pexon-Standard-Architektur für 300-1.500 User:

Drei vLLM-Instanzen auf drei H100- oder L40S-Clusters, jede mit der gleichen Modell-Konfiguration. Tensor-parallele Verteilung wenn das Modell nicht auf eine GPU passt (z.B. Qwen 3.5 122B in 4-Bit AWQ auf 1x H100, in 16-Bit auf 2x H100 mit Tensor-Parallelism).

LiteLLM-Proxy als Load Balancer und Router davor. LiteLLM kennt die drei Backends, routet basierend auf aktueller Last (least-busy oder round-robin), failovert automatisch bei Outage einer Instanz. Mehr zu LiteLLM im LiteLLM-Router-Blog.

Reverse Proxy mit TLS (Caddy oder nginx) vor LiteLLM. Terminiert TLS, bietet Standard-Auth, kann Rate-Limits durchsetzen.

Monitoring-Stack. Prometheus + Grafana für GPU-Auslastung, Token-Throughput, p99-Latenz, Memory-Usage. vLLM exportiert die wichtigsten Metriken nativ. Alerting auf hohe HBM-Errors oder Latenz-Spikes.

Auto-Restart auf systemd-Level bei vLLM-Crashes oder OOM. Plus optional Kubernetes-Pod-Restart, wenn ihr K8s nutzt.

Hardware-Optionen 2026

Pragmatische Faustregel: Für PoC und Dev-Maschinen RTX 4090. Für 50-200 User produktiv L40S oder RTX 6000 Ada. Für 300+ User H100. Für Hochlast-Setups oder höhere Modell-Qualität H200 oder Multi-H100.

Häufig gestellte Fragen

Können wir Ollama nicht einfach skalieren?

Theoretisch ja, praktisch nein. Ollama-Skalierung bedeutet, mehrere Ollama-Instanzen hinter einen Load Balancer zu schalten — was funktioniert, aber den GPU-Memory verschwendet, weil jede Instanz das Modell separat lädt. vLLM nutzt PagedAttention, sodass eine Instanz mehrere parallele Sessions effizient bedient. Bei gleicher Hardware liefert vLLM 8-15x höheren Throughput. Für Production-Workloads ist Ollama nicht die richtige Wahl.

Welche Modell-Größe für unseren Use-Case?

Faustregel aus unseren Projekten: Unter 35B Parametern wird Tool-Use unzuverlässig. Qwen 3.5 35B-A3B (MoE mit 3B aktiven Parametern) ist die kleinste Größe, die wir produktiv empfehlen. Für höhere Genauigkeit Qwen 3.5 Medium 122B-A10B oder Llama 3.3 70B. Für Frontier-Niveau gibt es aktuell kein wirklich konkurrenzfähiges Open-Source-Modell — da bleibt Claude oder GPT über Cloud-Provider.

Wie skaliert das mit der User-Zahl?

Eine H100 mit Qwen 3.5 Medium 122B AWQ trägt etwa 80-200 parallele aktive Sessions. Bei einem typischen Mittelstand-Nutzungsmuster (User aktiv 5-15% der Arbeitszeit) entspricht das 1.000-2.500 nominalen Usern. Bei moderaterem Nutzungsmuster mehr. Für 3.000+ User braucht ihr einen Cluster aus 2-3 H100-Instanzen.

Was kostet die Strom-Rechnung wirklich?

Eine H100 zieht typisch 350-700W bei Volllast. Bei 24/7-Betrieb sind das rund 5.000-9.000 kWh pro Jahr, in Deutschland bei Industrie-Stromtarif rund 1.200-2.700 EUR pro Jahr. Plus Kühlung typisch nochmal 30-50% obenauf. Insgesamt rund 1.800-4.000 EUR Strom-Kosten pro H100 pro Jahr.

Lohnt sich das gegenüber Bedrock Frankfurt?

Bei kontinuierlichem Volumen ab 2.500 EUR Bedrock-Bill pro Monat fängt es an, wirtschaftlich zu werden. Bei 5.000-7.000 EUR pro Monat ist die On-Prem-Variante klar günstiger. Bei niedrigerem Volumen oder bursty Workload bleibt Bedrock die richtige Wahl. Mehr zur Kalkulation im Self-Hosted Agent Stack Blog.

Nächster Schritt

Wenn euer Ollama-Pilot ans Limit kommt und produktive Skalierung ansteht: Wir machen einen 60-Minuten-Call mit dir und idealerweise einem Senior-Infrastruktur-Engineer. Du beschreibst Last-Erwartung und Modell-Wahl, wir skizzieren Hardware und Cluster-Architektur mit Festpreis-Sprint.

Verwandte Themen