模型技术解析合集

Kimi系列模型技术解析合集

kimi3的Stable LatentMoE技术解析

Kimi K3 的 Stable LatentMoE 是其大规模 MoE（Mixture-of-Experts）架构中的核心技术之一，它主要解决传统 MoE 模型在扩展到万亿级参数规模后出现的训练不稳定、Expert 负载不均衡、Router 崩溃以及长时间训练难以收敛的问题。简单来说，普通 MoE 的核心思想是“扩大模型参数，但每次只激活部分 Expert”，例如一个拥有 1T 参数的模型，并不是每次推理都运行全部 1T 参数，而是通过 Router 根据当前 Token 的语义选择少量 Expert 参与计算，这样可以在保持巨大模型容量的同时控制计算成本。但是随着 MoE 规模不断扩大，传统 MoE 架构出现了明显问题：Expert 数量增加以后，Router 很难稳定地将 Token 分配给合适 Expert，容易出现部分 Expert 被大量使用形成热点（Expert Collapse），另一部分 Expert 几乎没有 Token 导致参数无法训练（Dead Expert），同时不同 Expert 之间的信息竞争会导致训练震荡。因此 Kimi K3 引入 Stable LatentMoE，通过 Latent Representation、稳定 Routing、Expert Load Balance 等机制，让超大规模 MoE 在 Agentic RL 和长上下文训练环境下保持稳定。

传统 MoE 的结构可以理解为：

# 输入 Token Hidden State
x = hidden_states

# Router 根据 Token 计算 Expert 概率
router_logits = router(x)

# Softmax 得到 Expert 权重
router_probs = softmax( router_logits)

# 选择 Top-K Expert
experts = top_k( router_probs,  k=8)

# Expert 计算
output = sum( weight[i] * expert[i](x))

其中 Router 是整个 MoE 的核心：

$P(e_i|x)=softmax(W_rx)$

它决定每个 Token 应该进入哪个 Expert。如果 Router 学习不稳定，就会导致整个 MoE 系统失衡。例如：

Token 分布：

Expert 1:
90%

Expert 2:
5%

Expert 3:
3%

Expert 4:
2%

结果就是：

Expert 1:
训练过度

Expert 2-4:
几乎没有学习

最终导致模型容量虽然很大，但是有效参数没有真正利用。

Stable LatentMoE 的核心思想之一是引入 Latent Space，让 Router 不直接根据原始 Hidden State 做 Expert 决策，而是在一个更加稳定的隐空间（Latent Representation）中进行路由。传统 Dense Transformer 中，每一层 Hidden State 会受到大量 Attention、Residual、Normalization 的影响，分布变化较大，如果直接使用这种动态变化的表示进行 Routing，Router 很容易随着训练阶段变化产生不稳定。而 Latent Representation 相当于建立一个更加稳定的中间语义空间，使 Router 判断 Token 类型时更加可靠。

传统方式：

Token Hidden State
↓
Router
↓
Expert

Stable LatentMoE：

Token Hidden State

↓

Latent Projection

↓

Stable Latent Space

↓

Router

↓

Expert

对应代码可以表示：

# 原始 Transformer hidden state
hidden = transformer_layer(x)

# 映射到 latent space
latent = latent_encoder( hidden)

# Router 不直接看 hidden
# 而根据稳定 latent 选择 Expert
router_logits = router(  latent)

expert_ids = top_k( router_logits, k=num_experts)

这样做的好处是 Router 学习的是更加稳定的语义聚类，而不是短期变化较大的神经表示。例如代码 Token、数学 Token、自然语言 Token、工具调用 Token，在 Latent Space 中会形成更加稳定的区域，使 Router 能够长期保持一致的 Expert 分配策略。

另一个关键创新是 Stable Routing。传统 MoE 使用 Softmax Router：

router_prob = softmax(router_logits)

但是 Softmax 存在一个问题，当某个 Expert 初期稍微表现更好时，Router 会不断增加它的概率，形成正反馈：

Expert A稍好

↓

更多Token进入A

↓

A训练更多

↓

A继续变强

↓

更多Token进入A

最终形成 Expert Collapse。

Stable LatentMoE 需要通过额外约束保持 Expert 使用均衡，常见方法包括 Auxiliary Loss、Expert Capacity Control 和 Router Regularization。

例如：

# 计算每个 Expert 接收 Token 数量
expert_load = count( expert_ids)

# 平衡损失
balance_loss = variance( expert_load)

# 总Loss
loss = model_loss + alpha * balance_loss

目标是：

Expert A:
25%

Expert B:
25%

Expert C:
25%

Expert D:
25%

而不是：

Expert A:
95%

其他:
5%

对于 Kimi K3 这种拥有数百 Expert 的超大规模 MoE，这种稳定性非常重要，因为训练阶段不仅包含 Pretrain，还包含 SFT、Agentic RL、On-Policy Distillation 等多个阶段，每个阶段数据分布变化巨大。如果 Router 不稳定，RL 阶段新的 Agent Trajectory 会导致 Expert 分布突然变化，从而破坏已经学习好的能力。

Stable LatentMoE 另一个重要价值是适合 Agentic RL。传统 MoE 在普通语言建模中面对的是相对稳定的数据分布：

文章

代码

网页

数学

但是 Agent RL 中：

Observation

↓

Reasoning

↓

Tool Call

↓

Tool Return

↓

Planning

↓

Correction

每一步 Token 类型完全不同。例如：

Reasoning Token 可能需要逻辑 Expert，代码修改需要 Coding Expert，Tool Return 需要信息解析 Expert。如果 Router 不稳定，模型可能无法形成稳定的 Expert 分工。而 LatentMoE 可以让不同 Expert 在隐空间中形成更明确的能力分区。

例如：

latent_space = {

    "coding_region":
        expert_1,

    "reasoning_region":
        expert_2,

    "planning_region":
        expert_3,

    "tool_use_region":
        expert_4
}

这样 Agent 执行复杂任务时，可以动态调用不同能力模块。

从计算角度看，Stable LatentMoE 仍然保持 MoE 最大优势：

$Compute \approx O(K)$

而不是：

$Compute \approx O(N)$

其中：

N:
总 Expert 数量

K:
每个 Token 激活 Expert 数量

例如：

# 总共有896个Expert
total_experts = 896

# 每个Token只激活16个
active_experts = 16

因此：

参数规模：

896 Expert

↓

巨大模型容量


计算量：

16 Expert

↓

接近小模型成本

这也是为什么 Kimi K3 可以达到万亿级参数规模，同时保持实际推理成本可控。

Stable LatentMoE 与 MoonEP 也是配套关系。Stable LatentMoE 解决“哪些 Expert 应该被调用”和“如何保持训练稳定”的问题，而 MoonEP 解决“这些 Expert 如何高效分布到 GPU 上运行”。如果 Router 产生大量不均衡 Token，即使 MoE 结构优秀，GPU 之间仍然会出现通信瓶颈：

GPU0:

Expert A
10000 tokens


GPU1:

Expert B
100 tokens

GPU0 忙碌：

等待计算

GPU1 空闲：

等待通信

MoonEP 通过 Expert Parallel 优化，让 Expert 分布更加均衡：

# Router输出
tokens = router(hidden)

# MoonEP重新调度
balanced_tokens = moon_ep.dispatch( tokens)

# GPU负载均衡
experts.forward( balanced_tokens)

因此 Kimi K3 的 MoE 系统实际上是：

Stable LatentMoE
        →
稳定Expert路由

MoonEP
        →
高效Expert并行

Native MXFP4
        →
低成本计算

KDA
        →
长上下文Attention优化

共同组成完整的大规模 Agent Foundation Model 架构。

所以，Stable LatentMoE 的创新点并不是简单增加 Expert 数量，而是在万亿级 MoE 模型中解决三个核心问题：第一，通过 Latent Representation 让 Router 在更加稳定的语义空间中进行 Expert 选择，降低训练震荡；第二，通过稳定 Routing 和负载均衡机制避免 Expert Collapse，使所有 Expert 都能够有效学习；第三，使 MoE 架构更适合 Agentic RL 场景，因为 Agent 任务包含大量不同类型的动态 Token，需要模型具备稳定的专家分工能力。对于 Kimi K3 来说，Stable LatentMoE 是支撑其 2.8T 参数规模、Agent 长链路推理以及大规模 RL 后训练的重要架构基础。

Kimi3的 AgentEnv 如何支撑长链路任务

AgentEnv 本质上并不是一个 Agent Framework，也不是一个 Benchmark，而是一套专门为 Agentic RL 构建的运行时环境（Runtime Environment）。传统强化学习环境（例如 OpenAI Gym）假设每个 Episode 都比较短，一个任务通常几十步就会结束，因此每轮训练都会调用 env.reset() 重置整个环境，模型重新从初始状态开始执行。而真实 Agent 完全不同，一个 Browser Agent、Coding Agent 或 CAD Agent 往往需要持续执行数千甚至数万步操作，一个任务可能持续几个小时甚至几天，中间不断调用工具、修改文件、执行命令、访问网页、读取数据库以及更新环境状态，如果每轮 Rollout 都重新创建环境，不仅大量时间浪费在重复初始化上，而且无法训练真正的长链路决策能力。因此 AgentEnv 的第一个创新就是 Persistent Environment（持久化环境），即整个 Linux Sandbox、文件系统、浏览器状态、Python 环境、数据库以及 Tool Cache 都不会因为一次 Rollout 而销毁，而是像真实工程师工作的电脑一样持续存在，Agent 每一步都建立在上一轮环境状态之上，从而能够完成持续数小时的大规模 Agent Rollout，这一点也是 Kimi K3 能够训练 Browser Agent、Terminal Agent 和 Chip Design Agent 的基础。

# 创建 Agent Environment
# Environment 内部维护完整 Linux Sandbox
env = LinuxEnvironment()

# 第一次执行
env.execute( "git clone https://github.com/project/repo.git")

# 第二次执行
# Repository 仍然存在
env.execute( "pip install -r requirements.txt")

# 第三次执行
# Python 环境仍然保留
env.execute( "python train.py")

# 修改代码
env.execute( "vim model.py")

# 所有状态持续存在，不需要 reset()

AgentEnv 的第二个创新是 Snapshot（环境快照）。传统 RL 中如果 Rollout 执行失败或者需要探索不同策略，通常只能重新执行整个 Episode，而对于持续几个小时的 Agent 来说，这种代价极高。例如 Browser Agent 已经完成几十轮网页浏览，Coding Agent 已经编译完成整个仓库，CAD Agent 已经综合了一次芯片，如果重新开始意味着重新执行所有工具调用和环境初始化。AgentEnv 因此引入 Snapshot，将整个 Sandbox 当前状态冻结，包括文件系统、运行进程、浏览器 Session、数据库状态、Python 虚拟环境以及 Tool Cache，都可以快速保存和恢复。恢复 Snapshot 后 Agent 可以继续从之前位置执行，而不是重新运行几千步 Rollout，大幅提升 RL 数据采集效率，这也是技术报告中 Persistent Rollout 与 Sandbox State 的核心组成部分。

# 当前 Agent 已经执行数千步
env.execute(  "python synthesis.py")

env.execute(  "python verification.py")

# 保存整个环境状态
snapshot = env.snapshot()

# 后续探索失败
env.execute( "rm -rf build/")

# 一键恢复环境
env.restore(snapshot)

# 所有文件、数据库、浏览器、进程全部恢复

AgentEnv 第三个重要创新是 Fork（环境分叉）。传统 RL 如果希望探索两种不同策略，通常只能重新执行前面的所有步骤，例如已经完成三千步 Rollout，现在希望尝试两种不同优化方案，只能重新执行三千步再分别测试两个分支。而 AgentEnv 支持直接复制当前环境状态，多个 Agent 可以共享前面所有执行结果，只在后续阶段分别探索不同策略，因此大量重复计算被消除，这一点非常类似 Git Branch，只不过复制的是整个运行环境而不是代码仓库。对于 CAD、Browser 和 Coding Agent，这意味着可以从同一个中间状态快速探索多个解决方案，再保留 Reward 更高的一条轨迹继续训练。

# 当前环境已经准备完成
env.execute( "python compile.py")

# 创建两个环境分支
branch_a = env.fork()
branch_b = env.fork()

# 两个分支独立探索
branch_a.execute( "python optimize_area.py")

branch_b.execute( "python optimize_timing.py")

# 最终选择 Reward 更高的方案

传统 RL 保存的数据通常只有 Prompt、Action 和 Reward，而 AgentEnv 中 Replay Buffer 保存的是完整 Environment State。对于 Kimi K3，一条 Trajectory 不仅包含 Observation、Reasoning、Action，还包含 Tool Call、Tool Return、Browser 状态、Terminal 输出、数据库修改以及 Snapshot，因此 RL Trainer 更新策略时学习的是完整 Agent 行为，而不是一句文本回答。

trajectory = {
    "observations": observations,
    "actions": actions,
    "tool_calls": tool_calls,
    "tool_returns": tool_returns,
    "rewards": rewards,
    "snapshot": snapshot
}

replay_buffer.add(  trajectory)

Kimi3的Native MXFP4 量化如何加速推理

Native MXFP4 是 Kimi K3 在部署与后训练阶段的重要基础设施创新，它解决的核心问题不是模型能力，而是超大规模 MoE 模型如何以极低显存成本完成训练和推理。传统大模型通常采用 FP16 或 BF16 完成全部训练，模型收敛以后再利用 GPTQ、AWQ 等 Post Training Quantization（PTQ）方法进行量化，这种方式虽然能够降低部署成本，但模型训练阶段从未见过低精度权重，因此量化以后往往产生明显精度损失，对于拥有数百 Expert 的超大规模 MoE 尤其明显，因为 Router 对权重变化非常敏感，量化误差会进一步放大 Routing Error。Kimi K3 并没有采用这种"训练结束再量化"的方法，而是从 SFT 开始就进入 Quantization Aware Training（QAT），整个后训练阶段始终使用 Native MXFP4 Weight 与 MXFP8 Activation，模型在训练过程中不断适应低精度误差，因此最终部署时几乎不需要再额外量化，这也是 Native Quantization 名称的来源，即模型从训练开始就是低精度模型，而不是后期转换得到的低精度模型。

# 保存一份高精度 Master Weight
master_weight = parameter

# 前向计算时进行 Fake Quantization
quant_weight = fake_quantize(  master_weight, format="MXFP4")

# Linear 使用低精度权重
output = linear(  input, quant_weight)

反向传播阶段并不会直接更新 MXFP4 权重，而是始终维护一份高精度 Master Weight，梯度更新完成以后再次执行 Fake Quantization，因此模型整个训练过程中不断适应 MXFP4 带来的数值误差，而不是最后一次性转换。

# 反向传播
loss.backward()

# 更新高精度参数
optimizer.step()

# 下一轮 Forward
# 再次执行 Fake Quantization
quant_weight = fake_quantize(  master_weight, format="MXFP4")

Kimi K3 同时没有把 Activation 也压缩到 4bit，而是采用 MXFP8。原因在于 Activation 动态范围远大于 Weight，如果 Activation 同样使用 4bit，误差会迅速累计，尤其是在深层 Transformer 与 MoE Routing 中容易导致性能下降，因此官方采用 Weight 使用 MXFP4、Activation 使用 MXFP8 的混合精度方案，在保持推理速度的同时尽可能降低数值误差。

# Weight 使用 MXFP4
weight = fake_quantize( weight, format="MXFP4")

# Activation 使用 MXFP8
activation = fake_quantize( activation, format="MXFP8")

Native MXFP4 真正发挥价值还依赖 MoonEP。对于拥有数百 Expert 的 MoE 模型，即使所有权重已经量化到 4bit，如果不同 Expert 收到的 Token 数量极不均衡，GPU 仍然会因为 All-to-All 通信等待而大量空闲，因此 MoonEP 在 Expert Parallel 阶段采用静态 Shape、完全均衡的 Expert 调度以及去除关键路径上的 Host Synchronization，使所有 GPU 尽可能保持相同工作量，从而让 MXFP4 的低显存优势真正转化为高吞吐率。如果没有 MoonEP，Native MXFP4 只能降低显存，而无法充分提升大规模 MoE 的训练与推理效率。

# Router 输出 Expert
expert_id = router(hidden_state)

# MoonEP 自动平衡不同 Expert 的 Token
balanced_tokens = moon_ep.dispatch(  hidden_state, expert_id)

# 每张 GPU 获得近似相同数量 Token
output = experts.forward( balanced_tokens)

综合来看，AgentEnv 与 Native MXFP4 分别解决了 Kimi K3 两个最大的工程瓶颈。AgentEnv 通过 Persistent Environment、Snapshot、Fork、Sandbox State 和长期 Rollout，使 Agent 可以在真实环境中持续运行数小时甚至数天，并高效采集百万 Token 的 Agent Trajectory；Native MXFP4 则通过从 SFT 开始执行 Quantization Aware Training，使模型天然适应 4bit 权重，再结合 MoonEP 的 Expert Parallel 优化，使 2.8T 级别的 MoE 模型能够以更低显存、更高吞吐完成训练和部署。两者共同构成了 Kimi K3 能够同时具备超长链路 Agent 能力和超大规模模型部署能力的重要基础设施创新。

Kimi3为什么能完成芯片设计

