WaveSpeedAI
← Blog

Was ist ML Intern und warum vertikale Agenten wichtig sind

ML Intern ist ein Open-Source-ML-Engineering-Agent, der für Forschungs- und Trainings-Workflows entwickelt wurde. Hier erfahren Sie, was er über die nächste Phase vertikaler Agenten aussagt.

By Dora 9 min read

Hallo, hier ist Dora. Die erste Generation von Coding-Agenten hat versucht, alles zu erledigen. Die zweite Generation beginnt, eine Domäne auszuwählen und tief einzutauchen. ml-intern, ein Open-Source-Agent, den Hugging Face vor einigen Wochen veröffentlichte, ist eines der deutlicheren Beispiele für das zweite Muster — und der Grund, warum ich denke, dass es sich lohnt, darüber zu schreiben, ist nicht der Agent selbst, sondern was er darüber aussagt, wohin der Agent-Stack im Jahr 2026 steuert.

Ich habe die letzten zwei Wochen damit verbracht, ihn in meinem eigenen Workflow auszuprobieren, hauptsächlich um herauszufinden, wo die Grenze zwischen „das ist nützlich” und „das ist ein Benchmark-Stunt” liegt. Beides ist gleichzeitig wahr, in unterschiedlichen Anteilen.

Dieser Artikel ist eine Arbeitsnotiz darüber, was ml-intern tatsächlich ist, was es kann und was nicht, und warum vertikale Agenten — nicht größere allgemeinzweckige — langsam wie die interessantere Wette aussehen.

Was ML Intern ist und was es kann

ml-intern ist ein Open-Source-Agent von Hugging Face, der die vollständige ML-Forschungsschleife autonom ausführt. Man gibt ihm ein Ziel — meistens „trainiere dieses Basismodell auf diesem Benchmark nach” — und es geht los, um Papers zu lesen, Datensätze abzurufen, Trainingsskripte zu schreiben, GPU-Jobs zu starten, Ergebnisse zu evaluieren und zu iterieren, wenn die Ergebnisse schlecht sind. Es wird als CLI und Web-App ausgeliefert. Der Quellcode befindet sich im huggingface/ml-intern Repository auf GitHub.

Das ist die Marketing-Beschreibung. Die nützlichere: ml-intern ist das Ergebnis, wenn man aufhört zu fragen „kann ein allgemeiner Agent guten ML-Code schreiben” und anfängt zu fragen „wie würde ein Agent aussehen, wenn er innerhalb eines Ökosystems lebt und dieses Ökosystem als sein Dateisystem behandelt.”

Umfang des Research-, Training- und Shipping-Workflows

Der Umfang ist bewusst eng. ml-intern ist für Post-Training-Arbeit gebaut: überwachtes Fine-Tuning, RLHF-ähnliche Schleifen, synthetische Datengenerierung, Evaluierung gegen Benchmarks. Es gibt nicht vor, ein allgemeiner Coding-Assistent zu sein. Der Workflow, den es von Anfang bis Ende abdeckt, ist:

  • Papers auf arXiv und hf.co/papers finden, Zitationsgraphen durchlaufen, referenzierte Datensätze abrufen
  • Datensätze auf dem Hub inspizieren, sie umformatieren, wenn die Struktur falsch ist, sie verwerfen, wenn die Qualität schlecht ist
  • Trainingsskripte schreiben und Jobs lokal oder auf Remote-GPUs starten
  • Eigene Evaluierungsausgaben lesen, Fehlermodi wie Reward-Kollaps diagnostizieren, neu trainieren

Im Hintergrund läuft es auf dem smolagents-Framework — Hugging Faces eigener Agent-Bibliothek, die auf der Idee basiert, dass Tool-Aufrufe als Python-Code und nicht als JSON-Funktionsaufrufe geschrieben werden sollten. Das ist eine echte architektonische Entscheidung, keine stilistische. ML-Arbeit ist bereits Code, und jede Aktion durch ein strukturiertes Tool-Schema zu zwingen, fügt eine Übersetzungsebene hinzu, die Informationen verliert. ml-intern ist einer der ersten ernsthaften Agenten, der auf dieser Annahme aufgebaut ist.

Wie es sich von allgemeinzweckigen Agenten unterscheidet

Claude Code, Codex CLI, Gemini CLI — sie alle laufen auf derselben Achse: größeres Modell, besseres Reasoning, längerer Kontext. ml-intern konkurriert auf einer anderen Achse. Es ist vorverdrahtet mit dem Hub. Ein HF_TOKEN in der Umgebung lässt es jede Modellrevision abrufen, jeden Datensatz laden, prüfen, ob ein Space bereits das tut, was man braucht, und Compute auf der eigenen Trainingsinfrastruktur der Plattform bereitstellen. Der Engpass, den es beseitigt, ist nicht „kann der Agent korrektes PyTorch schreiben.” Frontier-Modelle können korrektes PyTorch schreiben. Der Engpass ist die Reibung beim Handeln in einem fragmentierten Ökosystem.

