Kimi API Pricing vs Self-Hosted LLMs: Cost and Privacy (2026)

Kimi K2.6 and K2.7 Code cost $0.95 per million input tokens and $4.00 per million output tokens through Moonshot's API (benchlm.ai), on a 262,144-token context window. That's cheap by frontier standards, cheap enough that most teams never look past it. But Kimi API pricing isn't the whole story: multiple third-party pricing trackers already index Kimi's rates, and the harder question teams are starting to ask is whether Moonshot's terms are something they can actually build on. Moonshot stores API data in Singapore, not China, trains on your content by default with no documented opt-out, and doesn't publish a SOC 2 report or offer a signed HIPAA BAA. This runs the real numbers on both sides: what the API costs per model, what self-hosting K2 costs on H200 and B200, where the break-even actually falls, and what Moonshot's own privacy policy commits to.

Kimi API Pricing in 2026: K2.5, K2.6, and K2.7 Code Rates

Moonshot runs three models from the K2 family through its API today, plus the newer K3 flagship. All four price on a straightforward per-million-token basis, no separate reasoning-token surcharge the way some competitors structure it.

Input, Output, and Cache-Hit Discounts by Model

Source: benchlm.ai/moonshot/api-pricing.

Two things stand out here. First, K2.6 and K2.7 Code, released a couple months apart, carry identical headline input and output pricing despite K2.7 Code dropping the MoonViT vision encoder in favor of a coding-first focus, so the difference between them shows up in what Moonshot actually discloses, not in the sticker price. Second, cache-hit discounts aren't published for every model: K2.7 Code gets $0.19/M (an 80% discount off its cache-miss rate), the original K2 gets $0.15/M (a 75% discount), and K3 gets $0.30/M (a 90% discount), but Moonshot's own pricing page currently lists no cache-hit rate for K2.5 or K2.6. If you're budgeting around cached traffic, that's worth checking directly before you plan around a discount that may not exist for the model you're actually running. Where a cache-hit rate is published and your workload reuses a system prompt or tool schema across calls (the normal case for agentic and coding work), your effective input cost drops well below the headline number the moment the cache starts hitting.

