LLM-Control-Plane selbst bauen oder kaufen?

Die Inferenz-Runtime ist ein gelöstes, kostenloses Problem: Open-Source-Engines führen heute Open-Weight-Modelle auf Ihrer eigenen Hardware in Produktionsqualität aus. Die eigentliche Entscheidung zwischen Eigenentwicklung oder Kauf betrifft die Control Plane, also Identität, Auditierung, Aufbewahrung, Mandantenfähigkeit und Reaktion auf Vorfälle – und dieser Arbeitsaufwand existiert, egal ob Sie ihn selbst programmieren oder lizenzieren.

Dieser Beitrag ist das Framework, das wir in diesen Gesprächen verwenden, einschließlich jener Argumente, die gegen einen Kauf bei uns sprechen.

Die Runtime ist ein gelöstes Problem

Vor fünf Jahren war das Ausführen eines leistungsfähigen Sprachmodells auf eigener Hardware noch ein Forschungsprojekt. Heute ist es ein einfacher Download. Engines wie vLLM und Ollama stellen Open-Weight-Modelle mit einem Durchsatz bereit, der in der Produktion standhält. Unser eigener Inferenzpfad – das Gateway, der Daemon, die CLI, der Infoserver und das gemeinsame Datenbankschema – steht unter der Apache-2.0-Lizenz. Sie können ihn kommerziell nutzen, ohne jemals mit uns zu sprechen.

Das muss man so deutlich sagen, da Anbieter in diesem Markt das Thema gerne verschleiern. Wenn Ihnen jemand Gebühren für eine sogenannte "souveräne Inferenz" in Rechnung stellt, fragen Sie konkret nach, wofür Sie eigentlich bezahlen, denn die Inferenz selbst hat einen Marktpreis von Null. Kosten entstehen durch alles, was darum herumliegt.

Was ist eine LLM Control Plane?

Die Control Plane umfasst alle Funktionen, die aus einem Modellserver eine Infrastruktur machen, die ein Unternehmen auch tatsächlich betreiben kann. In der Praxis bedeutet das mindestens: Identitäts- und Zugriffsverwaltung, damit jede Anfrage einer Person oder einem Dienst zugeordnet werden kann; Audit-Protokollierung und -Aufbewahrung, damit Sie rekonstruieren können, wer wann was mit welchem Modell gefragt hat; Mandantenfähigkeit, damit Abteilungen Hardware gemeinsam nutzen können, ohne Daten zu teilen; Modell-Governance, damit Sie kontrollieren, welche Gewichte ausgeführt werden und wann sie sich ändern; sowie die operative Ebene des Schwachstellenmanagements und der Reaktion auf Vorfälle.

Nichts davon ist exotisch. Es ist genau dieselbe Arbeit, die Ihr Unternehmen bereits für jedes andere Produktionssystem leistet. Der Grund, warum dies die Budgets für On-Premise-KI dominiert, ist das Volumen: Eine Inferenz-Bereitstellung berührt gleichzeitig Identität, Netzwerk, Speicher und Compliance, und jede Schnittstelle erfordert eine Entscheidung, eine Implementierung und einen Test.

Wenn Sie eine detaillierte Aufschlüsselung darüber wünschen, wer wofür verantwortlich ist: Wir veröffentlichen das vollständige Modell der gemeinsamen Verantwortung für On-Premise-KI im Laufe dieser Woche auf einer eigenen Referenzseite.

Was wir aus CVE-2025-47277 über die Grenzen lernen

Im Mai 2025 wurde eine kritische Schwachstelle in vLLM offengelegt. In den betroffenen Versionen deserialisierte eine Komponente, die für den KV-Cache-Transfer zwischen verteilten Knoten verwendet wird, nicht vertrauenswürdige Eingaben, und die zugrunde liegende PyTorch TCPStore-Schnittstelle lauschte auf allen Netzwerkschnittstellen, selbst wenn sie mit einer privaten Adresse konfiguriert war. Die Folge war ein Risiko der Remotecodeausführung bei Multi-Node-Bereitstellungen, das in Version 0.8.5 behoben wurde. Die Details finden Sie im GitHub-Sicherheitshinweis.

Zwei Aspekte hierbei sind aufschlussreich, und keiner davon lautet "vLLM ist unsicher" .

