Two bills, two meters
Someone provisions a single H100 SXM to host DeepSeek V4 Pro because it only activates 49B parameters per token, roughly the compute footprint of a mid-size dense model. The job never loads. V4 Pro carries 1.6 trillion total parameters, and at FP8 (roughly 1.1GB per billion params) that’s on the order of 1.7TB before you add KV cache headroom. One GPU, or four, was never going to hold it. The activation count told the truth about compute and lied by omission about memory.
That’s the whole trap with sparse MoE models: two separate resources, billed by two separate numbers. Total parameters determine how much VRAM you need to even load the weights. Active parameters determine how much math runs per token, which drives throughput and, downstream, your compute cost per million tokens. Dense models collapse these into one number because total equals active. Every serious open model released in the last year doesn’t.
What V4 Pro costs to host
Run the math on DeepSeek V4 Pro: 1.6T params at FP8 is around 1.76TB, plus 25% KV headroom pushes you past 2.2TB. That rules out anything short of a multi-GPU cluster built on H200 or B200, and you’re buying that whole cluster’s memory whether you send it one request a minute or ten thousand.
Compare DeepSeek V4 Flash: 284B total, 13B active. Memory footprint lands around 390GB with headroom, small enough to fit comfortably in a node most providers already run. Compute-wise it behaves like a 13B model per token. Cheap to load, cheap to run, which is exactly why it’s priced that way on the API. V4 Pro isn’t cheap to load even though its per-token compute is similarly modest.
Why the API is cheap anyway
Providers hosting a model like V4 Pro or Kimi K2.6 amortize that huge memory bill across enormous concurrent traffic. The cluster’s fixed cost gets divided by however many tokens flow through it in a day. Your compute bill as a customer tracks active params because that’s the marginal cost of serving you one more token on hardware someone else already paid to fill with weights. You never see the memory bill directly. You only see the throughput it enables.
That’s also why the provider spread on any given model runs wide even for a “cheap” MoE. As of this writing, Qwen3-235B-A22B shows a provider price spread north of 20x on this site’s live tracker, same weights, wildly different economics depending on how well each provider batches requests against that fixed memory cost. Check the spread on the model page before assuming any single quoted rate reflects what the model actually costs to run.
The A3B workhorse
Self-hosting changes the calculus completely, because you’re paying the memory bill upfront regardless of traffic. This is where the A3B class wins outright. Qwen3-30B-A3B needs about 21GB at INT4, fitting with headroom on a single 24GB card like an L4 or A10. GPT-OSS-20B is similar: 21B total, 3.6B active, comparable footprint. Compute-wise both run like a 3-4B dense model per token, so throughput on modest hardware beats anything a dense 70B could ever hit on the same card, because a dense 70B has to run all 70B params on every single token whether the prompt needs that depth or not.
The dense 70B era made sense when sparse routing wasn’t mature enough to hold quality at low active-param counts. That’s no longer the constraint. If you’re speccing local inference today, an A3B-class model on a single RTX 4090 or L4 will out-throughput a dense 70B on the same card and use a fraction of the VRAM doing it.
The crossover trap
Bigger total params doesn’t always mean worse self-hosting economics, and this is where the intuition breaks. MiniMax M2 runs 229B total against 10B active. GLM-4.5 Air runs 106B total against 12B active. Air has the smaller memory bill: it fits on less hardware. M2 has the smaller compute bill: fewer active params burned per token once that hardware is loaded.
At low request volume, Air wins, because you’re not using enough of M2’s larger cluster to justify buying it. At high sustained volume, M2 can win, because its lower active-param compute processes more tokens per second across whatever hardware you already paid to fill with its memory footprint. The model with more total parameters is not automatically the more expensive one to self-host. It depends on how much of the memory you paid for you’re keeping busy.
What to check before you provision
Compute the FP8 footprint for total params plus 25% KV headroom, find the cheapest fit on /gpus, and separately check active params against your expected concurrency. If active params sit under roughly 5B, you’re VRAM-bound and should prioritize the smallest cluster that fits, cheaper tiers included, since H200 NVL and MI300X both list community and marketplace prices well under their secure-tier rate. If active params climb past 15-20B, you’re compute-bound, and the deciding factor becomes tokens/sec per dollar on that cluster, not the sticker price of the memory. Run both scenarios through the calculator with your real request volume before you sign a GPU contract, because the model page alone won’t tell you which meter you’re going to be billed against.