Kimi K3's open weights are live. Moonshot published them on July 26, 2026, ~7:30 PM EDT — about a day ahead of the July 27 target it had previously stated — to huggingface.co/moonshotai. That changes this guide from a prep checklist into an actual how-to: what hardware you need, the real vllm serve command instead of a placeholder, and where community GGUF quantization stands two days in. For the full release breakdown — what's confirmed vs. still a claim from social coverage — see Kimi K3 open weights: 2.8T params, day-0 hosting.
TL;DR — where the weights are, what you need, what your options are
| Question | Answer |
|---|---|
| Where are the weights? | huggingface.co/moonshotai — live since July 26, 2026 |
| Download size? | ~594GB for the native MXFP4 safetensors release |
| What setup do I need to self-host? | 8x H100 80GB minimum to load the full model; a single consumer GPU (24GB RTX 4090, Mac Studio) cannot run it, even quantized |
| License? | Modified MIT (matches K2.7) — confirm against the repo's own LICENSE file before commercial use |
| Serving stack? | vLLM / SGLang — Moonshot shipped a KDA prefill-cache contribution alongside the weights |
| GGUF / llama.cpp quants? | In progress — no full-fidelity community port confirmed as of July 28; check Hugging Face for the latest |
| Fastest alternative if I don't have GPUs? | OpenRouter — one key, no infra to manage; see the full alternatives table below |
| Other hosted alternatives? | Together AI, Modal, Fireworks AI, Ollama Cloud, Cursor Router, LM Studio Secure Cloud — see Alternatives |
| Lighter self-hosted fallback? | Kimi K2.7 Code — 1T MoE, 32B active, runs on far less hardware |
| OpenCode local wiring? | OpenCode guide — wire K3 or K2.7 as a local/cloud provider |
What actually shipped on July 26
The confirmed facts, traceable to Moonshot's own Kimi K3 tech blog and platform documentation:
| Spec | Value |
|---|---|
| Total parameters | 2.8 trillion |
| Context window | 1,048,576 tokens (1M) |
| Repository | huggingface.co/moonshotai |
| Download size | ~594GB (native MXFP4 safetensors) |
| License | Modified MIT (matches K2.7's prior release — verify the repo's LICENSE file directly) |
| Architecture | Stable LatentMoE, 16 of 896 experts active per token |
| Attention | Kimi Delta Attention (KDA) + Attention Residuals |
| Quantization | MXFP4 weights / MXFP8 activations, quantization-aware training from SFT |
| Serving support at launch | vLLM KDA prefill-cache contribution shipped with the weights |
Total parameters is not active parameters per token — with 16 of 896 experts routed per forward pass, the real compute footprint is a small fraction of the 2.8T headline figure. Scale hardware expectations from that sparsity, not the total count.
Hardware tiers — what you actually need
These are planning brackets based on Moonshot's published architecture and standard MoE serving math. Adjust once you've run your own load test.
| Tier | Hardware | Realistic K3 use |
|---|---|---|
| A — API only | Any desktop | Production today via kimi-k3 API, no local GPU needed |
| B — K2.7 local | 2–8x A100/H100 or high-end consumer + quant | Open-weight coding today — not full K3 |
| C — K3 quant lab | 4–8x H100 80GB | Loads the full model; limited concurrency, realistic first milestone |
| D — K3 production local | Multi-node H100/H200 cluster | Full-speed serving, large-batch, long-context workloads |
| E — MacBook / single consumer GPU | 24–48GB unified or VRAM | K2.7 quantized only — full K3 is not viable here even quantized, until a lower-fidelity community GGUF exists |
A single RTX 4090 or Mac Studio cannot load full-precision K3 — that hasn't changed since release. What's changed is that Tier C is no longer hypothetical: it's the actual entry point if you want to self-host today rather than wait for smaller quantizations. Compare against Mac vs. dedicated GPU local LLM economics and the Fable local hardware projection — frontier open weights at this scale still outrun consumer hardware by a wide margin.
Running Kimi K3 with vLLM
Moonshot's K2.7 Code documented vLLM, SGLang, and KTransformers as supported serving stacks. For K3, Moonshot's vLLM KDA prefill-cache contribution shipped alongside the weights — check you're on a recent-enough vLLM build before pinning a production image.
Setup
python -m venv ~/vllm-kimi
source ~/vllm-kimi/bin/activate
pip install -U vllm
# Reserve disk headroom — the native release is ~594GB
df -h
# Hugging Face auth if the repo requires it
huggingface-cli login
Serving the model
vllm serve moonshotai/Kimi-K3 \
--tensor-parallel-size 8 \
--max-model-len 131072 \
--trust-remote-code
Start at 128k–256k context rather than the full 1M window. Moonshot's Delta Attention benefits from its own cloud serving infrastructure; local max-model-len at 1M requires either a supported linear-attention kernel path in your vLLM/SGLang build or enough GPUs to shard KV cache across, and community kernel support may still lag the cloud implementation. Scale up from 128k once you've measured throughput on your own cluster.
| Cloud claim | Local implication |
|---|---|
| 6.3x faster decoding at 1M context | Needs kernel/runtime support in your vLLM/SGLang build — verify before assuming parity |
| 1,048,576-token window | VRAM scales with KV cache size; expect a lower local max-model-len than the cloud API default unless you shard across many GPUs |
| Hybrid linear attention | Falls back to standard attention if your runtime doesn't implement the linear-attention path — slower, more memory |
llama.cpp / GGUF — check current status before assuming availability
As of July 28, two days after release, no full-fidelity GGUF community port was confirmed. Given the ~594GB native size, expect partial or lower-precision quants first, with better-quality ports following over the next couple of weeks — this is a large model to requantize. Watch what is llama.cpp and the Hugging Face repo's community tab for the latest before planning a llama.cpp deployment.
Alternatives if you don't want to self-host
If you're not running 8x H100s, you don't need to be — Kimi K3 is already available through multiple hosted routes, ranked roughly by how little setup each one takes:
| Option | Setup effort | Best for |
|---|---|---|
| OpenRouter | One API key | Fastest way to try K3 today — routes to whichever backend hosts it, and has run free/discounted windows on prior open releases like GLM 5.2. Good default if you don't want to pick an infra vendor. |
| Cursor (Router) | None — built into the IDE | Cursor's Router auto-selects K3 for the right task; you never touch an API key or weights |
| Moonshot API | API key, direct integration | Lowest latency to Moonshot's own infra; official pricing and rate limits — see below |
| Together AI | API key | Day-0 hosted access, standard per-token pricing, no GPU provisioning |
| Modal | Account + deploy config | Serverless GPU deployment if you want more control than a fixed API but don't want to own hardware |
| Fireworks AI | API key | Already running production K3 traffic in its own routing benchmarks; pairs K3 with fallback/routing tooling |
| Ollama Cloud | ollama pull from the hosted catalog | Familiar Ollama workflow without local GPU limits — confirm the catalog shows the K3 tag specifically |
| LM Studio (Secure Cloud) | LM Studio Bionic app | ZDR-negotiated managed access with a desktop UI, for teams that want LM Studio's catalog without local hardware |
Check each platform's live docs for current model-ID naming and pricing before committing production traffic — availability and exact catalog tags move quickly on a model this new. If you're already inside one of these tools, use it; if you're starting fresh and just want K3 working today, OpenRouter or Cursor Router are the lowest-friction starting points.
Moonshot's own API
If you want direct access rather than a third-party host, the Moonshot API remains the reference path:
{
"model": "moonshot/kimi-k3",
"provider": {
"moonshot": {
"npm": "@ai-sdk/openai-compatible",
"options": {
"baseURL": "https://api.moonshot.ai/v1",
"apiKey": { "env": "MOONSHOT_API_KEY" }
},
"models": {
"kimi-k3": { "name": "Kimi K3 (cloud)" }
}
},
"local-k2": {
"npm": "@ai-sdk/openai-compatible",
"options": {
"baseURL": "http://127.0.0.1:8000/v1",
"apiKey": "local"
},
"models": {
"kimi-k2-7": { "name": "Kimi K2.7 local" }
}
}
}
}
Full walkthrough: how to run open-source models locally in OpenCode. A common hybrid pattern: route sensitive repos to a locally hosted K2.7, and send frontier frontend or long-context tasks to K3 via API — the same split covered in the closed vs. local guide.
Official API reference: Kimi K3 API guide · platform.kimi.ai/docs/llms.txt
K3 local vs. K2.7 local — which one you should actually run
| Need | K3 local (Tier C/D) | K2.7 local (today, lighter hardware) |
|---|---|---|
| Air-gapped coding | Yes, if you clear 8x H100 | Yes — Modified MIT, far less hardware |
| #1 nextjs.org/evals result | Yes — this is the model that scored it | Not equivalent |
| Single 24–48GB GPU | Not viable at full precision | Quantized K2.7 possible with offload |
| License | Modified MIT (verify repo LICENSE) | Modified MIT (documented) |
| MCP agent loops | Frontier depth | Strong — MCP Mark 81.1% |
If your hardware clears Tier C, K3 is the stronger model and the weights are sitting on Hugging Face today. If it doesn't, K2.7 is still the realistic self-hosted option — see the K2.7 guide for its own vLLM memory starting points. Enterprise-scale comparison: Fable 5 open-source alternatives.
Post-download checklist
- Pin a commit hash from
huggingface.co/moonshotaibefore wiring K3 into anything production — don't float onmain. - Read the LICENSE file directly in the repo rather than assuming Modified MIT carried over automatically from K2.7.
- Compare hosted vs. self-hosted economics — Together AI and Modal both offer day-0 hosted access, which removes the multi-GPU provisioning problem but may cost more than self-hosting at high volume. Run the math against your own request volume.
- Run your own eval suite rather than trusting benchmark claims at face value — the same discipline explainx.ai applied when Kimi K3 topped nextjs.org/evals.
- Check for GGUF and re-quantized community ports before committing to llama.cpp — none were confirmed at full fidelity as of July 28.
Summary
Kimi K3 open weights are live and self-hostable as of July 26, 2026 — 2.8 trillion parameters, ~594GB native MXFP4 download, Modified MIT license, hosted at huggingface.co/moonshotai. Running the full model locally requires real multi-GPU hardware (8x H100 80GB minimum); it is not a single-consumer-GPU model even quantized, and full-fidelity GGUF ports weren't confirmed as of two days post-release. If your hardware doesn't clear that bar, you have real alternatives: OpenRouter, Cursor's Router, the Moonshot API, Together AI, Modal, Fireworks AI, Ollama Cloud, and LM Studio's Secure Cloud all offer hosted access, or self-host Kimi K2.7 Code on far lighter hardware.
Related on explainx.ai
- Kimi K3 architecture — Raschka / LatentMoE / NoPE
- Deltafin — K3 on one Apple Silicon Mac
- Kimi K3 open weights: 2.8T params, day-0 hosting on Together and Modal
- Anthropic's position on open-weights models: no ban, but chips, distillation, and testing
- Kimi K3 API guide — pricing, specs, production limits
- Kimi K3 Next.js evals + Arena benchmarks
- Kimi K3 mobile app and API guide
- OpenRouter — aggregator pricing and free-window access
- Ollama's $88M raise and Ollama Cloud's open-model catalog
- Cursor Router — automatic model selection inside the IDE
- Kimi K3 + Fable 5 routing study — Fireworks AI
- Kimi K2.7 Code — self-host now on lighter hardware
- How to run open-source models locally in OpenCode
- What is llama.cpp? — GGUF local inference
- Mac vs. dedicated GPU local LLM economics
- Closed source vs. local open alternatives
- Fable 5 enterprise open-source alternatives
- Running SOTA LLMs locally — RTX 6000 reference build
Official sources: Kimi K3 tech blog · Kimi Platform · Docs index · huggingface.co/moonshotai · K2.7 resources
Weight release date, download size, and hardware guidance accurate as of July 28, 2026, based on Moonshot's own platform documentation and public statements from Together AI and Modal. GGUF/llama.cpp quantization status reflects the state of the Hugging Face community tab as of this writing and will change — check the repo directly before planning a deployment. Verify current license terms and hosting pricing before provisioning production workloads.