Erstens weist das vLLM-Projekt in seiner Sicherheitsdokumentation explizit darauf hin, dass die Engine für den Betrieb in einem gesicherten, vertrauenswürdigen Netzwerk konzipiert ist. Das ist Ehrlichkeit bezüglich des Leistungsumfangs: Die Runtime deklariert, welchen Schutz sie bietet und welchen sie von ihrer Umgebung erwartet. Die Schwachstelle war nur in Bereitstellungen erreichbar, in denen diese Erwartung an die Umgebung nicht erfüllt wurde.

Zweitens: Achten Sie darauf, auf welcher Seite der Grenze die Behebung stattfand. Der Patch war Aufgabe des Projekts. Zu wissen, dass die Schwachstelle (CVE) existierte, zu wissen, ob Ihre Konfiguration betroffen war, die Schnittstelle zu isolieren, bis Sie ein Upgrade durchführen konnten, und nachträglich nachzuweisen, dass Sie es getan haben: All das war Aufgabe des Betreibers. Das ist die Control Plane, und keine Lizenz, ob Open Source oder kommerziell, nimmt Ihnen diese Arbeit ab.

Deshalb formulieren wir unser eigenes Versprechen sehr sorgfältig. Der Kauf einer Control Plane macht Sie nicht automatisch compliant. Er macht Ihre Compliance nachweisbar, weil die Protokolle, Aufzeichnungen über Zugriffe und das Modellinventar, die ein Auditor anfordert, als Eigenschaft des Systems existieren und nicht als Dokument, das nachträglich verfasst wurde. Die Pflichten bleiben in jedem Fall bei Ihnen.

Was bekommen Sie kostenlos?

Die ehrliche Antwort, Paket für Paket:

Der gesamte Inferenzpfad ist und bleibt kostenlos. Das Dashboard ist im Quellcode verfügbar, was bedeutet, dass der Code zur Durchsetzung Ihrer Zugriffskontrolle lesbar ist, auch wenn er nicht Open Source ist. Die kommerzielle Grenze beginnt genau dort, wo Bereitstellungen für einzelne Teams enden: beim Betrieb vieler Knoten und der Isolierung vieler Organisationen auf einer gemeinsamen Infrastruktur.

Wir veröffentlichen diese Tabelle, weil sie die Antwort auf jene Frage ist, mit der jede Evaluierung beginnen sollte, und weil ein Anbieter, der das Äquivalent für sein eigenes Produkt nicht vorlegt, Ihnen damit bereits eine Aussage liefert.

Wann eine Eigenentwicklung die richtige Entscheidung ist

Eine eigene Control Plane zu bauen ist legitim, und einige Teams sollten das auch tun. Das Erfolgsmuster, das wir sehen: ein Plattform-Team, das bereits eine interne Entwickler-Infrastruktur betreibt, ein Identitätsanbieter und eine Logging-Pipeline, die der KI-Workload übernehmen kann, ein oder zwei Teams, die Inferenz nutzen statt zwanzig, und kein kurzfristiges Audit, das speziell vom KI-System abhängt. In einer solchen Situation ist die Anbindung einer Runtime an Ihr bestehendes SSO und die Weiterleitung von Protokollen an Ihre vertraute Pipeline eine Arbeit von wenigen Wochen – und die vollständige Kontrolle darüber zu haben, ist diese Wochen wert.

Das Fehlermuster besteht darin, diese Schätzung als das gesamte Projekt zu betrachten. Die Identitätsintegration ist der erste Punkt, nicht der letzte. Die nutzungsbasierte Zuordnung pro Schlüssel, von der Rechtsabteilung genehmigte Aufbewahrungsfristen, das Modell-Änderungsmanagement und die Mandantentrennung dauern jeweils länger als die Einrichtung der Inferenz selbst – und sie stehen an, nachdem die Demo funktioniert hat und das Unternehmen glaubt, das Projekt sei bereits abgeschlossen.

Wann ein Kauf die richtige Entscheidung ist

Ein Kauf ist sinnvoll, wenn der Zeitplan und nicht die Entwicklung die Einschränkung darstellt. Wenn Abteilungen bereits sensible Daten in öffentliche Chatbots kopieren, führt jeder Monat ohne eine kontrollierte interne Alternative zu einem kumulierenden Risiko. Wenn eine Einstufung nach dem EU-KI-Gesetz oder ein Branchenaudit im Kalender steht, muss die Nachweisebene existieren, bevor der Auditor kommt, nicht erst danach. Und wenn das Team, das die Control Plane bauen würde, dasselbe Team ist, das den Rest der Produktion am Laufen hält, sollte die Aufwandsschätzung für den Eigenbau auch das berücksichtigen, was dieses Team in der Zwischenzeit nicht tun kann.

