Kimi K3’s Open Weights Are Live: How to Download 1.56 TB and What It Takes to Run

Moonshot AI has released the actual Kimi K3 model checkpoint, not an adapter, a partial release, or a promise of weights to come. The repository is public and ungated on Hugging Face, with 96 downloadable weight shards.

The catch is scale. Those shards occupy 1,560,936,091,448 bytes: 1.561 TB in decimal units, or 1.420 TiB. Serving them requires a tightly connected datacenter GPU cluster. Here, “local” can mean infrastructure your organization controls, not a MacBook, gaming PC, or single workstation.

Download Kimi K3’s official weights on Hugging Face →

Full-checkpoint testing disclosure: Kingy.ai inspected the live repository, counted and totalled the shards through the Hugging Face API, downloaded the 60 MB metadata and code subset, and successfully ran the current CLI’s dry-run. We did not download the 1.56 TB checkpoint or claim a successful inference run.

Kimi K3 open-weights facts at a glance

These figures were checked against the live repository API, model card, configuration files, and technical report on July 27, 2026. The report describes an image-and-video vision pathway, while the released model card’s serving contract lists text and image. Treat video serving as unconfirmed for the open checkpoint until Moonshot documents it explicitly.

What Moonshot released

The Hugging Face repository contains the complete sharded weight set, a 59.8 MB tensor index, tokenizer assets, processor files, generation settings, the license, and custom Python implementation files. The index maps roughly 497,000 tensors across the 96 shards and reports 1,560,860,324,864 bytes of tensor data. The slightly larger on-disk shard total includes file-format overhead.

Kimi K3 is sparse, but the release is not small. Its Mixture-of-Experts router selects 16 of 896 routed experts for each token. That reduces the expert computation performed for a token; it does not remove the other experts from the checkpoint. Different tokens can route to different experts, so an ordinary full-model server still needs all weights available.

The model card and Kimi K3 report specify 2.8 trillion total parameters and approximately 104 billion activated parameters per token. Neither figure is a direct runtime-memory requirement. Checkpoint storage is a third quantity. GPU memory adds several more: loaded weights, temporary activations, KDA state, MLA key-value cache, communication buffers, and capacity for concurrent requests. Long context expands the state and cache burden even when weight storage stays fixed.

Kimi K3 combines routed and shared experts with Kimi Delta Attention, Gated MLA and a MoonViT-V2 input pathway. Source: Figure 2 of the Kimi K3 technical report. Credit: Moonshot AI / Kimi Team.

How to download Kimi K3 safely

Start on the filesystem that will hold the model. A nearly full 2 TB drive is not a comfortable target. Kingy.ai recommends at least 2.5 TB free, and preferably 3 TB if you expect staging copies, container layers, updates, or rollback space.

df -h .
python -m pip install -U huggingface_hub
hf version

The commands in this guide were verified with huggingface_hub 1.25.1. Inspect the transfer before fetching any large files:

hf download moonshotai/Kimi-K3 \
  --revision 301be1b88c89c0d3a763da6301352cb8fe399e90 \
  --dry-run

That dry-run should report 114 repository files and roughly 1.6 TB. To review the license, configuration and remote Python code first, exclude the weights:

hf download moonshotai/Kimi-K3 \
  --revision 301be1b88c89c0d3a763da6301352cb8fe399e90 \
  --exclude "model-*.safetensors" \
  --local-dir ./Kimi-K3-metadata

The metadata-only download was tested successfully. Review LICENSE and the custom .py files before loading the model with trust_remote_code=True. That option executes repository-supplied Python. Pin the commit, use an isolated environment, and audit the exact code you are trusting.

When the storage target is ready, download the full pinned snapshot:

hf download moonshotai/Kimi-K3 \
  --revision 301be1b88c89c0d3a763da6301352cb8fe399e90 \
  --local-dir /data/models/Kimi-K3

