Heute stellen wir „Altar“ vor, unser erstes offenes Sicherheitsmodell, das entwickelt wurde, um Ihnen in der von Ihnen kontrollierten Infrastruktur Sicherheit auf höchstem Niveau zu bieten.
Mit unserer „ autonomes Penetrationstesting “-Appliance „ Aikido Machine“ haben wir unseren ersten Schritt in Richtung souveräner Sicherheitsinformationen gemacht. Diese Appliance läuft vollständig innerhalb der kundeneigenen Infrastruktur, einschließlich vollständig luftisolierter Umgebungen. Teams, die strenge Vorschriften zur internen Code-Verwaltung einhalten müssen, können Schwachstellen in ihrer gesamten Angriffsfläche kontinuierlich erkennen, ausnutzen und validieren, ohne gegen diese Vorschriften zu verstoßen.
Altar stattet „Aikido Machine“ mit fortschrittlicher KI aus, die Schutz bietet, ohne die sensibelsten Daten eines Unternehmens an einen Inferenzdienst eines Drittanbieters weiterzuleiten.
Dazu mussten wir die Lücke bei der Bereitstellung schließen. Die meisten leistungsfähigen Open-Weight-Modelle lassen sich nach wie vor nur schwer im Produktionsmaßstab einsetzen, ohne dass dabei die Schlussfolgerungsqualität von Modellen der Spitzenklasse beeinträchtigt wird.
Wir haben mit GLM-5.3 begonnen, einem der leistungsstärksten Modelle in unseren Sicherheitsbewertungen. Das vollständige Modell belegt 1,51 TB; durch Quantisierung lässt sich dieser Speicherbedarf auf 488 GB reduzieren, und unser von Experten durchgeführter Pruning-Prozess verringert ihn weiter auf 328 GB, wobei der Großteil der Schlussfolgerungsqualität des Ausgangsmodells erhalten bleibt.
.png)
Die Unterschiede zwischen Frontier- und Open-Weights-Modellen erklärt
Geschlossene Frontier-Modelle, die auf der Infrastruktur eines Dritten laufen
Die Nutzung einer solchen Lösung bedeutet, dass Ihr Quellcode, Ihre interne Architekturdokumentation und Ihre noch nicht behobenen Sicherheitsbefunde Ihr Netzwerk verlassen. Für eine Bank, die einer Vorschrift zur Datenlokalisierung unterliegt, eine Krankenhausgruppe, die strengen Datenverarbeitungsvorschriften unterliegt, oder einen Industriebetreiber, dessen OT-Umgebung überhaupt keinen Zugang zum Internet hat, ist dies kein Kompromiss, den sie eingehen dürfen.
Die Lücke bei der Bereitstellung
Die Bereitstellung eines Modells wie GLM 5.3 mit voller Genauigkeit erfordert Hunderte von Gigabyte an einheitlichem Speicher und führt zu einer begrenzten Inferenzgeschwindigkeit, wenn parallele Konversationen mit großen Kontextfenstern bedient werden. Für den Menschen sind das enorme Mengen.
Dieser Ressourcenbedarf ergibt sich zum Teil aus der Art und Weise, wie diese Modelle aufgebaut sind. Viele der derzeit leistungsstärksten Modelle nutzen „Mixture-of-Experts“-Architekturen. Diese Modelle bestehen aus einer Vielzahl kleiner, spezialisierter neuronaler Netze, die jeweils als „Experte“ bezeichnet werden. Für jedes Token ist nur eine kleine Anzahl von Experten aktiv, während der gesamte Expertenpool dennoch gespeichert und bereitgestellt werden muss. Das bedeutet, dass erhebliche Speicher- und Infrastrukturkosten für Kapazitäten anfallen, die möglicherweise nur einen geringen Beitrag zu der tatsächlich ausgeführten Arbeitslast leisten.
Sicherheitsaufgaben wie die Überprüfung von Code auf Schwachstellen, das Vorschlagen von Patches und die Durchführung von Penetrationstests beanspruchen nur einen kleinen Teil dieses Expertenpools. Der Speicherbedarf lässt sich jedoch nicht entsprechend reduzieren: Bei jeder Anfrage muss weiterhin das gesamte Modell geladen werden, unabhängig davon, ob es für die jeweilige Aufgabe relevant ist oder nicht.
Fügt man nun noch Agenten hinzu, explodiert der Kontextverbrauch, was den Speicher überlastet und dazu führt, dass sich die Agenten gegenseitig um Speicherplatz konkurrieren. Jeder Agent führt ein laufendes Protokoll über alles, was er gesehen und getan hat, und dieses Protokoll befindet sich zusammen mit dem Modell selbst im GPU-Speicher. Es wächst, je länger eine Untersuchung läuft, und vervielfacht sich mit jeder parallel laufenden Untersuchung.
Deshalb spielt die Modellgröße hier eine Rolle: Das Modell und der gesamte wachsende Kontext greifen auf denselben festen Speicherpool zurück, sodass mehr von dem einen weniger Platz für das andere lässt. Das Ziel besteht darin, den Betrieb eines „Frontier“-Modells für eine bestimmte Arbeitslast effizienter zu gestalten, wobei die wichtigen Funktionen erhalten bleiben und gleichzeitig Kapazität für alle parallel laufenden Prozesse freigegeben wird.
Was können wir weglassen, ohne das Wesentliche zu verlieren?
Die große Herausforderung, so viele Experten in ein Modell einzubeziehen, lässt sich mit den richtigen Techniken in einen Vorteil verwandeln. Um die Größe von Modellen mit offenen Gewichten im Kontext der agentenbasierten Sicherheit zu minimieren und gleichzeitig eine hohe Genauigkeit zu gewährleisten, haben wir Quantisierung und Pruning eingesetzt.
Beim „Expert Pruning“ werden einige der Experten aus dem Modell entfernt, in der Regel durch das Löschen ganzer Expertengewichtungsblöcke und die Anpassung des Modells, sodass jedes Token nur noch aus den verbleibenden Experten auswählen kann. Das Entfernen selbst erfolgt mechanisch. Die Entscheidung, welche Experten entfernt werden sollen, ist der schwierige Teil, und der Verlust kann ungleichmäßig ausfallen: Ein kleineres Modell kann zwar eine starke Codierungsleistung beibehalten, verliert dabei jedoch einen Großteil seiner Fähigkeit, eine bestimmte natürliche Sprache zu verstehen. Dadurch ist es unter Umständen nicht mehr in der Lage, in dieser Sprache beschriebene Dokumentationen, Geschäftsregeln oder Anwendungsfunktionen zuverlässig zu interpretieren.
Um zu entscheiden, was wir behalten sollten, gingen wir von den natürlichsten Daten aus: den Protokollen unseres Pentesting-Harnesses, mit dem interne Benchmarks durchgeführt wurden. Diese erfassen den Code, die Tool-Aufrufe und die Antworten, die die Agenten während eines vollständigen Pentests durchlaufen, und liefern uns repräsentative Eingaben als Grundlage für die Auswahl der Experten. Es wurden zu keinem Zeitpunkt Kundendaten einbezogen.
Dieser Kalibrierungsschritt liefert uns eine auf die jeweilige Arbeitslast zugeschnittene Grundlage für die Expertenauswahl, ohne dass dem Modell neue Fähigkeiten antrainiert werden müssen.
Die Testfälle deckten den technischen Arbeitsaufwand ab. Außerdem mussten wir das Sprachverständnis gewährleisten: Die Untersuchung einer Anwendung bedeutet, ihre Funktionen, Geschäftsregeln und beabsichtigten Arbeitsabläufe zu verstehen – auch dann, wenn die Dokumentation oder die Benutzeroberfläche auf Französisch, Niederländisch oder in einer anderen Sprache verfasst ist. Daher haben wir mehrsprachige Texte hinzugefügt, um diese Fähigkeiten während des Prunings zu erhalten.
Die Auswahl ist genauso wichtig wie die Größe
Es gibt zahlreiche Pruning-Techniken, um den Speicherbedarf von LLMs zu reduzieren. Daher haben wir uns für eine Technik entschieden, die die Leistung für unsere Anwendungsfälle erhalten kann: Cerebras REAP( Router-weighted Expert Activation Pruning). Wir haben den Beitragswert von REAP mit einer domänenerhaltenden Aggregationsstrategie verwendet, die anhand von Fidelity-Experimenten ausgewählt wurde. Die bloße Zählung, wie oft ein Experte ausgewählt wird, liefert nur ein unvollständiges Bild. REAP schätzt dessen Beitrag sowohl anhand der Gewichtung des Routers als auch anhand der Größe der Ausgabe des Experten.
Wir untersuchen außerdem die Beiträge verschiedener Beispielgruppen. Andernfalls könnte eine Kompetenz, die für eine weniger häufige Arbeitsaufgabe von Bedeutung ist, im Gesamtdurchschnitt untergehen. Kompetenzen in den Bereichen Cybersicherheit, Programmierung und Sprachen verteilen sich auf verschiedene Experten; es gibt keine klar definierte Gruppe von „Cybersicherheitsexperten“, die man beibehalten oder verwerfen könnte.
In der begleitenden Kompressionsstudie unterschieden sich Modelle mit derselben Anzahl von Experten erheblich darin, wie genau ihre Ergebnisse dem Referenzmodell folgten. Die Größe allein war nicht ausschlaggebend dafür, welche Modelle sich durchsetzen konnten.
Von 1,51 TB auf 328 GB
Wir erzielten eine Reduzierung der Modellgröße um insgesamt 78,2 % im Vergleich zu GLM 5.3 bei voller Präzision und eine Reduzierung um 32,8 % im Vergleich zu GLM 5.3 mit einer AWQ-INT4-Quantisierung. Altar behält 168 der ursprünglich 256 gerouteten Experten in jeder Backbone-Expertenebene bei und entfernt 88 bzw. 34,4 % davon. Der Router wählt weiterhin acht pro Token aus, nun jedoch aus der kleineren Bank.
Der andere Teil der Reduzierung ergibt sich aus der Quantisierung. Die Gewichte eines Modells sind die numerischen Werte, die es während des Trainings lernt. Bei der Quantisierung werden diese Zahlen mit weniger Bits gespeichert, wobei ein Teil der Genauigkeit zugunsten kleinerer gespeicherter Gewichte geopfert wird. Im Gegensatz zum Pruning werden dabei keine Experten entfernt.
Unser Start-Checkpoint nutzte AWQ, um die meisten Expertengewichte in vier Bit statt in den sechzehn Bit des BF16-Modells zu speichern. AWQ nutzt Informationen über die Aktivität des Modells bei Beispiel-Eingaben, um die durch die geringere Genauigkeit verursachten Fehler zu begrenzen. Die während der Inferenz erzeugten Zwischenwerte, sogenannte Aktivierungen, bleiben 16-Bit-Werte: daher W4A16, also Vier-Bit-Gewichte und 16-Bit-Aktivierungen. Einige Gewichte behalten zudem eine höhere Genauigkeit bei. Anschließend haben wir auf diesen bereits quantisierten Checkpoint eine Pruning-Maßnahme angewendet.
Ein Vergleich der beiden übergeordneten Darstellungen zeigt, welchen Beitrag die einzelnen Schritte leisten:
Das sind 78,2 % weniger Speicherplatz als beim vollständigen 16-Bit-Modell. Im Vergleich zum bereits quantisierten Ausgangsmodell werden durch das Pruning weitere 160 GB eingespart, was einer Reduzierung um 32,8 % entspricht.
Die Auswirkungen der Komprimierung auf die Fähigkeiten zur Erkennung von Schwachstellen
Wir haben bereits einen internen CVE-Benchmark entwickelt, mit dem wir die Fähigkeit eines Modells bewerten, komplexe Schwachstellen aus der Praxis mithilfe unseres „ KI-Codeanalyse “-Harness zu identifizieren: 32 bekannte Schwachstellen in 30 Repositories, mit jeweils drei Durchläufen pro Fall.
Wir haben „Altar“ damit getestet. „Altar“ erzielte im Durchschnitt eine Wiedererkennungsrate von 60,4 % pro Durchlauf und entdeckte 23 der 32 Schwachstellen in drei Durchläufen mindestens einmal wieder.
Im Vergleich dazu erzielte das quantisierte GLM-5.3 AWQ im Durchschnitt eine Recall-Rate von 61,5 % und deckte dieselben 23 Schwachstellen ab. Das ursprüngliche GLM-5.3-Modell bei voller Präzision erzielte im Durchschnitt eine Recall-Rate von 65,6 % und deckte 25 von 32 Schwachstellen ab.
Mit anderen Worten: Die Verkleinerung des bereits quantisierten Checkpoints von 488 GB auf 328 GB – was einer Reduzierung der gespeicherten Gewichte um 32,8 % entspricht – führte zu einem um etwa einen Prozentpunkt geringeren durchschnittlichen Recall im Vergleich zur AWQ-Basislinie, wobei die Abdeckung aller Schwachstellen vollständig erhalten blieb. Im Vergleich zum ursprünglichen Elternmodell behielt Altar 23 seiner 25 abgedeckten Schwachstellen bei, was 92 % entspricht, bei einem Rückgang des durchschnittlichen Recalls um 5,2 Prozentpunkte. Damit wurden 92 % der Schwachstellenabdeckung des Elternmodells bei 33 % weniger Speicherplatz beibehalten.
Das ist genau der Kompromiss, den wir gesucht haben: ein deutlich kleineres Modell, bei dem der Großteil der Sicherheitsfunktionen des Vorgängermodells erhalten bleibt.
Wir geben den durchschnittlichen Recall pro Durchlauf getrennt von der Abdeckung über drei Durchläufe hinweg an: Eine Schwachstelle einmal zu finden ist etwas anderes, als sie konsistent zu finden. Abgeschlossene Durchläufe ohne Fund werden als Fehltreffer gewertet; unvollständige Durchläufe werden separat ausgewiesen.
Dieser Maßstab misst die gezielte Wiederentdeckung von CVEs innerhalb einer Pipeline, die für die vor- und nachgelagerten Phasen andere Modelle verwendet. Er misst weder die blinde Erkennung über eine gesamte Codebasis hinweg, noch werden Exploits ausgeführt, um die Ergebnisse zu validieren, noch wird die Phase der Fehlerbehebungsvorschläge bewertet. Durch diese Abgrenzungen unterscheidet sich der Benchmark von dem umfassenderen Pentesting-Workflow, für dessen Unterstützung wir Altar entwickeln.
Darüber hinaus haben wir Altar unmittelbar nach Abschluss dieser Evaluierungen in unserer „ Aikido “-Maschinenflotte bereitgestellt. Kurz nach der Bereitstellung identifizierte das System im Rahmen eines Pentests in der Produktionsumgebung eines Kunden eine gültige Sicherheitslücke mit kritischem Schweregrad.
{{cta}}
Wie geht es weiter?
Der zugrunde liegende Gedanke ist weiter gefasst: Souveräne Sicherheitsinformationen sollten in jeder Umgebung laufen, die sie schützen.
Altar ist erst der Anfang. Im Bereich der Komprimierung untersuchen wir derzeit Formate mit niedrigerer Bitrate wie EXL3, die es uns ermöglichen könnten, mehr Experten zu behalten, sowie weitere Optimierungen für die Bereitstellung von H200.
Der nächste Schritt besteht darin, über die Komprimierung hinaus in die Trainingsphase überzugehen: die Feinabstimmung von Modellen für Sicherheits-Workflows, die Verbesserung des Tool-Einsatzes und der langfristigen Schlussfolgerungen sowie den Aufbau einer selbstlernenden Pipeline, die auf unseren internen Benchmarks basiert, um zukünftige Modelle zu steuern und zu gestalten.
Diese Arbeit wird sich auf die Bereiche Schwachstellenforschung, Code-Analyse, Behebung von Schwachstellen und andere defensive Sicherheitsprozesse erstrecken.
Aikido Labs wurde ins Leben gerufen, um diesen Ansatz weiter voranzutreiben: Modelle, die mit der Zeit immer leistungsfähiger werden, ohne dabei die entscheidende Einschränkung aus den Augen zu verlieren, dass Sicherheitsverantwortliche in der Lage sein müssen, sie vollständig innerhalb der Umgebungen auszuführen, für deren Schutz sie zuständig sind.
Vielen Dank an Z.AI für GLM-5.3, an Cerebras für REAP, an cyanwiki für das quantisierte Modell und an 0xSero für die Komprimierungsarbeit. Die öffentliche Fidelity-Studie sowie das „Keep Plans“- und das „Pruning“-Toolkit liefern weitere technische Details, ohne dabei die Rohdaten der Agentenkonversationen zu veröffentlichen.
Die Gewichte von Altar sind auf der Website „ Aikido“ verfügbar. Altar lässt sich bequem mithilfe eines 4-H200s-Knotens und der neuesten Version von vLLM bereitstellen und ausführen. Laden Sie Altar herunter, um die Modellkarte, die Lizenz, die Serving-Flags und die Anweisungen zur Bereitstellung zu erhalten.
Benötigen Sie Unterstützung bei der Einrichtung in Ihrer eigenen Umgebung? Wenden Sie sich an den Vertrieb, um die Bereitstellung von Altar vor Ort zu besprechen.
Dieser Ansatz wird zunehmend auf die gesamte Produktpalette von „ Aikido “ ausgeweitet, darunter „Aikido Attack“ (KI-Penetrationstests), „Code Security Audit “ und „Deep PR Review“.
