深入 Kimi-K3：Hugging Face 仓库分析 Moonshot 在 2026 年 7 月 27 日把 Kimi-K3 的权重推上了 Hugging Face。发布报道定下了几个基本事实。 模型有 2.8 万亿参数，是迄今最大的开放权重发布。它能读一百万 token 的上下文，原生看图，而且每次请求都在思考。 发布当天我一直泡在 Hugging Face 仓库 moonshotai/Kimi-K3 里，把每个 Python 和配置文件都读了一遍。代码印证了 Moonshot 发布时点名的两项技术：Kimi Delta Attention 和 Attention Residuals。 它还藏着几件没人提过的事。 顶层是一个 Llava 的后代：一个叫 MoonViT-3D 的视觉塔、一个小投影器，加一个叫 KimiLinearForCausalLM 的文本主干。这个主干注册了自己的模型类型，单拎出来也能当语言模型跑。 文件头部的注释说这是参考实现。它是认真的。 先从算术开始。配置写着 93 层、隐藏维度 7,168、词表 163,840。除第一层外每层都是混合专家：896 个路由专家，每 token 激活 16 个，另有一对常开的共享专家。每个路由专家 3,300 万参数。 所以光专家池就是 92 乘 896 乘 33.0M，等于 2.72 万亿。注意力再加 362 亿。共享专家、latent 投影、词嵌入、一层稠密 FFN 和视觉部分再贡献约 200 亿。 总计：2.780 万亿。媒体说的是 2.8。我把数字算了两遍，因为对得这么齐通常意味着哪里错了。这次没错。每 token 大约 1,050 亿参数在干活，稀疏率接近 26 比 1。 注意力遵循严格的循环。三层 Kimi Delta Attention 接一层全注意力，重复 23 轮。末尾再补一层全注意力，所以整栈以连续两层全局层收尾。配置里这些列表从 1 开始编号，运行时悄悄加一换算。 KDA 是 Moonshot 的 delta 规则线性注意力。Q、K、V 各自先过一段带 SiLU 的短卷积。 核函数内部对 Q 和 K 做 L2 归一化。衰减按通道进行，由低秩投影加每头参数驱动，并设了负五的下限，保证任何通道都不会一步清空状态。 K3 把输出门升级成了满秩。内部宽度让我意外：96 个头乘维度 128 是 12,288，等于隐藏维度的 1.7 倍。 状态大小与上下文无关。69 层 KDA 合计每条序列约 1.09 亿个数值，fp32 下约 434MB。 十个 token 还是一百万个，成本一样。 全注意力层更奇怪。它们借用了 DeepSeek-V3 的 latent attention 几何：query 秩 1,536，key-value 秩 512，96 个头。 然后模块断言了一个叫 use_nope 的开关，把旋转位置编码设成 None。从头到尾没有任何旋转。 本该承载 RoPE 的那 64 维，以 MQA 式共享额外 key 的身份随行。位置信息完全来自因果掩码和 KDA 层自带的近因性。 这就是 1,048,576 token 的窗口不需要 YaRN、不玩 theta 把戏的原因。根本没有旋转可外推。 每个全局层还用 sigmoid 给输出加了门，这是 Kimi Linear 一脉对付 attention sink 的老习惯。 缓存的账随之而来。93 层里只有 24 层需要缓存，生产环境缓存的是压缩后的 512 加 64 latent。 fp8 下每 token 13.5KB，装满一百万 token 的上下文是 13.8GB。首发适配的部署笔记给出的数字是：八张 B300、KV 容量 4,437,504 token、加载后每卡剩约 73GB。 验算一下：444 万乘 13.5KB 是 61.3GB。只要缓存按卡复制，装得下。 数字不用硬凑就对上了。作为对照，这个仓库里的参考缓存存的是展开后的逐头 K/V，每 token 1.5MB。 它是为正确性存在的。没人应该拿它上线。 Attention Residuals 解释了配置里那个设成 12 的 attn_res_block_size。残差流被切成了段。 每十二层，累加和被存成一个检查点，然后重新开始累加。第 0 层也算，所以第一个检查点就是原始的 token embedding。 整个深度上累积出八个检查点。在每次注意力、每次 FFN 和最终归一化之前，输入都由一次微型的深度注意力重建：把各检查点加当前累加和做归一化，与一个学到的查询向量打分，softmax，加权合并。 每个 token 都在对自己的层间历史做注意力。每层代价约 2.9 万参数，基本等于免费。 Moonshot 称这项技术是残差连接的即插即用替代，且随规模稳定增益。代码与这句话逐行吻合。 Latent MoE 解开了另一个谜之字段：routed_expert_hidden_size 等于 3,584。正好是隐藏维度的一半。 路由专家住在一个瓶颈里。一个共享投影先把每个 token 降到 3,584。 选中的 16 个专家各跑一个 3,584 到 3,072 再回 3,584 的 MLP。加权和过一次 RMSNorm，再由第二个投影抬回 7,168，然后加上全宽的共享专家。 路由器用 sigmoid 打分，外加一个只影响选择、不碰混合权重的学习偏置。分组路由被彻底关掉。 宽度减半一举多得。专家缩到 33M，896 个才装得下。 每 token 计算量随之减半。专家并行的 all-to-all 传的也是 3,584 宽的激活，网络流量同样减半。 我猜正是最后这一条，让节点受限路由变得没有必要。 SiTU 是我花时间最久才看明白的部分。这个激活函数把 FFN 输入劈成 gate 和 up 两半。 gate 一侧算 4 * tanh(gate/4) * sigmoid(gate)。up 一侧被软削顶为 25 * tanh(up/25)。 两者相乘，全程 float32。接近零时它贴着 SiLU 走。 远离零时它在正负四附近平滑饱和。SiTU 就是把振幅圈起来的 SwiGLU。 圈栏的理由写在隔壁的配置块里：激活离群值会毁掉四比特权重和 fp8 缓存，而有界激活能让量化误差老实。K2 训练时有 MuonClip 压住注意力 logits。 SiTU 读起来像它在 FFN 侧的对应物。推理栈甚至直接用它命名内核。 量化用的是 MXFP4。四比特浮点、32 个一组、每组共享一个 uint8 指数，这是 Blackwell 原生支持的格式。 仅权重量化，激活保持 bf16。检查点不带 KV 缩放系数，所以加载器把 fp8 KV scale 默认为 1.0 并给出警告。 ignore 列表是一手漂亮的正则活。凡是叫 self_attn 的模块统统跳过，而两种注意力共用这个属性名，一条规则护住全部 93 层。 共享专家、稠密 FFN、输出头和视觉部分按名字跳过。路由专家用 w1/w2/w3 命名，漏过所有规则，被量化。 结果：2.780 万亿中的 2.727 万亿按每权重 4.25 比特存放，约 1.45TB，外加约 105GB 的 bf16。落盘算 1.56TB。 部署数字反推八张 B300 上约消耗 1.58TB。相差百分之二。 config.json 里藏着一个坑。那些采样字段，temperature 1.0、top_k 50、do_sample false，全是序列化的默认样板。 generation_config.json 只钉了两个值：max_length 1,048,576 和 eos 163586。整个仓库没给任何采样建议。 按前沿标准，视觉塔很小。27 层、隐藏 1,024，注意力加宽到 1,536、十二个头，RMSNorm，全程无偏置。 位置编码上了两道，一道是插值的可学习网格，一道是每层都有的 2D RoPE。2 乘 2 合并让每 28 乘 28 像素变成一个 token。 预算高达每图 65,536 个 patch，即 16,384 个视觉 token、边长最高 7,168 像素。透明图会在缩放后合成到八像素棋盘格上，模型看到的透明就是编辑器里那种样子。 配置里还躺着一整套视频管线：每秒八帧采样、四帧合并、文本时间戳，而处理器目前仍拒绝除图片外的一切。水管装好了，龙头还没开。 图片进入 prompt 的方式很怪。每张图贡献一段字面文本 "image {width}x{height}"，外加一个 media_pad token，id 163605。 到 embedding 阶段，这一个 token 会展开成图片真实的 token 数，位置 id 也随之重排。模型是用文字读到自己输入分辨率的。 聊天格式里没有一行 Jinja。apply_chat_template 是纯 Python。四个控制 token 撑起全部结构：open、close、sep，以及兼任生成终止符的 end_of_msg。标签名和属性都是普通文本，格式扩展不用铸造新 token。一段渲染后的对话如下， 换行是我加的： <|open|>message role="user"<|sep|>首尔今天天气怎么样？<|close|>message<|sep|><|end_of_msg|> <|open|>message role="assistant"<|sep|> <|open|>think<|sep|>...推理...<|close|>think<|sep|> <|open|>response<|sep|>我来查一下。<|close|>response<|sep|> <|open|>tools<|sep|> <|open|>call tool="get_weather" index="1"<|sep|> <|open|>argument key="city" type="string"<|sep|>Seoul<|close|>argument<|sep|> <|close|>call<|sep|> <|close|>tools<|sep|> <|close|>message<|sep|><|end_of_msg|> <|open|>message role="tool" tool="get_weather" index="1"<|sep|>{"temp": 31}<|close|>message<|sep|><|end_of_msg|> <|open|>message role="assistant"<|sep|><|open|>think<|sep|> <- 生成提示符 K2 几乎为其中每个概念都花了一个专用 token。tokenizer 文件里还留着那份 K2 时代的默认列表当化石，被随附的配置悄悄覆盖。 注入防护是内建的。用户文本编码时禁用特殊 token，就算敲出 close 序列也只会变成普通字节。 属性值只转义 & 符号和双引号，这就够了，因为作用域只能靠真正的控制 token 关闭。还有分块保护罩护着正则引擎。 写这些的人，显然被病态输入在凌晨三点叫醒过。 思考通道是结构性的。每个 assistant 轮次都带 think 标签，有没有内容都在，序列形状永不改变。 模板把 thinking_effort 默认设为 max。有个不一致让我会心一笑：注入的消息宣称支持 low、medium、high、max，校验器却只认其中三个。 medium 的意思看来就是什么都不注入。tool_choice 和 response_format 会渲染成带类型的系统消息，摆在整段对话之后、生成提示符之前。 近因性拉满，且不会残留到下一轮。工具 schema 渲染前按 key 排序，相同工具集必然产出相同前缀。 前缀缓存最爱这个。 工具结果在渲染前会被修复。它们按 id 与上一个 assistant 的调用匹配、重排，并以匹配到的调用为准改名，因为调用才是权威。 这一遍是写时复制且幂等的。K2 那套死板的 id 格式没了，不透明 id 直接能用。 输出侧，这个格式天生适合 token id 状态机。call 标签在任何参数字节到来之前就带上了函数名和序号，客户端可以立刻画出工具卡片。 参数按各自类型分标签流式到达，一个坏值毒不到兄弟参数。生成停在 end_of_msg，163586，而名义上的 EOS 留在 163585。 另外 open、close、sep 注册成了非特殊 token，skip_special_tokens 解码时骨架依然可见。我的解读：这是在保护下游解析器，防着那些默认剥掉特殊 token 的客户端。 还有几处零头。没有多 token 预测头，推测解码得靠外部草稿模型。 Token 163649 被保留为 osagent_mode，原样未动。tokenizer 的相对导入在 snapshot 软链接下会断，所以推理引擎要求摊平的检查点副本。 视觉编码器的十二个头除不尽八，只好按数据并行跑，每卡一整张图。 退后一步看，一条约束解释了几乎所有决定：这个模型必须能在现有硬件上跑起来。状态恒定的线性层、按 KB 每 token 计的缓存、半宽的专家、为低精度圈住的激活。 残差改造则让这么深的一栈得以训练。技术报告应该会回答剩下的问题：osagent token、视频上线日期、收尾那两层全局层。 在那之前，代码就是文档。它读起来就像作者们料到每一行都会被人研究。 发布第一天，他们至少料对了。