GLM-5.2’s real footprint
GLM-5.2 lists 744 billion total parameters and 40 billion active per token on its model page. Run the standard INT4 estimate, roughly 0.55GB per billion params, and the weights alone come to about 410GB. Add the usual 25% for KV cache headroom and you’re at roughly 510GB before serving a single token.
That number eliminates almost everything on the GPU page. Two H200 cards give you around 280GB combined. Two B200 cards, somewhere around 180GB apiece, land you near 360GB. Neither clears 510GB. You need at least three B200s, or four H200s, wired together with tensor parallelism, before the weights fit in memory at all. That’s before you’ve allocated anything for batching multiple requests.
The trap in MiniMax M3’s numbers
MiniMax M3 looks more forgiving on paper: 428B total, 23B active. INT4 math puts the weights around 235GB, and with headroom you land near 294GB. That’s close enough to two H200s’ combined 280GB that a lot of people spec exactly that node, provision it, load the checkpoint, and watch it fail on an out-of-memory error a few gigabytes short of fitting. The fix is a redeploy onto a three-card layout, which costs at minimum a wasted rental hour, and closer to a wasted afternoon if you were mid-benchmark and have to requeue capacity on a busier provider. Round numbers lie by exactly the amount that matters here.
Kimi K2.7 Code: the extreme case
Kimi K2.7 Code sits at the far end of this tier: 1059B total, 32B active. INT4 weights alone run about 582GB, and with KV headroom you’re past 725GB. Four B200s land you right at the edge of that number, not comfortably past it, so in practice you’re looking at four or five B200s, or six H200s, once framework overhead and batching pile on top of the raw weight math. This isn’t a model you spin up to try for an afternoon. It’s a model you provision a cluster for, or you don’t run it yourself.
Three paths, and what each one asks of you
A rental node with three or more matched GPUs is the direct path: check current per-card floors on /gpus, confirm the tier supports tensor parallelism across the number of cards you need, and treat the reservation as a standing cost, not a one-off job. This only pencils out if the node stays busy. An idle four-card cluster billed by the hour burns money whether or not anyone sends it a request.
A 256GB-plus unified-memory workstation is the second path, and it’s the one this guide can’t quantify, because the site tracks GPU rental and per-token API pricing, not owned hardware. What’s knowable without a benchmark: unified memory bandwidth sits well below HBM, so token throughput on a box like that runs materially slower than the same weights on H200 or B200, even though the capacity math works out fine. If your workload is latency-sensitive, that gap matters more than the capex savings.
The third path is per-token API against a hosted endpoint: GLM-5.2, Kimi K2.7 Code, or MiniMax M3 directly, with zero idle cost between requests.
The community discount that doesn’t transfer
On H200 NVL, community tier runs more than 70% cheaper than secure tier right now. That discount is real money for a single-card inference job. It gets murkier once you’re stitching three or four cards into one tensor-parallel run, because community capacity lives on shared hosts that don’t guarantee the NVLink or InfiniBand topology multi-GPU parallelism needs. The same discount that looks free on a single card can cost you the debugging session when card-to-card bandwidth turns out to be PCIe instead of NVLink and your throughput craters for reasons that have nothing to do with the model.
The rule
Compute the card count first: total params times 0.55, plus 25% for KV, divided by the per-card capacity on /gpus. If that number clears three, you’re paying for cluster orchestration, not just GPU-hours, and the rental only wins if utilization stays high enough, close to continuous, to justify reserving that many cards around the clock. Provider pricing on these exact three models varies too: spreads over 20x show up routinely on similarly sized open MoE models like qwen3-235b-a22b, as of this writing, so check the model’s own page before assuming API is the cheap default. What none of this tells you is your actual traffic shape. A workload that bursts to full concurrency for an hour and sits idle the rest of the day has no business owning a four-card cluster, no matter how the per-token math looks on paper.