On-Premise KI mit HostSpezial — vLLM, MiniMax M2.5 und Qwen3 27B im Tech Deep Dive

Warum On-Premise KI — und warum gerade jetzt?

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.

Der HostSpezial-Stack im Überblick

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.

• Inference-Engine: vLLM 0.6+ als hochperformanter LLM-Server mit OpenAI-kompatibler REST-API.
• Modelle: MiniMax M2.5 (agentisch, Tool Use, Coding) + Qwen3 27B (Reasoning, Mehrsprachigkeit, Allzweck-Chat).
• Hardware: NVIDIA H100 80GB im 4er-Cluster, Tensor-Parallel und Pipeline-Parallel je nach Modellgröße. Optional über GPU-Pooling mehreren Mandanten zugewiesen.
• Orchestrierung: Kubernetes mit GPU-Operator, Prometheus/Grafana für Monitoring, MinIO mit S3-Storage-API für Modell-Weights.
• Gateway-Layer: LiteLLM als Routing-Proxy, mit RBAC, Rate Limiting und vollständigem Audit-Logging.
• Vektor-Store für RAG: Qdrant oder pgvector als Vector-DB — je nach bestehender Datenbank-Landschaft des Kunden.

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: Warum diese Inference-Engine?

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.

PagedAttention — der KV-Cache-Durchbruch

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.

Continuous Batching — keine Wartezeit auf den Slowest

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.

Quantisierung: FP8, AWQ und GPTQ

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.

MiniMax M2.5 und Qwen3 27B — die Modell-Wahl

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. Die Kombination aus MiniMax M2.5 und Qwen3 27B hat sich als ergänzendes Duo herauskristallisiert: zwei Modelle, die unterschiedliche Stärken abdecken und sich nicht überschneiden.

MiniMax M2.5 — der agentische Spezialist

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:

• Tool-Use auf höchstem Niveau: M2.5 ist explizit auf Function Calling und mehrstufige Tool-Chains trainiert und liefert auf agentischen Benchmarks (BFCL, Tau-Bench) Spitzenwerte.
• Coding-Stärke: Bei Code-Generierung, Debugging und Refactoring liegt M2.5 in unseren internen Tests gleichauf oder vor Claude Sonnet 4 — mit dem Vorteil offener Gewichte.
• Long-Context bis 256k Tokens: Ideal für Code-Repositories, große Tickethistorien oder umfangreiche Vertragsdokumente.
• Effizientes Streaming: Aufgrund der MoE-Architektur sind die Time-to-First-Token-Werte (TTFT) trotz Modellgröße konkurrenzfähig zu deutlich kleineren Dense-Modellen.

Qwen3 27B — der vielseitige Reasoner

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:

• Hybrid Thinking Modus: Qwen3 schaltet bei Bedarf in einen expliziten Reasoning-Modus, der intern Schritt-für-Schritt-Denkprozesse durchläuft, bevor die finale Antwort kommt. Über einen einzelnen Switch (/think oder /no_think im Prompt) lässt sich das je Anfrage steuern — schnelle Antworten für FAQ, tiefes Reasoning für Analysen.
• Mehrsprachigkeit auf Deutsch-Niveau: Qwen3 wurde auf einem hochwertigen mehrsprachigen Korpus trainiert und liefert auf Deutsch eine Idiomatik, die viele westliche Modelle in dieser Größenklasse nicht erreichen — entscheidend für Helpdesk, Kommunikation und Dokumentenverarbeitung in deutschsprachigen Unternehmen.
• Apache-2.0-Lizenz: Vollständig kommerziell nutzbar, keine versteckten Klauseln, kein "Acceptable Use Policy"-Risiko wie bei einigen anderen Open-Weights-Modellen.

Eigenschaft	MiniMax M2.5	Qwen3 27B
Architektur	MoE (~230B / 10B aktiv)	Dense oder MoE-Variante
Stärken	Tool Use, Coding, Agentic	Reasoning, Mehrsprachigkeit, Chat
Kontextlänge	bis 256k Tokens	32k–128k Tokens
Quantisierung im Einsatz	FP8	AWQ-Int4 oder FP8
VRAM-Bedarf (FP8)	~240 GB (4× H100)	~32 GB (1× H100)
Throughput (4× H100)	~2 100 Tokens/s	~3 900 Tokens/s
Lizenz	MiniMax Open License	Apache 2.0
Idealer Use Case	Agenten, Code, RAG mit Tools	Helpdesk, Übersetzung, Analyse

