Three open-weight models are currently fighting for the title of best coding LLM, and the fight isn't close to settled. Kimi K3 leads frontend code generation. DeepSeek V4-Pro posts the strongest LiveCodeBench score of the three. Qwen3.8-27B beats a frontier closed model on SWE-bench Pro while running on a single consumer GPU. Picking between them isn't really a quality question, it's a hardware question: one needs a multi-node cluster, one needs a single 8-GPU node, and one fits on the GPU in your desktop.
TL;DR: Best Self-Hosted LLM for Coding in 2026
| Model | Architecture | Self-host floor (INT4) | Minimum GPU tier | Standout benchmark |
|---|---|---|---|---|
| Kimi K3 | MoE | ~1,515GB | 8x B300 288GB, multi-node (no single-node option) | #1 open model, Arena.ai Frontend Code Arena |
| DeepSeek V4-Pro | MoE, 1.6T total / 49B active | ~865-871GB | Single 8x H200 141GB node | 93.5% LiveCodeBench Pass@1-COT |
| Qwen3.8-27B | Dense, 27B | ~15GB | Single RTX 4090 24GB or A100 | 61.7 SWE-bench Pro, beats Claude Opus 4.6 Max's 53.4 |
Kimi K3 needs a true multi-node cluster, DeepSeek V4-Pro fits on one 8x H200 node, and Qwen3.8-27B runs on one GPU, so the deciding factor for most teams is the hardware tier they can justify, not a single leaderboard score. Spheron's H200 GPU rental page shows the live rate for the exact node tier DeepSeek V4-Pro needs.
Why SWE-Bench Scores Alone Won't Settle This (Verified Is Retired)
If you've tried to compare these three models by SWE-bench Verified score, you've probably seen contradictory numbers depending on which source you read. That's not sloppy reporting, it's because the benchmark itself got retired. Vals AI archived SWE-bench Verified as saturated on September 1, 2026, after seven of the 86 models it had evaluated reached 95% or better, and it no longer runs the benchmark on new model releases. Ofir Press, one of the benchmark's co-creators, put it plainly on Hacker News: "SWE-bench Verified is now saturated at 93.9%... but anyone who hasn't reached that number yet still has more room for growth."
That's the real reason the numbers floating around for Kimi K3, DeepSeek V4-Pro, and Qwen3.8-27B don't line up. Some sources are citing scores from before saturation, some are citing different sub-benchmarks entirely, and none of them are comparing apples to apples anymore. SWE-bench Pro and LiveCodeBench are where the real separation shows up now.
Kimi K3: #1 Open Model on Frontend Code Arena
Kimi K3 is the first open-weight model to top Arena.ai's Frontend Code Arena, a head-to-head leaderboard specifically for frontend code generation. That's a narrower claim than "best coding model," but it's a real one: frontend work (component generation, CSS layout, interactive UI) is a different skill from backend algorithm work, and K3 is the first model without a closed license to lead it.
DeepSeek V4-Pro: 93.5% on LiveCodeBench Pass@1-COT
DeepSeek V4-Pro scores 93.5% on LiveCodeBench Pass@1-COT. LiveCodeBench pulls from live competitive programming problems rather than a fixed historical set, which makes it harder to game than an older, frozen benchmark, and it's a big part of why V4-Pro's score is notable.
Qwen3.8-27B: Beats Claude Opus 4.6 Max on SWE-bench Pro
Qwen3.8-27B is the outlier on this list: a dense 27B model (no mixture-of-experts routing at all) that scores 61.7 on SWE-bench Pro and 90.3 on LiveCodeBench v6. The SWE-bench Pro number is the one worth sitting with: it's ahead of Claude Opus 4.6 Max's 53.4 on the same test, even though the two were scored under different harnesses, so the exact gap should be read as approximate rather than exact. A 27B dense model beating a frontier closed model on any agentic coding benchmark, even approximately, is the kind of result that changes which GPU tier is worth considering.
GPU Requirements: K3's Multi-Node Cluster vs V4-Pro's Single 8x H200 Node vs Qwen3.8-27B's Single GPU
This is where the decision actually gets made for most teams. Benchmark scores tell you what a model can do; GPU requirements tell you what it costs you to find out. Our VRAM tier guide for self-hosting open-source LLMs walks through this math in more depth if you're sizing a GPU for a model outside these three.
To check these cluster claims against something other than a single vendor's spec sheet, we ran each model's published checkpoint size through Spheron's own GPU recommender tool rather than taking one source's word for the hardware floor. Feeding in Kimi K3 returned an 8x B300 288GB floor with explicit no-single-node language attached; DeepSeek V4-Pro returned a clean fit on a single 8x H200 141GB node; Qwen3.8-27B returned a single RTX 4090 24GB as the cheapest viable GPU. All three matched the figures below (each one links to the recommender's own result page), which is the kind of cross-check worth running yourself before committing budget to any of these tiers.
Kimi K3: ~1,515GB at INT4, No Single-Node Option
Even at INT4, the most aggressive quantization tier that still ships production checkpoints, Kimi K3 needs roughly 1,515GB of VRAM. Spheron's GPU recommender lands on an 8x B300 288GB configuration as the cheapest fit, starting from $5.84/hr per GPU on spot, but it explicitly notes there's no single-node option: the 8-GPU total has to be assembled across multiple physical nodes rather than booked as one unit. That's a genuine multi-node cluster commitment, not a single large server. An 8-GPU spot total comes out to roughly $46.72/hr, and spot capacity on B300 can be reclaimed without notice, so treat that figure as a floor, not a guaranteed rate.
DeepSeek V4-Pro: 1.6T Total / 49B Active, Fits One 8x H200 Node
DeepSeek V4-Pro's native FP4/FP8 checkpoint runs about 865GB, fitting one 8x H200 141GB node (1,128GB total); it does not fit on 8x H100 (640GB). That's the practical dividing line: if your cluster is built on H100s, V4-Pro doesn't fit no matter how you quantize within that checkpoint format; if it's H200s, one node is enough. On Spheron, an 8x H200 node runs from $38.40/hr total on-demand ($4.80/hr per GPU), which is the realistic entry cost for running V4-Pro yourself rather than through an API.
Qwen3.8-27B: Dense 27B, Fits a Single A100 or RTX 4090
Qwen3.8-27B is a dense (non-MoE) model, so its full weights must be held and computed on every forward pass, which is exactly what keeps its footprint small and predictable: there's no expert-routing overhead to size around. At INT4, its footprint is around 15GB, comfortably inside a single RTX 4090 24GB (from $0.72/hr on Spheron) or a single A100 (from $1.48/hr) with headroom left for KV cache. For teams whose bottleneck is a GPU budget, not a benchmark score, this is the only one of the three that doesn't require a cluster conversation.
Pricing fluctuates based on GPU availability. Spheron rates above are live as of 17 Sep 2026; other providers reflect their most recent published rates and may have changed. Check current GPU pricing → for live rates.
Cost Per Token for Agentic Coding Workloads
Dollars per GPU-hour don't mean much without knowing how much code you're actually running through the model, and agentic coding workloads burn tokens fast: every tool call, every file read, every retry is a separate LLM call, not just the visible chat turn.
Qwen3.8-27B is the cleanest case study here because it's the only one of the three cheap enough to run the math on a single GPU. According to Akash Network's cost comparison, an always-on H100 serving Qwen3.8-27B in FP8 runs about $1,469 a month, and the break-even point against a managed API lands around 460 million output tokens a month. Below that volume, the API is cheaper; above it, self-hosting wins. Those figures are Akash Network's own calculation as of its publication date and will move with GPU and token pricing, so treat them as a shape of the math rather than a number to lock in: run the same volume math against your own team's actual call count before assuming self-hosting saves money.
DeepSeek V4-Pro and Kimi K3 don't have an equivalent single-GPU cost case, because their fixed floor is a full node or cluster rather than one card. The same logic still applies, just at a much higher break-even: an 8-GPU node is only worth running once your team's coding-agent token volume clears that node's fixed monthly cost, which is why most teams evaluating V4-Pro or K3 start with the managed API and only move to self-hosting once usage is predictable. Our breakdowns of Kimi API pricing against self-hosting and DeepSeek API pricing against self-hosting walk through that specific crossover in more detail.
The Best Self-Hosted LLM for Coding by Team Size
Solo Developer or Small Team: Qwen3.8-27B on One GPU
If you're a solo developer, a small team, or you just want a coding model that doesn't phone home, Qwen3.8-27B is the only one of the three that makes sense to self-host at small scale. One RTX 4090 or A100 is enough, there's no cluster orchestration to manage, and its SWE-bench Pro score genuinely competes with frontier closed models rather than being a budget compromise. If your monthly output token volume is well under the few-hundred-million range, though, run the break-even math first: a managed API might still be cheaper than paying for a GPU to sit mostly idle.
Platform Team Serving Many Developers: DeepSeek V4-Pro on One Node
A platform or infrastructure team provisioning a coding assistant for an entire engineering org has the volume to justify DeepSeek V4-Pro's single 8x H200 node. It's still a serious hardware commitment, but it's a single, bookable unit rather than a multi-node build-out, and its LiveCodeBench lead gives it a real claim on raw coding capability rather than just "good enough at scale." Our guide to GPU sizing for AI agent infrastructure covers the general version of this node-vs-API sizing decision for teams past the single-GPU stage.
Quality-First, Cluster-Ready: Kimi K3
If frontend-heavy coding quality is the priority and you already operate multi-node GPU infrastructure, or you're willing to build it, Kimi K3's Frontend Code Arena lead is the strongest reason to take on its multi-node footprint. For most teams evaluating K3 for the first time, though, a managed API is the more sensible starting point: committing to an 8x B300 cluster with no single-node option is a reserved-capacity, high-spend decision, not something to test casually before you know the model actually fits your workflow.
Deployment Notes for Each Model
Kimi K3: vLLM/SGLang Expert Parallelism, Quantization Options
As a large MoE model, Kimi K3 is built to be served with expert parallelism rather than naive tensor parallelism, splitting experts across GPUs so each device only holds and computes the experts it's routing to. Both vLLM and SGLang support expert-parallel serving for large MoE checkpoints, and INT4 quantization is what gets the footprint down to the ~1,515GB figure that makes an 8-GPU cluster feasible at all; running it at full precision would push the requirement well past what any reasonable cluster size could hold.
DeepSeek V4-Pro: FP4/FP8 Native Checkpoint, Tensor and Expert Parallel
V4-Pro ships with a native FP4/FP8 checkpoint rather than requiring post-hoc quantization, which is part of why its ~865-871GB footprint fits cleanly inside an 8x H200 node. In practice that means combining tensor parallelism across the 8 GPUs with expert parallelism for the MoE layers, the same general pattern covered in our guide to deploying Qwen3-Coder-Next, a smaller 80B MoE coding model that uses the same serving approach at a fraction of the hardware. If your team is choosing between V4-Pro and a smaller MoE coder, that post is a useful contrast point on what you give up by going smaller.
Qwen3.8-27B: Single-GPU vLLM Serving, No Cluster Orchestration Needed
Because Qwen3.8-27B is dense, serving it is the simplest of the three by a wide margin: a standard vLLM deployment on a single GPU, no expert routing, no multi-GPU parallelism strategy to tune. That simplicity is itself a reason to pick it when your team doesn't have in-house MoE serving experience yet. Our H100 vs A100 cost guide is worth reading before deciding which single-GPU tier to rent, since A100 and H100 land at very different price points for a model that doesn't need H100-class compute to run well.
If you're also evaluating DeepSeek's reasoning-focused sibling model rather than its coding-tuned release, see our guide to deploying DeepSeek R2 for how that comparison plays out, and our writeup on GPU infrastructure behind commercial coding tools for how Cursor, Claude Code, and GitHub Copilot size the infrastructure behind the coding assistants most teams are comparing self-hosting against.
IDE Integration and Licensing: What Actually Changes Once You Self-Host
Wiring any of these three into an IDE isn't model-specific work. vLLM and SGLang both expose an OpenAI-compatible endpoint, and that's what Cursor's custom model setting, Continue.dev, and Cline all talk to, so the integration step is identical whether you're pointing at Qwen3.8-27B on one GPU or DeepSeek V4-Pro on a full node. What actually changes between them is the latency and concurrency your hardware tier can sustain under real agentic usage, not the shape of the API call.
Licensing is the one place these three genuinely diverge, and it's worth checking before you commit engineering time to any of them. DeepSeek V4-Pro ships under an MIT license, which is about as unrestricted as it gets for commercial use. Kimi K3 is open-weight with no closed license gating access to it, but the exact terms (and any usage caps) are worth reading on the model's own published card rather than assumed from its MoE sibling models. Qwen3.8-27B's license terms are also worth confirming directly on its model card before you build a commercial coding product on top of it rather than assumed from an earlier Qwen release.
None of this is a one-size answer, and that's the point: the right model is the one whose hardware tier matches what your team is actually willing to provision, not whichever one happens to lead this month's leaderboard.
Whichever tier you land on, Spheron's GPU recommender maps Kimi K3, DeepSeek V4-Pro, and Qwen3.8-27B to the exact GPU count and live rate each one needs, from a single RTX 4090 up to a full B300 cluster.
Frequently Asked Questions
There's no single winner, because the three leading open coding models each win a different benchmark. DeepSeek V4-Pro posts 93.5% on LiveCodeBench Pass@1-COT as of its April 2026 release. Kimi K3 is the first open-weight model to rank #1 on Arena.ai's Frontend Code Arena. Qwen3.8-27B scores 61.7 on SWE-bench Pro, ahead of Claude Opus 4.6 Max's 53.4 on the same test (the two were scored under different harnesses, so treat the gap as approximate). The model that's best for you depends on which benchmark matches your actual workload and which GPU tier you can afford to run.
Qwen3.8-27B is the only one of the three built for single-GPU use. It's a dense 27B model, not a mixture-of-experts model, and its INT4 footprint is roughly 15GB, small enough for a single RTX 4090 24GB or a single A100. Kimi K3 and DeepSeek V4-Pro are both massive MoE models that need an 8-GPU node or cluster even at INT4 quantization, so they aren't realistic single-GPU options.
Yes, if you pick Qwen3.8-27B. At INT4 quantization its roughly 15GB footprint fits consumer and prosumer cards like the RTX 4090. DeepSeek V4-Pro needs a full 8x H200 141GB node (roughly 865-871GB at INT4), and Kimi K3 needs an 8x B300 288GB configuration that Spheron's recommender notes has no single-node option, meaning it spans multiple physical nodes. Those two are cluster-tier deployments, not a desk-side setup.
Vals AI retired SWE-bench Verified from its leaderboard on September 1, 2026, after seven of the 86 models it had evaluated scored 95% or higher, officially declaring the benchmark saturated. Once a benchmark is saturated, small differences at the top stop reflecting real capability gaps, and different outlets kept citing different pre-saturation scores for the same models, which is why Kimi K3, DeepSeek V4-Pro, and Qwen3.8-27B each show wildly different SWE-bench Verified numbers depending on the source. SWE-bench Pro and LiveCodeBench are now the more trustworthy points of comparison.
For Qwen3.8-27B, keeping a single H100 running FP8 inference costs about $1,469 a month, and that only beats a managed API once you're pushing roughly 460 million output tokens a month through it, according to Akash Network's cost-per-token comparison. Below that volume, a managed API is cheaper. DeepSeek V4-Pro and Kimi K3 need an 8-GPU node or cluster, so their fixed monthly floor is far higher, and the same volume math applies: self-hosting only pays off once your team's token volume clears the fixed cost of the hardware.
