Skywork-R1V3 を採用する前に読む、38B 視覚言語推論モデルの構成と推論手順
Skywork-R1V is an advanced multimodal AI model series developed by Skywork AI, specializing in vision-language reasoning.
ひと目でわかる
- これは何？
- SkyworkAI が公開するマルチモーダル推論モデル Skywork-R1V シリーズの、リポジトリ構成・推論コマンド・評価結果の読み方を整理する。MIT ライセンスのコードと、InternVL3-38B を土台にした重みの関係を切り分けて確認する。
- 誰に向いている？
- 視覚と言語をまたぐ推論タスクを自前の GPU 上で動かしたい研究・検証チームに向く。逆に、閉域での長期運用や日本語の画像内テキスト処理を主目的にする場合、このリポジトリだけでは判断材料が足りない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 49 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Skywork-R1V が埋めようとしている穴はどこにあるか
画像を見て答えるモデルは多いが、その多くは視覚入力をテキストに変換したあと、通常の言語モデルとして答えを出す。Skywork-R1V が狙うのはこの間にある推論の部分で、README は初期バージョンを「first industry open-sourced multimodal reasoning model with advanced visual chain-of-thought capabilities」と説明している。図表の読み取り、数式を含む画像問題、論理パズルのように、視覚情報を保持したまま複数段の推論を積む必要があるタスクが対象になる。
想定読者は、マルチモーダル推論のベンチマークを再現したい研究者と、社内の画像処理パイプラインに推論モデルを組み込みたいエンジニアだ。API 経由で済ませる層ではなく、38B クラスの重みを自分のマシンに置いて動かす前提の設計になっている。
重みとコードは別物として配られている
このリポジトリに入っているのは推論コードと評価コードであって、学習済み重みそのものではない。重みは Hugging Face の Skywork/Skywork-R1V-38B として別に配布され、README の推論コマンドは --model_path でそのローカルパスを指す形になっている。つまり git clone しただけでは何も動かない。
もう一点、ライセンスの層が二つある。コードリポジトリは MIT で、README は商用利用、改変、配布を可とし、無保証であると明記している。一方、ベースモデルには OpenGVLab の InternVL3-38B が使われており、これも README によれば MIT ライセンスである。コードの MIT と重みの利用条件は同じ文書の中で一緒に語られているが、実際に配布物として手元に来るのは後者である。導入検討では、どちらの条件を確認しているのかを意識して分けたほうがよい。
推論は Transformers 経路と vLLM 経路に分かれる
環境構築は conda で二つの仮想環境を作る形になっている。Transformers 用は python=3.10 の環境 r1-v を作り、inference ディレクトリで setup.sh を実行する。vLLM と評価用は別環境 r1v-vllm を作り、eval/vlmevalkit/build_env.sh を実行する。同じモデルを動かすのに環境が二つに分かれているのは、評価フレームワーク側の依存が重く、推論だけの環境と同居させたくないという判断だろう。
Transformers 経路の実行例はこうなっている。CUDA_VISIBLE_DEVICES="0,1" を指定して inference_with_transformers.py を呼び、--model_path、--image_paths、--question を渡す。vLLM 経路は inference_with_vllm.py に対して --tensor_parallel_size 4 を渡す形で、複数画像を空白区切りで並べられる。38B を 4 枚の GPU に分割する前提の数値なので、単卡で試したい場合は AWQ 量子化版の Skywork-R1V2-38B-AWQ が別途案内されている。README は 30GB 超の単一カードで動くと書いている。
評価を再現する場合は eval ディレクトリのコードを使うと明記されている。ここで注意したいのは、公開されているベンチマーク表の多くがこの評価フレームワーク経由の数値だという点で、表の脚注には [*] 付きの結果が自前評価によるものだと書かれている。
評価表はスコアの高さより、どの列で負けているかを見る
README の比較表は、Skywork-38B を QVQ-72B、InternVL-78B、Qwen-72B、Claude 3.7、GPT-4o と並べている。MMMU の 76.0、MMMU-pro の 55.4、MathVista の 77.1 などで先頭に立つ一方、EMMA (mini-cot) は 40.3 で Claude 3.7 の 56.5 に大きく差をつけられている。MMBench-en-1.1 でも 85.7 に対して Qwen-72B が 88.0、InternVL-78B が 87.7 で上にいる。SeePhys は 31.5 で Claude 3.7 の 34.6 に届かない。
つまり全項目で最強という構成ではない。表の見出しは state-of-the-art と書いているが、実際には数学系と論理系の一部で強く、一般的な画像理解や英語中心のベンチマークでは同規模の他モデルと互角か劣る。自前の用途が MMBench 寄りなのか MathVerse 寄りなのかで結論が変わる。
もう一つ、この表はすべて英語圏のベンチマークで構成されている。日本語の画像内テキストや日本語の図表を扱う性能は、この表からは何も読み取れない。
R1V2 と R1V3 の間にある実務的な差
リポジトリのニュース欄を時系列で追うと、2025 年 3 月 18 日の R1V、4 月 24 日の R1V2、7 月 9 日の R1V3-38B という流れになる。4 月 28 日には R1V2-38B-AWQ が公開され、単一カードでの推論が可能になったと書かれている。3 月 26 日にも R1V-38B-AWQ が出ている。
ここから読み取れるのは、量子化版が必ずしも最新版に追従していないという点だ。AWQ の案内があるのは R1V と R1V2 で、R1V3 については README の範囲では量子化版の記載が見当たらない。VRAM が限られる環境で R1V3 を使いたい場合、現時点で案内されている道は vLLM の tensor parallel で複数カードに分ける経路になる。単卡で試したいなら R1V2 の AWQ に落とす判断もあり得るが、その場合は MMMU 76.0 の世代ではなくなる。
技術レポートも版ごとに分かれている。R1V は arXiv 2504.05599、R1V2 は 2504.16656、R1V3 は 2507.06167 で、引用情報もそれぞれ別に用意されている。
このリポジトリが向かない場面
第一に、推論コードだけを clone して動かそうとする使い方は成立しない。重みは別配布で、しかも 38B クラスである。GPU のメモリ要件は README に明示されておらず、vLLM の例にある tensor_parallel_size 4 から逆算するしかない。何枚必要かは自分で確かめる項目になる。
第二に、このリポジトリはモデルの学習やファインチューニングの手順を提供していない。README にあるのは推論スクリプトと評価環境であって、GRPO や強化学習によるポストトレーニングの再現手順は記載されていない。トピックには grpo や reinforcement-learning が並んでいるが、それは手法の説明であって、手元で回せるコードがあるという意味ではない。自前データで追加学習したい用途には応えられない。
第三に、評価は vlmevalkit という外部フレームワークに依存している。評価環境の構築は build_env.sh に閉じているが、ベンチマークの実装そのものはこのリポジトリの管理下にはない。評価指標の定義を自分で変えたい場合、変更すべきファイルはこのリポジトリの外にある。
比較対象としての Qwen2.5-VL 系との違い
同じ表に並ぶ Qwen-72B や InternVL-78B は、いずれも汎用の視覚言語モデルとして公開されている。違いは学習の重心にある。Skywork-R1V3 は README によれば「Mainly through RL algorithm in post-training」でマルチモーダル推論能力を引き上げたと説明されており、ベースは InternVL3-38B である。汎用モデルが事前学習の段階で広い画像理解を身につけるのに対し、こちらはポストトレーニングで推論の連鎖を伸ばす方向に振っている。
この差はベンチマークの形にも表れている。MMBench-en-1.1 のような一般的な認識寄りの指標では Qwen-72B に譲り、MathVerse や WeMath のような多段推論を要する指標で前に出る。汎用の画像分類やキャプション生成が主目的なら、わざわざ 38B の推論特化モデルを選ぶ理由は薄い。逆に、図表を読ませて計算過程まで出させたいなら、この振り方は噛み合う。
なお、パラメータ数が 38B と 72B で異なる点は比較の前提として押さえておきたい。同じ土俵の勝負ではない。
導入前に確認すべき三つのこと
一つ目は、手元のタスクで公開スコアが再現するかどうか。eval ディレクトリのコードと vlmevalkit 環境を使えば、同じ指標を自分で回せる。README の表には [*] 付きの数値が混在しており、自前評価の結果であることが明記されている。再現しなければ、その数値は自分の意思決定の根拠にならない。
二つ目は、日本語の画像を扱ったときの挙動。公開ベンチマークは英語のみで、日本語の図表や日本語の文字を含む画像に対する結果は提供されていない。ここは自分のデータで確かめる以外に方法がない。
三つ目は、ライセンスの確認範囲。コードは MIT で、README は商用利用と改変、配布を認め、無保証としている。ベースモデルの InternVL3-38B も MIT と記載されている。ただし重みの配布元での条件と、コードリポジトリの条件は別の文書である。社内の法務確認に回すなら、参照すべきは GitHub の LICENSE だけでなく Hugging Face 側のモデルカードになる。
保守コストの面では、このリポジトリは推論スクリプトと評価環境という構成で、頻繁な更新を前提とした作りには見えない。バージョン間の差はモデルの重み側で吸収されるため、コードを追い続ける負担は小さい。ただし量子化版の有無のように、バージョンごとに使える経路が変わる点は追跡が必要になる。
編集部の結論
視覚と言語をまたぐ推論タスクを自前の GPU 上で動かしたい研究・検証チームに向く。逆に、閉域での長期運用や日本語の画像内テキスト処理を主目的にする場合、このリポジトリだけでは判断材料が足りない。まず eval ディレクトリの vlmevalkit 環境を構築し、手元のタスクで MMMU 系の数値が再現するかを確認する。再現しなければ、公開表のスコアは自分の用途の根拠にならない。
コミュニティノート