模型架构推理与性能AI Agent

Kimi K3 报告解读:当规模从一个旋钮变成一组受约束的生产要素

Moonshot AI 最近发布了 Kimi K3 的技术报告《Open Frontier Intelligence》。这个模型拥有 2.78 万亿总参数、单 token 激活 104.2B 参数,全网络 93 层,并且原生支持 1M token 上下文与多模态能力。Kimi K3 官方报告模型仓库 都已经公开。

大家如果去看它的第三方评测,会发现一个很有意思的直觉特征:它在 Web 开发、代码编写和复杂 Agent 任务上表现突出,但在传统的纯文本聊天和泛化文本生成榜上相对克制。这种偏科体感其实传递出了一个信号——它并不是靠海量通用文本盲目堆出来的,而是从一开始就冲着解决真实物理世界里的 Agent 任务去设计的。

我们拆开技术报告时,最容易产生的直觉反应往往是盯着 2.8 万亿这个数字发呆。但如果仔细把里面的工程设计梳理一遍,会发现整篇报告隐藏的最核心主线,其实是对 Scaling Law 的重新定义。在过去很多人的印象里,Scaling Law 像是一个单向调节音量的旋钮:似乎只要把总参数量做大、或者把上下文窗口拉长,更强的智能就会自动降临。

但真正做过系统工程的朋友都知道,现实中的 Scaling 并不是单一维度的膨胀。它实际上包含了一整套相互牵制、相互竞争的旋钮:总参数容量、单步激活参数、网络深度、专家池规模、单步路由的专家数量、长上下文的依赖距离、强化学习的轨迹长度,以及推理时的计算努力程度。

更重要的是,这些旋钮并不是在理想的数学模型里旋转。每当你试着把某个旋钮拧大一点,硬件底层的物理硬墙就会立刻迎面撞上来——显存容量不够了、GPU 内存带宽打满了、跨卡跨节点的全局通信开销爆掉了,或者 Prefill 和 Decode 的延迟高到无法上线。

所以真正的关键问题不在于是否 Scale,而在于:到底在哪个维度上扩大容量性价比最高?当某个维度扩张引发系统失衡时,怎么用算法和工程手段把这个代价偿还掉?K3 真正出彩的地方,正是向我们示范了如何在一个个真实的 GPU 硬件约束下,通过精妙的工程权衡来实现 Scaling 效能的放大。

Scaling 从单一总参数旋钮变成受显存、带宽、通信和延迟约束的一组生产要素

序列架构的精打细算:寻找上下文长度与系统吞吐的平衡点

在序列维度上,处理 1M token 的长上下文时,传统的全局注意力机制会带来昂贵的显存与计算墙:计算开销和 KV Cache 随序列长度呈二次方增长。但如果为了省钱把所有历史信息都硬塞进固定大小的递推状态里,又容易丢失关键细节。

针对这个两难,K3 采用了 3:1 的混合序列分工机制:全网络由 69 层 Kimi Delta Attention(KDA)与 24 层 Gated MLA 组成,每 3 层 KDA 后面接 1 层 MLA,末层保持全局注意力。这里提到的多头潜变量注意力 MLA 最早由 DeepSeek 在 DeepSeek-V2 与 DeepSeek-V3 中提出,其核心是用低秩投影把 Key 和 Value 压缩到一个共享的潜在向量中,从而大幅挤掉推理时的 KV Cache 显存开销。K3 采用的则是其门控变体 Gated MLA。在 K3 中,KDA 通过固定大小的递推状态以恒定开销传播历史,MLA 层则保留全局关联读取,补全递归状态可能漏掉的细节。

如果拿 K3 的做法和 DeepSeek V4 技术报告 做对比,会发现两家在前沿长上下文架构上呈现出精彩的同构呼应:

为什么说这是同构呼应?因为两家的核心洞察完全一致:模型内部不能在每一层都保存全量无压缩的 KV,也不能把所有历史全押注在一个固定维度的向量里,而是必须在模型内部建立一套近精远粗、分层存储与选择性召唤的信息经济学。DeepSeek V4 是在空间和相关性上做动态分层拉取,K3 是在网络层级和递推频率上做固定分工。

为了让 KDA 的递推计算适应 GPU 显存与计算核心的宽并行偏好,团队还研发了 FlashKDA、设备内 Context Parallelism 以及专属的前缀缓存。在位置编码上,MLA 不再使用显式 RoPE,位置关系完全由 KDA 的衰减与因果递归隐式承载,省去了扩窗时坐标系统的校准麻烦。

