青稞社区于12月28日组织了青稞Talk 第100期特辑：2025 “青稞” AI 嘉年华！

本次活动专为青年科学家打造，旨在搭建一场 AI 技术的深度对话，来自学术和工业界的 20+ 青年科学家，与大家一起回顾 2025，展望 2026！

其中 Infra 专题，由 Sea AI Lab 算法工程师、新加坡国立大学博士生万信逸主持，参与讨论的嘉宾还有：

• 章明星：清华大学计算机系副教授
• 游凯超：vLLM Core Maintainer、清华大学博士
• 朱子霖：智谱 AI RL Infra 工程师、slime 开源项目作者
• 朱力耕：NVIDIA 研究员、MIT 博士
• 庄博涵：浙江大学研究员
• 张晗：RLite 作者、Founder of Yiven AI

以下为专题讨论的实录：

---

2025 技术回望：
Infra 的“第一性原理”回归与演进

万信逸（主持人）:

大家好，我是新加坡国立大学博士生万信逸。欢迎大家参加 2025 “青稞” AI 嘉年华 Infra 专题。

我们先请各位嘉宾用几分钟做一个自我介绍。大概介绍一下自己正在做的方向、主要关心的研究领域，以及在 2025 年，您所关注的领域里面最重要的技术进展是什么！

我们从章明星老师这边开始。

章明星：

非常高兴受到青稞社区的邀请。我是章明星，清华大学副教授。

大家可能对我有所了解，主要是因为我们团队在去年发起的两个开源项目：Mooncake 和 KTransformers。

• Mooncake 聚焦于云侧分布式集群的推理优化；
• KTransformers 则专注于边缘侧 CPU 与 GPU 异构环境下的推理加速。

我长期以来的研究主线始终围绕“推理”展开。今年下半年，我们也开始探索 RL Infra和 Agent Infra（，但即便在这两个新方向上，我们的关注点依然落在推理场景——因为当前 RL 的核心瓶颈，本质上仍在于高效的 rollout（推理生成）能力。

关于“2025 年最大的进展”，我认为这一年确实发生了许多关键性突破。如果回看年初，会发现像 PD 分离（Parameter-Decoupled Architecture）、大 EP（Large Execution Parallelism）等架构理念，如今虽已广泛应用于生产环境、看似“理所当然”，但实际上它们正是在 2025 年才真正落地并走向成熟。

以 Mooncake 为例，我们在 2024 年启动项目时，采用者还相对有限。而到了 2025 年，在 vLLM、SGLang 等开源社区的协同推动下，PD 分离架构被迅速集成到各大推理框架中，如今几乎已成为行业标配。

另一方面，正如本次讨论的主题所暗示的，RL Infra 在 2025 年下半年全面兴起。整个社区都在加速构建可扩展的强化学习基础设施——如何高效地 Scaling Up Rollout，已成为新的技术焦点。

可以说，2025 年的上半场属于“推理的集群化”，下半场则属于“RL Infra 的规模化”。这两股浪潮共同推动了大模型推理与智能体系统迈向更高效率与更大规模。

万信逸（主持人）:

感谢章明星老师的分享，下面请庄博涵老师来聊一聊您的想法。

庄博涵:

大家好，我是庄博涵，来自浙江大学的研究员。非常感谢青稞社区的邀请。

我的研究主要集中在高效算法与基础设施（infra）代码设计，特别关注于高效推理和强化学习（RL）后训练阶段。例如，我最近在探索 diffusion RL 相关的工作，并发现有些场景下算法先行，而在其他情况下则是 infra 先行，后者往往能引出许多新的算法挑战。

近期，我的工作重点放在高效的 word model 开发上，特别是基于 block diffusion 新范式的算法及推理引擎开发。我们的目标是实现实时交互且符合物理规律的长视频生成，为下游应用场景如具身智能和自动驾驶提供强大的数据引擎支持。

回顾2025年，这一领域取得了诸多重要进展：

1、首先，年初 DeepSeek 的发布成为行业转折点，使各大厂商对 Infra 的重视达到了前所未有的高度。在此之前，Infra 的价值或许并未得到充分认识，但现在，所有大厂都已认识到算力、算法与数据三者的协同设计才是成功的关键。

2、此外，预训练模型和后训练规模法则持续发展，使得今年的大模型不仅智力大幅提升，还能够处理更长的上下文和更强的推理任务。

其中，Google 推出的 Gemini 3 Nano Banana 和 VO3 系列模型尤其值得一提，得益于其在数据、算法和 TPU 芯片上的全面优势，这些模型展现了卓越性能，甚至可以作为个人科研助手使用，极大地降低了训推成本，并让某些垂直领域的应用落地变得更加可行。

3、在基础设施领域，今年取得了多项里程碑式的突破。分布式推理技术方面，Prefill-Decoding 分离（PD 分离）、专家并行（EP）以及训推分离架构已得到广泛应用。

与此同时，针对大规模强化学习（RL）的训练框架不断涌现，特别是在 Agent 场景下，异步训练与推理分离技术成为了下半年的核心关注点。

4、在算子层（Operator Level），针对长上下文场景的 Sparse Attention 和 Linear Attention Kernel 实现取得了重大进展。行业内出现了一系列试图超越 Triton 性能限制的尝试，例如利用 NVIDIA 原生 CUDA/CUTLASS 以及新型调度框架进行深度优化，这代表了底层算子开发回归原生的新趋势。

总的来说，2025 年见证了从底层架构到顶层框架的全面协同演进，这种算法与基础设施的深度融合，正在以前所未有的速度推动整个行业的智能化进程。

万信逸（主持人）:

谢谢庄博涵老师的分享，下面请游凯超博士来讲一讲您的想法。

游凯超

好的，感谢主持人，也感谢青稞社区的邀请。我是清华大学的博士游凯超，目前主要负责开源推理框架 vLLM 项目的维护工作。

我感觉到 2025 年的一个显著趋势是：推理的重要性日益凸显，且整个技术栈的演进变得越来越深。回顾 2024 年，我们做推理优化更多停留在框架层面，许多底层基础设施是直接调用的，例如使用现成的 NCCL 通信算子（Kernel）或框架自带的常用算子库。

然而今年，优化的技术栈已经下沉得非常深。在引入专家并行（EP）后，各种通信算子需要深入到 RDMA 和网络传输层进行定制化优化。同时，随着 Prefill-Decoding 分离（PD 分离）的上线，涉及大量 GPU Direct 与 RDMA 的底层配合。

以前，vLLM 可能只是一个简单的 Python 包，安装后配合系统原生的 NCCL 即可良好运行。但现在，若要部署“PD 分离 + 大规模 EP”架构，则是一项集群级别（Cluster-level）的工程。这不仅需要配好互连架构（Interconnect），还需要驱动（Driver）和操作系统（OS）提供配套支持。

与此同时，由于推理负载（Workload）变得越来越重，大家对性能的要求也从 GPU 延伸到了全系统。例如，发现用 Python 写前端 Web 服务的性能存在瓶颈，于是开始引入 Rust；

在推理侧，除了 GPU 上的计算，CPU 上的调度和 Continuation Action 也受到 Python 性能的限制，业界开始讨论是否转向 C++ 重构。

我近期在 vLLM 社区的工作，也主要集中在如何跟进这些新挑战：

1、 新负载：针对 Reasoning 模型带来的超长文本输出，研究如何高效支撑。
2、 新硬件：适配如 GB200 等新一代 GPU 以及 TPU 等加速器。
3、 新算法：如何在 vLLM 中高效支持 Linear Attention 或 Hybrid Model 等新型算法。

总的来说，现在的技术创新呈现出“深度耦合”的特征。开发者不仅要懂算法，还要精通硬件特性和负载规律，进行多维度的联合优化。社区一直在不断创新，也欢迎大家一起参与 vLLM 的开源贡献。

万信逸（主持人）:

好的，感谢凯超的分享。凯超刚才提到的关于 I/O 和底层通信的内容，确实是当前 Infra 领域避不开的核心挑战，那我们后面请朱子霖来聊一聊你的研究内容和你对 2025 年的看法。

朱子霖：

大家好，我是朱子霖，目前在智谱 AI 负责基础设施（Infra）相关的工作。今年我们团队的一个核心任务是从零到一实现了一个完整的强化学习（RL）框架。结合这一年的实践，我谈谈对 2025 年技术进展的看法：

1、首先，2025 年最显著的变化在于训练范式的重塑。从 OpenAI o1 到 DeepSeek R1 的发布，让整个业界意识到，通过强化学习来提升模型的逻辑推理能力是极具潜力的路径。

这导致我们在设计 Infra 时，必须打破原有的“训练”与“推理”的边界。现在，推理已经深度嵌入到训练循环之中，我们需要在同一套框架内，同时处理高吞吐的采样（Sampling）和高性能的参数更新。

2、其次，关于 2025 年最重要的进展，我认为是对底层通信和算子的“第一性原理”回归。过去我们可能更多依赖现成的库，但今年为了追求极限性能，大家开始重新审视通信机制。

例如在处理大规模 MoE（专家混合模型）时，如何优化 All-to-All 通信，如何减少 I/O 带来的阻塞，以及如何针对特定算子进行手写 Kernel 优化，这些都变得非常关键。

3、最后，关于 2025 年及未来的展望，我非常关注长序列与复杂逻辑推理下的系统稳定性。随着 Reasoning 模型输出的 Token 越来越多，如何在长时间的 RL 流程中保证显存管理的极致高效，以及如何通过异步化手段屏蔽 I/O 开销，将是决定大模型智力上限的基础支撑。