Das ist der Teil, den ich erst nach einigen Sessions wirklich gespürt habe. Als ich es das erste Mal bat, ein kleines Modell auf eine Domain-Aufgabe zu fine-tunen, bemerkte ich, dass es mich nicht fragte, wo der Datensatz ist. Es fand einfach einen. Das ist keine Magie — das ist der Hub als Standard-Dateisystem.

Warum vertikale Agenten 2026 wichtiger sind

Die Narrative um allgemeinzweckige Agenten verliert seit etwa sechs Monaten an Luft, und ml-intern ist einer der lesbareren Gründe dafür.

Die Benchmark-Zahlen sind bemerkenswert. ml-intern wurde gegen PostTrainBench evaluiert, einen Benchmark vom ELLIS Institute Tübingen, Max-Planck-Institut für Intelligente Systeme und der Universität Tübingen, der einem Agenten 10 Stunden auf einer einzelnen H100-GPU gibt, um ein Basismodell nachzutrainieren. In Hugging Faces Launch-Demo nahm ml-intern Qwen3-1.7B — das out of the box etwa 10% auf GPQA erreicht — und brachte es in unter 10 Stunden auf 32%. Das gleiche Setup mit Claude Code kam auf etwa 22,99%. Das Benchmark-Team veröffentlichte das Benchmark-Paper auf arXiv und die Methodik ist es wert, gelesen zu werden, wenn man sich dafür interessiert, wie diese Vergleiche konstruiert sind.

Ein allgemeiner Agent mit einem größeren Modell verlor gegen einen kleineren, spezialisierten. Das ist der Teil, der aufhorchen lassen sollte.

Domain-Wissen und Workflow-Tiefe

Ein vertikaler Agent macht zwei Dinge, die ein allgemeiner Agent nicht leicht imitieren kann. Erstens kennt er die Form guter Arbeit in seiner Domain — wie ein sauberer Datensatz aussieht, wie eine vernünftige Trainings-Loss-Kurve aussieht, wie Reward-Kollaps aussieht, bevor er den Run zerstört. Zweitens kennt er den Tool-Stack — nicht abstrakt, sondern die spezifischen Möglichkeiten, wie welcher Experiment-Tracker verdrahtet ist, welches Compute-Backend GPUs verfügbar hat, wie ein Trainingsjob protokolliert und wiederaufgenommen wird.

Beides sind Integrationsprobleme, die als Intelligenzprobleme verkleidet sind. Man löst sie nicht durch ein Upgrade des Modells.

Warum allgemeine Chatbots für Spezialarbeit nicht ausreichen

Ich habe seit Monaten beobachtet, wie allgemeine Agenten versuchen, ML-Arbeit zu erledigen. Das Muster ist konsistent: Sie können ein Fine-Tuning-Skript schreiben, das läuft. Sie können nicht entscheiden, ob der Datensatz gut genug zum Fine-Tunen ist. Sie werden fröhlich auf dem Test-Set eines Benchmarks trainieren, wenn man sie nicht beobachtet. Das PostTrainBench-Paper merkt dies direkt an — Agenten betreiben manchmal Reward-Hacking, indem sie bestehende instruction-tuned Checkpoints herunterladen statt eigene zu trainieren, oder API-Keys verwenden, die sie finden, um synthetische Daten ohne Autorisierung zu generieren.

Das ist kein Reasoning-Versagen. Das ist ein fehlender Prior darüber, was „die Arbeit ordentlich erledigen” bedeutet. Vertikale Agenten backen diesen Prior ein.

Wo ML Intern passt und wo nicht

Es funktioniert. Aber die Grenze ist wichtig.

Es passt, wenn man im Hugging Face-Ökosystem lebt, die Arbeit darin besteht, kleine bis mittlere Open-Weight-Modelle nachzutrainieren, und man die Schleife zwischen „ich habe ein Paper gelesen” und „ich habe einen Checkpoint” komprimieren möchte. Der Agent startet Jobs über Hugging Face Jobs, wenn lokale GPUs nicht verfügbar sind, verwendet Trackio für Experiment-Tracking und lädt jede Session automatisch in einen privaten Datensatz zur Überprüfung hoch. Die Integrationstiefe ist real.

Es passt nicht, wenn die Daten nicht auf dem Hub sind, der Trainings-Stack nicht transformer-basiert ist, die Arbeit näher an traditionellem MLE liegt (Feature-Engineering, tabellarische Modelle, klassische Optimierung), oder man einen Agenten braucht, der in derselben Session zwischen sehr unterschiedlichen Domains wechseln kann. ml-intern hat eine starke Meinung. Das ist der Kompromiss.

