从心出发：从架构原本到训推工坊的转型之路

时间：2026-07-25 | 作者：318050 | 阅读：0

2022 年的上海，发生了很多事情。

当时，固有工作难觅新增长点，也正值大模型爆发的前夜。

一个关键问题浮现：传统技术如何玩出新花样？团队和个人又该往哪个方向突破？

工作间隙，我曾想创办一个名为“架构原本”的公众号。这个名字的初衷很纯粹——回到架构的本源。

不局限于某个技术点，也不迷恋某个漂亮的方案。而是去探寻技术背后的内核。

这个内核既包含技术本身，也包含一个架构师、高阶技术人员应该具备的判断力、表达能力、协同能力和交付能力。

那篇发刊词里，写过一句朴素的话：最好的投资，是投资自己。越往后越觉得它重要。

无论外部环境怎么变，逼出更好的自己，长期看都是最稳的投资。写文章就是其中一种方式——它会逼你重新组织知识，逼你分辨自己到底是真懂，还是只是听过。

后来因为工作变动，这个公众号没能持续写下去。

这是一份遗憾。但现在，我决定重新开始。

这一次，名字从“架构原本”变成了“训推工坊”。关注点也从更宽泛的架构设计，收束到 AI 时代最核心的一条工程链路：训练和推理如何组成一个可持续生产模型能力的系统。

为什么是现在

过去几年，AI 行业的叙事变化极快。

一开始大家看模型参数、看 benchmark、看 demo。模型越大、分数越高、回答越惊艳，似乎就越代表技术先进性。

但到今天，这已经不够了。

模型能力还在继续上升，但能力本身不再是唯一问题。

一个 AI 系统能不能被持续训练？能不能稳定评估？能不能低成本推理？能不能把业务反馈重新变成训练信号？能不能在真实环境里支撑 Agent 多轮交互？

这些问题越来越重要。换句话说，AI 的竞争正从“模型中心”进入“系统中心”。

如果只看模型，问题会变成：模型多大？数据多少？榜单多少分？

但看系统，问题就完全不同了：

训练系统能不能支撑反复试错？
推理系统能不能承受真实流量？
后训练能不能把 reward、rollout、policy update 串成稳定闭环？
多轮 Agent 的轨迹能不能精确还原到 token 级别？
GPU 时间到底花在有效计算上，还是花在等待、通信、搬数据和空转上？

这些问题听起来更工程，也更琐碎。但真正能把 AI 能力持续生产出来的，恰恰是这些工程问题。

为什么是训推

传统理解中，训练和推理是两个分开的阶段。训练是离线的，负责更新模型权重；推理是在线的，负责服务用户请求。

但在 RLHF、PPO、GRPO、DAPO、Agentic RL 这些后训练场景里，这个边界正在消失。

推理不再只是训练结束后的部署结果。它会进入训练循环，成为训练样本的生产过程。

具体流程如下：

模型先 rollout，生成回答、代码、工具调用或行动轨迹。
系统再根据规则、reward model、sandbox、搜索工具、环境反馈或人工偏好给轨迹打分。
训练引擎根据 reward、logprob、value、advantage、KL 等信号更新 actor。
更新后的权重再同步回 rollout engine。
然后开始下一轮生成。

这就是“训推”两个字真正合在一起的地方。它不是训练加推理两个模块的简单拼接，而是一条从数据到轨迹、从轨迹到 reward、从 reward 到梯度、从梯度到新权重、再从新权重回到推理生成的闭环。

如果把这条链路展开，至少包括 8 个环节。

第一，数据进入系统

原始题目、对话、偏好样本、代码任务、多模态样本，要先被整理成训练框架能消费的格式。这里会涉及 dataset、parquet、prompt schema、chat template、tokenization、max prompt length、truncation。很多训练问题不是从模型开始坏的，而是从数据字段、模板和 token 边界开始偏掉的。

第二，构造 rollout 请求

系统从训练集中取出一批 prompt，变成推理引擎可以生成的输入。对于 GRPO、DAPO 这类算法，一个 prompt 往往会生成多个 response，形成 group sampling。这里会涉及 rollout batch、generation batch、temperature、top-p、response length、request scheduling。

第三，推理引擎生成轨迹

模型通过 vLLM、SGLang、TensorRT-LLM 或 HF rollout 生成 token。单轮任务里轨迹主要是 prompt 和 response；Agentic RL 里，轨迹还会包含多轮对话、工具调用、环境返回、sandbox 执行结果等。推理在这里不是终点，而是训练样本的生产机。

第四，reward 或环境反馈

生成结果出来后，系统要给轨迹打分。分数可能来自 rule-based reward，比如数学答案匹配；也可能来自 reward model、代码 sandbox、搜索工具、真实环境或人工偏好。这里会涉及 reward function、reward model、verifiable reward、process reward、outcome reward 等。

第五，把生成轨迹转成训练信号

