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

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

开头先抛结论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 倍。 但是 —