Pick a self-hosted coding model in 2026: Qwen3-Coder vs GLM vs Kimi vs DeepSeek

What you need to know

Two years ago, running your own coding model was a compromise you made for privacy and then quietly regretted every time the completions came back wrong. As of July 2026, that has changed. A cluster of open-weight models has crossed the threshold where a team can serve them in-house and get genuinely useful engineering help — not just autocomplete, but multi-file refactors, agentic task loops and long-running builds. The question is no longer whether you can self-host; it is which model, on what hardware, and whether the sums actually work out in your favour.

This guide is written for two kinds of team. The first is a Pune product company with a 2×48GB GPU pair sitting in a rack, wondering whether it can retire part of its API bill. The second is a London studio whose lead engineer has an Apple M4 Max with 128GB of unified memory and wants a private coding model that never sends a line of proprietary source to a third party. Both are viable in 2026, and both need the same three decisions made in order: pick the model that fits the hardware, serve it properly, and check the break-even before you celebrate. A short word of caution up front — every benchmark number below is reported, gathered as of July 2026, and coding leaderboards move quickly and rarely match your own repository. Treat the figures as a starting shortlist, then re-benchmark on your own tasks before you commit a team to anything.

The 2026 open-weight coding landscape

The open-weight field has stratified into a handful of models that each own a niche. Rather than one winner, you are choosing the model whose strengths line up with your workload and, more prosaically, whose weights fit in the memory you actually have. Here is the shape of the field as of July 2026.

At the top of the self-hostable pile, on one reported aggregate coding score, sits GLM-5.2 at roughly 51.1 — noticeably ahead of a tightly packed cluster around 42 to 44 that includes MiniMax M3, DeepSeek-V4-Pro, Kimi K2.6 and K2.7, and MiMo-V2.5-Pro. GLM-5.2 has a reputation for long-running engineering agents: the kind of task where the model plans, edits several files, runs tests and iterates without a human in the loop for minutes at a stretch. DeepSeek-V4-Pro is the cost-efficient frontier-reasoning option, strong on hard algorithmic problems for the compute it uses. MiniMax M3 optimises for low cost and high throughput, which matters when many developers hit the same box at once. Kimi K2.6 leans into multimodal and multi-agent work. And Qwen3-Coder is the model most teams will actually reach for locally, because it was built to be self-hosted and is available in sizes that map cleanly onto real hardware.

A word on that top score. GLM-5.2 leading at 51.1 while the rest cluster in the low-to-mid 40s sounds decisive, but the gap between second and fifth place is small enough that on your specific stack — your language, your framework, your house style — the ordering can easily flip. A model that tops an aggregate of public benchmarks may still trail on your Django monolith or your Rust service, and vice versa. The leaderboard is a filter for the shortlist, not the decision.

The single-GPU case: when Qwen is the answer

If you have exactly one GPU — a 24GB consumer card in a workstation, say, which describes a great many small teams in Bengaluru and Bristol alike — the decision is simpler than the landscape table suggests. A Qwen2.5-Coder or Qwen3-Coder sized to your VRAM is the strongest general pick, full stop. It was designed for exactly this constraint, the tooling around it is mature, and the quantised variants degrade gracefully. Two models sit close enough to be worth trialling as alternatives: Codestral 22B, which is a strong general coder that fits comfortably on a 24GB card, and DeepSeek-Coder-V2 16B, which is lighter still and leaves headroom for a longer context window.

The newer Qwen3-Coder-Next is worth understanding because its architecture is the template for where local coding models are heading. It is a mixture-of-experts model with roughly 80B total parameters but only about 3B active per token — an 80B-A3B design. In plain terms, it holds the knowledge of a large model but only lights up a small slice of it for any given token, which keeps inference fast and memory pressure lower than a dense 80B would imply. That is precisely the trick that makes a genuinely capable coding model fit on hardware a small team can afford, and it is why the MoE models dominate this year's self-hosting conversation.

Hardware sizing: matching VRAM to model