结论先说：Kimi K3 并不是训练了一个"会设计芯片"的专用模型，也不是把 EDA 算法塞进 Transformer 里面。 从 Kimi K3 Technical Report、AgentEnv、MoonEP 以及官方 Blog 能看到的公开信息来看，它能够完成 CAD/EDA/芯片设计，本质上依赖的是 Agentic Foundation Model + 长链路 Agent RL + Tool Use + Sandbox Environment + 超长上下文 的组合，而不是某一种新的神经网络结构。官方展示的 48 小时自主设计芯片案例，使用的是开源 EDA 工具链和 Nangate 45nm PDK，K3 的角色更像是一位能够持续调用工具、阅读文档、修改 RTL、运行综合、分析报错并迭代优化的高级 Agent，而不是直接"生成芯片版图"。(arXiv)

可以把整个能力拆成几个层次。

首先，AgentEnv 是能力的运行环境，而不是模型本身。 AgentEnv 提供的是一个可以大规模并行运行 Agent 的 Sandbox。每个 Agent 都拥有独立 Linux、文件系统、Terminal、网络、快照（Snapshot）以及 Fork 能力，可以像真人工程师一样持续工作几十个小时，而不是一次 Prompt 回答结束。对于芯片设计来说，一个完整任务通常持续数千到数万步，例如阅读 RTL→修改 Verilog→调用 Yosys 综合→调用 OpenROAD Place&Route→查看 Timing Report→修改 RTL→再次综合→再次布局布线→直到 Timing Closure。普通 ChatBot 无法保存这么长的状态，而 AgentEnv 可以把整个环境冻结成 Snapshot，在 RL 训练时随时恢复，所以模型真正学习的是如何在真实工程环境里持续完成任务，而不是学习某个 CAD API。官方对 AgentEnv 的定位也是 persistent rollout、sandbox state、snapshot、fork、massively parallel agent training。(geopolitechs.org)

其次，Kimi K3 学到的不是 EDA，而是 Tool Use Policy。 芯片设计过程中真正完成计算的是开源 EDA 软件，例如 RTL 综合、逻辑优化、布局布线、静态时序分析（STA）、形式验证等都仍然由专业工具完成。模型负责的是决定下一步该调用哪个工具、如何修改代码、如何分析工具输出。例如：

# 当前 Observation
observation = {
    "rtl": rtl_code,
    "timing_report": timing_report,
    "previous_history": history
}

# Agent 推理下一步动作
action = actor.generate( observation)

# Action 可能不是自然语言
action = {
    "tool": "yosys",
    "arguments": {
        "script": "synth.tcl"
    }
}

# 调用真实 EDA
tool_result = executor.run(action)

如果综合失败：

ERROR:
Latch inferred.

Agent 不会停止，而是继续：

action = {
    "tool": "edit_verilog",
    "arguments": {
        "file": "alu.v"
    }
}

再次运行：

yosys

直到：

Timing PASS

因此模型学习的是：

Observation → Decision → Tool → Feedback → Replan

而不是：

Observation → Final Answer

这一点和普通 Coding Agent 完全一致，只不过 Tool 从 Python Compiler 变成了 EDA Tool。

第三，也是 K3 技术报告反复强调的一点，就是Million-token Agentic RL。芯片设计最大的特点不是数学难，而是上下文极长。一次设计可能需要同时阅读几十份 Spec、多个 RTL 文件、Timing Report、Floorplan、综合网表、约束文件、脚本、日志。如果上下文窗口只有几万 Token，模型很快就会遗忘前面的设计约束，因此 K3 使用 KDA + 1M Context + Persistent Rollout 支撑长链路任务。技术报告中明确提到，其后训练支持 million-token agentic RL with persistent rollout and sandbox states，这意味着 RL 训练过程中并不是每一步重新开始，而是在持续运行的 Agent 环境中完成整条轨迹。(arXiv)

第四，Agent RL 是真正让模型学会 CAD Workflow 的原因。 如果只用 SFT，模型最多学会回答"如何综合 Verilog"。而 Agent RL 会让模型真正执行：

阅读设计规格 →
生成 RTL →
运行综合 →
查看 Timing →
修改 RTL →
再次综合 →
布局 →
布线 →
DRC →
LVS →
再次修改 →
Timing Closure →
Finish

Reward 并不是回答是否正确，而是：

reward = (
    timing_score +
    area_score +
    power_score +
    verification_score
)

例如：

if timing_pass:
    reward += 1

if area < target:
    reward += 0.5

if drc_errors == 0:
    reward += 1

因此模型最终优化的是：

哪种设计流程最终最容易得到 Timing Closure。

而不是：

哪句话最像训练数据。

第五，MoonEP 解决的是训练如此巨大 MoE Agent 的工程问题，而不是 CAD 算法。 K3 是一个约 2.8T 参数、每 Token 激活 16/896 Experts 的 Stable LatentMoE 模型。如此大的 MoE，如果 Expert Parallel 不平衡，RL Rollout 会大量等待通信。MoonEP 的作用就是让 Expert Parallel Communication 保持均衡，即使不同 Expert 的 Token 数量差异很大，也尽量维持 GPU 利用率，从而支撑大规模 Agent RL。MoonEP 并没有任何 CAD 逻辑，它解决的是 MoE 的 All-to-All 通信、负载均衡和显存管理问题。(arXiv)

最后，也是很多人误解的一点，官方展示的 Chip Design Demo 并不是意味着 K3 发明了新的芯片设计算法。 官方博客描述的是：K3 在约 48 小时自主运行中，利用开源 EDA 工具完成了一个面向自身 Nano 模型的芯片设计，完成 RTL、综合、优化、验证，并在 Nangate 45nm 工艺库下达到 Timing Closure，最终得到约 4 mm²、100 MHz 的设计。这里真正完成综合、布局布线、时序分析的仍然是成熟的开源 EDA 工具，K3 的价值在于它能够像资深工程师一样持续阅读文档、分析日志、调用工具、修改设计并迭代，而不是直接替代 EDA 软件。(Kimi)

从公开资料来看，Kimi K3 能做 CAD/芯片设计，并不是因为它拥有专门的"芯片设计神经网络"，而是因为它把超长上下文（KDA）、持续运行环境（AgentEnv）、真实工具调用（EDA Toolchain）、大规模 Agentic RL、MoE 高效训练（MoonEP）整合成了一套能够长时间自主完成复杂工程任务的 Agent 系统。真正完成芯片设计的是"模型 + Agent Runtime + EDA 工具 + Sandbox + RL Policy"这个整体，而不是 Transformer 本身。这一点也是 K3 与传统聊天模型最大的区别。

Kimi3的KDA（Kimi Dynamic Attention）如何优化推理

KDA（Kimi Dynamic Attention）是 Moonshot AI 在 Kimi K3 中提出的新型 Attention 推理架构，其目标不是改变 Transformer 的基本计算逻辑，而是在保持 Transformer 表达能力的前提下，大幅降低超长上下文推理阶段的 Attention 计算量、KV Cache 占用以及显存带宽压力。传统 Transformer 的 Self-Attention 在生成每一个新 Token 时，都需要访问历史上下文中所有 Token 的 Key 和 Value，因此随着上下文不断增长，KV Cache 会持续膨胀，Attention 的访存开销逐渐成为整个推理系统最大的瓶颈。对于 Agent 系统来说，一个任务往往包含几十轮工具调用、数万 Token 的 Observation、Reasoning、Tool Return 和历史 Memory，如果仍然使用传统 Dense Attention，即使计算能力足够，GPU 大部分时间也会消耗在读取 KV Cache，而不是实际计算，因此长链路 Agent 推理的速度会迅速下降。KDA 的核心思想就是让模型只读取真正有价值的历史信息，而不是无差别访问全部 KV Cache，通过动态选择历史上下文，使每一步 Attention 的计算量与访存量大幅降低，同时尽可能保持模型性能。

传统 Self-Attention 可以表示为：

其中 Query 会与所有历史 Key 做相似度计算，然后利用得到的权重对全部 Value 做加权求和，因此如果历史长度为 $N$ ，理论上每生成一个新 Token 都需要访问全部 $N$ 个 KV Cache。当上下文达到几十万 Token 时，虽然 FlashAttention 等算法能够减少中间显存，但读取全部 KV Cache 的成本仍然无法避免。KDA 的改进思路是在计算 Attention 之前增加一层动态路由（Dynamic Routing），先判断哪些历史 Token 对当前 Query 最重要，再仅加载对应 KV，而不是一次读取全部历史缓存。从概念上可以表示为：

其中 $K'$ 、 $V'$ 并不是全部历史 KV，而是经过动态筛选后的子集，因此真正参与 Attention 的 Token 数量远小于完整上下文，从而降低 KV Cache 的访问压力。

KDA 的一个重要特点是动态（Dynamic）。传统 Sparse Attention 往往使用固定窗口（Sliding Window）、固定块（Block Sparse）或者预定义模式，这些方法虽然能够减少计算量，但模型无法根据当前任务动态调整关注区域。例如编写代码时，模型可能需要关注几千 Token 之前的函数定义；阅读论文时，可能需要回顾文档开头的数学符号；执行 Agent 时，又可能需要读取几十轮之前某次 Tool Call 的结果。固定窗口无法覆盖这些远距离依赖，而 KDA 会根据当前 Query 的语义动态决定需要访问哪些历史 KV，因此不同 Token 的 Attention 范围并不固定，而是随着推理过程不断变化。

从工程角度来看，KDA 的真正收益主要体现在 KV Cache 管理。传统 Transformer 每生成一个 Token，都会把新的 Key、Value 追加到 KV Cache：

# 传统 Transformer
kv_cache.append(
    new_key,
    new_value
)

下一步推理：

# Attention 访问全部历史 KV
context = attention(
    query,
    kv_cache
)

随着上下文增长，kv_cache 会越来越大，每一步都必须完整读取：

# 上下文长度

len(kv_cache)

# 1000

# 10000

# 100000

# ...

KDA 则会首先根据当前 Query 动态选择需要访问的 KV：

# 当前 Query
query = hidden_state

# 动态选择相关 KV
selected_cache = router.select(
    query=query,
    kv_cache=kv_cache
)

随后真正计算 Attention：

# 只计算选中的 KV
context = attention(
    query,
    selected_cache
)

这里 router 并不是简单按位置截断，而是依据 Query 与历史上下文的相关性动态筛选，因此不同 Query 访问的 KV 子集可能完全不同。

对于 Agent 场景，这种设计尤为重要。例如一个 Browser Agent 已经执行了二十多轮操作：

User Request →
Open Browser →
Search →
Click →
Read Page →
Tool Return →
Reasoning →
Search Again →
Database Query →
Reasoning →
Write Code →
Run Code →
...

传统 Attention 会在每一步继续访问整条 Trajectory，而 KDA 更可能优先读取与当前任务相关的 Observation、Reasoning 和 Tool Call，而忽略大量已经失效的中间日志，使推理速度保持稳定。对于代码 Agent，同样可以动态回到真正相关的函数定义，而不是扫描整个仓库上下文。

KDA 还与 Kimi K3 的 Agentic RL 后训练形成配合。Agent 在执行长链路 Rollout 时，会不断产生新的 Observation、Tool Return 和历史 Memory，如果没有高效的 Attention 机制，Rollout 越长，训练吞吐率就越低。KDA 能够减少长上下文推理成本，使同样 GPU 可以完成更多 Rollout，因此不仅提升推理速度，也提高了 Agentic RL 的数据采集效率。对于 On-Policy RL 而言，这意味着单位时间能够生成更多高质量 Trajectory，从而加快整个策略优化过程。

Kimi K3 的 Agentic RL 后训练创新点合集-含代码

Kimi K3 的 Agentic RL 后训练并不是在传统 PPO、GRPO 等强化学习算法上进行简单应用，而是针对大模型在真实 Agent 场景中的长链路决策特点，对数据采集、Rollout 生成、长上下文推理、工具调用、策略优化以及模型蒸馏进行了整体设计。传统 RLHF 更多关注 Prompt 到 Response 的文本生成过程，而 Agentic RL 面对的是一个持续与环境交互的决策系统，一条训练样本往往包含几十甚至几百步交互，每一步都会产生新的 Observation、Reasoning、Action、Tool Call、Tool Return 以及 Environment Feedback，因此模型优化目标也从单纯提高最终回答质量扩展为优化整条 Trajectory 的决策能力。K3 在后训练阶段大量采用真实环境 Rollout，让模型不断进入 Browser、Terminal、GUI、代码仓库等环境执行任务，再根据真实环境返回的 Reward 对策略进行更新，而不是依赖静态 SFT 数据进行监督学习，使训练数据始终保持 On-Policy，不断贴近当前模型能力边界。与此同时，K3 配合 KDA（Kimi Dynamic Attention）降低长上下文推理成本，使模型能够在几万甚至更长上下文中持续执行 Agent 推理，而不会因为 Attention 开销快速增长导致训练效率下降，这也是其能够支持复杂长链路任务的重要基础。

# -------------------------------
# Step 1：初始化 Agent 环境
# -------------------------------
# Environment 可以是 Browser、Terminal、GUI、
# Coding、TauBench 等真实交互环境
env = AgentEnvironment(task)

# 获取初始 Observation
observation = env.reset()

# -------------------------------
# Step 2：当前策略开始 Rollout
# -------------------------------
# Actor 根据 Observation 决定下一步 Action
trajectory = []

done = False

while not done:

    # 模型推理
    action = actor.generate(observation)

    # 与真实环境交互
    next_obs, reward, done, info = env.step(action)

    # 保存完整轨迹
    trajectory.append({
        "observation": observation,
        "action": action,
        "tool_call": info.get("tool_call"),
        "tool_return": info.get("tool_return"),
        "reward": reward
    })

    observation = next_obs

另一个重要创新是 Multi-Teacher On-Policy Distillation。传统知识蒸馏通常只有一个 Teacher，Student 模型尽可能拟合 Teacher 的输出分布，而 K3 后训练过程中允许多个 Teacher 同时参与监督，每个 Teacher 负责不同能力，例如代码生成、数学推理、工具调用、规划能力等，再通过 On-Policy Rollout 将多个 Teacher 的能力融合到 Student 中。Student 并不会机械模仿某一个 Teacher 的回答，而是在真实 Reward 的约束下学习多个 Teacher 的策略分布，因此既能够保持探索能力，又能够继承多个模型的优势，相比传统离线蒸馏能够获得更高的泛化能力。同时，Teacher 自身也不是固定数据集，而是随着 Student 能力提升持续参与新的 Rollout，因此整个蒸馏过程始终建立在最新策略产生的数据之上，而不是依赖早期静态轨迹。

针对 Agent 训练过程中大量 Tool Return 会干扰语言建模的问题，K3 在 RL 阶段采用 Tool Return Mask。Agent 每执行一次工具调用，都会返回大量 JSON、HTML、终端日志、数据库记录或网页源码，这些内容本身通常并不需要模型记忆，如果直接参与 Token Loss，会使模型浪费大量训练能力学习工具输出格式，而不是学习决策策略。因此 K3 在计算语言模型损失时会屏蔽 Tool Return 对应 Token，仅保留 Observation、Reasoning 和 Action 参与 Loss 计算，而工具执行结果则主要通过 Environment Reward 影响策略更新，使模型学习"什么时候调用工具、调用哪个工具以及如何利用工具结果继续规划"，而不是学习工具返回内容本身，从而显著提高 Agent RL 的训练效率。

# -------------------------------
# Step 3：Tool Return Mask
# -------------------------------
# 工具返回内容通常包含大量日志、JSON、
# HTML、终端输出等低价值 Token，
# RL Loss 不参与这些 Token 的训练
labels = input_ids.clone()

labels[tool_return_mask] = -100

# CrossEntropyLoss 会自动忽略 -100
loss = F.cross_entropy(
    logits.view(-1, vocab_size),
    labels.view(-1),
    ignore_index=-100
)

# -------------------------------
# Step 4：Multi-Teacher OPD
# -------------------------------
# 多个 Teacher 分别提供不同能力
teacher_outputs = [
    teacher_math.generate(prompt),
    teacher_code.generate(prompt),
    teacher_reason.generate(prompt)
]

# Student 使用当前策略生成回答
student_output = student.generate(prompt)

# Teacher 共同提供监督信号
teacher_logits = average_logits( teacher_outputs)

为了进一步降低长链路 RL 的训练成本，K3 采用了 Short Rollout 思想。传统 RL 通常会对完整 Trajectory 做反向传播，但对于几千甚至上万 Token 的 Agent Rollout，大部分早期 Token 对最终 Reward 的贡献非常有限，如果全部参与梯度计算，不仅显著增加显存占用，还会降低有效梯度密度。因此 K3 更倾向于保留能够影响最终 Reward 的关键轨迹参与训练，例如规划阶段、关键 Tool Call、错误恢复以及最终决策等位置，而不是完整保留所有交互过程，使 RL 更新更加聚焦于真正影响策略优化的部分，同时提高训练吞吐率。随着模型能力不断提升，新策略又会重新进入环境生成新的 Rollout，旧轨迹逐渐从 Replay Buffer 中淘汰，新的 On-Policy 数据不断加入训练，从而形成"Rollout Generation→Reward Evaluation→Replay Buffer→Policy Optimization→Model Update→New Rollout"的持续闭环，使模型能力能够不断自我提升。

# -------------------------------
# Step 5：RL + Distillation Loss
# -------------------------------
# RL 保证策略优化
rl_loss = ppo_loss(
    old_log_probs,
    new_log_probs,
    advantages
)

# Teacher 保持能力上界
distill_loss = kl_div(
    student_logits,
    teacher_logits
)

# 两部分共同优化
loss = rl_loss + beta * distill_loss

# -------------------------------
# Step 6：Short Rollout
# -------------------------------
# 只保留真正影响最终 Reward 的关键轨迹
short_traj = trajectory[-256:]

# 避免几千 Token 全部参与反向传播
trainer.update(short_traj)