总的来说，Infra 的工作正变得越来越硬核，我们需要在算力、通信和算法之间寻找最优的平衡点。谢谢大家。

万信逸（主持人）：

好的，感谢朱子霖老师的分享。下一位请朱力耕老师来讲一讲您对于 2025 年的看法。

朱力耕:

大家好，我是朱力耕，目前在 NVIDIA Research 从事高效 AI（Efficient AI）相关的研究工作。我的个人主要研究领域是多模态推理（Reasoning）。

回顾 2025 年，这一年发生了很多里程碑式的事件。我认为整个行业的技术演进可以分为三个阶段：

第一阶段：DeepSeek V3 带来的基座变革。

三、四月份左右，DeepSeek V3 的发布给业界带来了巨大冲击。这是开源界第一次拥有了能与 ChatGPT 媲美的基础模型。它向我们证明了两件至关重要的事：

• 一是大规模 MoE（专家混合模型）的训练路径是可行的；
• 二是大规模 MoE 的推理存在许多可以落地的技巧。

在 DeepSeek V3 的技术报告发布后，整个业界迅速从传统的 Dense（稠密）模型范式转向了 MoE 模型。

第二阶段：强化学习（RL）基础设施的百花齐放。

随着 DeepSeek V3 的成功，RL Infra 开始进入爆发期。从早期的 OpenRLHF，到后来各种团队开发的垂直框架，再到之后的 Veril 以及 9 月份推出的 SGLang，工具链的迭代速度极快。

今年上半年，如果想复现一个 7B 或 8B 规模的推理（Reasoning）模型，可选择的框架和 Baseline 还很少；

但到了年底，开源社区提供的工具已经非常成熟且丰富。

第三阶段：大厂展示 Agentic（智能体）的未来。

年底，Google 通过 NotebookLM 等项目向我们展示了顶尖 Infra 支撑下的 Agent 表现。这些模型能够在极其复杂的场景下高质量地完成任务，这为整个行业树立了更高的追赶目标。

核心趋势观察：训推一体化的深度融合。

在这些技术潮流中，最令我感触的是推理（Inference）地位的变化。以往在大多数公司或学术组中，SFT（监督微调）团队与推理团队是完全分开的：训练团队关注模型架构修改，推理团队关注算子优化。

但随着强化学习（RL）的普及，推理变成了训练闭环中的关键一环，这要求两个团队必须紧密配合。这种“训推一体化”是今年 Infra 领域最显著的变革。

就我个人而言，2025 年也是一个身份转变的过程。此前对于 vLLM 或 SGLang，我更多是以使用者的身份去调研；但随着技术的演变，我也开始深入参与到这些框架的功能开发与社区贡献中，从“使用者”转变为“参与者”。

以上是我对 2025 年技术路线演变的总体观察，谢谢大家。

万信逸（主持人）:

好的，感谢朱力耕老师。最后我们请张晗老师也来聊一聊聊一聊您的看法。

张晗：

大家好，感谢青稞社区的邀请。我之前毕业于清华大学交叉信息学院，随后在阶跃负责强化学习（RL）相关工作，目前正在围绕 AI 应用层做一些基础设施（Infra）的创业。

在 2025 年上半年，我们开源了一个名为 RLite 的强化学习框架。该框架采用纯原生的 PyTorch 和 Transformers 接口实现，旨在提供高效的 RL 支持。可以说，我们在 2025 年共同见证了 Infra 与算法之间同步且螺旋式上升的过程。

关于今年的技术观察，我想从以下几个独特的角度进行补充：

1、首先，我非常认同前面嘉宾对 DeepSeek 的评价。除此之外，我对 Gemini 的出现感到非常兴奋。它向行业证明了预训练与后训练依然存在巨大的演进空间。未来的方向不仅是“训练模型”，而是“训练一个系统”。

这意味着配套的 Infra 绝不仅仅局限于训推（训练与推理），还包括模型前后置流程的配合，例如复杂的渲染系统或其他工程环节，这些都将成为 Infra 研究的主流。

2、其次，是原生多模态能力的爆发。像 Gemini 以及原生多模态模型展示出的能力，是撬动模型能力跃迁的重要杠杆。我们看到 2025 年模型能力呈阶跃式上升，我预期 2026 年在 Agentic（智能体） 方向将会看到百花齐放的场景。

3、最后，我想提到一个目前行业内尚未完全解决的痛点：CPU 密集型任务与训推框架的深度结合。虽然大家都在关注 GPU 端的进步，但在实际 AI 应用执行中，有大量繁重的任务发生在 CPU 端。

例如，如何处理文件系统故障（Failure）、如何解决 CPU 侧的阻塞以减小整体瓶颈（Bottle Neck）等。特别是在训练时，如何模拟那些现实应用中可能出现的工程错误（如文件系统挂载失败），并让模型学会处理这些 Case？这些问题具有极强的实际意义，目前我们依然在探索的道路上。

以上是我的一些观点，谢谢大家。

---

RL 系统深水区：尚未攻克的硬核挑战

万信逸（主持人）：

感谢各位嘉宾。刚才大家提出的问题都非常有启发性，刚才几位老师也都提到了 RL 系统的问题。

回顾 2024 年，ML Systems的核心议题无疑是推理（Inference）。而步入 2025 年，业界已经达成共识：RL（强化学习）系统正逐渐成为新的核心议题。

今年，行业内涌现了许多优秀的 RL 框架，例如 Slime、ROLL 以及 AReal 等 。目前这些系统在负载均衡、解决 Rollout 阶段的长尾问题，以及提升系统吞吐量和稳定性方面，都取得了显著进展 。

接下来，我们想深入探讨一下：在各位老师看来，目前在 RL 系统层面，还有哪些最关键的挑战尚未被攻克？立足当下，你们认为最紧迫需要解决的问题是什么？

首先，我们还是请章明星老师分享您的见解。

章明星：

RL 的确就是当前，至少是下半年大家很关注的一个主题。

关于刚才那个“问题是否已解决”的判断性提问，我的观点是：解决之路才刚刚开始。强化学习（RL）与之前的预训练（Pre-train）存在一个巨大的本质区别——RL 没有像预训练那样明确的主线。

在预训练阶段，大家的主力任务相对集中，即训练一两个超大规模模型，并致力于将 MMLU 等核心指标刷上去。但 RL 面对的是极度碎片化的场景，它需要在灵活性、收敛性、系统效率以及 CPU/GPU 资源分配等多个维度，根据不同场景进行复杂的权衡（Trade-off）。

这种多样性导致我们必须针对不同需求进行定制化开发：

• 异步与同步的切换：早期我们认为异步训练更有潜力，因此实现了部分 Rollout；但后来发现某些场景更需要同步信号，于是我们又通过历史数据实现了类似投机采样（Speculative Decoding）的工作。
• CPU 开销优化：针对 CPU 负载过重的问题，我们开发了透明环境（Transparent Environment）等技术。

然而，这些技术并非在所有 RL 实验中都通用，这使得 灵活组合（Composability） 成为了 RL 框架的核心需求。例如 SGLang 这样的框架，其最重要的生命力就体现在灵活性上。

目前，RL 领域的许多研究者需要根据特定的业务场景，不断定制新的 Workload、Workflow 甚至是 Agent 环境。但在当前的工程体系下，这些组件的易用性与迁移成本依然很高。

我们要加速的不仅仅是实验本身的运行速度，更是从研究者脑中的构思到最终投产拿数的全链路迭代速度。这不仅需要一个框架，更需要完善的中间件、脚手架工具以及更底层的基础设施支撑。

此外，我非常认同张晗老师的观点：业界目前对 CPU 的关注度严重不足。 未来，若要构建更复杂的 Agent 环境，现有的 Docker 容器技术可能已无法满足需求。我们可能需要引入 MicroVM（微虚拟机）、嵌套虚拟机、复杂的网络拓扑以及精密的 Workflow 编排。

目前在开源界，这些针对复杂 Agent 环境的构造工具几乎处于“负分”状态，表现非常原始。这其中蕴含着巨大的技术机会，值得我们投入更多精力去解决。

万信逸（主持人）:

好的，感谢章老师，庄博涵老师这边有没有什么想法呢？

庄博涵

好的。我认为目前的 RL 基础设施（Infra）主要还是针对大语言模型（LLM）开发的。我最近在探究一些与 Diffusion RL（扩散模型强化学习）相关的工作，发现这个领域目前处在一个比较尴尬的局面，算法端和系统端的研究者有些“大眼瞪小眼”。

具体来说，做系统的人认为 Diffusion 算法尚未完全成熟，采样速度极慢，因此在系统架构设计上还在纠结；而做算法的人则抱怨 Infra 性能太差，尤其在训练视频生成模型（Video Generation）或世界模型（World Model）时，训练时长过长，导致开发成本极高。双方陷入了一个僵局。

我最近也在做一些关于 Diffusion RL 高效采样的相关工作，并一直在思考系统层面的核心问题。在 LLM 的 RL 场景下，由于推理（Rollout）是 I/O Bound（受限于输入输出带宽），而训练是 Compute Bound（受限于计算能力），因此**“训推分离”架构非常符合第一性原理**。但在 Diffusion 领域，训练和推理（Rollout）对资源的消耗都非常大，往往两者都能把硬件性能打满。

在这种情况下，原有的“训推分离”动机是否依然成立？如果第一性原理不成立，那么 Diffusion RL 系统的优化空间到底在哪里？我觉得这是大家急需审视的问题。

目前我也没有完全想清楚，但可以肯定的是，随着视频生成和世界模型的火热，大家已经看到了它的价值，但市面上非常缺乏一套成熟的 Diffusion RL 训练与推理系统。