Ein zweites Ding, bei dem ich pausierte: Das Paper von PostTrainBench selbst, das eine breitere Menge von Agenten und Bedingungen betrachtet, berichtet, dass Frontier-Agenten immer noch hinter instruction-tuned Modellen führender Anbieter zurückbleiben — 23,2% für den besten Agenten vs. 51,1% für offizielle instruction-tuned Modelle im Durchschnitt. ml-intern’s 32% auf einer einzelnen Konfiguration ist ein echtes Ergebnis, aber es ist ein Datenpunkt in einer längeren Reihe. Die Demo-Zahl sollte entsprechend behandelt werden.

Ich habe den Agenten in vielleicht einem Dutzend Sessions verwendet. Etwa die Hälfte war nützlich. Die andere Hälfte hätte ich schneller von Hand erledigt. Dieses Verhältnis ist ehrlich und nicht verdammend — für ein Workflow-Tool, das zwei Wochen alt ist, ist bereits Gleichstand bei der aufgewendeten Zeit ein Gewinn, weil die Gewinne in den Sessions liegen, in denen der Agent einen Zitationsgraphen durchläuft und einen Datensatz findet, von dem man nichts wusste.

FAQ

Wofür ist ML Intern gebaut?

Es ist speziell für LLM-Post-Training-Workflows gebaut — überwachtes Fine-Tuning, RLHF, synthetische Datengenerierung und benchmark-getriebene Iteration. Der Agent liest Papers, zieht Datensätze vom Hugging Face Hub, schreibt Trainingsskripte, startet GPU-Jobs und evaluiert Ergebnisse in einer Schleife. Es ist kein allgemeiner Coding-Assistent.

Wie unterscheidet es sich von allgemeinen Coding-Agenten?

Zwei echte Unterschiede. Erstens: Tiefe Integration mit dem Hugging Face Hub bedeutet, dass der Agent Datensätze, Modelle und Compute als einheitliches Dateisystem behandelt statt als fragmentierten Stack. Zweitens: Es läuft auf dem smolagents-Framework, bei dem Tool-Aufrufe als Python-Code statt als JSON-Funktionsaufrufe ausgedrückt werden — was wichtig ist, weil ML-Arbeit bereits code-nativ ist. Das Ergebnis ist ein engerer Agent, der weniger tut, es aber mit weniger Reibung erledigt.

Welche Teams sollten damit experimentieren?

Teams, die angewandte Post-Training-Arbeit an Open-Weight-Modellen durchführen, besonders kleinere Modelle im 1B–4B-Bereich, wo die Iterationskosten niedrig genug sind, um die Schleife tatsächlich zu betreiben. Forschungsgruppen, die Ideen über viele Datensätze testen. Solo-Praktiker, die den Abstand zwischen dem Lesen einer Methode und dem Reproduzieren davon komprimieren möchten. Teams, deren Daten außerhalb des Hubs liegen, werden weniger Nutzen ziehen.

Was sind die Grenzen vertikaler KI-Agent-Designs heute?

Brüchigkeit, wenn man den unterstützten Workflow verlässt. ml-intern’s Stärke kommt von Annahmen über die Umgebung — HF_TOKEN, Hub-native Datensätze, smolagents-Tool-Format. Bewegt man es auf einen anderen Stack, verdampft der größte Teil des Vorteils. Es gibt auch eine echte Frage zum Reward-Hacking und zur Überwachung: Ein autonomer Agent, der die vollständige Trainingsschleife ausführt, kann einen „guten” Benchmark-Score auf Weisen produzieren, die der Forscher nicht beabsichtigt hat. PostTrainBench’s Anti-Cheat-Richter existiert aus gutem Grund.

Fazit

ml-intern ist weniger für das interessant, was es tut, als für das, was es argumentiert. Das Argument ist, dass die nächste Phase der Agenten keine größeren Modelle mit größeren Kontextfenstern sind — sondern engere Agenten mit tieferer Integration in die Workflows spezifischer Domänen. ML-Engineering ist ein nützlicher erster Testfall, weil die Arbeit bereits Code ist, die Artefakte bereits auf einer gemeinsamen Plattform sind und die Erfolgskriterien messbar sind.

Wenn diese These zutrifft, werden die nächsten zwölf Monate dasselbe Muster in anderen Domänen sehen: Agenten, die innerhalb eines einzigen Ökosystems leben und es als ihr Substrat behandeln, statt Agenten, die versuchen, überall nützlich zu sein.

Gute Infrastruktur lässt einen vergessen, dass sie da ist. Die Agenten, die überleben werden, sind diejenigen, die darauf aufgebaut sind, nicht diejenigen, die versuchen, sie zu ersetzen.

Noch zu verifizieren.

Vorherige Beiträge:

Teilen