Hardware-Sizing für den Produktivbetrieb

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 klare Konfigurationsklassen ableiten.

Sizing-Klasse S — bis 50 Nutzer, ein Modell

Ein einzelner Server mit 1× H100 80GB, 2× AMD EPYC 9354 (32 Cores), 512 GB ECC-RAM, 4 TB NVMe für Modell-Weights. Reicht für Qwen3 27B in AWQ-Quantisierung mit ca. 30 parallelen Sessions und 3 000+ Tokens/s aggregiertem Throughput. Investition typischerweise im niedrigen sechsstelligen Bereich, alternativ als Mietmodell ab ca. 1 800 €/Monat in unserem Colocation-Rechenzentrum.

Sizing-Klasse M — 50 bis 500 Nutzer, zwei Modelle

Cluster aus 4× H100 80GB, NVLink, 1 TB RAM, 10 GbE-Anbindung. Beide Modelle parallel im Betrieb: Qwen3 27B auf einer GPU, MiniMax M2.5 mit Tensor-Parallel-Size 4 verteilt. Das ist die Konfiguration im Hero-Mockup oben — und die in der Praxis am häufigsten realisierte Klasse für mittelständische KI-Plattformen.

Sizing-Klasse L — Multi-Tenant oder hohe SLA-Anforderungen

Mehrfache redundante M-Cluster über zwei Rechenzentren, mit aktivem Load-Balancing und automatischem Failover. Hier sprechen wir über Investitionen ab dem mittleren sechsstelligen Bereich — relevant typischerweise für KI-Plattform-Anbieter, große Konzern-Töchter oder regulierte Branchen mit strengen Verfügbarkeitsvorgaben.

Anwendungsfälle aus der Praxis

Theorie ist gut, Anwendungen sind besser. Die folgenden Use Cases stammen aus realen HostSpezial-Kundenprojekten der letzten Monate — anonymisiert, aber inhaltlich repräsentativ.

Helpdesk-Agent für IT-Dienstleister

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.

Coding-Assistant für Softwarehaus

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.

Dokumentenanalyse für Steuerberatung

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.

RAG-System für Maschinenbau-Dokumentation

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.

Compliance-Bot für Gesundheitswesen

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.

Integration in bestehende Systeme

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.

OpenAI-API-Kompatibilität als Schlüssel

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.

Gateway, RBAC und Audit-Logging

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.

RAG: Wissen aus dem eigenen Haus

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.

Sicherheit, Compliance und Auditierbarkeit

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.

Datenschutz und DSGVO

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.

AI Act und Risikomanagement

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.

Modell-Updates und Lifecycle-Management

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.

Monitoring, Observability und Alerting

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.

Was HostSpezial bietet — und wie der Einstieg aussieht

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.

Unser Leistungsspektrum rund um On-Premise KI

• Dedizierte GPU-Server: H100, H200 und L40S in deutschen Rechenzentren — als Bare-Metal oder als virtualisierte Instanzen mit GPU-Passthrough.
• Managed vLLM Inference: Vollständig betreuter vLLM-Stack mit MiniMax M2.5, Qwen3 27B oder weiteren Modellen Ihrer Wahl. SLAs 99,9% Verfügbarkeit, 24/7 Monitoring.
• KI Workplace Komplett-Lösung: Browser-basiertes Chat-Frontend für Mitarbeitende, integriert mit Active Directory / Entra ID, mit RAG-Anbindung an SharePoint und gängige Dokumentensysteme.
• Integration und Consulting: Anbindung Ihrer ERP-, CRM- und ITSM-Systeme an die KI-Plattform. Aufbau von RAG-Pipelines, Tool-Use-Workflows und Multi-Agent-Systemen.
• Sizing und Architekturberatung: Vor dem Kauf eines GPU-Clusters klären wir, ob die Investition zu Ihrem Lastprofil passt — oder ob ein Mietmodell wirtschaftlicher ist.
• Compliance-Begleitung: DSGVO-Dokumentation, AI-Act-Vorbereitung, Datenschutz-Folgenabschätzung und Auftragsverarbeitungsverträge.

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.