Download the verified Kimi K3 helper script (.zip) → It defaults to a dry-run, requires 2.5 TB free before a full transfer, resumes completed files and can perform an optional SHA-256 pass.

If the transfer stops, run the same command again. The current client reuses completed files and resumes the snapshot rather than requiring a fresh download. A Hugging Face token is not required for this ungated repository, but authenticating can improve Hub rate limits.

Afterward, confirm the local shard count and byte total:

python3 - <<'PY'
from pathlib import Path

files = sorted(Path("/data/models/Kimi-K3").glob("model-*-of-*.safetensors"))
print("shards:", len(files))
print("bytes:", sum(path.stat().st_size for path in files))
PY

Expected output for the pinned revision is 96 shards and 1,560,936,091,448 bytes. The Hub client checks repository metadata during transfer. For a separate integrity pass, compare each shard’s SHA-256 value with the LFS hashes exposed by the repository API. A full hash pass will read all 1.56 TB and can take hours.

Without --local-dir, Hugging Face stores snapshots in its standard Hub cache, normally under ~/.cache/huggingface/hub. With --local-dir, files go to the selected directory and a small .cache/huggingface metadata folder supports future updates. Do not download to the default cache and then make an unnecessary second 1.56 TB copy.

Idealized transfer times

These are line-rate calculations using bytes × 8 ÷ bits per second. They exclude protocol overhead, Hub or ISP throttling, retries, decompression or verification work, and disk bottlenecks. Real transfers will be slower.

Open weights does not mean consumer-local. The checkpoint alone is more than 65 times the 24 GB VRAM of a common high-end gaming GPU. Sparse routing reduces work per token, but a full server still stores all experts and reserves memory for state, cache and concurrency.

Hardware needed to run Kimi K3

Moonshot lists vLLM, SGLang and TokenSpeed as recommended engines. The most detailed public cluster matrix at release comes from the SGLang Kimi K3 cookbook. Its entries were still marked Not Verified on the final weights and then-current code when checked. Treat them as launch recipes to reproduce, not guaranteed minimum specifications.

HBM figures use official NVIDIA HGX specifications, NVIDIA’s supported-GPU memory table, NVIDIA’s GB200/GB300 compute-node specification, and AMD’s MI350X platform specification. Aggregate HBM is simple multiplication, not usable model capacity and not a guarantee that the recipe will start.

TokenSpeed publishes a more concrete 8×B300 Kimi K3 recipe with a 32,768-token limit, plus an 8×AMD gfx950 recipe at 8,192 tokens. Its NVIDIA path uses a specialized sidecar and expects a flattened local checkpoint. Those are source-reported configurations, not Kingy.ai tests. They also show why a model’s one-million-token limit should not be confused with a default serving setting.

The vLLM Kimi K3 recipe is live, but its July 25 source still calls itself “pre-release,” requires a K3-enabled vLLM 0.26+ nightly, and says its 1,680 GB VRAM estimate should be replaced after publication. It marks H200, B300, GB300 and MI355X profiles verified while separately naming 8×GB300 as the prerequisite. Those stale and conflicting signals need reconciliation on the final checkpoint. The SGLang CUDA 13, CUDA 12 and MI35x ROCm tags were also live, but an available container does not prove a full deployment.

The answer for one consumer GPU is no. The answer for a typical MacBook, gaming PC or single workstation is also no for the official checkpoint and documented engines. CPU or unified-memory offload is theoretically imaginable on a machine with extraordinary capacity, but memory bandwidth, expert movement and interconnect overhead would make it a research stunt, not a practical service. No official consumer-offload recipe was available.

Nor does the maximum 1,048,576-token context arrive automatically on the smallest cluster. Operators trade among context length, simultaneous requests and numerical precision. Shorter context accepts smaller prompts. Lower concurrency serves fewer users at once. FP8 KV cache or BF16 KDA state can reclaim memory, but precision changes should be evaluated for quality and kernel compatibility. The model weights remain unchanged throughout.

