Kimi K3 架构深度拆解：百万上下文到底靠什么撑起来的

为什么 Kimi 能读 100 万字还不丢信息？为什么 MoE 模型又快又省？为什么长文本推理显存涨得快？这篇把底层逻辑给你讲明白。

一、整体简介
市面上稠密大模型存在两大致命瓶颈：长文本下注意力计算平方爆炸、深层网络信息逐层衰减、单套全量参数算力开销极高。K3 采用四层核心架构叠加 KV 显存优化，实现百万 Token 无损阅读：稀疏 MoE 混合专家（控算力）、共享 + 稀疏双专家架构（保通用语义稳定）、自适应残差层间耦合（防止长距离信息丢失）、跨窗口 KDA 解耦注意力（平衡计算量与全局上下文连通），同时配套 MoE 负载均衡约束、多维度 KV 缓存显存压缩方案。

开头先抛结论Kimi K3 能做到百万级上下文，靠的不是堆显存，而是四层架构设计的组合拳：

MoE 混合专家架构 —— 用稀疏激活省算力，参数量大但实际计算量小

共享专家 + 稀疏专家双轨制 —— 通用知识共享打底，细分领域专家专精

跨窗口注意力机制 —— 分段处理但全局连通，长文本逻辑不断

自适应层间耦合 —— 文本越长，层间信息传递越强，深层不丢细节

这四层叠在一起，才撑起来了百万上下文的能力。下面一层一层给你拆。

一、MoE 混合专家：不是一个大脑，是一群大脑1.1 稠密模型的问题：全院医生会诊感冒传统的大模型（比如 GPT-3、LLaMA）都是稠密模型—— 每一个 token 输入，都要经过全部参数的计算。比如一个 70B 的稠密模型，生成一个 token，700 亿参数全部都要参与计算。这就像什么？你去医院看个感冒，全院所有科室的医生都来给你会诊 —— 没必要，还贵。1.2 MoE 的核心思想：分科看病MoE（Mixture of Experts，混合专家）的思路很简单：

不是所有参数都参与计算，每次只激活一小部分 “专家”。

就像医院分科 —— 感冒去呼吸科，骨折去骨科，肚子疼去消化科。每个科室（专家）只管自己擅长的，不用全院出动。
1.3 MoE 的基本结构一个典型的 MoE 模型包含三部分：

共享专家（Shared Expert）：处理通用知识，一般 1~2 个，所有 token 都经过它。
稀疏专家（Sparse Expert）：处理细分领域，一般 8~64 个，每次只激活少数几个。路由器（Router/Gate）：决定每个 token 该去找哪个专家，就像医院的导诊台。每次 token 进来，路由器判断：这个 token 该找哪几个专家？然后只激活选中的专家进行计算。

1.4 MoE 到底省多少？
算笔账以 8x7B 的 MoE 模型为例：总参数量大概 560 亿，是 7B 稠密模型的 8 倍。
但是 —— 每 token 实际激活的参数只有 140 亿左右。什么概念？总参数大 8 倍，但实际计算量只有 2 倍左右。
这就是 MoE 的核心优势：用更大的总参数量换知识容量，用稀疏激活控制计算量。模型更大更聪明，但推理速度不慢，甚至更快。

1.5 为什么 MoE 适合长文本？长文本最大的问题是计算量和显存随上下文长度线性增长。
稠密模型：上下文从 4k 涨到 128k，计算量涨 32 倍，直接扛不住。MoE 模型：虽然总参数量大，但每次只激活 2 个专家，实际计算量小得多。上下文涨了，计算量也涨，但基数小，扛得住。
二、共享专家 + 稀疏专家：通用打底，细分专精

2.1 纯稀疏 MoE 的坑：通用知识分散纯稀疏 MoE 有个问题：通用知识分散在各个专家里，每次都要路由，效率低还容易丢信息。比如 “的、了、是、在” 这种高频通用词，每个专家都得会，不然路由到哪个专家都处理不好。
结果就是：每个专家都得学一遍通用知识，浪费参数；而且每次都要路由，增加计算开销。

2.2 共享专家：专门管通用的共享专家就是干这个的 ——所有 token 都经过共享专家，共享专家负责处理通用语法、常见知识。稀疏专家只负责处理细分领域、专业内容。就像医院有个全科门诊，普通感冒发烧直接全科解决，不用每次都去专科。

2.3 双轨制的好处这样设计的好处很明显：第一，通用知识不丢。 共享专家全程在线，基础能力有保障，长文本稳定性好。第二，专业能力更强。 稀疏专家各管一摊，细分领域更专精，遇到复杂问题能处理得更好。第三，计算效率更高。 大部分 token 只走共享专家，不用每次都路由，省了很多开销。

2.4 K3 的设计思路K3 的百万上下文能力，很大程度上靠共享专家打底。长文本里大部分内容都是普通叙述、通用信息，这些全部由共享专家处理，稳定可靠。只有遇到专业内容、复杂推理时，才调用稀疏专家。既保证了长文本的稳定性，又有足够的知识深度。三、层间残差耦合：信息接力赛，深层不丢失

