If you read one line: Kimi K3's weights are free; running them is not. At ~1.4TB and ~18 H100 GPUs to serve, self-hosting the largest open-weight model ever only beats the API if you're burning over a billion tokens a month, need the data to never leave your perimeter, or want to fine-tune. For almost every solo founder, the API isn't the compromise — it's the right answer.

On Sunday, July 27, Moonshot AI drops the full open weights for Kimi K3 — 2.8 trillion parameters, the largest open-weight model anyone has ever released (CNBC). It's genuinely frontier-class: independent testing puts it fourth overall, behind only Claude Fable 5 and GPT-5.6 Sol, and just ahead of Opus 4.8, with a 1-million-token context window and multimodal input.

"Open weights" reliably triggers the same reflex: now I can run it myself and stop paying per token. For a 7B or a 30B model, that reflex is right. For K3, it is a trap. Here's the math nobody puts in the launch tweet.

The weights are 1.4 terabytes#

K3 was quantization-aware trained at 4-bit (MXFP4), so its floor footprint is about 1.4TB — and that's weights alone, before activations, KV cache for a million-token context, and runtime buffers (TECHi). In BF16 the weight files land around 594GB, needing roughly 720GB of accelerator memory before you generate a single token.

Nothing on your desk holds that. Not a workstation, not a pair of 4090s, not a Mac Studio. The practical deployment target is around 18 H100 80GB GPUs at 4-bit, and Moonshot recommends supernode configurations of 64 or more accelerators for production serving (Northflank). This is a multi-node, high-interconnect data-center workload. The "open" in open weights means you may run it — not that you can cheaply.

The break-even is a billion tokens a month#

Put a price on the cluster. Eighteen H100s at a typical on-demand rate of ~$2 per GPU-hour is roughly $26,000 a month — and that's before storage for a 1.4TB checkpoint, before the high-bandwidth networking that keeps a sharded MoE fast, and before the engineering time to provision, shard, and babysit it. Critically, that bill is fixed: it lands whether you serve one request or a million. Idle GPUs cost full rate.

Now the API side. Kimi K3 is served at $3 per million input tokens and $15 per million output — roughly half the price of the top US flagships. To spend $26,000 a month on the API, you'd have to push well over a billion tokens through it, every month, at high utilization.

A self-hosted cluster is a fixed cost you pay for capacity. An API is a variable cost you pay for use. The cluster only wins when you keep it full — and a solo founder almost never keeps 18 H100s full.

That's the whole decision in one sentence. The API scales to zero; your cluster never does. Until your traffic is both large and steady, the API is not just easier — it's cheaper, often by an order of magnitude. This is the same logic we walked through for smaller models in On-Device vs Cloud API, pushed to the extreme by a model this size: the cost line moves toward the API, not away from it, as the model gets bigger.

When self-hosting K3 is actually right#

Three cases justify the cluster, and notice that none of them is "to save money":

  1. Data residency or air-gap. If your data legally cannot leave your perimeter — regulated health, defense, some EU deployments — self-hosting is the only option, and cost is beside the point. This is the real founder-scale reason.
  2. Sustained, saturated scale. If you genuinely keep the cluster near 100% utilization — a high-volume product, not a spiky prototype — the fixed cost amortizes and can beat the API. Measure your actual token volume for a month before believing you're here.
  3. Fine-tuning. The API gives you the base model; the weights let you change it. If a custom-trained K3 is your moat, you need the weights.

If you're nodding at one of those, self-host — and read our checklist for verifying an open-weight model before you run it first, because 1.4TB from an overseas lab is a supply-chain surface, not just a download.

What to do this week#

Don't let "open weights" pull you into a capital-expenditure decision you didn't need to make. The correct default is boring: point your agent at the K3 API, ship, and measure your token spend. Only when that number gets big and steady enough to rival a $26k/month cluster — or when compliance forces your hand — does self-hosting enter the conversation. The largest open model in the world is a gift. It's just not a gift you keep in your garage.