Skywork-R1V: Ein 38B-Modell für multimodales Reasoning, mit vLLM oder Transformers lokal betrieben

Welches Problem Skywork-R1V adressiert und für wen es gedacht ist

Die meisten offenen Vision-Language-Modelle beantworten Bildfragen in einem einzigen Vorwärtsdurchlauf. Skywork-R1V setzt dagegen auf eine sichtbare Denk- oder Begründungskette vor der Antwort. Das Repository beschreibt den Ansatz als Reinforcement Finetuning auf einem bestehenden Bild-Text-Modell, konkret auf InternVL3-38B. Die Zielgruppe sind damit weniger Anwendungsentwickler, die eine Bildbeschreibung in eine App einbauen wollen, sondern Forschungsteams und Plattformgruppen, die ein offenes Modell mit nachvollziehbaren Zwischenschritten für Aufgaben aus Mathematik, Logik und Physik benötigen. Das README nennt als Beispielaufgaben unter anderem MathVista, MathVerse, MathVision, Visulogic, LogicVista und PhyX. Wer eine OCR-Pipeline, einen Bildtagger oder einen Chatbot für Produktfotos baut, bekommt hier ein Modell, dessen Stärke in einem anderen Aufgabenfeld liegt und dessen Betriebskosten deutlich über denen kleinerer Modelle liegen.

Aufbau: InternVL3-38B als Basis, RL als Nachtraining

Das Repository beschreibt die Architektur nicht im Detail, sondern verweist auf den technischen Bericht (arXiv 2507.06167 für R1V3, 2504.05599 für die erste Generation). Aus dem README geht hervor, dass InternVL3-38B als Basismodell dient und die multimodalen Reasoning-Fähigkeiten vor allem durch einen RL-Algorithmus im Post-Training verbessert wurden. Der Themenkatalog des Repositories nennt GRPO explizit, das Modell wird also mit gruppenrelativer Policy-Optimierung nachtrainiert. Der Datenfluss zur Laufzeit ist der eines klassischen Vision-Language-Modells: Bild oder Bilder werden zusammen mit einer Textfrage an das Modell übergeben, das Modell erzeugt zunächst eine Begründungskette und daraus die Antwort. Die Inferenzskripte unterscheiden sich nur im Backend: inference_with_transformers.py nutzt die Hugging-Face-Transformers-Bibliothek, inference_with_vllm.py setzt auf vLLM und akzeptiert tensor_parallel_size, um die Gewichte über mehrere GPUs zu verteilen. Ein separates Serving-Framework, ein API-Server oder ein Docker-Setup werden im README nicht beschrieben.

Inferenz lokal starten: die konkreten Befehle aus dem README

Das README gibt einen vollständigen Ablauf vor. Zuerst wird das Repository geklont und in das Unterverzeichnis inference gewechselt. Für die Transformers-Variante wird eine Conda-Umgebung mit Python 3.10 angelegt, aktiviert und anschließend bash setup.sh ausgeführt. Für vLLM und die Evaluation existiert eine zweite Umgebung, in der bash ./eval/vlmevalkit/build_env.sh ausgeführt wird. Der Aufruf mit Transformers lautet CUDA_VISIBLE_DEVICES="0,1" python inference_with_transformers.py mit den Argumenten --model_path, --image_paths und --question. Für vLLM lautet der Aufruf python inference_with_vllm.py mit denselben Argumenten plus --tensor_parallel_size 4. Die Modellgewichte selbst liegen nicht im Repository, sondern auf Hugging Face unter Skywork/Skywork-R1V-38B. Wer die Evaluation nachfahren will, findet die Skripte im eval-Ordner; das README behauptet, dass sich die Tabellenwerte damit reproduzieren lassen, was auf eigener Hardware zu prüfen ist.

Hardware-Anforderung und die Grenze der Praktikabilität

Das README macht keine Angabe zum VRAM-Bedarf der 38B-Version. Aus der Modellgröße und dem vLLM-Beispiel mit tensor_parallel_size 4 lässt sich ableiten, dass ein Betrieb auf einer einzelnen Karte nicht vorgesehen ist. Der einzige konkrete Speicherhinweis im Repository betrifft eine andere Version: die AWQ-quantisierten Varianten von R1V und R1V2 werden als Single-Card-tauglich ab über 30 GB beschrieben. Für R1V3 fehlt eine solche Angabe. Das ist die zentrale Einschränkung. Wer keine Multi-GPU-Maschine mit ausreichend Speicher für 38B-Gewichte plus KV-Cache und Bildtokens hat, kann das Modell nicht sinnvoll betreiben. Hinzu kommt, dass Denkketten die Ausgabelänge erhöhen. Jede Anfrage erzeugt zusätzliche Tokens vor der eigentlichen Antwort, was Durchsatz und Latenz gegenüber einem Modell ohne explizite Begründung verschlechtert. Für interaktive Anwendungen mit harter Latenzgrenze ist das ein Ausschlusskriterium, nicht ein Detail.

Was die Benchmark-Tabelle zeigt und was sie nicht zeigt

