Qwen3.8-2.4T-A95B: the VRAM math behind a trillion-plus-parameter MoE

Published 2026-08-28
Trillion-param MoE VRAM math priced daily on llmhosting.ai

The only price this model has right now

Qwen3.8-2.4T-A95B is trending on Hugging Face at 2.4 trillion total parameters and roughly 95B active per token. As of this writing, no inference provider has listed a price for it. This isn’t a gap in the site’s index: the model exists as open weights, with no hosted endpoint behind it yet. Until a provider ships one, the only number you can compute is what it costs you to run yourself.

That number runs bigger than the active-parameter count suggests. The reason is worth working through before anyone quotes you an API rate.

What the weights cost to hold

Qwen3.82.4T total /95B act~1,650GB (INT4+KV) DeepSeek V4 Pro1.6T total /49B act~1,100GB (INT4+KV) B200 node~1,440GB pooled H200 node~1,128GB pooled H100 SXM node~640GB pooled Qwen3.8 exceedsALL 3 single-nodeoptions→forcesmulti-node TP over by ~210GB over by ~522GB over by ~1010GB fits, room to spare Better hardware doesn't fix a total-param problem — the shortfall gets worse on smaller nodes. 1,650GB doesn't fit in one node

At INT4, the standard estimate (~0.55GB per billion params) puts Qwen3.8’s weights at roughly 1,320GB. Add the usual 25% KV cache headroom and you need about 1,650GB of GPU memory before a single token generates.

Compare that to DeepSeek V4 Pro, the largest open model currently priced on the site at 1.6T total / 49B active. Its INT4 footprint with headroom lands around 1,100GB, which fits inside a single 8-GPU node of B200 cards (roughly 1,440GB of pooled memory) with room to spare for long context.

Qwen3.8 doesn’t fit. 1,650GB against a single node’s ~1,440GB means you’re over capacity before you’ve added a second node’s worth of hardware, at INT4, the most aggressive quant anyone runs in production. Swap in H200 (roughly 1,128GB per 8-GPU node) or H100 SXM (roughly 640GB per node) and the shortfall gets worse, not better. This model is sized to force multi-node tensor parallelism no matter which card you pick or how hard you quantize.

The active-param objection

The obvious pushback: active params are 95B, about 4% of total. Once the weights are loaded and sharded, the compute cost per generated token tracks active params, not total params, the same logic that makes Qwen3 235B A22B cheap to run despite its size. A 95B-active MoE should cost roughly what a dense 100B model costs per token, once you’re past the memory problem.

That holds up as far as it goes. If your cluster is sized for capacity and you’re running it at high sustained utilization, the marginal cost of the next token really is closer to a 95B dense model’s than to a 2.4T dense model’s. This is where self-hosting starts to look attractive again: you pay the memory tax once, at the node level, and every token after that rides on cheap active-param compute.

Where it breaks: cross-node tensor parallelism

1 node, 8 GPUsNVSwitch all-reduce cost scales withactive params (95B) 2-3 nodes stitcheddatacenter network hopevery layer, every token cost scales withlayers crossingslow fabric marketplace GPU70%+ off, butpreempt 1 node =stall whole cluster only cost that matters added tax on top discount doesn't scale here Rule: if node count > 1 NVLink domain, price the secure tier — not marketplace. Two cost curves, not one

The catch is that a cluster sized for capacity, not compute, isn’t a single NVLink domain anymore. It’s two or three nodes stitched together, and the tensor-parallel group generating each token now spans a boundary the pooled-memory math doesn’t account for.

Every layer in a TP setup does an all-reduce across the parallel group. Inside one 8-GPU node that hop rides NVSwitch. Cross two 8-GPU B200 nodes connected by standard datacenter networking instead of a single NVLink fabric, and that same hop now crosses whatever interconnect links the boxes, at every layer, on every token. A cross-node deployment adds interconnect binding on top of compute binding, and those two have different cost curves: one scales with active params, the other with how many layers your all-reduce has to cross a slower fabric. A model this deep has a lot of layers to pay that tax on.

There’s a second wrinkle if you try to cut cluster cost with marketplace or community-tier GPUs, where discounts against secure on-demand pricing run steep: H200 NVL and several other cards clear 70%+ off. That discount is easy money for a single-card fine-tune. For a job that needs two or three nodes to stay up together for the duration of a request, preemption on any one node stalls the whole generation, not just its share. The discount that makes sense for one GPU doesn’t scale cleanly to a multi-node inference cluster.

The decision rule

Price your cluster before you price your tokens. Take the node count your target quant level actually requires (total params times the per-param constant, plus 25% KV, divided by per-node pooled memory on the per-GPU pages), multiply by that configuration’s hourly rate, and run it against your expected volume in the calculator. If the node count exceeds what fits in one NVLink domain, price the secure tier, not the marketplace tier, since a preempted node stalls the whole cluster. And if your target model’s total-param footprint clears a single node’s pooled memory at INT4 the way Qwen3.8’s does, and no provider has listed a price for it yet, that absence is itself the answer: nobody’s found a token volume that clears this math profitably enough to sell it back to you.

Put the numbers to work. Run your own workload through the breakeven calculator with today's floors, then price hardware: rent at Vast.ai → · rent at RunPod → Rental links are referral links. They never affect our rankings, which are ordered by price alone.

← All guides