# -------------------------------
# Step 7：Replay Buffer
# -------------------------------
# 保存当前策略产生的 On-Policy 数据
replay_buffer.add(

    trajectory
)

# 丢弃过旧轨迹
replay_buffer.evict_old()


# -------------------------------
# Step 8：下一轮 On-Policy Rollout
# -------------------------------
# 更新后的模型重新进入环境，
# 继续采集最新轨迹
actor.load_state_dict(

    trainer.latest_policy()
)

trajectory = rollout_worker.run(
    actor,
    env
)

Kimi K3 的训练和部署怎么做的？QAT是什么？

Kimi K3 的训练和部署并不是传统意义上的"训练一个 MoE 模型然后部署"，而是从模型结构设计开始就围绕超大规模 MoE、高吞吐训练以及低成本推理共同设计，因此整个系统实际上是一条完整的端到端 Pipeline，而不是几个独立模块的简单组合。官方公开资料显示，K3 约有 2.8T Parameters、896 Experts、每个 Token 激活 16 个 Expert、100 万 Token Context，如果按照传统 Transformer + MoE 的方式训练，这样规模的模型几乎无法稳定收敛，也无法在有限 GPU 集群上高效部署，因此 Moonshot 在训练阶段同时设计了 Stable LatentMoE、Balanced Expert Parallel、QAT（Quantization-aware Training）、KDA、Attention Residuals、Hybrid Attention、Hybrid Parallelism 等一整套系统，使训练和部署天然保持一致，而不是训练结束以后再进行部署优化。整个训练主线可以表示为：Training Data → Tokenizer → Hybrid Attention → Stable LatentMoE → Balanced Expert Parallel → QAT Training → SFT → RL → Checkpoint → Quantized Serving。

首先，K3 并没有采用传统 Dense Transformer，而是采用 Stable LatentMoE。MoE（Mixture of Experts）的核心思想是总参数可以非常大，但每个 Token 只激活极少数 Expert，因此 Forward FLOPs 保持相对稳定。例如 K3 的配置可以表示为：

TOTAL_EXPERTS = 896
TOP_K = 16

router_score = router(hidden)

selected = torch.topk(
    router_score,
    TOP_K
)

output = 0

for idx in selected.indices:
    output += experts[idx](hidden)

也就是说，虽然模型总共有约 896 个 FFN Expert，但一次 Forward 实际只计算其中 16 个，因此一个 Token 的计算量更接近几十亿参数模型，而容量却接近数万亿参数模型。但是传统 MoE 最大的问题并不是计算，而是 Expert Balance。如果 Router 自己学习，很容易出现：

Expert1    45%
Expert2    30%
Expert3    15%
其它893个 10%

大量 Expert 几乎没有训练，而少数 Expert GPU 已经完全跑满。传统 Switch Transformer 通常采用 Auxiliary Load Balance Loss：

loss = task_loss + λ * load_balance_loss

其中：

load_balance_loss = variance(
    expert_usage
)

虽然能够一定程度缓解问题，但 Router 与主任务之间存在冲突，经常影响模型最终性能。

K3 则提出 Stable LatentMoE，并采用 Quantile Balancing 替代传统 Auxiliary Loss，其核心思想不是额外增加一个 Balance Loss，而是在 Router 本身进行分位数（Quantile）约束，使每个 Expert 天然获得更加均匀的数据流。整个流程更接近：

router_score = router(hidden)

quantile = compute_quantile(
    router_score
)

selected = balanced_topk(
    quantile
)

而不是：

selected = torch.topk(
    router_score
)

这样 Router 不需要额外学习 Load Balance，而是在 Routing 阶段就自动保持 Expert 使用率更加均衡，因此官方称为 Stable LatentMoE，其训练稳定性明显高于传统 Sparse MoE。

Expert Balance 之后，又引出了另一个工程问题，即 Expert Parallel。如果每张 GPU 保存全部 896 个 Expert，那么显存根本无法容纳，因此实际部署通常采用 Expert Parallel，将 Expert 分散到不同 GPU。例如：

GPU0

Expert0~55

GPU1

Expert56~111

GPU2

Expert112~167

...

GPU15

Expert840~895

Router 输出以后，需要把 Token 自动发送到对应 GPU。例如：

token

↓

Router

↓

Expert3

↓

GPU0

另一个 Token：

token

↓

Router

↓

Expert520

↓

GPU9

因此实际 Forward 会出现大量 All-to-All 通信。对应伪代码可以表示为：

expert_id = router(token)

remote_gpu = expert_table[
    expert_id
]

send(
    token,
    remote_gpu
)

output = receive()

因此 Expert Parallel 的通信效率几乎决定整个 MoE 推理吞吐。Moonshot 在训练过程中采用 Balanced Expert Parallel，目标不是简单平均分配 Expert，而是同时考虑：

Router Usage

+

GPU Memory

+

Communication Cost

+

Compute FLOPs

使每张 GPU：

Load ≈ Equal

而不是：

GPU0 95%

GPU1 20%

GPU2 75%

否则整个训练速度将由最慢 GPU 决定。除了 Expert Parallel，K3 训练同样采用 Hybrid Parallel，而不是单一 Data Parallel。整个系统更接近：

Data Parallel

×

Tensor Parallel

×

Pipeline Parallel

×

Expert Parallel

例如：

Cluster

↓

DP

↓

Node

↓

PP

↓

GPU

↓

TP

↓

Expert

每一种 Parallel 都负责不同层次。对应训练过程：

batch

↓

Data Parallel

↓

Transformer Layer

↓

Tensor Parallel

↓

MoE

↓

Expert Parallel

四种 Parallel 同时存在，因此才能训练数万亿参数模型。K3 在训练阶段另一个非常重要的创新就是 QAT（Quantization-aware Training）。

传统模型通常：

FP16 Training

↓

Finish

↓

INT8 Quantization

或者：

BF16

↓

GPTQ

↓

AWQ

这种方式属于 PTQ（Post Training Quantization）。

问题在于：模型训练时从未见过量化误差。因此部署以后：

Accuracy ↓

Reasoning ↓

Tool Use ↓

K3 则直接在训练阶段模拟量化误差，使模型天然适应低精度。整个训练过程：

Forward

↓

Fake Quant

↓

Backward

↓

Update FP Weight

对应代码可以表示为：

weight_fp = parameter

weight_quant = fake_quantize(
    weight_fp
)

output = linear(
    input,
    weight_quant
)

loss.backward()

optimizer.step()

注意：

真正更新的是：

weight_fp

而不是：

weight_quant

因此称为 Fake Quantization。

官方公开资料显示，K3 训练阶段已经采用：

Weight

↓

MXFP4

Activation

↓

MXFP8

整个 Forward：

weight = MXFP4(weight)

activation = MXFP8(
    activation
)

output = matmul(
    activation,
    weight
)

因此模型在训练期间已经不断适应：

4-bit Weight

+

8-bit Activation

部署阶段无需再次进行复杂 PTQ。

最终部署时：

Checkpoint

↓

Direct Quantized Model

↓

Serving

而不是：

Checkpoint

↓

GPTQ

↓

Calibration

↓

Deploy

这样不仅部署速度更快，而且量化精度损失更小。

部署阶段，K3 同样围绕低延迟进行了大量优化。由于采用 KDA，大部分 Layer 不再维护传统 Transformer 的完整 KV Cache，而是维护有限状态，因此：

传统 Transformer：

Token

↓

KV Cache++

↓

Attention

每生成一个 Token：

KV Cache

越来越大

而 KDA：

Token

↓

Delta Update

↓

State Update

状态大小几乎保持固定，因此官方数据显示 KV Cache 可减少约 75%，百万 Context 推理吞吐可提升约 6 倍。

整个部署链路可以表示为：

Prompt → Tokenizer → Embedding → KDA ×3 → MLA ×1 → Attention Residual → Stable LatentMoE → Router → Expert Parallel → MXFP4 GEMM → Decoder → Next Token

其中 Router 决定 Token 去哪个 Expert，Balanced Expert Parallel 保证各 GPU 负载均衡，MXFP4/MXFP8 保证低显存推理，KDA 保证超长 Context 的线性扩展，而 Hybrid Parallel 保证整个模型能够横跨数百张 GPU 持续运行。

因此，K3 的训练与部署并不是几个独立优化的简单叠加，而是形成了一条完整的协同设计路线：Training Data → Stable LatentMoE → Quantile-balanced Routing → Balanced Expert Parallel → Hybrid Parallel（DP+TP+PP+EP）→ QAT（MXFP4+MXFP8）→ SFT → RL → Quantized Checkpoint → KDA-based Serving → Million-token Inference。其中 Stable LatentMoE 解决 Expert 收敛稳定性，Balanced Expert Parallel 解决 GPU 负载均衡，Hybrid Parallel 解决超大规模训练，QAT 保证训练即适配量化部署，KDA 则解决长上下文 Attention 和 KV Cache 问题，这几项共同构成了 Kimi K3 从训练到部署的一体化工程体系，而不仅仅是一个采用 MoE 的大语言模型。

Kimi K3 的整体架构主线是什么？ KDA有什么作用？

Kimi K3 的整体架构主线可以概括为 KDA（Kimi Delta Attention）+ Attention Residuals（AttnRes）+ Stable LatentMoE + Hybrid Attention。其中 KDA 并不是一个独立模型，而是整个 K3 的核心 Attention 架构，它决定了模型如何处理长上下文、如何降低 KV Cache 开销以及如何提升推理吞吐。官方资料显示，K3 是目前首个开源 3T（2.8T）级模型，总参数约 2.8 万亿，每个 Token 实际仅激活 896 个 Expert 中的 16 个，同时拥有 100 万 Token 上下文窗口。相比上一代 K2，官方称整体 Scaling Efficiency 提升约 2.5 倍，而这种提升主要来自 KDA、Attention Residuals 和 Stable LatentMoE 的协同设计，而不是单纯扩大参数规模。(Kimi AI)

整个 K3 的计算流程可以表示为：Token → Embedding → KDA Layer → KDA Layer → KDA Layer → Gated MLA Layer → Attention Residual → Stable LatentMoE → FFN → Next Block → ... → Decoder → Next Token。官方公开的信息显示，K3 并没有完全使用传统 Transformer Full Attention，而是采用 3:1 的 Hybrid Attention 结构，约四层 Attention 中三层使用 KDA，一层使用 Gated MLA（Multi-head Latent Attention），因此模型既能够保持线性 Attention 的高效率，又能够周期性地恢复完整全局 Attention 的表达能力，而不是完全放弃二次 Attention。整个结构可以理解为：

KDA → KDA → KDA → Gated MLA → KDA → KDA → KDA → Gated MLA → ...

这种交替结构意味着，大部分计算采用线性复杂度完成，而少量 Layer 保留全局信息建模能力，因此相比全部使用 Full Attention，计算量明显下降，同时不会像纯 Linear Attention 那样损失全局表达能力。

传统 Transformer Attention 的计算可以表示为：

$Attention(Q,K,V)=softmax\left(\frac{QK^T}{\sqrt d}\right)V$

其中需要计算完整的：

因此时间复杂度为： $State_t=f(State_{t-1},x_t)$

对应代码通常就是：

Q = Wq(x)
K = Wk(x)
V = Wv(x)

score = torch.matmul(
    Q,
    K.transpose(-2, -1)
)

weight = torch.softmax(
    score / math.sqrt(d),
    dim=-1
)

output = torch.matmul(
    weight,
    V
)

当 Context 达到几十万甚至一百万 Token 时，完整 Attention Matrix 已经无法存储，因此传统 Transformer 很难继续扩展。

KDA 的核心思想来自 Moonshot 此前公开的 Kimi Linear 工作，它不是直接计算完整 Attention Matrix，而是利用 Delta Rule + Gated State Update + Linear Attention 来维护一个持续更新的隐藏状态（State），每读取一个 Token，只更新当前状态，而不是重新与全部历史 Token 做 Attention，因此计算方式更接近一种可学习的状态空间模型（State Space Model），其思想可以表示为：

$State_t=f(State_{t-1},x_t)$

而不是：

$Attention(x_t,x_1,\cdots,x_{t-1})$

代码可以写成：

state = init_state()

for token in tokens:

    state = delta_update(
        state,
        token
    )

    output = state

因此每读取一个新 Token，并不会重新扫描全部历史 Token，而只是更新一次状态。

官方称 KDA 属于 Delta Attention，它建立在 Gated DeltaNet 的基础之上，引入更加细粒度的 Gating，使有限状态能够保存更多有效历史信息，同时采用专门设计的 Chunkwise Kernel 和 DPLR（Diagonal Plus Low Rank）状态更新算法提高 GPU 利用率，因此整个 Attention 更接近：

state = gate * state

state += update(token)

output = project(state)

而不是：

attention = Q @ K.T

output = attention @ V

因此随着 Context 增长，KDA 的状态大小几乎保持固定，不需要保存越来越大的 KV Cache。

传统 Transformer 推理过程中，每生成一个 Token，都需要保存全部历史 Key、Value：

Token1 KV
Token2 KV
Token3 KV
...
Token1000000 KV

KV Cache 会持续增长。

KDA 则更接近：

Token1

↓

Update State

↓

Token2

↓

Update State

↓

Token3

↓

Update State

始终维护一个有限状态，因此官方公开数据显示，相比传统 Full Attention，KDA 可以减少约 75% KV Cache 占用，同时在百万上下文推理时获得最高约 6 倍 Decoding Throughput。(arXiv)

但是 Linear Attention 也存在天然问题，由于不断压缩历史信息，模型容易逐渐遗忘远距离的重要表示，因此 K3 又提出了 Attention Residuals（AttnRes）。传统 Transformer 的 Residual Connection 表示为：

x = x + attention(x)

x = x + ffn(x)

每一层都不断向同一 Residual Stream 累积。

AttnRes 则允许当前 Layer 有选择地重新读取更早 Layer 的表示，而不是所有信息都必须经过连续残差传播，更接近：

x = attention(x)

history = retrieve(
    previous_layers
)

x = x + history

因此信息不仅可以沿深度连续传播，还可以跨 Layer 检索早期特征，减少超深网络的信息衰减。官方描述其本质是"selectively retrieves representations across depth rather than accumulating them uniformly"。

除了新的 Attention，K3 仍然采用稀疏 MoE，但进一步升级为 Stable LatentMoE。整个模型共有约：

896 Experts

每个 Token：

Top-16 Experts Activated

因此一次 Forward 实际参与计算的参数远小于总参数规模。

Router 可以表示为：

scores = router(hidden)

topk = torch.topk(
    scores,
    k=16
)

output = sum(

    experts[i](hidden)

    for i in topk.indices

)

官方进一步提出 Quantile Balancing，直接根据 Router Score 的 Quantile 进行 Expert 分配，不再需要传统 MoE 常见的 Auxiliary Load Balance Loss，因此 Expert 利用率更加稳定，同时减少了一个敏感超参数。(Kimi AI)

训练方面，K3 从 SFT 阶段开始即采用 Quantization-aware Training，权重使用 MXFP4，激活使用 MXFP8，因此模型训练阶段就已经适配低精度推理，而不是训练结束后再进行离线量化，这使部署效率进一步提高。(Kimi AI)

整个 K3 可以概括为如下主线：

Input → Embedding → KDA ×3 → Gated MLA ×1 → Attention Residual → Stable LatentMoE → FFN → Repeat → Decoder → Next Token

其中 KDA 负责解决长上下文 Attention 的计算瓶颈；Gated MLA 定期恢复完整全局建模能力；Attention Residuals 改善超深网络中的信息流动；Stable LatentMoE 利用 16/896 的稀疏激活扩展模型容量；Quantization-aware Training 则保证模型从训练阶段就兼顾推理效率。官方表示，这几项设计共同带来了约 2.5 倍于 K2 的 Scaling Efficiency，使 K3 能够在保持百万 Token 上下文和超大参数规模的同时，兼顾推理效率与 Agent 长链路任务能力，而不仅仅依赖增加参数数量来提升性能。(Kimi AI)

GLM系列模型技术解析

GLM-5.3 后训练 Scaling 的第一性原理与技术创新

GLM-5.3 最值得关注的地方不是换了一个更大的 Base Model，而是在基本不改变 Base Model 的情况下，通过持续扩大 Post-Training 的计算量、任务环境、Trajectory 数量、任务难度和训练迭代，把 GLM-5.2 已经存在的 Agent 能力进一步“挖出来”；Z.ai 在 2026 年 8 月 14 日公布 GLM-5.3 时明确强调其提升主要来自 Post-Training Scaling，而不是重新进行一次 Base Model Pre-training，公开资料显示 GLM-5.3 与 GLM-5.2 使用相同的基础模型路线，提升重点集中在复杂 Coding、长程 Agent Task 和 Cyber 等需要大量交互的任务上，例如官方报告的内部 Code Bench 提升约 50%，而 CyberGym 达到 84.5%，ExploitBench 从 GLM-5.2 的 24.4% 提升到 54.4%，这说明它真正验证的不是“模型参数越大越强”，而是当 Base Model 已经具备足够能力之后，继续增加有效 Post-Training Compute，尤其是增加可执行 Environment、On-Policy Rollout 和 RL Iteration，同样能够产生非常大的能力增长。(Reuters)

# GLM-5.3最核心的Scaling思想
# 不重新训练一个更大的Base Model
base_model = glm_5_2

# 而是在同一个Base Model上增加Post-Training Compute
for iteration in range(more_rl_iterations):

    # 增加更复杂、更长的Agent任务
    tasks = sample_harder_tasks()

    # Agent在真实可执行Environment中Rollout
    trajectories = rollout(
        model=base_model,
        tasks=tasks
    )

    # Verifier / Environment产生真实Reward
    rewards = verify(
        trajectories
    )

    # 使用RL更新Policy
    base_model = rl_update(
        base_model,
        trajectories,
        rewards
    )

