Skywork-R1V3 : le raisonnement multimodal après un post-entraînement par RL
Skywork-R1V is an advanced multimodal AI model series developed by Skywork AI, specializing in vision-language reasoning.
En bref
- De quoi s’agit-il ?
- La série Skywork-R1V empile un raisonnement visuel en chaîne de pensée sur un socle InternVL3-38B, avec des poids ouverts et un code d'inférence réduit à deux scripts. La vraie question pour un ingénieur n'est pas le score MMMU, mais le coût matériel et la façon dont les résultats sont produits.
- À qui s’adresse-t-il ?
- Adoptez Skywork-R1V3 si vous disposez déjà d'un socle de serving pour modèles 38B et que vous voulez un raisonnement visuel en chaîne de pensée sous licence MIT, sans dépendre d'une API. Évitez-le si votre matériel se limite à une carte de moins de 30 Go, si vous avez besoin d'une bibliothèque d'inférence maintenue, ou si vous devez auditer la provenance des données d'entraînement.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 49 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le raisonnement visuel comme objet d'entraînement, pas comme prompt
La plupart des modèles vision-langage traitent une question sur une image en une passe : encoder l'image, générer la réponse. Skywork-R1V prend le problème par l'autre bout. Le README présente la série comme un travail de raisonnement multimodal obtenu par reinforcement finetuning, et la note de version de juillet 2025 indique que R1V3 améliore les capacités de raisonnement principalement par un algorithme de RL en post-entraînement. Autrement dit, la chaîne de pensée visuelle n'est pas obtenue en demandant au modèle de réfléchir dans le prompt : elle est installée dans les poids.
Le public visé est étroit. Ce n'est pas un outil pour développeur qui veut brancher une API et obtenir une description d'image. C'est un dépôt pour quelqu'un qui veut charger 38 milliards de paramètres, poser une question sur une ou plusieurs images, et récupérer une trace de raisonnement. Les sujets du dépôt le confirment : grpo, reinforcement-learning, vlm-r1, multimodal-understanding. La cible est l'équipe qui travaille sur l'évaluation de modèles ou sur un pipeline de raisonnement scientifique, pas le produit grand public.
Deux chemins d'exécution, deux environnements conda séparés
Le dépôt ne fournit pas de serveur ni de bibliothèque. Il fournit deux scripts d'inférence et un dossier eval. La séparation est explicite dans le README : un environnement conda pour Transformers, un autre pour vLLM et l'évaluation.
Pour Transformers, la procédure documentée est la suivante :
conda create -n r1-v python=3.10 && conda activate r1-v bash setup.sh
Pour vLLM et l'évaluation :
conda create -n r1v-vllm python=3.10 && conda activate r1v-vllm bash ./eval/vlmevalkit/build_env.sh
L'appel lui-même tient en une commande. En Transformers :
CUDA_VISIBLE_DEVICES="0,1" python inference_with_transformers.py --model_path path --image_paths image1_path --question "your question"
En vLLM, le script accepte plusieurs images et un paramètre de parallélisme tensoriel :
python inference_with_vllm.py --model_path path --image_paths image1_path image2_path --question "your question" --tensor_parallel_size 4
Le fait que --image_paths accepte plusieurs chemins dans l'exemple vLLM et un seul dans l'exemple Transformers est le genre de détail qui décide de l'outil à utiliser selon votre cas. Le README ne décrit pas la sortie produite par ces scripts, ni le format de la trace de raisonnement. C'est une lacune réelle : vous ne saurez pas avant d'exécuter si la chaîne de pensée est renvoyée structurée ou noyée dans le texte.
Ce que la licence MIT couvre, et ce qu'elle ne couvre pas
Le README est clair sur un point : le code du dépôt est sous MIT, avec usage commercial, modification et distribution autorisés, sans garantie. Le modèle de base, InternVL3-38B, est également annoncé sous MIT. C'est une combinaison permissive, plus simple que les licences à clauses d'usage qui accompagnent certains modèles ouverts.
Deux réserves. D'abord, la licence du code ne dit rien de la provenance des données d'entraînement ni des conditions attachées aux poids publiés sur Hugging Face : le README ne les détaille pas, et il faut consulter la fiche du modèle. Ensuite, l'usage commercial d'un modèle dérivé d'un autre modèle dépend de la chaîne complète des licences, pas seulement de la dernière. Le README affirme que la base est sous MIT, ce qui lève l'essentiel du risque, mais cette affirmation mérite d'être vérifiée sur la fiche InternVL3-38B avant un déploiement payant. Je ne donne pas d'avis juridique ici, seulement l'endroit où regarder.
Les chiffres du README et ce qu'ils ne disent pas
Le tableau d'évaluation place Skywork-R1V3-38B devant QVQ-72B, InternVL-78B et Qwen-72B sur une longue liste de benchmarks : MMMU à 76.0, MMMU-pro à 55.4, MathVista à 77.1, MathVerse en vision-only à 59.6. Le README précise que le code du dossier eval permet de reproduire ces résultats et que les valeurs marquées d'un astérisque proviennent de son propre framework d'évaluation.
Cette dernière mention est la plus importante du tableau. Un astérisque signifie que le score du concurrent a été mesuré par l'équipe qui publie le modèle, avec son propre harnais, et non repris de la publication d'origine. C'est une pratique courante, mais elle rend les comparaisons fragiles : un écart de deux points entre deux modèles peut tenir au format de réponse attendu ou au décodage. Le tableau montre aussi ses propres défaites, ce qui est honnête : Claude 3.7 devance R1V3 sur EMMA (56.5 contre 40.3) et sur SeePhys (34.6 contre 31.5), GPT-4o devance sur LogicVista (64.4 contre 59.7). Le profil est donc celui d'un modèle fort en mathématiques visuelles et en physique, moins net sur le raisonnement logique général.
Aucun de ces chiffres ne renseigne sur le débit, la latence ou la mémoire nécessaire en production. Le README n'aborde pas ces points.
38B paramètres : la contrainte qui décide de tout
Le modèle phare fait 38 milliards de paramètres. Le README ne publie pas d'exigence de mémoire pour R1V3, mais il en donne une pour la génération précédente : la version AWQ de R1V2 est annoncée comme supportant l'inférence sur une seule carte de plus de 30 Go. C'est une indication utile par analogie, pas une garantie pour R1V3, dont aucune quantification n'est mentionnée dans le matériel fourni.
Concrètement, cela signifie que le chemin vLLM avec --tensor_parallel_size 4 suppose quatre GPU. L'exemple Transformers fixe CUDA_VISIBLE_DEVICES="0,1", soit deux cartes. Si votre parc se limite à une carte de 24 Go, ce dépôt ne vous est d'aucun secours en l'état : il n'y a pas de variante quantifiée documentée pour R1V3, et vous devrez soit attendre une publication AWQ, soit quantifier vous-même, ce qui sort du périmètre du dépôt. C'est la limitation la plus concrète de l'ensemble.
Deuxième angle mort : le dépôt ne contient pas de code d'entraînement visible dans le README. Les sujets grpo et reinforcement-learning renvoient à la méthode décrite dans les rapports techniques, pas à des scripts fournis. Si votre objectif est de reproduire le post-entraînement par RL, ce dépôt ne suffit pas.
Face à un modèle multimodal servi par API
L'alternative la plus directe n'est pas un autre modèle ouvert mais un modèle propriétaire accessible par API. Le tableau du README inclut GPT-4o et Claude 3.7, et les écarts sont instructifs : R1V3 domine sur MMMU, MMMU-pro, MathVista, MathVerse et plusieurs benchmarks de physique, tandis que Claude 3.7 garde l'avantage sur EMMA et SeePhys.
La différence d'approche est plus profonde que les scores. Avec une API, vous n'avez ni poids, ni version épinglée, ni possibilité d'inspecter la trace de raisonnement selon vos propres règles. Avec Skywork-R1V, vous téléchargez des poids, vous les servez vous-même, et vous contrôlez le décodage. Le prix de ce contrôle est matériel et opérationnel : quatre GPU pour l'exemple vLLM, la gestion des versions de transformers et de vLLM via setup.sh, et aucune garantie de compatibilité ascendante quand ces bibliothèques évoluent. Une équipe qui n'a jamais servi un modèle de cette taille sous-estimera ce coût.
Il existe aussi des alternatives ouvertes plus petites, mais le README ne les mentionne pas et je n'ai pas de matériel pour les comparer ici.
Coût de maintenance et rythme de publication
Le dépôt n'a pas de releases publiées, et le README documente les versions par des entrées de journal : R1V en mars 2025, R1V2 en avril, R1V3 en juillet. Trois générations majeures en quatre mois. Ce rythme a deux conséquences pour un adoptant.
La première est que la documentation des versions antérieures reste dans le même README, sans guide de migration entre R1V, R1V2 et R1V3. Si vous épinglez R1V2 aujourd'hui, rien ne décrit ce qui change dans le script d'inférence pour passer à R1V3. La seconde est que les scripts setup.sh et eval/vlmevalkit/build_env.sh sont des points de dépendance fragiles : ils installent des versions de bibliothèques qui évoluent vite, et un environnement recréé dans six mois peut ne plus produire le même résultat. Épingler les versions après une première installation réussie est la seule protection que je peux recommander à partir du matériel fourni.
Le dossier eval est présenté comme permettant de reproduire les résultats publiés. C'est un argument en faveur du dépôt pour un usage d'évaluation, à condition d'accepter que le harnais soit celui de l'équipe qui publie le modèle.
Conclusion éditoriale
Adoptez Skywork-R1V3 si vous disposez déjà d'un socle de serving pour modèles 38B et que vous voulez un raisonnement visuel en chaîne de pensée sous licence MIT, sans dépendre d'une API. Évitez-le si votre matériel se limite à une carte de moins de 30 Go, si vous avez besoin d'une bibliothèque d'inférence maintenue, ou si vous devez auditer la provenance des données d'entraînement. Avant tout engagement, vérifiez trois points : la taille réelle des poids sur le dépôt Hugging Face, le contenu de inference/setup.sh pour les versions de transformers et de vLLM qu'il épingle, et la carte de licence du modèle de base InternVL3-38B.
Notes de la communauté