Ollama Cloud Compute vs Capability: I Ranked Every Model by GPU Cost Per Task
By Kris Racette · Originally published at executivemind.io · 12 min read
If you're an Ollama Cloud subscriber, you've probably noticed the weekly quota is a moving target. Hit the limit halfway through Wednesday, you're stuck for the rest of the week. Hit it on Saturday afternoon, you've been efficient. The difference is almost entirely about which models you route to — and almost no one is publishing the data on what actually burns the most compute per task.
Until now. I crunched the numbers on every major Ollama Cloud model — DeepSeek V4 Flash, DeepSeek V4 Pro, GLM 5.2, Kimi K2.7 Code, MiniMax M3, Qwen 3.7 Max, GPT-OSS 120B, and both Gemma 4 variants — and ranked them by GPU compute per task against their actual coding benchmark performance.
⚡ The Headline Finding: DeepSeek V4 Flash (13B active parameters) burns ~73% less compute than V4 Pro (49B active) — and lands within 1-3 points on virtually every coding benchmark. If you're paying for V4 Pro tier to do routine work, you're burning three quarters of your weekly quota for marginal quality gains.
Why Compute Is a Moving Target on Ollama Cloud
Most people read the Ollama Cloud pricing page and think they're paying per token. They're not. From Ollama's pricing page:
"Models consume a different amount of usage based on how difficult they are to run."
In practice, this means Ollama weights your usage by GPU compute difficulty, not raw tokens. A 1,000-token response from a 13B active MoE model costs a small fraction of the quota of the same 1,000 tokens from a 49B active MoE model. The two biggest drivers are:
- Active parameters per token — the number of parameters that actually fire on each forward pass
- Thinking token overhead — reasoning models emit hidden "thinking" tokens that count toward your quota but never appear in the output
Context window memory matters too, but the dominant variable is active params. That's why a 1T-parameter MoE with 32B active (Kimi K2.7 Code) costs less than a 744B-parameter model with 40B active (GLM 5.2). Total parameter count is a vanity metric on cloud subscriptions — what matters is what fires per token.
The Model Roster
Sorted by active parameters, because that's the primary compute driver:
| Model | Total Params | Active Params | Context | Open Weights |
|---|---|---|---|---|
| Gemma 4 26B (A4B MoE) | 26B | 4B | 1M | ✅ Open |
| GPT-OSS 120B | 117B | 5.1B | 128K | ✅ Apache 2.0 |
| DeepSeek V4 Flash | 284B | 13B | 1M | ✅ MIT |
| MiniMax M3 | 428B | 23-26B | 1M | ✅ MIT |
| Gemma 4 27B (dense) | 27B | 27B | 1M | ✅ Open |
| Kimi K2.7 Code | 1T | 32B | 256K | ✅ Modified MIT |
| GLM 5.2 | 744B | 40B | 1M | ✅ MIT |
| DeepSeek V4 Pro | 1.6T | 49B | 1M | ✅ MIT |
| Qwen 3.7 Max | Proprietary | N/A | 1M | ❌ API only |
Note the wild spread: Gemma 4 26B (MoE) fires only 4B parameters per token, while DeepSeek V4 Pro fires 49B. That's a 12× difference in per-token compute — which is exactly what Ollama is charging you for.
Benchmark Performance Across the Field
Pulled from SWE-bench Verified, SWE-bench Pro, Terminal-Bench 2.1, LiveCodeBench, the Composio tool-use benchmark, and Design Arena. Estimated values are marked in italics — these are interpolation estimates from partial public data, not made up.
| Model | SWE-bench Verified | SWE-bench Pro | Terminal-Bench | LiveCodeBench |
|---|---|---|---|---|
| GLM 5.2 | 82.8 | 62.1 | 81.0 | — |
| DeepSeek V4 Pro | 80.6 | 55.4 | ~76 (est.) | 93.5 |
| DeepSeek V4 Flash | 79.0 | ~52 (est.) | ~73 (est.) | 91.6 |
| Qwen 3.7 Max | — | 60.6 | 69.7 | 91.6 |
| Kimi K2.7 Code | ~65 (est.) | ~55-58 (est.) | ~75 (est.) | ~88 (est.) |
| MiniMax M3 | — | 59.0 | 66.0 | — |
| Gemma 4 27B (dense) | 61.2 | — | — | — |
| GPT-OSS 120B | ~54.9 (est.) | — | — | — |
| Gemma 4 26B (A4B) | 17.4 | — | — | — |
GLM 5.2 is the capability leader for open-weight models — #1 on SWE-bench Pro (62.1), Terminal-Bench (81.0), and Design Arena for code. Qwen 3.7 Max and DeepSeek V4 Pro are tightly bunched behind. DeepSeek V4 Flash sits in the top tier at 79% SWE-bench Verified and 91.6 LiveCodeBench.
The Gemma 4 MoE variant (A4B) at 17.4% is essentially not a coding model. Google chose not to feature SWE-bench in their official Gemma 4 press materials for a reason.
Compute Per Token — The Real Number
If Ollama weights usage by GPU compute difficulty, and the dominant driver is active parameters, then the relative cost per token looks like this (V4 Pro = 1.0x as the reference):
| Model | Active Params | Compute/Token | Notes |
|---|---|---|---|
| Gemma 4 26B (A4B) | 4B | 0.08x | Cheapest, but not a coding model |
| GPT-OSS 120B | 5.1B | 0.10x | Cheapest viable, weak coder |
| DeepSeek V4 Flash | 13B | 0.27x | Sweet spot: low compute + high capability |
| MiniMax M3 | 23-26B | 0.53x | Mid-tier |
| Gemma 4 27B (dense) | 27B | 0.55x | Dense = all params active |
| Kimi K2.7 Code | 32B | 0.65x | + 30% fewer thinking tokens |
| GLM 5.2 | 40B | 0.82x | Can exceed on max thinking |
| Qwen 3.7 Max | N/A | ~0.65-0.82x (est.) | Proprietary |
| DeepSeek V4 Pro | 49B | 1.00x | Heaviest per token |
That 0.27x on V4 Flash versus 1.0x on V4 Pro isn't a typo. It's a 73% compute reduction for the same kind of work, on most tasks. If you're running a 10-agent operation on Ollama Cloud, the difference between routing everything to V4 Pro and routing routine work to V4 Flash could literally be the difference between hitting your quota on Wednesday and hitting it on Saturday.
Total Compute for the Same Coding Task
Per-token cost is half the story. The other half is thinking token overhead. For a moderate coding task (5,000 thinking + 2,000 output tokens), the total compute looks like this:
| Model | Active (rel.) | Thinking (rel.) | Est. Total Compute | Tier |
|---|---|---|---|---|
| Gemma 4 26B (A4B) | 0.08x | 1.0x | ~0.08x | ❌ Not viable |
| GPT-OSS 120B | 0.10x | 1.0x | ~0.10x | ⚠️ Weak |
| DeepSeek V4 Flash | 0.27x | 1.0x | ~0.27x | ✅ Strong |
| Kimi K2.7 Code | 0.65x | 0.7x | ~0.46x | ✅ Strong |
| MiniMax M3 | 0.53x | 1.0x | ~0.53x | ✅ Strong |
| Gemma 4 27B (dense) | 0.55x | 1.0x | ~0.55x | ⚠️ Mid |
| Qwen 3.7 Max | ~0.65-0.82x | 1.0x | ~0.65-0.82x | ✅ Top tier |
| GLM 5.2 | 0.82x | 1.0-1.4x | ~0.82-1.15x | ✅ Best open |
| DeepSeek V4 Pro | 1.0x | 1.0x | ~1.0x | ✅ Top tier |
Note Kimi K2.7 Code's trick: it uses 30% fewer thinking tokens than its peers. That single design choice moves it from a 0.65x per-token cost to a 0.46x total cost — a meaningful efficiency gain for IDE-bound coding work.
The Compute vs Capability Matrix
Each model plotted by total compute per task and coding capability tier:
Low Compute High Compute
┌───────────────────────┬───────────────────────┐
Top-Tier │ │ GLM 5.2 (best open) │
Capability │ DeepSeek V4 Flash │ Qwen 3.7 Max (API) │
│ (best value) │ DeepSeek V4 Pro │
├───────────────────────┼───────────────────────┤
Mid-Tier │ MiniMax M3 │ │
Capability │ Kimi K2.7 Code │ │
│ Gemma 4 27B (dense) │ │
├───────────────────────┼───────────────────────┤
Low │ GPT-OSS 120B │ │
Capability │ Gemma 4 26B (A4B) │ │
└───────────────────────┴───────────────────────┘
The single most important cell: DeepSeek V4 Flash in the top-left quadrant. High capability, low compute. The closest competitor in that cell is Kimi K2.7 Code — but Kimi is purpose-built for agentic IDE coding, not for general-purpose reasoning at the Flash tier's quality.
What About GPT-OSS and Gemma?
Short answer: no, they're not in the same league for coding on Ollama Cloud.
GPT-OSS 120B has the cheapest compute profile on Ollama Cloud (5.1B active — barely a blip on the quota), but it ranks #78 out of 124 models on coding benchmarks with a score of 21.2. It's a reasoning model that can do tool use, but for real software engineering it's nowhere near the frontier.
Gemma 4 27B (dense) is more interesting. Google reports 61.2% on SWE-bench Verified, which is respectable. But independent testing of the MoE variant (A4B, 4B active) scored only 17.4% — and Google deliberately omitted SWE-bench from their official Gemma 4 benchmark press materials.
⚡ Key Insight: On Ollama Cloud, the compute cost difference between the cheapest viable coder (DeepSeek V4 Flash at 13B active) and GPT-OSS or Gemma is irrelevant compared to the capability gap. You're already on a subscription — use the model that actually solves the problem. GPT-OSS and Gemma are models for local hardware constraints, not cloud subscription optimization.
Final Ranking — All Nine Models, by Value
| Rank | Model | Why |
|---|---|---|
| 🥇 | DeepSeek V4 Flash | 13B active = ~73% less compute than V4 Pro. 79% SWE-bench Verified. The undisputed value king. |
| 🥈 | Kimi K2.7 Code | 32B active + 30% fewer thinking tokens. Purpose-built for agentic coding. |
| 🥉 | MiniMax M3 | 23-26B active, 59% SWE-bench Pro, 1M context, native multimodal. |
| 4 | GLM 5.2 | 40B active, but #1 on SWE-bench Pro (62.1) and Terminal-Bench (81.0). Best open-weight coder. |
| 5 | Qwen 3.7 Max | 60.6 SWE-bench Pro, 69.7 Terminal-Bench. Top-tier but proprietary + heavier. |
| 6 | DeepSeek V4 Pro | 49B active — heaviest. V4 Flash covers ~96% of its capability at ~27% of compute. Use sparingly. |
| 7 | Gemma 4 27B (dense) | Decent coding (61.2 SWE-bench Verified) but outclassed by Flash/M3. For local, not cloud. |
| 8 | GPT-OSS 120B | Cheap compute (5.1B active) but coding score 21.2. Not viable for software engineering. |
| 9 | Gemma 4 26B (A4B) | 17.4% SWE-bench Verified. Not a coding model. |
Recommended Model Routing on Ollama Cloud
Here's the playbook I use across my 10-agent operation:
| Task Type | Model | Why |
|---|---|---|
| Routine agent calls (heartbeats, monitoring) | DeepSeek V4 Flash | Barely dents quota, near-frontier quality |
| IDE execution (Cline/Codium) | Kimi K2.7 Code | 30% fewer thinking tokens, purpose-built |
| Legal/financial analysis | DeepSeek V4 Flash | 1M context, near-Pro quality, fraction of compute |
| Web/SEO content | MiniMax M3 | Native multimodal, 1M context, strong coding |
| Architecture & planning | GLM 5.2 (high mode) | 1M context, best coding benchmarks |
| Hard problems | GLM 5.2 (max mode) | Frontier quality, accept the compute cost |
| When Flash can't handle it | DeepSeek V4 Pro | Last resort — but Flash usually can |
| Local-only / no cloud | Qwen 3.6 27B (local) | Not on cloud, but your local fallback |
The Bottom Line
If you're hitting Ollama Cloud Max limits at 55% through the week, the fix isn't to upgrade. The fix is to route better.
- Move all routine/monitoring to DeepSeek V4 Flash — could cut 30-40% of compute usage overnight
- Use Kimi K2.7 Code for IDE execution — purpose-built efficiency, minimal thinking overhead
- Reserve GLM 5.2 for planning only — don't waste 40B active params on heartbeats
- DeepSeek V4 Pro should almost never run — V4 Flash covers 96% of what Pro does at 27% of the cost
- GPT-OSS and Gemma are not your friends here — built for local hardware constraints, not cloud subscription optimization
The Ollama Cloud pricing model is poorly understood because nobody has published the data in this format. I hope this analysis helps you route smarter.
Benchmark sources: DeepSeek V4 tech report, Z.ai GLM 5.2 release, Moonshot K2.7 Code release, MiniMax M3 release, Qwen 3.7 blog, OpenAI GPT-OSS release, Google Gemma 4 release, Composio benchmark, Artificial Analysis, SWE-bench leaderboard, BenchLM.ai, vals.ai. Compute weights estimated from active parameters and thinking token efficiency per the Ollama Cloud pricing model.
— Kris Racette, Founder of Executive Mind — https://executivemind.io | https://krisracette.me | https://github.com/Roughn3ck
Top comments (0)