DeepSeek vs Qwen for local coding: VRAM, licences and what actually runs
Both families ship open weights. The decision is less about benchmarks and more about which size class fits your GPU, your licence review and your latency budget.
If you are running a coding model on your own hardware, the shortlist usually collapses to two families: DeepSeek and Qwen. Both publish weights. Both are strong at code. The choice is decided by VRAM, licence terms and how much context you actually need — in that order.
Size classes first
Local coding quality is dominated by parameter count and quantisation, not by which family logo is on the model card. A useful mental model for a single workstation:
| Target | Realistic setup | What to expect |
|---|---|---|
| 7–9B, 4-bit | 8 GB VRAM | Autocomplete, small edits, fast iteration |
| 14–32B, 4-bit | 24 GB VRAM | Multi-file edits, decent instruction following |
| 70B class, 4-bit | 48 GB+ or multi-GPU | Repo-level reasoning, slower loops |
| MoE flagships | 2×80 GB or hosted | Best quality, needs serving infrastructure |
Qwen's advantage here is breadth: there is a Qwen variant in nearly every size class, including small models that fit laptops. DeepSeek's open releases concentrate on larger architectures plus distilled variants that inherit behaviour from the big model. If your constraint is "must run on the machine I already own", Qwen usually has a better-fitting option.
Quantisation is not free
4-bit quantisation costs you instruction-following reliability before it costs you coding knowledge. On a 30-step agent task, that shows up as skipped test runs and silently malformed patches. If you are quantising for memory, budget for a lower step count and more human review, and test with your own harness rather than a generic benchmark.
KV cache is the other half of the VRAM story. Long context is expensive in a way parameter count is not: a 128k-token session can consume more memory than the weights at aggressive batch sizes. Serve with a paged-attention backend (vLLM or SGLang) and cap context explicitly instead of letting the client ask for the maximum.
Licence reality
- Qwen: most open releases are Apache 2.0. That is the simplest case for commercial redistribution and internal compliance review.
- DeepSeek: flagship open weights have been released under MIT. Distilled and derivative releases have their own terms — check each model card rather than the family.
- Both: a hosted API tier exists alongside the weights. Using the API does not grant you the weights, and downloading the weights does not give you the hosted model's exact behaviour.
This is a summary, not legal advice. Our longer licence breakdown covers the custom-licence families (GLM, Kimi) that need more attention.
Latency, not just throughput
A local 32B model on a single 4090 generates slower than a hosted flagship. For interactive coding that is usually acceptable — you are reading while it writes. For agent loops it compounds: thirty steps at 20 tokens/second is a different working day than thirty steps at 80.
If your workload is agentic, price the hosted option before you buy hardware. At current Chinese-model API prices, a heavy agent user often spends less per month on tokens than on the electricity and depreciation of a workstation that can run the same quality.
How we would decide
- Measure your real context requirement. Most coding sessions need far less than the maximum.
- Pick the largest model that fits in memory after KV cache, not before.
- Serve it with vLLM or SGLang, cap context, enable prefix caching.
- Run ten tasks from your own backlog. If it does not beat your hosted baseline on cost per completed task, stop.
Both families are listed with live pricing in the Model Square, and the deployment steps are in our Qwen local guide.
Every number on this site comes from the live catalogue, not a static table.