ZoomGain-4B vs Qwen3.8-27B: The 11-Point Win Is Over a Dataset, Not a Model

The number that makes this matchup worth a page is 55.81 against 44.81. On ZoomGainBench, the 1,000-question fine-detail benchmark published alongside inclusionAI's ZoomGain-4B, a 4.54-billion-parameter vision model scores eleven points above Qwen3.8-27B, a 27.78-billion-parameter dense model that A​libaba released under Apache 2.0 in August and that reads images and video as well as text. Six times the parameters, and it loses by eleven points. Read the paper that produced both numbers and the gap stops being a claim about eyesight: ZoomGainBench was built by the same automated pipeline that generated ZoomGain-4B's training data, the authors say so themselves in their ablation study, and the model they were genuinely racing against is not Qwen3.8-27B at all — it is another dataset.

That is not a debunk. It is the most useful thing in the release, and it is what makes the comparison decidable: it tells you which of the two models to reach for, and which number to quote when someone asks you to justify the choice. What follows separates the three claims that get bundled together here — that a small specialist beats a large generalist, that a data pipeline beats another data pipeline, and that either of these is a reason to change your stack this month.

What shipped, and how quietly

The repository for ZoomGain-4B was created on Hugging Face on 10 November 2026 at 11:38 UTC and last modified on 11 November. The paper, arXiv 2611.14076, was submitted on 10 November. The GGUF repository was touched at 03:13 UTC on 11 November. At the time of writing both repositories show zero downloads and zero likes, there is no inference provider mapped to the model, and no vendor launch post, blog entry or press release exists for it. The model card's own Updates list, dated 11 November, is the only announcement: three lines saying the paper, the benchmark, the RL dataset and the checkpoints are out.

So the honest framing is that this shipped quietly and has not been announced. Everything below that comes from a repository is checkable today; anything about how the model behaves outside the authors' harness is not yet confirmed, because nobody outside Ant Group and Zhejiang University has run it and reported back.

Two details from the repository are worth having before the comparison starts, because both narrow what you can do with it.

• Architecture. A Qwen3.5-4B derivative — 32 layers, hidden size 2,560, 16 query heads against 4 KV heads at head dimension 256, a 3:1 schedule of linear DeltaNet to full attention, 262,144 maximum positions, a 248,320-token vocabulary, and a 24-layer vision encoder at hidden 1,024. The total, encoder and projector included, is 4,539,265,536 parameters.

• Licence. The card's License section covers the code, which is Apache 2.0, and then defers: "See the Hugging Face cards for the terms of each dataset and checkpoint." The checkpoint card carries no licence tag at all. Qwen3.8-27B is Apache 2.0 in unambiguous terms. If you need a licence you can hand to a lawyer, that asymmetry is the first thing you hit and it is not resolved by anything in the release.

The one list where both models appear side by side

ZoomGainBench is a 1,000-question, bilingual benchmark over 941 images: 472 attribute-recognition questions with four to six options, 94 counting questions and 434 OCR questions, each in an English and a Chinese version, so 2,000 evaluation instances. Twenty-eight models were run on it under one harness — same system prompt, temperature 0, thinking disabled for every Q​wen checkpoint, 2,048 output tokens for the non-agentic models. The best result in the field is GPT-5.6-Sol at 61.08, and only five models clear 50.

Qwen3.8-27B lands at 44.81 overall: 43.84 in English from 40.25 attribute, 54.26 counting and 45.49 OCR, and 45.78 in Chinese. ZoomGain-4B, in the training table rather than the benchmark table, lands at 55.81. Both figures are the two-language overall on the same scoring rules, so this is as close to a controlled pairing as the release offers, and on it the 4B wins by 11.00 points.

• Parameters. 4.54B against 27.78B — a 6.1× difference in the direction that makes the result surprising.

• What each was built to do. ZoomGain-4B is Qwen3.5-4B put through one epoch of GRPO on 9,000 mined questions, 140 steps, batch 64, eight rollouts per question, learning rate 1e-6, no KL term. Qwen3.8-27B is a general dense model with a reasoning mode, tool calling and a video path.

• Training data. 9,000 questions for one. For the other, the whole of A​libaba's pretraining and post-training corpus, undisclosed in size.

• Availability. ZoomGain-4B: three GGUF precisions and a separate projector file, no hosted endpoint. Qwen3.8-27B: Apache 2.0 weights, an FP8 build, 7.4 million downloads, and endpoints you can call today.

The comparison the paper actually establishes

