VLM-R1: GRPO-Training für visuelles Verstehen mit Qwen2.5-VL und InternVL
Solve Visual Understanding with Reinforced VLMs
Auf einen Blick
- Was ist das?
- VLM-R1 überträgt den R1-Ansatz auf Vision-Language-Modelle und trainiert Referring Expression Comprehension sowie offene Objekterkennung per GRPO statt per SFT. Das Repository liefert Skripte, Rewards und Checkpoints, aber keine fertige Inferenz-Pipeline.
- Für wen ist es gedacht?
- Wer Qwen2.5-VL oder InternVL mit GRPO für REC oder OVD nachtrainieren will und bereit ist, die Umgebung selbst aufzubauen, findet hier Skripte, Rewards und Checkpoints als Ausgangspunkt. Wer ein vortrainiertes Modell für den Produktionseinsatz sucht, sollte zu einem der veröffentlichten Checkpoints greifen statt das Training selbst zu fahren.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 71 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem VLM-R1 adressiert
Das Repository behandelt eine konkrete Frage: Lässt sich ein Vision-Language-Modell durch Reinforcement Learning dazu bringen, seine Antwort auf ein Bild zu begründen, statt eine Antwort direkt auszugeben? Die Autoren vergleichen für die Aufgabe Referring Expression Comprehension (REC) zwei Trainingswege auf Basis von Qwen2.5-VL: überwachtes Feintuning (SFT) und einen R1-artigen RL-Ansatz. Im README steht das Ergebnis dieser Gegenüberstellung: Auf In-Domain-Daten ändert sich die SFT-Leistung bei 100 bis 600 Trainingsschritten kaum, während das RL-Modell stetig zulegt. Auf Out-of-Domain-Daten verschlechtert sich das SFT-Modell mit steigender Schrittzahl leicht, das RL-Modell überträgt seine Reasoning-Fähigkeit dagegen auf Daten außerhalb des Trainingsverteilung. Wer also ein Modell für Bildregionen aufbauen will, das auch bei verschobenen Testdaten hält, ist die Zielgruppe. Wer lediglich ein festes Erkennungsmodell für bekannte Klassen braucht, findet hier keinen Vorteil.
Der Mechanismus: GRPO, Rewards und der Weg durch den Code
Der Trainingskern liegt in src/open-r1-multimodal/src/open_r1/grpo_jsonl.py. Laut Changelog wurde die REC-Pipeline dort integriert, damit verschiedene Aufgaben denselben Einstiegspunkt nutzen. Ein neuer Parameter, is_reward_customized_from_vlm_module, steuert, ob die Reward-Logik im VLM-Modul selbst liegt. Ist er true, wird die Belohnung in QwenVL2Module (src/open-r1-multimodal/src/open_r1/vlm_modules/qwen_module.py) oder InternVLModule (src/open-r1-multimodal/src/open_r1/vlm_modules/internvl_module.py) berechnet, je nach gewähltem Modell. Das ist eine bewusste Kopplung: Die Reward-Funktion kennt das Ausgabeformat des jeweiligen Modells, was die Anpassung an neue Modellfamilien erleichtert, aber die Reward-Logik über mehrere Dateien verteilt. Für die OVD-Aufgabe kamen am 3. April 2025 die Rewards odLength, weighted_sum und cosine hinzu, deren Verwendung in einem Blogbeitrag und in den Findings beschrieben ist. Die Daten fließen als JSONL herein, das Training läuft über GRPO, und die Auswertung für REC erfolgt separat in src/eval/test_rec_r1.py. Wer die Reward-Gewichtung ändern will, muss also an mehr als einer Stelle suchen.
Installation und Start: was die Skripte vorgeben
Das Repository liefert keine Installationsanleitung im README-Ausschnitt, sondern verweist auf Skripte. Für volles Feintuning mit GRPO ist run_scripts/run_grpo_rec.sh der Einstieg, für LoRA run_scripts/run_grpo_rec_lora.sh. Beide Skripte setzen die Trainingsparameter, darunter freeze_vision_modules, das laut Feature-Liste auf true gesetzt wird, um die Vision-Module einzufrieren. Multi-Node-Training ist über run_scripts/multinode_training_demo.sh abgedeckt, Multi-Image-Eingaben über run_scripts/run_grpo_gui.sh. Der Abschnitt For your own data im README beschreibt das Datenformat, das Multi-Image-Format wurde am 15. März 2025 ergänzt. Als Modelle sind QwenVL und InternVL unterstützt; wie ein weiteres Modell hinzukommt, steht in assets/add_new_model.md. Auffällig ist, dass das README keine Versionsangaben zu transformers, torch oder flash-attn macht. Wer den Lauf startet, muss diese Abhängigkeiten aus den Skripten und dem Code selbst ableiten. Das ist der größte Reibungspunkt beim Einstieg.
Die Grenze: wann VLM-R1 das falsche Werkzeug ist
Das Repository ist eine Trainings- und Evaluationssammlung, kein Inferenzserver. Wer ein Modell für eine Anwendung braucht, muss entweder einen der veröffentlichten Checkpoints auf Hugging Face oder ModelScope nutzen oder die Gewichte selbst über eine eigene Pipeline laden. Für den produktiven Betrieb ist das ein erheblicher Zusatzaufwand, den das Repository nicht abnimmt. Ein zweiter Punkt betrifft die Datenqualität: Die Autoren weisen selbst darauf hin, dass frühere REC-SFT-Experimente eine falsche Pixel-Konfiguration verwendeten und die Studie deshalb mit korrigierter Konfiguration auf komplexeren Out-of-Domain-Daten wiederholt wurde. Das ist ein ehrlicher Hinweis, aber auch eine Warnung: Kleine Konfigurationsfehler verschieben die Ergebnisse so stark, dass Schlussfolgerungen kippen können. Wer keine Kapazität hat, Trainingsläufe sauber zu wiederholen und die Pixel-Konfiguration zu prüfen, sollte die Finger davon lassen. Und wer lediglich geschlossene Objektklassen in bekannten Domänen erkennen will, braucht kein Reasoning-Training: Ein spezialisiertes Detektionsmodell ist dort billiger und schneller.
Der Vergleich: SFT mit korrigierter Pixel-Konfiguration
Die naheliegende Alternative ist überwachtes Feintuning auf denselben Daten, und genau diesen Vergleich zieht das Projekt selbst. Der Unterschied liegt nicht im Modell, sondern im Trainingssignal. SFT optimiert auf die nächste Token-Wahrscheinlichkeit einer vorgegebenen Antwort; das Modell lernt, die Trainingsantwort nachzuahmen. GRPO bewertet mehrere generierte Antworten pro Eingabe mit einer Reward-Funktion und verstärkt die besseren. Für REC heißt das: Das Modell muss eine Begründung erzeugen, die zur richtigen Bildregion führt, statt eine Region direkt auszugeben. Der Preis ist ein höherer Rechenaufwand pro Schritt, weil mehrere Antworten generiert und bewertet werden. Der Gewinn zeigt sich laut README erst außerhalb der Trainingsverteilung. Wer nur In-Domain evaluiert, sieht bei kleinen Schrittzahlen kaum einen Unterschied. Das ist die zentrale Entscheidungsgrundlage: Der RL-Ansatz lohnt sich, wenn Out-of-Domain-Generalisierung das Ziel ist, nicht wenn ein Benchmark auf denselben Daten maximiert werden soll.
Hardware, Ascend und der Wartungsaufwand
Seit August 2025 dokumentiert das Repository Deployment auf Huawei-Ascend-Hardware. Für Atlas 800T A2 und Atlas 300I Duo gibt es Anleitungen unter ascend_inference/910B/vllm_ascend/README.md und ascend_inference/300IDuo/README.md, basierend auf vllm-ascend. Für das xllm-Framework von JD liegt eine eigene Anleitung unter ascend_inference/910B/xllm/README.md; laut Changelog sinkt dort die Time to First Token um 50 Prozent gegenüber vllm-ascend, der Durchschnittsdurchsatz steigt um 127 Prozent. Diese Zahlen stammen aus dem Repository und beziehen sich auf diesen konkreten Vergleich, nicht auf allgemeine Inferenz. Wer auf Nvidia-Hardware bleibt, findet in den genannten Skripten keine entsprechenden Hinweise. Der Wartungsaufwand ist real: Drei Releases zwischen März und April 2025, danach weitere Änderungen bis August 2025, darunter eine nachträgliche Bounding-Box-Anpassung für QwenVL in Training und Evaluation. Wer das Repository forkt, übernimmt diese Änderungen selbst. Unter Apache-2.0 ist das erlaubt, auch kommerziell; die Lizenz verlangt lediglich die Beibehaltung der Urheberrechtshinweise. Rechtliche Beratung ersetzt das nicht.
Was vor dem ersten eigenen Lauf zu klären ist
Drei Punkte lassen sich aus dem Material direkt ableiten. Erstens: Die Skripte unter run_scripts/ sind der einzige dokumentierte Einstieg; ob die darin gesetzten Hyperparameter zu einer anderen Datenmenge passen, sagt das Repository nicht. Zweitens: is_reward_customized_from_vlm_module entscheidet, wo die Reward-Logik liegt. Wer eigene Rewards einbringt, muss diese Entscheidung bewusst treffen, sonst sucht man die Funktion an der falschen Stelle. Drittens: Für REC gibt es mit src/eval/test_rec_r1.py ein separates Evaluationsskript, dessen Bounding-Box-Nachbearbeitung am 26. Juni 2025 geändert wurde. Wer ältere Ergebnisse mit neuen vergleicht, muss diese Änderung berücksichtigen. Das Repository liefert Checkpoints für Qwen2.5-VL in 3B-Größe für REC, OVD und Math sowie Demos für REC und OVD. Wer diese direkt nutzt, spart sich den gesamten Trainingspfad. Wer selbst trainiert, sollte mit einem der bereitgestellten Skripte beginnen und erst danach die Reward-Konfiguration anfassen.
Redaktionelles Fazit
Wer Qwen2.5-VL oder InternVL mit GRPO für REC oder OVD nachtrainieren will und bereit ist, die Umgebung selbst aufzubauen, findet hier Skripte, Rewards und Checkpoints als Ausgangspunkt. Wer ein vortrainiertes Modell für den Produktionseinsatz sucht, sollte zu einem der veröffentlichten Checkpoints greifen statt das Training selbst zu fahren. Vor jedem eigenen Lauf: prüfen, ob die installierte transformers-Version zur im Repository erwarteten Qwen2.5-VL-Unterstützung passt, und ob freeze_vision_modules im eigenen Szenario true oder false sein soll. Beide Punkte entscheiden, ob der Lauf überhaupt startet und ob das Ergebnis zu den veröffentlichten Zahlen führt.
Community-Notizen