Kimi K3 已正式发布完整模型权重。 Moonshot AI 将它称为全球首个开放权重的 3 万亿参数级模型：总参数 2.8 万亿，每个 token 激活约 1040 亿参数，原生支持视觉输入和 100 万 token 上下文。 权重可以从 Hugging Face 免费下载，但“下载免费”不等于“普通电脑可以低成本运行”。 官方模型仓库当前包含 96 个 Safetensors 权重分片，合计约 1.42 TiB，下载、校验、加载和推理都需要服务器级资源。 本文把发布信息、下载命令、硬件判断、部署入口、许可证和性能对比分开说明，避免只看排行榜或一句“全球最强”。
先回答最常见的三个问题
Kimi K3 的完整权重确实已经公开，不是只有 API 或技术报告。
官方入口是 moonshotai/Kimi-K3，GitHub 仓库也明确列出 vLLM、SGLang 和 TokenSpeed 三条部署路线。
模型文件可以免费下载，但完整仓库体积超过 1 TiB，不能按 7B、32B 或普通消费级量化模型的方式估算硬件。
官方基准显示它在部分编程、Agent 和知识工作测试中达到或超过 Claude、GPT-5.6 系列，但并非每一项都第一。
因此，更准确的表述是“开放权重模型中的旗舰级选择”，而不是脱离任务和测试条件宣布绝对最强。
这次开放了哪些内容
官方 GitHub 仓库提供 README、Kimi K3 License 和技术报告。 Hugging Face 模型页提供配置、Tokenizer、自定义建模代码以及完整 Safetensors 权重。 权重不是需要申请才能看到的占位文件，登录 Hugging Face 后可通过 CLI 下载到本地或服务器。 官方也公开模型结构、量化格式、主要评测结果和推荐推理引擎。
但这不是一个完整训练数据包。 “开放权重”表示可以取得并部署模型参数，不等于训练语料、全部训练流水线和每个评测环境都已经公开。 判断开放程度时，应分别查看权重、代码、许可证、训练数据和复现实验，而不是只看项目标题中的 open-source。
2.8 万亿参数怎样工作
Kimi K3 使用 Mixture-of-Experts 架构，共有 896 个专家，每个 token 选择其中 16 个，并使用两个共享专家。 总参数为 2.8T，激活参数约 104B。 这意味着单次推理并不会像一个 2.8T 稠密模型那样激活全部参数，但所有专家权重仍需要存储，并在设备之间组织和传输。
模型共有 93 层，其中注意力层由 69 层 KDA 与 24 层 Gated MLA 组成。 视觉编码器是 MoonViT-V2，约 4.01 亿参数。 上下文上限是 1,048,576 token，但达到协议上限不代表任何部署都能经济地提供 100 万上下文。 KV cache、并发数、输入图片和输出长度都会继续消耗显存。
MXFP4 不能直接等同于“小显存量化版”
Kimi K3 从监督微调阶段开始进行量化感知训练，官方权重采用 MXFP4，激活采用 MXFP8。 这比把 BF16 权重事后压成 4-bit 更接近模型原生设计。 不过，能保存 MXFP4 文件不代表任意 GPU 都能高效执行对应算子。 推理引擎版本、GPU 架构、通信库和内核支持仍会决定能否启动及实际速度。
不要只用“2.8T × 0.5 byte”估算最终磁盘。 仓库还包含视觉模块、尺度信息、索引、Tokenizer 和其他配置；文件系统也要为下载临时文件、缓存和日志预留空间。 部署前应以 Hugging Face 当前文件清单为准，而不是引用发布前的预估数字。
完整权重实际有多大
截至本文核对时，官方模型仓库包含 96 个 .safetensors 分片。
通过 Hugging Face API 汇总这些文件的 size 字段，合计为 1,560,936,091,448 bytes，约 1.42 TiB。
这只是 Safetensors 权重之和，不包含下载中的临时占用、容器镜像、Python 环境和运行日志。
实际部署建议准备至少 2 TiB 可用的高速本地存储。
如果下载工具会保留缓存与 local-dir 两份数据，空间需求可能进一步增加。
机械硬盘适合归档，不适合频繁冷启动超大模型；共享网络盘则要先测吞吐和元数据性能。
下载前先做容量预检
Linux 可以查看目标分区：
|
|
Windows PowerShell 可以检查数据盘：
|
|
除了容量，还要确认文件系统支持大文件、目录配额没有限制、下载账户对目标目录有写权限。 在云服务器上，先计算数据盘、快照和出站流量费用；权重免费下载不代表云磁盘免费。
安装 Hugging Face CLI
在独立 Python 环境中安装当前版 huggingface_hub：
|
|
Windows PowerShell 使用：
|
|
若仓库访问要求登录，在 Hugging Face 创建只读 token：
|
|
不要把 token 放进命令历史、Dockerfile 或公开的部署脚本。
先用 dry-run 查看文件清单
新版本 CLI 支持在真正下载前检查计划：
|
|
如果当前 CLI 不识别 --dry-run，先升级 huggingface_hub，再查看：
|
|
不要因为示例命令与旧版 huggingface-cli 不同，就同时安装多个互相覆盖的环境。
记录 hf --version 和下载开始时的模型 revision，后续才能重现同一份权重。
下载完整仓库
目标目录应位于容量充足的本地 SSD 或高吞吐并行文件系统：
|
|
下载过程中不要反复删除缓存重来。 Hugging Face 的下载器能够复用已完成文件；网络中断后先执行同一命令恢复。 在服务器重启前保存日志，并确认目标目录不是临时系统盘。
固定 revision 避免文件在集群中不一致
模型仓库可能继续更新 README、配置、代码或权重索引。 生产环境应锁定已验证的 commit SHA：
|
|
多节点部署不要让每台机器在不同时间各自下载 main。
先确定 revision，再同步到所有节点，最后比较文件清单和哈希。
滚动更新时保留上一目录，确认新版本能加载后再清理旧权重。
下载完成后不要只数文件
检查索引、总大小和异常小文件：
|
|
确认 config.json、Tokenizer 文件、权重索引和自定义代码都存在。
如果某个分片只有几 KB，可能拿到的是 Git LFS/Xet 指针或未完成临时文件。
不要在不完整目录上反复启动推理服务，让错误日志淹没真正的下载问题。
普通电脑可以运行 Kimi K3 吗
完整权重不适合普通台式机、游戏本或单张消费级 GPU。 仅权重就约 1.42 TiB，实际服务还需要运行时、激活、通信缓冲和 KV cache。 即使通过 CPU offload 勉强保存全部权重，内存带宽和磁盘换入也会使交互速度失去实用性。
不要把“每 token 激活 104B”理解成只需要加载 104B 参数。 MoE 路由会在不同 token 间选择不同专家，完整专家集合仍需可访问。 个人用户想体验模型，应优先选择 Kimi 官方 API、认证推理供应商或 Kimi Code，而不是先购买硬件。
服务器配置要从引擎配方反推
官方没有给出一张适用于所有 GPU 的单机最低配置表。 合理做法是先选择 vLLM、SGLang 或 TokenSpeed 的官方 Kimi K3 配方，再核对支持的 GPU 型号、节点数、互联和精度。 超大 MoE 部署通常需要多 GPU 甚至多节点，并依赖高速 NVLink、NVSwitch 或 InfiniBand 类互联。
显存总量只是第一关。 节点间带宽不足会让专家并行通信成为瓶颈；驱动、CUDA、NCCL 和推理引擎版本不匹配则可能在加载前就失败。 准备机器时应同时记录 GPU 架构、单卡显存、拓扑、系统内存和本地盘吞吐。
用 vLLM 前先核对专用 recipe
官方仓库推荐 vLLM，并链接到 Kimi K3 的部署配方。 先创建隔离环境并记录版本：
|
|
Hugging Face 页面给出的通用入口是：
|
|
对 Kimi K3 这种规模的模型，这条命令只是接口形式，不是单卡部署承诺。 张量并行、专家并行、多节点地址、端口和内存参数必须采用当前 recipe 中与硬件对应的配置。 不要凭其他 MoE 模型的参数猜测并行拓扑。
SGLang 也是官方推荐路线
基础启动入口如下：
|
|
先绑定 127.0.0.1 做本机验证，不要直接把未鉴权模型服务开放到公网。
完整集群同样要根据 SGLang 官方 cookbook 配置并行方式、节点发现和通信参数。
若日志显示不支持 MXFP4、未知架构或缺少自定义代码，先核对引擎版本与 Kimi K3 支持状态。
用 OpenAI 兼容接口做首次请求
服务健康后发送一条短文本请求：
|
|
模型始终启用 thinking，并通过 reasoning_content 返回推理内容。
首次测试使用短上下文和低并发，确认文本、推理字段、结束原因和 token 统计，再逐步增加负载。
不要一启动就提交 100 万 token 输入，这会把模型加载问题与 KV cache 压力混在一起。
多轮对话必须保留思考历史
Kimi K3 使用 preserved thinking history 模式。
继续多轮对话或工具调用时，需要把上一轮 assistant message 按原样放回 messages，包括 reasoning_content 和 tool_calls。
只保存最终 content 可能破坏模型延续推理和工具状态的能力。
应用数据库也要能保存这些字段。 若考虑隐私或存储成本，应在产品设计阶段决定保留时间，而不是在请求前随意删除部分历史。 对外展示时可以隐藏推理文本，但发送给模型的历史结构仍应遵守官方协议。
“性能直逼 Claude、GPT-5.6”怎样理解
官方表格并不是 Kimi K3 在所有指标上都获胜。 例如 Terminal-Bench 2.1 中，Kimi K3 为 88.3，GPT-5.6 Sol 为 88.8；DeepSWE 分别为 67.5 和 73.0。 但在 FrontierSWE 中，Kimi K3 为 81.2，高于表中的 GPT-5.6 Sol 71.3；SWE-Marathon 中 Kimi K3 为 42.0，GPT-5.6 Sol 为 39.0。 BrowseComp 的官方表格中，Kimi K3 为 91.2，GPT-5.6 Sol 为 90.4，Claude Opus 4.8 为 84.3。
这些数据支持“部分编程与 Agent 任务达到闭源旗舰水平”。 它们不支持“任何场景都全面超过所有闭源模型”。 模型选择还要测试中文质量、延迟、吞吐、工具框架、拒答行为、输出稳定性和实际成本。
横向基准不能忽略 harness 差异
官方说明不同模型并不总使用同一个 Agent 框架。 Kimi K3 可能搭配 Kimi Code 或 Claude Code，GPT-5.6 Sol 通常搭配 Codex，其他模型也可能使用各自最优 harness。 不同工具、提示词、上下文压缩策略和最大思考强度都会影响结果。
部分分数来自模型厂商测试，部分引用第三方榜单，还有一些是内部 benchmark。 阅读表格时要继续查看脚注、运行次数、硬件和任务子集。 企业选型最好拿自己的代码库、文档和工具链做盲测，不要只按一列总分采购集群。
Kimi K3 License 不是标准宽松许可证的简单复制
许可证允许使用、复制、修改、发布、分发、再许可、销售、部署和微调，但包含额外商业条件。 若企业及关联方经营 Model as a Service，连续 12 个月总收入超过 2000 万美元，需要另行与 Moonshot AI 达成协议，才能将软件或衍生版本用于商业目的。
商业产品或服务若月活超过 1 亿，或月收入超过 2000 万美元，需要在界面显著展示 “Kimi K3”。 许可证对内部使用、官方产品和认证推理合作方另有例外说明。 准备商用、再分发或提供模型服务时，应由法务阅读完整许可证，不能只写“免费商用”。
权重下载后的安全边界
Hugging Face 示例使用 trust_remote_code=True，这意味着加载模型时允许执行仓库中的自定义 Python 代码。
在生产服务器上，应先锁定 revision、审查代码，再在非特权容器或专用账户中运行。
不要让模型服务账户读取 SSH 私钥、云凭据或生产数据库备份。
API 端口前应配置认证、TLS、请求体限制和速率限制。 对图片、视频和超长上下文设置大小上限，防止单个请求占满 KV cache 或磁盘。 保存提示词与推理日志时执行脱敏，并明确用户数据保留期限。
常见下载问题
No space left on device 不一定是目标盘真的满了，也可能是缓存默认写到了较小的系统盘。
检查 HF_HOME、容器挂载和临时目录实际位置。
下载速度突然归零时，先看磁盘写入和文件校验，不要立即杀死进程。
出现 401 或 403 时，检查 token 权限、登录账户和仓库访问条款。
出现 checksum 或分片缺失时，重新运行同一 revision 的下载命令，让工具补齐文件。
多节点找不到模型时，比较挂载路径和权限；相同目录名不代表各节点看到同一块存储。
常见启动失败
unknown model type 通常意味着 Transformers 或推理引擎版本尚未包含 Kimi K3 支持。
unsupported quantization 指向 MXFP4 内核、GPU 架构或引擎构建不匹配。
NCCL timeout 多与节点网络、网卡选择、防火墙或并行拓扑有关，不应通过无限增加超时掩盖。
若加载到一半被系统杀死，检查 GPU 显存之外的主机内存和 cgroup 限制。 能加载但速度异常慢时，记录每张卡利用率、跨卡流量、首 token 延迟与解码速度。 只有部分 GPU 空闲，通常说明并行配置或专家分布没有按预期生效。
什么时候应直接用 API
个人开发、功能验证、低并发应用和没有 GPU 集群的团队，优先使用 Kimi API 或认证推理服务。 API 不需要下载 1.42 TiB 权重，也不承担引擎升级、故障恢复和集群通信成本。 已有的 Kimi K3 API 调用、视觉输入与工具使用示例可参考：Kimi K3 API 快速入门。
本地部署更适合必须控制权重、隔离数据、修改推理栈，或拥有现成高端 GPU 集群的组织。 即使这样，也建议先通过 API 建立质量基准，再衡量自托管吞吐、延迟与总拥有成本。 “已经下载成功”只是部署开始，不是服务达到生产标准。
上线前记录一份可复现清单
- 模型仓库 commit SHA 与许可证版本。
- 96 个权重分片的数量、总大小和校验状态。
- 推理引擎、PyTorch、CUDA、驱动与 NCCL 版本。
- GPU 型号、节点拓扑、显存和主机内存。
- 上下文长度、并发、thinking effort 与最大输出。
- 首 token 延迟、输出速度、错误率和峰值资源。
- 自有任务集上与 API、Claude、GPT-5.6 的对比结果。
- API 鉴权、日志脱敏、限流和数据保留策略。
完成这些记录，后续升级权重或引擎时才能判断性能变化来自哪里。
官方入口
Kimi K3 的意义不仅是发布了一个高分模型，更在于完整旗舰权重已经可以被研究、审查和部署。 但 1.42 TiB 权重、集群通信和自定义许可证也决定了它不是面向普通电脑的一键本地模型。 先通过官方 API 验证任务效果，再按固定 revision 下载，并依据 vLLM 或 SGLang 的 Kimi K3 专用配方规划集群，是更稳妥的采用顺序。