Wie Patronus Ark KI-Security-Inferenz in Echtzeit auf einer CPU ausführt

Teil I unserer Serie über den Aufbau von Patronus Ark für CPU-basierte KI-Security-Inferenz.

Die meiste KI-Security-Inferenz wird so entwickelt, als stünden immer ein Cloud-Dienst oder eine freie GPU zur Verfügung. Wir wollten eine andere Annahme prüfen: Ein vollständiger Security-Stack sollte dauerhaft dort laufen können, wo KI-Interaktionen tatsächlich stattfinden, auf dem Endgerät und auf einer normalen CPU.

Patronus Ark läuft inzwischen innerhalb von Patronus Protect Desktop auf einem MacBook Air M1 aus dem Jahr 2021 mit 16 GB RAM. Ohne GPU-Optimierung erreicht die gesamte Desktop-Anwendung etwa 750 MB Peak RSS und führt ihre ereignisabhängige Security-Analyse mit einer Median-Latenz von rund 500 Millisekunden aus.

Das ist kein Benchmark eines einzelnen kleinen Klassifikators gegen einen kurzen Satz. Die Eingaben reichen von einem einzelnen Chunk mit 256 Token bis zu etwa 30.000 bis 40.000 Token. Abhängig vom Ereignis und davon, was frühere Schichten erkennen, führt Ark unterschiedliche Kategorien und Analysetiefen aus. Der aktuelle Stack erkennt Prompt Injections und Bedrohungen, klassifiziert Tools und sensible Dokumente und extrahiert dynamische PII.

Das entscheidende Ergebnis ist keine isolierte Latenzzahl. Mehrere KI-Security-Aufgaben können gemeinsam und dauerhaft auf einer Laptop-CPU laufen, während Coding-Assistenten aktiv arbeiten.

Warum sollte KI-Security auf einer CPU laufen?

LLMs belegen bereits die teure Hardware.

Wenn jede Security-Entscheidung eine weitere GPU oder den Umweg über ein großes Cloud-Modell braucht, konkurriert die Schutzschicht mit dem System, das sie schützen soll. Auf Endgeräten, in privater Infrastruktur und bei Scan-APIs mit hohem Volumen ist das besonders unattraktiv.

Das Datenschutzargument liegt auf der Hand. Prompts, Dateien, abgerufene Webinhalte, Tool-Calls und Modellantworten können Quellcode, Zugangsdaten, personenbezogene Daten oder interne Dokumente enthalten. Fällt die Entscheidung lokal, muss nichts davon an einen weiteren Inferenzdienst geschickt werden, nur um zu entscheiden, ob der Inhalt sicher ist.

Datenschutz war jedoch nicht der einzige Grund. Die Durchsetzung findet ohnehin auf dem Endgerät statt. Wenn ein Agent kurz davorsteht, ein Tool aufzurufen, ein Dokument hochzuladen oder einer versteckten Anweisung in abgerufenen Inhalten zu folgen, wird das Security-Ergebnis gebraucht, bevor die Aktion weiterläuft. Die vollständige Interaktion zuerst an einen anderen Ort zu senden, fügt genau an dem Punkt eine weitere Abhängigkeit hinzu, an dem das System eingreifen soll.

Lokale Inferenz hält diese Entscheidung auch ohne Netzwerkverbindung verfügbar. Sobald dieselbe Engine effizient auf einer CPU läuft, kann sie außerdem zwischen Laptops, konventionellen Servern und privater Infrastruktur wechseln, ohne die grundlegende Architektur zu verändern.

Das verändert auch die Wirtschaftlichkeit. Wir prüfen, ob dieselbe Arbeit APIs für Prompt-Injection- und Content-Scanning mit hohem Volumen deutlich günstiger machen kann. Lange Eingaben, besonders um 50.000 Token, brauchen noch mehr Durchsatzoptimierung. Deshalb wollen wir dieses Ergebnis noch nicht behaupten. Das verbleibende Problem ist jedoch CPU-Skalierung und nicht der Zugang zu mehr GPUs.