我建议大家不要只关注在文本 Agent 场景下的 RL 系统开发，视觉相关的 Diffusion RL 框架也是极其紧迫且具有前景的方向。

另外，Diffusion 模型还面临 Batch Size 扩不大的问题，往往 Batch Size 设为 1 时系统资源就已经占满了，这同样是系统优化需要面对的巨大挑战。

万信逸（主持人）:

非常同意。Diffusion RL 的范式确实与 LLM 有很大不同，这确实是一个非常值得关注且具有潜力的方向。那我们也请凯超来聊一聊自己看法。

游凯超:

我非常认同前面两位老师的观点。目前 RL（强化学习）的基础设施框架中，相对成熟的确实大多集中在 LLM（大语言模型）和纯文本领域。这主要是因为文本环境的搭建相对容易——实际上几乎不需要复杂的外部环境，只需处理文本的输入输出即可。

但正如张老师所言，如果我们要进行 Agent（智能体）方向的强化学习，目前开源社区其实还缺乏一个真正好用的 Agent 框架。要实现大规模的 Agent Serving（智能体服务），这本身就是一个极高的基础设施（Infra）挑战。

同时，庄老师提到的多模态（Multimodal）RL 也是目前非常急需的方向。无论是 Agent 还是多模态任务，它们都在纯文本 LLM 的基础上增加了多维度的复杂度，而目前的 Infra 框架还无法很好地处理这些新增的复杂性。

当然，即便在 LLM 本身的强化学习领域，也依然存在尚未解决的痛点：

• 超大规模模型的 RL 实现：当模型参数量极其庞大时，如何高效配置计算与内存资源。
• 超长序列的 Rollout 采样：当推理长度显著增加时，如何保持训练的高效能。

所以，我认为未来还有很多关键工作需要突破：如何在 LLM 基础上让 RL 变得更高效、规模更大，以及如何攻克 Agent 和多模态场景下的 RL 难题。

作为开源社区的一员，我们也在思考下一个突破口在哪里——期待未来能有像 DeepSeek V3 这样具备影响力的开源项目出现，无论是针对 Agentic（智能体化）还是多模态体系，为整个行业提供可以跟随和参考的标杆。

万信逸（主持人）:

我想抛出一个很有意思的问题。凯超之前参与过 Tianshou（天授） 的开发，那是传统强化学习（RL）时代的代表性框架。现在的 RL 系统在环境搭建和采样（Rollout）等方面，其实与 LLM 时代之前的系统有着深厚的渊源。

你觉得传统 RL 系统所关注的重点，有哪些是现在的系统可以借鉴的？或者说，这两者之间最大的差别在哪里？

游凯超：

虽然同为 RL 系统，但两者的差别确实是跨代际的。

最核心的一点是 Actor（执行者）规模的剧变。在传统 RL 时代，我们处理的是 Atari 游戏或 MuJoCo 物理模拟。那时的 Actor 输入只是几十到几百像素的小图，网络结构往往只是几层 MLP，模型大小仅有几兆字节。

而现在的环境虽然逻辑上有相似之处（例如都要调用环境接口进行采样），但现在的 Actor 已经演变成了参数量巨大的 LLM。

以前的 Rollout 只是一个小网络的简单前向传播，计算开销极低；现在则变成了极其沉重的模型推理。这种从“轻量级 Actor”到“重量级 LLM”的转变，对基础设施（Infra）提出了巨大的挑战。

虽然现在的 Agent Rollout 在形式上能看到一点传统 RL 的影子，但底层面临的计算负载和系统复杂度已经完全不在一个量级上了。

万信逸（主持人）:

感谢凯超，那我们也请那个朱子霖老师聊一聊你的想法。

朱子霖

好的。我非常认同章明星老师刚才提到的观点。从另一个角度来看，过去两年我们在大模型领域优化的预训练（Pre-train）框架，其实是一个“过于有主线”的特例。

在以往开发 PyTorch 或 TensorFlow 等通用框架时，开发者并不需要预判算法老师的所有新想法并提前实现。但在预训练时代，因为主线明确，我们会直接将 RoPE（旋转位置编码）等特定技术写死在框架里。现在的 RL 时代则是一个“回归”的过程，大家开始重新适应一种更具通用性的 Infra 设计方式。

因此，今年我**们在进行系统设计时，一个核心重点是：**如何在给算法研究者留出足够设计空间的同时，将 Infra 问题进行模块化抽离。

目前我们的理解是，可以将 RL 框架视为一个 “训练框架 + 推理框架”的集成系统 。我们需要做的是处理好两者之间的联合逻辑，比如参数的同步更新、推理数据的回传等，并为算法老师提供足够的接口来进行自定义处理。

基于这种思路，前面提到的 Diffusion RL 同样可以纳入这个大系统。今年我们看到 ASR（语音识别）和视觉领域都在尝试 Diffusion 方案（如 VR-Omni）。随着开源推理框架在 Diffusion 领域逐渐成熟，配合现有的 SFT 训练框架，RL 系统自然可以通过“训推结合”的方式接入这些多模态场景。

谈到目前还剩下的问题，从训练框架的角度来看：

• 极致性能与稳定性：如何最大程度地压榨硬件性能，并保证长期训练的稳定，这永远是最紧迫的问题。
• Agent 系统的缺失：正如张老师所说，目前开源社区的 Agent System 几乎处于“负分”状态。这主要是因为算法层面尚未达成共识。

我们希望随着算法社区的发展和理解的深入，开源界能形成一套相对通用的 Agent 规范和系统。这样大家在进行研究时，就不必再经历手动搭建 Docker 集群等繁琐的工程体验。我认为这正是现阶段最紧迫需要解决的问题。

万信逸（主持人）:

好的，朱子霖老师的回答非常有insight。后面我们请朱力耕老师来聊聊对 RL 系统的看法。

朱力耕：

好的，我接着子霖老师的话题继续深入。

今年上半年的强化学习（RL）可能主要集中在解决“数学题”这类逻辑任务上。但到了年底，许多令人印象深刻的 Demo（如 Google 的 NotebookLM、Nano 以及国内的 AutoGLM、豆包等）都向我们展示了 Agent（智能体） 的重要性。

目前，对于大部分团队来说，构建一个 Sandbox（沙箱系统） 依然是一件极其麻烦的事情。即便是在公司内部，想要找到能帮你管理 K8S、自动拉起虚拟环境并运行 Reward（奖励机制）的运维支持都很难，更不用说缺乏运维经验的学术界了。

因此，如何构建一个既易于使用（Easy-to-use）又具备可扩展性（Scalable）的沙箱系统，是业界目前的当务之急。

如果没有这样的系统，很多复杂的 Python 任务只能通过一些非常原始且“脏”的方法（如 Mock 掉函数）来强行运行，这完全无法实现规模化（Scale）。

理想状态下，沙箱系统应该像推理引擎一样：用户只需发送一个 HTTP 请求，后台就能自动处理复杂的调度和 CPU 资源分配。目前这在开源生态中是完全缺失的，这也直接导致开源界难以训练出顶尖的 Agent 模型。

此外，我个人的另一个深切感受是 训练（Train）与采样（Rollout）阶段的资源分配问题。目前，大多数 Infra 同学在做 RL 训练时，习惯采用“训练与采样同规模部署”的方式（Colocation）。例如，用 128 张卡做训练，采样时也同样用这 128 张卡。

但随着任务变得更加复杂、更加偏向 Agentic（智能体化），训练不可避免地会向 异步化（Async） 演进，且 Context（上下文）的变动会非常大。在这种情况下，训练阶段可能只需要 64 张卡，但采样阶段为了保证效率，可能需要 256 张甚至 512 张卡。

我们需要一种弹性（Elastic）且动态的资源调整机制。比如给出一组包含 1024 张卡的资源池，系统能根据当前阶段的需求，智能地在训练和采样之间调配卡数。

目前在使用一些开源 RL 框架时，由于缺乏这种动态伸缩能力，经常会出现 GPU 空转闲置的情况，利用率非常低。

总结来说，我认为目前开源 RL 框架最紧迫的需求有两个：

• 一套开源且可扩展的沙箱系统（Scalable Sandbox System）。
• 一套智能的、支持训推动态分配的弹性调度机制（Elastic Dynamic Allocation）。

这两个点的突破，将对整个 RL 训练效率产生巨大的提升。

万信逸（主持人）：

非常同意朱力耕老师的观点。其实大家刚才在讨论中都多次提到了 Agentic（智能体化） 这一关键词。为了提高讨论效率，我们将接下来的两个问题合并：

除了刚才提到的系统架构，我想请张晗老师进一步分享您的见解。在您看来，当前的 Infra（基础设施）系统 与新兴的 Agent Workflow（智能体工作流） 之间，是否存在一些尚未解决的兼容性问题或特定的技术挑战？对于这两者的结合，您的核心看法是什么？

张晗：

我刚好在这一块有一些跨界的经验。在强化学习（RL）的开发过程中，我不仅编写算法，也编写基础设施（Infra）。最初自研 Infra 是因为当时市面上只有 OpenRLHF，很多想修改的底层逻辑无法实现。

在这个过程中，我观察到一个最致命的痛点：强化学习在跨环境后的泛化性（Generalization）极差。

我们曾做过一个非常针对性的案例：Word Count（字符计数） 任务。例如统计一个字符串里有多少个“t”或“r”。在一个简单的、针对性构建的环境里，我们可以把模型训得非常好，一个 7B 模型能将 512 位长度的字符串数得极其准确。