Here is the part that gets lost when the release is reduced to "4B beats 27B". The paper needed a baseline for its own data, and it used one: ZwZ, an ICML 2026 fine-grained perception dataset built by region-to-image distillation. Both sides were given identical treatment. Twelve thousand images were sampled and 23,610 questions generated; the benchmark took 1,000; the remainder yielded 8,746 image-matched question pairs, and 254 were duplicated on both sides to bring each set to 9,000. Same images, same base checkpoints, same hyperparameters, same 140 steps. The only variable is the questions.

ZoomGain data beats ZwZ data on every axis the paper reports. On Qwen3.5-4B the held-in score moves 40.99 to 55.81 and the thirteen-benchmark held-out average moves 58.94 to 63.96; on Qwen3.5-9B the same pair of numbers is 44.07 to 55.48 and 62.53 to 66.10. That is a real, well-controlled result about how you generate supervision, and it is the contribution the title of the paper is making.

Qwen3.8-27B contributes nothing to that argument. It appears once, as a single row among 27 other benchmarked models. It is a yardstick — a competent generalist measured on a distribution nobody trained it for — not a competitor. The paper's own text is explicit that the gap it exploits is shared: global-view error distractors take 71.7% of all incorrect answers across all 28 models, above the 54.5% a random choice among the options would produce, and the four closed-source models that took no part in building the benchmark show the same behaviour at 75.7% against 57.4% expected.

The ablation is the strongest argument against the headline

The authors ran the obvious sanity check on themselves, and the result is the most informative table in the paper. They retrained on the same 9,000 questions twice, each time removing one of the two design choices that define their pipeline: the rule that questions may only be built from details invisible in the full image, and the dedicated distractor generation stage.

• Full pipeline. ZoomGainBench 55.81; average over the ten held-out benchmarks the ablation reports, 60.96.

• Dedicated distractors removed. ZoomGainBench 46.85 — a loss of 8.96 points on the held-in test — and the ten-benchmark average 59.14, a loss of 1.82.

• Incremental evidence removed. ZoomGainBench 49.71, a loss of 6.10 — and the ten-benchmark average 58.57, a loss of 2.39.

Both design choices are worth six to nine points on ZoomGainBench and about two points on everything else. The authors give the reason plainly: removing dedicated distractors "causes the largest drop on the held-in ZoomGainBench" because "the benchmark's options are constructed using the same pipeline." In other words, roughly three-quarters of the headline gain on the benchmark that produced the headline number is the model learning to answer the kind of question the pipeline writes, not learning to see better.

What survives that is still substantial. On the thirteen benchmarks the training never touched, Qwen3.5-4B goes from 57.86 to 63.96 — 6.10 points from 9,000 samples — with the largest gains in exactly the family the pipeline targets: HR-Bench 4K 81.25 to 87.25, V*Bench 81.68 to 90.05, VisualProbe 43.30 to 57.28, O3-Bench 54.20 to 63.19. One benchmark regresses: TreeBench, 49.38 to 49.14, a fifth of a point. MMStar, a general multimodal suite, moves 66.80 to 72.53, and BabyVision stays poor at 21.13.

That profile is the signature of a narrow intervention, and it is the profile you should plan around. The model got better at resolving small things in a scene. It did not become a better generalist, and the arithmetic that says otherwise is arithmetic on its own benchmark.

What the benchmark actually asks, since that is what you would be buying

If the intended use is fine-detail checking, the composition of the test matters more than the overall score, and the paper's error analysis is unusually concrete about it.

• Small anchors dominate. Accuracy rises with the fraction of the image the queried detail occupies, for every model group: averaged over all 28, it climbs from 28.9% on the smallest quartile, where the anchor covers less than 0.4% of the image, to 55.2% on the largest.

• Counting is small-number counting. 67 of the 94 counting questions have a ground truth of at most three, and 71.6% of wrong numeric answers are off by exactly one. The difficulty is resolving a few small instances, not enumerating many.

• Attribute recognition is the hard category. It produces the lowest score for 23 of the 28 models, and guessing uniformly across the options would already yield about 21.5%.

• The failure mode is scene-plausible substitution. In one documented case, 46 of 56 evaluations call a white object on a truck's dashboard orange — plausibly the colour of the vest worn by the worker standing in front of it. In another, nearly every evaluation names a hockey equipment brand instead of the logo actually printed on the garment. Models do not say "I cannot see it"; they answer from context.

That failure mode is the practical argument for this kind of training, because it is the same one that makes a document pipeline quietly wrong on a scanned invoice. It is also the argument for measuring it: a model that substitutes a plausible answer produces confident output, so nothing downstream catches it.

Where Qwen3.8-27B is in a different room

The 44.81 is real, and it is also the only number in this article that Qwen3.8-27B is judged on here. Its own card reports a different set of things entirely, and none of them can be compared with ZoomGain numbers because the two models were never run on the same harness for them.

