KI lokal hosten 2026: Server-Empfehlung fuer Mistral, Llama und Qwen im Mittelstand

KI lokal hosten ist 2026 keine Bastel-Idee mehr. Was 2024 noch als teurer Sonderweg galt, ist heute in vielen mittelstaendischen IT-Umgebungen ein durchgerechneter Regelbetrieb: ein LLM-Server mit einer oder zwei GPUs, ein Modell aus der Mistral-, Llama- oder Qwen-Familie, dazu Ollama oder vLLM als Runtime — und die Konversation mit dem Modell laeuft komplett im eigenen Rack. Wir zeigen, welche Hardware fuer welches Modell in Frage kommt, welche VRAM-Faustregeln zaehlen, wo Ollama endet und vLLM anfaengt, und wann sich die Investition wirklich lohnt. Ohne erfundene Benchmarks und ohne feste Endpreise — der Markt fuer GPU-Karten schwankt zu stark, als dass eine Zahl in einem Blog-Post laenger als drei Wochen halten wuerde.

Wer die grundsaetzliche Frage “Cloud-API oder eigene GPU” noch nicht sortiert hat, findet die vorgelagerte Entscheidungshilfe in KI im Mittelstand — wann sich eigene GPU-Hardware lohnt. Hier geht es um den konkreten Bauplan fuer den Fall, dass die Entscheidung fuer den eigenen Server gefallen ist.

Warum KI lokal hosten 2026 zur echten Option wird

Drei Treiber bringen das Thema regelmaessig auf den Tisch — und zwar in dieser Reihenfolge.

DSGVO, Betriebsrat, Auftragsverarbeitung

Wer Kunden-, Personal-, Mandanten- oder Patientendaten in eine externe Chat-API kippt, hat ein Problem, das kein Preisschild loesen kann. Die Debatte um US-Cloud-Anbieter, Schrems II und die Frage, ob “no training, no logging”-Zusagen ausreichen, ist 2026 nicht befriedet — sie ist im Gegenteil in vielen Compliance-Abteilungen zum harten Nein geworden. Ein lokal betriebenes Modell nimmt diese Diskussion komplett vom Tisch: Die Daten verlassen das Haus nicht. Punkt. Details zur Auftragsverarbeitung, die oft uebersehen werden, haben wir in DSGVO-Auftragsverarbeitung — typische Fehler in KMU zusammengefasst.

Laufende Cloud-Token-Kosten

Ein Entwicklerteam mit fuenf Kolleginnen und Kollegen, die den ganzen Tag mit einem Coding-Assistenten arbeiten. Eine Rechnungspruefung, die pro Tag 800 Rechnungen automatisch klassifiziert. Ein Support-Kanal, der Tickets vorsortiert. Jeder dieser Workloads verbraucht Millionen Tokens pro Monat. Die Cloud-Rechnung steigt nicht mehr linear, sondern superlinear — weil man mit steigender Modell-Guete auch groessere Kontexte fuettert. Ab einer bestimmten Auslastungsschwelle rechnet sich ein LLM-Server im eigenen Rack schlicht besser. Die Amortisation liegt bei mittelstaendischen Setups typischerweise zwischen zwoelf und vierundzwanzig Monaten — konservativ gerechnet.

Latenz, Verfuegbarkeit und Offline-Faehigkeit

Ein lokaler Endpoint antwortet in einstelligen Millisekunden auf den ersten Token. Ein Cloud-Endpoint in einem europaeischen Rechenzentrum antwortet — guenstigsten Falls — in 80 bis 200 Millisekunden auf den ersten Token, plus die Zeit fuer die Warteschlange beim Anbieter. Fuer eine interaktive Anwendung, in die ein Modell live schreibt, ist der Unterschied spuerbar. Fuer eine Anwendung, die morgen frueh fertig sein muss und heute Nacht laeuft, ist der Unterschied irrelevant. Der Punkt: Die Entscheidung fuer lokal ist auch eine UX-Entscheidung.

LLM Server Mittelstand — welche GPU-Klasse braucht es wirklich

Der Markt fuer produktive LLM-GPUs ist 2026 uebersichtlicher, als er scheint. Drei Klassen decken 95 Prozent der Mittelstands-Szenarien ab.

Einstiegsklasse — Nvidia L4 mit 24 GB

