Moondream 3.1 9B A2B vs North Micro Vision Instruct: Which Vendor Actually Lets You Check The Number

Two open vision models, four months apart, with almost nothing in common about how they ask to be judged. M​oondream 3.1 9B A2B launched on 7 July 2026 with a benchmark table, a methodology footer naming a single H100 SXM5 and a batch size of 16, and an argument running through the same post that benchmarks do not measure what its customers actually need. North Micro Vision Instruct arrived on 12 August 2026 from C​ohere Labs at 2.4B parameters under Apache 2.0, and its release post spends its length on the training curriculum and its evaluation setup — the harness used, and the exact sampling parameters the numbers were produced with.

That is a real difference in kind, and it is more useful to a buyer than either model's parameter count. One vendor is telling you how to reproduce its table. The other is telling you not to trust tables and then printing one. Neither has been independently evaluated, as far as we can find, so the question that really decides which set of numbers to lean on is how much either vendor has given you to check.

What each one is

M​oondream 3.1 9B A2B is a sparse mixture-of-experts vision-language model: 9B total parameters, 2B active per token, 64 experts with 8 active, a SigLIP vision encoder with multi-crop channel concatenation, a 32K-token context and a SuperBPE tokenizer. Its four skills — query, detect, point and caption — are trained in rather than prompted, and the detection and pointing paths return structured geometry rather than description. It runs on Photon, the vendor's inference engine, targeting N​VIDIA GPUs from Ampere onward and Apple Silicon.

North Micro Vision Instruct is a 2.4B dense model built from three parts: a 400M native-resolution vision encoder further pre-trained from G​oogle's SigLIP 2 SO400M checkpoint, a projector that follows the DeepStack pattern of injecting patch embeddings from several encoder layers into early language-model layers, and a 2B language model called North Micro LLM that follows C​ohere's Command A+ architecture. It takes interleaved text and images — one or several — and outputs text. The tokenizer vocabulary is 262,144, and the languages listed run to eleven plus "and more".

The output-type difference is worth stating plainly because it shapes what follows: M​oondream is a perception model that answers with boxes and coordinates, North Micro Vision is an understanding model that answers with language. Everything either vendor publishes is a measurement of one of those two jobs, and they are not the same job.

The 8K number that is not the model's context window

Start with the trap, because it is sitting in the middle of the North Micro Vision model card and it is the kind of thing that ends up in an architecture decision by accident.

• North Micro Vision Instruct — language backbone context window 128,000 tokens; validated multimodal operating range up to 8,000 tokens. The card states outright that longer multimodal contexts may rely on extrapolation and have not been benchmarked.

• M​oondream 3.1 9B A2B — 32,000 tokens, one number, no modality carve-out published.

So the headline figure favours North Micro Vision by a factor of four and the figure that will actually apply to your image workload favours M​oondream by a factor of four. If you are estimating how many pages of a scanned document fit in a single call, 128K is the wrong number and 8K is the right one, and 8K of interleaved image and text tokens is not many pages once a native-resolution encoder starts emitting tokens in proportion to pixel area. The vendor deserves credit for publishing the caveat — most cards would not — but the caveat is buried below a table of specifications and the table is what gets copied.

How the two vendors report, side by side

This is the part of the comparison that has nothing to do with the models and everything to do with which one you can audit.

M​oondream's 3.1 post states its baselines (Qwen3.5 9B, SAM 3, LocateAnything, Gemma 4 12B), its metric (F1@0.5 for detection), its hardware (one H100 SXM5), its batch size (16), and the fact that each model was served by its own engine — vLLM for LocateAnything, Qwen3.5 and Gemma 4; Photon for M​oondream; Hugging Face Transformers for SAM 3. It also says the highest accuracy and reasoning settings were chosen per model, and that LocateAnything ran in a slow mode to maximise accuracy. The results it publishes are 81.46 F1@0.5 on COCO val, 93.94 on ODinW-13, 67.4 on LVIS, 74.61 on Dense200, 52.77 on SKU-110K, 74.5 on CrowdHuman, 87.1 on RefCOCO-M, 70.39 on HumanRef, 59.63 on DOTA-v2, 90.35 on CountBench, 74.86 on TallyQA, 88.68 on PixMo-Count, 86.01 on ChartQA and 88.6 on DocVQA, with state-of-the-art claims on five of the benchmark families.

What is not in that footer is the thing that makes a result reproducible: the prompts. Detection is an open-vocabulary task, and the phrase you ask for a thing with changes what comes back. A re-runner has the metric, the hardware and the batch size, and still cannot reproduce the number without knowing what text produced each box.

C​ohere Labs' post takes the other approach. It names the harness (VLMEvalKit), says the model was evaluated with an internal vLLM implementation, lists the benchmark composition for each capability group — General VQA is an average over MMBench, MMStar, RealWorldQA and GQA; the chart, document and OCR group covers ChartQA, DocVQA, InfoVQA, OCRBench, OCRBench v2 and AI2D; grounding and counting are RefCOCO average and CountBench — and publishes the sampling parameters the numbers were produced under: temperature 0.7, top_p 0.8, top_k 20, min_p 0.0, presence_penalty 1.5, repetition_penalty 1.0. It also flags that public vLLM support is "coming soon", which is the honest disclosure that matters most for anyone planning to reproduce: the model was tested on a fork.