然而，这个模型完全无法泛化到另一个看似相似的任务——比如将字符串里的“a”替换成“b”。在训完计数任务后，它的替换能力没有任何提升。

这暴露了当前强化学习 Recipe 的核心短板：缺乏跨环境的泛化能力。 虽然有些子任务（如大数计算）在训练后能提升模型在数学领域的整体表现，但对于许多并列的逻辑任务，目前依然无法实现从任务 A 到任务 B 的泛化。

这不仅是算法的困境，也是 Infra 的巨大痛点。如果无法实现跨环境泛化，我们就无法搭建一套普适的、能适应所有下游任务的环境系统。

从两个方面来看这个问题：

1、 机遇：由于没有公司能做出一个“吃掉所有任务”的普适环境，这给在关键垂直领域（如机器人、特定工业场景）深耕环境搭建的团队留下了机会。
2、 挑战：从 AI 系统的长远发展来看，这并不是一个好消息。我们目前只能像“打地洞”一样，一个环境接一个环境地去搭建，优先解决一些关键的 Agentic Case（智能体案例）。

我认为，系统挑战与算法本身是无法抽离的。下一步，我非常期待看到能实现显式泛化（Explicit Generalization） 的算法出现——即通过训练任务 A，能显著提升模型在任务 B 上的表现。这种算法的突破，将直接影响未来我们整个 Infra 架构的演进方向。

---

异构化与动态化：训练系统的范式转移

主持人（万信逸）：

感谢张晗老师。刚才我们深入探讨了 RL 系统的诸多细节。目前社区已经达成共识：大模型的训练范式正在发生根本性变革。

在过去两年（2023-2024年），预训练系统主要遵循 SPMD（单程序多数据） 模式，即上万张显卡同时运行相同的任务。但到了 2025 年，无论是 RL、预训练还是 SFT，这种单一模式已被打破。

以 DeepSeek-V3 为例，它采用了流水线并行（PP）与专家并行（EP）的深度融合变形，这本质上已经脱离了传统的 SPMD 范式。再加上 MoE（混合专家模型）和各类稀疏模型（Sparse Models）的普及，训练系统正从同构走向高度异构化。

这种演进带来了数据输入长度不一、计算负载极度不均衡等一系列复杂问题。因此，我想请各位嘉宾聊聊：这种高度异构化给训练系统带来了哪些新的机遇与挑战？在 RL 这条主线之外，有哪些之前不存在、但在这种异构形态下新出现的有趣课题值得研究？

章明星：

关于 SPMD（单程序多数据）和 MPMD（多程序多数据）的讨论，虽然很多 RL 框架都在强调两者的区别，但说实话，我一直觉得从本质上界定它们的界限并不是最核心的痛点。

最近我重新回顾了 Jeff Dean 在 2021 年提出的 Pathways。虽然距今只有四年，但在 AI 领域确实有种“恍若隔世”的感觉。当时他预测我们需要 MoE（专家混合模型）来让模型泛化到不同场景，现在的技术走向证明了他的预判极其准确。

但我认为，当前系统演进最大的区别不在于 SPMD 与 MPMD 的名称之争，而在于控制范式的转变：我们到底是用一个预设好的、主线式的 Workflow 去驱动所有计算，还是转向一个更加 Event-driven（事件驱动） 的架构？

在未来的高度异构环境下，系统底层应该是一个巨大的 Dataflow（数据流）。不同的事件互相驱动产生不同的 Workload（工作负载），其中包含大量的异步操作。例如，实时感知环境状态并据此动态调整计算资源。

为什么 Event-driven 模式是未来的必然选择？主要有两点原因：

1、 解决利用率瓶颈：特别是在 RL 场景下，Batch Size 往往很难打满，我们需要通过更灵活的事件调度来填补计算空隙。
2、 处理 CPU 与 GPU 的异构协同：正如几位老师提到的，当 GPU 运行时 CPU 可能在等待，或者不同 Agent 的任务密度不一。只有通过事件驱动的方式，才能在复杂的异构资源中实现更高效的切换与利用。

当然，Event-driven 的代价是编程复杂度的急剧上升。这需要一套非常强大的基础设施（Infra）才能支撑起这种系统的平稳运行，这正是未来的一个巨大机会。

此外，这种思路也正在深入到算子层。最近大家关注的 Megakernel、MPK 以及 Triton 等底层研究，其本质也是不再将 CUDA Kernel 视为一个整体的黑盒，而是将其拆解为更小的单元，进行类似事件驱动的微调度。我认为，这种从上层框架到底层算子的“动态化”与“事件化”，将是未来异构优化最重要的思路。

主持人（万信逸）：

非常感谢章老师。我非常认同您的观点，随着系统变得越来越动态，传统的“预先编排策略、整体同步执行”的范式确实需要进行根本性的改变。接下来，我们请博涵老师分享一下您的看法。

庄博涵：

好的。关于异构化和大规模模型，我有一个关于 2026 年的预测：各大厂的模型参数规模肯定会突破 T（万亿）级别，甚至达到 1.5T 到 3T 左右。

在这样的参数规模下，首先面临的挑战就是超大规模 Checkpoint（检查点） 的处理。Checkpoint 的体积将变得巨大无比，其保存和加载过程会极其缓慢。针对这种异构系统，我们是否可以利用 CPU 和 GPU 的不同特性来加速这一过程？

我认为这里有几个非常有意义的研究方向：

1、 异构加速 Checkpoint 加载：探索如何利用 CPU 侧的大内存和高速带宽，配合 GPU 进行并行化的加速。
2、Partial Checkpoint（部分检查点）方案：是否可以实现增量式或部分式的保存与加载，而不是每次都处理完整的巨型文件。
3、 高可用与快速容错恢复：在训练出现故障时（例如某个 GPU 挂掉），系统如何快速恢复？

特别是在 MoE 架构下，如果某个节点失效，我们能不能做到只“屏蔽”部分受影响的专家，而不是让整个集群停摆？实现这种非阻塞式的快速恢复，对于万亿规模模型的训练稳定性至关重要。这不仅是工程问题，更是异构系统设计中必须攻克的难关。

主持人（万信逸）：

刚才博涵老师提出的关于大规模 Checkpoint 和系统容错的问题非常关键。

其实我觉得这是一个非常典型的视角差异：在学术界研究系统时，弹性（Elasticity）或容错可能不是最优先考虑的 Top Tier 问题；但在工业界，这些挑战是非常直接且残酷的。比如你在万卡集群上训练，任务跑到一半突然崩溃，如何进行高效的 Checkpoint 回滚？如何实现无感知的快速恢复？这些都是决定项目成败的核心工程问题。

顺着这个思路，我想请凯超聊聊：面对训练系统日益明显的异构化趋势，你有怎样的观察和想法？

游凯超：

我感觉系统的异构程度确实在变高，复杂度也随之提升。原先的 LLM 训练任务主要依赖以 GPU 为主的集群，因为输入输出的文本数据量极小，即便把整个 Web 抓取下来，相对于现在的存储容量也并不算大。但刚才提到的存储（Storage）问题，在模型规模急剧膨胀后，连磁盘存储都成了挑战。

再者是 Agentic 任务，它需要在 CPU 集群上运行。如果现有的集群纯粹由 GPU 组成，那就必须考虑硬件改造：是否需要增加 CPU 节点？CPU 与 GPU 节点之间如何互联？

加上前面提到的多模态（Multimodality）趋势，机器的配置会变得更加复杂。比如在纯 GPU 的计算节点之外，可能还需要专门处理视频编解码（Codec）的模块。这些复杂度其实是问题本身内置的。此前大家只关注纯粹的文本 LLM 任务，掩盖了这些复杂性，而现在我们不得不面对这些本质的难题。

主持人（万信逸）

的确，在预训练（Pre-training）时期，谁能想到后续会涉及这么多复杂的环节。

游凯超：

对。如果你只在一个集群内训练，存储处理会非常简单，大家共用一个文件路径即可。但一旦涉及到跨集群（Cross-cluster）训练，原有的很多假设就不再成立了，必须重新考虑整套处理机制。

主持人（万信逸）：

好，感谢凯超。梓琳（朱梓琳），针对异构化这个趋势，你有什么想法？

朱子霖：

我其实觉得 RL 系统化与异构化（即训练与推理并存）的趋势，对于做 Infra 的人来说是一件好事。

在之前的预训练（Pre-training）或 SPMD 训练模式下，最棘手的问题是基于 MPI 或 NCCL 的通信机制容灾性极差。一旦某个节点发生故障，整个集群就会挂起（Hang死），大家只能强行杀掉所有进程并重启。

在这种情况下，调度层（Scheduling）几乎没有发挥空间，K8S 往往只充当一个 Gang Scheduler，用户在机器学习平台上申请固定数量的机器，启动预训练或 SFT 任务。这种模式使得传统架构关心的容灾、混部、弹性扩缩容等功能，都被底层 NCCL 的限制卡死了。

现在引入了异构性，尤其是推理引擎的加入，情况发生了变化。推理服务端（Inference Server）之间通常不需要 NCCL 这种强耦合的通信，每个实例可以独立运行。如果某个推理节点出现故障，我们只需将其剔除或单独重启即可。

这意味着我们的操作空间变大了。例如，国内厂商的用户量巨大，存在明显的“潮汐效应”：在业务高峰期，我们可以将更多算力资源拨给线上推理侧；

到了夜间业务低谷，则可以将这些显卡释放出来，供给 RL 任务进行大规模采样（Rollout）。此外，我们还可以探索 SFT 与 RL 集群的混部方案，以最大限度地提升硬件利用率。