Die Rahmenbedingungen wurden zur Architektur

Am Anfang stand eine ziemlich kompromisslose Produktanforderung: Patronus musste KI-Security auf das Endgerät bringen. Inferenz auf unseren Entwicklungsrechnern zum Laufen zu bringen, reichte dafür nicht. Der Stack musste auf älteren Business-Laptops mit 8 GB RAM ohne GPU nutzbar bleiben und für deutsche Organisationen funktionieren.

Die meisten konkurrierenden Systeme mussten diese Einschränkungen nicht akzeptieren. Cloud-Inferenz kann einen weiteren Modellprozess, eine weitere GPU oder mehr Speicher hinzufügen. Auf einem Endgerät konkurriert jedes zusätzliche Modell mit Browser, IDE, Office-Anwendungen, lokalen Agents und manchmal mit dem LLM selbst.

Unser Ziel war deshalb nie, einen Prompt-Injection-Klassifikator zu verkleinern und ihn dann Endpoint-Security-Stack zu nennen.

Ark muss mehrere unterschiedliche Entscheidungen treffen. Es muss Injections und Security-Bedrohungen erkennen, verstehen, welche Art von Tool ein Agent verwenden will, sensible Dokumentklassen identifizieren und dynamische Entitäten wie PII finden. Kurze Prompts müssen genauso verarbeitet werden wie lange Dateien und Traces. Gleichzeitig muss das System ansprechbar bleiben, während andere Anwendungen die CPU bereits auslasten.

Daraus entstanden strenge Rahmenbedingungen:

• Ausführung ausschließlich auf der CPU;
• weniger als ungefähr 1 GB Peak Memory für die gesamte Laufzeit;
• begrenzte Verarbeitung langer und stark variierender Eingaben;
• mehrere Security-Aufgaben, ohne für jede einen eigenen Encoder zu laden;
• keine wiederholte Tokenisierung und Einbettung zwischen dem günstigen und dem teuren Entscheidungspfad;
• tiefere Inferenz nur dort, wo sie das Ergebnis tatsächlich verändert.

Jedes Modell für jeden Chunk auszuführen, kam nicht infrage. Genauso wenig konnten wir für jede Security-Kategorie einen anderen Transformer laden.

Die ersten Versionen machten das sehr deutlich. Ein Stack mit getrennten Modellen bewegte sich auf ungefähr 3 GB Speicher zu. Das war bereits zu viel für die Geräte, die wir schützen wollten. Die aktuelle Desktop-Laufzeit erreicht ungefähr 750 MB Peak RSS. Dafür mussten wir mehrere verschiedene Probleme lösen, statt auf eine glückliche Quantisierungseinstellung zu hoffen.

Was ist Patronus Ark?

Patronus Ark ist unsere mehrstufige Engine für KI-Security-Inferenz. Sie verarbeitet Text, Dateien, KI-Interaktionen und Agent-Inhalte und wandelt sie in Security-Evidenz um, die eine Anwendung für Richtlinien und Durchsetzung verwenden kann.

Die aktuelle Klassifikationspipeline hat drei Schichten.

Schicht 1 enthält aktuell native Heuristiken mit regulären Ausdrücken. Wir erweitern sie um strukturiertere Erkenner, die mit Ankern, Kandidatenwerten, Kontext und Validierung arbeiten. Das eignet sich für Signale mit bekannter Struktur, etwa Zugangsdaten, Kennungen, explizite Secrets und andere Fälle, in denen eine deterministische Prüfung passender ist als ein semantisches Modell.

Schicht 2 besteht aus unseren Non-Transformer Decision Blocks, kurz NTDBs. Ein NTDB kombiniert mehrere günstige, gelernte Klassifikatoren, darunter kleine neuronale Heads, LightGBM und logistische Regression, mit Attention über einen oder mehrere Chunks. Er erzeugt die erste gelernte Entscheidung und die Informationen, die ein Promote Gate benötigt.

