KI lokal hosten 2026: Server-Empfehlung für 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 mittelständischen 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 läuft komplett im eigenen Rack. Wir zeigen, welche Hardware für welches Modell in Frage kommt, welche VRAM-Faustregeln zählen, wo Ollama endet und vLLM anfängt, und wann sich die Investition wirklich lohnt. Ohne erfundene Benchmarks und ohne feste Endpreise — der Markt für GPU-Karten schwankt zu stark, als dass eine Zahl in einem Blog-Post länger als drei Wochen halten würde.

Wer die grundsätzliche 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 für den Fall, dass die Entscheidung für den eigenen Server gefallen ist.

Warum KI lokal hosten 2026 zur echten Option wird

Drei Treiber bringen das Thema regelmäßig 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 lösen 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 übersehen werden, haben wir in DSGVO-Auftragsverarbeitung — typische Fehler in KMU zusammengefasst.

Laufende Cloud-Token-Kosten

Ein Entwicklerteam mit fünf Kolleginnen und Kollegen, die den ganzen Tag mit einem Coding-Assistenten arbeiten. Eine Rechnungsprüfung, 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-Güte auch größere Kontexte füttert. Ab einer bestimmten Auslastungsschwelle rechnet sich ein LLM-Server im eigenen Rack schlicht besser. Die Amortisation liegt bei mittelständischen Setups typischerweise zwischen zwölf und vierundzwanzig Monaten — konservativ gerechnet.

Latenz, Verfügbarkeit und Offline-Fähigkeit

Ein lokaler Endpoint antwortet in einstelligen Millisekunden auf den ersten Token. Ein Cloud-Endpoint in einem europäischen Rechenzentrum antwortet — günstigsten Falls — in 80 bis 200 Millisekunden auf den ersten Token, plus die Zeit für die Warteschlange beim Anbieter. Für eine interaktive Anwendung, in die ein Modell live schreibt, ist der Unterschied spürbar. Für eine Anwendung, die morgen früh fertig sein muss und heute Nacht läuft, ist der Unterschied irrelevant. Der Punkt: Die Entscheidung für lokal ist auch eine UX-Entscheidung.

LLM Server Mittelstand — welche GPU-Klasse braucht es wirklich

Der Markt für produktive LLM-GPUs ist 2026 übersichtlicher, 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-Gehäuse ohne dedizierte Kühlungsplanung und ist die günstigste Neu-Karte, die man ernsthaft in Produktion stellen kann. Sinnvoll für: 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 größere Kontexte will, stößt 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 ähnlicher Leistungsklasse. Beide Karten sind der De-facto-Standard 2026 für den Mittelstand, wenn “richtige” Modelle produktiv laufen sollen: 30B in guter Quantisierung, 70B in 4-Bit, mehrere kleinere Modelle parallel, ordentliche Kontextlängen. 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 täglich Dutzende Nutzer parallel bedient, größere 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 für 70B-Modelle in höherer Präzision. Aber: Datacenter-Kühlung, hoher Stromverbrauch, hoher Anschaffungspreis (typisch fünfstellig pro Karte). Für 90 Prozent der Mittelstands-Setups übertrieben. Auf Anfrage rechnen wir das gerne durch.

Nicht im Rennen für Production: RTX 4090/5090. Verlockend günstig, aber Nvidia-EULA verbietet Datacenter-Einsatz, keine ECC, keine 24/7-Freigabe. Für die Entwickler-Workstation OK, im Serverraum nicht.

VRAM-Faustregeln für 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 für Kontext und KV-Cache. Für 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. Für 70B in höherer Präzision oder größere 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 für deutschsprachige Aufgaben, gute Instruction-Follow-Qualität, kompakter Footprint.
• Llama 3.1/3.3: breites Ökosystem, gute Feintuning-Basis, viele fertige Community-Varianten.
• Qwen 2.5: starke Coding- und Reasoning-Leistung, sehr solide auch bei längeren Kontexten, gute Mehrsprachigkeit.