总的来说，异构化其实是一个“松绑”的过程。之前受限于底层硬件和通信库的约束，很多技术尝试都以失败告终，甚至导致没人敢再去尝试。

现在有了这些新机会，我们可以重新翻开曾经在分布式系统或数据库领域积累的经验。我相信这些经典的工程智慧在新的异构环境下，能够催生出更多有意思的工作。

主持人（万信逸）：

我顺着这个话题多问一个。你提到了 NCCL 通信和容灾的问题，我的理解是，非 RDMA（如普通的 TCP/IP）网络相对容易实现重连和弹性。现在的推理系统之所以容易做 Elastic（弹性伸缩），是因为节点间相对独立。

但目前我也看到一些前沿工作在研究基于 RDMA 的弹性通信，比如通过按专家（By-expert）切分服务等。你觉得现在的底层通信库（如 NCCL 或其他 RDMA 库）是否有一个明确的趋势，正朝着支持弹性或动态调节的方向发展？

朱子霖：

首先说明一下，我对底层通信库的研究并不算深，以下仅基于我个人的理解，不一定完全准确。

在大模型领域，我们之所以看到机会，是因为算法层面的 Scaling Law 带来了性能骤变，比如我们发现 RL 和 MoE 结合后产生了一系列全新的问题。但在通信领域，我不确定从传统分布式时代到现在，底层硬件是否发生了足以支撑这种“弹性”跨越的巨大变化。

其实在 MPI 时代，大家就一直在尝试做容灾，比如 OpenMPI 提出过很多方案，但最后在生产环境的生效效果并不理想。

我不确定现在是不是因为底层架构变得更简单了，还是因为目前这个领域资源投入极高（“钱太热”），导致每一个细节都能被做到极致。如果真的能实现更具容灾能力的 RDMA 通信，或者说具备高容灾特性的 NCCL 集合通信，那对所有做系统的人来说都是特大喜讯。

据我所知，NCCL 的新版本（如 2.2x 之后）已经引入了可以从通信组（Communication Group）中剔除某个故障节点（Rank）的容灾机制。但像我们理想中那种完全动态的、无感的扩缩容，目前似乎还没有成为主流。

所以，从一个不深耕通信、但极度渴求这种能力的开发者视角来看：如果通信库能真正实现弹性与容灾，我们能实现的功能空间会大得多。但我确实不太确定目前通信库领域最前沿的进展是否已经能完美解决这些本质挑战。

章明星：

有的，这正是我们目前重点攻关的方向！欢迎大家关注我们的 Mooncake 项目。

目前我们在 HStore 上正准备进行 Elastic EP（弹性专家并行） 的 POC（原型验证），预计很快就会发布。其底层核心采用了 P2P（点对点）通信原语，这使得上层架构可以非常灵活地进行组网。无论是动态加卡、删卡，还是处理各类复杂的拓扑变化，在技术上都是可实现的。

此外，我们下一代的 Transformer Engine (TENT) 在内核层面也会原生自带 容错（Fault Tolerance） 特性。正如大家所感受到的，当集群规模迈向万卡甚至更高时，系统对自动容错和动态弹性的诉求已经从“可选项”变成了“必选项”。

朱子霖：

那太好了！这正是我们 Infra 侧最期待突破的技术节点，非常期待 Mooncake 和 TENT 的后续进展。

主持人（万信逸）：

好的，那我们继续。朱力耕老师，您这边有什么想法吗？

朱力耕：

前面各位老师已经聊了很多从统一的 SPMD 到动态工作流（Workflow）演进的话题。我站在一个稍微不同的视角补充一下，因为我之前所在的团队有成员是真正做芯片流片的，所以我会关注硬件层面的变化。

当 Workflow 变得异构（Heterogeneous）时，意味着我们可以为不同的任务匹配不同的硬件。在预训练阶段，大家更多是在比拼 H100 的集群规模；但在 RL 阶段，尤其是采样（Rollout）环节，硬件选择其实非常多元。

目前在训练（Training）领域，NVIDIA 仍有绝对优势，但在推理侧，可选的硬件有很多，包括国产卡。即便是 NVIDIA 内部，H100 侧重训练，H200 等侧重推理。以前这两类卡在物理上或权限上可能分属不同的集群与分组，但在 RL 框架下，如果你将训练和 Rollout 阶段分开，就可以把这些卡更好地利用起来。

这种系统层面的新机遇源于两者计算密度的巨大差异。预训练的 ​FLOPs/Byte 大约在 ​10^5 数量级，而 Decoder 推理时大约只有 ​10^1 到 ​10^2 左右，中间差了两三个数量级。我认为针对这种本质差异进行系统优化，是一个全新的机会。

主持人（万信逸）：

感谢。我顺着这个思路问一下：从 NVIDIA 的角度看，不同的任务对应不同的计算特性，其计算访存比（Arithmetic Intensity）差异巨大。比如用 H100 去跑一些访存密集型任务，计算算力可能会被大量浪费，因为访存瓶颈导致其根本无法达到峰值性能。不知道 NVIDIA 在设计专门的推理硬件时，是否有针对这类问题的特殊考虑？

朱力耕：

这正是最近讨论度很高的 Groq所关注的方向。他们利用超大容量的 SRAM 来构建推理硬件，本身就是解决访存瓶颈的一种尝试。

当然，在 GPU 产品线中，每一代的 L40/L40S 等型号也都是针对推理场景优化的卡。NVIDIA 在这方面一直有很多尝试。本质上，系统设计需要根据不同的 Workload（工作负载）去适配不同的算法与硬件。而 RL 恰好是“训练”与“推理”两种负载的天然混合体，因此它天生就非常适合通过这种异构硬件的思路来进行深度优化。

主持人（万信逸）：

好的。张晗老师，您有什么看法？

张晗：

前面的老师们已经把这个问题拆解得非常细致了，我补充一点自己的观察。现在的异构化主要集中在两个层面：一是 CPU 与 GPU 的协同，目前两者已经紧密耦合；二是训练与推理使用不同的卡。

在强化学习（RL）中，大家会混合使用 A100、H100 甚至国产的 S0 等不同型号的芯片。由于这些卡的架构不同，训练出的模型在稳定性等方面可能会存在差异。不过，我一直在跟进相关的 Infra 进展，目前的底层设施已经在逐步处理这些硬件兼容性问题，所以我认为这方面不会存在特别大的技术门槛。

谈到机遇，我觉得未来的方向可能会更多来自于多精度训练（Mixed Precision Training）。有些卡可以利用更低精度的计算特性来显著提升效率，从而让训练和推理变得更加高效。

因此，在异构化训练这一块，取决于我们站在什么角度：如果是站在国产芯片的角度，可能存在很多通过芯片特性实现“弯道超车”的机会；如果是站在整个系统架构的角度，尝试向更低精度（如 FP8 或 INT8） 演进，可能是将系统性能推向新高度的关键。我大概的想法主要是这些。

---

精度博弈：
低精度的红利与工程阵痛

主持人（万信逸）：

嗯，这就顺着引出了我们要讨论的下一个核心话题：精度问题。我观察到 ML 系统社区通常非常青睐低精度，因为这能显著提升吞吐；但算法社区对此却持有保留意见，近期已有数项研究（尤其是针对 RL 领域）指出，精度损失是导致训练崩溃的核心诱因之一。

站在 Infra 的角度，我们追求的是“训得快”；而算法层面，大家更关心“收敛效果”。现在社区出现了一些反思：我们是否在推广低精度（如 FP8/INT8）这件事上过于乐观了？

由于系统层面对低精度的极致追求，是否已经对算法的实质性效果造成了负面影响？针对这一点，我想请各位嘉宾，特别是张晗老师谈谈您的看法。

张晗：

关于低精度的问题，首先从推理（Inference）侧来看，如果我们不涉及重新训练，仅看离线评测，其实很难发现明显的性能下降，因为我们在 Benchmark 上测试的各项指标通常能保持稳定。

至于为什么训练过程中会出现不稳定性，我认为这不完全是低精度本身的错，很大程度上与算法特性有关。精度带来的挑战不仅在于“低”，更在于精度不一致性（Precision Inconsistency），这种差异往往会导致严重的 Off-policy 问题。

核心矛盾在于：由于训练（Training）和推理（Inference）的负载（Workload）截然不同，为了追求极致的性能，两者在系统架构实现上往往存在取舍，这便引入了精度偏差。

目前社区已经关注到了这一痛点，并开始涌现出类似 Slime 这样致力于“训推精度对齐” 的工作。通过在框架层面拉齐训练与推理的精度表现，我们正在逐步解决这些问题。

因此我依然认为，循序渐进地降低精度以提升系统效率，绝对是一个极具前景的大方向。现在的重点不在于是否该用低精度，而在于如何通过系统手段，让低精度下的算法表现更加稳健。

主持人（万信逸）：

章明星老师，关于精度与算法收敛的博弈，您怎么看？

章明星：

我个人的感受是，高精度本质上是对系统各种缺陷的“容忍度”更高。我印象非常深，最早我们在 Kimi 训练第一个大模型时，光是折腾精度就耗费了巨大精力。早上一起来发现训练“炸了”，起初怀疑是 FP16 的问题，换成 BF16 后又出现了新状况。

后来我们发现，核心问题往往不在精度本身，而在于梯度裁剪（Clipping）、数据混合（Data Mixing）等细节。这就引出了一个关键逻辑：精度越高，系统对各类扰动的容错率就越高；

而一旦你想跑通低精度，就必须在其他环节打磨得更细。比如 Loss 的精细化控制、数据混合的配比，甚至需要引入课程学习（Curriculum Learning），避免模型一上来就接触过难的题目。

