Ein offenes Coding-Modell, das im Einsatz gelernt hat

Ein offenes Coding-Modell, das im Einsatz gelernt hat

JetBrains hat am 8. Oktober Mellum2.1 veröffentlicht. Es ist ein Mixture-of-Experts-Modell mit 12 Milliarden Parametern, gebaut für Coding-Agents, und auf Hugging Face unter Apache 2.0 verfügbar. Für sich genommen wäre es damit eine von mehreren ähnlichen Veröffentlichungen dieses Monats. Was es heraushebt, ist die Art des Trainings.

Das Post-Training von Mellum2.1 nutzt Reinforcement Learning in echten Coding-Umgebungen. Kein simulierter Benchmark-Harness, kein statischer Datensatz gelöster Probleme. Das Modell erkundet Repositories, bearbeitet Dateien und prüft seine eigenen Änderungen, so wie es ein berufstätiger Entwickler tut.

Warum das Trainings-Setup wichtiger ist als die Parameterzahl

Die meisten Coding-Modelle werden heute darauf trainiert, den nächsten Codeabschnitt vorherzusagen, und anschließend auf Beispielen guter Patches feinabgestimmt. Das ist eine vernünftige Pipeline, und sie liefert Modelle, die vervollständigen und erklären können. Auf die unordentliche Realität eines Repositories, das sich nicht bauen lässt, ist sie schlecht vorbereitet: Der erste Fix bricht einen Test, der zweite bricht etwas anderes.

Die entscheidende Fähigkeit ist nicht, eine Funktion zu schreiben. Sie ist, den Kreis zu schließen: eine Hypothese bilden, etwas ändern, das Ergebnis beobachten, nachbessern. Training mit Reinforcement Learning in einer lebendigen Umgebung belohnt genau dieses Verhalten, denn die Belohnung kommt daher, ob die Änderung tatsächlich gewirkt hat.

Das ist dieselbe Verschiebung, die Coding-Agents überhaupt nützlich gemacht hat. Ein Modell, das nur Code schreiben kann, ist eine schicke Autovervollständigung. Ein Modell, das die Tests ausführen, die Fehler lesen und es erneut versuchen kann, ist ein Mitarbeiter. Die Trainingsdaten von Mellum2.1 sind der Kreis selbst.

Ein 12B-Modell ist eine bewusste Größe

Zwölf Milliarden Parameter sind klein im Vergleich zur Frontier. Genau darum geht es. Ein Coding-Agent arbeitet in einer engen Schleife: Dateien lesen, Befehle ausführen, Diffs prüfen. Deshalb wird er ständig aufgerufen. Ein Modell, das günstig läuft und schnell antwortet, lässt sich deutlich aggressiver einsetzen als eines, das pro Schritt echtes Geld kostet.

Das Mixture-of-Experts-Design verstärkt denselben Gedanken. Die Aktivierungen pro Token bleiben bescheiden, während die Gesamtkapazität wächst, was die Inferenz günstig hält, ohne dem Modell Wissen zu entziehen. Für ein Werkzeug, das für eine einzige Aufgabe Dutzende Male ausgelöst werden kann, ist dieser Tausch genau richtig.

Über den Oktober hinweg entsteht ein Muster. Kleine, spezialisierte, offen lizenzierte Modelle erscheinen, um die repetitive Arbeit in größeren Systemen zu erledigen: hier JetBrains, dazu die Entscheidungsmodelle von Liquid AI, der komprimierte 27B-Build von Underdog AI. Das Frontier-Modell setzt die Obergrenze. Die kleinen Modelle setzen die Untergrenze, und an der Untergrenze werden die meisten Token ausgegeben.

Offene Gewichte als Vertriebsstrategie

JetBrains ist kein Labor, das um Benchmark-Kronen kämpft. Es verkauft Entwicklerwerkzeuge, und sein Anreiz ist, diese Werkzeuge besser zu machen, nicht ein Modell zu hüten. Mellum2.1 unter Apache 2.0 zu veröffentlichen, lässt das Modell durch das Ökosystem wandern, auch in konkurrierende Editoren und Agent-Harnesses.

Das ist bemerkenswert. Wenn ein Werkzeugunternehmen ein Coding-Modell als Open Source freigibt, wettet es darauf, dass der Wert in der Integration und im Workflow liegt, nicht in den Gewichten. Es ist dieselbe Wette, die in diesem Jahr viele Infrastrukturunternehmen eingehen, und es ist eine Wette, die meist gut altert. Ein Modell, das niemand übernehmen kann, kann kein Standard werden.