从第一性原理来看，Pre-training 的核心是在扩大模型的“潜在能力上限”，Post-Training 的核心则是在提高模型把这些潜在能力转化成有效行为的概率，对于普通问答任务，增加 Post-Training 可能主要表现为 Instruction Following、格式遵循和偏好对齐，但对于 Agent 来说，真正的能力不是“知道答案”，而是 理解任务 → 制定计划 → 调用工具 → 获取 Observation → 判断结果 → 修正错误 → 继续执行 → 最终完成任务，因此 Agent 的能力上限不仅取决于模型本身，还取决于模型是否经历过足够多的 真实状态转移；如果一个模型只训练过 10 万条简单 Tool Call，那么即使继续增加 SFT 数据，也很难让它突然学会一个需要几百步交互、多个文件修改、测试失败后自主 Debug 的任务，所以 GLM-5.3 的 Scaling 第一性原理实际上可以写成：Agent Capability ≈ Base Capability × Environment Coverage × Successful Trajectory Density × RL Compute × Task Horizon，也就是说 Post-Training Scaling 的重点已经从“增加更多文本”变成了“增加更多有效的可执行经验”。

# 普通LLM训练关注Token数量
pretraining_compute = (
    num_tokens
    * model_size
)

# Agent后训练更关注有效交互经验
agent_posttraining_compute = (
    num_rollouts
    * avg_steps
    * avg_tokens_per_step
    * task_difficulty
    * environment_diversity
)

# 因此Agent Scaling不只是增加Token
# 而是增加有效Environment Interaction

这也是为什么 Environment Scaling 会成为 GLM-5.3 后训练的关键，因为 Agent 训练数据不应该只是静态 prompt → answer，而应该变成 task → action → observation → action → observation → ... → reward，模型每一次和 Environment 交互都可能产生新的训练样本，因此如果 Environment 数量、任务类型、状态空间和任务难度不断扩大，模型实际上获得的是一个越来越丰富的 Policy Learning Distribution；对于 Coding Agent 来说，一个 Environment 可以是真实 Git Repository，模型需要修改代码、运行测试、读取错误日志、定位 Bug、重新修改并最终提交 Patch，这比单纯给模型一个“请修复这个 Bug”的文本样本提供了更多训练信号。

# 一个Coding Agent任务不是一个静态QA样本
trajectory = [
    {
        "state": "repository_initial",
        "action": "read_file",
        "observation": "source_code"
    },
    {
        "state": "source_code",
        "action": "edit_file",
        "observation": "file_modified"
    },
    {
        "state": "modified_code",
        "action": "run_tests",
        "observation": "test_failed"
    },
    {
        "state": "test_failed",
        "action": "debug",
        "observation": "root_cause_found"
    },
    {
        "state": "fixed",
        "action": "run_tests",
        "observation": "all_tests_passed"
    }
]

# 最终Reward由Environment/Verifier决定
reward = verifier.score(trajectory)

GLM-5.3 这种 Scaling 的第二个关键是 Long-Horizon Scaling，因为短任务中模型可能只需要做一两个正确 Action，但长任务会产生大量误差累积，例如单步 Action 正确率假设是 99%，如果任务需要执行 100 步，那么完全不出错的概率理论上只有 0.99^100 ≈ 36.6%，所以 Agent 的真正瓶颈不是单步能力，而是 长时间保持正确状态、错误恢复和目标一致性；因此当训练任务从几十步扩大到几百步甚至更长时，模型会被迫学习 Planning、State Tracking、Error Recovery 和 Tool Selection，这也是为什么 GLM-5.3 的提升主要集中在 Coding Agent、Terminal Agent 和 Cyber Agent 这类 Long-Horizon Task 上。

# 长任务会放大单步错误
step_success_rate = 0.99
num_steps = 100

# 理想情况下连续100步全部正确的概率
trajectory_success = step_success_rate ** num_steps

print(trajectory_success)
# 约0.366

因此 Post-Training Scaling 的核心单位已经从 Token 变成 Trajectory，Pre-training 可以问“训练了多少 Trillion Tokens”，但 AgentRL 更应该问“模型经历了多少有效 Trajectories、每条 Trajectory 有多少 Environment Steps、成功率是多少、任务覆盖了多少 State Space”，如果只增加 Rollout 数量但任务非常简单，那么 Scaling 很可能只是重复采样；真正有价值的是增加 有效状态覆盖率，也就是让模型不断进入以前没有见过、或者当前 Policy 容易失败的 State。

# AgentRL真正应该统计的Scaling指标
metrics = {
    "num_trajectories": len(trajectories),

    # 平均每条轨迹的交互长度
    "avg_steps": average_steps(trajectories),

    # 成功轨迹比例
    "success_rate": success_rate(trajectories),

    # Environment覆盖的任务数量
    "num_environments": len(environments),

    # 不同任务类型覆盖程度
    "task_diversity": calculate_diversity(tasks),

    # 长轨迹比例
    "long_horizon_ratio": calculate_long_horizon_ratio(
        trajectories
    )
}

第三个关键创新是 Verifier Scaling，因为 RLVR 的前提是 Environment 能够告诉模型“做得对不对”，如果 Reward 设计得很弱，增加 RL Compute 反而可能让模型越来越擅长钻 Reward Hack；因此高质量 AgentRL 的 Scaling 不是简单增加 GPU，而是同时增加 更强的 Environment + 更可靠的 Verifier + 更丰富的 Task Generator，GLM-5 的公开技术报告已经明确把 Agent RL 建立在可执行任务、Tool Invocation、Environment Feedback 和 Verifier-guided branching 之上，而 GLM-5.3 进一步把这种思路用于更大规模、更长周期的 Post-Training。(alphaXiv)

# 一个高质量AgentRL任务需要完整的闭环
task = task_generator.generate()

# Environment必须真实可执行
env = environment.reset(task)

trajectory = []

while not env.done:

    # Policy产生Action
    action = model.generate(env.state)

    # Environment执行Action
    observation = env.step(action)

    trajectory.append({
        "state": env.state,
        "action": action,
        "observation": observation
    })

# Verifier给出最终结果
reward = verifier.evaluate(
    task,
    trajectory,
    env.final_state
)

第四个关键点是 Rollout Compute Scaling，AgentRL 的最大计算瓶颈之一不是 Training，而是 Rollout，因为传统 RL 往往需要 Generate → Wait → Train → Generate，如果 Training GPU 和 Inference GPU 互相等待，那么大量 GPU 时间都会浪费在同步上；GLM 系列此前已经通过 slime 建立了异步 RL 基础设施，把 Rollout 和 Training 解耦，并支持多任务 Rollout、Server-based Execution、Mixed Precision、MTP、Prefill-Decode Disaggregation、Heartbeat Fault Tolerance 等机制，因此 Post-Training Scaling 真正能够成立的基础并不是“多买 GPU”，而是 让新增 GPU 真正转化成更多有效 Rollout 和 Training FLOPs。(alphaXiv)

# 传统同步RL
while True:

    # Trainer等待Rollout
    trajectories = rollout(model)

    # Rollout完成后才能训练
    model = train(model, trajectories)


# 异步RL
rollout_queue = Queue()

# Rollout Worker持续产生Trajectory
rollout_workers.start(
    model,
    output_queue=rollout_queue
)

# Trainer持续消费Trajectory
while training:

    batch = rollout_queue.get()

    model = train(
        model,
        batch
    )

这里就会出现 GLM-5.3 后训练 Scaling 的一个核心技术问题：如果 Rollout Policy 和 Training Policy 不同步，数据就会变成 Off-Policy，而 Agent Trajectory 又非常长，所以 Policy 在生成一条 200-step trajectory 的过程中可能已经更新很多次，如果完全不处理这种 Policy Lag，训练数据和当前模型之间的分布差异会越来越大，因此 GLM-5 的 Agent RL 基础设施和算法设计中重点处理了异步 Rollout 的 Off-Policy 问题，公开技术报告介绍了异步 RL、可定制 Rollout 和稳定性机制，而相关技术解读还提到 Double-sided Importance Sampling、Token-level Clipping 和过旧 Sample 丢弃等设计，用于控制 Staleness。(alphaXiv)

# 异步Rollout产生Trajectory时记录生成Policy版本
trajectory = {
    "policy_version": rollout_policy_version,
    "tokens": tokens,
    "old_logprobs": old_logprobs,
    "reward": reward
}

# Trainer当前Policy版本
current_version = trainer.policy_version

# 如果Trajectory过旧，直接丢弃
if current_version - trajectory["policy_version"] > max_staleness:
    discard(trajectory)
else:
    # 使用Importance Sampling修正Policy差异
    ratio = torch.exp(
        current_logprobs
        - trajectory["old_logprobs"]
    )

    # 防止Importance Ratio过大造成训练不稳定
    ratio = torch.clamp(
        ratio,
        1 - clip_eps,
        1 + clip_eps
    )

第五个关键创新是 Task Scaling，而不是简单 Data Scaling，传统 SFT 可以通过不断增加高质量 Instruction 数据提升能力，但 AgentRL 中如果任务分布不变，继续训练很容易出现 Overfitting，也就是模型越来越擅长某一批 Benchmark，却没有真正增加 General Agent Capability，因此更有效的方法是不断生成新的 Environment 和新的任务，例如同一个 Coding Environment 可以生成不同 Bug、不同 Repository、不同依赖冲突、不同测试失败方式、不同需求变化，这种 Procedural Task Generation + Environment Scaling 本质上是在扩大模型需要学习的 State Distribution。

# 不只是重复同一个Prompt
for environment in environments:

    # 在不同真实项目中生成任务
    tasks = task_generator.generate(
        environment=environment,
        difficulty="hard",
        horizon=random_horizon()
    )

    # 每个任务进入AgentRL
    for task in tasks:

        trajectory = rollout(
            model,
            task
        )

        reward = verifier.score(
            trajectory
        )

第六个关键点是 失败轨迹本身也是 Scaling 资源，AgentRL 不能只保留成功 trajectory，因为真正能够提升 Policy 的往往是模型失败的位置，例如模型在第 47 步错误调用 Tool、在第 80 步误读测试结果、在第 120 步进入错误循环，这些 Failure State 可以通过 Verifier、Trajectory Analyzer 和 Error Classifier 被重新加工成训练任务，因此 Post-Training Scaling 不应该只是 Success Trajectory Scaling，而应该是 Failure Discovery → Failure Classification → Targeted Rollout → Corrective Training，这和你之前问的 Bad Case 数据回流、SAO、OPD、RFT 本质上可以连接起来。

# 找出Agent失败轨迹
bad_cases = [
    traj
    for traj in trajectories
    if traj.reward <= 0
]

# 分析失败原因
for traj in bad_cases:

    failure = failure_analyzer.analyze(
        traj
    )

    # 将失败State转成新的训练任务
    hard_task = task_generator.rebuild(
        failure
    )

    # 针对失败State重新Rollout
    new_trajectory = rollout(
        model,
        hard_task
    )

第七个值得关注的创新是 Sequential / Progressive RL Scaling，GLM-5 的公开技术报告并不是把所有 RL Objective 一次性混在一起，而是采用逐阶段的 Post-Training Strategy，例如先通过 Multi-task SFT 建立基础行为，再进行 Reasoning RL，然后进行 Agent RL，最后通过 General RL 做整体对齐，并使用 On-Policy Cross-Stage Distillation 缓解不同阶段之间的能力回退；这种设计背后的第一性原理是不同能力之间存在明显的梯度冲突，例如 Reasoning RL 可能强化长思考，但 General RL 又可能希望减少某些不必要的行为，因此不能简单把所有 Reward 加起来训练，而应该把复杂能力拆成不同 Stage，让每个阶段解决一个主要目标。(alphaXiv)

# Progressive Post-Training
model = base_model

# Stage 1：建立基本Agent行为
model = sft(
    model,
    multitask_sft_dataset
)

# Stage 2：强化Reasoning
model = reasoning_rl(
    model,
    reasoning_environment
)

# Stage 3：强化Agent能力
model = agent_rl(
    model,
    agent_environments
)

# Stage 4：General RL进行整体对齐
model = general_rl(
    model,
    general_tasks
)

# Stage 5：跨阶段蒸馏，避免能力回退
model = cross_stage_distillation(
    model,
    previous_checkpoints
)

这里的 Cross-Stage Distillation 很重要，因为 Scaling Post-Training 会产生一个新的问题：如果只追求当前 Stage 的 Reward，模型可能遗忘前一个 Stage 已经学会的能力，例如 Agent RL 大量训练 Coding Task 后，数学 Reasoning 能力下降，因此可以把之前 Stage 的 Checkpoint 当作 Teacher，在当前 On-Policy State 上进行 Distillation，这种设计实际上把你之前学习的 MOPD、OPD、Self-Distilled RL 和 AgentRL 连接起来：RL 负责把能力往当前目标方向推，Distillation 负责防止模型在这个过程中把旧能力丢掉。GLM-5 技术报告公开介绍了 On-Policy Cross-Stage Distillation 作为最终 refinement，用于降低能力回退。(alphaXiv)

# 当前模型：经过AgentRL后能力增强
student = current_model

# 旧阶段Checkpoint作为Teacher
teachers = [
    sft_checkpoint,
    reasoning_rl_checkpoint,
    general_rl_checkpoint
]

# 在Student当前On-Policy State上进行蒸馏
for state in student_states:

    teacher_targets = [
        teacher.predict(state)
        for teacher in teachers
    ]

    # 保留旧模型的有价值能力
    distill_loss = multi_teacher_distill(
        student,
        teacher_targets
    )

    # 与当前RL目标联合训练
    loss = rl_loss + alpha * distill_loss

从 AI Infra 的角度看，GLM-5.3 这种 Scaling 真正改变的是 Post-Training Compute 的经济模型，以前模型能力增长很大程度依赖“重新训练更大的 Base Model”，现在则越来越像一个工业系统：Task Generation → Environment Provisioning → Rollout → Verification → Replay / Buffer → RL Training → Checkpoint → Evaluation → Hard Case Mining → New Rollout，因此 Post-Training Infrastructure 本身成为 Scaling Law 的一部分，GPU 数量只是其中一个变量，真正重要的是 GPU Utilization × Rollout Throughput × Training Throughput × Environment Throughput × Verifier Throughput × Iteration Count。

# AgentRL有效Scaling可以粗略理解成
effective_compute = (
    rollout_gpu_utilization
    * rollout_throughput
    * training_gpu_utilization
    * training_throughput
    * environment_throughput
    * verifier_throughput
    * num_iterations
)

# 所以不是GPU越多一定越强
# 如果Environment / Rollout / Verifier成为瓶颈，
# 新增GPU无法转化成有效Training Signal

GLM-5.3 后训练 Scaling 的第一性原理可以总结成一句话：**当 Base Model 已经拥有足够高的潜在能力以后，模型能力的主要瓶颈开始从“模型知道多少”转向“模型是否经历过足够多、足够难、足够真实、足够长的有效决策过程”，因此 Scaling 的对象从 Pre-training Token 转移到了 Post-Training Trajectory，从静态 Dataset 转移到了 Executable Environment，从单一 Reward 转移到了可靠 Verifier，从同步 RL 转移到了高吞吐异步 RL，从简单增加 Rollout 数量转移到了扩大 Task / Environment / Horizon / Failure State Coverage，从单阶段 RL 转移到了 Progressive RL + Cross-Stage Distillation，这也是 GLM-5.3 最值得关注的技术创新——不是 Base Model Scaling，而是把 Post-Training 本身工程化、环境化、异步化和规模化，让更多 GPU Compute 转化成更多有效 Agent Experience；不过需要注意，GLM-5.3 刚于 2026 年 8 月 14 日公布，当前公开信息主要来自 Z.ai 的发布材料和 GLM-5 技术报告体系，部分 GLM-5.3 具体训练配方尚未像 GLM-5 技术报告一样完整公开，因此上面涉及 GLM-5.3 的具体机制，应区分“官方已确认的 Post-Training Scaling”与“基于 GLM-5 已公开基础设施对 GLM-5.3 的技术推断”，不能把所有 GLM-5 的实现细节都直接宣称为 GLM-5.3 新增技术。(Reuters)

GLM-5.2 在 Agentic RL 后训练中提出的 CompactionRL有什么用

GLM-5.2 在 Agentic RL 后训练中提出的 CompactionRL（Trajectory Compaction Reinforcement Learning），本质上是一种针对超长 Agent 轨迹（Long-horizon Agent Trajectory）的强化学习训练方法，它解决的问题不是如何获得更高的 Reward，而是如何让模型能够在有限 Context Window 内持续完成数百甚至数千步 Tool Use、Planning 和 Reflection，而不会因为上下文越来越长导致显存急剧增加、Attention 计算复杂度爆炸以及模型逐渐遗忘早期信息。传统 Agent RL 中，一次 Rollout 会不断把新的 Observation、Tool Return、Reflection、Action 拼接到上下文后面，例如：User Request → Planner → Search → Observation → Planner → Python → Observation → Reflection → Browser → Observation → Final Answer。如果每一步 Observation 都完整保留，那么随着 Agent 不断执行任务，Context 会持续增长，例如第 1 步只有几百个 Token，第 20 步可能达到数万个 Token，第 100 步甚至超过模型最大 Context Window，不仅 GPU 显存占用持续增长，而且 Self-Attention 的计算复杂度为 (O(n^2))，Token 数量增加一倍，Attention FLOPs 将增加约四倍，因此长链路 Agent 的训练成本远高于普通语言模型。传统方法通常只能在 Context 超过窗口时直接截断（Truncation），例如：

