Inferenzbeschleunigung: NIS2-Risiken proprietärer Stacks

Stand 2026 wird Inferenzbeschleunigung mit einer einzigen Kennzahl verkauft: Tokens pro Sekunde. Vendor-Roadmaps und Launch-Blogs führen mit Multiplikatoren, während NIS2-Auditoren eine andere Frage stellen: Wer hat das Binary gebaut, das meinen Modell-Serving-Stack betreibt, und kann ich das nachweisen? Für proprietäre Beschleunigungsschichten lautet die Antwort meist nein. Offene Alternativen liefern vergleichbaren Durchsatz und machen den Nachweis möglich.

TL;DR: Anbieter von Inferenzbeschleunigung bewerben rohen Durchsatz, doch proprietäre Stacks erzeugen NIS2-Lieferkettenintransparenz und Lock-in. Offene Engines wie vLLM erreichen annähernd gleiche Leistung und halten die Prüfspuren intakt.

Wichtigste Erkenntnisse

• Marketing-Kennzahl: Proprietäre Beschleunigungsversprechen, etwa die nahezu verzehnfache Geschwindigkeit von Taalas, beruhen auf vendor-eigenen Baselines statt unabhängigen Benchmarks.
• Offene Parität: Der Heise-Benchmark von vLLM, SGLang und Nvidia NIM ergab: Die proprietäre Engine zeigt nur punktuelle Stärken in Extremkonfigurationen und nutzt teils selbst vLLM.
• NIS2-Druck: Die Richtlinie erfasst über 160.000 Einrichtungen in 18 Sektoren, mit Bußen bis 10 Millionen Euro oder 2 Prozent des weltweiten Umsatzes; Vorwarnung innerhalb von 24 Stunden.
• Transparenz-Asymmetrie: Open Source ist in 97 Prozent der Anwendungen weltweit integral, und NIS2 wertet Open Source ausdrücklich für transparente Verifikation.
• Migrationspfad: Engine-Ebene austauschen: Latenzbudget bleibt erhalten, Lieferketten-Dokumentation wiederhergestellt.

Herausforderungen der Inferenzbeschleunigung bei proprietären Stacks

Proprietäre Inferenzbeschleunigung optimiert eine einzige Achse: rohen Durchsatz. Das neueste Beispiel ist der Taalas-HC1-Chip, der Speicher und Rechenlogik auf einem einzelnen Die verschmilzt und nahezu zehnmal schneller als der aktuelle Stand der Technik zu sein beansprucht, gemessen an Nvidia-eigenen Baseline-Daten zur H200. Derselbe Launch-Text nennt drei Designprinzipien: totale Spezialisierung auf einzelne Modelle, Speicher-Rechen-Fusion und einen radikal vereinfachten Hardware-Stack. Jedes Prinzip verbessert die Leistung. Jedes Prinzip verengt zugleich, was ein Auditor inspizieren kann.

Ein spezialisierter Chip, gebunden an ein Modell, ist eine einzelne Abhängigkeit. Wenn der Vendor Lizenzbedingungen ändert, eine SKU einstellt oder seine Roadmap auf eine andere Beschleunigerfamilie ausrichtet, kann das Unternehmen nichts rekompilieren, forken oder prüfen. Die Performance-Zahl ist real; die Abhängigkeit, die sie verdeckt, steht in keinem Launch-Blog.

Was die Leistungsangabe tatsächlich abdeckt

Heise Online berichtet die verzehnfache Zahl als Unternehmensangabe aus dem eigenen Blog von Taalas, gemessen an Nvidias H200-Baseline. Vendor-veröffentlichte Vergleiche sind Marketing-Artefakte: Vergleichsmenge, Workload-Mix und Batchgrößen wählt der Vendor. Der eigene Benchmark von Heise zu Inferenz-Engines zeigt, wie dünn proprietäre Performance-Differenzierung in der Praxis tatsächlich ist.

NIS2-Konformität und Supply-Chain-Risiken

NIS2 (EU-Richtlinie 2022/2555) gilt für wesentliche und wichtige Einrichtungen in 18 Sektoren, von Energie und Transport über Banken und Gesundheit bis zu digitaler Infrastruktur und Fertigung, und erfasst Organisationen mit 50 oder mehr Beschäftigten oder 10 Millionen Euro Umsatz. Legiscope stellt fest, dass die Richtlinie den Anwendungsbereich von etwa 10.000 auf über 160.000 Einrichtungen ausweitete, mit Verwaltungsbußen bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Umsatzes. Für die Störungsmeldung beschreibt nis-2-directive.com eine Meldearchitektur mit Vorwarnung innerhalb von 24 Stunden nach Kenntnisnahme einer wesentlichen Störung, vollständiger Benachrichtigung innerhalb von 72 Stunden und grenzüberschreitender Auswirkungsanalyse.