Gerade Apache 2.0 zählt für die Akzeptanz. Eine permissive Lizenz erspart die Rechtsprüfung, die ein großes Unternehmen beim Ausprobieren eines neuen Modells ausbremst. Für ein Unternehmen, dessen Kunden genau solche Konzerne sind, ist ein permissiv lizenziertes Modell ein Weg, Vertrautheit zu säen, bevor etwas verkauft wird.

Der Vergleich mit den Frontier-Coding-Modellen

Die Frontier-Coding-Modelle sind bei schweren Problemen besser. Das steht außer Frage und dürfte sich so schnell nicht ändern. Strittig ist, ob jede Coding-Aufgabe die Frontier braucht. Die meisten brauchen sie nicht. Eine Funktion im ganzen Projekt umbenennen, eine Abhängigkeit aktualisieren, einen Test für bestehendes Verhalten schreiben: Das ist alltäglich, mühsam und für ein kleines Modell mit gutem Harness gut erreichbar.

Mellum2.1 versucht nicht, die größten Modelle bei ihren besten Aufgaben zu schlagen. Es versucht, bei den Aufgaben gut genug zu sein, die den Tag eines Entwicklers füllen. Das ist ein engeres Ziel und ein haltbareres, weil es nicht davon abhängt, ein Rennen zu gewinnen, das es nicht gewinnen wird.

Es gibt auch einen strategischen Grund für ein Werkzeugunternehmen, ein Modell in dieser Größe zu halten. Ein Modell, das klein genug für den lokalen Betrieb ist, lässt sich ohne Abrechnung pro Anfrage anbieten, was die Messung beseitigt, die Entwickler zögern lässt, Agents frei einzusetzen. Ein Editor, der sein eigenes Modell ohne Netzwerk-Roundtrip aufrufen kann, ist ein anderes Produkt als einer, der das nicht kann, und der Unterschied zeigt sich darin, wie forsch Nutzer sich darauf verlassen.

Warum Reinforcement Learning in einer echten Umgebung anders ist

Der Unterschied zwischen dem Training an Beispielen und dem Training an Ergebnissen verdient einen weiteren Durchgang, denn er ist das folgenreichste Detail dieser Veröffentlichung. Ein an Beispielen trainiertes Modell lernt, wie gute Ausgabe aussieht. Ein an Ergebnissen trainiertes Modell lernt, welche Handlungen zu guten Ergebnissen führen, eine andere und schwierigere Fähigkeit.

Handlungen sind Sequenzen. Ein Patch, der Tests besteht, ist keine einzelne Entscheidung, sondern eine Kette: wo nachsehen, was ändern, was ausführen, wie einen Fehler lesen. Reinforcement Learning in einer lebendigen Umgebung gibt dem Modell ein Signal über die ganze Kette, und das ist der einzige Weg zu lernen, dass manche lokal vernünftigen Entscheidungen an einer schlechten Stelle landen. Das ist die Intuition hinter echten Repositories statt eines kuratierten Problem-Sets.

Dieser Ansatz ist teurer und störanfälliger im Betrieb als überwachtes Feintuning, weshalb ihn nicht mehr Modelle nutzen. Er neigt außerdem dazu, Agents zu erzeugen, die sich in unbekannten Situationen besser verhalten, weil sie geübt haben, sich von Fehlern zu erholen, statt nur das Richtige nachzuahmen.

Worauf man achten sollte

Der naheliegende Test ist, ob ein so trainierter 12B-Agent bei einer echten Repository-Aufgabe standhält: einen fehlschlagenden Test diagnostizieren, einen Patch vorschlagen, das Ergebnis verifizieren. Wenn ja, wird die interessante Frage, wie nah ein kleines offenes Modell an Frontier-Coding-Qualität herankommen kann, sobald man ihm einen guten Harness und eine enge Rückkopplungsschleife gibt.

Diese Frage ist folgenreicher als jede einzelne Modellveröffentlichung. Wenn sich die Lücke zwischen einem 12B-Agenten und einem Frontier-Modell in der Praxis verkleinert, dann geht es in einem großen Teil des Coding-Agent-Markts nicht mehr darum, wer das beste Modell hat, sondern wer das beste Werkzeug um ein ausreichend gutes Modell herum baut. Mellum2.1 ist ein kleiner, konkreter Datenpunkt in diese Richtung, und die Richtung ist, was zählt.