Kimi K3 has officially released full model weights. Moonshot AI calls it the world’s first 3 trillion parameter-level model with open weights: 2.8 trillion total parameters, each token activates approximately 104 billion parameters, and natively supports visual input and 1 million token contexts. The weights can be downloaded for free from Hugging Face, but “free to download” does not mean “can be run on a regular computer at low cost.” The official model repository currently contains 96 Safetensors weight shards, totaling approximately 1.42 TiB. Server-level resources are required for downloading, verification, loading, and inference. This article explains the release information, download commands, hardware judgment, deployment entrance, license and performance comparison separately to avoid just looking at the rankings or the sentence “the strongest in the world”.
Answer the three most common questions first
The full weights of Kimi K3 have indeed been made public, not just the API or technical report.
The official entrance is moonshotai/Kimi-K3, and the GitHub repository also clearly lists three deployment routes: vLLM, SGLang and TokenSpeed.
The model file is free to download, but the full repository size exceeds 1 TiB, and the hardware cannot be estimated in the same way as 7B, 32B, or ordinary consumer-grade quantized models.
Official benchmarks show that it meets or exceeds the Claude, GPT-5.6 series in some programming, agent, and knowledge work tests, but not every one is first.
Therefore, a more accurate statement is “flagship-level choice in the open weight model” rather than declaring the absolute strongest out of mission and test conditions.
What Moonshot AI released
README, Kimi K3 License and technical reports are available in the official GitHub repository. The Hugging Face model page provides configuration, tokenizer, custom modeling code, and full Safetensors weights. The weight is not a placeholder file that needs to be applied to see. It can be downloaded to the local or server through the CLI after logging in to Hugging Face. The official also disclosed the model structure, quantitative format, main evaluation results and recommended reasoning engine.
But this is not a complete training data package. “Open weights” means that model parameters can be obtained and deployed, which does not mean that the training corpus, all training pipelines, and each evaluation environment have been made public. When judging the degree of openness, you should look at the weight, code, license, training data and replication experiments separately, rather than just looking at the open-source in the project title.
How 2.8 trillion parameters work
Kimi K3 uses a Mixture-of-Experts architecture, with a total of 896 experts, 16 of which are selected for each token, and two shared experts are used. The total parameters are 2.8T and the activation parameters are about 104B. This means that a single inference does not activate all parameters like a 2.8T dense model, but all expert weights still need to be stored, organized and transferred between devices.
The model has a total of 93 layers, of which the attention layer consists of 69 layers of KDA and 24 layers of Gated MLA. The visual encoder is MoonViT-V2, ~401 million parameters. The context cap is 1,048,576 tokens, but reaching the protocol cap does not mean that any deployment can economically provide 1 million contexts. KV cache, concurrency number, input image and output length will continue to consume VRAM.
MXFP4 cannot be directly equated to the “small memory quantized version”
Kimi K3 starts quantization-aware training from the supervised fine-tuning stage. The official weights use MXFP4 and the activation uses MXFP8. This is closer to the model’s native design than compressing the BF16 weights into 4-bit afterwards. However, being able to save MXFP4 files does not mean that any GPU can efficiently execute the corresponding operators. Inference engine version, GPU architecture, communications libraries, and kernel support still determine launch and actual speed.
Don’t just use “2.8T × 0.5 byte” to estimate the final disk. The repository also contains vision modules, scale information, indexes, tokenizers, and other configurations; the file system also reserves space for downloading temporary files, cache, and logs. Hugging Face’s current documentation list should be used as a guideline before deployment, rather than quoting pre-launch estimates.
How large the complete weights are
As of the time of checking for this article, the official model repository contains 96 .safetensors shards.
Summarizing the size fields of these files through the Hugging Face API, the total is 1,560,936,091,448 bytes, approximately 1.42 TiB.
This is only the sum of Safetensors weights, excluding temporary occupation in downloads, container images, Python environments and running logs.
For actual deployment, it is recommended to prepare at least 2 TiB of available high-speed local storage.
If the download tool retains two copies of the cache and local-dir data, the space requirements may further increase.
Mechanical hard disks are suitable for archiving, but are not suitable for very large models with frequent cold starts; for shared network disks, throughput and metadata performance must be tested first.
Do a capacity pre-check before downloading
Linux can view the target partition:
|
|
Windows PowerShell can check the data disk:
|
|
In addition to capacity, make sure the file system supports large files, there are no restrictions on directory quotas, and the download account has write permissions on the target directory. On the cloud server, first calculate the data disk, snapshot and outbound traffic costs; free downloading of weights does not mean that the cloud disk is free.
Install Hugging Face CLI
Install the current version of huggingface_hub in a standalone Python environment:
|
|
Windows PowerShell usage:
|
|
If repository access requires login, create a read-only token in Hugging Face:
|
|
Don’t put tokens in command histories, Dockerfiles, or public deployment scripts.
First use dry-run to view the file list
New version of the CLI supports checking the plan before actually downloading:
|
|
If the current CLI does not recognize --dry-run, upgrade huggingface_hub first, and then check:
|
|
Do not install multiple overlapping environments at the same time just because the example commands are different from the old version huggingface-cli.
Record hf --version and the model revision at the beginning of the download so that the same weight can be reproduced later.
Download the complete model repository
The target directory should be on a local SSD or high-throughput parallel file system with sufficient capacity:
|
|
Do not delete the cache repeatedly during the download process. Hugging Face’s downloader can reuse completed files; after the network is interrupted, execute the same command to restore it. Save the log before restarting the server and confirm that the target directory is not a temporary system disk.
Pin a revision across every cluster node
The model repository may continue to update README, configuration, code, or weight indexes. Production environments should lock the verified commit SHA:
|
|
For multi-node deployments, do not allow each machine to download main at different times.
First determine the revision, then synchronize to all nodes, and finally compare the file list and hash.
Keep the previous directory during rolling updates, and then clean up the old weights after confirming that the new version can be loaded.
Validate more than the file count
Check index, total size and unusual small files:
|
|
Confirm that config.json, Tokenizer files, weight indexes, and custom code all exist.
If a shard is only a few KB, you may have downloaded a Git LFS/Xet pointer or an incomplete temporary file.
Do not repeatedly start the inference service on an incomplete directory and let the error logs drown out real download problems.
Can an ordinary computer run Kimi K3?
Full weights are not suitable for regular desktops, gaming laptops, or single consumer GPUs. The weight alone is about 1.42 TiB, and the actual service also requires runtime, activation, communication buffering, and KV cache. Even if all weights are barely saved via CPU offload, memory bandwidth and disk swapping will make the interaction speed impractical.
Don’t understand “activating 104B per token” as meaning that only 104B parameters need to be loaded. MoE routing will select different experts between different tokens, and the complete set of experts still needs to be accessible. Individual users who want to experience the model should first choose Kimi official API, certified inference providers or Kimi Code instead of purchasing hardware first.
Derive server requirements from the inference recipe
The official does not provide a single-machine minimum configuration table that applies to all GPUs. It makes sense to first select the official Kimi K3 recipe of vLLM, SGLang or TokenSpeed, and then check the supported GPU models, node count, interconnects and accuracy. Very large MoE deployments often require multiple GPUs or even multiple nodes and rely on high-speed NVLink, NVSwitch or InfiniBand type interconnects.
The total amount of VRAM is only the first level. Insufficient bandwidth between nodes can cause expert parallel communication to become a bottleneck; mismatched driver, CUDA, NCCL, and inference engine versions may fail before loading. When preparing the machine, you should also record the GPU architecture, single-card VRAM, topology, system memory, and local disk throughput.
Check the dedicated recipe
before using vLLM The official repository recommends vLLM and links to the deployment recipe for Kimi K3. First create an isolation environment and record the version:
|
|
The general entrance given by the Hugging Face page is:
|
|
For a model of the size of the Kimi K3, this command is interface form only, not a single-card deployment commitment. Tensor parallelism, expert parallelism, multi-node address, port and memory parameters must use the configuration corresponding to the hardware in the current recipe. Do not guess parallel topology based on parameters of other MoE models.
SGLang is also the official recommended route
The basic startup entrance is as follows:
|
|
First bind 127.0.0.1 for local verification. Do not directly open the unauthenticated model service to the public network.
The complete cluster also needs to configure the parallel mode, node discovery and communication parameters according to the SGLang official cookbook.
If the log shows that MXFP4 is not supported, the architecture is unknown, or custom code is missing, first check the engine version and Kimi K3 support status.
Make the first request using OpenAI compatible interface
Send a short text request after the service is healthy:
|
|
The model always enables thinking and returns inference content via reasoning_content.
Use short context and low concurrency for the first test, confirm the text, inference fields, end reasons and token statistics, and then gradually increase the load.
Don’t submit 1 million tokens as input as soon as you start, as this will mix model loading issues with KV cache pressure.
Multiple rounds of dialogue must retain thinking history
Kimi K3 uses preserved thinking history mode.
When continuing multiple rounds of conversations or tool calls, you need to put the previous assistant message back to messages as it is, including reasoning_content and tool_calls.
Saving only the final content may destroy the model’s ability to carry over inference and tool state.
The application database must also be able to store these fields. If privacy or storage costs are a concern, retention times should be determined during the product design phase rather than haphazardly deleting portions of history before requesting it. The inference text can be hidden when displayed externally, but the historical structure sent to the model should still comply with the official protocol.
“Performance comparable to Claude and GPT-5.6” How to understand
Official form Not that the Kimi K3 wins on every metric. For example, in Terminal-Bench 2.1, Kimi K3 is 88.3, GPT-5.6 Sol is 88.8; DeepSWE is 67.5 and 73.0 respectively. But in FrontierSWE, Kimi K3 is 81.2, which is higher than the GPT-5.6 Sol 71.3 in the table; in SWE-Marathon, Kimi K3 is 42.0, and GPT-5.6 Sol is 39.0. In the official BrowseComp table, Kimi K3 is 91.2, GPT-5.6 Sol is 90.4, and Claude Opus 4.8 is 84.3.
The data supports “some programming and Agent tasks reaching closed-source flagship levels.” They do not support “any scenario comprehensively exceeding all closed source models”. Model selection also tests Chinese quality, latency, throughput, tool framework, refusal behavior, output stability and actual cost.
Cross-model benchmarks cannot ignore harness differences
Officially, different models do not always use the same Agent framework. Kimi K3 may be paired with Kimi Code or Claude Code, GPT-5.6 Sol is usually paired with Codex, and other models may also use their own optimal harness. Different tools, prompts, context compression strategies, and maximum thinking intensity all affect the results.
Some scores come from model manufacturer tests, some refer to third-party lists, and some are internal benchmarks. As you read the table continue looking at the footnotes, number of runs, hardware, and task subsets. When selecting an enterprise, it is best to conduct a blind test with its own code base, documentation, and tool chain. Do not purchase clusters based on just one column of total scores.
Kimi K3 License is not a simple copy of the standard permissive license
The license permits use, copying, modification, publication, distribution, sublicense, sale, deployment and fine-tuning, subject to additional commercial conditions. If the enterprise and its affiliates operate Model as a Service and the total revenue exceeds US$20 million for 12 consecutive months, a separate agreement with Moonshot AI is required to use the software or derivative versions for commercial purposes.
If a commercial product or service has more than 100 million monthly active users, or a monthly revenue of more than 20 million U.S. dollars, “Kimi K3” needs to be prominently displayed on the interface. The license states exceptions for internal use, official products, and certified reasoning partners. When preparing for commercial use, redistribution or providing model services, the legal department should read the complete license and cannot just write “free commercial use”.
Security boundary after weight download
The Hugging Face example uses trust_remote_code=True, which means that custom Python code in the repository is allowed to be executed when loading the model.
On production servers, revisions should be locked down and code reviewed before running in an unprivileged container or dedicated account.
Don’t let the model service account read SSH private keys, cloud credentials, or production database backups.
Authentication, TLS, request body limit and rate limit should be configured before the API port. Set size limits for images, videos, and very long contexts to prevent a single request from filling up the KV cache or disk. Perform desensitization when saving prompts and inference logs, and clarify the retention period of user data.
Common download problems
No space left on device It may not necessarily mean that the target disk is really full, or it may be that the cache is written to a smaller system disk by default.
Check HF_HOME, container mount and temporary directory actual location.
When the download speed suddenly returns to zero, check disk writing and file verification first, and do not kill the process immediately.
When 401 or 403 appears, check the token permissions, login account and repository access terms.
When a checksum or shard is missing, rerun the download command of the same revision and let the tool complete the file.
When multiple nodes cannot find a model, compare the mounting path and permissions; the same directory name does not mean that each node sees the same piece of storage.
Common startup failures
unknown model type usually means that the Transformers or inference engine version does not yet contain Kimi K3 support.
unsupported quantization points to a MXFP4 core, GPU architecture, or engine build mismatch.
NCCL timeout is mostly related to node network, network card selection, firewall or parallel topology and should not be masked by increasing the timeout infinitely.
If it is killed by the system halfway through loading, check the host memory and cgroup limits outside of GPU memory. When it can be loaded but the speed is abnormally slow, record each card utilization, cross-card traffic, first token delay and decoding speed. Only part of the GPU is idle, usually indicating that the parallel configuration or expert distribution is not working as expected.
When should you use API
directly? For personal development, functional verification, low-concurrency applications and teams without GPU clusters, Kimi API or certified inference service is preferred. The API does not require downloading of 1.42 TiB weights and does not incur engine upgrade, failure recovery, and cluster communication costs. For existing Kimi K3 API calls, visual input and tool usage examples, please refer to: [Kimi K3 API Quick Start] (/en/2026/07/18/kimi-k3-api-python-streaming-vision-tools-quickstart/).
On-premises deployment is better suited for organizations that must control weights, isolate data, modify the inference stack, or have high-end GPU clusters readily available. Even then, it is recommended to first establish a quality baseline through the API before measuring self-hosted throughput, latency, and total cost of ownership. “Downloaded successfully” is just the start of deployment, not that the service has reached production standards.
Record a reproducible list before going online
- Model repository commit SHA and license version.
- The number, total size, and check status of 96 weighted shards.
- Inference engine, PyTorch, CUDA, driver and NCCL versions.
- GPU model, node topology, VRAM, and host memory.
- Context length, concurrency, thinking effort and maximum output.
- First token latency, output speed, error rate, and peak resources.
- Comparison results with API, Claude, and GPT-5.6 on our own task set.
- API authentication, log masking, current limiting and data retention policies.
After completing these records, you can determine where the performance changes come from when upgrading weights or engines later.
Official resources
The significance of Kimi K3 is not only the release of a high-scoring model, but also that the full flagship weight can already be studied, reviewed and deployed. But the 1.42 TiB weight, cluster communication and custom license also determine that it is not a one-click local model for ordinary computers. It is a safer choice to first verify the task effect through the official API, then download according to the fixed revision, and plan the cluster according to vLLM or SGLang’s Kimi K3 special recipe.