Lieferketten-Transparenz steht im Zentrum dieses Regimes. CrowdSec verweist darauf, dass Open-Source-Code inzwischen in 97 Prozent der Anwendungen weltweit integral ist, und dass NIS2 Open Source ausdrücklich als Mittel für einen transparenteren Verifikationsprozess von Sicherheitstools wertet, mit gemeinschaftsgetriebenem Schwachstellen-Finding. Ein proprietärer Beschleuniger-Binary kann in diesen Verifikationskreislauf gar nicht eintreten: keine Quelle zur Prüfung, keine Community für Defektmeldungen, kein reproduzierbarer Build zum Hashen.

Dokumentierte Entscheidungen sind Audit-Entscheidungen

Heises Leitfaden zur Absicherung der LLM-Inferenz im eigenen Rechenzentrum betont, dass alle technischen Sicherheitsmaßnahmen für Audits im Rahmen von DSGVO, AI Act oder NIS2 nachweisbar dokumentiert sein müssen. Dazu zählen bewusste Entscheidungen über Zielkonflikte, etwa zwischen Datensparsamkeit und der Protokollierung von Anfragen zur Vorfallsanalyse. Eine intransparente Beschleunigungsschicht macht selbst diese Dokumentation unvollständig, denn der Entscheidungsspielraum ist dem Betreiber unsichtbar.

Ein weiterer Regulierungsfakt prägt den Horizont: Teldat berichtet, dass die Europäische Kommission am 20. Januar 2026 gezielte Änderungen an NIS2 vorgeschlagen hat, eingebettet in ein breiteres Cybersicherheitspaket, das auch den Cybersecurity Act revidiert. Strategisch sensible Einrichtungen kommen hinzu, Regeln werden über Mitgliedstaaten hinweg harmonisiert. Die Richtung ist mehr Aufsicht über Abhängigkeiten, nicht weniger.

Performance-Vergleich offener Alternativen

Das Performance-Argument für proprietäre Stacks ist empirisch schwächer als die Werbung nahelegt. Heise benchmarkte vLLM, SGLang und Nvidia Inference Microservices (NIM) auf CUDA-fähigen Modellen auf Nvidia-Hardware. Ergebnis: SGLangs theoretische Vorteile aus Radix- und Prefix-Caching waren kaum messbar, weil vLLM dort offenbar aufgeholt hatte. NIM zeigte nur punktuelle Stärken in Extremkonfigurationen und nutzt teils selbst vLLM als Teil seiner Implementierung.

Den Benchmark ehrlich lesen

• vLLM: konkurrenzfähiger Durchsatz über die gemessenen Konfigurationen; Open Source, prüfbar.
• SGLang: Caching-Vorteile weitgehend von vLLM absorbiert; ebenfalls Open Source.
• NIM (proprietär): punktuelle Stärken nur in Extremkonfigurationen, teils gebaut auf der offenen Engine, gegen die es antritt.

Für Architekturentscheidungen heißt das: Die Lücke zwischen proprietären und offenen Inferenz-Stacks ist eine Konfigurationsmarge, kein Größenunterschied. Die Literatur zur sicheren Inferenz zeigt das Gegenteil für geschlossene Ansätze: arXiv untersucht private Transformer-Inferenz und findet, dass Ansätze wie MPCFormer einen vertrauenswürdigen Dealer plus zusätzliche Destillationstrainings benötigen, während andere Studien sämtliche Matrixmultiplikationen naiv in elementweise Operationen umwandeln, nur ein kleines Modell wie BERT-Tiny evaluieren und keine Laufzeiten berichten.

Latenz versus Datenhoheit abwägen

Unternehmenskäufer rahmen die Entscheidung oft als Latenz gegen Datenhoheit, als wäre Souveränität ein Preis in Millisekunden. In der Praxis liefern offene Stacks das Latenzbudget auf Hardware, die Sie kontrollieren: vLLM-klassisches Serving auf Ihrer eigenen GPU-Flotte, mit Kernels, die Sie inspizieren und Patches, die Sie prüfen. Der stärkste Gegenpunkt der Proprietären liegt auf Chip-Ebene, wo verschmolzene Speicher-Rechen-Designs echte Speedups erzielen. Dieser Gegenpunkt verdient Anerkennung: In compute-bounden, batch-lastigen Workloads gewinnt spezialisiertes Silizium.

Ein Beispiel-Szenario: Ein Versicherer betreibt Dokument-Extraktion für die Schadenabwicklung. Der proprietäre Beschleuniger verspricht 40 Prozent geringere p95-Latenz bei doppeltem Durchsatz pro GPU. Aber die Pipeline speist eine NIS2-erfasste Einrichtung, und der Auditor verlangt Provenienz des Serving-Stacks, SBOM und Nachweis, dass keine Telemetrie das Rechenzentrum verlässt. Der Vendor liefert einen vertraglichen Assurance-Brief. Der offene Stack liefert Quellcode, reproduzierbare Builds und Logs, die Ihnen gehören. Latenzeinsparungen rechtfertigen diese Dokumentationslücke selten.