Where Kimi K3 Fits (and Why It's Not the Focus Here)

Kimi K3 launched July 16, 2026, and it's priced like a different tier of model: $3.00/M input and $15.00/M output, roughly 3.5-4x K2.6/K2.7 Code's rate, on a 1,048,576-token context window that's 4x larger than K2's 256K. That's a real jump in both capability and cost, but K3 has been live for a few weeks as of this post, with essentially no query history to ground pricing analysis in yet. K2.5, K2.6, and K2.7 Code, by contrast, have been in production long enough to have real usage patterns behind them, so the cost and break-even math in this post centers on those three. If you're evaluating K3 specifically, the Kimi K3 deployment guide covers its real 1.56TB checkpoint and the multi-node clusters it needs, a genuinely different infrastructure commitment from anything in the K2 family.

Batch API: The 40% Discount for Async Workloads

Moonshot's Batch API charges 60% of the standard rate, a 40% discount, on K2.5, K2.6, and K2.7 Code for asynchronous jobs (benchlm.ai). K3 doesn't have a published batch rate yet.

The discount only applies where latency doesn't matter: nightly document processing, bulk classification, offline eval runs, dataset generation. Run the math on a workload sending 500M tokens a day at an 80/20 input/output split through K2.6 or K2.7 Code. At the standard synchronous rate ($1.56/M blended), that's $780/day. At the batch rate (60% of standard, or $0.936/M blended), it drops to $468/day, a $312/day difference that adds up to roughly $113,880 a year for a workload that can tolerate async processing. That's a meaningful lever to check before assuming your only options are the standard API rate or a self-hosted cluster: for genuinely async work, batch pricing narrows the gap between the two considerably.

Self-Hosted Kimi K2 Cost: Per-Million-Token Math on H200 and B200

Direct answer: K2.5, K2.6, and K2.7 Code share the same 1-trillion-parameter MoE architecture (32B active per token), so the same two cluster tiers cover all three: a budget 4x B200 SXM6 node running AWQ INT4 (~630GB weights), or a production 8x H200 SXM5 node running FP8 (~1TB weights). At current Spheron rates, the production H200 cluster costs about $5.21/M tokens on-demand, and an 8x B200 cluster at the same FP8 tier comes in cheaper per token despite a higher hourly rate, because it pushes roughly 1.8x the throughput.

Hardware Requirements: What It Actually Takes to Run K2 Yourself

Kimi K2.5 and K2.6 use a 1-trillion-parameter MoE architecture that activates only 32B parameters per token, a roughly 31:1 sparsity ratio that's why the API's output rate undercuts most dense frontier models despite the enormous total parameter count. K2.7 Code shares the identical architecture, just trained with a coding-first data mix.

Because it's a MoE model, VRAM sizing follows total parameters, not active ones: the router can send any token to any of the model's experts on a given forward pass, so every expert's weights have to sit resident in memory regardless of how few actually fire.

The AWQ INT4 path on 4x B200 SXM6 (768GB total) is the cheapest way to get a serving endpoint running, leaving roughly 138GB for KV cache at the full 256K context. FP8 on 8x H200 SXM5 (~1,128GB total HBM3e) is the production target, with about 128GB of headroom for KV cache at small batch sizes. Both configurations run on a single NVLink node; K2's architecture is built for 8-way tensor parallelism within a node, not split across nodes, so stick to that unless you have a specific reason to go multi-node. For the full deployment walkthrough, including the exact vLLM flags for each precision tier, see the Kimi K2.6 deployment guide and the Kimi K2.7 Code deployment guide, or the Kimi K2.5 guide if you're specifically comparing against the older, cheaper API tier.

H200 vs B200 Cost Per Token at Production Concurrency

Live Spheron GPU pricing, fetched 07 Aug 2026:

Spheron's pricing page currently lists B200 (and B300) only at a starting spot rate; on-demand availability for those cards should be confirmed at provisioning time since it moves with capacity.

Using an 8x H200 SXM5 cluster against an 8x B200 SXM6 cluster, both at FP8 and 8K context with batch 8, the production throughput difference is large enough to flip which GPU is actually cheaper per token. At roughly 1,800 tok/s on H200 and 3,200 tok/s on B200 (Spheron: Deploy Kimi K2.6):

B200's per-GPU rate runs about 27% above H200 on-demand, but its throughput advantage on this workload is close to 1.8x, so the B200 cluster still lands cheaper per token than H200 on-demand, just not quite as cheap as H200 on spot. A closely related but distinct comparison from SemiAnalysis, running B200 at native NVFP4 against H200 at INT4 rather than both at FP8, found B200 2.71x-2.95x cheaper per million tokens across a 30-90 tokens/sec/user serving band, peaking at 2.95x at 32 tok/s/user ($0.140/M on B200 NVFP4 versus $0.413/M on H200 INT4) (SemiAnalysis InferenceX). That gap is wider than the FP8-vs-FP8 numbers above because it's comparing Blackwell's native FP4 tensor cores against a quantization path Hopper has to emulate, not just raw throughput at matched precision. Either way, the pattern holds: at K2's scale, B200's throughput advantage tends to outweigh its higher sticker price once you're running production concurrency, not just a single stream.

Pricing fluctuates based on GPU availability. The prices above are based on 07 Aug 2026 and may have changed. Check current GPU pricing → for live rates.

Break-Even Token Volume: Kimi API vs Renting GPUs

For K2.6 or K2.7 Code, blended at an 80/20 input/output split (the more common shape for RAG and agentic workloads):

K2.6 / K2.7 Code blended (80/20) = (0.8 x $0.95) + (0.2 x $4.00) = $0.76 + $0.80 = $1.56/M tokens

At a more output-heavy 60/40 split, that climbs to $2.17/M. Both figures ignore caching; on K2.7 Code, which does publish a cache-hit rate, a workload with meaningful cache-hit traffic pushes the real blended rate lower still, and every crossover below moves out further in the API's favor. K2.6 doesn't currently have a published cache-hit rate to build that same discount into the math.

Against that $1.56/M uncached blended rate, here's where a self-hosted cluster starts winning on pure infrastructure cost:

†Cluster cost is flat only up to that cluster's throughput ceiling; sustained volume well past the crossover may need a second cluster, which resets the comparison.

The budget AWQ INT4 cluster crosses over around 329M tokens a day. The production FP8 cluster crosses over later, around 519M tokens a day on-demand, but drops to roughly 311M tokens a day on spot pricing, since H200 spot at $2.53/GPU undercuts a 4x B200 budget cluster running at $5.34/GPU despite having double the GPU count. That's worth pulling live rates to confirm before you commit to a tier: the cheaper cluster on paper isn't always the cheaper cluster once spot and on-demand rates actually move.

Run the same math for K2.5, which blends to $1.08/M uncached, and the crossover pushes out further still, roughly 475M tokens a day against the budget cluster and 750M tokens a day against production FP8 on-demand, simply because the API itself is cheaper. Below these volumes on either model, paying Moonshot per token is the cheaper option; above them, and especially once you factor in the batch API's 40% discount pushing the API-side numbers down further, the crossover moves out even more in the API's favor unless your workload is genuinely sustained, high-volume, and can't use batch pricing. For the underlying throughput data these figures are built on, see the GPU cost-per-token benchmarks.

Privacy and Data Residency: Why Teams Self-Host Kimi Anyway

No token volume changes this part of the decision. Moonshot's terms store API data in Singapore, train on submitted content by default, and don't currently offer a SOC 2 report or a signed HIPAA BAA. For regulated or IP-sensitive workloads, that's a self-hosting decision independent of cost.

What Moonshot's Own Privacy Policy Actually Says

Moonshot's Kimi OpenPlatform privacy policy is direct about data location: "We store the information we collect in secure servers located in Singapore" (Moonshot Kimi OpenPlatform privacy policy). That's a meaningful detail if you've been assuming Kimi's API works like DeepSeek's, where prompt data is stored in China under a legal framework that compels cooperation with state intelligence work. Singapore residency sidesteps that specific exposure.

It doesn't clear every concern, though. The same policy states that submitted content helps Moonshot "optimize our models and understand your needs and preferences," and describes using information for "training and refining our underlying technology, such as machine learning models and algorithms." As of mid-2026, there's no documented in-product opt-out for this in the way ChatGPT, Claude, and DeepSeek all offer one. If your prompts contain proprietary source code, unpublished research, or other IP-sensitive material, "the vendor might train on this" is a real, standing risk with the Kimi API, not a hypothetical.

The compliance gap compounds this. Moonshot does not directly offer SOC 2 reports or a signed HIPAA business associate agreement for its hosted service (Layer3 Labs). Without a BAA, US healthcare organizations legally cannot send protected health information through the Kimi API, and without a SOC 2 report, security teams evaluating the API for anything beyond low-sensitivity workloads have little to audit against beyond the privacy policy's own language.

Put together: teams under HIPAA, teams with contractual data-residency requirements, and teams handling IP-sensitive prompts generally self-host Kimi K2 regardless of what the token-volume math above says. On Spheron, self-hosted instances run with SSH root access and no shared GPU tenancy, which is the baseline you want before treating self-hosting as a genuine compliance lever rather than just a cost one. If you're weighing a similar China-adjacent privacy question against a different lab, the DeepSeek API pricing vs self-hosted breakdown covers the National Intelligence Law exposure specifically, which Kimi's Singapore storage does not carry in the same form.

Kimi API Pricing vs Self-Hosted: Decision Framework

If you're weighing this same tradeoff against a different closed API, the DeepSeek API pricing vs self-hosted, Claude Opus 4.8 vs self-hosted LLMs, Mistral API pricing vs self-hosted, and Grok 4.5 API pricing vs self-hosted breakdowns run the same framework at different price points, with the DeepSeek comparison being the closest analog for the China-residency question specifically. For a broader look at which open-weight models are realistic to self-host at all before committing to a GPU cluster, see the best open-source LLMs to self-host VRAM guide, and the NVIDIA B200 cloud pricing breakdown if you're specifically pricing out a Blackwell cluster across providers. Spheron's docs cover instance provisioning in more depth if you're standing up your first cluster.

If your Kimi usage is climbing toward hundreds of millions of tokens a day, or your prompts can't legally leave your own infrastructure, benchmark K2.6 or K2.7 Code against your own eval set on a rented H200 or B200 cluster before your next contract renewal.

H200 SXM5 on Spheron → | Check B200 availability → | View all GPU pricing →