深层残差与专家并行:拆解显存容量与跨卡通信墙

再看网络深度与专家容量的治理,K3 同样展现出从最初理念到撞上硬件墙、再到工程折中的完整推导链。

在网络深度维度,93 层的网络面临着连续残差传递中的特征改写问题。网络越深,早期提取的有用特征越容易在逐层累加中被后续改写淹没。团队最初的直觉思路是引入 Attention Residuals(AttnRes),允许后续层像做注意力寻址一样,对前面所有历史层的输出做加权读取,从而打通深层网络的特征通道。

但在物理硬件上,如果允许 93 层网络里的每一层都独立寻址前面所有单层的输出,全网就会产生 93 个寻址源,跨卡跨节点的激活传输与显存驻留将不可接受。为了解决这个显卡墙,团队提出了 Block AttnRes 的折中方案:把 93 层网络按每 12 层聚合成一个 Block,全网加上初始 Embedding 只保留 9 个 Block 级别的寻址源。

这意味着,在一个 12 层的 Block 内部,层与层之间依然走普通的逐层残差传递(放弃了在 Block 内部做 12 层细粒度的逐层 AttnRes 寻址);但跨 Block 之间则允许读取更早 Block 的聚合输出。这种设计实际上是用放弃 Block 内部细粒度逐层寻址为代价,将寻址源从 93 个压缩到了 9 个,在保留跨 Block 深度特征通道的同时,控制住了显存与通信账单。

最后看专家并行。在混合专家架构中,提高表达能力最直接的办法就是增加专家数量并允许单个 token 激活更多专家。K3 每层设置了 896 个专家,每个 token 激活其中的 16 个,并配合 2 个全宽共享专家。然而,专家一旦多起来,系统就会立刻撞上两道物理硬墙:跨卡通信拥堵,以及热门专家倾斜。

第一道墙是跨卡通信瓶颈。当 896 个专家分散分布在多台 GPU 上时,每次要给 16 个专家分发数据,GPU 之间就必须做大规模的跨卡数据分发(all-to-all 通信)。如果直接传输 7,168 维的主状态向量,网络通信带宽会被吃满,所有的计算核心都会停下来干等数据。

LatentMoE 的工程解法是先给数据瘦身:在数据送给专家计算之前,先投影压缩到 3,584 维的低维空间做路由与专家计算,等计算完后再扩回 7,168 维。半宽路径把每次传输的数据包裁剪了一半,降低了单专家的通信开销。省下来的通信带宽,刚好让系统能够在带宽预算内多激活几个专家,实现了 16/896 的更大专家组合表达。

第二道墙是高度稀疏路由下的专家负载倾斜。近千个专家中,很容易产生少数热门专家被大量请求挤爆的情况,导致处理这几个专家的 GPU 节点卡死,别的 GPU 节点在干等。

为了平抑这种硬件等待,K3 在算法与工程上双管齐下:在算法层,Quantile Balancing 机制通过估计路由分数的全局分位数分布,直接计算并调整下一步的路由偏置,避免了传统固定小步长调整的迟滞;在硬件执行层,MoonEP 机制则通过动态预取与专家迁移,保证每个专家并行节点拿到的计算形状是静态均匀的,平抑了单卡拥堵导致的整集群长尾等待。

数据信号与 AgentENV 环境:如何生产真实可验证的训练信号

单靠架构容器无法自动产出智能,Scaling 的另一个关键旋钮在于训练信号的生成开销与可验证性。

很多初学者容易产生疑问:训练普通大模型只需要填文本,为什么训练 Agent 会需要一个专门的环境?原因在于,真实的 Agent 任务(如修 Bug、写脚本、配置数据库)不能只靠文本凭空脑补。模型必须在一个真实的运行环境里执行代码、修改文件并产生系统状态改变,才能学会真实的操作能力。