3.1 深层网络的痛点：接力棒传丢了大模型动不动就几十层，层数深了有个经典问题：信息从底层传到顶层，越传越模糊。就像接力赛 ——100 个人传接力棒，传到最后一棒，接力棒都快磨没了。短文本还好，信息密度高，丢一点没关系。长文本就麻烦了 —— 前面的细节传到后面，全丢光了。

3.2 残差连接：直接抄近道残差连接（Residual Connection）的解决思路很简单：
每层的输出 = 本层计算结果 + 直接抄过来的输入

公式就是这么简单：(x_{l+1} = x_l + F(x_l))(F(x_l)) 是本层的计算结果，(x_l) 是直接抄过来的输入。这样信息就有两条路走：

一条路：经过本层计算（可能丢信息）
另一条路：直接跳过去（信息完整保留）
就像接力赛加了一条传送带给你保底 —— 接力棒传丢了不要紧，传送带上还有一份。

3.3 长文本需要更强的耦合普通的残差连接是固定的 —— 不管文本长短，残差增益都一样。但长文本需要更强的信息传递：
文本越长，层数越深，信息丢失越严重
需要更强的残差连接来保住细节
所以 K3 这类长文本模型的设计思路是：文本越长，层间耦合越强。序列长度从 4k 涨到 128k，层间的信息传递增益自动上调，确保深层网络还能看到前面的细节。

3.4 直观感受：差多少？普通残差在百万上下文下，信息丢得只剩一成多，基本没法用。自适应耦合能保住四五成，虽然也丢了不少，但至少还能用。差的这三四成，就是百万上下文能不能用的关键。

四、跨窗口注意力：分段阅读，但全局连通

4.1 全注意力的问题：计算量爆炸Transformer 的自注意力机制，计算量是序列长度的平方 —— 序列长度翻一倍，计算量翻四倍。100 万 token 的全注意力，计算量是 1024 token 的一百万倍，根本算不动。所以长文本模型都用滑动窗口注意力—— 只看附近的 token，不看全局。

4.2 滑动窗口的痛点：看完就忘滑动窗口的思路是：每个 token 只和窗口内的 token 做注意力，窗口大小固定（比如 4k、8k）。这样计算量从平方级降到了线性级，长文本能跑了。但有个大问题：窗口之间断了。就像你看书，每次只看一页，看完一页翻下一页，但你不记得上一页讲了啥 —— 前后逻辑连不上。

4.3 跨窗口注意力：怎么解决断层？跨窗口注意力的思路是：
大部分 token 只看窗口内，少数关键 token 负责跨窗口传递信息。
常见的实现方式有好几种：有的用全局 token—— 有几个特殊 token 能看到全局，负责在窗口之间传递信息。有的用分层注意力—— 底层看局部，高层看全局，越往上层视野越广。有的用KDA（Key-Value Decoupling Attention）—— 把 Key 和 Value 分开处理，Key 跨窗口共享，Value 留在本地。

4.4 K3 的 KDA 机制K3 用的是类似 KDA 的跨窗口方案：本地窗口：每个 token 正常看窗口内的邻居，负责细节。跨窗口连接：Key 向量跨窗口共享，Value 留在本地。注意力计算：Query 可以在全窗口范围内找 Key，但 Value 只取本地的。这样既保证了全局的语义连通性，又控制了计算量。

4.5 几种方案对比全注意力效果最好，但计算量爆炸，百万上下文根本跑不动。纯滑动窗口计算量最小，但逻辑断，长文本没法用。跨窗口方案效果不错，计算量也可控，是目前的最优解。五、MoE 负载均衡：不能让有的专家累死，有的闲死

5.1 负载均衡为什么重要？MoE 模型有个经典坑：路由器偷懒，总把 token 往少数几个专家送。为什么？因为那几个专家处理得好，损失低，路由器就越爱送过去。结果就是：

2 个专家干了 80% 的活，累死
剩下 6 个专家闲着没事干，闲死

模型效果退化成稠密模型，还不如直接用稠密的
这就叫负载崩塌（Load Balancing Collapse）。

5.2 怎么解决？加辅助损失解决办法很直接：在损失函数里加一项 “负载均衡惩罚”。(\mathcal{L}{total} = \mathcal{L}{task} + \lambda \cdot \mathcal{L}{balance})(\mathcal{L}{balance}) 就是负载均衡损失 —— 专家负载越不均匀，惩罚越大。

常见的负载均衡损失有好几种：重要性损失（Importance Loss）：每个专家收到的 token 数要均匀，不能有的太多有的太少。负载损失（Load Loss）：每个专家的计算量要均匀，不能有的累死有的闲死。熵正则（Entropy Regularization）：鼓励路由器多探索，不要总选同一个专家，增加多样性。

5.3 健康的负载长什么样？一个健康的 MoE 模型，