context = context[-max_length:]

或者采用滑动窗口（Sliding Window）：

context = (
    recent_context +
    latest_observation
)

虽然能够控制长度，但是大量历史 Planning、Tool Decision 和关键 Observation 会被直接删除，导致 Agent 后续推理缺乏上下文，出现"忘记自己已经做过什么"的问题，因此 Agent 在长任务中容易重复调用工具、重复规划甚至进入死循环。

CompactionRL 的核心思想不是简单删除历史，而是在强化学习过程中动态学习如何"压缩（Compact）"轨迹，把已经完成推理所需的重要信息保留下来，把冗余 Token 转换成更加紧凑的表示，使模型能够利用较短的 Context 完成同样的任务。整个流程可以表示为：Original Trajectory → Compaction Policy → Compact Context → Continue Rollout → RL Optimization，压缩后的 Context 不再是原始 Tool Return，而是模型生成的一段结构化摘要，例如：

Original Context

↓

Search:
返回20页网页

↓

Python:
输出500行日志

↓

Browser:
HTML 300KB

↓

Compact

压缩后变成：

Search Summary:
发现论文A支持方案一

Python Summary:
代码测试通过32项，失败1项

Browser Summary:
官方文档指出API已废弃

整个上下文长度可能从数万 Token 压缩到几百 Token，但保留了完成后续推理真正需要的信息。

CompactionRL 并不是传统意义上的文本摘要，因为普通摘要模型通常优化 Rouge、BLEU 等文本指标，而 CompactionRL 优化的是最终 Agent Reward，即如果压缩后的 Context 仍然能够完成任务，那么压缩就是成功的，否则压缩失败。因此训练目标不是"压缩得像原文"，而是"压缩后仍然能够完成 Agent Decision"。训练过程可以表示为：

trajectory = rollout(prompt)

compact_context = compactor(
    trajectory
)

reward = run_agent(
    compact_context
)

loss = rl_loss(reward)

这里真正参与优化的是：

Compactor Policy

而不是普通 Summarizer。

在训练过程中，Agent 会不断学习哪些信息值得保留。例如一次 Browser Tool 返回：

2000 Tokens HTML

模型最终真正使用的信息可能只有：

API Version = v3

Authentication = OAuth2

Endpoint = /chat

因此 Compaction Model 会逐渐学习：

important_information = extract(
    tool_return
)

compact_context = summarize(
    important_information
)

随后继续执行下一轮 Rollout：

context = (
    compact_context +
    new_observation
)

这样整个 Agent 可以持续工作，而 Context 长度始终保持在一个稳定范围。

CompactionRL 的训练仍然属于强化学习，因此压缩是否成功不是通过人工标签决定，而是通过最终 Reward 反馈。例如：

reward = solve_task(
    compact_context
)

if reward == SUCCESS:

    reinforce(compactor)

else:

    penalize(compactor)

如果压缩后 Agent 依然成功完成 SWE-bench Bug 修复，那么说明压缩保留了足够的信息；如果压缩导致 Agent 无法继续推理，那么 Reward 会下降，Compactor Policy 会自动调整压缩策略。

整个训练流程可以表示为：

trajectory = rollout(policy)

compact_state = compact(
    trajectory
)

next_trajectory = continue_rollout(
    compact_state
)

reward = compute_reward(
    next_trajectory
)

loss = policy_gradient(
    reward
)

loss.backward()

optimizer.step()

CompactionRL 与普通 Memory Summarization 最大的区别在于它不是离线摘要，而是 RL Environment 的一部分。对于 Agent 来说：

State

↓

Compaction

↓

New State

↓

Action

↓

Environment

↓

Reward

其中 Compaction 本身就是 Environment Transition 的组成部分，因此 Compaction Strategy 也需要参与策略优化。

GLM-5.2 在 Agentic RL 中通常会把 Compaction 插入到超长轨迹中，当 Context 超过一定长度时，不再简单截断，而是主动执行 Compaction。例如：

if len(context) > threshold:

    context = compactor(
        context
    )

之后继续生成：

response = policy.generate(
    context
)

这样可以支持远超过模型原始 Context Window 的长链路任务。

由于 Agent 轨迹通常包含大量 Tool Return，因此 Compaction 的对象不仅包括自然语言，还包括代码输出、终端日志、网页内容、搜索结果等。例如：

Tool Return

↓

Code Output

↓

Execution Log

↓

Search Result

↓

Browser HTML

↓

Compaction

↓

Structured Memory

压缩后的内容往往采用结构化表示，例如：

memory = {

    "tool":"browser",

    "key_findings":[

        "...",

        "..."

    ],

    "status":"finished"

}

这种结构比原始网页更容易被后续 Planning 使用，也能够显著减少 Token 数量。

从强化学习角度来看，CompactionRL 实际上改变了 Agent 的状态空间。传统 Agent 的状态可以表示为：

State = Entire Context

随着 Rollout 增长：

State Size

1000

↓

5000

↓

10000

↓

30000 Tokens

而 CompactionRL 则变成：

State

↓

Compaction

↓

Compact State

↓

Action

即：

$s_t \rightarrow C(s_t) \rightarrow a_t$

其中：

$C(\cdot)$ 表示可学习的 Compaction Function，它不是固定算法，而是在 RL 中不断优化，使压缩后的状态能够最大程度保持未来决策所需的信息。

整个 GLM-5.2 Agentic RL Pipeline 可以表示为：Prompt → Planner → Tool Use → Observation → Context Growth → Compaction → Compact Memory → Continue Planning → Reward → Policy Update。CompactionRL 的核心贡献并不是提出一种新的摘要算法，而是把上下文压缩（Context Compaction）正式纳入强化学习优化目标，使 Agent 学习"保留什么信息比保留多少信息更重要"，最终让模型能够在有限 Context Window 内持续执行长时间、多工具、多阶段的复杂 Agent 任务，而不会因为上下文无限增长导致推理能力下降或训练成本失控。这种设计使 Compaction 不再只是工程优化，而成为 Agent Policy 本身的一部分，也是 GLM-5.2 长链路 Agentic RL 能够稳定训练的重要组成模块。

GLM-5.2 在 Agentic RL 后训练中的 SAO方法

GLM-5.2 在 Agentic RL 后训练阶段提出的 SAO（Single-rollout Asynchronous Optimization）本质上是一种专门针对长链路 Agent 设计的异步强化学习算法，它解决的问题并不是传统语言模型的 Next Token Prediction，而是 Agent 在真实环境中执行复杂任务时训练吞吐量低、同步等待严重、Off-policy 误差不断累积以及长轨迹梯度不稳定等问题。传统 PPO、GRPO 等 RL 方法基本都是同步训练（Synchronous RL），整个 Batch 的所有 Rollout 必须全部完成之后才能统一计算 Reward、Advantage 和 Policy Gradient，因此训练流程通常表现为：Prompt Batch → Parallel Rollout → Wait All Finish → Reward → Advantage → Policy Update → Next Batch。这种方式在数学推理等短链路任务中问题不大，因为几十个 Token 很快即可完成，但是在 Agent 场景中，一条轨迹往往需要经历 Planning、Tool Selection、Tool Execution、Environment Feedback、Reflection、Retry 等多个阶段，不同任务耗时差异极大，例如一个简单搜索任务可能几秒结束，而一个 SWE-bench Bug 修复任务可能执行数百次 Tool Call 持续十几分钟，如果采用同步训练，那么最快结束的 GPU Worker 必须一直等待最慢的 Rollout 才能开始下一轮优化，大量 GPU 长时间空闲，整个 RL Pipeline 被长尾任务拖慢。GLM-5.2 因此采用 Rollout Worker 与 Trainer 解耦的异步架构，整个系统更接近生产环境中的消息队列而不是同步 Barrier，其执行流程可以表示为：Prompt Queue → Rollout Worker → Trajectory Buffer → Trainer → Parameter Server → Rollout Worker，Rollout Worker 持续生成轨迹，Trainer 持续消费轨迹并更新参数，两者完全并行，不需要等待整个 Batch 完成，因此 GPU 利用率能够长期保持较高水平。对应的系统结构可以简单表示为：

from queue import Queue

trajectory_queue = Queue()

def rollout_worker(policy):
    while True:
        prompt = sample_prompt()
        trajectory = rollout(policy, prompt)
        trajectory_queue.put(trajectory)

def trainer(policy):
    while True:
        traj = trajectory_queue.get()
        loss = compute_loss(policy, traj)
        loss.backward()
        optimizer.step()

但是异步训练会立即带来一个新的问题，即 Rollout 与 Trainer 使用的策略版本已经不同，Rollout Worker 在生成轨迹时可能仍然使用的是 Policy Version100，而 Trainer 此时已经更新到了 Version110，这意味着采样轨迹越来越偏离当前策略，即产生越来越严重的 Off-policy 问题。如果继续采用 GRPO（Group Relative Policy Optimization）的方法，一个 Prompt 通常需要同时采样多个回答，再进行组内排序计算 Relative Advantage，例如：

responses = [
    rollout(prompt),
    rollout(prompt),
    rollout(prompt),
    rollout(prompt)
]

advantages = compute_group_advantage(responses)

loss = grpo_loss(responses, advantages)

GRPO 默认假设这一组 Rollout 来自同一个策略版本，因此组内比较具有一致性，但是异步训练环境下四条轨迹可能来自四个不同版本：

Response A → Policy v100
Response B → Policy v103
Response C → Policy v108
Response D → Policy v110

此时再进行组内排序已经没有理论保证，因此 SAO 完全放弃了 Group Sampling，而采用 Single Rollout Sampling，每个 Prompt 只生成一条轨迹，每条轨迹独立计算 Reward、独立计算 Advantage、独立更新 Policy，不再等待其它 Rollout，因此训练流程变成：Prompt → Single Rollout → Reward → Advantage → Policy Update，这种方式可以立即消费新数据，非常适合异步训练架构。

trajectory = rollout(policy, prompt)

reward = reward_model(trajectory)

advantage = compute_advantage(
    trajectory,
    reward
)

loss = policy_loss(
    trajectory,
    advantage
)

loss.backward()
optimizer.step()

由于没有了组内比较，SAO 引入了独立 Value Function 来估计状态价值，从而计算 Advantage，而不是依赖同组回答排序。其思想与 Actor-Critic 更接近，对于每一个状态，Value Model 学习未来能够获得的累计 Reward，然后利用 Reward 与 Value 的差值估计当前策略到底比预期好还是差。

states = trajectory.states

returns = compute_returns(
    trajectory.rewards
)

values = value_model(states)

advantages = returns - values

然后再利用 Advantage 更新 Policy。

policy_loss = (
    log_probs *
    advantages.detach()
).mean()

Agent 的轨迹通常非常长，一条轨迹可能包含几千甚至几万个 Token，如果直接优化，很容易因为某几个 Token Reward 很大而导致梯度爆炸，因此 SAO 在 PPO 的基础上进一步提出 Token-level Double-side Clipping，不仅限制整个轨迹的更新幅度，而且限制每一个生成 Token 的 Importance Ratio，防止局部梯度过大。

传统 PPO：

ratio = (
    new_logprob -
    old_logprob
).exp()

loss = torch.min(
    ratio * advantage,
    torch.clamp(
        ratio,
        1 - eps,
        1 + eps
    ) * advantage
)

SAO 更接近：

token_ratio = torch.exp(
    new_token_logprob -
    old_token_logprob
)

token_ratio = torch.clamp(
    token_ratio,
    lower_bound,
    upper_bound
)

loss = (
    token_ratio *
    token_advantage
).mean()

这样每一个 Token 的更新都会受到限制，即使轨迹非常长，也不会因为少数几个 Token 导致整个 Policy 崩溃。

SAO 还有一个非常重要的设计，就是 Agent RL 并不会优化 Tool Return，而只优化模型自己的 Decision Token。真实 Agent 的执行过程通常表现为：User Request → Planner → Tool Selection → Tool Call → Observation → Reflection → Retry → Final Answer。其中 Browser、Python、Search、SQL 等工具返回的 Observation 都属于环境反馈，并不是模型生成的 Token，因此训练时需要 Mask 掉这些 Tool Return，只训练模型自己的输出，例如：

trajectory = [

    UserToken(...),

    AssistantToken(...),

    ToolCall(...),

    ToolReturn(...),

    AssistantToken(...),

    ToolReturn(...),

    AssistantToken(...)
]

训练 Mask：

loss_mask = [

    1,

    1,

    1,

    0,

    1,

    0,

    1
]

最终 Loss：

loss = (
    token_loss *
    loss_mask
).sum() / loss_mask.sum()

这样模型学习的是如何规划任务、什么时候调用工具、调用哪个工具、如何根据 Observation 做下一步决策，而不是去拟合搜索引擎或者 Python Interpreter 返回的数据，否则模型会把环境反馈误认为自己生成的语言，最终降低泛化能力。

整个 SAO 更接近标准强化学习环境而不是传统语言建模，其训练循环可以表示为：

state = env.reset()

while not done:

    action = policy(state)

    next_state, reward, done = env.step(action)

    buffer.append(
        state,
        action,
        reward
    )

    state = next_state

policy.optimize(buffer)

其中 Action 不再只是生成一个 Token，而可能是 Planner Decision、Tool Selection、Tool Arguments、Reflection 或 Final Answer；Environment 不再只是文本，而是真实 Browser、Python、Shell、Search Engine、Git Repository 等执行环境，因此整个训练实际上已经变成了 Decision Making 而不是 Language Modeling。

SAO 最大的价值并不仅仅是提出了一个新的 Loss，而是重新设计了长链路 Agent 的强化学习范式，它将传统同步 RL 转变为持续异步优化，将 Group Sampling 转变为 Single Rollout Optimization，将等待整个 Batch 更新变成轨迹实时更新，同时结合 Token-level Clipping、Value Function、Tool Return Mask 等机制，使 Agent 可以稳定训练数千步以上，并能够支持真实生产环境中的持续在线学习。整个 Agentic RL Pipeline 可以总结为：Prompt → Planner → Tool Use → Environment Feedback → Reflection → Single Rollout → Reward → Value Estimate → Advantage → Token-level Clipping → Asynchronous Policy Update → New Policy，这也是 GLM-5.2 Agentic RL 相比传统 PPO、GRPO 最大的工程创新之一。

GLM-5.2 的 IndexCache 和 IndexShare

GLM-5.2 里的 IndexCache 和 IndexShare是一套围绕长上下文推理效率与多轮/多任务复用设计的 KV cache + attention indexing 体系升级方案。它解决的是一个工程化的问题：在长对话、agent trajectory、多轮工具调用场景下，如何避免重复计算 attention，同时又能保持上下文一致性与可控更新。

先从 Transformer 推理的基本瓶颈说起。在标准自回归生成中（Vaswani et al., https://arxiv.org/abs/1706.03762 ），每一步生成 token 都需要对历史 KV cache 做 attention，因此随着 context 变长，推理成本线性增长。但在 agent 或 long-context system 中，一个更严重的问题不是“长”，而是“重复长”：很多上下文片段在不同 query、不同 step 之间是重复使用的，例如 system prompt、工具说明、长期 memory、历史 trajectory、甚至中间 reasoning chain。如果每次都重新参与 attention 计算，本质上是在做重复的 KV 读取与重复的 attention scoring，这会造成大量冗余计算。

IndexCache 是在传统 KV cache（按 token 顺序存储 K/V）的基础上，引入一个“可寻址索引层”，把 KV 从“线性序列存储”变成“可按语义/结构访问的缓存单元”。也就是说，它不仅存 K/V，还存一个 index structure，用来标记“这一段 KV 属于哪个语义块 / 哪个 session / 哪个 memory region”。可以把它理解成：

普通 KV cache:
    token1 -> K1,V1
    token2 -> K2,V2
    ...

IndexCache:
    block_A (system prompt)
    block_B (tool schema)
    block_C (conversation turn 1)
    block_D (agent trajectory step k)

在 attention 时，不再是简单地 scan 全部 KV，而是先通过 index 决定“哪些 block 参与 attention”，再在 block 内部做精细计算。这本质上是一个 hierarchical memory addressing mechanism，类似把 transformer 从 flat memory 结构升级为 block-structured memory。

更关键的是 IndexCache 的作用不只是加速，而是改变 attention 的访问模式。在长 agent trajectory 中，不同 token 的重要性是高度结构化的，例如当前 step 主要依赖最近 reasoning + tool output，而不是全部历史 token。IndexCache 等价于在 KV cache 外部增加了一层“结构化过滤器”，使 attention 从：

full scan over all tokens

变成：

indexed retrieval over relevant blocks

因此它和 DSA、是互补的：DSA解决“算哪些token”，IndexCache解决“这些token怎么组织与复用”。

IndexShare 则是更进一步的系统优化，它解决的是另一个问题：多轮推理 / 多query之间的KV重复计算问题。在 agentic system 中，一个模型通常会经历多个 query 或多个 step rollout，例如：

user question
agent planning
tool call reasoning
reflection step
retry step

这些过程中，大量 context 是重复的，比如 system prompt、tools description、memory state 等。如果每一步都重新构建 KV cache，本质是浪费计算。

IndexShare 的核心思想是：

不同 inference session / different steps 可以共享同一份 indexed KV memory，而不是重新构建 cache。

也就是说，它把 KV cache 从“session-local”变成“shareable memory object”。

可以用结构化方式理解：

Session A:
    uses IndexCache block_A + block_B + block_C

Session B:
    reuses block_A + block_B
    adds block_D