最近 Kimi 发布的 k1 (k-to-thinking)，我同事在外部分享时也提到过，它后端采用了原生的 INT4。这一方面是为了降低推理成本，另一方面我们发现，在 RL 阶段引入低精度带来的适度“噪声”，有时反而能让模型收敛得更好。前提是你在 Kimi 内部所说的“内核”逻辑要解释得足够透彻、打磨得足够精细，那么低精度是完全可以跑通的。

但 4-bit 是否就是极限？能不能再往下走？我目前也没有绝对的把握，未来的红利空间确实值得商榷。不过有一个特殊的场景值得关注，就是边缘侧（Edge Computing）。

如果大家关注 MSRA 的工作，会发现他们有一系列利用 LUT（查找表） 进行极低精度计算的研究，这能大幅降低能耗。虽然这种极低精度模型可能不是当前的 SOTA（最先进）大模型，但在端侧和边缘侧场景中，它依然具备巨大的发挥潜力。

主持人（万信逸）：

好的，感谢张老师。博涵老师，针对低精度这个话题，您有什么实战经验可以分享吗？

庄博涵：

我们在 LLM（大语言模型） 和 Diffusion（扩散模型） 上都分别尝试过 FP8 和 FP4。实验发现，LLM 对低精度的容忍度相对更高，因为它本质上是离散采样（Discrete Sampling）。

但 Diffusion 模型的情况完全不同，因为它处于 Continuous Space（连续空间）。在连续空间进行采样时，误差会随着步数不断累积。尤其是在计算 Reward 时，它是基于所有像素（Pixel）的全局计算，细微的精度损失在多轮 Propagation（传播） 后会被剧烈放大。

我们在 Diffusion 上尝试了例如 NVFP4 等精度，发现性能会掉 10 到 20 个点，生成的图像质量基本上无法接受。我们也尝试了多种修正手段，比如 Clipping（裁剪） 策略，发现其均值偏离依然非常严重。这种连续 Latent Space（潜空间） 下的误差累积问题，目前确实很难彻底解决。

相比之下，FP8（如现有的精度方案）表现尚可，具备一定的实用价值。但在性能提升上，它相对于 BF16 或 FP16 的实际提速往往只有 1.5 倍左右，还达不到理论上的最优加速比。

所以我的结论是：极低精度（如 FP4）在当前的技术条件下确实还存在很大问题，但也意味着它有巨大的探索空间。目前业内的核心共识是——确保“训推精度一致”。这对于维持 RL 训练的稳定性来说是至关重要的，甚至可以说是目前最优先要解决的事情。

主持人（万信逸）：

好的，感谢博涵老师。凯超，针对低精度带来的挑战，你有什么看法？

游凯超：

我感觉低精度对整个软件生态的挑战非常巨大，需要全链路的适配。虽然 NVIDIA 每一代新显卡发布时都会宣传算力又翻了几倍，但要真正吃掉这些算力红利，整个生态都要付出巨大的代价。

一个很典型的例子是：以前 BF16 或 FP16 是非量化的数据格式，一个 Tensor 就是一个完整的数据项。但到了 FP8，表示一个权重需要一个 Data Tensor 加上一个 Quantization Scale Tensor；

到了 NVFP4 甚至可能需要三个 Tensor。你原来的一份权重，现在被拆成了三份，而且为了遵循硬件底层的要求，还需要进行复杂的 Packing（位包装） 处理。

这导致软件层面的抽象变得极其复杂：

1、 元数据管理：你需要大量的 Metadata 来描述每一个 Tensor 的 Layout（布局）。
2、 算子适配难题：像 PyTorch 这样的框架，底层许多数据格式此前并未做深度适配。BF16 这种格式还可以直观地做加法运算，但 FP4 这种 Sub-byte（低于 1 字节） 的类型怎么直接运算？
3、 硬件对齐限制：PyTorch 处理的最小单位通常是一个 Byte（8位），但 FP4 必须将两个数据 Pack 在一起。而在寄存器层面，为了效率，你可能还需要将它们打包进 32 位或更宽的单位中。

这些硬件为了榨取低精度收益而设置的限制，最终全部上升到了软件层面，给开发者带来了巨大的心智负担和复杂度挑战。我们现在正处于一个学习期，需要去摸索那个平衡的边界——即如何既能获得显著的算力红利，又能在合理的复杂度内让这套系统真正跑起来。如果系统过于复杂，导致大家用不起来或到处是 Bug，那么低精度的意义也就大打折扣了。

主持人（万信逸）：

的确。子霖，你这边有什么想法吗？

朱子霖：

首先我想反驳一个观点。我觉得并不是 ML 社区喜欢低精度，而是硬件厂商喜欢低精度。因为硬件厂商做定点运算可以把硬件性能指标堆到最高，这样显卡才比较好卖。而 Infra 侧的同学或朋友喜欢低精度，更多是因为新硬件带来了新特性，大家就有新的工作可以做。

我个人的理解是，做系统的人其实并不觉得低精度好管。因为每多一种精度，整套训练范式（如前面张老师所说）可能都要重新调一遍。一旦训练出问题，大家永远会先怪罪精度，然后开始一点点找细节问题

。我们可能还是要看 Scaling 这件事到底有多重要。大家做低精度的初衷，是希望在单位数量的硬件上获得更多算力，从而训更大的模型或跑更长的实验。

如果最后发现，用 1000 张卡跑 FP4 的 1T 模型，效果还不如跑 BF16 的 200B 模型，那这件事可能就不那么重要了。所以这本质上是需要跟算法联合考虑的事情。

另外，前面张晗老师也提到，现在 RL 领域训练与推理的精度一致性问题让人非常头疼。我有一个纯个人的感觉，不确定在当年从模拟电路系统向数字电路系统转变的过程中，大家经历了怎样的变化。

现在听起来，我们就像是要把两个由模拟信号生成的系统，对齐成完全相同的输出；否则实验室的系统和最后给厂商、线上的系统，得到的效果就不一样。

如果能从前人的经验中学习到一些东西，也许随着精度变低或逐渐转向 INT（定点化），这反而是一个噪声逐渐降低的过程。当噪声降低到一定程度，很多关于精度对齐的问题也许就都解决了。

主持人（万信逸）：

朱力耕老师这边有什么见解？

朱力耕：

好的，关于低精度，我可以站在一个更长远的视角来谈谈。我接触深度学习相对较早，完整见证了行业从 Lua Torch 到早期 TensorFlow，再到如今 PyTorch 主导的过程。我完整看到了大家从 FP32 到 FP16，再到 BF16，直到现在迈向 FP8 的整个演进过程。

其实正如张老师所说，低精度训练“爆炸”的主要原因往往在于训练算法没有打磨好。回想社区当年从 FP32 向 FP16 推进时，大家也经历过类似的阵痛：训到一半 Loss 炸了，或者同样的任务高精度没问题、低精度直接“起飞”；或者高精度准确率很好，低精度一训就掉三四个点。

当时大家从 FP32 转 FP16，以及从 FP16 转 BF16 时都见过类似的情况。但随着训练算法逐渐稳定，大家不断修正训练配置（Training Config），这些问题最终都得到了解决。

因此，我认为 FP8 甚至 FP4 阶段的低精度收益依然会非常大。现阶段看到的 Loss Spike（损失尖峰）或准确率掉点，应该是短期的过渡性阵痛，长期来看肯定是可以解决的。

比起精度本身，我认为目前低精度给 RL Infra 带来的真正挑战在于**算子实现（Operator Implementation）**变得非常麻烦。

举个例子，现在大部分框架（如 NeMo-Aligner、veRL 等）理论上都支持了 FP8 的训练和推理（Rollout）。但大家发现，如果使用 FP8 且不开启 TE（Transformer Engine，此处可能指代相关精度缩放库）或相应的精度对齐技术，掉点依然显著。大家会担心：BF16 训练和推理不掉点，为什么 FP8 就不行？

一个本质原因是：训练时的 FP8 算子往往是 PyTorch 原生提供的，而推理算子可能是由 FlashInfer 或 Axon 社区提供的。训练库与推理库在算子实现上存在数值差异（Numerical Diff）。

在一些大厂内部，因为训练和推理库是在同一个大仓库（Repo）里由同一组人维护，他们会极力对齐所有算子的精度，所以精度问题会好很多。而开源社区的训练和推理往往由两拨人、两个团队在做，这种不一致性就被放大了。

所以，我觉得低精度本身不是系统不稳定的根源。相反，训练设置（Training Setting）没调好以及不同库之间算子精度没对齐，才是导致准确率不稳定的核心原因。

---

Co-design：
算法演进与硬件特性的双向奔赴

主持人（万信逸）：

的确，从历史角度看，从 FP32 一步步演进到今天，我们已经解决了一系列系统性的挑战。

现在我们过渡到下一个话题。ML 系统（MLC）处于算法与硬件的中间层：下游是算法同学的需求，上游是硬件厂商的特性。因此，MLC 必须对双向的发展都保持高度敏感。

站在 2025 年底 这个时间节点，我想请教各位：

• 从算法侧看：有哪些新的模型架构（例如：DeepSeek R1/V3 的多标记预测 MTP、原生多模态架构 Gemini 2.5/3，或是 Agentic AI 驱动的动态计算图）是我们需要重点关注的？
• 从硬件侧看：又出现了哪些足以改变 MLC 设计范式的特性？比如 NVIDIA 的 GB200 NVL72（72 卡机柜级大型机）带来的全机柜 NVLink 互联，甚至是 第五代 NVLink 支撑的“机柜即显卡”特性。

