JetBrains packt Maven-ähnliche Build-Logik in die Gewichte eines neuronalen Netzes

Entscheidungslogik als Gewichte, nicht als trainierte Vermutung

Das Projekt, das Denis Shiryaev im JetBrains-AI-Blog beschreibt, trainiert kein Modell darauf, vorherzusagen, was Maven üblicherweise als Nächstes tut. Ein solches Modell liege meistens richtig, argumentiert JetBrains, und „ein Build-Tool, das meistens richtig liegt, ist kaputt“. Stattdessen wollte das Team die Entscheidungslogik selbst in den Gewichten verankern, sodass das Netz entweder die exakte Antwort liefert oder die Antwort verweigert.

Der Ansatz stammt von Handwired: Man schreibt ein Programm und setzt die Gewichte eines Netzes so, dass das Netz dieses Programm ist. Das Team schrieb einen kleinen Maven-kompatiblen Build-Controller in einer eingeschränkten Teilmenge von Python und kompilierte ihn in eine Tabelle mit 29.625 × 7 Zahlen sowie 7.382 Zellen mit Konstanten. Das ist die erste Version, v1 genannt. Es gab kein Training und kein Gradientenverfahren, also null Optimierungsschritte.

Zur Laufzeit schlägt das Netz pro Schritt mit zwei Matrixmultiplikationen eine Zeile seiner Tabelle nach, führt die darin kodierte Rechenoperation auf einer kleinen Registerdatei aus und schreibt das Ergebnis in den Speicher. Dateien öffnen oder javac starten kann es nicht. Dafür schreibt es eine Anfrage in einen festen Speicherplatz, und eine schlanke Brücke führt sie aus und gibt die rohe Antwort zurück. Laut JetBrains entscheidet die Brücke nie etwas.

Bytegleiche JARs bei ZXing 3.5.3

Als Testobjekt diente die Barcode-Bibliothek ZXing 3.5.3: das Parent-Projekt sowie die Module core und javase, gebaut mit clean package und aktivierten Tests. Laut JetBrains stimmen die JARs Byte für Byte mit denen von Apache Maven überein. Der Build lief in einer Sandbox, in der Maven nicht laufen kann, das Netzwerk abgeschaltet ist und weder die Python-Version der Logik noch die Ausgaben von Maven gelesen werden können.

• Alle 549 Upstream-Tests liefen und bestanden.
• Die gebauten JARs kodierten und dekodierten QR-Codes in 27 von 27 Prüfungen korrekt.
• 519 handgeschriebene Build-Fälle bestanden, jeweils gegen echtes Maven geprüft.
• 10.000 generierte Projektfälle bestanden.
• 33 weitere kleine Projekte wurden mit denselben Gewichten korrekt gebaut.

Ein vollständiger ZXing-Build benötigte 4.796.191 Netzschritte. Zwei Prüfungen belegen nach Angaben des Teams, dass die Arbeit in den Gewichten stattfindet: CPU- und GPU-Version stellten exakt dieselben 1.731 Anfragen in derselben Reihenfolge, und wurde die Gewichtsdatei gelöscht oder beschädigt, kam kein Build zustande.

Der Preis: in jedem Szenario langsamer

JetBrains räumt offen ein, dass das Netz in jedem gemessenen Szenario langsamer ist. Jede winzige Anweisung kostet eine volle Runde Matrixarithmetik. Ein sauberer Build mit Tests dauerte 1,49-mal so lange wie die Python-Version (95-Prozent-Intervall 1,4× bis 1,54×, 30 gepaarte Läufe). Die Mediane lagen bei 15,52 s für Python, 23,12 s für das Netz auf der CPU, 70,11 s auf der GPU (Metal) und 15,29 s für Apache Maven 3.9.11.

Bei den Entscheidungen allein ist der Abstand deutlich größer: 146,54 ms für Python gegenüber 4,15 s für das CPU-Netz, also das 28,3-Fache. Im gesamten Build schrumpft die Lücke, weil die meiste Zeit auf javac und JUnit entfällt, die beide Versionen gemeinsam nutzen. Der Einsatz der GPU machte alles schlimmer, denn ein Programm, das Anweisung für Anweisung abläuft, bietet einer GPU nichts zum Parallelisieren.

Ein günstigerer Compiler statt eines anderen Netzes

Das Team zählte nach, wohin die Schritte gingen. Von den 4.796.191 Schritten der Version v1 kopierten 652.773 (14 Prozent) lediglich einen Wert zwischen Registern, weitere 553.333 (12 Prozent) luden eine Konstante oder sprangen an den Anfang einer Schleife. JetBrains nennt das Compiler-Kleber und verbesserte den Compiler statt des Netzes.

Das resultierende v2-Modell (nmvn-exact-v2) braucht für einen vollständigen ZXing-Build 3.676.728 Schritte, also 23 Prozent weniger, und seine Gewichtstabelle schrumpft um 10 Prozent auf 26.626 Zeilen. Es stellt dieselben 1.731 Anfragen in derselben Reihenfolge und besteht dieselben Korrektheitsprüfungen, darunter bytegleiche JARs. Der saubere Build mit Tests sank auf der CPU von 23,12 s auf 21,09 s, ein Verhältnis von 1,42× zu Python (95-Prozent-KI 1,40× bis 1,43×). Die Entscheidungen allein fielen auf 3,40 s. Auf der GPU sanken die reinen Entscheidungen von 27,97 s auf 21,61 s, womit sie weiterhin die langsamste Engine bleibt.

Ein Labyrinth-Löser und was das bedeutet

Um zu prüfen, dass der Compiler nicht auf ein einzelnes Programm zugeschnitten ist, kompilierte JetBrains einen Labyrinth-Löser auf Basis der Breitensuche in 279 Gewichtszeilen. Bei drei verschiedenen Labyrinthen der Größe 171×121 lieferten reines Python, ein Debug-Shim sowie die neuronalen Läufe auf CPU und GPU identische Ereignisfolgen. Das erste Labyrinth benötigte 2.572.288 Netzschritte. Der neuronale CPU-Lauf brauchte das 161- bis 168-Fache der Zeit von reinem Python, die GPU das 791- bis 812-Fache, wobei JetBrains diese Werte als grob bezeichnet.

Das Fazit des Unternehmens ist eindeutig: Wer schnellere Builds will, nutzt weiterhin Maven, und eine größere GPU hilft nicht, weil sich in einem Build-Controller nichts auf Tausende Kerne verteilen lässt. Es handle sich „nicht um ein schnelleres Build-Tool“, sondern um eines, „das man als Tensor halten kann“. Die Demonstration zeigt, dass exakte, regelbasierte Softwarelogik in den Gewichten eines Netzes laufen kann, auch wenn Geschwindigkeit nicht das Ziel war.