IndexShare 的关键不是简单 cache reuse，而是 index-level sharing，也就是说共享的不是 raw KV tensor，而是“KV + index mapping”。这意味着不同推理路径可以引用同一个 memory block，但仍然可以进行局部扩展或更新。

从系统视角来看，IndexCache + IndexShare 本质上构成了一个三层 memory architecture：

第一层是 token-level KV cache，负责基础 attention 存储；第二层是 index layer，把 token 聚合成结构化 memory block；第三层是 share layer，使不同 inference trajectory 可以复用同一 memory graph。

如果用更抽象的方式表达，它等价于把 Transformer 推理从：

sequence computation

升级为：

graph-structured memory computation

从 agentic RL 或 long-horizon reasoning 的角度看，这两个机制非常关键，因为 agent 的核心瓶颈不是“生成能力”，而是“上下文管理能力”。在一个长 trajectory 中（planning → tool call → observation → reflection → retry），模型不断在重复访问相同 memory state，如果没有 IndexCache，每一步都会重新 attention 全历史 token，成本极高；如果没有 IndexShare，每个 step 都是孤立 memory，会导致 state fragmentation。

IndexCache 提供的是：

intra-session memory compression

IndexShare 提供的是：

inter-session memory reuse

两者组合起来，本质上是在 Transformer 内部实现一个 lightweight memory system，使模型具备类似数据库 cache + pointer referencing 的能力。

从优化角度来看，这类机制还会改变 attention 的计算复杂度结构。在 full attention 中复杂度是 O(n²)，在 sliding window 或 sparse attention 中是 O(nk)，而在 IndexCache + IndexShare 中，复杂度更接近：

O(block_retrieval + selected_attention)

也就是说复杂度主要取决于“索引命中多少块”，而不是 token 总长度。

所以，GLM-5.2 的 IndexCache 可以理解为“结构化 KV memory system”，它通过对 attention key/value 进行分块索引，使模型能够按语义单元而不是按 token 序列访问历史信息；而 IndexShare 则是在这个结构之上引入跨 session / 跨 trajectory 的共享机制，使 KV memory 从“临时缓存”变成“可复用的持久化认知状态”。两者结合，本质是在 Transformer 内部构建了一个轻量级的 distributed memory system，使长上下文推理从线性扩展问题变成结构化检索问题，这一点在 agentic RL 和 long-horizon reasoning 中非常关键，因为它直接决定了 trajectory 能否在多步推理中保持一致的状态表示。

GLM-5.2的Agentic RL做法

GLM-5.2 在 “Built for Long-Horizon Tasks” 这篇文章里讲的 agentic RL，其实本质不是在提出一个全新的强化学习算法，而是在描述一种“面向长时间、多步骤执行任务的系统级训练范式”。它解决的问题不是传统 LLM 的一次性问答能力，而是让模型在真实或模拟环境中，能够持续执行多个步骤的任务链，比如写代码、调试、调用工具、读取中间结果、再修改策略，并且在整个过程中保持目标一致性不崩掉。所谓 long-horizon tasks，在文章语境里更多指的是“需要几十步甚至上百步交互才能完成的任务”，比如 repo-level coding、复杂 bug 修复、多文件重构、自动化数据分析 pipeline 这类任务，而不是简单的长文本生成。

在这个设定下，GLM-5.2 的 agentic RL 训练方式的核心变化是：不再把模型看成一个“回答问题的函数”，而是看成一个“执行轨迹生成器（trajectory generator）”。也就是说，训练样本不再是 prompt → answer，而是 prompt → agent rollout → trajectory-level reward。所谓 rollout，就是模型在环境中完整跑一遍任务执行过程，这个过程不是一次生成，而是一个循环：模型先根据当前状态做决策，然后可能生成一个 tool call（例如搜索、执行代码、调用 API），环境返回 observation（比如代码输出、错误信息、文件变化），模型再基于新的状态继续下一步，直到任务结束。整个过程形成一个非常长的执行链条，这个链条才是 RL 优化的对象。

从结构上看，可以把这个 agent rollout 理解成一个循环系统，它比普通 LLM 推理复杂得多，因为 state 已经不再只是 prompt + context，而是一个持续更新的“任务状态空间”，里面包含当前代码库状态、工具返回结果、历史决策路径、以及被压缩后的记忆信息。一个简化的执行过程可以写成这样：

state = init_task_environment(task)

trajectory = []

for t in range(MAX_STEPS):

    # policy is not just text generation, but decision + tool-use
    action = policy(state)

    if action.type == "tool_call":
        observation = environment.execute(action)
    else:
        observation = None

    state = update_state(state, action, observation)

    trajectory.append({
        "state": state,
        "action": action,
        "observation": observation
    })

    if check_done(state):
        break

在 GLM-5.2 的 agentic RL 里，关键点不在这个循环本身，而在于这个 trajectory 会被一个“critic”模型整体评估，而不是逐步打分。也就是说 reward 不是 step-level supervision，而是 trajectory-level evaluation。critic 会看整条执行路径是否成功完成任务、是否中途跑偏、是否出现工具滥用或 hacking 行为、以及最终结果是否可验证正确。这个 reward 可以写成一个组合函数：

R(trajectory) =
    task_success
  + execution_consistency
  + tool_correctness
  - deviation_penalty
  - hacking_penalty

然后 RL 优化的对象就是整条 trajectory 的概率分布，而不是单个 token 的概率。也就是说优化目标从 next-token prediction 变成：

$\max_\pi \mathbb{E}_{\tau \sim \pi}[R(\tau)]$

这里的 τ 是完整的 agent 执行轨迹。

在优化方法上，文章强调的一个关键变化是从 group-based optimization（比如 GRPO 或 RLAIF 中常见的 group ranking）转向 critic-based PPO on individual rollouts。也就是说，以前是把多个答案放在一起比较谁更好，现在是对每一条 rollout 单独计算 advantage，然后直接做 PPO 更新。形式上就是：

trajectory = rollout(policy, task)
reward = critic(trajectory)
advantage = reward - baseline

loss = -log_prob(policy, trajectory) * advantage

update(policy, loss)

这种做法的本质意义是：long-horizon 任务里“对比排序”已经不够用了，因为问题不是“哪个答案更好”，而是“整个执行过程是否稳定完成任务”，必须对每一条完整执行链单独建模。

另一个非常关键但容易被忽略的设计是 state compression 和 trajectory compaction。在 long-horizon 任务中，执行链可能非常长，如果把所有历史信息全部塞进 context，会导致计算爆炸并且模型会出现 early goal forgetting。所以 GLM-5.2 会在每一步把历史 trajectory 压缩成一个更高层的 state representation，这个 state 不再是原始 token 序列，而是经过总结的“任务进展状态”，它可能包含当前目标、已经完成的子任务、失败记录以及工具输出的摘要信息。可以表示为：

state_t = compress(
    previous_state,
    action_t,
    observation_t,
    memory_summary
)

这个 compression 本质上是 long-horizon RL 能否成立的关键，否则 policy 无法在几十步后仍然保持稳定决策。

此外，文章还特别强调 agentic RL 中 tool use 的问题，因为在 coding agent 或自动化环境里，模型很容易学会 reward hacking，例如读取隐藏测试、绕过评测逻辑、或者通过不合法 API 获取答案。因此 GLM-5.2 的训练环境中会加入 tool-use constraint 和 anti-hacking filter，对异常行为进行惩罚甚至替换 observation，而不是直接中断 rollout，这一点非常重要，因为如果直接终止 trajectory，会破坏 RL 分布稳定性。形式上可以理解为：

if detect_hacking(action, observation):
    observation = sanitize(observation)
    penalty += hack_penalty

从整体来看，GLM-5.2 的 agentic RL 实际上构建的是一个完整闭环系统：模型在环境中生成 long-horizon trajectory → trajectory 被 critic 评估 → reward 用于 PPO 更新 policy → 同时失败轨迹会被存入 replay buffer 用于后续再训练。这个闭环的关键不在模型结构，而在“trajectory 是一等公民”，也就是说优化单位已经不是 token，也不是 answer，而是完整执行过程。

如果把它抽象成一个系统级 pipeline，可以写成：

Agent Rollout (tool + reasoning + memory)
        ↓
Trajectory Logging
        ↓
Critic / Reward Model Evaluation
        ↓
Advantage Computation
        ↓
PPO / RL Update
        ↓
Replay / Failure Mining
        ↓
Next Iteration

最终 GLM-5.2 在这篇文章里想表达的核心其实非常明确：所谓 built for long-horizon tasks，不是指模型“能处理更长输入”，而是指整个训练系统已经转向一个新的范式——用强化学习去优化一个“持续执行任务的智能体轨迹系统”，这个系统必须同时具备规划能力、工具使用能力、记忆压缩能力和自我纠错能力，并且这些能力不是靠 prompt engineering 实现，而是通过 trajectory-level reinforcement learning 在系统层面被统一优化出来的。

GLM-5.2 的注意力机制 DSA

DSA（Deepseek Sparse Attention来源于deepseek3.2）本质是在解决一个非常典型的长上下文问题：当 context window 变得很长时，标准 full attention 的计算复杂度 O(n²) 不再可接受，同时绝大多数 token 之间的注意力实际上是“冗余的”，并不需要全连接建模。因此 DSA 的核心思想不是发明一种新的 attention 公式，而是改变 attention 的“连接方式”，也就是从 dense attention 转向 data-dependent sparse attention，让模型只在“有意义的 token 子图”上做注意力计算。

从标准 Transformer（Vaswani et al., https://arxiv.org/abs/1706.03762 ）来看，attention 的本质是对所有 token pair 计算相关性：softmax(QKᵀ)V，这种结构的隐含假设是所有 token 都可能互相影响。但在长链路语言建模或者 agentic reasoning 场景中，这个假设是过强的，因为很多 token 之间在语义上是天然弱相关的，例如在一个多 step reasoning trajectory 中，早期 observation token 对后期 tool output 可能只有局部影响，而不是全局影响。因此 DSA 的第一步就是“结构稀疏化”：不再计算全连接 attention，而是只计算一个子集邻接关系。

DSA 的关键不是固定 sparse pattern（如 sliding window attention 或 block attention），而是 dynamic sparse pattern，也就是注意力连接关系是“数据驱动生成的”。在 GLM-5.2 模型中，这种动态性体现在：模型会根据 query token 或当前 hidden state，动态选择一部分 key tokens 参与 attention，例如通过 routing、top-k selection 或 learned gating function 来决定 attention graph。可以理解为：

full_attention:
    each token attends to all previous tokens

DSA:
    each token attends to a subset of tokens selected by relevance scoring

如果写成更形式化一点，可以表示为：

$A_i = \text{softmax}(Q_i K_{S(i)}^T) V_{S(i)}$

其中 S(i) 是一个动态子集，不再是 {1..i}，而是由一个 selection function g(i, context) 决定，这个函数可以是 learnable router，也可以是基于 similarity / clustering / memory retrieval 的机制。

从系统角度来看，DSA 在 GLM-5.2 中的作用不是单纯提升效率，而是同时解决三个问题：第一是长上下文计算成本问题，第二是信息干扰问题（irrelevant tokens introduce noise），第三是 implicit memory selection 问题。在 full attention 下，所有历史 token 都会被同等考虑，但在长文档或 agent trajectory 中，大量 token 实际上是“语义噪声”，例如 tool observation log、重复 reasoning step、或者早期无关 context，这些 token 会导致 attention entropy 上升，从而降低模型对关键路径的聚焦能力。DSA 的作用就是在 attention 层面引入一个“信息路由机制”，类似在 transformer 内部做 retrieval。

如果从 agentic RL 或 trajectory modeling 的角度看，DSA 的意义会更明显。在 agent trajectory 中，信息结构通常是稀疏依赖的：当前 action 主要依赖最近的 reasoning chain + 少量关键历史 observation，而不是全历史 token。因此 full attention 实际上是在做大量无效计算，而 DSA 相当于在 attention 层引入“trajectory credit assignment bias”，让模型更倾向于关注与当前决策相关的历史节点。这一点和 RL 里的 credit assignment 是高度同构的，只不过 RL是在优化 reward分配，而 DSA是在优化 attention分配。

在一些实现范式中，DSA通常可以拆成三步：第一步是 relevance scoring，即对历史 token 做重要性估计，这个可以通过 QK 相似度、learned scoring network 或 memory gate 来实现；第二步是 top-k / threshold selection，从所有 token 中筛选一个子集 S(i)；第三步是在这个子集上做标准 attention。可以写成伪代码：

for token i:
    scores = similarity(q_i, k_1..k_n)

    selected = topk(scores, k)

    attn = softmax(scores[selected]) @ v[selected]

从更深层的结构来看，DSA是在把 Transformer 从“fully connected graph model”变成“learned sparse dynamic graph model”。也就是说 attention 不再是固定计算图，而是一个随输入变化的图结构学习问题。这一点和你做的 graph agent / lang2struct 其实是高度一致的：都是在学习一个 latent computation graph，只不过 DSA 是在 token level 做 graph construction。

在 long-context model 研究中，这类 sparse/dynamic attention 方向还有一系列相关工作，例如 Longformer（https://arxiv.org/abs/2004.05150 ）、BigBird（https://arxiv.org/abs/2007.14062 ）、以及基于 routing 的 MoE-attention hybrid 结构。DSA相比这些方法的关键区别在于：它不是固定稀疏模式（fixed sparsity pattern），而是输入依赖的动态稀疏结构，因此更接近“learned retrieval inside attention”。

从训练角度来看，DSA还带来一个重要变化：attention 不再是纯 differentiable dense operator，而是包含 discrete selection / soft routing，因此训练时通常需要用 straight-through estimation、Gumbel-Softmax 或 soft relaxation 来保持可导性。这会影响模型的 optimization dynamics，使得模型更偏向于“结构学习 + 表示学习”的混合优化，而不仅仅是参数拟合。

GLM-5.2 中的 DSA 可以理解为：一种将标准 Transformer 的全连接注意力机制替换为“基于输入内容动态生成稀疏计算图”的 attention 机制，它通过对 token 进行动态筛选，使模型在长上下文下只关注语义相关子结构，从而同时提升计算效率与信息聚焦能力，本质上是 attention 层面的 learned retrieval + dynamic graph construction，其思想与 long-horizon agent 中的 memory selection 和 trajectory credit assignment 在结构上是同构的。

GPT系列模型技术解析

GPT-5 系列的推理架构路线：从 Scaling Transformer 到 Reasoning System，再到 Agent Foundation Model

GPT-5 系列的核心变化并不是简单增加 Transformer 参数规模，而是 OpenAI 推理架构路线的一次明显转变：从过去 GPT-4 时代主要依靠预训练模型能力，发展到 o1/o3 系列代表的“推理模型（Reasoning Model）”，再进一步融合成 GPT-5 的统一智能系统。根据 OpenAI 公开的 GPT-5 System Card，GPT-5 并不是一个单独模型，而是一个由快速模型、深度推理模型以及实时路由系统组成的统一系统。系统会根据任务复杂度、用户意图、是否需要工具等因素动态决定使用哪一种推理路径。

传统 GPT 系列（GPT-3、GPT-4、GPT-4o）的核心范式可以理解为：

User Prompt → Transformer → Next Token Prediction → Answer

模型本质目标是最大化：

$P(x_t|x_1,x_2,...,x_{t-1})$

也就是根据已有上下文预测下一个 token。通过扩大参数规模、增加训练数据、提升训练方法，模型获得越来越强的知识和语言能力。但是这种架构存在一个天然限制：模型更擅长“快速生成”，而不是“长时间思考”。面对复杂数学证明、复杂代码工程、科学推理问题时，模型容易出现一步错误导致后续全部错误的问题。

例如：

用户：
设计一个复杂系统架构，并分析性能瓶颈。

普通LLM：

理解问题
↓
直接生成答案
↓
结束

这种模式的问题是模型没有真正进行多轮验证。

因此 OpenAI 在 o1 系列开始探索新的路线，也就是 Reasoning Model。o1、o3、o4-mini 等模型的核心变化，是将推理过程作为模型训练和推理阶段的重要部分。OpenAI 公开说明 o3 和 o4-mini 使用大规模强化学习训练推理能力，并且能够在推理过程中调用工具，例如 Python、网页搜索、文件分析等。

推理模型的基本思想可以表示为：

Problem
↓
Generate Reasoning Process
↓
Evaluate Intermediate Result
↓
Continue Search
↓
Final Answer

数学上，它不再只优化：

$P(answer|question)$

而是优化：

$P(answer, reasoning\ trajectory|question)$

也就是让模型学习一个隐藏的搜索过程。

传统模型：

answer = model(prompt)

推理模型：

state = prompt

while not solved:

    action = model(state)

    state = update(
        state,
        action
    )

answer = state.final()

这里的核心变化是模型从一个“函数”变成一个“搜索过程”。

GPT-5 的架构路线进一步把 Reasoning Model 和普通 Chat Model 合并成统一系统。公开资料显示，GPT-5 包含：

gpt-5-main负责快速、高吞吐量任务
+
gpt-5-thinking负责复杂推理任务
+
Router负责动态选择模型

整体结构更接近：

User Request
↓
Intent Understanding
↓
Real-Time Router
↓
Fast Model / Reasoning Model
↓
Tool Usage
↓
Verification
↓
Final Response

其中 Router 是 GPT-5 系列非常重要的变化。过去用户需要自己选择：

GPT-4o或者o3

但是 GPT-5 希望系统自动判断：

简单问题：

"What is Python?"
↓
Fast Model

复杂问题：

"Design a distributed database system"
↓
Reasoning Model

需要工具：

"Analyze this PDF and calculate data"
↓
Reasoning Model + Tools