面对这些新变量，MLC 的设计需要做出哪些进化？我们先听听博涵老师的意见。

庄博涵：

好，我先从算法侧谈谈。现在的推理环节变得越来越重要，尤其是大家都在关注 Agent 场景。推理面临的主要挑战是：吞吐量（Throughput）相对好解决，但延迟（Latency）非常高。

我目前关注的一些工作主要是为了降低推理延迟，包括大小模型协作等。其中一个非常重要的方向是 Diffusion LM。它本质上也是一种并行采样，旨在一次生成多个 Token。之前像 DeepSeek V3，以及更早的 Medusa（美杜莎） 等，都是通过接多个预测头来实现并行采样。

但我认为，目前的 MTP（多 Token 预测） 等并行采样范式还存在本质问题。以 Diffusion LM 为例，它在 Scaling up 上面临巨大挑战。其底层逻辑在于：如果我的并行度是 2，理论上采样空间应该是 ​V \times V（词表大小的平方），即应该从一个联合分布中去采样；但现在的 Diffusion LM 采样空间往往只是 ​2 \times V，这会导致性能受限。

因此，我认为接下来如果能提出新的并行采样范式，在数学上实现接近 AR（自回归） 无损效果的并行化，再配合 SD（投机解码） 等技术，将极具价值。

另一个方向是稀疏模型，尤其是针对 Long Context 的 Sparse Attention（稀疏注意力），这会是未来的重要方向。我们可以看到大厂的趋势：之前大家探索过 Linear Attention 或混合 Attention，但最近似乎逐渐放弃了 Linear Attention 路线，转而收敛到 Sparse Attention。

这非常符合逻辑（Make sense），因为在 Agentic 场景中，任务通常是多轮的（Multi-turn），属于典型的长上下文。最理想的情况是把历史全部存下来，通过稀疏检索（Sparse Retrieval）来处理。现在的难点在于：如何在长文推理场景下，把稀疏注意力做到“不掉点”。

以 Gemini 3 为例，它在处理 OpenAI 的某个高难度 Benchmark 时（例如多重“大海捞针”测试，即从长文本中捞出多根“针”），精度也只有 20% 到 30%。这说明在稀疏注意力、长上下文以及 Agentic 场景的精度保持上，我们还有很长的路要走。

主持人（万信逸）：

凯超，从你的视角看呢？

游凯超：

我从推理框架的角度出发，还是更关心大家在 Attention 机制上的新进展。

大语言模型（LM）其实可以拆解为两部分：与状态（State）无关的部分，以及与上下文（Context）相关的部分。

• 状态无关部分：主要是 Feed-forward 层。目前无论是从 Dense 转向 MoE，还是现在的细粒度 MoE，系统侧已经有了比较成熟的解决方案，通过 EP（专家并行） 基本上就能较好地解决。
• 上下文相关部分：这一块主要就是 Attention，它对推理引擎的影响最大。因为涉及到上下文，我们需要专门设计 KV State 的管理策略。

从最早的 Full Attention 到 Sliding Window Attention（滑动窗口注意力），再到现在的 Linear Attention，算法侧的每一步演进都会对推理引擎产生巨大的冲击。

除此之外，多模态模型中是否引入 Cross Attention（交叉注意力），也是我们关注的重点。对推理框架来说，这类架构层面的改动往往是最“痛”的，需要投入大量的工程精力去适配。

主持人（万信逸）：

你觉得有什么有意思的硬件特性是需要社区关心的吗？

游凯超：

硬件特性方面，这几年最重要的肯定还是 Tensor Core 的演进，它的算力增长极快。

随之而来的挑战是：你的模型该如何设计，才能充分利用上 Tensor Core 的性能？因为显卡标注的峰值 FLOPs 通常是基于特定的最大 Shape（形状）测得的。如果你的模型在计算时用的 Shape 比较小，导致无法对齐硬件的计算单元，那你实际能享受到的算力就会大打折扣。

所以，很多时候我们感觉像是在“给老黄（黄仁勋）打工”——他把硬件设计成什么样，我们的推理框架就得去硬碰硬地适配，甚至连算法模型的设计都要为了迎合硬件特性而做出妥协。

主持人（万信逸）：

好的，子霖这边有什么想法吗？

朱子霖：

我觉得首先从 RL（强化学习） 的角度来看，目前做端到端的复杂系统 RL 依然面临很大挑战。客观来说，整个社区——或者说国内目前在这一块离 OpenAI 或 Gemini 的水平可能还存在一定距离。这不仅仅是靠我们做 Infra 的人努力就能解决的，更需要算法侧老师们的突破，我们希望能配合算法逐渐追上去。

另外一点，就是前面提到的 Diffusion 类 RL。今年大家应该都感受到了 Nano Banana 这整套系统的强悍。站在训练系统开发者的角度，我非常希望有一天，无论是开源界还是公司内部，也能跑通并训练出这样强有力的系统。我也非常希望能深入理解这类系统在训练侧对 Infra 究竟有哪些具体的需求。这些是我目前比较感兴趣的方向。

主持人（万信逸）：

好的，力耕老师。在算法和硬件的结合趋势上，您觉得有哪些点是值得我们深入关注的？

朱力耕：

好的。站在算法和硬件的趋势交汇点，我觉得可以重点关注一下推理侧的新硬件特性。

回想 2022 到 2024 年，大显存几乎是高端计算卡的“特权”。如果你想要 80GB 的显存，除了寻找一些非正规渠道，NVIDIA A100 几乎是唯一的选择。但到了今年，情况发生了很大变化：

• 高端桌机/开发端：NVIDIA 推出了像 DGX Spark（基于 Grace Blackwell GB10）这样的产品，它拥有 coherent 统一系统显存，让开发者能在桌边就跑起 70B 甚至更大的模型。
• 友商竞争：AMD 的 MI300/MI350 系列（如 MI325X 等）提供了巨大的 HBM 显存容量；而 Apple 的 M4 Ultra 等芯片通过统一内存架构（UMA），能以相对便宜的价格让用户在本地单机上获得数百 GB 的显存。

这种“大显存平民化”的趋势，对推理侧意义重大。现在的行业共识是“Model size is Intelligence”（模型规模即智能），大家对模型参数的需求依然旺盛。以前在单机上部署 DeepSeek-V3 (671B) 这种量级的模型几乎不可想象，但现在推理框架正在合力解决这个问题。

对于未来，我认为云端和边缘端（Edge）的技术路径会正式分裂：

• 云端（Cloud）：会完全收敛到 High-end GPU + PD 分离（Prefill-Decode Disaggregation） 的范式。通过物理隔离预填充和解码阶段，配合 EP（专家并行），形成一套极其复杂且极致优化的推理 Infra。
• 边缘端（Edge）：会基于完全不同的 Hardware + Infra Setting。利用统一显存技术，在资源受限的情况下通过更灵活的显存管理来跑大模型。

这种云与端的演化差异非常值得关注，以后这可能是两条完全不同的技术护城河。

主持人（万信逸）：

好的。那张晗老师，关于算法和架构这一侧，你有什么观察？

张晗：

我觉得在新兴算法和模型架构这一块，目前开源界还没有看到特别令人惊艳（Promising）的突破，但我们可以从 Google 近期发布的信息中捕捉到一些趋势。

最值得关注的是 Attention（注意力机制） 的演进。以 Gemma 3 为例，它引入了一种 5:1 的交错式注意力（Interleaved Attention） 架构。

• Local Attention（局部注意力）：在大部分层级使用滑动窗口注意力，窗口大小通常只有 1024。
• Global Attention（全局注意力）：每 5 层局部层后插入 1 层全局层。 这种设计显著降低了 KV Cache 的内存占用，让模型在保持长上下文能力的同时，推理效率大幅提升。我觉得这可能就是 Gemini 3 能在推理侧做到极速响应的技术底座之一。

另一个确定的方向是原生多模态（Native Multimodal）。Gemini 3 的核心不再是简单的“插件式”多模态（即挂载一个 Frozen 的 Vision Encoder），而是走向了统一嵌入空间（Unified Embedding Space）。

我猜想，未来的技术高地在于 Cross Attention（交叉注意力） 的深层优化。

• 高维融合：如何将图片、视频这种稠密的、高维度的 Embedding，与文字这种稀疏的 Embedding 进行高效的低维融合。
• 特征解耦：在处理跨模态信息时，模型如何通过注意力机制精确对齐不同模态的特征。

这种原生多模态的 Cross Attention Recipe，正是目前开源框架（如我们现在使用的那些框架）最缺少的东西。如何把多模态融合做得既不掉点（保持推理能力），又能兼顾极速推理，我觉得 2026 年会有更多机会出现在这个方向上。

---

2026 风向预测：
脱离“古法编程”与空间智能

主持人（万信逸）：

好的。2025 年我们经历了推理侧和 RL 的精彩爆发。站在现在的节点，大家预测一下，2026 年技术发展的风向标或者核心主题会是什么？博涵老师，您怎么看？

庄博涵：

我觉得可以从任务、数据和系统三个维度来看：

1、任务维度：从多模态走向“All-in-One”统一模型

2026 年的主旋律一定是 Unified Model（统一模型）。

• 全模态融合：我们要解决如何将音频、文字、视频和图像真正地 Unified 在一起，实现真正的 All-in-One。
• 具身与空间智能（Spatial Intelligence）：在具身智能或自动驾驶场景下，重点在于 VLA（Vision-Language-Action） 模型与 World Model（世界模型） 的深度融合。
• 能力整合：一个成熟的范式需要整合三种核心能力：感知能力、理解/推理能力（Reasoning） 以及 预测/生成能力。如何在一个架构下把这些能力无损地整合在一起，仍有巨大的探索空间。