Schicht 3 ist Lion Warden, unser einheitlicher mmBERT-Security-Klassifikator. Er liefert die tiefere Kontextanalyse, wird aber nicht automatisch für jeden Chunk ausgeführt.

Dynamische PII bleibt aktuell ein eigener Pfad. Wir verwenden ein quantisiertes GLiNER-Modell, um kontextabhängige Entitäten zu identifizieren und ihre exakten Spans zurückzugeben. Diese Komponente verursacht einen relevanten Teil des aktuellen Speicherbedarfs und ist einer der nächsten Bereiche, die wir enger in die gemeinsame Architektur integrieren wollen.

Eine Repräsentation, zwei Entscheidungstiefen

Dieser Teil unterscheidet das aktuelle System deutlich von einem kleinen Klassifikator vor einem vollständig getrennten Transformer.

NTDB und Lion Warden teilen denselben mmBERT-Tokenizer, denselben Embedder und denselben latenten Raum.

Ark zerlegt jede Eingabe in Chunks mit bis zu 256 Token. Tokenisierung und Einbettung finden einmal statt. Anschließend arbeiten die NTDB-Klassifikatoren auf dieser gemeinsamen Repräsentation und treffen eine günstige Entscheidung in Schicht 2.

Ein gelerntes Promote Gate bewertet, ob diese Entscheidung ausreicht. Ist das der Fall, endet die Verarbeitung des Chunks in Schicht 2. Wenn eine tiefere Kontextverarbeitung voraussichtlich hilft, läuft derselbe Chunk durch die mmBERT-Schichten von Lion Warden weiter.

Vereinfacht sieht das so aus:

Text
  → einmal tokenisieren
  → einmal einbetten
  → gemeinsame latente Repräsentation
      ├─ NTDB-Entscheidung → Stopp in Schicht 2
      └─ Promote Gate → Weiterleitung durch mmBERT

Das spart mehr als einen Modellaufruf.

Für den tieferen Pfad brauchen wir weder einen zweiten Tokenizer noch eine zweite Embedding-Tabelle. Die ursprüngliche Repräsentation wird nicht doppelt berechnet. Schicht 2 und Schicht 3 treffen ihre Entscheidungen außerdem im selben latenten Raum. Damit hat das Promote Gate eine bessere Grundlage für die Entscheidung, ob zusätzliche mmBERT-Schichten das Ergebnis wahrscheinlich verbessern.

Lion Warden ist selbst über mehrere Aufgaben vereinheitlicht. Statt getrennte Transformer für Injection-Erkennung, sensible Dokumente, Tool-Klassifikation und Threat Detection zu laden, stellt ein gemeinsamer mmBERT-Stack die relevanten Security-Heads bereit.

Die dominanten Repräsentationskosten werden damit zweifach geteilt: über Entscheidungstiefen und über Security-Aufgaben hinweg.

Selektive Tiefe vermeidet bereits die meisten vollständigen Schicht-3-Ausführungen

Das Promote Gate ist kein fester Konfidenzschwellenwert. Schicht 3 liegt nicht automatisch richtig, nur weil sie größer ist. Schicht 2 liegt auch nicht automatisch falsch, wenn sie unsicher ist. Das Gate lernt, wann eine vollständige Schicht-3-Ausführung einen Fehler aus Schicht 2 voraussichtlich korrigiert und wann sie eine richtige Entscheidung lediglich wiederholt oder sogar überschreibt.

Über die acht Evaluationspipelines, die wir aktuell für ausreichend belastbar halten, werden an den ausgewerteten Betriebspunkten ungefähr 16 bis 24 Prozent weitergeleitet. Ark vermeidet damit etwa 76 bis 84 Prozent der vollständigen Schicht-3-Ausführungen.

