Cloud-LLMs sind komfortabel — und für viele Mittelständler aus DSGVO-, Datenhoheits- und Kostengründen schlicht ungeeignet. Wir zeigen, wie ein produktionsreifer On-Premise-Stack aussieht: vLLM als Inference-Engine, MiniMax M2.5 für agentische Workloads, Qwen3 27B für Reasoning und GPT OSS 120B als Mitarbeiter-Chatbot. Architektur, GPU-Sizing, Anwendungsfälle und der Betrieb in deutschen Rechenzentren.
Die Argumentation für eigenen KI-Betrieb hat sich 2025/26 grundlegend gewandelt. Noch 2023 war die Antwort einfach: „Nimm OpenAI." Heute ist sie es nicht mehr — aus drei Gründen, die sich gleichzeitig verstärkt haben: regulatorischer Druck, Modell-Kommodifizierung und betriebswirtschaftliche Realitäten.
Auf der Regulierungsseite hat der EU AI Act konkrete Pflichten geschaffen, die jenseits der DSGVO wirken: Risikoklassifikation, Transparenzpflichten, Dokumentation der Datenflüsse, Audit-Fähigkeit. Wer im Mittelstand mit personenbezogenen Daten, Geschäftsgeheimnissen oder geistigem Eigentum hantiert und diese Daten in einen US-Cloud-LLM-Endpoint schickt, hat ein konkretes Compliance-Problem — kein theoretisches. Für KRITIS-Betreiber und NIS-2-pflichtige Unternehmen ist der Drittland-Transfer ohnehin nicht mehr darstellbar.
Auf der Modellseite hat sich der Abstand zwischen geschlossenen und offenen Modellen drastisch verringert. Wo 2023 noch GPT-4 die unangefochtene Spitze bildete, liegen heute Open-Weights-Modelle wie Qwen3, MiniMax M2 oder Llama 4 in vielen Benchmarks gleichauf — und in manchen Aufgaben (Tool Use, mehrsprachiges Reasoning, Code-Generierung) sogar voraus. Was vor zwei Jahren ein technischer Kompromiss war, ist heute eine pragmatische Wahl mit überlegenen Eigenschaften für viele Enterprise-Use-Cases.
Auf der Wirtschaftsseite verschiebt sich das Kostenkalkül mit zunehmender Nutzung. Eine einzelne Token-Anfrage in der Cloud kostet wenig — aber bei 50 Mitarbeitenden, die täglich 100.000 Tokens generieren, ergeben sich schnell vier- bis fünfstellige Monatskosten. Eine eigene GPU-Plattform ist eine Capex-Investition mit kalkulierbaren Opex-Werten — und nach 18 bis 24 Monaten in den meisten Szenarien günstiger als äquivalente Cloud-API-Calls.
Kurzfassung: On-Premise KI ist 2026 keine Sonderlocke mehr, sondern für viele Mittelständler die rationalere Wahl. Vorausgesetzt, der Stack ist richtig gewählt — und genau hier kommen vLLM, MiniMax M2.5 und Qwen3 27B ins Spiel.
Wir haben uns nach Evaluation mehrerer Alternativen auf eine klare Stack-Architektur festgelegt, die Stabilität, Performance und Wartbarkeit balanciert. Das Ziel: produktionsreifer Betrieb für Kunden mit echten SLAs, nicht ein Hobby-Setup.
Diese Komponenten sind nicht zufällig gewählt. Jede einzelne hat in den letzten 18 Monaten produktive Belastung in Kundenumgebungen gesehen — und wir wissen, wo die Kanten liegen.
vLLM ist das Industrie-Standard-Framework für hochperformante LLM-Inference auf NVIDIA-GPUs. Im Gegensatz zu Ollama (entwickler-orientiert, single-user) oder llama.cpp (CPU/Edge) ist vLLM von Grund auf für produktiven Multi-User-Betrieb konzipiert. Drei technische Innovationen heben es ab.
Der Kontext eines LLM (die "Erinnerung" an Prompt und bisherige Tokens) wird im sogenannten Key-Value-Cache (KV-Cache) gespeichert. Klassische Implementierungen reservieren für jede Anfrage einen kontinuierlichen GPU-Speicherblock in maximaler Größe — was zu massiver Speicher-Fragmentierung und schwacher Auslastung führt. PagedAttention ist eine Methode, die — analog zum virtuellen Speicher in Betriebssystemen — den KV-Cache in feste Blöcke (Pages) zerlegt und nur bei Bedarf zuweist. Resultat: Dieselbe Hardware verarbeitet zwei- bis viermal so viele parallele Anfragen, weil der GPU-Speicher endlich vollständig genutzt wird.
Klassisches Static Batching wartet, bis alle Anfragen einer Batch fertig sind, bevor neue eingespeist werden. Continuous Batching dagegen entfernt fertige Anfragen aus der Batch und schiebt neue ein, sobald GPU-Slots frei werden. Bei stark variierender Antwortlänge — typisch im Chat-Betrieb — verdoppelt das die effektive Throughput-Rate, ohne Latenz-Nachteile für einzelne User.
vLLM unterstützt eine breite Palette an Quantisierungsformaten. Für Qwen3 27B verwenden wir typischerweise AWQ-Int4 (Activation-aware Weight Quantization) — das halbiert den VRAM-Bedarf von ca. 54 GB auf ca. 16 GB bei einem Qualitätsverlust unterhalb der Messbarkeitsschwelle in deutschen Aufgaben. Für MiniMax M2.5 setzen wir FP8 ein, was die nativen Hopper-Tensor-Cores der H100 voll ausnutzt und eine Throughput-Steigerung von ca. 80% gegenüber BF16 bringt.
Die Modellauswahl ist die folgenreichste Designentscheidung im gesamten Stack. Wir haben über sechs Monate eine breite Auswahl an Open-Weights-Modellen unter realen Kunden-Workloads getestet. Aus dem Spielfeld haben sich drei Modelle als ergänzendes Trio herauskristallisiert: MiniMax M2.5 für Agentik und Coding, Qwen3 27B für Reasoning und mehrsprachige Fachsprache, und seit Kurzem GPT OSS 120B als ergonomischer Mitarbeiter-Chatbot. Drei Modelle, die unterschiedliche Stärken abdecken — und einen Großteil der Use Cases im Mittelstand sauber bedienen.
MiniMax M2.5 ist ein Mixture-of-Experts-Modell (MoE) der zweiten Generation aus dem Hause MiniMax. Bei einer Gesamtparameterzahl von rund 230 Milliarden werden pro Token nur etwa 10 Milliarden aktiv geschaltet — was eine sehr günstige Inference-Effizienz bei gleichzeitig hoher Modellkapazität ergibt. Die zentralen Stärken aus unserer Praxis:
Qwen3 27B (technisch als Qwen3-30B-A3B in der MoE-Variante oder Qwen3-32B als Dense-Modell verfügbar — wir nutzen die im Markt gebräuchliche „27B"-Notation für die Klasse) ist Teil der dritten Qwen-Generation aus dem Hause Alibaba. Es ist das ergonomischste Allround-Modell, das wir derzeit kennen, und bringt zwei Eigenschaften mit, die im Mittelstandseinsatz Gold wert sind:
/think oder /no_think im Prompt) lässt sich das je Anfrage steuern — schnelle Antworten für FAQ, tiefes Reasoning für Analysen.GPT OSS 120B ist OpenAIs erstes Open-Weights-Modell seit GPT-2 und ist 2025 unter Apache-2.0-Lizenz erschienen. Was wie eine PR-Geste klingen mag, ist in der Praxis ein ernsthaftes Werkzeug: 117 Milliarden Gesamtparameter in Mixture-of-Experts-Architektur, davon nur rund 5 Milliarden aktive Parameter pro Token. Das macht GPT OSS 120B zum sparsamsten 120B-Klasse-Modell auf dem Markt — und zur ergonomischsten Wahl für unternehmensweite Chatbots, in denen Mitarbeitende den vertrauten OpenAI-Stil erwarten.
low, medium und high umschalten lässt. Auf MMLU, GPQA und AIME erreicht das Modell Werte nahe der geschlossenen OpenAI-Reasoning-Modelle — bei voller Kontrolle über die eigene Hardware.Die Praxis bei HostSpezial-Kunden: GPT OSS 120B wird zunehmend zum Default-Backend für den unternehmensweiten KI-Workplace-Chatbot — also für genau das, was Mitarbeitende im Tagesgeschäft als „den ChatGPT-Ersatz" wahrnehmen. Qwen3 27B bleibt erste Wahl für deutsche Fachsprache und Dokumentenanalyse, MiniMax M2.5 das Backend für Tool-Heavy-Agenten. GPT OSS 120B steht als drittes Modell nicht in Konkurrenz, sondern füllt die Lücke „freier, vertrauter, breit einsetzbarer Allround-Chat".
| Eigenschaft | MiniMax M2.5 | Qwen3 27B | GPT OSS 120B |
|---|---|---|---|
| Architektur | MoE (~230B / 10B aktiv) | Dense oder MoE-Variante | MoE (~117B / 5B aktiv) |
| Stärken | Tool Use, Coding, Agentic | Reasoning, Mehrsprachigkeit, Chat | Mitarbeiter-Chat, OpenAI-Stil, Reasoning |
| Kontextlänge | bis 256k Tokens | 32k–128k Tokens | bis 128k Tokens |
| Quantisierung im Einsatz | FP8 | AWQ-Int4 oder FP8 | nativ MXFP4 |
| VRAM-Bedarf | ~240 GB (4× H100) | ~32 GB (1× H100) | ~65 GB (1× H100) |
| Throughput (Single-GPU) | n/a (4× H100 nötig) | ~3 900 Tokens/s | ~2 700 Tokens/s |
| Lizenz | MiniMax Open License | Apache 2.0 | Apache 2.0 |
| Idealer Use Case | Agenten, Code, RAG mit Tools | Helpdesk, Übersetzung, Analyse | Mitarbeiter-Chatbot, Allround-Assistant |
Pragmatische Empfehlung: GPT OSS 120B als Default-Chatbot für die Belegschaft (vertrauter Stil, breite Verfügbarkeit, niedrige Akzeptanz-Hürde). Qwen3 27B als zweites Modell für deutsch-affine Reasoning- und Dokumenten-Workloads. MiniMax M2.5 als spezialisiertes Backend für agentische und Coding-Workflows. Ein Router im Gateway-Layer (LiteLLM) wählt das jeweils passende Modell automatisch — transparent für die Anwendung, optimal für Kosten und Qualität.
Die häufigste Frage in Erstberatungen: „Welche Hardware brauche ich konkret?" Die Antwort hängt vom erwarteten Lastprofil ab — aber für die typischen Mittelstandsszenarien lassen sich vier Konfigurationsklassen ableiten. Alle vier laufen produktiv in deutschen Rechenzentren bei HostSpezial-Kunden.
Reicht für Qwen3 27B in AWQ-Int4 oder alternativ GPT OSS 120B in MXFP4 mit ca. 30 parallelen Sessions und 2 700–3 000+ Tokens/s aggregiertem Throughput. Klassischer Einstieg in eine eigene LLM-Plattform — ein Modell, eine GPU, kein Cluster-Overhead.
GPT OSS 120B in MXFP4 belegt ca. 65 GB auf einer GPU, daneben passt Qwen3 27B in AWQ-Int4 auf dieselbe Karte oder die zweite — die freie GPU steht für Embedding-Workloads, RAG-Reranking oder einen dritten Modell-Slot zur Verfügung. Blackwell bringt native FP8- und FP4-Tensor-Cores mit; der Throughput pro Karte liegt bei aktuellen Modellen bei ~65–75 % einer H100 80GB — bei deutlich attraktiveren Anschaffungs- und Stromkosten.
Drei Modelle koexistent: Qwen3 27B und GPT OSS 120B je auf einer dedizierten GPU, MiniMax M2.5 mit Tensor-Parallel-Size 2 über die verbleibenden zwei GPUs verteilt. Deckt das gesamte Use-Case-Spektrum gleichzeitig ab — Mitarbeiter-Chat, Reasoning und Agentic-Workloads ohne Modellwechsel-Overhead.
Mehrfache redundante M-Cluster mit aktivem Load-Balancing und automatischem Failover. Modelle und KV-Cache werden synchronisiert, ein RZ-Ausfall bleibt für Anwendungen unsichtbar. Auf Wunsch mit hartem Mandanten-Isolations-Layer (MIG, dedizierte Namespaces, getrennte Audit-Logs).
Hardware-Tipp aus der Praxis: Unterschätzen Sie nicht die Kühlung und die Stromversorgung. Eine H100 zieht unter Volllast bis zu 700 Watt — ein 4er-Cluster also bis zu 3 kW alleine für die GPUs. In den meisten Bürogebäuden ist das nicht darstellbar. Co-Location in einem fachgerecht ausgestatteten Rechenzentrum ist für die meisten Mittelständler der wirtschaftlichere Weg.
Theorie ist gut, Anwendungen sind besser. Die folgenden Use Cases stammen aus realen HostSpezial-Kundenprojekten der letzten Monate — anonymisiert, aber inhaltlich repräsentativ.
Ein mittelständischer IT-Dienstleister mit 12 000 Endkunden und 80 000 Tickets/Jahr nutzt einen Helpdesk-Agenten auf Qwen3 27B im Stil unseres Managed Helpdesk. Das Modell klassifiziert eingehende Tickets, schlägt Lösungswege aus der Wissensdatenbank vor (RAG mit Qdrant) und beantwortet Standardfragen wie Passwort-Resets vollständig automatisch via Active-Directory-Integration. Ergebnis: 38% der Tickets werden ohne menschliche Beteiligung gelöst, durchschnittliche Erstantwortzeit von 4 Stunden auf 90 Sekunden gesunken.
Ein Software-Entwicklungshaus mit 45 Entwicklern setzt MiniMax M2.5 als internen Coding-Copilot ein. Der entscheidende Vorteil: Quellcode des Kunden verlässt zu keinem Zeitpunkt die Infrastruktur des Softwarehauses — ein hartes Compliance-Erfordernis vieler Endkunden, das mit Cloud-Lösungen wie GitHub Copilot oder Cursor nicht erfüllbar wäre. Integration: VS Code-Plugin gegen vLLM-OpenAI-API, Continue.dev als Frontend.
Eine mittelständische Steuerberatung verarbeitet monatlich rund 8 000 eingehende Belege, Verträge und Mandantenanschreiben. Qwen3 27B in Kombination mit einem OCR-Vorprozessor extrahiert strukturierte Daten, klassifiziert Dokumenttypen und schlägt Buchungsvorschläge vor. Compliance-Anforderung: Mandantendaten dürfen das Hausnetz nicht verlassen — On-Premise war hier keine Option, sondern eine Pflicht.
Ein Maschinenbau-Unternehmen mit 30 Jahren Bestand und mehreren Tausend technischen Dokumentationen, Schaltplänen und Reparaturhandbüchern hat alle Dokumente in eine Vektor-Datenbank überführt. Servicetechniker fragen über ein einfaches Chat-Interface auf Tablet oder Smartphone Reparaturanleitungen ab — auch offline-fähig durch lokalen Stack auf einem kleinen Edge-Server. Modell: Qwen3 27B wegen exzellenter deutscher Fachsprache. Lade- und Onboarding-Zeit für neue Servicetechniker um geschätzt 40% reduziert.
Ein Verbund von Medizinischen Versorgungszentren beantwortet mit einem Compliance-Bot Fragen zu Datenschutz, Hygienevorschriften und Abrechnungsregeln. DSGVO-relevant: Patientendaten werden zu keinem Zeitpunkt von der KI verarbeitet — der Bot arbeitet ausschließlich mit anonymisierten Regelwerken und Schulungsmaterial. Trotzdem war On-Premise zwingend, weil Klinikrichtlinien jeden externen API-Call mit Kontextinformationen über interne Prozesse untersagen.
Eine Industrie-Holding mit ca. 1 200 Mitarbeitenden an fünf Standorten hat ChatGPT firmenweit gesperrt — aus Sorge vor Geschäftsgeheimnissen, die in Cloud-Logs landen. Ersatz: ein interner Chatbot auf Basis von GPT OSS 120B, ausgespielt über ein Browser-Frontend mit SSO-Anbindung (Entra ID). Die Belegschaft nutzt den Bot für Texte, Übersetzungen, Tabellenlogik, Brainstorming, Code-Snippets — der gesamte „ChatGPT-Alltag", aber im eigenen Rechenzentrum. Akzeptanz: innerhalb von vier Wochen aktive Nutzung durch > 60% der Belegschaft, vergleichbar mit der vorher erlaubten ChatGPT-Nutzung. Schlüsselfaktor war der vertraute Antwortstil von GPT OSS 120B — alternative Open-Modelle hatten in der Vor-Evaluation deutlich schlechter abgeschnitten, schlicht weil sich die Antworten "anders anfühlten".
Die schlankeste Implementierung des Stacks nützt wenig, wenn die Anbindung an ERP, CRM, Ticketsystem und Dokumentenmanagement nicht funktioniert. Integration ist erfahrungsgemäß der Bereich, der die meiste Projektzeit verschlingt — und der über Erfolg oder Misserfolg entscheidet.
vLLM exponiert eine vollständig OpenAI-kompatible API: /v1/chat/completions, /v1/embeddings, Streaming via Server-Sent Events, Function Calling mit OpenAI-Schema. Das bedeutet konkret: Jede Anwendung, die heute gegen die OpenAI-API entwickelt ist — Chatbots, Frameworks wie LangChain oder LlamaIndex, fertige SaaS-Tools mit OpenAI-Integration — funktioniert ohne Code-Änderung gegen den lokalen vLLM-Endpunkt. Lediglich OPENAI_BASE_URL wird auf den internen Server umgestellt.
Direkt-Zugriff auf vLLM ist nur in Entwicklungsumgebungen sinnvoll. Im Produktivbetrieb steht ein Gateway davor — wir nutzen LiteLLM. Es übernimmt Authentifizierung (typischerweise gegen Active Directory oder Keycloak), Rate Limiting pro Nutzer/Team, Modell-Routing (richtige Anfrage an MiniMax M2.5 oder Qwen3 27B), Cost Tracking pro Kostenstelle und vollständiges Audit-Logging aller Anfragen mit Eingabe, Ausgabe und Metadaten — ein Pflicht-Feature für AI-Act-Compliance.
Für die meisten Unternehmens-Use-Cases ist Retrieval-Augmented Generation (RAG) der Hebel zwischen "interessantes Spielzeug" und "echter Geschäftswert". Dokumente aus SharePoint, Confluence, Dateifreigaben oder Ticketsystemen werden über Embedding-Modelle (z.B. bge-m3 oder multilingual-e5-large) in Vektoren überführt, in Qdrant oder pgvector als Vector-DB gespeichert und bei jeder Anfrage semantisch durchsucht. Das Ergebnis fließt in den Kontext des LLM — präzise, aktuell, ohne Modell-Retraining.
On-Premise-Betrieb löst das Datenschutz-Grundproblem (keine Drittland-Übertragung), schafft aber neue: Wer betreibt die GPUs, wer hat Zugriff, wie werden Modelle aktualisiert, wie wird missbräuchliche Nutzung verhindert? Eine professionelle Plattform muss alle diese Fragen sauber beantworten.
Der zentrale Vorteil: Keine personenbezogenen Daten verlassen die Hostumgebung. Auftragsverarbeitungsverträge nach Art. 28 DSGVO sind selbstverständlich, eine Datenschutz-Folgenabschätzung-Vorlage stellen wir bereit. Alle Logs werden in Deutschland gespeichert, Zugriff ist auf benannte Administrator:innen beschränkt und protokolliert.
Der EU AI Act fordert je nach Risikoklasse Dokumentation, Transparenz und Auditierbarkeit. Mit dem oben beschriebenen Gateway-Layer und vollständigem Logging ist die technische Grundlage für AI-Act-Konformität gegeben — die organisatorischen Pflichten (Risikobewertung, Schulung der Mitarbeitenden, Dokumentation der Anwendungsfälle) müssen daneben erfüllt werden, dabei beraten wir. Achten Sie zusätzlich auf Prompt-Injection-Schutz im Gateway und im Frontend, besonders wenn Nutzereingaben in Tool-Calls fließen.
Open-Weights-Modelle entwickeln sich weiter — etwa alle 3 bis 6 Monate erscheint eine relevante neue Version eines bestehenden Modells. Wir betreiben eine Staging-Umgebung, in der neue Modelle gegen einen Eval-Korpus aus echten (anonymisierten) Kundenanfragen getestet werden, bevor sie in Produktion gehen. Ein Wechsel von Qwen3 27B auf eine hypothetische Qwen3.5 27B ist damit ein kontrollierter Vorgang ohne Risiko für laufende Anwendungen.
Prometheus und Grafana liefern Metriken zu GPU-Auslastung, VRAM-Nutzung, Throughput, Latenzverteilungen und Fehlerquoten. Loki sammelt alle Anfrage-Logs zentral, mit konfigurierbarer Aufbewahrungsdauer pro Datenklasse. Alerting erfolgt über Alertmanager an Slack oder unsere ITSM-Ticket-Pipeline — dieselbe, die für unsere klassischen Managed-Hosting-Kunden im Einsatz ist.
HostSpezial betreibt seit 2010 Managed-Hosting-Infrastruktur in deutschen Rechenzentren. Die KI-Plattform ki-spezial.systems ist die konsequente Erweiterung dieses Geschäfts: dieselbe Disziplin in Betrieb, Monitoring und Support — aber für GPU-getriebene LLM-Inference statt klassischer Webserver. Wir übernehmen die komplette technische Verantwortung, Sie konzentrieren sich auf Ihre Anwendungen.
Der typische Einstiegsweg: Ein einstündiges Erstgespräch zu Ihren Use Cases, anschließend eine Proof-of-Concept-Phase mit Test-Zugang zu unserer Shared-Infrastruktur (ohne Investitionsrisiko), dann ein klar dimensioniertes Produktivsystem. Sprechen Sie uns an unter 09571 873149 oder per Mail an info@hostspezial.de.
Vertiefendes Lesematerial: Im IT-Glossar — Kategorie KI erläutern wir die Kernbegriffe (vLLM, LLM, MoE, GPT OSS, Qwen3, MiniMax, RAG, Embeddings, Vector-DB, GPU-Pooling, LoRA, Prompt-Injection) jeweils kompakt mit Definition, Praxisrelevanz und weiterführenden Artikeln. Das Wissenskompendium bündelt sämtliche KI-Fachartikel als geführten Lesepfad.
vLLM, MiniMax M2.5, Qwen3 27B, GPT OSS 120B — produktionsreif, DSGVO-konform, mit SLA. Wir bauen, betreiben und betreuen Ihre On-Premise-KI-Plattform.
Beratungsgespräch vereinbaren