Best-value coding models for a team GPU pair

We own the H100 pair already, so the marginal cost of a token is electricity and my patience. That changes the question from "which model is best" to "which model produces the most useful code per unit of a fixed, already-paid-for resource." Fun per dollar, where the dollars are sunk. After a few months of rotating models under our team endpoint, here is the honest ranking.

The candidates are everything that actually fits on 2× 96 GB with room to serve a team, per the sizing math: gpt-oss-120b, Qwen3-Coder-30B-A3B, GLM-4.5-Air, Llama 3.3 70B as the dense baseline, and a Qwen3.6-27B-class dense model as the small option.

why active parameters are the whole ballgame

For team serving, the number that predicts your experience is not total parameters. It is active parameters per token, because that is what sets decode compute, which sets tokens per second, which sets how many concurrent users the box carries before the queue forms.

A dense 70B spends 70B parameters of compute on every single token. gpt-oss-120b spends 5.1B. Qwen3-Coder-30B-A3B spends 3.3B. That is roughly an order of magnitude less decode compute per token for models that, on coding tasks, are competitive with or better than the dense 70B. The MoE tax is memory, you hold all the experts even though each token visits few, and memory is exactly what a 96 GB pair has in abundance. A big-total, small-active MoE is almost a purpose-built shape for this hardware.

The dense 70B is a sports car with one seat. The MoE is a train: slower per passenger on paper, and it moves the whole team at once.

the table

Numbers approximate and from our box, single-stream decode via vLLM, FP8 or native quant, TP=2:

Those single-stream numbers understate the real gap. Under concurrent load the MoEs degrade gracefully while the dense 70B falls off a cliff, because batch capacity is bounded by the same active-parameter compute. The 30B-A3B in particular has so much batch headroom that we point our noisiest consumers at it, autocomplete, commit-message generation, overnight agent runs, and it shrugs.

agentic coding quality, honestly

gpt-oss-120b is the best all-rounder we have hosted. Solid multi-step tool use, respects diff formats, rarely wanders off into rewriting files it was not asked to touch. It became the default team-llm alias behind our vLLM endpoint and nobody has campaigned to change it.

GLM-4.5-Air punches above its throughput. It has the best agentic instincts of the group, it plans before editing, recovers from failed tool calls instead of looping, and its tool-call formatting is unusually disciplined. If our team were smaller and the box less contended, it might be the default despite being roughly half the speed of gpt-oss-120b on our hardware.

Qwen3-Coder-30B-A3B is shallower. Ask it for a focused function, a test, a refactor within one file, and it is fast and correct enough that the speed becomes the feature. Ask it to reason across a gnarly module boundary and you feel the 3.3B active parameters. Great employee, wrong meeting.

Llama 3.3 70B was our baseline and taught us what "good" felt like in 2025, and every MoE above beats it on coding while serving three to five times the traffic. It is off the box. Sentiment is not a serving strategy.

The Qwen3.6-27B-class small model is the one I keep on the Blackwell test bench and as an emergency fallback; I wrote up my long-form impressions separately. On a team pair it is not the main event, but as a second model squeezed alongside a bigger one, it earns its VRAM.

context length reality

Spec-sheet context and useful context are different numbers. All of these claim 128k or more. In practice we cap serving at 32k for capacity reasons, and honestly the models justify the cap: in our internal long-context retrieval checks, quality on all of them degrades noticeably past roughly 60k tokens of code, well before the advertised limit. Agent harnesses that summarize and re-ground beat harnesses that stuff context, on every model on this list. Buy context length with engineering, not with KV cache.

licenses matter more than you think for internal code

Everything above is permissive: Apache 2.0 for the gpt-oss and Qwen families, MIT for GLM-4.5-Air, and Llama's community license, which is fine at our scale but is a bespoke document your legal team has to actually read. This is not a box-ticking concern. These models ingest our proprietary code and emit code we ship. Permissive weights mean we can fine-tune on internal data, deploy derivatives, and never re-read a rights clause after a funding announcement. The full breakdown lives in the model licenses post, but the short version is: for internal-code use, Apache 2.0 and MIT are a quiet superpower, and "open weights" with a custom license is a meeting waiting to happen.

where we still burn API credits

The honest limitation: none of these models match frontier hosted models on hard multi-file refactors. The task shape that separates them is precise: change an interface, propagate the consequences through eleven files, keep the tests green, notice the subtle call-site that also needed updating. Our local models complete maybe two-thirds of such tasks acceptably. The frontier hosted models complete most of them, and their failures are cheaper to review. So we still hold API accounts, and the big models get invoked deliberately, for the surgeries, while local handles the endless everyday volume. Watching the ratio over months, local takes a slightly bigger share every model generation. The gap is real, and it is shrinking, and both facts belong in the same sentence.

If I had to compress this to one recommendation for a team with a pair like ours: serve gpt-oss-120b as your default, keep Qwen3-Coder-30B-A3B warm for the high-volume grunt work if you can spare the memory, and keep a frontier API key in your pocket for the refactors that would otherwise cost you an afternoon of cleanup. The best-value coding model is a routing decision.