Fünf dieser acht Pipelines bleiben innerhalb eines F1-Prozentpunkts gegenüber einer immer ausgeführten vollständigen Schicht 3: Injection, Threat, Source Sensitive, Source Untrusted und Sink External.

Sensitive Documents, Tool Class und Tool Action liegen noch nicht innerhalb dieser Spanne. Wir verschweigen diesen Unterschied nicht. Selektive Inferenz erzeugt eine aufgabenabhängige Abwägung zwischen Qualität und Rechenaufwand, keine automatische Parität bei jeder Weiterleitungsrate.

Die vollständige Evaluation pro Pipeline und die Idee überlappender Entscheidungsräume von Schicht 2 und Schicht 3 gehören in Teil III dieser Serie. Für den Moment ist entscheidend, dass das System die meisten kontextuellen Transformer-Ausführungen vermeiden kann, ohne das Modell aus Schicht 2 als Wegwerfentwurf zu behandeln.

Was der Median von 500 ms darstellt

Es wäre einfach, die schnellste Zahl pro Chunk in die Überschrift zu schreiben. Es wäre auch irreführend.

Schicht 2 kann einzelne Entscheidungen deutlich schneller treffen als die vollständige Desktop-Beobachtung, während eine vollständige Schicht-3-Ausführung teurer ist. Patronus Protect verarbeitet jedoch keinen festen Benchmark-String isoliert. Es beobachtet reale Aktivitäten von KI-Agents, wählt die relevanten Security-Kategorien, verarbeitet Eingaben von einem Chunk bis zu Zehntausenden Token, leitet ausgewählte Chunks weiter, führt dynamische PII-Prüfungen aus und aggregiert die Ergebnisse.

Die Zahl von ungefähr 500 ms ist der Median dieser ereignisabhängigen Analyse in der laufenden Desktop-Anwendung. Die ungefähr 750 MB sind der Peak RSS der gesamten Anwendung über die Laufzeit. Es handelt sich um Messungen auf Systemebene, nicht um serialisierte Modellgrößen oder idealisierte Inferenzzeiten eines einzelnen Heads.

Diese Unterscheidung ist wichtig, weil On-Device-Inferenz als vollständige Laufzeit gelingt oder scheitert. Eine ONNX-Datei mit 100 MB hilft nicht, wenn geladene Session, Tokenizer, Aktivierungspuffer, Entitätsmodell und Host-Anwendung zusammen mehrere Gigabyte belegen. Ein schneller Benchmark mit kurzem Text sagt ebenso wenig über eine Security-Schicht aus, die eine lange abgerufene Webseite oder lokale Datei scannen muss.

Wie wir von ungefähr 3 GB auf 750 MB gekommen sind

Die oben beschriebene Architektur war nicht der Ausgangspunkt. Jeder Bestandteil existiert, weil eine frühere Version an eine konkrete Grenze des Endgeräts gestoßen ist.

Deutsche Security-Modelle und deutsche Security-Daten

Der deutsche Markt durfte kein nachträglicher Zusatz sein. Wir brauchten Modelle, die deutsche Angriffe, normale deutsche Geschäftssprache, gemischte deutsch-englische Prompts, Dokumente und Agent-Interaktionen verstehen.

Open-Weight-Modelle mit deutscher Sprachunterstützung existieren. Metas Prompt Guard 2 berichtet zum Beispiel deutsche Evaluationen neben mehreren anderen Sprachen. Wir fanden jedoch keinen offenen Stack mit Priorität auf Deutsch, der das breitere Endpoint-Problem abdeckte: Injections, Threats, Tool-Verhalten, sensible Dokumente und Datenabfluss in einer lokalen Architektur.

Deshalb haben wir die Modelle und einen großen Teil der Daten selbst gebaut. Dazu gehörten das Sammeln öffentlicher Datensätze, das Entfernen von Duplikaten und Leakage, die Korrektur von Labels, die Erzeugung fehlender deutscher Fälle, die Übersetzung und Erweiterung von Angriffen ohne Übersetzungsrauschen und schwierige gutartige Beispiele, die wie Security-Inhalte aussehen, aber keine Angriffe sind. Unser offenes Modell Wolf Defender ist ein sichtbares Ergebnis dieser Arbeit. Dasselbe Problem besteht auch bei den anderen Security-Heads.