Das Verhältnis kippt weiter, wenn das Modell selbst Open Weight ist. Unsere Analyse von Open-Source-LLM-Benchmarks ergab Modellparität mit Frontier-Cloud-Modellen auf Enterprise-Workloads, was die zweite Lock-in-Achse entfernt, die Unternehmen sonst zurück in proprietäres Serving zieht.

Migrationsstrategien für Enterprise-Architektur

Der Wechsel von einem proprietären Beschleuniger erfordert keinen Big-Bang-Rewrite. Die Serving-Schicht, die Engine, ist vom Modell und von der Anwendungs-API trennbar.

1. Inventar: Kartieren, welche Inferenz-Endpunkte auf proprietärer Beschleunigung laufen und welche Modellfamilien sie bedienen.
2. Baseline: Durchsatz, p95-Latenz und Kosten pro Token auf dem aktuellen Stack unter Produktionslastprofilen erfassen.
3. Shadow-Deployment: vLLM oder eine gleichwertige offene Engine auf identischer Hardware mit demselben Traffic fahren, Tail-Latenz vergleichen statt Durchschnittswerte.
4. Dokumentieren: Performance-Differenz und akzeptierten Zielkonflikt explizit festhalten, denn NIS2-Audit erwartet dokumentierte Zielkonflikt-Entscheidungen.
5. Entkoppeln: Den Vendor-Beschleuniger nur dort behalten, wo gemessene Gewinne ihn rechtfertigen, und als dokumentierte Ausnahme mit Kompensationskontrollen isolieren.

Zwei praktische Hinweise. Erstens brauchen auch offene Stacks Härtung: Heise dokumentiert exponierte Endpunkte von vLLM und Ollama unter den Schwachstellen des Jahres 2026, Authentifizierung und Netzwerksegmentierung gehören von Tag eins in den Migrationsplan. Zweitens zählt die Supply Chain des offenen Stacks so viel wie seine Offenheit; unser Leitfaden zur Software-Supply-Chain-Sicherheit behandelt dafür Self-Hosted-Registries und Provenienzverifikation.

Checkliste für Hardwaresouveränität bei Inferenz

Vor der Unterschrift unter ein Beschleuniger-Engagement diese Liste gegen Vendor und Deployment fahren:

• Quellverfügbarkeit: Können Sie den vollständigen Software-Stack, inklusive Kernels und Serving-Runtime, erhalten und inspizieren?
• Reproduzierbare Builds: Veröffentlicht der Vendor Hashes oder Build-Pipelines, die Sie unabhängig verifizieren können?
• Modell-Portabilität: Wie viele Modellfamilien bedient die Hardware, und was passiert, wenn der Vendor weiter spezialisiert?
• Telemetrie: Meldet sich das Gerät nach Hause, und können Sie diesen Pfad vollständig deaktivieren?
• Störungsmeldung: Verpflichtet sich der Vendor zu dem NIS2-rhythmischen 24-Stunden-Vorwarn- und 72-Stunden-Benachrichtigungstakt?
• Ausstiegskosten: Können Sie dieselben Modelle auf einer offenen Engine neu deployen, ohne Retraining oder Re-Lizenzierung?

Die Vendor-Lock-in-Frage ist keine Frage des Misstrauens, sondern der Asymmetrie. Ein Vendor mit Performancevorteil und Sie mit Compliance-Verpflichtung verhandeln von unterschiedlichen Tischen. Offene Inferenz-Stacks stellen beide Seiten auf denselben: Durchsatz, den Sie selbst messen, Souveränität, die Sie dokumentieren können.

Fazit: Durchsatz ist ein Feature, Souveränität ist die Anforderung

Inferenzbeschleunigung wird auf beiden Seiten der proprietär/offenen Grenze weiter vorankommen, und spezialisiertes Silizium hat berechtigte Plätze in compute-bounden Pipelines. Aber die Ausweitung von NIS2 auf über 160.000 Einrichtungen und ihr Fokus auf transparente Lieferketten bedeuten, dass ein Performance-Multiplikator, den Sie nicht auditieren können, eine Haftung ist, die Sie nicht amortisieren. Behandeln Sie Durchsatz als gemessene Eingangsgröße der Architekturentscheidung, nicht als Schlagzeile. Der praktische nächste Schritt: Führen Sie vor dem nächsten Beschleuniger-Vertragslauf Ihren eigenen Benchmark einer offenen Engine auf Ihrem Produktionsverkehr durch.