Der Test, den wir vorschlagen, ist pragmatisch: Bringen Sie diese Woche irgendeine Runtime zum Laufen, die ein Modell bereitstellt, unsere oder eine andere, und versuchen Sie dann eine einzige End-to-End-Aufgabe der Control Plane zu lösen – zum Beispiel die Erstellung eines benutzerbezogenen Protokolls aller Anfragen der letzten 24 Stunden, nachvollziehbar über Ihren echten Identitätsanbieter. Wenn das einen Nachmittag dauert, haben Sie die Plattform-Reife für eine Eigenentwicklung. Wenn es einen Projektplan erfordert, ist dieser Plan das, worüber Sie entscheiden müssen, ob Sie ihn selbst umsetzen oder einkaufen.

Das Entscheidungs-Framework

Vier Fragen klären die meisten Fälle. Wer nutzt die Inferenz, ein Team oder viele? Denn bei der Mandantenfähigkeit multiplizieren sich die Kosten für den Eigenbau. Was muss nachweisbar sein und gegenüber wem? Denn nachträglich konzipierte Audit-Nachweise sind teuer und unüberzeugend. Wer patcht, überwacht und reagiert um 2 Uhr morgens? Denn CVE-2025-47277 wird nicht die letzte Sicherheitswarnung in diesem Stack gewesen sein. Und was tut das Entwicklerteam stattdessen nicht? Denn der wahre Preis des Eigenbaus bemisst sich in einer verschobenen Roadmap, nicht in Gehältern.

Wenn diese Antworten für eine Eigenentwicklung sprechen, dann bauen Sie selbst und nutzen Sie unsere Apache-2.0-Runtime als Basis, wenn es hilft; genau dafür ist die Lizenz da. Wenn sie für den Kauf sprechen, zeigt die obige Tabelle genau, wofür Sie bezahlen würden, und das Modell der gemeinsamen Verantwortung, das im Laufe dieser Woche erscheint, zeigt präzise, wo unsere Verpflichtungen enden und Ihre fortbestehen.

Häufig gestellte Fragen (FAQ)

Ist die Xinity-Runtime wirklich kostenlos für die kommerzielle Nutzung? Ja. Das Gateway, der Daemon, die CLI, der Infoserver und das Datenbankschema stehen unter der Apache-2.0-Lizenz. Sie können sie kommerziell nutzen, modifizieren und bereitstellen, ohne eine Vereinbarung mit uns treffen zu müssen.

Werden wir durch den Kauf einer Control Plane konform mit der DSGVO oder dem EU-KI-Gesetz? Nein. Die Compliance-Verpflichtungen verbleiben immer beim bereitstellenden Unternehmen. Eine Control Plane macht die Compliance nachweisbar, indem sie die Audit-Protokolle, Zugriffsnachweise und das Modellinventar erstellt, die Ihre Kontrollmaßnahmen belegen. Die rechtlichen Pflichten liegen bei Ihnen, das System liefert die Nachweise.

Was ist der Unterschied zwischen der Control Plane und der Inferenz-Runtime? Die Runtime lädt Modelle und verarbeitet Anfragen. Die Control Plane umfasst alles, was den Betrieb in einem Unternehmen ermöglicht: Identität, Audit-Protokollierung, Aufbewahrung, Mandantenfähigkeit, Modell-Governance, Schwachstellenmanagement und Reaktion auf Vorfälle.

Können wir mit der Open-Source-Runtime beginnen und die kommerzielle Ebene später hinzufügen? Ja, und das ist auch der Weg, den wir für Evaluierungen empfehlen. Der Open-Source-Stack und die kommerziellen Features teilen sich dieselbe Architektur, sodass eine Single-Node-Bereitstellung unverändert übernommen werden kann.

Transparenzhinweis: Dieser Artikel wurde mit Unterstützung von KI erstellt und vom Xinity-Team, das die redaktionelle Verantwortung für den Inhalt trägt, überprüft, auf Fakten kontrolliert und bearbeitet. Alle Quellen sind im Text verlinkt.