Your teammate opens a ticket: "Can we just self-host the new Kimi K3? It's open-weight." The weights did land on July 26 - a day ahead of schedule - and the model genuinely is the largest open-weight release in history. The question of whether your team can run it is separate, and the answer mostly comes down to one number: 1.4 terabytes of GPU memory, before you even boot the model.
What Kimi K3 actually is
Kimi K3 is Moonshot AI's flagship 2.8-trillion-parameter multimodal reasoning model. It uses 2.8 trillion total parameters, activates 16 of 896 experts during inference, and can process up to 1 million tokens of context. In practice, that MoE routing means the model only computes a fraction of its parameters per token - but every single expert still has to sit in GPU memory, warm, waiting to be called.
Moonshot AI released the weights on July 26, 2026, roughly a day ahead of the July 27 target the company had previously communicated.
Moonshot published the K3 weights on their Hugging Face organization. The release includes MXFP4 quantized weights - approximately 594 GB total download - the same format Moonshot uses internally, with the claim of near-lossless quality at 4-bit precision.
The MXFP4 weight format means the full 2.8T model requires approximately 1.4 TB of weight storage - substantially less than the ~5.6 TB that FP16 weights would demand. That compression is real and meaningful, but it doesn't change the fundamental constraint: 1.4 TB of VRAM is a datacenter problem, not a server-room one.
The self-hosting hardware math
Self-hosting a model this size is not a configuration question. It is a procurement question.
At 4 bits per parameter, 2.8T parameters need about 1.4 TB for the weights alone - before microscaling metadata, runtime buffers, activations, and context state. For scale: eight DGX Sparks pool 1 TB of unified memory and are still at least 376 GB short of the raw weight floor.
The weights alone need roughly 1.4 TB of VRAM at the native 4-bit quantization, which in practice means an 8× NVIDIA B200 node (1,536 GB) at the low end, and 16× H200 (about 2.25 TB across two nodes) for the full 1-million-token context.
At full precision with tensor parallelism across nodes, you need at least 64 accelerators (8 nodes of 8× H100), or a single node of 8× H200 if you can tolerate MXFP4 quantization. Moonshot's own recommendation goes further: Moonshot recommends deploying Kimi K3 on a supernode configuration with 64 or more accelerators. It has not published a minimum GPU count, a list of validated GPU models, the required interconnect, or a minimum amount of aggregate GPU memory.
The operational overhead compounds the hardware cost. Teams must benchmark interconnect performance, parallelism, prefill and decode behavior, concurrency, and retry handling instead of treating it like a conventional single-node model endpoint. That is a DevOps function, not a setting.
The API vs. self-host break-even
This is where the self-hosting pitch usually collapses for most teams.
Calling K3 through an API costs $3 per million input tokens and $15 per million output tokens (OpenRouter list price, July 2026).
At a mid-market rate near $5.50 per GPU-hour, an 8× B200 node runs about $32,000 a month, so the break-even against the $15/M API sits above 2 billion output tokens a month. Below that volume, the managed API wins on both price and operational effort.
Two billion output tokens a month is roughly the throughput of a dedicated AI inference product serving tens of thousands of active daily users. It is not a team's internal tooling budget.
| Path | Monthly cost floor | Who it makes sense for |
|---|---|---|
| Managed API (OpenRouter/Moonshot) | Pay-per-token, $3/$15 per M | Teams under ~2B output tokens/month |
| Self-hosted 8× B200 node | ~$32,000/month + ops | High-volume inference products |
| Hosted third-party (Together AI, Modal) | Metered, no hardware ops | Privacy-adjacent but not air-gapped |
Beagle in action#platform-eng, Thursday afternoonWhat "open-weight" actually means here
The license is the other thing most coverage glossed over. K3 ships under a bespoke document titled the Kimi K3 License, tagged on Hugging Face as license:other. It is not MIT and it is not Apache 2.0.
The K3 license no longer calls itself "modified MIT" and goes further, requiring a separate agreement with Moonshot for large "Model as a Service" businesses: if the licensee or any of its affiliates operates a Model as a Service business and aggregate revenue exceeds $20 million over any consecutive 12 months, the licensee must enter into a separate agreement with Moonshot AI before commercial use.
Using K3 inside your own product requires prominently displaying "Kimi K3" if that product passes 100 million monthly active users or $20 million a month in revenue.
Most enterprise internal deployments are clean: the commercial clauses do not apply to purely internal use never exposed to third parties, nor to access through Moonshot's own official products or certified inference partners. Most in-house enterprise deployments sit here. The gates are aimed squarely at inference resellers and platform companies - the sharpest clause is therefore not aimed at developers or corporate users, but at the layer above them: cloud and inference providers that host and resell open models.
To Kimi's credit, they make no attempt to describe this as an "open source" license in their own materials, consistently using the term "open weight" in its place. That distinction matters. Open-weight means you can download the parameters and run them on hardware you control. It does not mean the training data, pipeline, or architecture code are public, and it does not mean commercial use is unconditional.
For most teams asking about self-hosting K3 for privacy reasons, a third-party hosted endpoint like Together AI or Modal is a practical middle ground: no weights to operate, but prompts stay off Moonshot's infrastructure. Air-gapped requirements are the real forcing function for true self-hosting - and at that point, you are running a datacenter project, not an AI project.
A teammate like Beagle, living in Slack, would route to the K3 API the same as any other model endpoint - the model it calls is a configuration, not a rebuild.
Kimi K3 self-hosting: common questions
Can any team self-host Kimi K3?
Technically yes, practically very few. Self-hosting K3 requires a minimum of 8× H100 or B200 GPUs to hold the MXFP4 weights, and Moonshot recommends 64 accelerators for production serving. The break-even against the $3/$15/M token API is roughly 2 billion output tokens a month - out of reach for most internal tooling use cases.
Is Kimi K3 actually open-source?
No. It is open-weight, which means the trained parameters are publicly downloadable. The license is a custom document - not MIT, not Apache 2.0 - with commercial gates for Model-as-a-Service operators above $20M annual revenue and attribution requirements for products above 100M monthly active users or $20M monthly revenue.
What is the cheapest way to use Kimi K3 today?
The managed API at $3 per million input tokens and $15 per million output tokens via OpenRouter or Moonshot's own platform. No hardware, no ops, same model quality as the hosted product - Moonshot confirmed the MXFP4 weights used for self-hosting are identical to what runs their API.
When does self-hosting Kimi K3 actually make sense?
Primarily for two cases: air-gapped environments with strict data residency requirements where no external API is permitted, or high-volume inference products processing well above 2 billion output tokens a month. For everyone else, the API is cheaper and simpler until those conditions change.