Qwen3-VL-30B-A3Bは、AlibabaのQwenチームが2025年10月に公開した視覚言語モデル(VLM)です(Hugging Faceへの登録は9月30日、公式GitHubでの告知は10月4日)。画像・動画・テキストを入力でき、MoE(Mixture of Experts)構成のため言語モデル部では1トークンあたり約30億のパラメータが活性化します(名称の「A3B」)。ライセンスはApache-2.0で商用利用できます。
このモデルを調べる人が迷うのは、主に3点です。InstructとThinkingのどちらを使うか、手元のGPUに載るか、そして2026年に出た後継(Qwen3.5・3.6の35B-A3B、Qwen3.8-27B)ではなくこれを選ぶ理由があるか。この記事では、モデルカード・公式GitHub・技術報告・Hugging FaceのAPIから取った数値でこの3点に答えます。なお、Alibaba Cloud Model StudioのAPI版は2026年10月10日に提供を終えており、APIで使う場合の提供先も変わっています。数値は2026年10月17日時点で確認したものです。
まとめ:Qwen3-VL-30B-A3Bの要点
- 仕様:テキスト部は48層・128エキスパート中8個を使うMoE。ネイティブのコンテキスト長は262,144トークンで、YaRNを使えば約100万トークンまで広げられます。
- InstructとThinking:文字認識のOCRBench(903対839)とGUI要素を特定するScreenSpot Pro(60.5対57.3)はInstructのほうが高スコアです。数式を含む図の読解や複数画像の比較はThinkingが上回ります(MathVision 60.2対65.7、MUIRBENCH 62.9対77.6)。
- 重みの容量:重みファイルだけでBF16が62.14GB、FP8が32.25GB、GGUFのQ4_K_Mが18.56GB(別途mmprojが0.71〜1.08GB)あります。Ollamaの4bit版は20GBです。
- Ollamaの注意点:
qwen3-vl:30bタグの中身はThinking版です。Instructを使いたい場合はqwen3-vl:30b-a3b-instructを指定します。 - APIの提供:Alibaba Cloud Model StudioのAPI版は2026年10月10日に廃止され、代替はqwen3.7-plusです。APIで使い続けるならOpenRouter経由で、Instructは入力$0.15・出力$0.60です(100万トークンあたり)。
- 後継との関係:これから新規に採用するなら、同じ「3B活性」クラスのQwen3.6-35B-A3Bを先に評価するのが順当です。2026年8月のQwen3.8世代には35B-A3B相当が無く、密モデルのQwen3.8-27Bが画像も扱います。30B-A3Bを選ぶ理由は、ファインチューニング済みの資産があることや、検証済みの推論環境を変えずに済むことです。
Qwen3-VL-30B-A3Bの仕様と構成
Hugging FaceのAPIで重みを数えると、BF16で31,070,754,032パラメータ(約311億)あります。この数には視覚エンコーダが含まれるため、名前の「30B」とは少しずれます。config.jsonの値を表にまとめます。
| 項目 | 値 |
|---|---|
| 公開日 | 2025-10-04告知(HF登録は09-30) |
| ライセンス | Apache-2.0 |
| 重みの総パラメータ数 | 31,070,754,032(BF16) |
| テキスト部の層数 | 48層 |
| エキスパート数 | 128個(1トークンあたり8個を使用) |
| アテンションヘッド | Q 32 / KV 4 |
| コンテキスト長 | 262,144トークン(YaRNで約100万) |
| 視覚エンコーダ | 27層・パッチサイズ16 |
| 語彙数 | 151,936 |
| OCR対応言語 | 32言語(前世代は19言語) |
MoEは、推論のたびに全パラメータを動かすのではなく、ルーターが選んだ一部のエキスパートだけを計算する方式です。これによりエキスパート部分の計算を減らせますが、視覚エンコーダやアテンションの処理もあるため、モデル全体の計算量が3Bの密モデルと同じになるわけではありません。また、メモリには全エキスパートを載せる必要があります。「3Bだから小さいGPUで動く」とはなりません。仕組みはMoE(Mixture of Experts)とは?疎活性化とルーターの仕組み・VRAM要件と採用判断を実装者向けに解説で詳しく説明しています。
前世代Qwen2.5-VLから変わった3つの設計
モデルカードは、アーキテクチャの変更点として次の3つを挙げています。
- Interleaved-MRoPE:時間・幅・高さの3軸に位置情報の周波数を交互に割り当てる方式です。長い動画での推論を狙った変更で、
config.jsonではmrope_section: [24, 20, 20]として現れます。 - DeepStack:視覚エンコーダ(ViT)の複数の層から特徴を取り出し、言語モデルへ渡します。このモデルでは
deepstack_visual_indexesが[8, 16, 24]で、0から数えるインデックスなので9・17・25層目の出力が使われます。 - Text-Timestamp Alignment:動画のフレームにタイムスタンプを文字として添え、「何秒目に何が起きたか」を答えやすくします。
学習データと評価の詳細は、2025年11月26日に公開された技術報告「Qwen3-VL Technical Report」(arXiv:2511.21631)にまとまっています。モデルカードにはベンチマークが画像でしか載っていないため、数値を引用するときは技術報告の表のほうが扱いやすいです。
位置埋め込みの拡張手法そのものはRoPEとは:回転位置埋め込みの仕組みとコンテキスト長拡張・実装判断を実装者向けに解説を参照してください。Qwen3-VLシリーズ全体(2B〜235B)のモデル一覧はQwen3-VLとは|2B〜235Bのモデル一覧・必要メモリ・Ollama/transformersでの動かし方にまとめています。
InstructとThinkingの違い
Instructは質問にすぐ答えるモデルで、Thinkingは回答の前に推論の過程を出力するモデルです。重みは別々のリポジトリで配布されており、実行時のフラグで切り替えられるわけではありません。どちらを使うかは、読み込む時点で決めます。
ダウンロードが多いのはInstructです。Hugging Faceの公式リポジトリの累計ダウンロード数は、Instructが18,139,752回、Thinkingが1,054,571回で、約17倍の差があります(2026年10月17日にHugging FaceのAPIで取得)。この数はファイルへのリクエストを数えた値で、利用者数そのものではありませんが、使われ方の偏りを見る目安にはなります。
InstructとThinkingのベンチマーク比較
公式のベンチマーク表から、差が大きい項目を抜き出しました。Thinkingのほうが全項目で上というわけではありません。
| ベンチマーク | 測るもの | Instruct | Thinking |
|---|---|---|---|
| OCRBench | 文字認識 | 903 | 839 |
| ScreenSpot Pro | GUI要素の特定 | 60.5 | 57.3 |
| VideoMME | 動画理解 | 74.5 | 73.3 |
| IFEval | 指示追従(テキスト) | 85.8 | 81.7 |
| MMMU | 大学レベルの図表問題 | 74.2 | 76.0 |
| MathVision | 図を含む数学 | 60.2 | 65.7 |
| MathVerse mini | 図を含む数学 | 70.2 | 79.6 |
| MUIRBENCH | 複数画像の比較 | 62.9 | 77.6 |
| AIME25 | 数学(テキスト) | 69.3 | 83.1 |
出典は公式GitHub(QwenLM/Qwen3-VL)とInstruct・Thinkingのモデルカードに画像で掲載された表です。動画の評価は256Kトークンのコンテキストで、最大2,048フレームを入力して測定されています。
OCR・図表推論におけるInstructとThinkingの選択
画像内の文字をそのまま書き起こす処理や、スクリーンショットからボタンの位置を特定する処理にはInstructを使います。この2つはスコアが高いうえに、推論過程を出力しない分だけ応答が短く、処理件数が多い業務で待ち時間とトークン数を抑えられます。ただし文書系でも一様ではありません。技術報告の表では、DocVQAはInstruct 95.0・Thinking 95.5とほぼ同じで、図表入りの資料に答えるInfoVQAはThinkingが上回ります(81.8対85.6)。文書の中身を読んで推論させる質問なら、Thinkingも比較対象に入れてください。
グラフや図形を読んで計算する問題、複数枚の画像を見比べて違いを答える処理にはThinkingを使います。複数画像を比較する用途では、MUIRBENCHの14.7ポイント差がThinkingを評価候補にする根拠になります。
公式の推奨生成パラメータ
公式GitHubのREADMEは、2つのモデルに異なるサンプリング設定を推奨しています。Thinkingは出力が長くなるため、最大出力長も大きく取られています。
| パラメータ | Instruct | Thinking |
|---|---|---|
| temperature | 0.7 | 0.6 |
| top_p | 0.8 | 0.95 |
| top_k | 20 | 20 |
| presence_penalty | 1.5 | 0.0 |
| repetition_penalty | 1.0 | 1.0 |
| 最大出力長 | 32,768 | 40,960 |
Instructのpresence_penalty=1.5は、一般的なLLMの既定値(0)より大きい値です。OpenAI互換APIで呼ぶときに指定し忘れると、同じ語句を繰り返す出力が出やすくなります。
テキスト版Qwen3-30B-A3B・Coder・Omniとの違い
「30B-A3B」という名前のモデルはQwen3世代に複数あり、検索でも混同されがちです。同じ48層・128エキスパート構成のテキスト部を持ちますが、入出力と学習の目的が異なります。
| モデル | 入力 | 出力 | 主な用途 |
|---|---|---|---|
| Qwen3-VL-30B-A3B | テキスト・画像・動画 | テキスト | 画像理解・OCR・GUI操作 |
| Qwen3-30B-A3B(2507) | テキスト | テキスト | 汎用の対話・推論 |
| Qwen3-Coder-30B-A3B | テキスト | テキスト | コード生成・エージェント |
| Qwen3-Omni-30B-A3B | テキスト・画像・音声・動画 | テキスト・音声 | 音声対話 |
画像を扱わないなら、VL版を選ぶ理由は多くありません。モデルカードに掲載されたテキスト性能の比較表では、VL版InstructとQwen3-30B-A3B-Instruct-2507の差は小さく(MMLUは両方85.0)、Arena-Hard v2では2507のほうが高い値です(58.5対69.0)。一方でAIME25はVL版が高く(69.3対61.3)、テキスト性能が大きく落ちるわけでもありません。画像とテキストの両方を1つのモデルで処理したい場合は、VL版を1本置けば足ります。Qwen3のテキストモデル全体はQwen3とは?アリババのオープンLLMの特徴・モデル一覧・日本語性能・商用利用を解説で扱っています。
必要VRAMと配布形式の選び方
Hugging FaceのファイルAPIとOllamaのタグ一覧から、配布形式ごとの重みファイルの容量を集計しました(1GB=10億バイト)。これはファイルの容量であり、動作に必要なVRAMそのものではありません。実際にはKVキャッシュと、画像・動画から作られる視覚トークンの分が上乗せされます。
| 配布形式 | 配布元 | 重みの容量 |
|---|---|---|
| BF16(safetensors) | Qwen公式 | 62.14GB |
| FP8(safetensors) | Qwen公式 | 32.25GB |
| GGUF Q8_0 | Qwen公式 | 32.48GB+mmproj |
| GGUF Q4_K_M | Qwen公式 | 18.56GB+mmproj |
| AWQ(4bit) | QuantTrio | 17.89GB |
| Ollama q4_K_M | Ollama公式 | 20GB |
| Ollama q8_0 | Ollama公式 | 34GB |
GGUFで画像を読ませるには、本体とは別に視覚側の射影ファイル(mmproj)が必要です。公式リポジトリにはF16(1.08GB)とQ8_0(0.71GB)があります。本体だけをダウンロードすると、テキストしか扱えません。
全重みをGPUに載せる場合、上の表のうち24GBのGPU(RTX 4090など)1枚に収まるのは4bit系(GGUF Q4_K_M、AWQ、Ollama q4_K_M)だけです。FP8版の重みは32.25GB(約30.04GiB)なので、24GB級GPUには収まりません。32GiBのGPUでは重み以外に使える領域が限られるため、KVキャッシュや実行時の作業領域を含めた実測が必要です。その必要量は、コンテキスト長(--max-model-len)と同時に処理するリクエスト数で変わります。一方、GGUF版はllama.cppでCPUとGPUを併用できるため、一部のレイヤーをCPU側に置けばGPUのメモリが足りない環境でも動かせます。GGUFと量子化の選び方はGGUFとは?量子化モデルフォーマットの仕組みとGPTQ・AWQとの違い・採用判断を解説【2026年版】とLLM量子化とは?仕組みとGPTQ・AWQ・GGUFの違い・企業の採用判断を解説【2026年版】で扱っています。
Ollamaのqwen3-vl:30bはThinking版
Ollamaのタグ一覧では、qwen3-vl:30b・qwen3-vl:30b-a3b・qwen3-vl:30b-a3b-thinkingの3つが同じダイジェスト(eda0be100877)を指しています。つまり短いタグで取得するとThinking版が入ります。OCRや帳票処理のためにInstructを使うつもりなら、タグを明示してください。
qwen3-vl:30b-a3b-instruct(q4_K_M・20GB)qwen3-vl:30b-a3b-instruct-q8_0(34GB)qwen3-vl:30b-a3b-instruct-bf16(62GB)
Ollamaのモデルページには「Qwen3-VL models require Ollama 0.12.7」と書かれています。Ollama 0.12.7は2025年10月29日にリリースされ、Qwen3-VLの全サイズが同時に追加されました。
AWQ版(QuantTrio)を使うときの注意
「qwen3-vl-30b-a3b-instruct-awq」で検索すると、QuantTrioが2025年10月4日に公開した4bit AWQ版が見つかります。これはQwen公式の量子化ではなく、コミュニティによる変換です。ライセンスは元モデルと同じApache-2.0です。
モデルカードに載っているvLLMの起動例は、リポジトリ名がtclf90/Qwen3-VL-30B-A3B-Instruct-AWQになっていて、実際の配布元(QuantTrio)と一致しません。また、--tensor-parallel-size 2と--max-model-len 32768というGPU2枚前提の設定です。そのまま貼り付けず、リポジトリ名とGPU枚数を自分の環境に合わせて書き換えてください。
Qwen3-VL-30B-A3Bの動かし方
公式のREADMEは、本番の推論にvLLMを推奨しています。試すだけならOllama、Pythonのコードに組み込むならTransformersが手軽です。
Transformersによる画像入力の実装
Qwen3-VLのコードはtransformers 4.57.0(2025年10月3日リリース)で本体に取り込まれました。モデルカードには「4.57.0は未リリースなのでソースから入れる」と書かれていますが、これは公開直後の記述です。なお4.57.0はインストール時の不具合でPyPIから取り下げられている(yanked)ため、下限は4.57.1にします。2026年10月17日時点の最新版(5.20.1)にもQwen3VLMoeForConditionalGenerationクラスがあります。
pip install "transformers>=4.57.1" accelerate pillow torchvision
from transformers import Qwen3VLMoeForConditionalGeneration, AutoProcessor
model_id = "Qwen/Qwen3-VL-30B-A3B-Instruct"
model = Qwen3VLMoeForConditionalGeneration.from_pretrained(
model_id, dtype="auto", device_map="auto"
)
processor = AutoProcessor.from_pretrained(model_id)
messages = [{
"role": "user",
"content": [
{"type": "image", "image": "https://qianwen-res.oss-cn-beijing.aliyuncs.com/Qwen-VL/assets/demo.jpeg"},
{"type": "text", "text": "この画像を説明してください。"},
],
}]
inputs = processor.apply_chat_template(
messages, tokenize=True, add_generation_prompt=True,
return_dict=True, return_tensors="pt"
).to(model.device)
generated_ids = model.generate(**inputs, max_new_tokens=512)
trimmed = [out[len(inp):] for inp, out in zip(inputs.input_ids, generated_ids)]
print(processor.batch_decode(trimmed, skip_special_tokens=True)[0])
クラス名はQwen3VLMoeForConditionalGenerationで、MoEではない2B〜32Bの密モデル用クラス(Qwen3VLForConditionalGeneration)とは別です。取り違えると読み込みの段階でエラーになります。
vLLMによるOpenAI互換サーバーの起動
公式READMEの要件はvllm>=0.11.0です。vLLMの公式レシピにある設定項目を30B-A3BのFP8版に当てはめると、画像だけを扱うサーバーの設定例は次のとおりです。FP8推論に対応したGPU環境が必要で、128,000トークン分のKVキャッシュも確保するため、重み容量だけでGPUを選ばないでください。
pip install -U vllm qwen-vl-utils==0.0.14
vllm serve Qwen/Qwen3-VL-30B-A3B-Instruct-FP8 \
--max-model-len 128000 \
--limit-mm-per-prompt.video 0 \
--port 8000
--limit-mm-per-prompt.video 0は動画入力を無効にするオプションです。レシピによると、動画を有効にしたままだと長い動画の埋め込み用にメモリが予約され、その分KVキャッシュに回せる量が減ります。画像しか扱わないサーバーでは指定しておくべきです。起動したら、OpenAI SDKのbase_urlをhttp://localhost:8000/v1に向けて呼び出せます。
用途に応じて足すオプションが2つあります。どちらも2026年10月5日リリースのvLLM 0.31.0のソースコード(エンジン引数の定義)に残っていることを確認しています。
--mm-encoder-tp-mode data:GPUを複数枚使う(--tensor-parallel-size 2以上)ときに、視覚エンコーダを分割せず各GPUに丸ごと置き、画像のバッチを分けて処理します。レシピの説明では、視覚エンコーダは小さいので分割しても得が少なく通信のコストが勝つため、このモードのほうが速くなります。その分メモリを余計に使うので、--gpu-memory-utilizationの調整が要ることがあります。--language-model-only:全モダリティの入力上限を0にして、画像・動画を受け付けないサーバーにします。レシピによると視覚エンコーダの読み込みとマルチモーダル用のメモリ見積もりが省かれ、その分をKVキャッシュに回せます。テキストだけを処理するサーバーなら指定します。
なお、vLLM公式レシピの30B-A3B個別ページ(2026年9月12日更新)で動作が検証されているのはIntel Xeon 6のCPU上でのBF16推論だけで、必要メモリの目安は72GBと書かれています。GPU向けの起動例は、シリーズ共通のページ(Qwen3-VL)に235B-A22Bを例として載っています。vLLMの仕組みと他の推論エンジンとの違いはvLLMとは?PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説を参照してください。
Ollamaによる領収書画像の読み取り
ollama pull qwen3-vl:30b-a3b-instruct
ollama run qwen3-vl:30b-a3b-instruct "この領収書の金額と日付を読み取って ./receipt.png"
Ollamaはプロンプトの中に画像ファイルのパスを書くと、その画像を読み込みます。Thinking版で試したいときは、タグをqwen3-vl:30b-a3b-thinkingに変えます。
APIで呼び出す場合の提供先と料金
Alibaba Cloud Model Studioでは、qwen3-vl-30b-a3b-instructとqwen3-vl-30b-a3b-thinkingの2つのモデルIDが2026年10月10日 00:00に廃止されました。Model Studioのモデル廃止一覧(2026年10月11日更新)では、代替モデルとしてqwen3.7-plusが示されています。廃止日以降はAPIの呼び出しが失敗するため、このIDを使っているコードは差し替えが必要です。2026年9月まで公式の料金一覧に載っていた単価(シンガポールで入力$0.20、出力はInstruct $0.80・Thinking $2.40)も、10月15日更新の料金一覧からは消えています。
同じ重みをAPIで使い続けたい場合は、ほかの事業者がホストしているものを使います。OpenRouterのAPIで、配信している事業者ごとの価格を取得しました(100万トークンあたり・2026年10月17日時点)。
| モデル | 配信事業者 | 量子化 | 入力 | 出力 | コンテキスト |
|---|---|---|---|---|---|
| Qwen3-VL-30B-A3B-Instruct | DeepInfra | FP8 | $0.15 | $0.60 | 262,144 |
| Qwen3-VL-30B-A3B-Instruct | Novita | BF16 | $0.20 | $0.70 | 131,072 |
| Qwen3-VL-30B-A3B-Instruct | SiliconFlow | FP8 | $0.29 | $1.00 | 262,144 |
| Qwen3-VL-30B-A3B-Thinking | SiliconFlow | FP8 | $0.29 | $1.00 | 262,144 |
| Qwen3.6-35B-A3B(後継) | Darkbloom | FP4 | $0.05 | $0.70 | 262,144 |
| Qwen3.6-35B-A3B(後継) | AkashML | FP8 | $0.10 | $0.90 | 262,144 |
同じモデルでも、事業者によって量子化とコンテキスト長が違います。Thinkingを配信しているのはSiliconFlowの1社だけで、ここが止めると代わりがありません。OCRの精度を比べるときは、どの事業者に振り分けられたかを固定して測ってください。Thinkingは推論の過程も出力トークンとして課金されるため、同じ質問でも請求額の差は単価の差より大きくなります。
YaRNによる256K超のコンテキスト拡張
配布されているconfig.jsonは262,144トークンまでの設定です。それを超える入力にはYaRNを有効にします。公式READMEは、Interleaved-MRoPEは位置IDの増え方が通常のRoPEより遅いため、100万トークンに広げる場合でも係数(factor)は4ではなく2か3にするよう注意しています。
公式READMEとモデルカード由来の例には--rope-scalingが載っていますが、このオプションはvLLM 0.26で削除されました。vLLMのレシピ集の執筆ガイドによると、現行版では--hf-overridesでrope_parametersを渡し、VLモデルではtext_configの下に入れる必要があります。rope_thetaはこのモデルのconfig.jsonの値(5000000)です。
VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 vllm serve Qwen/Qwen3-VL-30B-A3B-Instruct \
--hf-overrides '{"text_config":{"rope_parameters":{"rope_type":"yarn","rope_theta":5000000,"factor":3.0,"original_max_position_embeddings":262144,"mrope_section":[24,20,20],"mrope_interleaved":true}}}' \
--max-model-len 1000000
画像1枚あたりのトークン数を抑える設定
VLMでは、重みとKVキャッシュに加えて、画像や動画から作られる視覚トークンもメモリを使います。Qwen3-VLは画像を32×32ピクセルごとに1トークンへ圧縮するため、高解像度の画像ほどトークン数が増えます。公式READMEは、プロセッサの設定で画像1枚を256〜1,280トークンに収める例を示しています。
processor.image_processor.size = {
"longest_edge": 1280 * 32 * 32, # 最大 1,280 トークン
"shortest_edge": 256 * 32 * 32, # 最小 256 トークン
}
processor.video_processor.size = {
"longest_edge": 16384 * 32 * 32 * 2, # 動画全体で最大 16,384 トークン
"shortest_edge": 256 * 32 * 32 * 2,
}
動画は既定で毎秒2フレームを取り出します。長い動画ではフレーム数(num_frames)を指定するか、fpsを下げて総トークン数を抑えます。細かい文字を読むOCRで上限を下げすぎると認識精度が落ちるため、帳票処理では上限を下げずに一度に送る枚数を減らすほうが安全です。
なお、qwen-vl-utilsで前処理する場合は、Qwen3-VLのパッチサイズに合わせてimage_patch_size=16を渡す必要があります。この引数の既定値はQwen2.5-VL向けの14です。
後継のQwen3.6-35B-A3B・Qwen3.8-27Bとの選び分け
2026年2月16日に始まったQwen3.5世代から、Qwenは視覚言語モデルを別系列で出さず、1つのモデルで画像も扱う方式に変わりました。2月24日に公開されたQwen3.5-35B-A3Bのモデルカードには「Early fusion training on multimodal tokens achieves cross-generational parity with Qwen3 and outperforms Qwen3-VL models」と書かれています。2026年4月には同じ規模のQwen3.6-35B-A3Bが出ました。2026年8月のQwen3.8世代で公開された重みは27B(密モデル)・Flash-Next・2.4T-A95Bの3系統で、35B-A3Bに当たるMoEの後継はありません(2026年10月17日にHugging FaceのQwen公式アカウントの一覧で確認)。
| 項目 | Qwen3-VL-30B-A3B | Qwen3.6-35B-A3B | Qwen3.8-27B |
|---|---|---|---|
| 公開日 | 2025-10 | 2026-04 | 2026-08 |
| 構成 | MoE(約30B・活性3B) | MoE(35B・活性3B) | 密(27B・全パラメータが活性) |
| 層数 | 48 | 40 | 64 |
| 画像・動画入力 | あり | あり | あり |
| コンテキスト | 262,144 | 262,144(最大1,010,000) | 262,144(最大1,000,000) |
| Instruct/Thinking | 別リポジトリ | 1モデルで切替(既定はThinking) | 1モデルで切替(既定はThinking) |
| Ollamaの既定タグ(4bit) | 20GB | 23GB | 18GB |
| ライセンス | Apache-2.0 | Apache-2.0 | Apache-2.0 |
Qwen3.5-35B-A3Bのモデルカードの値とQwen3-VL-30B-A3B-Thinkingの公式表を並べると、MMMUは81.4対76.0、MathVisionは83.9対65.7、ScreenSpot Proは68.6対57.3です。別々の表から取った値で評価条件が同じとは限らないため参考値ですが、差は小さくありません。
新しく画像処理を組むなら、まず同じ活性3BのQwen3.6-35B-A3Bを評価するのが順当です。仕様の詳細はQwen3.6-35B-A3Bとは|必要VRAM・GGUFサイズ・Ollama/vLLMの動かし方とベンチ比較にあります。Qwen3.8-27BはOllamaの4bit版が18GBと30B-A3Bより小さい一方、1トークンごとに全パラメータを使う密モデルです。1トークンあたりに使うパラメータは27B対3Bで約9倍ですが、アーキテクチャが違うため、計算量や生成時間がそのまま9倍になるわけではありません。重み容量を優先するなら3.8-27Bを候補にし、生成速度を優先するなら同じGPU・量子化・入力長で3.6-35B-A3Bと比較してください。Qwen3.8世代の全体像はQwen3.8-Maxとは|2.4兆MoEの必要VRAM・GPU台数・ライセンスと27Bの選び方で扱っています。
一方、Qwen3-VL-30B-A3Bを使い続ける理由がある場面もあります。
- Qwen3-VL-30B-A3Bでファインチューニング済みのモデルがあり、再学習のコストをかけたくない。
- 本番環境のvLLMやOllamaの版を固定していて、新しいアーキテクチャ(線形アテンションのGated DeltaNetを含むQwen3.5以降の系統。3.8-27Bも同じ)に対応した版へ上げられない。
- OCRの出力を後段のパーサーが前提にしていて、モデルを替えると出力の書式が変わるリスクを負えない。
採用を見送るべき場面
次のいずれかに当てはまる場合は、Qwen3-VL-30B-A3Bを選ばないほうがよいです。
- GPUのメモリが16GB以下で、GPUだけで動かしたい:4bit版でも重みだけで約18〜20GBあり、全重みをGPUに載せられません。llama.cppでCPUを併用すれば動かせますが、GPUだけの構成とは別に速度を測る必要があります。GPUに収めたいなら、Qwen3-VLの8B(Ollamaで6.1GB)を検討します。
- 日本語の手書き文字や縦書き帳票が主な対象:OCRは32言語に対応していますが、公式ベンチマークに日本語の手書き・縦書きを対象とした項目はありません。自社の帳票で精度を測ってから決めるべきです。帳票の読み取り精度の評価から業務への組み込みまでを外部に頼む場合は、AI-OCR導入支援のような支援サービスを使う手もあります。
- 音声の入出力が必要:Qwen3-VLは音声を扱えません。同規模ならQwen3-Omni-30B-A3Bが対象です。
- Alibaba Cloud Model StudioのAPIで使いたい:2026年10月10日に廃止済みです。Model Studioに留まるなら、代替として示されているqwen3.7-plusへ移る必要があり、30B-A3Bそのものは使えません。
ファインチューニングを検討する場合は、Unslothがunsloth/Qwen3-VL-30B-A3B-Thinkingなどの変換済みリポジトリを公開しています。手順はUnslothとは?読み方・使い方とDesktop・Studio・Coreの違い【2026年9月】を参照してください。
よくある質問
Qwen3-VL-30B-A3B-InstructとThinkingの違いは何ですか?
Instructはすぐに回答を返し、Thinkingは回答の前に推論の過程を出力します。公式ベンチマークでは、文字認識(OCRBench 903対839)とGUI要素の特定(ScreenSpot Pro 60.5対57.3)ではInstructが、図を含む数学(MathVision 60.2対65.7)と複数画像の比較(MUIRBENCH 62.9対77.6)ではThinkingが上回ります。重みは別リポジトリなので、使う方を読み込みます。
Qwen3-VL-30B-A3B-Instruct-AWQはどこにありますか?
Qwen公式のAWQ版はなく、QuantTrioが公開しているQuantTrio/Qwen3-VL-30B-A3B-Instruct-AWQ(17.89GB)を利用できます。モデルカードの起動例はリポジトリ名がtclf90/になっているため、書き換えてから使ってください。公式の量子化はFP8版とGGUF版です。
Qwen3-VL-30B-A3Bのモデルカードとダウンロード先はどこですか?
Hugging FaceのQwen/Qwen3-VL-30B-A3B-InstructとQwen/Qwen3-VL-30B-A3B-Thinkingです。FP8版は末尾に-FP8、GGUF版は-GGUFが付いたリポジトリで配布されています。公式GitHubのREADMEからは、ModelScope上のQwen3-VLコレクションにも辿れます。
動かすのに必要なVRAMはどれくらいですか?
重みファイルの容量は、BF16が62.14GB、FP8が32.25GB、4bit系(GGUF Q4_K_M・AWQ)が約18GBです。これにKVキャッシュと視覚トークンの分が加わるため、全重みを24GBのGPU1枚に載せるなら4bit版を使い、コンテキスト長と画像の解像度を抑える必要があります。
Qwen3-Coder-30B-A3Bとは別のモデルですか?
別のモデルです。Qwen3-Coder-30B-A3Bはテキストのみを扱うコード生成向けのモデルで、画像は入力できません。Qwen3-VL-30B-A3Bは画像・動画を入力できる視覚言語モデルです。名前の「30B-A3B」は規模(総パラメータ約30B・活性約3B)を示しているだけで、同じモデルの派生ではありません。