因此 GPT-5 的核心不是单模型，而是一个模型调度系统。

可以抽象为：

def gpt5_system(user_input):

    complexity = router.predict(
        user_input
    )

    if complexity == "simple":

        model = gpt5_main

    elif complexity == "hard":

        model = gpt5_thinking

    result = model.solve(
        user_input
    )

    return result

GPT-5 系列推理路线中的第二个关键变化，是从 Chain-of-Thought 走向 Test-Time Compute（测试时计算）。

传统 Transformer：

输入一次
↓
生成一次
↓
结束

推理模型：

输入
↓
生成多个可能路径
↓
评估路径
↓
选择更优结果
↓
输出

类似搜索算法：

solutions = []

for i in range(N):

    reasoning = model.generate(
        problem
    )

    score = evaluator(
        reasoning
    )

    solutions.append(
        (reasoning, score)
    )


best = max(
    solutions,
    key=lambda x:x[1]
)

这里增加的不是参数，而是推理时间。因此：模型能力 ≈ 参数规模 × 推理计算量对于复杂任务：增加思考时间可能比增加参数更加有效。第三个变化是 Tool-Augmented Reasoning（工具增强推理）。

GPT-5 系列延续 o 系列路线，不再认为模型必须把所有能力压缩在参数里面，而是允许模型在推理过程中调用外部工具。OpenAI 公开表示 o3/o4-mini 可以在推理过程中使用网页浏览、Python、文件分析、图像处理等工具。

Question

↓

Reasoning

↓

Need Information?

↓

Call Tool

↓

Observe Result

↓

Continue Reasoning

↓

Answer

这已经不是普通语言模型，而是一个能够和环境交互的推理系统。第四个变化是从单步推理到长链路 Agent Reasoning。

GPT-4 时代：

Input → Output

GPT-5 时代：

Goal

↓

Planning

↓

Reasoning

↓

Tool Selection

↓

Execution

↓

Observation

↓

Correction

↓

Final Result

这也是为什么 GPT-5 系列和 Harness Engineering、Agent Runtime 方向高度相关。

一个复杂任务可以表示为： $\tau=(s_0,a_0,s_1,a_1,...,s_T)$

其中：

s：环境状态。

a：Agent 动作。

例如 Coding Agent：

{
"task":"Fix bug",

"steps":[

{
"action":"search_code"
},

{
"action":"read_file"
},

{
"action":"modify_code"
},

{
"action":"run_test"
}

]
}

模型优化目标从：生成一句正确答案。

变成：完成整个任务轨迹。

第五个变化是 Reinforcement Learning for Reasoning（推理强化学习）。o 系列模型公开强调通过大规模强化学习训练推理能力。

传统 SFT：

Question

↓

Correct Answer

训练目标： $Loss=-logP(y|x)$

但是复杂推理需要：

Attempt

↓

Feedback

↓

Improve

↓

Retry

因此更接近：

$J(\theta)=E_{\tau\sim\pi_\theta} [\sum r_t]$

其中：

r_t表示每一步行为奖励。

例如数学：

错误：

Step 1:
选择错误公式

reward=-1

正确：

Step 1:
识别问题类型

reward=0.5


Step 2:
正确推导

reward=1

模型学习的是解决问题的方法，而不是答案。从整体路线看，GPT-5 系列实际上经历了三个阶段。

第一阶段：

GPT-3/GPT-4：

Scale Model

↓

Knowledge + Language Ability

核心：

扩大参数和数据。

第二阶段：

o1/o3：

Model

+

Reasoning Search

+

RL Training

核心：让模型学会思考。

第三阶段：

GPT-5：

Reasoning Model + Fast Model+Router + Tools + Agent Runtime

让模型成为一个能够自主选择计算方式、调用工具、验证结果的智能系统。因此 GPT-5 系列真正的架构路线可以总结为：

GPT-4

↓

Large Language Model

↓

o1/o3

↓

Reasoning Model

↓

GPT-5

↓

Unified Reasoning System

↓

Future Agent Foundation Model

目前 OpenAI 并没有公开 GPT-5 内部完整 Transformer 结构，例如具体层数、参数规模、Attention 改进、是否 MoE 等，因此不能确认具体网络结构。但是从公开 System Card 可以确认，GPT-5 的核心架构方向已经从“更大的语言模型”转向“统一推理系统”：通过 Router 调度不同能力模型，通过强化学习提升复杂推理，通过工具调用扩展能力，通过 Agent Runtime 完成长链路任务。

Deepseek系列模型技术解析

DeepSeek Harness 技术解析：为什么 Harness 正在成为 Agent 的核心基础设施

DeepSeek 在 2026 年 8 月 13 日公开了 DeepSeek Harness Developer Previewhttps://github.com/deepseek-ai/deepseek-harness，并采用 MIT License 开源，其核心定位并不是再做一个“调用大模型的 Agent SDK”，而是把 Model 之上的整个 Agent Runtime 拆成可组合、可替换的插件系统，官方公开信息里最值得关注的设计理念就是 Everything is a Plugin，也就是 Model、Tool、Skill、Session、Sandbox、Filesystem、Loop、Orchestration、UI 等都不应该被写死在一个巨大的 Agent 类里面，而应该成为可以动态组合的 Plugin，这实际上解决的是当前 Claude Code、Codex、OpenCode 这类 Coding Agent 最核心的工程问题：模型本身只是产生下一步 Action 的 Policy，真正决定 Agent 能不能长期稳定工作的其实是 Harness，也就是 Model + Tools + State + Memory + Loop + Sandbox + Permission + Orchestration + UI，因此 DeepSeek Harness 更准确地说是在做一个 Agent Operating Runtime / Agent Harness Framework，而不是单纯的 Agent Application；公开报道显示其开发预览基于 Cordis 元框架，并将 Model、Tool、Skill、Session、Sandbox、Filesystem、Loop、Orchestration、UI 全部放进 Plugin 边界，这个架构最大的价值是让 Agent 的核心 Loop 和外围能力解耦，后续可以替换模型、工具、Memory、Sandbox 甚至整个 UI，而不需要重写 Agent Runtime。 (Pandaily)

# 传统Agent容易把所有逻辑写死在一个Runtime里
class Agent:

    def __init__(self, model, tools):
        self.model = model
        self.tools = tools
        self.memory = Memory()
        self.sandbox = Sandbox()

    def run(self, task):
        # 一个巨大的Agent Loop
        while True:
            response = self.model.generate( task, self.memory )
            if response.tool_call:
                result = self.tools.execute( response.tool_call)
                self.memory.add(result)
            else:
                return response

DeepSeek Harness 的核心思路则是把上面的“大 Agent 类”拆成多个 Plugin，例如 Model Plugin 负责模型调用，Tool Plugin 负责工具注册和执行，Session Plugin 管理会话状态，Memory Plugin 管理上下文和持久化记忆，Filesystem Plugin 管理文件系统，Sandbox Plugin 提供隔离执行环境，Loop Plugin 管理 Agent 循环，Orchestrator Plugin 负责多 Agent 或 Subagent 协调，而 UI Plugin 负责终端或其他交互界面，这样 Agent Runtime 本身只需要负责 Plugin Lifecycle + Event Dispatch + State Coordination，而不需要知道每个具体能力怎么实现，这和你之前做 AgentRuntime、AgentState、run_tool() 统一 Tool Envelope 的设计思路非常接近，只不过 Harness 把这种解耦进一步提升到了整个 Agent Runtime 层面。

# Harness式架构：能力全部通过Plugin注册
class Harness:
    def __init__(self):
        self.plugins = {}
    def register(self, name, plugin):
        # Plugin成为Runtime中的可替换能力
        self.plugins[name] = plugin
    def get(self, name):
        return self.plugins[name]


# 注册不同能力
harness.register("model", ModelPlugin())
harness.register("tools", ToolPlugin())
harness.register("memory", MemoryPlugin())
harness.register("sandbox", SandboxPlugin())
harness.register("filesystem", FilesystemPlugin())
harness.register("loop", AgentLoopPlugin())

这里最重要的不是“用了 Plugin”这三个字，而是 Plugin Boundary 本身成为 Agent 的架构边界，因为 Agent 最大的问题之一就是权限、状态和工具之间容易互相污染，例如传统实现可能把数据库权限写在 Prompt 中，让模型自己遵守“只能读数据库”，但真正可靠的 Agent Runtime 应该在 Tool / Permission Layer 直接限制模型能够调用什么工具，因此 Plugin 化以后，一个 Agent 可以拥有 filesystem.read 但没有 filesystem.write，另一个 Agent 可以拥有 database.query 但没有 database.update，这种限制属于 Runtime Capability，而不是 Prompt Instruction，这对于生产 Agent 的安全性非常重要。

# 不应该只依赖Prompt告诉模型“不要写数据库”
agent = Agent()

# Runtime直接决定Agent拥有哪些Capability
agent.register_tool( "database.query",DatabaseQueryTool())

# 不注册database.update
# 模型即使生成database.update，
# Runtime也无法执行这个不存在的Capability

Harness 最核心的运行逻辑仍然是 Agent Loop，但和简单的 while True: model → tool → model 不同，一个成熟 Harness 需要把一次 Agent Execution 看成一个状态机，也就是当前 State 包含 messages、tool results、working directory、files、session、permissions、subagents、pending actions、budget、tokens、time 等信息，Model 根据当前 State 生成 Action，Runtime 判断 Action 是否允许执行，如果是 Tool Call 就交给 Tool Plugin，如果是 Subagent Action 就交给 Orchestrator，如果是 File Action 就交给 Filesystem，如果是 Terminal Command 就交给 Sandbox，执行结果重新写入 State，然后再次进入 Model，这实际上就是 Policy + Environment + Runtime State 的 Agent 化版本。

# Harness核心Agent Loop
def run(task):
    state = SessionState(task)
    while not state.finished:
        # Model根据当前完整State产生下一步Action
        action = model.generate( state.to_context() )
        # Runtime负责决定Action能否执行
        if not permission.allow(action):
            state.add_error("Permission denied")
            continue
        # Tool / Sandbox / Filesystem等Plugin执行Action
        result = dispatcher.execute(action)
        # Observation重新写回State
        state.add_observation(result)
        # 判断是否应该继续执行
        if loop.should_stop(state):
            state.finished = True
    return state

这种设计对 AgentRL 也非常重要，因为 AgentRL 训练的不是一个静态 Chat Completion，而是一个 Policy 在 Environment 中不断产生 Action 的过程，如果 Harness 把 State → Action → Observation → State 这个循环标准化，那么训练和推理就可以共享同一套 Agent Runtime，训练阶段可以通过 Harness 生成 Rollout，Verifier 根据 Environment State 判断 Reward，RL Trainer 根据 trajectory 更新 Policy，部署阶段则继续使用同一个 Harness 执行真实任务，这样可以显著降低你之前一直关注的 Agent RL 训推不一致问题，因为训练时使用的 Tool Schema、Tool Result、State Representation、Permission、Error Handling 和部署时可以保持一致。

# RL训练阶段也可以复用Harness Runtime
def rollout(model, task):
    harness = build_harness(
        model=model,
        tools=tools,
        sandbox=sandbox,
        memory=memory
    )
    # 生成真实Agent Trajectory
    trajectory = harness.run(task)
    # Environment / Verifier提供Reward
    reward = verifier.score( trajectory  )
    return trajectory, reward

Harness 的另一个核心价值是 Session / State 管理，因为长链路 Agent 最大的问题不是模型不会生成 Token，而是上下文不断增长以后，模型不知道哪些信息已经完成、哪些信息仍然有效、哪些 Tool Result 已经过期，因此 Harness 应该把 Conversation History 和 Runtime State 区分开来，例如 messages 只是模型可见上下文，而 session_state 保存任务状态、文件状态、工具状态、子 Agent 状态和权限状态，这样即使进行 Compaction，也不应该简单地删除所有历史信息，而应该把历史压缩成结构化 State。

# Conversation History
messages = [
    {"role": "user", "content": "..."},
    {"role": "assistant", "content": "..."},
    {"role": "tool", "content": "..."}
]

# Runtime State独立保存关键事实
state = {
    "task": "修复项目Bug",
    "working_directory": "/workspace/project",
    "modified_files": [
        "src/main.py"
    ],
    "tests": {
        "passed": 8,
        "failed": 1
    },
    "current_goal": "修复main.py中的测试失败"
}

这也是 Harness 和普通 Chatbot Framework 的一个本质区别：Chatbot 的核心对象通常是 Message，Agent 的核心对象应该是 State，因为 Agent 要执行几十甚至几百个 Action，而每一步都可能改变 Environment，所以真正需要持久化的是 State Transition，而不是简单的聊天记录，这一点也直接关系到 Agent Memory、Context Compaction 和 Long-Horizon Agent。

# Agent真正关心的是State Transition
state_t = {
    "files": files_t,
    "tools": tools_t,
    "task": task_t,
    "observations": observations_t
}

action = policy(state_t)

state_t1 = environment.step(action)

# Agent实际上学习的是：
# State_t -> Action_t -> State_t+1

Harness 的 Plugin 化还天然适合 Subagent / Multi-Agent Orchestration，因为一个主 Agent 不一定需要自己完成所有事情，例如 Coding Agent 可以创建 planner、coder、tester、reviewer 等 Subagent，每个 Subagent 可以拥有不同的 Tool Capability、Context、Model 和 Permission，而 Orchestrator Plugin 负责创建、调度、暂停、恢复和汇总这些 Subagent，这比在一个 Prompt 里要求模型“你现在扮演 Planner，然后再扮演 Coder”更加可靠，因为不同 Agent 可以在 Runtime 层真正拥有不同的状态和权限。

# Orchestrator创建多个专门Agent
planner = orchestrator.spawn(
    role="planner",
    model=planning_model,
    tools=["filesystem.read"]
)

coder = orchestrator.spawn(
    role="coder",
    model=coding_model,
    tools=[
        "filesystem.read",
        "filesystem.write",
        "terminal.execute"
    ]
)

tester = orchestrator.spawn(
    role="tester",
    model=test_model,
    tools=[
        "filesystem.read",
        "terminal.execute"
    ]
)

这实际上意味着 Harness 可以把 Agent Capability 从模型能力中分离出来，同一个 DeepSeek 模型可以被装进不同 Harness Profile 中，一个 Agent 可以只有 Read-only Filesystem，另一个 Agent 可以拥有 Shell，第三个 Agent 可以连接数据库，第四个 Agent 可以拥有 Browser，这时候 Agent 的能力就不再等于“模型有多聪明”，而是 Effective Agent Capability = Model Capability ∩ Runtime Capability，这也是 Harness 工程非常重要的思想，因为生产环境真正需要控制的不是模型“想做什么”，而是模型“实际上能够做什么”。

# 不同Agent使用同一个模型
model = DeepSeekModel()

# 只读Agent
readonly_agent = Harness( model=model, tools=[ "filesystem.read"])

# Coding Agent
coding_agent = Harness(
    model=model,
    tools=[ "filesystem.read", "filesystem.write", "terminal.execute"  ]
)

对于 Coding Agent 来说，Sandbox 又是 Harness 的关键组成部分，因为模型生成 Shell Command 本身没有意义，真正重要的是 Command 在什么 Environment 中执行，生产 Harness 通常需要处理 Working Directory、Environment Variables、Process Lifecycle、Timeout、Network Permission、Filesystem Permission、Resource Limit 和 Process Cleanup，因此 Sandbox Plugin 实际上是 Agent 和真实机器之间的一层安全隔离。

# Sandbox负责真正执行模型产生的命令
class Sandbox:
    def execute(self, command):
        # 限制执行目录
        cwd = self.workspace
        # 限制执行时间
        timeout = 30
        # 禁止危险环境变量
        env = self.safe_environment()
        return subprocess.run(
            command,
            cwd=cwd,
            env=env,
            timeout=timeout,
            shell=True
        )

Harness 还有一个非常值得关注的方向就是 Skill 和 Tool 的分离，Tool 是模型能够调用的原子能力，例如 read_file、write_file、grep、git_diff、run_tests，而 Skill 更接近一组高层行为规范，例如如何 Debug、如何 Review Code、如何进行数据库迁移、如何处理某种项目结构，因此 Skill 不应该和 Tool 混在一起，Tool 提供“能做什么”，Skill 提供“应该怎么做”，Model 则负责在当前 State 下决定“现在做什么”，这种分层可以表达成 Model = Policy、Skill = Procedure / Knowledge、Tool = Capability、Environment = World、Harness = Runtime。

# Tool：原子能力
tools = {
    "read_file": read_file,
    "write_file": write_file,
    "run_tests": run_tests
}

# Skill：高层操作规范
skills = {
    "debugging": debugging_skill,
    "code_review": code_review_skill
}

# Model负责根据当前State选择下一步Action
action = model.generate(
    state=state,
    tools=tools,
    skills=skills
)

从 AI Infra 角度看，DeepSeek Harness 最值得关注的并不是某一个 Tool，而是它把 Agent Runtime 从 Model Runtime 中抽离出来，VLLM、SGLang、TensorRT-LLM 解决的是 Model → GPU → Tokens，而 Harness 解决的是 Task → State → Model → Action → Environment → Observation → State，二者之间通过标准 Model API 连接，因此一个完整 Agent Infra 可以理解为 Application → Harness → Model API → Inference Engine → GPU，这样模型可以替换，Inference Backend 可以替换，Tool 可以替换，甚至整个 Agent Policy 都可以替换，而 Runtime 不需要重写。