License in plain English

The custom Kimi K3 License broadly permits using, copying, modifying, publishing, distributing, sublicensing and selling the software, including the weights and derivatives, subject to conditions.

License summary: Keep the copyright and permission notice with copies or substantial portions. A model-as-a-service business whose aggregate revenue exceeds US$20 million over any consecutive 12 months must make a separate agreement with Moonshot before commercial use. A commercial product or service above 100 million monthly active users or US$20 million in monthly revenue must prominently display “Kimi K3.” The license states exceptions for internal use and access through Moonshot’s official products or certified partners. It provides no warranty.

That is not the same as an established OSI-approved open-source license. “Open-weight under the Kimi K3 License” is the accurate description. This summary is not legal advice; companies near either threshold should have counsel read the original text.

Can Kingy.ai host a copy?

Not in this article, and no mirror is being claimed. A 1.56 TB checkpoint cannot be embedded in a web page. The license appears to permit redistribution when the required notice accompanies substantial copies, but a responsible mirror also needs durable storage, verified files and hashes, preserved attribution, operational headroom, and an egress budget. Curtis has not approved that storage or bandwidth commitment, and Kingy.ai has not completed and verified a mirror. The safer reader service is the official Hugging Face link, a pinned command, the license link and the small download helper supplied with this article.

Who should self-host?

Self-hosting makes sense for organizations that already operate multi-node accelerator clusters and need data control, model modification, predictable internal latency, or sustained high utilization. Even then, teams should budget for fast local storage, host RAM, high-bandwidth GPU links, container images, monitoring, failure recovery and engineering time.

For evaluation, irregular traffic, or teams without cluster operations experience, Kimi’s hosted API is the practical starting point. It turns a capital and operations project into usage-based access. The trade is reliance on an external service and its data, availability and pricing terms.

Kimi K3’s release is meaningful because the complete weights are obtainable. It is also a useful correction to casual talk about “local AI”: ownership of the files and ease of running them are separate questions. Here, the first is unusually open and the second remains a datacenter job.

Frequently asked questions

Are the Kimi K3 weights really public?

Yes. The official Hugging Face repository was public and ungated when checked on July 27, 2026. It contained 96 weight shards plus code, configuration, tokenizer files, an index and the license.

How much disk space does the checkpoint need?

The shards total 1.561 TB, or 1.420 TiB. Plan for at least 2.5 TB free and preferably 3 TB when staging, cache, containers and operational copies are considered.

Can I download only the 104B active parameters?

No official partial checkpoint supports that. The router can choose different experts for different tokens, so sparse activation does not define one fixed 104B subset you can keep and discard the rest.

Can Kimi K3 run on a single 24 GB or 96 GB GPU?

Not the official 1.56 TB checkpoint with the documented serving paths. Community conversions should be treated as experimental until their provenance, completeness, runtime compatibility and demonstrated inference are independently verified.

Does Kimi K3 support a one-million-token prompt on every deployment?

No. One million tokens is the model’s configured maximum. Actual usable context depends on memory reserved for KDA state, MLA cache, activations and concurrent requests. Published launch recipes use much smaller operating limits in some cases.

Is trust_remote_code=True safe?

It runs Python supplied by the model repository. Pin the commit, inspect the downloaded code, isolate the runtime and apply the same controls you would to any third-party software dependency.

Is Kimi K3 open source?

It is safer to call it open-weight under the custom Kimi K3 License. The license grants broad rights but adds commercial conditions and has not been established here as an OSI-approved license.

Methodology

Kingy.ai inspected the official Hugging Face model card, live file API, index and configuration; read the official license and technical report; checked the launch blog and serving documentation; confirmed the listed Docker tags; tested hf download --dry-run; and downloaded only the metadata/code subset. File totals were calculated from live API byte values. HBM totals were calculated from vendor specifications. No full checkpoint, cluster start or throughput test was performed.