Den Stack in ein Gigabyte bringen

Ein Endgerät mit 8 GB hat keine drei freien Gigabyte für einen Security-Dienst im Hintergrund. Wir setzten deshalb eine Obergrenze von ungefähr 1 GB für die gesamte Laufzeit.

Die serialisierte Modellgröße allein löst das Problem nicht. Wir mussten Modelle, Embeddings und ONNX-Graphen quantisieren und anschließend messen, was nach dem Laden von Tokenizern, Inferenzsessions, Aktivierungspuffern, Entitätsmodell und Desktop-Laufzeit tatsächlich im Speicher blieb.

Viele Klassifikationen ohne viele Encoder ausführen

Prompt Injection war nur eine Entscheidung. Ein weiterer Transformer für Threats, Tools, Routing-Eigenschaften und sensible Dokumente hätte das Speicherbudget sofort gesprengt.

Lion Warden wurde deshalb zu einem einheitlichen quantisierten Klassifikator: eine mmBERT-Repräsentation mit mehreren aufgabenspezifischen Security-Heads. Eine weitere Klassifikationsaufgabe bedeutet nicht länger einen weiteren vollständigen Encoder.

Ein interaktives Latenzbudget erreichen

Selbst ein gemeinsamer Transformer ist zu teuer, wenn er jeden Chunk jedes Ereignisses verarbeitet. Daraus entstanden die NTDB-Architektur und das gelernte Promote Gate.

NTDB trifft zuerst die günstige Entscheidung. Das Gate entscheidet, ob die Fortsetzung durch die kontextuellen mmBERT-Schichten das Ergebnis voraussichtlich verbessert. Wir führen also nicht einfach ein kleineres Modell aus. Wir lernen, wie viel Modell ein bestimmter Chunk benötigt.

Platz für dynamische PII schaffen

GLiNER liefert etwas, das ein normaler Klassifikator nicht kann: dynamische Entitätstypen und exakte Spans. Das fügt dem Prozess zugleich ein weiteres substanzielles Modell hinzu.

Die gemeinsame Nutzung von mmBERT-Tokenizer, Embedder und latentem Raum zwischen Schicht 2 und Schicht 3 entfernte doppelte Repräsentationskosten. Dadurch sank der vollständige Desktop-Stack von ungefähr 3 GB auf rund 750 MB Peak RSS, inklusive des aktuell noch getrennten quantisierten GLiNER-Pfads.

Das Ergebnis ist das mehrstufige System, das wir heute verwenden. Zum ersten Mal erfüllt ein Build mehr als die ursprüngliche Endpoint-Anforderung. Die durch diese Rahmenbedingungen erzwungene Architektur kann mit einem permanent ausgeführten GPU-Inferenzdesign konkurrieren und ist in manchen Einsatzumgebungen sogar besser geeignet.

Die offenen Probleme

Das aktuelle System ist praktisch einsetzbar, aber drei große Arbeitspakete bleiben.

GLiNER in die gemeinsame mmBERT-Architektur integrieren

Unser dynamisches PII-Modell basiert aktuell auf DeBERTa. Ein Training der GLiNER-Architektur auf mmBERT würde den latenten Raum über den gesamten Stack konsistent halten und einen weiteren getrennt geladenen Encoder entfernen. Das Ziel ist kein kurzlebiger Low-Memory-Benchmark, sondern ein stabiler Peak RSS von ungefähr 500 MB unter realer Nutzung.

Erste interne Ablationen deuten außerdem darauf hin, dass NTDBs vorentscheiden können, welche Chunks eine vollständige GLiNER-Entitätsextraktion benötigen. Dynamische PII würde dann derselben Regel folgen wie der Rest von Ark: Der teure Kontextpfad läuft dort, wo er Informationen hinzufügt, statt über jeden Chunk.