有了 response 和 reward 还不够。训练侧通常还要计算 old logprob、reference logprob、value、KL、token-level reward、advantage、returns 等字段。PPO 会依赖 critic 和 GAE；GRPO 依赖组内相对 reward；DAPO 还会引入 dynamic sampling、token-level loss 等。算法论文里的公式，到了系统里会变成一批必须精确对齐的数据字段。

第六，更新 actor 和 critic

训练引擎拿到整理好的 batch 后，才真正进入 forward、backward、optimizer step。这里会出现 FSDP、Megatron、tensor parallel、pipeline parallel、gradient checkpointing、sequence parallel 等训练系统问题。后训练不是不训练，而是训练只占闭环中的一段。

第七，把新权重同步回推理侧

actor 更新以后，rollout engine 必须用新策略继续生成下一批轨迹。于是系统要处理 checkpoint、weight sync、weight resharding、parameter broadcast、sleep/resume、KV cache 管理。模型越大，推理副本越多，这一步越容易成为关键瓶颈。

第八，评测、观测和故障处理

系统还要定期 validation，记录 reward、response length、KL、entropy、MFU、throughput、GPU memory、rollout latency、trainer idle ratio 等指标。否则很难判断模型是在学习、在发散，还是只是因为 rollout 长尾、reward 噪声、batch 不均衡或权重同步拖慢了整个系统。

后续这个系列会逐篇拆解这些环节。哪些属于算法，哪些属于系统；哪些是论文里的目标函数，哪些是工程里的数据字段；哪些是训练瓶颈，哪些是推理瓶颈——都会尽量讲清楚。

为什么用 verl 作为参照

这个系列，会以 verl 代码库为参照。

选择 verl，不是因为它是唯一值得学习的框架，而是因为它足够适合作为一个“解剖标本”。

verl 来自 HybridFlow 论文，是一个面向大语言模型后训练的 RL 训练框架。它把 PPO、GRPO 等算法流程，放进一个可以连接 FSDP、FSDP2、Megatron-LM、vLLM、SGLang、HF Transformers 等训练和推理组件的系统里。

这件事的价值不只是“支持很多后端”。真正有意思的是：verl 把 LLM 后训练这件事拆成了一个可以观察的系统。

在 verl 里，能看到一轮 RL step 是怎样发生的：

数据从 dataset 进入 DataProto；controller 通过 Ray 调度不同角色的 worker；rollout engine 生成 response；reward function 或 reward model 给轨迹打分；actor 重新计算 old logprob；reference policy 计算 KL 相关约束；critic 估计 value；driver 计算 advantage；actor 和 critic 分别更新；训练权重再同步给 rollout engine。

这条链路里，每一步都对应一个真实的 AI infra 问题。算法问题会变成数据流问题，数据流问题会变成分布式调度问题，分布式调度问题会变成显存、通信、batch、checkpoint、profiling 和 fault tolerance 问题。

这就是想讲清楚的东西。

从“架构原本”到“训推工坊”的系统地图

当年想写“架构原本”，是因为一直觉得架构有“道”和“术”。

设计模式、架构原则、模块边界、抽象能力、演进判断，这些更接近道。
业务架构、搜索推荐、云原生、可观测、工程平台，这些更接近术。

道太抽象，需要术来支撑；术太具体，也需要道来校准。

好的架构设计，往往不是一开始就画出一张漂亮图，而是在约束、目标、团队能力、业务阶段和外部变量之间做取舍。

AI infra 也是一样。

FSDP、Megatron、vLLM、SGLang、checkpoint engine、Agent Loop、reward model，这些都是术。
但它们背后也有道：控制流和计算流如何分离？训练和推理如何复用资源？数据协议如何让复杂轨迹可流动？算法灵活性和系统效率如何取舍？可观测性如何帮助我们判断系统是真的在学习，还是只是在消耗 GPU？

如果只看术，很容易陷入配置和参数；如果只谈道，又容易变成空泛的原则。“训推工坊”想做的，是用真实代码把两者接起来。

这个系列写给谁

最重要的，写给自己。

然后，首先写给工程师。如果你在做训练、推理、RLHF、Agent、GPU 集群、模型平台，verl 是一个很好的入口。它能帮你把很多平时散落在不同项目里的概念连起来：FSDP、Megatron、vLLM、SGLang、reward、rollout、advantage、KL、checkpoint、sequence packing、dynamic batch size、profiling。

也写给 PM 和技术管理者。很多 AI 产品的瓶颈，表面上是“模型效果不稳定”，背后其实是数据闭环、后训练能力、推理成本和系统可观测性的问题。如果不理解训推链路，就很难判断一个功能到底是模型问题、数据问题、系统问题，还是成本结构问题。

还写给 行业分析师和技术观察者。AI 行业的下一阶段，不能只看模型发布会。真正决定格局的，是谁能把模型能力持续生产出来，谁能把训练、推理、数据、反馈、工具、环境和成本管起来。开源框架不是全部答案，但它们给了我们观察产业能力的窗口。