ModelsQwen3-VL 30B A3B Thinking: Visual Reasoning on a Budget
The small Qwen3-VL reasoning model gains more on code from thinking than the 235B does, at 3B active. Where it fits between the 30B Instruct and the 235B Thinking.
Reasoning on images is usually treated as a flagship feature: you want the model to work through a diagram, so you reach for the biggest model available. Qwen3-VL-30B-A3B-Thinking is a reason to check that instinct. With about 3B active parameters per token it is cheap and fast to run, and on Qwen's own numbers it closes a large part of the gap to the 235B reasoning model.
Qwen released it on 4 October 2025 alongside the Instruct edition, with Apache-2.0 weights and an FP8 checkpoint. It shares the 30B-A3B architecture and the 256K native context; the difference is post-training for reasoning, and it always writes a trace before answering.
Where thinking pays most
The Qwen3-VL technical report gives text-only scores for both editions of each MoE model. On maths the jump from Instruct to Thinking is similar at both sizes; on code it is larger at 30B:
- AIME25: 69.3 for 30B Instruct, 83.1 for 30B Thinking, a 13.8-point gain; the 235B pair gains 15.0
- LiveCodeBench v6: 42.6 to 64.2, a 21.6-point gain; the 235B pair gains 15.8
- MMLU-Pro: 77.8 to 80.5
The LiveCodeBench row is the striking one. The 30B Thinking scores 64.2 against 54.3 for the 235B Instruct, so on algorithmic code a small model allowed to think beats a large model that is not. That is the general lesson of chain of thought in miniature: for problems with intermediate steps, spending output tokens can substitute for parameters.
Knowledge does not follow. MMLU-Pro moves less than three points, because thinking does not supply facts the model never learned. If a task fails on recognition or recall, a trace will not rescue it.
Where it sits against the 235B Thinking
The 235B Thinking edition still leads: 89.7 on AIME25 against 83.1, 70.1 on LiveCodeBench against 64.2, 83.8 on MMLU-Pro against 80.5. The report also reserves its state-of-the-art claims on visual maths benchmarks for the larger model and describes the 30B as competitive.
The price gap runs the other way. OpenRouter listed the 30B Thinking at $0.29 input and $1.00 output per million tokens at the time of writing, against $0.40 and $4.00 for the 235B Thinking. Because a reasoning model's bill is dominated by output, a quarter of the output price is close to a quarter of the cost per answer at similar trace lengths.
Against the text-only reasoning model of the same size, it gives up very little. Qwen's published figures for Qwen3-30B-A3B-Thinking-2507 are 85.0 on AIME25, 66.0 on LiveCodeBench v6 and 80.9 on MMLU-Pro, within two points on each row. If your traffic mixes images and text, one deployment of this model is a reasonable choice. The Qwen3 30B A3B Thinking guide covers the text-only model.
Fast traces, because 3B active
A reasoning trace is many sequential tokens, so per-token speed sets the user's wait. With 3B active parameters, each decode step does far less work than one on a model with 22B active, so on comparable hardware a long trace finishes sooner. For interactive tools such as a tutor that reads a photographed problem, or an assistant that explains a chart in a dashboard, measure that wait on your own stack, because it decides whether reasoning is usable there.
It also changes self-hosting. The checkpoint is about 31B parameters including the vision encoder, roughly 62 GB at 16-bit by simple arithmetic and about half that in FP8, which Qwen says needs H100-class hardware. Long traces mean a large KV cache per request, so leave memory headroom beyond what an Instruct deployment would need.
Settings that matter
Qwen's evaluation settings for the Thinking editions are temperature 0.6, top-p 0.95, top-k 20 and no presence penalty, with outputs up to 40,960 tokens. The report extends that to 81,920 tokens for the hardest maths and code benchmarks. In production, cap output per task class; a chart question rarely needs more than a few thousand tokens of reasoning, and a cap stops the occasional runaway trace from becoming the slowest and most expensive request of the day.
Keep the trace out of user-facing output. Most OpenAI-compatible servers with a reasoning parser return it as a separate field, but verify on your own stack before shipping, and log trace length so you can see when a prompt change makes the model think twice as long.
An escalation ladder
- Send perception tasks, such as reading, captioning and screen description, to the 30B Instruct.
- Send multi-step image tasks to this model first.
- Escalate to the 235B Thinking only for the class of problems where your own tests show this model failing, not by default.
Build the test from thirty of your own image-reasoning problems with known answers, and record accuracy, output tokens and wall-clock time per problem. If the 30B solves most of them, the ladder above will spend most of its budget at the cheap rung.
Common questions
Is Qwen3-VL-30B Thinking better than Qwen3-VL-235B Instruct?
On reasoning-heavy work, sometimes. Qwen's report gives the 30B Thinking 83.1 on AIME25 and 64.2 on LiveCodeBench v6, against 74.7 and 54.3 for the 235B Instruct. On knowledge and perception tasks the larger model remains ahead or equal.
When should I not use the Thinking edition?
For reading and describing images: OCR, captioning, field extraction and screen reading. A reasoning trace adds cost and latency there without improving accuracy, so the 30B Instruct edition is the better fit.
What output limit should I set for Qwen3-VL-30B Thinking?
Qwen evaluates with up to 40,960 output tokens, and 81,920 for the hardest maths and code. In production, set a lower cap per task class and log trace length so unusually long reasoning is visible.
