如何分层学习推理 Infra：从 CUDA 基线到昇腾，再到训练与 RL

整理日期：2026-09-14（晚间增量）。依据当天新增问题、可见对话摘录与一手资料整理，不是完整逐字稿。教学推导与用户反馈分别注明，未执行服务器操作。

今天的困惑

你感到推理 Infra 已经很复杂，叠加昇腾后需要同时处理模型、量化、缓存、并行、网络和版本；因此考虑先在 CUDA 生态建立理解，再回到昇腾，并问训练、RL、数据库与浏览器是否也有类似复杂度。

复杂度不能用客观总分排名

没有统一公认的“软件复杂度排行榜”。可比较的维度包括：组件数量、状态空间、性能约束、正确性验证、故障恢复和跨团队依赖。具体项目规模、成熟度与需求决定难度。

数据库强调事务、持久化和故障恢复；浏览器强调协议、渲染、语言运行时及兼容性；训练系统增加梯度、优化器、检查点和集体通信；在线推理强调动态请求、缓存和尾延迟。这是工程维度比较，不是量化评分。

RL Infra 为什么会再增加一层

LLM RL 将生成 rollout、奖励或验证、训练更新与权重同步串成闭环。既有推理侧的变长生成与吞吐问题，也有训练侧的内存和并行问题；异步方式还需处理策略版本、数据新鲜度与背压。

这些困难依配置而定，不能宣称任意 RL 系统一定比任意数据库难。verl HybridFlow 指南

CUDA 是否没有耦合

CUDA 同样有驱动、运行时、框架、编译工具和扩展 ABI 的配套约束。NVIDIA 提供一定范围的兼容机制，但有驱动最低要求、平台及功能限制。CUDA Compatibility

pip 安装把许多依赖解析和二进制分发封装起来；大 Docker 镜像可能同时包含开发工具、框架和多层依赖。镜像 20 多 GB 是你观察到的现象，不等于运行时 HBM 占用，也不能单独证明执行效率低。

适合当前目标的递进路线

第一步：固定小模型，解释 tokenizer、prefill、decode、KV 生命周期和 TTFT/TPOT。

第二步：做同一模型的浮点与量化比较，学会 scale、KV dtype 和正确性验证。

第三步：理解 GQA、MLA、DSA、KDA 的状态表示，再读相应后端缓存布局。

第四步：在多卡上分别验证 TP、DP/EP；然后才组合 PD、池化和特定 DCP。

第五步：带着同一份基线与指标迁移到昇腾，逐层比较而非同时打开全部开关。

若有 CUDA 资源，可用它降低首次理解概念的环境成本；若没有，也可在现有昇腾小模型上完成前两步，不必把学习推迟到换平台之后。

专家能力的可检验目标

拿到一个慢或精度异常的部署，能明确描述状态、画出数据移动、构造对照实验，并把问题归到模型、内核、调度、通信或环境某一层。先形成这种定位能力，再扩展到训练和 RL，比一次性掌握所有组件更可执行。

2026-09-16 补充：推理、训练、RL 不是简单的严格超集关系

推理、训练、RL 共享大量底层能力，但它们的核心状态对象和优化目标不同，因此更适合看成三个重叠但不完全包含的系统域。

推理 Infra 的独特核心

推理主要围绕 forward 与在线 serving：

Continuous batching、request scheduling、SLO；
KV Cache、PagedAttention、Prefix Cache；
TTFT / TPOT / tail latency；
speculative decoding；
PD 分离、KV transfer、DCP；
低延迟量化 kernel 与 graph capture。

这里的核心状态往往是 weights + KV Cache + request state。

训练 Infra 新增的状态与并行问题

训练不是“推理再加 backward”这么简单。Backward 会引入一整套新的状态与通信：

activations；
gradients；
optimizer states；
parameter/gradient sharding；
activation checkpointing / recomputation；
FSDP / ZeRO；
Pipeline Parallel 与 micro-batch scheduling；
gradient AllReduce / ReduceScatter；
parameter AllGather；
compute-communication overlap；
distributed checkpoint。

因此训练内存问题的中心从推理中的 KV Cache，转向 parameters + activations + gradients + optimizer states。

RL Infra 为什么更像“系统组合体”

大模型 RL 通常同时存在：

Rollout / Inference
        ↓
Reward / Verifier
        ↓
Training
        ↓
Weight Sync
        ↓
New Rollout

所以它复用推理与训练两边的能力，同时新增：

rollout/train colocated 或 disaggregated placement；
actor/ref/critic/reward 等角色编排；
weight synchronization / resharding；
policy staleness；
asynchronous pipeline 与 backpressure；
trajectory / replay 数据流；
Agent 场景下的 environment、browser、tool latency 与长尾调度。

因此从系统维度数量看，Agentic RL 往往会比单纯 inference 暴露更多耦合变量；但不能据此断言任意 RL 项目一定比任意训练或数据库系统复杂。

学习时应该看到“复用关系”，而不是不断开新课程

从推理进入训练、RL，并不是从零重学：

GPU/NPU / Network / Distributed Fundamentals
                    ↓
              LLM Forward
                    ↓
            Inference Runtime
                    ↓
       + Backward / Optimizer / State
                    ↓
            Training Runtime
                    ↓
      + Rollout / Weight Sync / Async
                    ↓
               RL Runtime

你现在学的 TP、EP、Attention、MoE、CUDA/Ascend、NCCL/HCCL、collective、topology、communication overlap 在训练和 RL 中仍然会继续复用。

真正新增的主要知识块可以压缩成：

从推理到训练：Backward + model-state memory + training parallelism；
从训练到 RL：Inference/Training composition + rollout + weight sync + async scheduling。