Die L4 ist eine kompakte, sparsame Datacenter-Karte mit 24 GB VRAM und typischerweise 72 Watt TDP. Sie passt in fast jedes Rack-Server-Gehaeuse ohne dedizierte Kuehlungsplanung und ist die guenstigste Neu-Karte, die man ernsthaft in Produktion stellen kann. Sinnvoll fuer: 7B- bis 14B-Modelle in guter Quantisierung (Mistral 7B, Llama 3.1 8B, Qwen 2.5 7B/14B), Embedding-Modelle, kleinere RAG-Setups. Grenze: Wer 30B+ oder groessere Kontexte will, stoesst schnell an das VRAM-Limit.

Sweet Spot — L40S oder RTX Pro 6000 mit 48 GB

Die L40S ist die Datacenter-Variante mit 48 GB VRAM und 350 Watt TDP, die RTX Pro 6000 (Ada-Generation) ist die Workstation-Variante mit denselben 48 GB und aehnlicher Leistungsklasse. Beide Karten sind der De-facto-Standard 2026 fuer den Mittelstand, wenn “richtige” Modelle produktiv laufen sollen: 30B in guter Quantisierung, 70B in 4-Bit, mehrere kleinere Modelle parallel, ordentliche Kontextlaengen. Preisrahmen: mittlerer bis oberer vierstelliger Bereich pro Karte — Tagespreise auf Anfrage, da der Markt weiterhin volatil ist.

Production-Klasse — H100/H200 mit 80 bis 141 GB

Wer taeglich Dutzende Nutzer parallel bedient, groessere Modelle (100B+) hosten oder Fine-Tuning betreiben will, landet bei H100 oder H200. Die H200 verdoppelt den Speicher der H100 auf 141 GB HBM3e und ist damit die aktuell komfortabelste Karte fuer 70B-Modelle in hoeherer Praezision. Aber: Datacenter-Kuehlung, hoher Stromverbrauch, hoher Anschaffungspreis (typisch fuenfstellig pro Karte). Fuer 90 Prozent der Mittelstands-Setups uebertrieben. Auf Anfrage rechnen wir das gerne durch.

Nicht im Rennen fuer Production: RTX 4090/5090. Verlockend guenstig, aber Nvidia-EULA verbietet Datacenter-Einsatz, keine ECC, keine 24/7-Freigabe. Fuer die Entwickler-Workstation OK, im Serverraum nicht.

VRAM-Faustregeln fuer Mistral, Llama und Qwen

Die simple Regel: Modell-Parameter mal Bits pro Parameter durch 8 gleich VRAM-Bedarf in GB, plus 15 bis 30 Prozent Overhead fuer Kontext und KV-Cache. Fuer den Alltag reicht diese Tabelle:

Modell-Klasse	4-Bit-Quantisierung	8-Bit	FP16 / voll
7B (Mistral 7B, Llama 3.1 8B, Qwen 2.5 7B)	ca. 6 GB	ca. 10 GB	ca. 16 GB
13B / 14B (Qwen 2.5 14B)	ca. 10 GB	ca. 16 GB	ca. 28 GB
30B / 34B	ca. 20 GB	ca. 35 GB	ca. 65 GB
70B (Llama 3.3 70B, Qwen 2.5 72B)	ca. 40 GB	ca. 75 GB	ca. 140 GB

Praktisch bedeutet das: Auf einer L4 (24 GB) laufen 7B/14B-Modelle komfortabel. Auf einer L40S oder RTX Pro 6000 (48 GB) laufen 70B-Modelle in 4-Bit-Quantisierung, 30B in 8-Bit sehr entspannt. Fuer 70B in hoeherer Praezision oder groessere Kontexte braucht es 80+ GB VRAM — also H100/H200 oder zwei 48-GB-Karten mit Tensor-Parallelism.

Welches Modell im Mittelstand welchen Job macht — unsere Kurzformel:

• Mistral 7B / Mistral Small: solider Allrounder fuer deutschsprachige Aufgaben, gute Instruction-Follow-Qualitaet, kompakter Footprint.
• Llama 3.1/3.3: breites Oekosystem, gute Feintuning-Basis, viele fertige Community-Varianten.
• Qwen 2.5: starke Coding- und Reasoning-Leistung, sehr solide auch bei laengeren Kontexten, gute Mehrsprachigkeit.

Ollama Server fuer den Start — vLLM fuer die Last

Die Runtime ist mindestens so wichtig wie die GPU. 2026 haben sich drei Bausteine als Standard etabliert.

Ollama Server — Modelle in Minuten laden