What that post does not publish is a per-benchmark table. Its results are capability-group averages and a relative claim — in Instruct mode, 35B-A3B scores higher in less inference time than Qwen3.6 35B-A3B, and the 1B variant outperforms Qwen3.5 0.8B on both score and efficiency — which is less immediately quotable and more robust to cherry-picking. Neither document lets you recompute the other vendor's number. Both let you see how much they are hiding.

Where the architecture difference shows up in practice

Native resolution is the one design decision in North Micro Vision that changes daily work, and it is worth understanding before the benchmark tables. Most vision encoders resize whatever you give them into a fixed square, which is why a wide spreadsheet screenshot arrives at the language model with its columns squashed. North Micro Vision's encoder is trained to take the image at its own resolution and aspect ratio, preserving the fine detail of documents, tables, charts and forms. The published curriculum went from a fixed 384×384 stage on 10 million examples to a 1024×1024 stage on 13 million and beyond.

M​oondream's encoder is instead based on multi-crop: the image is treated as a set of crops whose features are concatenated, which is also a way of preserving detail on large inputs and is coupled to how its detection head produces boxes. Both are legitimate answers to the same problem and neither vendor publishes a head-to-head at matching resolution, so the useful thing to take from the architecture discussion is narrower than a verdict: if your work is dense documents and wide UI screenshots, native resolution is the property to test, and the test is a screenshot of your own, not a benchmark row.

The other structural difference is multi-image and video. North Micro Vision Instruct handles interleaved multi-image input and lists multi-image benchmarks among the groups it evaluated. M​oondream 3.1 9B A2B is scoped to one image per call — no video path, no multi-image path. That is consistent with its design: M​oondream's own engineering writing on live video argues that the problem is inference plumbing rather than model capability, and the company's answer to temporal workloads is an engine that keeps up with a stream rather than a checkpoint that ingests one. Whether that is a better answer than a model that takes 128 frames at once is an honest open question, and the two vendors are not measuring the same thing.

Deployment and licence, quickly

• Size — 9B total / 2B active against 2.4B dense. In storage terms the gap is wider than the active-parameter ratio suggests, because a sparse model's footprint tracks its total.

• Fine-tuning scale — a 2.4B dense model is small enough to fine-tune on a single device; a 9B sparse model wants a real training setup for anything beyond a LoRA, which is why M​oondream's own tuning path ran through a hosted product.

• Runtimes — North Micro Vision Instruct asks for Transformers 5.16.0 with accelerate and Pillow; community quantisations exist in MLX, LiteRT and ONNX-adjacent formats. M​oondream 3.1 9B A2B runs on Photon, with the first third-party GGUF packaging of the checkpoint appearing on 15 October 2026.

• Licence — Apache 2.0 for North Micro Vision Instruct, with no threshold and no restriction on hosting it for others. The M​oondream Model License 1.0 for M​oondream 3.1 9B A2B: commercial use, self-hosting, fine-tuning, quantisation and redistribution all permitted, with one prohibition — you may not offer general-purpose M​oondream inference or fine-tuning as a hosted service.

• Churn — North Micro Vision Instruct has been static since release; the notable recent additions are third-party quantisations. M​oondream's terms changed under it in the last fortnight: Prime Intellect acquired the company on 13 October 2026, and M​oondream Cloud, including the Lens fine-tuning product, shuts down on 13 November 2026. The weights and Photon are unaffected; the hosted path is not.

The second model in the pipeline, and who routes it

Neither of these checkpoints is served on OrcaRouter, so read this as an integration note. Both are single-stage components: one returns boxes, the other returns text, and a production system needs a model behind them to decide what the observation means and to write it down. That stage is a text stage, it usually costs more per call than the vision stage, and it is the stage you will want to swap first when a cheaper or better reasoning model appears. Doing that swap through one OpenAI-compatible endpoint across 200-plus models — with provider list pricing passed through at 0% markup and automatic failover across providers when an upstream has a bad hour — means changing a model identifier rather than re-plumbing the camera. Where one opinion is not enough, model fusion runs a panel of models on the same input, and the routing DSL composes several into a single call.

There is one place we can be more specific, and it is worth being honest about which way it cuts. North Micro Vision Instruct is Apache 2.0 and small enough to run on hardware you own, which means the usual argument for routing a vision model through a hosted endpoint — that you cannot self-host it — does not apply. The argument that remains is the ordinary one: a second model in the loop, on the same key, with one bill and one set of credentials.

Which to pick, and what would change the answer

Choose North Micro Vision Instruct if you are reading documents, tables, charts or screens, if you need several images in one call, if Apache 2.0 matters because you intend to host the model for other people, or if you want a 2.4B checkpoint you can fine-tune on your own data. C​ohere's model card points at fine-tuning as the intended use and the licence puts no obstacle in the way.

Choose M​oondream 3.1 9B A2B if your output is geometry — boxes, coordinates, counts with instances attached — and your deployment is a CUDA box with Photon on it. The model is specialised and its speed claim is aimed at exactly that workload.

What would change the answer for both is an independent evaluation, and that is the thing to keep watching. Neither vendor's numbers have been reproduced outside the vendor, and each has published under conditions that make reproduction harder than it needs to be: one withholds its prompts, the other ran on an internal serving implementation of a framework whose public support is still pending. When a third party runs either checkpoint on the same document set, whichever model's table survives that contact intact is the one worth believing — and until then, the vendor that told you how it measured is the easier one to argue with.

A result like this is also a reminder that model mistakes are already documented: the AI incidents and agent failures behind models in this class are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.