2、数据维度：高质量合成数据的系统化

Synthetic Data Generation（合成数据生成） 将成为核心。例如，利用 World Model 批量合成高质量的物理世界交互数据，再喂给 VLA 模型进行强化学习。这套“模型生产数据，数据哺育模型”的闭环将是 2026 年提升模型上限的关键。

3、系统与底座：从 Triton 走向 Tile-based 编程

在 Infra 层面，我预感 Tile-based Kernel Programming（基于分块的内核编程）会逐渐成为主流并替代一部分现有的 DSL（如 Triton）。大家会更深入地在底层针对硬件特性进行高性能 Kernel 开发。

此外，Diffusion RL 的算法与训练框架将成为“刚需”。随着具身智能和视频生成任务的火爆，如何对连续空间的扩散模型进行强化学习对齐，是社区急需攻克的难关。

主持人（万信逸）：

的确，多模态（Multimodal）领域的未来非常有想象力。子霖老师，关于 2026 年的主题，你怎么看？

朱子霖：

我这边的视角可能比较特别。最近我关注到最有趣的一件事，是前天 Capability（推特大 V 或相关账号）发的一条推文，他感叹近两个月模型的代码编写能力有了质的飞跃。

我认为 2026 年对于 Infra 领域最重要的一件事，就是如何“脱离古法编程”。

在 Slime 中，很多 Debug 工作或新特性的原型开发，如果交给 Agent System（智能体系统）去写，其效率已经远远超过了纯人工编写。

因此，在整个 Infra 的研发流程中，我们应该通过 AI 辅助来处理那些繁琐的“脏活累活”，让工程师能够把精力真正集中在架构设计和核心逻辑上。我觉得这会是让整个行业生产力产生质变的关键点。

另外，作为框架的维护者，我依然会高度关注 RL（强化学习）框架的训练稳定性。随着系统变得越来越复杂，我们如何定义稳定性？如何通过工程手段去量化并维护这种稳定性？这依然是我们需要攻克的硬骨头。

主持人（万信逸）：

好的，感谢。力耕老师，你这边对 2026 年有什么预判？

朱力耕：

我非常同意子霖说的，2026 年的一个核心趋势就是逐渐脱离“古法编程”。

大家会以更开放的心态去使用 Cursor、GitHub Copilot 之类的工具。这不仅是口头说说，它确实极大地提升了个人产出。以我负责的项目为例：在 2024 年，我平均每周提 7 个左右的 PR（Pull Request）；

但最近两个月，开始深度使用 Cursor 和 Copilot（尤其是它在云端运行的 Sandbox 功能）后，我每周能产出 40 多个 PR。而且代码质量和注释的详细程度，比我以前手写的要好得多。这种开发迭代效率完全不在一个量级，它将彻底改变我们的研发模式。

另一方面，关于未来的 Research 方向，我一直在思考学术界与工业界之间的鸿沟。工业界需要学术界带来新鲜血液和创新思考，也需要一些轻量级的 Platform 帮助快速试错。但现实是，大模型的门槛越来越高，很多同学因为缺乏算力资源（卡），能做的事情非常有限。

因此，对于 2026 年新入行的同学，我建议可以从推理框架或算子层切入。这块对资源的需求相对较小，且大有可为：

• 训推一体化算子：过去训练算子（ISA for Training）和推理算子（ISA for Inference）是完全分开的两个领域。但随着 RL 的兴起，我们需要能兼顾两边性能且精度对齐的算子。
• 算子调优自动化：比如 Tile Size（分块大小）写得不一样，训推精度就可能对不齐。如何搜索出最合适的参数（Parameter）、实现高效的 Cache Reuse（缓存复用）或 Tiling Strategy（分块策略），从而在特定的训推比（如 3:7）下实现最优的整体性能？

这在目前的算子库开发中是非常前沿且实用的工作，非常适合资源有限但想深入底层的同学。

主持人（万信逸）：

我非常认同你讲的两点。首先是 Auto-coding，我个人也在用，它对我的产出效率提升了至少两三倍。而且它写的代码质量很高，能规避很多由于人类粗心导致的低级错误。

另外一点也是我一直想探讨的：工业界的模型规模越来越大。我甚至听过一种夸张的说法，认为 DeepSeek-V3（671B）只是个“小模型”，因为有些 MoE 模型已经向 1T（万亿） 参数迈进了。

反观学术界，很多研究 RL 的同学大部分还在 Qwen-Distill 1.5B 上做实验。这中间存在近千倍的参数量差距。力耕老师，你觉得学术界的 Scale 已经明显跟不上工业界了吗？这种资源不对等会导致什么问题？

朱力耕：

这是一个避不开的现实。在学术界，没有卡确实跑不动 600B 甚至 1T 的模型。这甚至不是一个选择题，而是一个必答题。如果你真的想跑 1T 的模型，最合理的办法就是找工业界的大组合作。

但我认为现在真正值得思考的问题是：在有限资源下，我们做哪些事情是具备“可迁移性”（Transferable）和“可扩展性”（Scalable）的？

说实话，全世界能有资格管 671B 叫“小模型”的人，可能也就那一百来号人。因为即便是目前最顶尖的 SOTA 模型，也没有比 671B 大出一个数量级。所以，学术界的工作重点应该放在那些能被 Scale 到大尺寸模型上的核心技术上：

1、 底层算子优化：无论你是在训练 125M、1.5B 还是 671B 的模型，底层的算子实现是一样的。无非是 Batch Size 或显存维度扩大了。如果你在小模型上验证了一套更高效的算子或实验方式，这种经验是完全可以 Transfer（迁移）到大模型上的。
2、 范式（Paradigm）研究：比如最早的 LLaVA 如何将文本模型转化为多模态模型，或者现在的 Diffusion LM。这些方法论的研究，在 1.5B 上做和在 1T 上做，其底层逻辑没有本质区别。一旦在学术界跑通，工业界可以直接接过你的成果进行 Scale up。

相反，有些工作在学术界做的意义就不大。比如通过 Distill（蒸馏） 某些 SOTA 模型的数据，造个新 Benchmark，然后在上面提个一两点。随着工业界下一代基座模型的提升，这种提升会变得非常 Marginal（微乎其微）。
所
以，学术界虽然资源受限，但不代表受阻。只要专注于那些真正有价值、可迁移、可扩展的底层逻辑或新范式，即便在有限的选择面里，依然能做出具有深远影响力的工作。

主持人（万信逸）：

感谢力耕老师的建议。张晗老师，关于未来的风向，你有什么补充？

张晗：

我非常认同子霖、力耕和博涵老师的看法。我先分享一个自己的例子：往年我在 GitHub 上的 Commits 大约也就两三百个，但今年仅两个月就冲到了一千多。原因是我在“十一”期间利用 AI 工具，三天就提了七八百个 Commits。

这让我意识到，效率提升已经不只是工具层面的改变了。我现在更关心的是更上层的 AI Infra。如果说 Claude Code、各种 SDK 是基础，那么再往上，能让 AI 自动完成、自主激发的东西还有很多。

我个人的核心观点在今年 9 月发生了转变：以前我做的是面向开发者（Researcher）的 RL Infra；但到了 2026 年，未来的 Infra 将更倾向于面向 AI 本身。也就是说，AI 会在你的 Infra 里面自主完成更多任务。我目前关注的重点已经上移到了 Runtime（运行时） 层的 Infra。

为什么这么说？

1、 开源能力的快速追赶：Google 的 Gemini 效果极强，Nano Banana 的出现也证明了从效果图到真实产品的转化速度。假设闭源模型领先开源界 6 个月，到 2026 年，会有大量开源模型通过学习这些 Trace（轨迹数据）达到近似的效果。
2、 生态范式的转移：当每个人都能通过 AI 自主交付代码时，生态会发生巨大的 Shift。我们不再关心程序员如何写代码，而是关心 AI 的 Tool Call、Skills（比如它的 Notebook 操作能力）。AI 不仅在自我进化，还在为自己制造工具。

我预期 2026 年会迎来应用层的爆发。头部公司会通过积累的大量 Trace 去分析：哪些用户的 Tool、哪些运行环境最具经济价值？然后针对性地优化。

所以我最期待的，是那种能让非专业人士实现 Hands-off（甩手掌柜）的 AI Infra。为了实现 AI 接管所有工作，我们需要提供：

• 更强的 Runtime 管理 与 Sandboxing（沙箱技术）。
• 更智能的数据库支持（现在的 Supabase 够用吗？可能需要更原生的支持）。
• 全周期的 Context（上下文）管理：不仅是解决一个 PR，而是关注从设计（Design）到测试的整个产品生命周期。

另一个方向是 AI for Science。随着投资热点向技术研究倾斜，Infra 在科研自动化中将扮演关键角色。因为传统的科学研究极度缺乏能支持 AI 闭环的 Environment。

最后我想说，虽然 2026 年的机会极其繁多，但一个好消息是：技术路线正在收敛。比如 veRL 和 vLLM 等框架，大家优化的方向正在相互贴近。我们在底层基建上达成了一致，这对于托举上层应用层的爆发——从解决单一 Task 进化到交付整个 Product——将产生巨大的助力。

主持人（万信逸）：

好的，那今天我们的 AI Infra 专题 就到这里。

非常感谢今天五位嘉宾带来的深度分享，从 FP8 精度对齐、PD 分离架构，一直聊到了 2026 年面向 AI 本身的运行时基建。这些洞察对我们理解未来一年的技术演进非常有价值。

再次感谢各位嘉宾，也感谢直播间观众们的陪伴！