Ollama Cloud Compute Analysis: Which Model Burns the Most?

Posted by Kris Racette on July 9, 2026 · 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. We 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 matrix you wish Ollama published is below.

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 you a small fraction of the quota of the same 1,000 tokens from a 49B active MoE model. The two biggest drivers are:

1. Active parameters per token — the number of parameters that actually fire on each forward pass
2. 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 — Active Parameters & Context

Here's the field. We've 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

Compute is half the story. The other half is: what can the model actually do? We pulled scores 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) and Terminal-Bench (81.0), plus #1 on 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.

That last row is the part most people get wrong. Gemma 4 27B dense hits a respectable 61.2% SWE-bench Verified, but the MoE variant that everyone benchmarks is 17.4%. Google chose not to feature SWE-bench in their official Gemma 4 press materials for a reason.

Compute Per Token — The Real Number

Now we get to the meat. 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	Relative 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 model, weak coder
DeepSeek V4 Flash	13B	0.27x	Sweet spot: low compute + high capability
MiniMax M3	23-26B	0.53x	Mid-tier compute
Gemma 4 27B (dense)	27B	0.55x	Dense = all params active every token
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, mid-to-heavy
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. Reasoning models emit "thinking" tokens that count toward your quota but never appear in the response. For a moderate coding task — say, 5,000 thinking tokens plus 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 coder
DeepSeek V4 Flash	0.27x	1.0x	~0.27x	✅ Strong coder
Kimi K2.7 Code	0.65x	0.7x (30% fewer)	~0.46x	✅ Strong coder
MiniMax M3	0.53x	1.0x	~0.53x	✅ Strong coder
Gemma 4 27B (dense)	0.55x	1.0x	~0.55x	⚠️ Mid-tier
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 (mode)	~0.82-1.15x	✅ Best open coder
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

This is the chart you wish Ollama published. Each model plotted by total compute per task and coding capability tier.

Tier	Low Compute (< 0.50x)	High Compute (> 0.50x)
Top-Tier Capability	DeepSeek V4 Flash (0.27x) Best value overall. 79% SWE-bench Verified at 13B active.	GLM 5.2 (0.82-1.15x) — best open-weight coder Qwen 3.7 Max (~0.65-0.82x) — proprietary DeepSeek V4 Pro (1.0x) — heaviest
Mid-Tier Capability	MiniMax M3 (0.53x) Kimi K2.7 Code (0.46x) Gemma 4 27B dense (0.55x)	Nothing occupies this space.
Low Capability	GPT-OSS 120B (0.10x) Gemma 4 26B (A4B) (0.08x)	Nothing occupies this space.

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.

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. On Ollama Cloud, where you're already on a subscription, the compute efficiency is irrelevant because the coding quality isn't good enough to replace the bigger models.

Gemma 4 27B (dense) is more interesting. Google reports 61.2% on SWE-bench Verified, which is respectable for a 27B. 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. The dense 27B is a competent mid-tier coder, but it's competing against MiniMax M3 (59% SWE-bench Pro) and DeepSeek V4 Flash (79% SWE-bench Verified), which are dramatically stronger. Gemma's advantage is that it can run locally. On Ollama Cloud, where you're paying for GPU time anyway, there's no reason to pick it over the bigger models.

Final Ranking — All Nine Models, by Value

Recommended Model Routing on Ollama Cloud

Here's the playbook we use across our 10-agent operation:

Task Type	Model	Active Params	Why
Routine agent calls (heartbeats, monitoring)	DeepSeek V4 Flash	13B	Barely dents quota, near-frontier quality
IDE execution (Cline/Codium)	Kimi K2.7 Code	32B	30% fewer thinking tokens, purpose-built
Legal/financial analysis	DeepSeek V4 Flash	13B	1M context, near-Pro quality, fraction of compute
Web/SEO content	MiniMax M3	23-26B	Native multimodal, 1M context, strong coding
Architecture & planning	GLM 5.2 (high mode)	40B	1M context, best coding benchmarks
Hard problems	GLM 5.2 (max mode)	40B	Frontier quality, accept the compute cost
When Flash can't handle it	DeepSeek V4 Pro	49B	Last resort — but Flash usually can
Local-only / no cloud	Qwen 3.6 27B (local)	27B dense	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.

1. Move all routine/monitoring work to DeepSeek V4 Flash. Could cut 30-40% of compute usage overnight.
2. Use Kimi K2.7 Code for IDE execution. Purpose-built efficiency, minimal thinking overhead.
3. Reserve GLM 5.2 for planning only. Don't waste 40B active params on heartbeats.
4. DeepSeek V4 Pro should almost never run. V4 Flash covers 96% of what Pro does at 27% of the cost.
5. GPT-OSS and Gemma are not your friends here. They're built for local hardware constraints. On Ollama Cloud, use the big models that actually solve the problem.

The Ollama Cloud pricing model is poorly understood because nobody has published the data in this format. We hope this analysis helps you route smarter. If you're building an agent operation on Ollama Cloud and want help with the architecture, get in touch — this is the kind of system we build at Executive Mind.

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 — krisracette.me | GitHub

← Back to All Articles