Kimi K2.7 Code ships as a 1059B parameter mixture-of-experts model that activates only 32B of those parameters per token. That gap, roughly 33x between total and active, is the whole story for anyone deciding whether to self-host it or keep paying per token.
What the footprint demands
At INT4 quantization, storing the weights costs roughly 0.55GB per billion parameters, so K2.7 Code needs about 582GB just for weights. Add the usual 25% KV cache headroom and you land around 728GB before a single concurrent request hits the box. At FP8, the number nearly doubles, to around 1.46TB.
Check current specs on B200 and H200: the INT4 footprint alone rules out anything smaller than a 4-6 card cluster, and FP8 pushes you into full 8-GPU node territory, or a second node if you’re on H200 and want real headroom for concurrency. This isn’t a model you run on a single card at any quant level. The total-param count sets your node size. The active-param count is a separate, much smaller number that determines how much that node can actually produce once it’s running.
The case for self-hosting
Node rental is a fixed monthly cost. API pricing is linear per token. Every additional million tokens you push through a self-hosted node costs you compute bounded by the 32B active parameters, essentially flat, while every additional million tokens through the API costs the same rate as the first one. That crossing point is a real number you can compute today: take the monthly rental cost for your chosen node config from the B200 or H200 page, divide by the current per-million-token rate on the K2.7 Code page, and you get the monthly token volume where the two lines cross. Below it, the API wins on cost. Above it, the node wins, and it wins by a wider margin every month you clear it.
Where that argument breaks
A model this new typically launches with a wide provider price spread because every host serving it is still calibrating margin against actual GPU cost, and nobody has settled on a stable rate yet. Check the live spread on the K2.7 Code page before you lock in a breakeven number: if the cheapest listed provider today is a promotional rate that won’t survive the quarter, your crossover point moves closer to you than the snapshot suggests.
The bigger problem is utilization, not price. A 728GB to 1.46TB footprint sitting on rented B200s or H200s costs the same whether it’s serving requests at full concurrency or sitting mostly idle overnight. If your traffic is bursty, a support desk, a coding agent fleet, a demo integration, rather than sustained batch volume, you’ll pay for a full node around the clock to catch a few peak hours a day, and the math that looked favorable at your monthly token estimate collapses once you divide by actual hours of high-concurrency use. Marketplace capacity adds its own volatility: community-tier listings on cards like H200 NVL run 70%+ cheaper than secure on-demand as of this writing, which looks like it fixes the utilization problem, until a mid-batch preemption on a model this size costs you a multi-minute reload before you’re serving traffic again.
The boundary line
Self-hosting wins when two conditions hold at once: your monthly token volume clears the node-cost-over-API-rate breakeven from the calculator, and your actual concurrent traffic keeps that node busy more than roughly 60% of the hours you’re paying for. Clear the first condition without the second and you’ve bought an expensive space heater. Clear the second without the first and you’re overpaying for hardware you didn’t need to rent.
One trap specific to this model: teams size the node off the INT4 footprint, land on 4-5 cards, and then discover that KV cache under real multi-turn agentic context, which is exactly what K2.7 Code is built for, eats far more headroom than the flat 25% estimate once concurrency climbs. That pushes the deployment to a 6-8 card config mid-contract. Size for your expected concurrent context length, not the baseline formula, before you sign a monthly commitment.
What this exercise can’t tell you is your own expert-parallel routing efficiency. A 32B-active MoE split across six or more cards depends on how cleanly your inference stack maps experts to GPU boundaries; a routing config that crosses node boundaries on every decode step will not hit the throughput your node-cost math assumed, and you won’t know your real number until you benchmark your own request shapes on the exact node you’re renting.
If your projected monthly volume clears the calculator’s breakeven and your traffic is sustained rather than bursty, rent the node. If either condition is soft, stay on the API until your volume forces the question again.