Ollama ist die einfachste Art, ein LLM lokal zu betreiben: Ein Binary, ollama pull llama3.1, ollama serve — fertig. Die HTTP-API ist OpenAI-nahe, es gibt Container-Images, es laeuft auf Linux/Windows/macOS. Ideal fuer Prototypen, kleine Teams (bis ca. fuenf parallele Nutzer), Entwickler-Sandbox und die erste RAG-Integration. Wer einen Ollama Server aufsetzt, hat in einer Stunde von “GPU eingesteckt” zu “erstes Token laeuft” gearbeitet. Wichtig fuer den Serverraum: Ollama nicht ungesichert im LAN exponieren — Reverse-Proxy mit Authentifizierung davor, siehe Nginx Reverse-Proxy fuer Dienste oder als Alternative Caddy mit automatischem HTTPS.

vLLM — Continuous Batching fuer mehrere Nutzer

Sobald mehrere Nutzer gleichzeitig anfragen und die Antwortzeit zaehlt, ist Ollama nicht mehr die richtige Wahl. Dann uebernimmt vLLM: Continuous Batching, PagedAttention, sehr hohe Throughput-Effizienz. In der Praxis bedeutet das: Statt 20 Requests pro Sekunde bei Ollama sind auf derselben GPU 100+ moeglich — exakte Zahlen haengen an Modell, Quantisierung und Kontextlaenge und sollten pro Setup gemessen werden. vLLM erfordert mehr Konfigurationsarbeit, laeuft aber stabil unter Last. Fuer produktive LLM-Endpoints im Mehrbenutzerbetrieb der Quasi-Standard 2026.

LiteLLM als OpenAI-kompatibler Proxy

Anwendungscode sollte nicht wissen muessen, ob das Modell hinten Ollama, vLLM, OpenAI oder Mistral-Cloud spricht. LiteLLM bietet einen OpenAI-kompatiblen Endpoint mit Routing, API-Keys, Rate-Limits, Kostenverfolgung und Logging. Wir empfehlen die Kombination “LiteLLM vorne, vLLM hinten” fuer jedes ernsthafte lokale Setup — damit man spaeter wechseln kann, ohne den Anwendungscode anfassen zu muessen.

Server-Empfehlung fuer KI lokal hosten im Mittelstand

Drei Konfigurationen decken den Grossteil der Anfragen ab, die wir 2026 in der Beratung sehen.

Prototyp / Entwickler-Workstation

Ein Tower- oder Kompakt-Server mit einer L4 oder RTX Pro 6000, 128 GB RAM, 2 TB NVMe. Ollama als Runtime, ein 7B- bis 14B-Modell im Cache. Ideal, um die Organisation an den Umgang mit lokalen LLMs zu gewoehnen, RAG-Prototypen zu bauen, Anwendungsfaelle zu identifizieren. Preisrahmen: unterer bis mittlerer vierstelliger Bereich fuer die Hardware — konkrete Konfiguration und Preis auf Anfrage.

KMU-Production — Rack-Server mit ein bis zwei GPUs

Ein 2HE- oder 4HE-Rack-Server mit ein oder zwei L40S/RTX Pro 6000, 256 GB RAM, redundantes Netzteil, 8 TB NVMe fuer Modell-Cache, 25 GbE-Anbindung zur Storage. vLLM als Runtime, LiteLLM als Proxy. Ollama optional daneben fuer Entwickler-Tests. Genug fuer den taeglichen Betrieb mit mehreren Nutzern parallel, Coding-Assistenz fuer ein Entwicklerteam, RAG-Backend fuer eine interne Wissensbasis. Preisrahmen: mittlerer bis oberer fuenfstelliger Bereich — individuelles Angebot ueber unseren IT-Service Linux und Serversysteme.

Storage-Anbindung fuer den Modell-Cache

Grosse Modelle sind grosse Dateien. Llama 3.1 8B belegt ca. 16 GB als Original-Gewicht, Llama 3.3 70B ca. 140 GB, Qwen 2.5 72B in aehnlicher Groessenordnung. Quantisierte Varianten sind kleiner, aber immer noch im zweistelligen GB-Bereich. Wir empfehlen fuer den Modell-Cache einen NVMe-Pool auf TrueNAS: eine zentrale Quelle fuer alle Inferenz-Server, Snapshots vor jedem Modell-Update, schnelles Nachladen ueber 25 oder 100 GbE, Versionierung ueber ZFS-Dataset-Properties. Die passende Systemgroesse berechnet unser TrueNAS-Konfigurator transparent nach RAID-Level und Modell-Volumen.

DSGVO und Betrieb — was nach dem Kauf zaehlt

Ein LLM-Server ist ein sensibler Endpoint: Er hat — ueber den RAG-Kontext — potentiell Zugriff auf alle internen Dokumente, die man ihm zum Antworten anbietet. Zwei Grundregeln:

Kein LLM-Endpoint ohne Authentifizierung. LiteLLM mit API-Keys, dahinter ein Reverse-Proxy mit Single-Sign-on — praktikabel z.B. mit Authentik, siehe Authentik als Single-Sign-on. Netzwerksegmentierung nicht vergessen: Der GPU-Host gehoert nicht ins flache Client-Netz.

Monitoring, Modell-Updates, Audit-Logging. Wer den LLM-Server auf setzt und dann jahrelang nichts anfasst, verpasst Modell-Verbesserungen und laeuft in Sicherheitsluecken. Ein Grafana-Dashboard fuer GPU-Auslastung, VRAM, Temperatur, Request-Latenz und Fehlerraten ist Pflicht — siehe Grafana, Prometheus und Loki als Self-Hosted-Stack. Audit-Logs der Prompts sind DSGVO-relevant und muessen einer Aufbewahrungsstrategie folgen.

Grundhaertung des darunter liegenden Linux-Systems ist selbstverstaendlich — die 15-Minuten-Checkliste in Linux-Server-Haertung reicht als Startpunkt.

Wann sich der eigene LLM-Server NICHT lohnt

Ehrlichkeit gehoert dazu. Drei Konstellationen, in denen wir vom Kauf abraten — oder zumindest zu einem sehr kleinen Setup:

• Sehr niedrige Nutzung. Wenn das Modell taeglich weniger als eine Stunde tatsaechlich rechnet, brennt die GPU Strom, ohne Wert zu schaffen. Cloud-API bleibt guenstiger.
• Wenige Nutzer, kurze Interaktionen. Zwei Personen, die einmal am Tag eine Frage stellen, brauchen keinen eigenen Ollama Server. Ein DSGVO-konformer europaeischer API-Anbieter reicht.
• Kein internes Know-how, keine Bereitschaft, welches aufzubauen. Eine GPU zu kaufen ist einfach. Sie ueber Jahre produktiv zu halten — Treiber, CUDA, Modell-Updates, Monitoring, Sicherheit — ist Arbeit. Ohne mindestens eine Person, die diese Rolle uebernimmt (intern oder ueber uns als Systemhaus), wird die Karte zur Staubsammlerin.

FAQ

Reicht eine einzige L4 (24 GB) fuer ein KMU?

Fuer ein kleines Team mit 7B- oder 14B-Modellen und ueberschaubarer Parallelitaet: ja, gut. Fuer 30B+ oder mehrere Nutzer parallel unter hoher Last: nein, dann besser L40S oder RTX Pro 6000.

Wie viel VRAM braucht Llama 3.3 70B?

In 4-Bit-Quantisierung ca. 40 GB, plus 10 bis 20 GB fuer Kontext und KV-Cache — also praktisch 48 GB VRAM als Untergrenze. In hoeherer Praezision oder mit sehr langen Kontexten kommt man ohne 80 GB nicht sinnvoll aus.

Ollama oder vLLM — was ist die richtige Wahl?

Ollama fuer Prototyp, kleine Teams und Entwickler-Workstations. vLLM fuer produktiven Mehrbenutzerbetrieb mit Anspruch an Durchsatz und stabile Latenz. LiteLLM davor, damit die Anwendung nicht weiss, was hinten laeuft.

Kann ich lokale und Cloud-Modelle mischen?

Ja, das ist sogar der Regelfall im Mittelstand. LiteLLM routet nach Modellname oder Policy: sensible Daten aufs lokale Modell, oeffentliche Recherchen auf eine Cloud-API. Dieses hybride Muster ist 2026 die praktikabelste Loesung.

Was kostet ein LLM-Server im Mittelstand?

Preisrahmen: eine Prototyp-Workstation liegt im unteren bis mittleren vierstelligen Bereich, ein produktiver Rack-Server mit ein bis zwei GPUs im mittleren bis oberen fuenfstelligen Bereich. Feste Endpreise geben wir nicht in einem Blog-Post — der GPU-Markt schwankt zu stark. Wir rechnen pro Setup ein individuelles Angebot.

Wie starte ich konkret?

Wir empfehlen einen kurzen Discovery-Termin: Use Cases, DSGVO-Rahmen, erwartete Auslastung, Storage-Situation. Daraus leitet sich die passende Konfiguration ab — vom Ein-GPU-Prototyp bis zum produktiven Rack-Server inklusive TrueNAS-Modell-Storage. Ansprechpartner ist unser Linux-Serversystem-Team, das die Umsetzung von Hardware ueber Runtime bis Monitoring durchgehend begleitet.