# AI Infra分层
class AgentSystem:
    def __init__(self):
        self.harness = AgentHarness()
        # Harness下面可以接不同Inference Backend
        self.model = VLLMBackend( model="DeepSeek-V4" )
        self.harness.attach_model( self.model )
        self.harness.register_tools( tools )

因此 DeepSeek Harness 对 AgentRL 还有一个很大的潜在价值：Harness 可以成为训练和部署之间的统一 Environment Contract，训练阶段 Agent Policy 在 Harness 中 rollout，Verifier 根据真实 Environment State 给 Reward，RL Trainer 更新模型，新的 Checkpoint 再加载回 Harness 进行下一轮 Rollout；线上部署时仍然使用同样的 Tool Interface、State Schema、Permission、Sandbox、Memory 和 Loop，这样就形成 Policy → Harness → Environment → Reward → Policy 的闭环，而不是传统 AgentRL 中训练代码一套、线上 Agent Runtime 又一套。

# AgentRL训练闭环
for iteration in range(num_iterations):
    # 当前Policy加载进Harness
    harness.model = policy
    # Harness负责真实Rollout
    trajectories = [
        harness.run(task)
        for task in tasks
    ]
    # Environment / Verifier计算Reward
    rewards = [
        verifier.score(traj)
        for traj in trajectories
    ]
    # RL算法更新Policy
    policy = grpo_update(
        policy,
        trajectories,
        rewards
    )

最终理解 DeepSeek Harness 最重要的一句话就是：它不是在给大模型增加几个 Tool，而是在重新定义 Agent 的运行时边界，把 Model 从 Agent 中解耦出来，把 Tool、Skill、Memory、Session、Sandbox、Filesystem、Loop、Orchestration 和 UI 全部变成可组合 Plugin，让 Model 只负责 Policy Decision，而 Harness 负责 State Management、Action Execution、Permission、Environment Interaction 和 Lifecycle Management；这意味着未来 Agent 的竞争可能不再只是“谁的模型 benchmark 更高”，而是 Model Capability × Harness Quality × Tool Ecosystem × Environment × Evaluation 的综合竞争，尤其对于 AgentRL 来说，Harness 可以直接成为 Rollout Runtime + Training Environment + Deployment Runtime + Evaluation Runtime 的共同底座，这一点比单纯增加一个 Agent SDK 更重要；目前公开资料确认的是 DeepSeek Harness Developer Preview 已于 2026 年 8 月 13 日开源，核心设计是 Cordis + Everything-is-a-Plugin，而具体内部实现细节仍需要以官方仓库源码和后续技术文档为准，因此上面的 Plugin、State、Loop、RL 集成代码是按照公开架构抽象出的核心实现方式，不应理解为 DeepSeek 官方源码的逐行复现。 (Pandaily)

DeepSeek V4 Pro 的 pretraining 方法

DeepSeek V4 Pro 的 pretraining 方法不是新训练算法，而是一个典型的大规模 MoE 语言模型训练体系的工业级实现，只是在数据规模、上下文长度课程设计以及稀疏注意力架构上做了系统级增强。它的核心仍然是标准的自回归语言模型预训练，也就是 next-token prediction，没有引入强化学习，也没有引入 agentic 轨迹优化，这一点和 GLM-5.2 那种 long-horizon agent RL 完全是两个阶段的系统。

在 pretraining 阶段，DeepSeek V4 Pro 的基础目标函数非常朴素，本质上就是最大化 token 序列的似然概率。模型结构是典型的 Mixture-of-Experts（MoE），总参数规模达到 trillion 级别，但每个 token 实际只激活少量 expert，因此计算成本控制在几十B active parameters 的范围内。这种设计的本质是用“参数容量换表达能力，但用稀疏路由控制计算成本”。训练目标可以写成非常标准的形式：

L = - Σ log P(x_t | x_<t)

但真正决定 V4 Pro pretraining 特性的，并不是这个 loss，而是它的数据组织方式和上下文课程学习策略。官方明确提到训练数据规模约为 33 trillion tokens，这个规模本身并不是创新点，真正重要的是数据结构的组成方式：它不是简单混合网页、书籍、代码，而是特别强调“long-document native data”，也就是说训练语料中大量保留了完整结构化文档，例如完整代码仓库、整本书、长篇论文、法律文本、技术文档，而不是被切碎的小段文本。这一点非常关键，因为它直接影响模型在长上下文建模上的能力上限。

在训练过程中，DeepSeek V4 Pro 采用的是一种 curriculum learning（课程式上下文增长策略），也就是说模型在不同训练阶段看到的 context length 是逐步增长的，而不是一开始就训练 1M context。早期阶段主要是短上下文（几百到几千 token），中期扩展到中等上下文（几万 token），后期才逐渐扩展到超长上下文（接近百万 token级别）。这种设计的核心目的是避免 attention 在训练初期就退化，同时保证模型逐渐学习“跨段依赖关系”，而不是依赖局部窗口。

Stage 1: 512 - 4k tokens (local syntax + short reasoning)
Stage 2: 4k - 64k tokens (document-level dependency)
Stage 3: 64k - 1M tokens (long-horizon dependency)

在这个过程中，模型架构本身也必须配合长上下文能力，DeepSeek V4 Pro 使用的是 hybrid attention 机制（通常被描述为 CSA + HCA 或类似 sparse attention 组合），其核心思想是用局部密集 attention 处理短距离依赖，同时用稀疏或压缩 attention 处理长距离依赖，从而避免 full attention 在 1M context 下的 O(n²) 计算爆炸。同时还会配合 KV cache compression 或 block-wise attention 来降低显存压力。这些机制的组合，本质上是为 long-context pretraining 提供可训练性基础，而不是改变训练目标。

从工程实现角度看，V4 Pro 的 pretraining pipeline 仍然是标准 causal LM 训练循环，但在数据调度和模型结构上引入了 MoE routing + context scheduler + distributed parallelism。可以简化写成如下形式：

for step in training_steps:
    batch = sample_corpus()
    # curriculum-controlled context length
    ctx_len = schedule_context_length(step)
    tokens = tokenize(batch, max_length=ctx_len)
    logits = moe_model(tokens)   # sparse expert activation
    loss = cross_entropy(logits, tokens)
    loss.backward()
    optimizer.step()

这里真正复杂的部分不是 loss，而是 moe_model 内部的 routing 机制，它决定每个 token 激活哪些 expert，以及如何在 distributed system 中进行 expert parallel communication。此外，context scheduler 会动态调整 batch 内不同样本的上下文长度，使模型逐渐适应长序列输入。

从官方描述来看，还有一个非常重要但容易被忽略的点是：DeepSeek V4 Pro 的 long-context capability 并不是通过“强化学习”获得的，而是 purely data + architecture driven。也就是说，它不是通过 reward 去教模型“如何处理长文本”，而是直接通过在训练阶段暴露大量长文档 + 逐步扩展上下文窗口，让模型在 next-token prediction 目标下自然学习 long-range dependency。这一点和后面 GLM-5.2 那种 agentic RL 完全不同，后者是通过 trajectory reward 去优化“执行行为”，而 V4 是通过语言建模去学习“分布结构”。

在更深一层的理解上，V4 Pro pretraining 的本质其实是三件事的组合：第一是 MoE scaling，也就是通过 sparse activation 扩展模型容量；第二是 long-document curriculum learning，让模型逐步适应长上下文依赖；第三是 hybrid sparse attention，让 1M context 在计算上可行。这三者共同构成了 V4 Pro 的训练基础。

如果把它用更工程化方式表达，其实可以理解为：

Data Layer: 33T tokens + long documents
        ↓
Curriculum Scheduler: context length growth
        ↓
Model Layer: MoE Transformer + hybrid sparse attention
        ↓
Objective: next-token prediction
        ↓
Optimization: distributed large-scale training

DeepSeek V4 的 OPD（on-policy distillation）

DeepSeek V4 中的 on-policy distillation（在策略蒸馏），如果从官方技术报告语境去完整还原，它本质上不是一个孤立的新算法，而是一种把“在线数据生成（on-policy rollout）”与“蒸馏学习（distillation）”结合在同一个训练闭环里的持续优化机制。它试图解决的是一个在大规模 MoE 模型训练中非常现实的问题：模型在训练过程中策略分布不断变化，如果仍然依赖静态数据或离线 teacher 数据进行蒸馏，会出现严重的 distribution mismatch，尤其是在 long-context 和 reasoning / code / agent-like 任务中，这种 mismatch 会直接导致性能上限下降和行为不稳定。因此 DeepSeek V4 的思路是把数据生成过程本身变成“当前策略驱动的”，也就是让模型用自己当前最新的 policy 去生成训练数据，再用这些数据反过来训练自己，从而保证训练始终发生在“当前分布”上。

在 OPD 里，第一步是 on-policy rollout，也就是模型用当前 checkpoint 自己生成训练数据，这一步非常关键，因为数据分布完全等于当前 policy πθ，而不是外部 dataset。模型在 prompt 上进行采样生成，可能是 answer，也可能是 reasoning trace 或 code execution sequence，在一些任务中甚至包含 tool-like interaction。这个阶段本质是在采样当前策略空间，而不是固定语料库：

on_policy_data = []

for prompt in batch:
    output = model.generate(
        prompt,
        sampling=True,
        temperature=1.0,
        top_p=0.9
    )
    on_policy_data.append((prompt, output))

这个 rollout 的意义在于，它让训练数据分布始终贴近模型当前行为，而不是历史行为。这一点在 MoE 模型中尤其重要，因为 MoE routing 是动态变化的，不同 expert 在不同训练阶段会发生 specialization drift，如果仍然使用 offline data，会导致 expert activation pattern 和训练数据分布严重不匹配。

接下来是 evaluation 阶段，这是 OPD 的第二个核心组件。在 DeepSeek V4 的设计里，evaluation 并不是单一 teacher 模型，而是一个组合信号系统，包括更强 teacher model 的 soft logits、reward model 的评分以及规则验证器（尤其在 code / math / tool-use 场景）。这些信号共同构成一个“软目标分布”，而不是单一 label。例如 teacher 提供语言结构和表达方式，reward model 提供行为质量评分，verifier 提供正确性约束，这些信号被整合成一个 weighted supervision target：

y* = α * teacher_distribution + β * reward_weight + γ * rule_score

在 loss 设计上，OPD 通常不会使用纯 supervised cross entropy，而是使用 KL divergence 形式的 soft distillation loss，同时引入 reward weighting，使得不同样本的梯度贡献不同。一个典型形式是：

L = KL(π_student || π_teacher) * w(reward)

或者工程化表达：

loss = 0

for x, y in on_policy_data:
    teacher_logits = teacher(x, y)
    student_logits = student(x, y)
    reward = reward_model(x, y)
    weight = normalize(reward)
    loss += kl_div(student_logits, teacher_logits) * weight

这里的 normalize(reward) 本质上是在做一个 soft advantage scaling，使得高质量 trajectory 在梯度更新中占据更大权重，而低质量 trajectory 即使存在，也不会主导训练方向。这个机制本质上是在做“弱强化学习”，但实现方式仍然是 supervised learning 框架。

在具体机制上，on-policy distillation 的核心流程可以理解为一个循环系统。首先模型在当前 checkpoint 下，根据一批 prompts 或任务输入进行生成，这个生成过程不是 deterministic 的，而是带采样的，也就是说它会产生多样化的 outputs，这些 outputs 本身就是当前 policy πθ 的分布采样结果。这个阶段可以写成：

for prompt in batch:
    output = model.generate(prompt, sampling=True)
    store(prompt, output)

这里的关键点是 data distribution 不是固定 dataset，而是 πθ(x)，也就是当前模型自身的行为分布。接下来，这些 on-policy 生成的样本不会直接用于 supervised learning，而是会进入一个评估与重加权阶段，这个阶段可能同时包含多个信号源，例如更强的 teacher model（如果存在的话）、reward model、规则验证器（尤其在 code 或 math 任务中），以及一些安全或一致性检查模块。这些信号共同构成一个“soft supervision target”，它不一定是单一 label，而是一个分布或者一个加权评分体系。

在 DeepSeek V4 的语境里，distillation loss 通常不只是简单的 cross entropy，而更常见的是 KL divergence 或者 reward-weighted imitation learning 的组合形式。也就是说 student 模型不仅要模仿 teacher 的输出，还要根据 reward 对不同样本进行权重调整，从而强化高质量 trajectory 的学习信号。可以抽象成：

L = KL(π_student || π_teacher)
  + λ * Reward_weighted_loss

或者更工程化一点的形式：

loss = 0
for x, y in on_policy_data:
    teacher_logits = teacher(x, y)
    student_logits = student(x, y)
    reward = reward_model(x, y)

    loss += kl(student_logits, teacher_logits) * reward_weight(reward)

这里最关键的变化在于 reward 不再只是 RL 阶段才出现，而是直接进入 distillation 权重体系，也就是说 on-policy distillation 实际上是“弱 RL + 强 imitation learning”的混合体，它把 RL 的评分能力嵌入到了 supervised learning 的目标函数中。

从系统层面来看，DeepSeek V4 的 on-policy distillation 还有一个非常重要的设计点，就是它是一个持续更新的闭环，而不是一次性训练流程。模型在每一轮更新之后都会改变自己的输出分布，而下一轮数据生成又依赖这个新的分布，因此整个训练过程实际上是在不断追踪 policy shift。可以用一个循环来表示：

for iteration in training:
    # 1. current policy generates data
    data = model.generate(prompts, sampling=True)
    # 2. evaluate data
    scores = reward_model(data)
    # 3. optional teacher guidance
    teacher_targets = teacher_model(data)
    # 4. compute distillation loss
    loss = kl(student, teacher_targets)
    loss += weighted_reward(scores)
    # 5. update model
    optimizer.step()

这种设计的本质意义在于，它让训练数据始终“贴着模型当前能力边界分布”，而不是停留在历史数据分布上。对于 MoE 模型尤其重要，因为 MoE 的 routing 会随着训练动态变化，不同 expert 的激活分布会漂移，如果仍然使用静态数据，会导致 expert specialization 和 data distribution 不匹配，从而影响整体性能稳定性。

另一个隐含但非常关键的点是 on-policy distillation 对 long-context training 的适配性。DeepSeek V4 是一个支持超长上下文的模型，而 long-context 本身就会引入一个问题：模型在长序列中的行为是高度非线性的，早期 token 的微小变化可能会在后续数千 token 中放大成完全不同的输出轨迹。在这种情况下，如果使用 off-policy data（历史生成结果），模型会学习到已经过期的 context behavior pattern，而无法适应当前 policy 在长序列中的真实行为。因此 on-policy sampling 的意义在于，它保证所有训练样本都来自当前 long-context dynamics，从而避免 temporal distribution mismatch。

从更本质的角度来看，DeepSeek V4 的 on-policy distillation 可以理解为一种“将强化学习信号融入监督学习”的折中方案。它没有像完整 RL（例如 PPO 或 agentic RL）那样直接优化 trajectory reward，而是通过 reward 来调整 distillation 权重，使模型在模仿 teacher 的同时倾向于高 reward 样本。这种方式的优势在于训练稳定性更高，计算成本更低，同时仍然保留一定程度的行为优化能力，因此非常适合大规模 MoE pretraining / mid-training 阶段。

如果把整个训练过程抽象成系统结构，可以写成：

On-policy data generation (current model)
        ↓
Reward evaluation + teacher scoring
        ↓
Reward-weighted distillation
        ↓
MoE parameter update
        ↓
Updated policy generates new data

最终 DeepSeek V4 的 on-policy distillation 本质上是在做一件事：让模型始终在“自己当前行为分布”上进行学习，同时用 teacher 和 reward signal 对这个分布进行轻量纠偏，从而避免传统 distillation 中“数据过时”和“分布错位”的问题。它介于纯 supervised learning 和 full reinforcement learning 之间，是一种更偏工程稳定性与大规模训练效率的折中路径。

如果把它放在整个大模型训练谱系里，可以非常清晰地看到它的位置：pretraining 是 learning distribution（学语言分布），on-policy distillation 是 tracking evolving policy distribution（跟随策略分布演化），而 agentic RL（比如 GLM-5.2 那种）则是 optimizing execution trajectories（优化行为轨迹）。三者不是同一层方法，而是从“语言建模 → 分布对齐 → 行为优化”的递进结构。

强化学习笔记 →上下文工程 →Mission: 掌握多模态 LoRA 与 QLoRA →

Kimi系列模型技术解析合集

kimi3的Stable LatentMoE技术解析

Kimi3的 AgentEnv 如何支撑长链路任务

Kimi3的Native MXFP4 量化如何加速推理

Kimi3为什么能完成芯片设计

Kimi3的KDA（Kimi Dynamic Attention）如何优化推理

Kimi K3 的 Agentic RL 后训练创新点合集-含代码

Kimi K3 的训练和部署怎么做的？QAT是什么？

Kimi K3 的整体架构主线是什么？ KDA有什么作用？

GLM系列模型技术解析

GLM-5.3 后训练 Scaling 的第一性原理与技术创新

GLM-5.2 在 Agentic RL 后训练中提出的 CompactionRL有什么用

GLM-5.2 在 Agentic RL 后训练中的 SAO方法

GLM-5.2 的 IndexCache 和 IndexShare

GLM-5.2的Agentic RL做法

GLM-5.2 的注意力机制 DSA

GPT系列模型技术解析

GPT-5 系列的推理架构路线：从 Scaling Transformer 到 Reasoning System，再到 Agent Foundation Model

Deepseek系列模型技术解析

DeepSeek Harness 技术解析：为什么 Harness 正在成为 Agent 的核心基础设施

DeepSeek V4 Pro 的 pretraining 方法

DeepSeek V4 的 OPD（on-policy distillation）

相关文章