Ollama Server für den Start — vLLM für 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 läuft auf Linux/Windows/macOS. Ideal für Prototypen, kleine Teams (bis ca. fünf parallele Nutzer), Entwickler-Sandbox und die erste RAG-Integration. Wer einen Ollama Server aufsetzt, hat in einer Stunde von “GPU eingesteckt” zu “erstes Token läuft” gearbeitet. Wichtig für den Serverraum: Ollama nicht ungesichert im LAN exponieren — Reverse-Proxy mit Authentifizierung davor, siehe Nginx Reverse-Proxy für Dienste oder als Alternative Caddy mit automatischem HTTPS.

vLLM — Continuous Batching für mehrere Nutzer

Sobald mehrere Nutzer gleichzeitig anfragen und die Antwortzeit zählt, ist Ollama nicht mehr die richtige Wahl. Dann übernimmt 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+ möglich — exakte Zahlen hängen an Modell, Quantisierung und Kontextlänge und sollten pro Setup gemessen werden. vLLM erfordert mehr Konfigurationsarbeit, läuft aber stabil unter Last. Für produktive LLM-Endpoints im Mehrbenutzerbetrieb der Quasi-Standard 2026.

LiteLLM als OpenAI-kompatibler Proxy

Anwendungscode sollte nicht wissen müssen, 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” für jedes ernsthafte lokale Setup — damit man später wechseln kann, ohne den Anwendungscode anfassen zu müssen.

Server-Empfehlung für KI lokal hosten im Mittelstand

Drei Konfigurationen decken den Großteil 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 gewöhnen, RAG-Prototypen zu bauen, Anwendungsfälle zu identifizieren. Preisrahmen: unterer bis mittlerer vierstelliger Bereich für 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 für Modell-Cache, 25 GbE-Anbindung zur Storage. vLLM als Runtime, LiteLLM als Proxy. Ollama optional daneben für Entwickler-Tests. Genug für den täglichen Betrieb mit mehreren Nutzern parallel, Coding-Assistenz für ein Entwicklerteam, RAG-Backend für eine interne Wissensbasis. Preisrahmen: mittlerer bis oberer fünfstelliger Bereich — individuelles Angebot über unseren IT-Service Linux und Serversysteme.

Storage-Anbindung für den Modell-Cache

Große Modelle sind große Dateien. Llama 3.1 8B belegt ca. 16 GB als Original-Gewicht, Llama 3.3 70B ca. 140 GB, Qwen 2.5 72B in ähnlicher Größenordnung. Quantisierte Varianten sind kleiner, aber immer noch im zweistelligen GB-Bereich. Wir empfehlen für den Modell-Cache einen NVMe-Pool auf TrueNAS: eine zentrale Quelle für alle Inferenz-Server, Snapshots vor jedem Modell-Update, schnelles Nachladen über 25 oder 100 GbE, Versionierung über ZFS-Dataset-Properties. Die passende Systemgröße berechnet unser TrueNAS-Konfigurator transparent nach RAID-Level und Modell-Volumen.

DSGVO und Betrieb — was nach dem Kauf zählt

Ein LLM-Server ist ein sensibler Endpoint: Er hat — über 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 gehört 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 läuft in Sicherheitslücken. Ein Grafana-Dashboard für 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 müssen einer Aufbewahrungsstrategie folgen.

Grundhärtung des darunter liegenden Linux-Systems ist selbstverständlich — die 15-Minuten-Checkliste in Linux-Server-Härtung reicht als Startpunkt.

Wann sich der eigene LLM-Server NICHT lohnt

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

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

FAQ

Reicht eine einzige L4 (24 GB) für ein KMU?

Für ein kleines Team mit 7B- oder 14B-Modellen und überschaubarer Parallelität: ja, gut. Für 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 für Kontext und KV-Cache — also praktisch 48 GB VRAM als Untergrenze. In höherer Präzision oder mit sehr langen Kontexten kommt man ohne 80 GB nicht sinnvoll aus.

Ollama oder vLLM — was ist die richtige Wahl?

Ollama für Prototyp, kleine Teams und Entwickler-Workstations. vLLM für produktiven Mehrbenutzerbetrieb mit Anspruch an Durchsatz und stabile Latenz. LiteLLM davor, damit die Anwendung nicht weiß, was hinten läuft.

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, öffentliche Recherchen auf eine Cloud-API. Dieses hybride Muster ist 2026 die praktikabelste Lösung.

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 fünfstelligen 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 über Runtime bis Monitoring durchgehend begleitet.