Qwen3-VLは、Alibaba Cloud(Qwenチーム)が2025年9月から10月にかけて公開した視覚言語モデル(VLM)のシリーズです。画像・動画・テキストを一緒に入力でき、重みはすべてApache 2.0で公開されています。サイズは2Bから235Bまで6種類あり、それぞれに即答型のInstructと推論過程を出すThinkingがあります。
この記事では、Hugging Faceの登録情報、公式GitHubのREADME、Ollamaのタグ一覧、Alibaba Cloudの料金表を2026年10月13日時点で確認し、モデルの選び方と動かし方を整理しました。2Bは実際にCPUだけのPCで動かし、手順と所要時間を記録しています。
まとめ:Qwen3-VLのモデル選びと動かし方の要点
- 構成:Denseの2B・4B・8B・32Bと、MoEの30B-A3B・235B-A22Bの6サイズ。末尾の「A3B」「A22B」は1トークンあたりに使う活性パラメータ数(約3B・約22B)で、エキスパートの数ではありません。
- ライセンス:全モデルApache 2.0。商用利用・改変・再配布に追加の許諾は要りません。
- 選び方:手元のCPUや小型GPUで書類の読み取りを試すなら2B、単一GPUで精度を取りに行くなら32B(4bit量子化で約21GB)、計算量を抑えたいなら30B-A3Bが目安です。
- 落とし穴:Ollamaの
qwen3-vl:8bなど無印タグの中身はThinking版です。即答型が欲しいときは-instruct付きのタグを指定します。transformersは4.57.0が取り下げ済みなので、4.57.1以上を入れます。 - 後継:2026年2月以降のQwen3.5・Qwen3.6・Qwen3.8は、画像入力を最初から統合した単一モデルになり、「VL」付きの別系列は出ていません。新規に選ぶなら、2026年8月公開のQwen3.8-27Bや、Qwen3.5の2B・4Bも比較対象に入れてください。
以下、モデル一覧、サイズ別の使いどころ、実行手順、API料金、後継世代との関係の順に解説します。
Qwen3-VLのモデル一覧:公開日・パラメータ数・Ollamaでの容量
全6サイズの基本情報です。総パラメータ数はHugging Faceのsafetensorsの合計値、公開日は公式GitHubリポジトリのNews欄の告知日です。Ollama容量は、4bit量子化(q4_K_M)のタグのファイルサイズです。
| モデル | 方式 | 総パラメータ | 公開日 | Ollama q4_K_M | Ollama BF16 |
|---|---|---|---|---|---|
| Qwen3-VL-2B | Dense | 2.13B | 2025-10-21 | 1.9GB | 4.3GB |
| Qwen3-VL-4B | Dense | 4.44B | 2025-10-15 | 3.3GB | 8.9GB |
| Qwen3-VL-8B | Dense | 8.77B | 2025-10-15 | 6.1GB | 18GB |
| Qwen3-VL-32B | Dense | 33.36B | 2025-10-21 | 21GB | 67GB |
| Qwen3-VL-30B-A3B | MoE(活性約3B) | 31.07B | 2025-10-04 | 20GB | 62GB |
| Qwen3-VL-235B-A22B | MoE(活性約22B) | 235.67B | 2025-09-23 | 143GB | 471GB |
各サイズにInstructとThinkingがあり、その全部にFP8版がそろっています。Hugging Faceの公式コレクションには、通常版とFP8版でこの24リポジトリが並び、ほかにGGUF版なども掲載されています。llama.cpp向けの公式GGUFは、2025年10月31日に別リポジトリ(Qwen/Qwen3-VL-8B-Instruct-GGUF など)として追加されました。技術的な詳細は2025年11月に公開された技術レポート(arXiv:2511.21631)にまとまっています。
表の容量はファイルサイズで、必要メモリはこれより大きくなります。画像のトークンとKVキャッシュの分が、入力の長さや同時に処理する件数に応じて上乗せされるためです。機材は、実際に扱う画像と入力長で測ってから決めてください。量子化の形式による違いはGGUFとは?量子化モデルフォーマットの仕組みとGPTQ・AWQとの違いで解説しています。
DenseとMoEの違い:30B-A3Bと235B-A22Bの「A」の意味
Denseモデルの言語モデル部分は、MoEのようにエキスパートを選別せず、各層の密なフィードフォワードネットワークで計算します。MoE(Mixture of Experts)モデルは、多数の専門家(エキスパート)のうち一部だけを選んで計算します。30B-A3Bなら総31Bのうち約3B分しか動かないため、1トークンあたりの計算量は3B級のモデルに近くなります。実際の速度はメモリ帯域や実行エンジンで変わるので、比べるときは手元で測ります。
ただし、どのエキスパートが選ばれるかはトークンごとに変わるので、オフロードを使わない構成では全エキスパートの重みをメモリに保持します。CPUやディスクへのオフロードも可能ですが、転送による待ち時間が増えます。30B-A3Bは「計算は軽いが、メモリは30B級に要る」モデルです。4bit版のファイル容量は30B-A3Bが20GB、32Bが21GBとほぼ同じなので、メモリ量では選び分けられません。計算量を抑える候補は30B-A3Bです。精度を優先する場合は32Bも比較し、同じ画像・生成設定で項目抽出の正答率と処理時間を測って選びます。仕組みはMoE(Mixture of Experts)とは?、30B-A3B固有の動かし方はQwen3-VL-30B-A3Bとは|InstructとThinkingの違い・必要VRAM・Ollama/vLLMでの動かし方で詳しく扱っています。
InstructとThinkingの違い:推奨サンプリング値
Instructは質問にそのまま答えます。Thinkingは回答の前に推論過程を出力し、数学・図表の読解・多段の判断で精度を上げる代わりに、出力トークンと待ち時間が増えます。公式READMEに書かれた評価時の生成設定は次のとおりで、両者は温度と繰り返し抑制の設定が大きく違います。
| 設定 | Instruct | Thinking |
|---|---|---|
| temperature | 0.7 | 0.6 |
| top_p | 0.8 | 0.95 |
| top_k | 20 | 20 |
| presence_penalty | 1.5 | 0.0 |
| 最大出力長 | 32,768 | 40,960 |
OCRで帳票の項目を取り出す、画像の説明文を作る、といった答えが一つに決まる処理はInstructで足ります。グラフから傾向を読み取る、複数の画像を見比べて結論を出す、といった推論を挟む処理でThinkingを試す、という順番が無駄がありません。
Qwen3-VLでできること:OCR・長い動画・GUI操作の公式仕様
公式READMEは前世代のQwen2.5-VLからの強化点を8項目挙げています。業務での使い道に直結するのは次の5つです。
- OCR:対応言語を10から32へ拡大。暗い・ぼやけた・傾いた画像や、珍しい文字・古い字体、長い文書の構造の読み取りを強化。
- 長いコンテキスト:ネイティブで256Kトークン。YaRNで100万トークンまで拡張でき、書籍や数時間の動画を扱えるとしています。
- 動画の時刻特定:動画内の出来事を秒単位のタイムスタンプで特定。
- 視覚エージェント:PCやスマートフォンの画面を認識してボタンなどを操作するGUI操作。
- 視覚からのコード生成:画像や動画からDraw.io・HTML・CSS・JavaScriptを生成。
OCRと帳票処理は、2Bから試せる用途です。次の章のとおり、検証用に作成した請求書風画像1枚からは2Bでも3項目を抽出できました。ただし、実帳票のレイアウト差や画質低下に対する精度は検証していません。GUI操作や長い動画は、1回の入力に含む画像トークンが多く、推論の段数も増えます。小さいモデルで結論を出さず、8B以上で検証するのが現実的です。
3つのアーキテクチャ変更:Interleaved-MRoPE・DeepStack・Text-Timestamp Alignment
構造面の変更は3点です。Interleaved-MRoPEは、位置埋め込みの周波数を時間・幅・高さの3軸に交互に割り当て、長い動画での位置関係を崩れにくくします。DeepStackは、画像エンコーダ(ViT)の最終層だけでなく複数の層の特徴を言語モデル側へ渡し、細部の読み取りと画像・テキストの対応付けを強めます。Text-Timestamp Alignmentは、前世代のT-RoPEに代えて、テキストのタイムスタンプと映像フレームを直接対応付ける方式です。
利用者側の設定に直接効くのは位置埋め込みで、100万トークンへの拡張はこのRoPEの設定を書き換えて行います。RoPEそのものの仕組みはRoPEとは:回転位置埋め込みの仕組みとコンテキスト長拡張を参照してください。
Qwen3-VL-2Bの使いどころ:CPUだけで請求書を読ませた記録
2Bは総2.13Bで、BF16でも4.3GB、4bit量子化なら1.9GBに収まります。GPUのないノートPCやエッジ機器で、書類の項目抽出や画像の簡単な説明をさせる用途が想定されます。
2026年10月13日に、Intel Mac(Core i9-9880H・メモリ16GB・GPU不使用)で Qwen/Qwen3-VL-2B-Instruct をtransformers 4.57.1で動かしました。検証用に作成した架空の請求書画像(640×320ピクセル。見出しと請求番号・発行日・品名・合計金額の5行)をPillowで描いて渡し、「この画像の請求番号・発行日・合計金額をJSONで返してください。」と指示した結果が次です(ログからの抜粋。モデルは回答をMarkdownのjsonコードブロックの記法で囲んで返しており、下では囲みの行を外しています)。
python 3.11.15 torch 2.2.2 transformers 4.57.1
load_sec 30.1
input_tokens 232 output_tokens 66 gen_sec 166.1 tok_per_sec 0.4
OUTPUT>>>
{
"請求番号": "INV-2026-1013",
"発行日": "2026年10月13日",
"合計金額": "12,345円(税込)"
}
3項目とも画像の文字と一致しました。一方で速度は0.4トークン/秒で、66トークンの回答に約2分46秒かかっています。これはCPUでFP32のまま動かした数字で、GPUやApple Silicon、量子化版での速度は今回測っていません。「CPUでも読めるが、この条件では件数をさばく用途に向かない」というのがこの環境での結論です。
入力の232トークンのうち大半は画像です。Qwen3-VLは32×32ピクセルごとに1トークンへ圧縮するため、640×320の画像は計算上200トークンになります。高解像度のスキャン画像をそのまま渡すとトークンが一気に増えるので、後述の max_pixels で上限を決めておきます。
この環境ならではの問題も1つありました。Intel Mac向けに公式配布されたPyTorchのビルド済みパッケージは、2.2.2が最後です。transformers 4.57.1の高速版の画像前処理は、2.2.2に無い torch.compiler.is_compiling を呼ぶため AttributeError で止まりました。AutoProcessor.from_pretrained(..., use_fast=False) として低速版の前処理を使うと動きます。transformers 4.57.1のPyTorch要件は「2.2以上」なので、インストールは通るのに実行時に落ちる組み合わせです。
Qwen3-VL-32Bの使いどころ:Dense最大モデルの必要メモリ
32BはDenseモデルの最上位で、総33.36Bです。重みのファイル容量は、Hugging Faceの実ファイルでBF16が66.7GB、FP8版が35.5GB、Ollamaの4bit量子化(q4_K_M)が21GB、8bit(q8_0)が36GBです。
ファイル容量の上では、24GBのGPUに4bit版(21GB)が収まります。ただし画像トークンとKVキャッシュが加わるため、長い文脈や高解像度画像を扱う余裕はほとんどありません(この構成での動作は今回検証していません)。容量から見た目安は、8bit版(36GB)やFP8版(35.5GB)なら48GB級のGPU(RTX 6000 Ada、L40Sなど)、長い文脈や同時処理のためにキャッシュの余裕を大きく取りたいなら80GB級です。80GBは最低必要容量ではありません。FP8はA100(Ampere)とH100(Hopper)でvLLMの対応方式が異なるため、使うGPUでvLLMの量子化対応表を確認してください。
同じ容量帯の30B-A3Bと比べると、32Bは言語モデル部分でエキスパートの選別を行わないため、トークンあたりの計算量が大きくなります。速度より精度を優先する書類の読み取りやGUI操作の検証は32B、応答の速さを重視する対話用途は30B-A3Bから試す、という順番が判断の軸です。
OllamaでQwen3-VLを動かす:タグの中身はThinking版に注意
Ollamaでは0.12.7以上でQwen3-VLが使えます。インストール済みなら次の1行で起動し、画像ファイルのパスをプロンプトに含めると画像を読ませられます。
ollama run qwen3-vl:8b-instruct
>>> この画像の文字をすべて書き出してください ./invoice.png
注意したいのはタグの選び方です。Ollamaのタグ一覧でファイルのダイジェストを照合すると、qwen3-vl:2b・:4b・:8b・:30b・:32b・:235b と latest は、すべてThinking版の4bit量子化と同じファイルでした(latest の中身は 8b-thinking)。ollama run qwen3-vl だけで始めると、即答型のつもりで推論過程付きの長い出力を受け取ることになります。
| 指定したタグ | 実際の中身 |
|---|---|
| qwen3-vl / qwen3-vl:latest | 8b-thinking-q4_K_M |
| qwen3-vl:2b | 2b-thinking-q4_K_M |
| qwen3-vl:32b | 32b-thinking-q4_K_M |
| qwen3-vl:30b | 30b-a3b-thinking-q4_K_M |
| qwen3-vl:2b-instruct | 2b-instruct-q4_K_M |
Instructを使うときは qwen3-vl:2b-instruct や qwen3-vl:32b-instruct のように明示し、精度を上げたいときは -q8_0 や -bf16 の付いたタグを選びます。
transformersでQwen3-VLを動かす:版条件と画像トークンの上限
公式READMEの指定は「transformers 4.57.0以上」ですが、PyPIでは4.57.0が取り下げ(yanked)られています。理由はセットアップの不具合です。4.57.1以上を入れます。現行の5系はPyTorch 2.5以上を要件にしているので、GPU環境ではPyTorchとそろえて新しい版を入れ、PyTorch 2.2.2が上限のIntel Macでは4.57.1に固定します。上の2Bの記録で使った組み合わせは次のとおりです。
pip install "torch==2.2.2" "torchvision==0.17.2" "transformers==4.57.1" "numpy<2" pillow accelerate
最小の推論コードは次のとおりです。上の2Bの記録は、このコードを dtype=torch.float32・device_map="cpu"・max_new_tokens=128・do_sample=False に変えて実行したものです。他のサイズはモデル名の差し替えで読み込めますが、必要メモリはサイズに応じて増えます。
import torch
from transformers import AutoModelForImageTextToText, AutoProcessor
model_id = "Qwen/Qwen3-VL-2B-Instruct"
model = AutoModelForImageTextToText.from_pretrained(model_id, dtype="auto", device_map="auto")
# 高速版の画像前処理はPyTorch 2.2系で失敗するため、低速版(use_fast=False)を指定
processor = AutoProcessor.from_pretrained(model_id, use_fast=False)
messages = [{
"role": "user",
"content": [
{"type": "image", "image": "invoice.png"},
{"type": "text", "text": "この画像の請求番号・発行日・合計金額をJSONで返してください。"},
],
}]
inputs = processor.apply_chat_template(
messages, tokenize=True, add_generation_prompt=True,
return_dict=True, return_tensors="pt",
).to(model.device)
out = model.generate(**inputs, max_new_tokens=256)
print(processor.batch_decode(out[:, inputs["input_ids"].shape[1]:], skip_special_tokens=True)[0])
GPUで複数画像や動画を扱うなら、attn_implementation="flash_attention_2" を指定するとメモリと速度の両方で有利だとREADMEは勧めています。
qwen-vl-utilsの役割と画像トークン数の調整
READMEの設定例では、画像1枚あたりのトークン数を256〜1,280の範囲に収めています。高解像度のスキャン画像で細かい文字を読ませたいときは上限を上げ、メモリが足りないときは下げます。
画像ごとに解像度を変えたい場合や動画を扱う場合は、公式ヘルパーの qwen-vl-utils(READMEの指定は0.0.14)を使います。メッセージ内の画像に min_pixels・max_pixels を書いておくと、ヘルパーが縦横比を保ったまま解像度を調整します。既定値はQwen2.5-VL向けなので、Qwen3-VLでは process_vision_info(messages, image_patch_size=16, return_video_kwargs=True, return_video_metadata=True) と呼ぶのがREADMEの指定です。このときプロセッサ側でもリサイズすると二重になるため、do_resize=False を渡します。動画は既定で毎秒2フレームを抜き出します。フレーム数はヘルパー側では動画要素の fps・nframes、プロセッサだけで処理する場合は fps・num_frames で指定します。
vLLMでのQwen3-VL APIサーバー構築
複数人で使う、他のシステムから呼び出す、という用途では、vLLMでOpenAI互換のAPIサーバーを立てます。READMEの要件は vllm>=0.11.0 です。
vllm serve Qwen/Qwen3-VL-8B-Instruct --max-model-len 32768
呼び出し側は、OpenAIのSDK(pip install openai)で image_url に画像を渡します。例の https://example.com/invoice.png は自分の画像URLに置き換えてください。手元のファイルを送る場合は、Base64の文字列をそのまま入れず、data:image/png;base64, で始まるdata URLにします。
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
res = client.chat.completions.create(
model="Qwen/Qwen3-VL-8B-Instruct",
messages=[{"role": "user", "content": [
{"type": "image_url", "image_url": {"url": "https://example.com/invoice.png"}},
{"type": "text", "text": "この画像の文字を書き出してください。"},
]}],
)
print(res.choices[0].message.content)
256Kを超えて100万トークンへ広げる手順は、READMEでは --rope-scaling 引数で示されています。ただしこの引数はvLLM 0.26で削除されたため、現行版では --hf-overrides で text_config 側のRoPE設定を上書きします。vLLM自体の仕組みはvLLMとは?PagedAttentionの仕組み・使い方で解説しています。
APIでQwen3-VLを使う:Model Studioのqwen3-vl-plus料金
GPUを用意せずに試すなら、Alibaba CloudのModel Studioで提供されている qwen3-vl-plus が手早い選択肢です。公式の料金表によるInternational(シンガポール)の単価は、1回のリクエストの入力長で3段階に分かれます。
| 入力長(1リクエスト) | 入力(100万トークン) | 出力(100万トークン) |
|---|---|---|
| 0〜32K | $0.2 | $1.6 |
| 32K超〜128K | $0.3 | $2.4 |
| 128K超〜256K | $0.6 | $4.8 |
Thinkingモードと非Thinkingモードは同じ単価で、思考過程のトークンも出力として課金されます。International向けには100万トークンの無料枠(有効期限90日)があります。料金は改定されることがあるため、契約前に料金表で確認してください。
APIは個人情報を含む書類を外部へ送ることになります。社外に出せない帳票を扱うなら、前章までのローカル実行を選ぶのが前提です。帳票のOCRを業務に組み込む設計は、当社のAI-OCR導入支援でも扱っています。
後継のQwen3.5・3.6・3.8との関係と画像対応モデルの選定
Qwen3-VLのあと、「VL」を名乗る別系列は出ていません。2026年2月16日に公開されたQwen3.5から、視覚と言語を最初から一緒に学習した単一のモデルに統合されました。QwenのGitHubリポジトリは、この統合型の基盤が推論・コーディング・エージェント・視覚理解のベンチマークでQwen3-VLを上回ると説明しています。
その後もQwen3.6(2026年4月)、Qwen3.8(2026年8月)と世代が進みました。Qwen3.8-27Bのモデルカードは、Qwen3.8をQwenのオープンモデル系列で最も高性能な世代と位置づけ、27Bを画像と動画を理解するネイティブの視覚言語モデルだと説明しています(Apache 2.0)。小さいサイズも、2026年3月2日にQwen3.5の0.8B・2B・4B・9Bが公開されました。画像を扱えるQwenを新しく選ぶなら、Qwen3.8-27BやQwen3.5の小型モデルが比較の中心です。MoEならQwen3.6-35B-A3BがQwen3-VL-30B-A3Bと同じ活性約3Bの位置にあり、最大規模のQwen3.5-397B-A17Bも画像入力に対応します。
Qwen3-VLを使い続ける判断が成り立つのは、既存の推論環境やファインチューニング済みモデルがQwen3-VL前提で組まれていて、移行の検証コストに見合う差が出ていない場合です。2026年1月には、Qwen3-VL-2B・8Bを土台にした画像・動画の検索用モデル(Qwen3-VL-Embedding、Qwen3-VL-Reranker)も追加されており、検索の仕組みにこれらを使っている場合も同様です。乗り換えるかどうかは、自社の画像と評価データで後継世代と比べてから決めます。
Qwen3-VLを選ばないほうがよい場面
次の条件に当てはまるなら、Qwen3-VL以外を先に検討してください。
- 新規構築で、既存のQwen3-VL資産が無い:同じサイズ帯に後継世代(Qwen3.5の2B・4B、Qwen3.8-27B、Qwen3.6-35B-A3Bなど)があるので、先にそちらと比較すべきです。
- 日本語の帳票OCRだけが目的:汎用VLMは項目の取り違えや、存在しない値を補う誤りがゼロになりません。OCR専用モデル(GLM-OCRなど)や既存のOCRエンジンと精度・速度を比べてから決めます。
- CPUだけで大量の画像を処理したい:上の記録(Intel CPU・FP32・出力66トークン)では、2Bでも1件に約2分46秒かかりました。この条件のまま件数をさばくのは現実的でなく、GPU・量子化版・APIのいずれかが前提です。
逆に、外部へ出せない画像を社内で扱っていて、既存の環境やファインチューニング済みモデルがQwen3-VL前提で動いている、という条件なら、無理に乗り換える必要はありません。
Qwen3-VLに関するよくある質問
Qwen3-VLは商用利用できますか?
できます。2B〜235Bの全モデルがApache 2.0で公開されており、商用利用・改変・再配布に追加の許諾は要りません。再配布時はライセンス文の同梱など、Apache 2.0の条件に従います。
Qwen3-VLの2Bと32Bはどちらを選べばよいですか?
GPUが無い、または8GB以下のGPUなら2B(4bit版1.9GB)、24GB以上のGPUがあり精度を優先するなら32B(4bit版21GB)が目安です。2BはCPUでも動きますが、Intel MacのCPUでは0.4トークン/秒でした。
OllamaでInstruct版を使うにはどうしますか?
qwen3-vl:8b-instruct のように -instruct を付けたタグを指定します。qwen3-vl:8b などの無印タグと latest の中身はThinking版です。
qwen-vl-utilsは必須ですか?
必須ではありません。画像1枚を渡すだけならtransformersのプロセッサだけで動きます。画像ごとに解像度を変える、動画のフレーム数を制御する、といった場合にqwen-vl-utilsを使い、その際はプロセッサに do_resize=False を渡します。
最新のQwen VLモデルはどれですか?
「VL」の付く最新シリーズはQwen3-VLですが、2026年2月以降のQwen3.5・Qwen3.6・Qwen3.8は画像入力を統合した単一モデルになっています。画像を扱えるオープンウェイトの最新世代はQwen3.8で、2026年8月公開のQwen3.8-27Bは画像と動画に対応しています。