为了解决这个问题,团队构建了 AgentENV 环境。这套环境本质上是一个由大量轻量级虚拟机组成的模拟沙箱,里面包含三套核心机制:

  1. 自动任务合成:通过知识图谱自动组合知识节点,源源不断地生成真实的代码、环境配置、数据库操作等多样化 Agent 任务,解决手写测试题数量不足的问题。
  2. 终态物理 Verifier:传统做法用另一个大模型 LLM Judge 给回答打分,但模型容易被好听的废话欺骗。AgentENV 引入了物理 Verifier——它不看模型说话有多漂亮,只看环境里的真实结果:代码单元测试是否跑通、数据库记录是否真正修改成功、编译是否通过。只有环境终态完全符合要求,才给予确切奖励,消除了模型伪造报告或偷懒耍滑的漏洞。
  3. 动态 Harness 换脚手架:在真实的 Agent 部署场景中,我们往往无法预知或依赖一个固定的目标环境。如果模型只在某一套固定的脚手架(如特定的工具名称和 Prompt 格式)上训练,就会产生死记硬背。AgentENV 在训练中动态更换 Kimi Code、Claude Code、Codex、OpenClaw 与 Hermes 等不同脚手架,逼着模型理解工具背后的真实操作意图,大幅提升了在不确定环境下的泛化能力。

同时,为了让模型在 1M 上下文内真正学会利用远处的信息,K3 经历了从 8K 到 1M 的渐进式退火训练,并专门合成了依赖关系散布在整个窗口的长文档与多模态数据,使模型在长序列与真实环境中都能获得高质量的训练信号。

K3 在长上下文、深网络、专家容量和训练信号四个方向上的约束与工程折中

推理计算扩展:把 Runtime Scaling 转换为单模型落地能力

前面探讨的技术点大多集中在预训练阶段的架构与数据层面。然而从 OpenAI o1 与 DeepSeek 以来,整个前沿大模型行业迎来了全新的发展轴线:Runtime Scaling(或称 Inference-Time / Test-Time Scaling),即在推理探索和后训练强化学习阶段扩展计算努力程度。

但在后训练多目标强化学习中,行业普遍遇到了著名的跷跷板效应:如果在一个单模型上直接同时训练多个领域和不同算力预算的任务,某项能力提升往往会导致其他领域能力退化。

为了破除这一瓶颈,DeepSeek V4 技术报告 最早提出了 Multi-Teacher On-Policy Distillation(MOPD)的工程解法:先训练 10 个以上的独立领域 Specialist Teacher 把各领域上限拉满,再让 Student 模型在自己生成的真实采样轨迹(On-Policy)上接收多导师的密集奖励,无损收拢能力。

对比来看,K3 继承了 DeepSeek V4 的 MOPD 在线蒸馏范式,但在拆解维度上做出了重要的增量贡献:

这种做法先让 9 个 Teacher 在各自的窄分布上独立把特定领域和指定算力预算下的 Runtime Scaling 上限提升到高点,再通过 MOPD 把 9 份独立的 Scaling 收益无损收拢进单一步署模型中。

这种让模型通过外部工具与显式查询突破上下文限制的做法,在哲学上也与 Recursive Language Models 论文 中探索的外部上下文检索与子模型调度思想遥相呼应。

Serving 经济学:用量化感知训练降低部署损耗

在完成模型的训练与能力收拢后,Scaling 最终必须落脚到真实的部署成本与 Serving 经济学上。

对于千亿乃至万亿级别的超大模型而言,传统的后量化(Post-Training Quantization)很容易在低比特截断时带来严重的精度衰减与智能损耗。为了解决这一痛点,K3 在训练阶段就全程引入了量化感知训练 QAT,对 routed expert 权重使用 MXFP4、激活使用 MXFP8。

通过在训练过程中让模型显式地适应低比特量化的扰动,K3 成功将部署时的智能与精度损耗降低到了较低的水平。这种在训练期提前偿还量化代价的做法,让模型在上线做低精度压缩部署时,依然能够完整保留高精度模型的推理能力,实现了 Serving 经济学与前沿智能的最佳结合。

归根结底,K3 报告展示的核心启示在于:前沿智能的提升并不依赖于盲目调大某个单一参数,而是在硬件物理极限与算法自由度之间寻求全局解:

Agent Intelligence = Policy × Environment × Verifier × Serving Economics

通过在序列上用 KDA 与 MLA 解耦上下文、在深度上用 Block AttnRes 保持信息流通、在专家上用 LatentMoE 降低通信开销,并用 QAT 量化感知训练与 MOPD 蒸馏连接后训练与部署,K3 为我们呈现了一套在真实硬件约束下精妙驾驭 Scaling Law 的系统工程范例。

鸭哥每日手记

日更的深度AI新闻和分析