MiniMax vs Qwen: Open-Weights Coding Compared

The most interesting fight in open-weight coding right now is not about who has more parameters — it is about how those parameters get spent. MiniMax M2.7 is a sparse mixture-of-experts model that activates only a slice of its weights for each token. Qwen3.5 27B is Alibaba’s dense workhorse, every parameter on duty for every token. Both publish open weights, both serve at FP8 in the arena, and you can watch them trade blows in real time: MiniMax M2.7 vs Qwen3.5 27B.

Open-model face-offs usually fall apart on serving details: one side runs full precision on the vendor’s rig while the other circulates as a community quant of unknown quality. Not here. Both models run at FP8 through the same routing, so the votes measure the models themselves rather than whoever got the kinder quantization.

Sparse vs dense: where the parameters go

MiniMax’s bet with the M2 line has always been routing: keep a large total pool of experts, touch only a few per token, and get big-model breadth at mid-size latency. M2.7 is the latest refinement of that recipe, tuned hard for coding and agentic tool use. Qwen3.5 27B takes the opposite bet — 27B dense is about the largest size an individual or small team can realistically own, so Alibaba packs it with as much coding ability as the architecture allows and ships weights you can pull tonight.

• MiniMax M2.7 — MoE: large total capacity, small active slice per token, throughput-friendly serving.
• Qwen3.5 27B — dense: predictable full-capacity compute on every token, in a size one GPU can hold.
• Both ship open weights, so neither choice locks you in if pricing, policy, or your stack changes.

Spec sheet

These are the facts that stay put. Deliberately missing: any performance claim, because that part is decided live by voters rather than by a launch post.

What the arena actually measures

Every matchup on this site is community-voted, one-shot, and live. Two models get the same coding prompt, each produces a single attempt, and voters judge the working output blind — no retries, no cherry-picked demos, no vendor-run harness. Because the standings move with every vote, this article quotes no scores on purpose: the current numbers live on the leaderboard, and the fastest way to form your own view is to open the arena and judge a few rounds yourself.

The self-host math

This is where MoE cuts both ways. Because M2.7 activates only a few experts per token, its tokens-per-second-per-dollar story is excellent — but every expert still has to sit in memory, so the VRAM bill is set by total parameters, not active ones. That pushes serious M2.7 self-hosting toward multi-GPU nodes, with hosted endpoints as the pragmatic default. Qwen3.5 27B flips the equation: at FP8 the weights come to roughly 27 GB, which fits a single 48 GB professional card with room for KV cache, or a pair of 24 GB consumer cards.

• One workstation GPU and strict data residency: Qwen3.5 27B is the realistic self-host pick.
• A proper multi-GPU node — or comfort with hosted APIs — plus heavy parallel agent traffic: M2.7’s MoE throughput starts paying for itself.
• Open weights on both sides mean you can change strategy later without rewriting your stack.

Sparse models make tokens cheap and memory expensive. Dense models flip the bill. Pick the invoice you would rather pay.

How to call it

Not from this page. Watch the live votes, then weigh them against your own deployment reality: if your constraint is a single GPU and full data control, the dense 27B story is hard to beat; if your constraint is serving throughput for swarms of coding agents, sparse routing earns its complexity. For the wider field beyond these two — open and closed alike — the best AI for coding guide maps the whole board. This particular matchup, though, is still being decided one community vote at a time.