Kimi K3：2.8T 参数、1M 上下文与 1.56TB 权重

K3 是 2.8 万亿参数、每 token 激活 104B 的混合专家模型，支持 1,048,576 token 上下文，权重在 2026 年 7 月 27 日放进 Hugging Face，118 个文件约 1.56TB。这四个数字里，只有「1M 上下文」对普通用户有直接感知，其余三个影响的是能不能自己部署。另外要提醒一句：截至 2026 年 11 月，K3 已经不是旗舰，10 月 24 日发布的 K3.1 Pro 才是。

2.8T 和 104B：两个数字必须一起看

2.8T 是总参数量，104B 是每个 token 实际参与计算的参数量。MoE 架构下这两个数差得很远是正常的，但差 27 倍属于激进。

具体结构是 896 个路由专家，每个 token 选 16 个，另有 2 个共享专家。93 层里，69 层是 Kimi Delta Attention（线性注意力），24 层是 Gated MLA（全注意力），比例 3:1。这个混搭是为了在百万级上下文下把解码成本压下来，官方给出的数字是百万 token 场景下解码最高快 6.3 倍。

只看 2.8T 会误判成本。真正决定推理开销的是 104B——它比上一代 K2.6 的 32B 激活高了约 3.3 倍，这也是 API 单价定在那个位置的直接原因。

1.56TB 是下载体积，不是显存

这是最容易被搞混的一点。1.56TB 指的是权重文件总大小，按 2026 年 7 月 27 日的仓库快照，118 个文件合计 1,560,998,984,390 字节，其中 96 个是 safetensors 分片。

为什么不是 BF16 下该有的五六 TB？因为官方在训练阶段就做了量化感知，权重是 MXFP4、激活是 MXFP8，从监督微调阶段就开始用这个精度训练，不是事后压缩。省掉了四分之三的体积，也省掉了自己验证量化损失的工作。

但跑起来需要的内存并不会因此变小太多。按 1.4TB 常驻显存估算，单机 8 卡 B300（288GB×8）才刚够放权重加 KV cache，另一条路是跨两节点 16 卡 B200。想算自己机器够不够，可以用 本地跑大模型的显存对照表，把参数量和精度代进去就能看出差距。

许可证不是 MIT

K3 用的是自定义的 Kimi K3 License，在 Hugging Face 上标记为 license: other，不是 MIT 也不是 Apache 2.0。

条款主体接近 MIT：可以下载、运行、修改、微调、分发、商用，不收许可费。但加了两条阈值。

一条针对模型即服务：如果集团连续 12 个月营收超过 2000 万美元，且对外提供 K3 的推理或微调服务，需要先和月之暗面单独签约。纯内部使用、以及通过官方产品或认证伙伴访问，都豁免。

另一条是署名：产品月活超过 1 亿或月收入超过 2000 万美元，界面上要显著标注「Kimi K3」。

对普通工程团队，这两条都碰不到。真正拦住人的是显存，不是法务。

对不自己部署的人，实际影响只有三条

第一，长文档和长代码库真的能一次塞进去。1M token 大致相当于一次读完几百页材料，但会员那边只有 Max 和 Ultra 解锁这个容量。低档位具体给多少上下文，官方会员页没有写明，只写了「Max 和 Ultra 可解锁 1M」。想验证自己手上的文档到底超没超，先按 token 估一遍再决定要不要升档。

第二，默认思考强度是 max。官方在发布时说明后续才补 low 和 high 两档，这意味着刚上手时响应会偏慢，因为模型默认在长思考。

第三，K3 的定位是长程编程和知识工作。它能连续跑几小时的工程任务，看截图改前端、调 kernel、写编译器，这些是官方演示里反复出现的场景。日常问答用不出差别，别为这个升级。

需要 API 的话，K3 现在是 3 美元输入 / 15 美元输出每百万 token，比 K3.1 Pro 的 2 / 10 更贵。新项目直接上 K3.1 Pro，K3 只在需要复现旧结果时才用。国内站的计价是人民币，20 元输入 / 100 元输出，和美元价不是按汇率简单换算，横向对照见 11 月大模型 API 价格表。