Here is the decision most teams get wrong by guessing. The honest threshold, as of July 2026, is this: self-hosted and genuinely good at code starts at around 96 to 128GB of unified or GPU memory. Below that you can still run something useful, but you are making trade-offs; at or above it, the flagship open-weight models are within reach. The sweet spot is real and specific: Qwen3-Coder 80B-A3B, Devstral-2 123B and MiniMax M3 all fit a single Apple M4 Max with 128GB, or a 2×48GB GPU pair. That is the London studio's laptop and the Pune team's rack described in one sentence — and it is not a coincidence that the two most common serious self-hosting setups land on the same class of model.

One architectural note that changes what you should buy: decode speed on these models is bound by memory bandwidth and capacity far more than by raw compute. When the model is generating tokens one at a time, it streams the active weights through memory on every step, so the width of that memory pipe sets your tokens-per-second. This is exactly why Apple silicon with wide unified memory punches above its FLOPS on decode, and why a bandwidth-starved card with plenty of compute can still feel slow. Size for memory first.

Notice where the flagship leader, GLM-5.2, sits: at the bottom of the table, in the multi-node tier, at full precision. That is the tension every self-hosting decision runs into. The model that tops the reported leaderboard is also the one whose full-precision hardware bill is hardest to justify against a hosted API. Most teams will be happier one rung up, running Qwen3-Coder 80B-A3B or Devstral-2 on the 128GB tier, and reserving the flagship for a quantised deployment or a genuine data-residency requirement. For the full serving-throughput picture — batching, prefill and decode splits, quantisation trade-offs — our companion guide on how to self-host open LLMs with vLLM for throughput and latency goes deeper than there is room for here.

Serving it: vLLM in one command

Once the model is chosen, serving is the least fiddly part of the job in 2026. vLLM and SGLang are the standard servers; both handle continuous batching, paged attention and an OpenAI-compatible API out of the box, which is what makes the agent wiring in the next section trivial. The choice between them is largely down to which one your team already knows — for most people vLLM is the default because of its documentation and community. Quantisation formats — GGUF, AWQ, FP8 — are the lever you pull to trade a little quality for a lot of VRAM headroom, and at scale the prefill and decode split becomes something you tune deliberately rather than accept.

Here is a minimal vLLM command that serves Qwen3-Coder with an OpenAI-compatible endpoint on port 8000, tensor-parallel across a 2×48GB pair, in FP8 to fit comfortably with room for context. Adapt the model tag and parallel size to your own box.

# Serve Qwen3-Coder with vLLM — OpenAI-compatible endpoint on :8000
# Tensor-parallel across a 2x48GB GPU pair, FP8 to leave context headroom.
vllm serve Qwen/Qwen3-Coder-80B-A3B \
  --tensor-parallel-size 2 \
  --quantization fp8 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --served-model-name qwen3-coder \
  --host 0.0.0.0 \
  --port 8000

# On an Apple M4 Max (128GB) you would instead reach for an
# MLX or llama.cpp server; vLLM targets NVIDIA/AMD GPUs.

Wiring the endpoint into a coding agent

The reason the OpenAI-compatible endpoint matters is that almost every coding agent and IDE extension in 2026 can be pointed at a custom provider by overriding one thing: the base_url. Instead of talking to a cloud API, the client talks to your box. The served model name you set with --served-model-name becomes the model identifier the client requests, and most clients require some API key string even when the server ignores it, so you pass a placeholder.

Here is the wiring in Python against the OpenAI SDK, which is the same shape most agent frameworks and editor plugins use under the hood. Swap the base_url for your server's address and the rest is unchanged from a normal cloud call.

from openai import OpenAI

# Point the standard OpenAI client at your own vLLM server.
client = OpenAI(
    base_url="http://localhost:8000/v1",   # your self-hosted endpoint
    api_key="not-needed-locally",          # placeholder; vLLM ignores it
)

resp = client.chat.completions.create(
    model="qwen3-coder",                   # matches --served-model-name
    messages=[
        {"role": "system", "content": "You are a senior engineer. Return a unified diff."},
        {"role": "user", "content": "Add retry-with-backoff to fetch_invoice() in billing.py"},
    ],
    stream=True,
)

for chunk in resp:
    delta = chunk.choices[0].delta.content or ""
    print(delta, end="", flush=True)