Die Tabelle im README vergleicht Skywork-R1V3-38B mit QVQ-72B, InternVL-78B, Qwen-72B, Claude 3.7 und GPT-4o über 16 Benchmarks. Das Modell führt die Tabelle in neun Zeilen an, darunter MMMU mit 76.0, MathVista mit 77.1, MathVerse vision-only mit 59.6 und PhyX mit 52.8. In anderen Zeilen liegt es nicht vorn: bei MMStar erreicht InternVL-78B mit 72.5 einen höheren Wert, bei MMBench-en-1.1 führt Qwen-72B mit 88.0, bei LogicVista liegt GPT-4o mit 64.4 vorne, bei SeePhys Claude 3.7 mit 34.6, und bei EMMA erreicht das Modell 40.3 gegenüber 56.5 bei Claude 3.7. Die Tabelle ist also kein Beleg für durchgängige Überlegenheit. Zudem markiert das README mit einem Sternchen, welche Vergleichswerte aus dem eigenen Evaluationsframework stammen; diese Zahlen sind nicht unabhängig erhoben. Wer die Tabelle als Auswahlgrundlage nutzt, sollte auf die Sternchen achten und die Werte für die eigenen Aufgaben selbst nachfahren, statt die fettgedruckten Bestwerte zu übernehmen.

Alternative: ein kleineres VLM statt eines 38B-Reasoning-Modells

Die naheliegende Alternative innerhalb desselben Repositories ist Skywork-R1V2-38B-AWQ. Der Unterschied liegt nicht im Aufgabenprofil, sondern im Betriebsmodus: die AWQ-Variante ist auf Single-Card-Inferenz ab etwa 30 GB ausgelegt, während für R1V3 nur das Multi-GPU-Beispiel mit tensor_parallel_size 4 dokumentiert ist. Wer eine einzelne Karte mit 48 GB betreibt, kann R1V2-AWQ fahren, R1V3 aber nicht ohne Weiteres. Der zweite Unterschied ist die Generation: R1V2 ist vom April 2025, R1V3 vom Juli 2025 und erreicht laut README die höheren Benchmark-Werte, etwa 76.0 statt der für R1V2 berichteten Werte. Eine zweite Alternative sind kleinere Vision-Language-Modelle, die auf einer Karte laufen und keine explizite Begründungskette erzeugen. Sie sind bei einfachen Bildfragen schneller und billiger, verlieren aber genau die Fähigkeit, für die Skywork-R1V gebaut wurde. Die Wahl ist damit keine Geschmacksfrage, sondern eine Frage des Speichers und der Latenzanforderung.

Lizenz, Wartung und Kosten der Aktualisierung

Das Code-Repository steht unter der MIT-Lizenz, das README listet kommerzielle Nutzung, Änderung und Weitergabe als erlaubt und Haftung als ausgeschlossen. Das Basismodell InternVL3-38B ist ebenfalls MIT-lizenziert. Der Code ist damit unkritisch, die Modellgewichte sind es nicht automatisch: das README macht keine Angabe zu einer eigenen Lizenz für Skywork/Skywork-R1V-38B auf Hugging Face, das ist vor einer kommerziellen Nutzung zu klären. Das ist keine Rechtsberatung, sondern ein Hinweis auf eine offene Stelle im Material. Zur Wartung: das Repository verzeichnet keine Releases, die letzten Änderungen stammen laut Metadaten vom Juli 2026. Die Versionsgeschichte im README zeigt einen schnellen Rhythmus zwischen März und Juli 2025 mit R1V, R1V2, den AWQ-Varianten und R1V3. Wer R1V3 heute einführt, sollte damit rechnen, dass eine Nachfolgeversion erscheint und die Inferenzumgebung erneut angepasst werden muss. Die setup.sh und build_env.sh binden konkrete Bibliotheksversionen, ein Upgrade des Basismodells zieht also einen erneuten Aufbau beider Conda-Umgebungen nach sich.

Wer Skywork-R1V3-38B einführen sollte und wer nicht

Geeignet ist das Modell für Teams mit Multi-GPU-Hardware, die ein offenes Vision-Language-Modell mit nachvollziehbaren Begründungsschritten für mathematische, logische und physikalische Bildaufgaben benötigen und die Bereitschaft haben, die im eval-Ordner enthaltenen Skripte selbst auszuführen. Ungeeignet ist es für Anwendungen auf einer einzelnen Karte, für latenzkritische Dienste und für Aufgaben, bei denen eine kurze Bildbeschreibung genügt. Vor der Einführung sind drei Dinge zu prüfen: ob die im README genannten Benchmark-Werte mit den eval-Skripten auf eigener Hardware erreicht werden, ob der tatsächliche Speicherbedarf der 38B-Gewichte zum GPU-Pool passt, und ob die Modellgewichte auf Hugging Face eine Nutzung erlauben, die über die MIT-Lizenz des Codes hinausgeht.

Redaktionelles Fazit

Wer mehrere GPUs mit ausreichend VRAM betreibt und ein offenes Vision-Language-Modell mit Denkketten für Mathematik, Logik und Physik braucht, kann Skywork-R1V3-38B über inference_with_vllm.py mit passendem tensor_parallel_size evaluieren. Wer ein Modell für eine einzelne 24-GB-Karte oder für latenzkritische Produktionsdienste sucht, sollte zuerst die AWQ-Variante von R1V2 prüfen oder ein kleineres Modell wählen. Vor dem Adoptionsentscheid sind drei Dinge zu verifizieren: ob die im eval-Ordner enthaltenen Skripte die im README genannten Benchmark-Werte auf eigener Hardware reproduzieren, ob die tatsächliche VRAM-Belegung der 38B-Gewichte zum vorhandenen GPU-Pool passt, und ob das Modell auf die eigenen Bildtypen dieselbe Antwortqualität liefert wie auf den Benchmark-Verteilungen.

Offizielle Quellen

1. Issues
2. License: MIT
3. Project website
4. README
5. SkyworkAI/Skywork-R1V on GitHub