• Agentic coding. Terminal Bench 2.1 at 73.0, SWE-bench Pro 61.7, LiveCodeBench v6 90.3, QwenSWEBench 79.0 — all vendor-reported on Q​wen's own card, with the harness notes published alongside.

• Reasoning and computer use. GPQA Diamond 89.2, HLE 30.8, OSWorld-Verified 84.3, WebArena-Verified 64.8.

• Multimodal work. OmniDocBench 1.5 at 91.1, CharXiv reasoning 83.7 without chain-of-thought injection and 90.2 with it, RealWorldQA 85.9, MathVision 90.0.

• Capability surface. Thinking on by default with reasoning_effort at xhigh, medium or low, preserved thinking across turns, native tool calling, structured outputs, video input, 262,144 positions natively and extensible to one million.

ZoomGain-4B has been evaluated on none of these and would not be expected to do well on any of them: its training never touched code, terminal tasks, documents or charts. It also has no reported evaluation in a thinking mode — the release's own harness runs with thinking disabled at temperature 0, so everything published about it describes its direct-answer behaviour. Qwen3.8-27B's 44.81 was measured the same way, with enable_thinking=false, which is the one thing that makes the comparison fair and the one thing that leaves Q​wen's best mode untested.

Put plainly: on the axis ZoomGain-4B was trained for, it wins, and on the axes Qwen3.8-27B was built for, the 4B is not in the room. Neither of those is a surprise, and treating either as the whole story is how a comparison page becomes useless.

What each costs to stand up, and the one you can call today

This is where the two diverge in a way that decides the deployment rather than the benchmark.

ZoomGain-4B has no hosted endpoint anywhere. What exists is the BF16 repository, 4.54 billion parameters across a language model and a separate vision encoder, and three GGUF builds: Q4_K_M at 2.71 GB, Q8_0 at 4.48 GB and F16 at 8.42 GB, each paired with its own mmproj projector — 0.23 GB, 0.36 GB and 0.67 GB respectively — which the GGUF card states is required for image input. Running it means llama-mtmd-cli or llama-server from a llama.cpp build recent enough to know Q​wen3.5 multimodal; running it at full precision means vLLM 0.19.1 with transformers 5.7.0. There is no MLX build, no ONNX, no draft model for speculative decoding, and no provider to fall back to if your build breaks.

Qwen3.8-27B is in the OrcaRouter catalogue, and we run those weights on our own infrastructure rather than reselling someone else's endpoint — which is why the price on our model page is the price, with no markup layered on top and no vendor list price being marked up in between. It is $0.33 per million input tokens and $2.40 per million output, text, image and video in, 262,144 tokens of context, and a single key. The same key also reaches Qwen3.8-Flash at $0.15 and $0.47 per million with a one-million-token window, and Qwen3.8-Max at $2.00 and $6.00, so a workload that outgrows the 27B or needs a longer window moves without a second contract or a code change. Failover is the part that matters for anything production-shaped: a stalled provider retries before the response starts rather than after your request times out.

ZoomGain-4B is not in that catalogue and cannot be called through us. It is a folder of weights you serve yourself, and the honest version of the recommendation has to start there.

Who should act, and what is still unconfirmed

If you have image-heavy work where the answer turns on a small detail — a part number on a label, a colour on a screen, whether there are two screws or three — a 4.54B model that was RL'd specifically on that, running locally at 2.71 GB in Q4_K_M, is a credible cheap second opinion to run alongside a hosted generalist. Not instead of one. The specialist's failure profile is confident substitution, which is the exact failure a generalist check catches, and vice versa.

If your workload is documents, charts, screenshots, video, code or agents, the 27B is the one to call, and the 44.81 on a fine-detail benchmark nobody trained it for is not a reason to think otherwise.

What remains unconfirmed, and worth watching rather than assuming:

• The weights licence. Apache 2.0 covers the code. The checkpoint carries no licence tag and the card defers to "the terms of each dataset and checkpoint" without stating them. Until that is resolved, commercial deployment is a conversation with a lawyer, not a checkbox.

• Any reproduction. Every number above is author-reported, produced on the authors' own harness. The benchmark and the evaluator are public, so it is checkable, but nobody outside Ant Group and Zhejiang University has checked it.

• Whether the gain generalises past the pipeline. The held-out numbers are the ones to trust, they are modest — 6.10 points over the base model's thirteen-benchmark average — and they lean heavily toward the fine-grained family the training targeted. Whether that transfers to your images is an open question the release does not answer.

• Whether it holds up at Q4. The GGUF card warns that quantisation can affect accuracy, and nothing published compares the quantised builds against the BF16 checkpoint on ZoomGainBench. For a model whose entire value is fine detail, that is the experiment to run before you trust a 2.71 GB file.