硬件学习边界：双主线而不是五个平台并行学习

当前更合理的硬件路线是：

CUDA：深入。 用它学习最成熟的 accelerator programming model、kernel、memory hierarchy、graph 和 collective；
Ascend：深入。 结合 CANN、HCCL、vLLM Ascend，并按问题下钻 AscendC；
ROCm：学习 CUDA/HIP 差异和后端设计，不另开完整专家路线；
XPU：掌握 torch.xpu、XCCL 与 vLLM backend 的架构映射即可；
CPU：NUMA、cache、SIMD、memory bandwidth 等系统基础要懂，但暂不需要专攻 vLLM CPU kernel。

这种结构的目标不是会五套 API，而是能围绕同一个问题，例如 Decode Attention，从算法一路追到 Runtime、通信和 CUDA/Ascend kernel，再用 ROCm/XPU 作为对照理解 abstraction boundary。

进一步阅读：

2026-09-22—23 深化：把概念树变成能验收的研究路线

近期连续问题显示需要加强的连接是：数学与shape→存储与数据流→算子正确性→性能证据→多卡通信→在线服务SLO。以下是本次整理建议，不代表已有项目完成。

四段递进项目

第一段：同一Add/Gather/Reduce在CUDA与Ascend各做一份参考与设备实现，写出尾块、对齐、dtype和误差测试。验收是能解释失败样例并复现，而不是只记API名。

第二段：固定GEMM或RMSNorm，比较单缓冲、双缓冲、融合及不同tile；报告内存账本、时间线和相同条件下的收益。再把优化接到真实模型确认占比。

第三段：从AllGather/AllReduce微基准到TP/EP，再到PD与KV传输。验收包含rank映射、拓扑、消息大小、正确性与并发曲线。

第四段：以一个可重现瓶颈形成研究问题，提出机制、强基线、消融和适用边界。开源补丁与论文可以共享实验资产，但论文需要新颖性和证据，不能用代码量代替；本次不承诺专利授权或论文接收。

一年内可用前2个月补基线、3—5个月做跨硬件kernel、6—8个月做通信/服务系统、9—12个月集中一项研究作为候选节奏；按验收结果调整，不要求把所有工具都学完才实践。

HPC与AI Infra的连接

两者共享并行计算、内存层级、通信、数值误差和测量方法。在线推理另有变长请求、KV状态、排队和SLO；HPC并不只是“更大的AI集群”。竞赛可练固定预算下的系统调优与团队复现，但不能以竞赛成绩直接代表生产服务可靠性。

知识地图的节点与边

你明确要求图形结构、连线、可展开、可继续细化。每节点记录：定义、前置知识、典型问题、实验、证据和Notion文章；边区分“依赖”“实现于”“优化”“对照”，不要把所有联系都强行变父子层级。

“已掌握”由你确认或依据验收，不因生成一篇说明便自动点亮。算子题库和WebGPU练习可以验证部分索引/并行思想，不能据此声称复现CUDA/NPU的特定指令性能。本次整理未修改Sites页面或学习状态。

阅读顺序：CUDA 与昇腾数据流对照：存储层级、分块与异步流水 → Ascend C 调试复盘：UB 容量账本、数据类型转换与最小复现 → 从 AllReduce 到通算融合：语义、流水、资源竞争与优化验收 → 本库并行与PD实战。

2026-10-07 路线优化：把成长手册落实为一个主项目

本次已读取10月4日《AI_Infra_成长行动手册_2026-10.md》全文。它是此前生成的执行规划，不是你已经完成的成果。本节细化执行方式；前文时间安排仍为候选，实际优先级以验收与资源为准。

当前主线：推理系统＋性能分析，第一专长围绕已有投机解码/异步后处理/运行时调度。CUDA与Ascend按同一个问题做对照，避免同时各开多个项目；训练/RL在核心推理案例形成证据后扩展。

每周约10小时只是手册预算假设，不是已确认投入。若资源不足，延长阶段或做CPU正确性/源码与成本推导，设备性能保留待测，不用模拟结果填空。

前十二周的验收链

第1—4周：环境/能力诊断 → Add索引与尾块 → Reduction或RMSNorm → GEMM复用和Roofline；每周一个正确实现或可解释对照。

第5—8周：stream/event依赖 → eager/graph适用边界 → KV参考对齐 → 固定版本请求生命周期追踪。

第9—12周：负载基线 → 两个代表trace → 现有MTP/异步工作单变量消融 → 可复现报告与新负载反例。

没有完成前置验收就延长，不按日期自动进入下一阶段。题库/阅读完成和知识图节点点亮不是独立能力证据。

闭卷回忆替代只收藏材料

先独立预测，再借助AI查证或审查；关闭答案，在新shape/负载上解释。每周记录问题、预测、配置、结果、解释、反例、证据和一个下一步。解释明确标实测/官方机制/教学推导/待验证。

个人成果至少有：正确性案例、性能案例、方案取舍案例。主项目先锁一个模型、一种后端和一条关键路径；负结果也可成为边界报告。

建议阅读顺序：数据流 → GEMM、Triton 与 TileLang：从分块代码到 Roofline 性能账本 → 本库量化与MTP → 并行/PD → 从 CP 到预训练系统：并行切分、状态账本与可恢复训练 → verl。职业与项目证据的对应关系见推理框架求职复盘：从昇腾适配到可验证的系统能力。

长期专家目标用原创问题、严谨验证、可维护实现和独立采用评估，不承诺一两年达到“世界级”。训练中断恢复和RL质量/成本闭环是后续验收，不把所有框架并列为现在必修。