Die Ausführung innerhalb von Schicht 3 kaskadieren

Heute entscheidet das zentrale Promote Gate, ob ein Chunk in Lion Warden eintritt. Wir ergänzen nun NTDB-artige Entscheidungen innerhalb der 22 mmBERT-Schichten von Lion Warden.

In den ersten Experimenten können ungefähr 90 Prozent der Fälle vor Schicht 12 entschieden werden. Weniger als 1 Prozent benötigen die vollständige Ausführung über 22 Schichten. Die ersten Latenzergebnisse deuten darauf hin, dass sich p99 mindestens halbieren und p50 um ungefähr ein Viertel reduzieren ließe. Diese Zahlen brauchen noch eine vollständige Ablation.

Wenn sie sich bestätigen, wird Ark auch als CPU-basierte API-Engine deutlich interessanter. Mehrere CPU-Container könnten dieselbe Security-Last zu einem Bruchteil heutiger GPU-Inferenzkosten verarbeiten und dabei ähnliche Ausführungszeiten erreichen. Das ist die Richtung. Die Durchsatzmessungen für lange Eingaben müssen sie noch bestätigen.

mmBERT durch einen für Ark entwickelten Encoder ersetzen

mmBERT lieferte die mehrsprachige Basis und die gemeinsame Repräsentation, die wir zum Nachweis der Architektur brauchten. Für diese Laufzeit wurde es nicht speziell entwickelt.

Langfristig wollen wir es durch einen Encoder ersetzen, der auf Arks begrenzten Entscheidungsraum, Aufgaben und Ausführungsmuster zugeschnitten ist. Modellgröße und Laufzeitspeicher sollen erneut sinken. Unser Ziel liegt bei ungefähr 200 bis 300 MB für den vollständigen Stack. Dann bewegt sich Ark über normale Laptops und Server hinaus in Richtung Gateways, Appliances und andere Geräte der IoT-Klasse.

Die Arbeit ist Teil der Bachelorarbeit von Benedikt Veith. Die Arbeit wird die genaue Architektur, Messungen und Ablationen detaillierter veröffentlichen. Wir stellen die Richtung früher vor, weil die Schlussfolgerung auf Systemebene bereits klarer wird.

Aus den Einschränkungen wurde ein Vorteil

Für Ark haben wir nicht die einfache Infrastruktur gewählt. Wir haben die Geräte gewählt, die die Security-Schicht später schützen muss: normale Endgeräte, darunter ältere Laptops mit 8 GB RAM und ohne GPU.

Das zwang uns, deutsche Daten aufzubauen, aggressiv zu quantisieren, Klassifikatoren zu vereinheitlichen, die Repräsentation zu teilen und nicht mehr jede Eingabe so zu behandeln, als brauche sie das vollständige Modell. Das Ergebnis ist noch nicht fertig, läuft aber bereits dauerhaft in unserer Desktop-Anwendung auf einem normalen M1-Laptop.

Die Architektur wirkt inzwischen nicht mehr wie ein Kompromiss für schwache Hardware. Selektive Ausführung, gemeinsame Repräsentationen, vorhersehbare lokale Kosten und der Verbleib sensibler Daten auf dem Gerät sind auch auf einem Server wertvoll. Die Einschränkungen des Endgeräts könnten der Grund sein, weshalb Ark besser skaliert.

In Teil II öffnen wir den NTDB selbst: wie seine Klassifikatoren zusammenarbeiten, wie Attention Evidenz über mehrere Chunks kombiniert und wie eine kleine Architektur in Schicht 2 lernt, wann ihre eigene Entscheidung ausreicht.

Wenn du an effizienter Inferenz, Early-Exit-Architekturen, AI-Agent-Security oder On-Device-ML arbeitest, tauschen wir uns gerne aus.