For most editor-based agents the equivalent is three settings fields: a base URL of http://your-box:8000/v1, a placeholder API key and the model name qwen3-coder. From the agent's point of view nothing else changes — it still sends the same tool-calling and diff-formatted requests. If you are choosing between agent front-ends to sit on top of this, our comparison of Claude Code vs Cursor vs Codex covers which ones support a custom OpenAI-compatible provider cleanly, and for a lighter-weight local setup the guide to building a local AI agent with Ollama, MCP and a small model shows the same pattern at the low end.

Licensing: read the model card before you deploy

Permissive licensing is one of the quiet reasons self-hosting became viable in 2026, but it is also where teams get caught out by assuming rather than reading. As of July 2026 the headline positions are clean: GLM-5.x, Kimi K2.x and DeepSeek-V4 ship under the MIT licence, while Qwen3-Coder and Devstral-2 ship under Apache 2.0. Both licences permit commercial use, modification and redistribution, and Apache 2.0 additionally carries an explicit patent grant, which some legal teams in the UK and India prefer for exactly that reason.

The caveat is that the model licence and any accompanying usage policy are two different documents, and a permissive weights licence does not automatically clear every downstream use. Before you deploy anything into a product, read the actual model card on Hugging Face for the specific release you are pulling, because per-release terms occasionally add conditions the headline licence does not. Cross-check the primary source — the Hugging Face model card — rather than a summary in a blog post, including this one. Frontier open-weight releases change fast, and the card is the only authoritative record of what you are actually allowed to do.

The cost question: when self-hosting actually pays

This is the part that decides whether the whole exercise was worth it, and the honest answer is that self-hosting only wins above a volume threshold. A hosted API has zero fixed cost and charges purely per token, so it is unbeatable for light, spiky or exploratory usage — a two-person team doing a few hundred completions a day should almost certainly stay on an API. Self-hosting flips the economics: you take on a fixed cost, whether that is the amortised price of an owned 2×48GB box or the hourly rate of a GPU instance in AWS Mumbai or London, and that cost is the same whether the model serves one request or a million. It only pays off once your steady-state throughput is high enough to keep the hardware genuinely busy.

The break-even calculation is simple enough to do on the back of an envelope. Take your fixed monthly cost — cloud GPU hours or the amortised hardware plus power and cooling — and divide it by the tokens your team actually pushes through the model in a month. That gives you a pence-per-token figure for self-hosting, which you compare directly against the API's published per-token price. Below the crossover, the API is cheaper and simpler; above it, the fixed box wins and keeps winning as volume grows, because your marginal cost per token is effectively zero. A studio running a handful of developers occasionally will sit well below the line; a product team with a dozen engineers plus CI-driven agentic workloads hammering the model all day can sit well above it.

Two things push the decision towards self-hosting below the pure financial break-even. The first is data residency and privacy: if your source code or customer data cannot legally or contractually leave your infrastructure, a self-hosted model in your own region is worth paying a premium for, and the DPDP-conscious Indian market and GDPR-conscious UK market both raise this often. The second is latency and control: a warm local endpoint has no cross-continent round-trip and no rate limits you did not set yourself. Neither shows up in a naive tokens-per-pence sum, but both are real value. For a concrete sense of how a specific open-weight flagship stacked up on a public coding benchmark, our news write-up on DeepSeek-V4's open-weight LiveCodeBench result is a useful data point to weigh alongside your own numbers.

Putting it together

The self-hosted coding decision in 2026 comes down to three honest questions asked in order. What memory do you actually have — because that, not the leaderboard, sets your shortlist? On a single 24GB card the answer is a quantised Qwen3-Coder; at the 128GB tier of an M4 Max or a 2×48GB pair the flagship-adjacent models open up. Can you serve it cleanly — which vLLM or SGLang make almost trivial, with an OpenAI-compatible endpoint your agent plugs into by changing one URL? And does the arithmetic work — because self-hosting only beats an API above a real volume threshold, with data residency and control as the tie-breakers that can tip a close call. Pick for the hardware, serve it safely, re-benchmark on your own repositories rather than trusting any reported number including the ones here, and check the break-even before you buy the GPUs. Do that and a private, capable coding model is no longer a compromise — it is just a good engineering decision.