新增: DeepSeek 全部 33 篇官方论文(原文 PDF 走 Git LFS + 中文精读笔记与索引)

2026-09-20 17:11:49 +08:00
parent f600fa5871
commit 14c280ffee
187 changed files with 94947 additions and 0 deletions
@@ -0,0 +1,119 @@
+# 萤火 AI-HPC：面向深度学习的低成本软硬件协同设计
+
+> **原文标题**：Fire-Flyer AI-HPC: A Cost-Effective Software-Hardware Co-Design for Deep Learning
+> **arXiv**：[2408.14158](https://arxiv.org/abs/2408.14158) ｜ **发布**：26 Aug 2024（v1），31 Aug 2024（v2）
+> **作者/机构**：Wei An 等（按姓氏字母序排列），DeepSeek-AI（深度求索，北京）与 High-Flyer Quant
+> **原文 PDF**：[01-Fire-Flyer-AI-HPC-2408.14158.pdf](./01-Fire-Flyer-AI-HPC-2408.14158.pdf)
+
+## 一、摘要（全文翻译）
+
+深度学习（Deep Learning, DL）与大语言模型（Large Language Model, LLM）的快速进步，使人们对算力与带宽的需求呈指数级增长。这一趋势与更快的计算芯片和互连技术的高昂成本叠加，显著推高了高性能计算（High Performance Computing, HPC）的建设成本。为应对这些挑战，我们提出萤火 AI-HPC（Fire-Flyer AI-HPC）架构——一套软硬件协同设计（hardware-software co-design）框架及其最佳实践。在深度学习训练方面，我们部署了拥有 10,000 块 PCIe A100 GPU 的 Fire-Flyer 2，其性能接近 DGX-A100，同时将成本降低一半、能耗降低 40%。我们专门设计了 HFReduce 来加速 allreduce 通信，并实施了大量措施以保持「计算-存储一体化网络」无拥塞。通过包括 HaiScale、3FS 和 HAI-Platform 在内的软件栈，我们借助计算与通信的重叠（overlap）实现了良好的可扩展性。我们在深度学习训练中积累的这类面向系统的经验，为未来 AI-HPC 的发展提供了有价值的洞见。
+
+## 二、核心贡献
+
+1. **以 PCIe A100 替代 SXM 的整集群架构与成本模型**：用 10,000 块 PCIe A100 组成 Fire-Flyer 2，在 TF32/FP16 GEMM 达 DGX-A100 约 83% 性能下，把节点价格压到 60%、功耗从 4200W 降到 2500W，性价比达 1.38，全集群仅需 122 台交换机。
+2. **HFReduce：把 allreduce 的规约计算从 GPU 搬到 CPU**：CPU 向量指令做节点内规约、Double Binary Tree + ibverbs RDMA 做节点间 allreduce，每单位数据只消耗 1 单位 PCIe 双向带宽，且不占用 GPU kernel；186 MiB 数据下节点间带宽 6.3–8.1 GB/s。
+3. **HaiScale：面向 PCIe 拓扑的并行训练优化**：DDP 异步 allreduce 与反向计算重叠、按 DP rank 错开 PP 时序、FSDP 通信-计算重叠，实现 88%（VGG16）、91%（LLaMa-13B）、95%（GPT2-medium）的并行可扩展性，训练时间比同等 PyTorch 实现缩短近一半。
+4. **存算一体网络的无拥塞工程实践**：用 IB SL→VL 隔离 HFReduce／NCCL／3FS／其他四类流量，改用静态路由，NCCL 走同 NUMA 节点的网卡与 GPU，3FS 引入 request-to-send 控制；并**关闭 DCQCN**，在不做拥塞控制下保持网络无拥塞。
+5. **3FS 与 HAI Platform 组成的生产级软件栈**：180 个存储节点、2880 块 NVMe SSD、超过 20PiB 容量，实测读吞吐 8TB/s；配合秒级 checkpoint 与周度巡检，支撑 99% 利用率。
+6. **真实故障画像与下一代架构**：公开一年生产集群故障统计（Xid74 占 42.57%、Xid43 占 33.48%、IB 链路闪断占其余故障的 30%），并提出面向 MoE 训练、1:1 GPU/NIC 配比、多平面 Fat-Tree + RoCE 的下一代架构。
+
+## 三、方法与技术要点
+
+### 3.1 节点架构：为什么选 PCIe
+
+依据是模型规模分布：ResNet、BERT、MAE 等参数量均小于 1B，显存需求不高，故 2021 年建设以深度学习为主的集群时 PCIe A100 已足够。节点为 2×AMD 32 核 EPYC Rome/Milan、512GB 16 通道 DDR4-3200、8×PCIe-A100-40GB、1×CX6 200Gbps IB 网卡。要点：不用 PCIe Switch，8 块 GPU 与网卡直连 CPU，网卡独占一个 Root Complex，避免与 GPU 争抢根端口带宽；预留 NVLink Bridge 位置，LLM 到来后确在两两卡间加装（600 GB/s）；实测 8 块 A100 的存储 IO 与通信带宽可由单块 200Gbps 网卡满足，这也是后文 PP 带宽竞争的根源。
+
+### 3.2 网络拓扑：双区两层 Fat-Tree 与存算一体
+
+选 Fat-Tree 而非 Dragonfly，因前者对分带宽极高，后者不足；实施时 RoCE 尚不成熟，故选 IB（QM8700，40 端口 × 200Gbps）。降本核心是**用两个两层 Fat-Tree 代替一个三层 Fat-Tree**：每区 800 端口，接入约 600 个计算节点；存储服务器各配两块 IB 网卡分接两区，使全部计算节点共享同一套存储；两区只用少量链路互连，并由 HAI Platform 保证跨区任务至多一个。这样即便用 NCCL 或 HFReduce（均可用双二叉树算法跨区），全集群任务只需一对节点跨区通信，仍能跑满 10,000 GPU。
+
+### 3.3 HFReduce：网络中的软硬件协同
+
+HFReduce 的核心策略是「**先节点内规约，再对各节点归并后的数据做节点间 allreduce**」，共三步：
+
+1. **节点内规约（Algorithm 1）**：按 `Chunk_Size` 切分梯度，异步 D2H 搬入 CPU 内存（小数据用 GDRCopy，大数据用 MemCpyAsync），再用 **CPU 向量（SIMD）指令**做 reduction add，支持 FP32/FP16/BF16/FP8。
+2. **节点间规约（Algorithm 2）**：用 **Double Binary Tree** 两趟（Pass 1 规约、Pass 2 收集广播）完成节点间 allreduce，传输基于 ibverbs RDMA Write。
+3. **H2D 回写**：CPU 把梯度经 PCIe 写回 GPU；用 GDRCopy 向同一 NUMA 节点内 4 块 GPU 写数据，因其可把 host 数据暂存于 CPU cache，使 host 内存读取相比 MemCpyAsync 降至 1/3。
+
+**为什么能超过 NCCL**：设 GPU 总数为 $n$，NCCL ring 下每单位数据需 $2n-1$ 次传输，消耗 $\frac{2n-1}{n}$ 单位 PCIe 双向带宽；HFReduce 只需一次 D2H 加一次 H2D，即 **1 单位**。本机器上 NCCL 主要受 PCIe 带宽限制，故 HFReduce 占优。此外 HFReduce 借 GPU 的 **Copy Engine（CE）** 做异步传输，不执行 GPU kernel，故不干扰其他 kernel。根因上，作者确认 EPYC Rome **不支持 chained write**（该特性可大幅加速 GPU↔IB 网卡的 PCIe P2P 传输），Rome 上二者最大带宽约 9 GiB/s，这解释了 NCCL 仅 4GB/s。
+
+**HFReduce 自身的瓶颈**：单节点内存操作量合计约 **24 倍**于 GPU 上原始数据量：D2H 8 次写、节点内规约 8 读 1 写、节点间 allreduce（IB 发送 2 读、接收 2 写与 1 次 reduce-add 读）、H2D（GDRCopy 2 读，MemCopy 8 读）。16 通道 DDR4-3200 实测访存约 320GB/s，理论上限约 13.3GB/s，扣除算法与网络开销后约 12GB/s，实测仅略超 8GB/s。原因是另一处 EPYC 限制：GPU5/GPU6 共享同一 Root Complex Port，Rome/Milan 上根端口到 CPU 内部总线最大带宽约 37.5GB/s，两块 GPU 并发即受限；论文指出 Genoa 仍有此问题。**HFReduce with NVLink** 即用于缓解该受限：先在 NVLink 互连的 GPU 对间规约再交给 CPU，CPU 返回时把结果切分送回成对 GPU，再经 NVLink 做 allgather，使节点间带宽超过 10 GB/s。
+
+### 3.4 HaiScale：并行训练优化
+
+HaiScale 定位类似 Megatron 与 DeepSpeed，针对 PCIe 架构优化 DP/PP/TP/EP：**DDP 重叠**——以 HFReduce 替代 NCCL，在反向传播中对已算出的梯度做异步 allreduce，因 HFReduce 不占用 SM，该通信可与反向计算完全重叠；**PP 带宽竞争**——单节点 8 卡只有一块网卡，故让 8 卡分属不同 DP rank，**错开各 rank 的 PP 时序**、拉开通信峰值；**TP** 借 NVLink Bridge 的 600GB/s 卡间带宽提升效率；**FSDP** 同属 ZeRO Stage-3，但改良显存管理，并把 allgather 与 reduce-scatter 与前后向计算重叠、把优化器更新切分进反向传播。
+
+### 3.5 网络无拥塞工程与 3FS
+
+流量分为 HFReduce、NCCL、3FS 存储、其他四类，建连时赋予不同 IB **Service Level（SL）**并映射到物理队列 **Virtual Lane（VL）**，按比例配置实现隔离，避免队头阻塞与流量互撞。高吞吐存储场景天然有大量 incast，实测开启自适应路由会让拥塞扩散更严重，故**改用静态路由**，并把各类节点均匀分散到 leaf→spine 链路以均摊存储流量。NCCL 侧调整拓扑使其经同 NUMA 节点内的 IB 网卡与 GPU 通信，减少 chiplet 互连引起的 PCIe 拥塞，并启用 PCIe Relaxed Ordering。
+
+**3FS** 存储节点为 1×64 核 EPYC 7742、512GB 8 通道内存、2×CX6 200Gbps IB、16×15.36TB PCIe 4.0×4 SSD。系统含 cluster manager、meta service、storage service、client 四种角色；元数据以键值对存于分布式 KV 系统（inode 表存文件元数据与内容位置，目录项表存 (parent_dir_inode_id, entry_name):(entry_inode_id,…)）。存储层用 **CRAQ** 的 write-all-read-any 策略保证强一致性并释放 SSD 吞吐与 IOPS，文件按 stripe size $k$ 切块复制到链上，每块 SSD 承载多个链的 target 以均衡读写。针对客户端 incast 拥塞，服务端与客户端间实现 **request-to-send** 流控：服务端读完 SSD 后先申请许可，客户端限制并发发送者数，获准后以 RDMA WRITE 发送并通知；该机制抬高 IO 时延，但为可持续高吞吐所必需。**3FS-KV** 在其上提供键值、消息队列、对象存储三种模型，支持读写分离与按需启动，并支撑 DeepSeek 的 KV Context Caching on Disk 技术，把 LLM 服务成本降低一个数量级。
+
+### 3.6 HAI Platform、稳定性与容灾
+
+**HAI Platform** 采用分时调度：用户提交 Python/bash 任务或容器，平台按资源需求与繁忙度中断并重装任务；任务代码须支持断点续跑——接受中断信号、保存 checkpoint、上报中断、从 checkpoint 恢复。集群不以 GPU 池化方式管理，而是**以计算节点为基本单位**按资源类型、网络区域分类标记，并鼓励用户多卡并行训练，从而实现 **99% 利用率**。
+
+**Checkpoint Manager**：参数与优化器状态切块后经 3FS 批量写 API 写入（每节点超 10 GiB/s），几秒内完成；并异步从 GPU 搬到主机内存，周期保存（通常每 5 分钟）；保存时记录张量索引与偏移，配合批量读 API 使加载同样只需几秒，故故障中断最多只丢 5 分钟进度。**Validator** 每周运行：查硬件频率与链路速率、状态，CPU 压力与内存带宽，逐字节 GPU 显存，满显存 GEMM（并查芯片运算逻辑），节点内 allreduce（借上层应用查 NVLink 带宽），存储带宽压力。
+
+**故障画像**：GPU Xid 错误分五类——软件成因（Xid 13/31、43/45）、NVLink 错误（Xid 74）、显存 ECC 错误（Xid 63/64、94/95，A100 行重映射使多数只需重置 GPU）、不可纠正故障（Xid 44/48、61/62/69/79，需重置 GPU 或重启节点）、其他（Xid 119，GSP 失效，多需 RMA）。实践中还遇到过 ECC 未检出的计算与显存错误，会造成 gradnorm 尖峰、loss 爆炸甚至不收敛。
+
+## 四、主要实验结果
+
+| 基准 / 任务 | 本方案 | 对比对象 | 说明 |
+|---|---|---|---|
+| TF32 GEMM（TFLOPS/GPU） | 107 | DGX-A100 131 | 相对性能 83% |
+| FP16 GEMM（TFLOPS/GPU） | 220 | DGX-A100 263 | 相对性能 83% |
+| 节点相对价格 | 60% | DGX-A100 100% | 性价比 1.38 vs 1 |
+| 功耗（Watts） | 2500 | DGX-A100 4200 | 降约 40% |
+| 交换机数 / 网络价格 / 总价 | 122 / 350 / 11600 | 三层 Fat-Tree 200 / 600 / 11850；DGX 架构 1320 / 4000 / 23000 | 网络成本省 40% |
+| allreduce 节点间带宽（186 MiB，16→1440 GPU） | HFReduce 6.3–8.1 GB/s | NCCL 1.6–4.8 GB/s | HFReduce with NVLink 超过 10 GB/s |
+| VGG16 训练（32→512 GPU） | 时间约为一半，并行可扩展性近 88% | Torch DDP（NCCL 后端） | 弱扩展性 |
+| GPT2-medium 训练（16→128 GPU） | 并行可扩展性 95%，时间比 PyTorch 少近一半 | Torch FSDP | 弱扩展性 |
+| LLaMa-13B（seq 2048, batch 4096, PP 4） | 64→512 GPU：step 64.118s → 9.717s，效率 91% | — | 强扩展性 |
+| DeepSeekMoE-16B（seq 4096, batch 4608, PP 10） | 40→640 GPU：79.615s → 6.535s，效率 76.14%；320 GPU 时 10.71s，效率 92.92% | — | 强扩展性 |
+| 3FS 存储吞吐 | 180 节点 / 360 个 200Gbps HCA，理论 9TB/s，实测读 8TB/s，>20PiB | — | 2880 块 NVMe SSD，镜像冗余 |
+| 整集群能耗 | 不超过 4 MW（约略高于 3 MW） | — | 含 IB 交换机与其他节点 |
+| GPU Xid 年度分布 | 共 12970 次：Xid74 5521（42.57%）、Xid43 4342（33.48%）、Xid31 2487（19.18%）、Xid45 240、Xid13 45，ECC 类约 2% | — | 不可纠正故障合计 57 次（0.45%） |
+| 稳定性对比 | NVLink 相关（主要 Xid-74）占 GPU 故障约 42.57% | 另一论文报告 NVLink 相关占 52.42%（54/103） | 原始数据：54 NVLink、21 CUDA、16 节点、12 ECC、12 网络错误 |
+
+强扩展性最好的观测点是 LLaMa-13B 的 91% 与 DeepSeekMoE-16B 在 320 GPU 时的 92.92%，后者扩到 640 GPU 时降至 76.14%，说明大规模 EP 通信仍有损耗。相对 DGX-A100，本架构 GEMM 稳定落后约 17%，但以半价与六成功耗换来 80% 的整体性能。主要故障来源是 Xid74（占 42.57%）与 Xid43（占 33.48%，也需警惕显存数据损坏）；IB 链路闪断占其余硬件故障的 30%。
+
+## 五、结论、局限与影响
+
+- **结论**：Fire-Flyer 2 用 10,000 块 PCIe A100 达到接近 DGX-A100 的性能并将建设成本减半；软件侧以 HFReduce、HaiScale 突破硬件限制保证可扩展性，以 3FS 与网络协同防拥塞，以 HAI Platform 覆盖系统故障。整体上本架构达到 DGX-A100 的 80% 性能，功耗低于其 60%。
+- **局限性**：
+  - PCIe 与 SXM 的规格固有差距带来约 17% 性能落后，论文自述已「reaching the utilization upper limit of PCIe GPUs」；
+  - HFReduce 受 EPYC Rome/Milan（乃至 Genoa）PCIe Host Bridge 带宽限制，实测约 8GB/s 未达约 12GB/s 的现实上限；
+  - Xid74 占 42.57%，作者坦言除压测筛除反复出错的卡外「没有好的办法避免」；
+  - 无法为 HFReduce 与 3FS 找到可共存的 DCQCN 参数，只能关闭拥塞控制、改以静态路由与流量隔离维持无拥塞；
+  - NVLink 是 LLM 需求倒逼的后期补丁，论文强调是否加装应基于实际需求，因其有潜在缺点。
+- **影响**：本文是 DeepSeek 训练基础设施的一手工程披露，价值在于可复现的成本-性能权衡路径（PCIe 替代 SXM、两层替代三层 Fat-Tree、CPU 规约替代 GPU 规约、存算一体的流量隔离）、真实故障分布数据与开源实践（HAI Platform 已开源）。未来工作提出面向 MoE LLM 训练的下一代架构：节点采用 1:1 GPU/NIC 配比（对标 DGX-H100/B100），引入多平面网络降成本，并探索以 RoCE 替代 IB——128 端口 400Gbps RoCE 组成的 4 平面两层 Fat-Tree 可支持 32,768 GPU。
+
+## 六、关键术语对照表
+
+| English | 中文 |
+|---|---|
+| Fire-Flyer AI-HPC / Fire-Flyer 2 | 萤火 AI-HPC／萤火二号 |
+| Software-Hardware Co-Design | 软硬件协同设计 |
+| All-Reduce / AllGather / Reduce-Scatter | 全规约／全收集／规约散射 |
+| HFReduce / HaiScale | 萤火自研 allreduce 通信库／并行训练框架 |
+| 3FS (Fire-Flyer File System) | 萤火分布式文件系统 |
+| HAI Platform | 萤火集群分时调度平台 |
+| Computation-Storage Integrated Network | 计算-存储一体化网络 |
+| Two-Layer Fat-Tree | 两层胖树拓扑 |
+| Bisection Bandwidth | 对分带宽 |
+| Double Binary Tree | 双二叉树算法 |
+| DP / PP / TP / EP | 数据／流水线／张量／专家并行 |
+| FSDP / ZeRO | 完全分片数据并行／零冗余优化器 |
+| MFU (Model FLOPs Utilization) | 模型算力利用率 |
+| GDRCopy / Copy Engine (CE) | GPU 直接拷贝／（GPU）拷贝引擎 |
+| Service Level (SL) / Virtual Lane (VL) | 服务等级／虚拟通道 |
+| Head-of-line (HOL) Blocking / Incast | 队头阻塞／多点汇聚 |
+| DCQCN / PFC / ECMP / Adaptive Routing | 数据中心量化拥塞通知／优先级流控／等价多路径／自适应路由 |
+| RoCE (RDMA over Converged Ethernet) | 融合以太网 RDMA |
+| CRAQ / Request-to-Send Control | 分配查询的链式复制／发送许可控制 |
+| Silent Data Corruption | 静默数据损坏 |
+| Xid Error / NVLink Bridge | GPU Xid 错误／NVLink 桥接器 |
+| Checkpoint Manager / Validator | 检查点管理器／硬件校验工具 |
+| PUE (Power Usage Effectiveness) | 电能利用效率 |
@@ -0,0 +1,98 @@
+# 深入理解 DeepSeek-V3：大规模缩放挑战与对 AI 架构硬件的反思（中文精读）
+
+> **原文标题**：Insights into DeepSeek-V3: Scaling Challenges and Reflections on Hardware for AI Architectures
+> **arXiv**：[2505.09343](https://arxiv.org/abs/2505.09343) ｜ **发布**：14 May 2025（最后修订 23 Dec 2025）
+> **作者/机构**：Chenggang Zhao、Chengqi Deng、Chong Ruan、Damai Dai、Huazuo Gao、Jiashi Li、Liyue Zhang、Panpan Huang、Shangyan Zhou、Shirong Ma、Wenfeng Liang、Ying He、Yuqing Wang、Yuxuan Liu、Y.X. Wei（通讯作者 Yuqing Wang、Liyue Zhang；作者按名字字母序排列），DeepSeek-AI（深度求索）。ISCA 2025 工业 track 论文（第 52 届国际计算机体系结构研讨会，2025 年 6 月 21–25 日，东京），DOI 10.1145/3695053.3731412
+> **原文 PDF**：[02-Insights-into-DeepSeek-V3-2505.09343.pdf](./02-Insights-into-DeepSeek-V3-2505.09343.pdf)
+
+## 一、摘要（全文翻译）
+
+大语言模型（Large Language Models, LLMs）的快速扩展，暴露出当前硬件架构中的若干关键局限，包括内存容量、计算效率与互联带宽方面的约束。在 2,048 张 NVIDIA H800 GPU 上训练而成的 DeepSeek-V3 表明，硬件感知的模型协同设计（hardware-aware model co-design）能够有效应对这些挑战，从而在规模化条件下实现高性价比的训练与推理。本文对 DeepSeek-V3/R1 的模型架构及其 AI 基础设施进行了深入分析，重点阐述了若干关键创新，例如用于提升内存效率的多头潜在注意力（Multi-head Latent Attention, MLA）、用于优化计算—通信权衡的混合专家（Mixture of Experts, MoE）架构、用于释放硬件能力全部潜力的 FP8 混合精度训练，以及用于最小化集群级网络开销的多平面网络拓扑（Multi-Plane Network Topology）。基于 DeepSeek-V3 开发过程中所遭遇的硬件瓶颈，我们与学术界及工业界同行就未来硬件的可能方向展开了更广泛的讨论，包括精确的低精度计算单元、scale-up 与 scale-out 的融合，以及低延迟通信网络（fabrics）方面的创新。这些洞见凸显了硬件与模型协同设计在满足不断攀升的 AI 负载需求中的关键作用，并为下一代 AI 系统的创新提供了一份可落地的蓝图。
+
+## 二、核心贡献
+
+1. **硬件感知协同设计复盘**：不复述技术报告，而把三大挑战与每项设计针对的硬件痛点一一对应。
+2. **MLA 压缩 KV 缓存**：把各头 KV 压为小潜在向量并只缓存它，每 token 仅 70.272 KB，为 Qwen-2.5 72B（GQA）的 1/4.66、LLaMA-3.1 405B 的 1/7.28。
+3. **MoE 成本效益量化**：671B 总参、每 token 激活 37B，训练算力约 250 GFLOPS/token，而 72B 与 405B 稠密模型需 394 与 2448，即少一个数量级算力达到相当性能。
+4. **FP8 训练实践与硬件批判**：细粒度量化下相对 BF16 精度损失低于 0.25%；并指出 Hopper 累加精度仅等效 FP22，建议原生支持细粒度量化。
+5. **LogFMT 通信压缩**：自适应步长在同比特宽下精度更高，但编解码与 all-to-all 融合开销达 50%~100%，最终未采用。
+6. **互联与网络协同设计**：以「弃用 TP + DualPipe + EP」配合节点受限路由规避 IB 瓶颈；两层多平面 Fat-Tree 支撑 16,384 端点、单价 4.39 k$/端点，实测与原多轨网络持平。
+
+## 三、方法与技术要点
+
+### 3.1 三大挑战与推理速度上限
+
+论文先量化矛盾：LLM 内存需求年增超 1000%，HBM 容量年增却不足 50%。**内存效率**上，KV 缓存把单 token 生成复杂度降为 $O(N)$，但计算退化为 GEMV 后转为访存带宽受限；MLA 用联合训练的投影矩阵把所有头的 KV 压成小潜在向量、推理只缓存它。**成本效益**上，MoE 只激活部分专家（V2 236B/21B，V3 671B/37B），使 AI SoC 的 PC 也能接近 20 TPS。**推理速度**上，以双微批次重叠把 all-to-all 藏在计算之后，生产再以预填充／解码分离分配不同 EP 组大小。
+
+延迟侧给出上限推导：MoE 要快需让每台设备只算一个专家，这就必须 all-to-all 路由 token，故**上限由互联带宽决定**。设每设备持一个专家、每批约 32 token：
+
+$$\text{Comm. Time}=(1\text{B}+2\text{B})\times 32\times 9\times 7\text{K}/50\text{GB/s}=120.96\,\mu s$$
+
+其中 dispatch 用 FP8、combine 用 BF16，隐藏维约 7K，系数 9 = 8 个路由专家 + 1 个共享专家。双微批次重叠且计算开销可忽略时，61 层共 **14.76 ms**，上限约 **67 tokens/s**；换成 GB200 NVL72 的 900 GB/s 则上限 0.82 ms ≈ 1200 tokens/s（论文强调纯属理论）。堆硬件太贵，算法必须分担：**多 token 预测（MTP）**每模块仅一个轻量单层，实测第二后继 token 接受率 80%~90%、TPS 提升 1.8 倍，略损吞吐却显著降低生成延迟，并因每步多 token 增大推理批量、提升 EP 计算强度。
+
+验证采用「小模型充分消融 → 少量大规模调参 → 一次完整训练集成」，如 FP8 先在 16B/230B 的 V2 上消融。
+
+### 3.2 低精度驱动设计
+
+**FP8 混合精度训练**：Transformer Engine 虽早支持 FP8 训练，但此前无开源大模型采用。V3 为 MoE 构建 FP8 训练框架，激活按 1×128 tile、权重按 128×128 block 细粒度量化（开源为 DeepGEMM）。两条硬件限制：Hopper Tensor Core 把 32 个尾数积按最大指数对齐后只保留最高 13 个小数位、累加进 FP22 寄存器，危及训练稳定性；反量化需把部分和从 Tensor Core 搬到 CUDA Core 乘缩放因子，开销大。建议累加精度改为 FP32 或可配置，并让 Tensor Core 原生接收缩放因子做分组缩放矩阵乘（如 Blackwell 的 microscaling）。
+
+**LogFMT 通信压缩**：EP 的 dispatch 已用 FP8 使通信量较 BF16 减少 50%，combine 仍为 BF16。所提 LogFMT-nBit 对 1×128 tile 取对数求 min/max：最小值编码 $S.00\cdots01$、最大 $S.11\cdots11$，步长 $Step=\frac{max-min}{2^{n-1}-2}$，零值编码 $S.00\cdots00$，其余取整到 Step 的整数倍 K，解码 $\exp^{min+Step\times(K-1)}$。因 min 与 Step 按块局部计算，范围可动态适配；论文强调必须**在线性空间取整**才无偏，并约束 $min>max-\log(2^{32})$ 使范围与 E5 相当。约 7B 模型上模拟 combine：n=8 精度优于 E4M3/E5M2，n=10 接近 BF16。但编解码与 all-to-all 融合开销高达 50%~100%，**最终未采用**，建议硬件提供原生编解码单元。
+
+### 3.3 互联驱动设计
+
+H800 为合规把节点内 NVLink 从 900 GB/s 削到 400 GB/s，故每节点配 8 张 400G CX7 IB 网卡补偿。并行策略据此确定：训练避免 TP（推理可用以改善 TTFT/TPOT）、用 DualPipe 重叠注意力与 MoE 计算和 MoE 通信、EP 的 all-to-all 超过 40 GB/s（开源实现 DeepEP）。**节点受限路由**源于 scale-up 与 scale-out 约 4:1 的带宽差（NVLink 200 GB/s、实测约 160；单网卡有效按 40 GB/s）。以 8 节点 64 GPU、256 专家为例：每 token 去 1 个共享 + 8 个路由专家，若其散布 8 个节点则 IB 耗时为 $8t$；若发往同一节点的 token 只经 IB 发一次、再在节点内用 NVLink 转发，**去重后降为 $Mt$**（M 为目标节点数）。既然流量只取决于 M，模型侧把 256 专家分 8 组分驻 8 个节点，并保证每 token 最多路由到 4 个节点。代价是内核更复杂：SM 既填 QP/WQE 又做转发，训练时最多 20 个 SM 用于通信；在线推理则让 EP all-to-all 全走网卡 RDMA 以避开争用。论文建议把这些任务卸载给专用硬件：统一网络适配器（单 LID/IP 加策略路由）、专用通信协处理器（类 TMA 加速 load/store）、灵活转发／广播／reduce 机制与硬件同步原语；并建议暴露流量类别 TC、把网卡集成进 I/O die，以缓解 KV 缓存传输与 EP 通信对 PCIe 的争用。
+
+### 3.4 大规模网络驱动设计
+
+**多平面 Fat-Tree（MPFT）**：每节点 8 GPU + 8 张 IB 网卡，每对 GPU–NIC 归属一个独立平面，另有 400 Gbps RoCE 网卡接入存储平面访问 3FS。64 端口 400G IB 交换机让两层拓扑理论上支持 16,384 GPU，但受政策监管最终只部署两千余张。受 CX7 限制未达理想形态——理想是每网卡多端口、bonding 为单一逻辑接口、单 QP 跨所有端口收发（类似 packet spraying），这会使包乱序到达，**要求网卡原生支持乱序落位**（CX-8 已支持 4 个平面）。它作为多轨 Fat-Tree（MRFT）的特例可复用 NCCL 与 PXN 优化，且成本与延迟更低。实测 MPFT 与 MRFT 几乎持平：all-to-all 性能相近、EP 模式每 GPU 超过 40 GB/s、2048 GPU 训练 V3 的吞吐与 MFU 差异落在测量误差内；但跨平面通信仍需节点内转发。
+
+**低延迟网络**：按 50 GB/s 带宽，前述传输理想耗时约 120 μs，故微秒级固有延迟不可忽略。64B 传输的 CPU 侧端到端延迟为 IB 同叶 2.8 μs、跨叶 3.7 μs，优于 RoCE 的 3.6/5.6 μs，但 IB 更贵、交换机端口更少（64 对 128）。RoCE 改进建议：（1）开发专为 RDMA 优化的低延迟交换机、去掉冗余以太网特性；（2）改用自适应路由——默认 ECMP 难以分摊缺乏随机性的 LLM 训练流量，造成 NCCL 集合通信拥塞退化；（3）改进拥塞控制——all-to-all 突发多对一会引发 incast，可用 VOQ 按 QP 隔离或 RTTCC 等可编程拥塞控制。**IBGDA** 让 GPU 直接填工作请求（WR）并写 RDMA doorbell 的 MMIO 地址，把控制面移入 GPU，消除 CPU 代理线程的 GPU–CPU 延迟。
+
+### 3.5 面向未来硬件架构的洞见
+
+**稳健性**：互联间歇断连在 EP 中危害极大，节点／GPU／ECC 故障迫使重启，ECC 检测不到的静默数据损坏会在长任务中无声传播且只能靠应用层缓解，故建议硬件级校验和与冗余校验。**CPU 与互联**：PCIe 在参数、梯度或 KV 传输时成为瓶颈，应改直连或纳入 scale-up 域；打满 160 lane PCIe 5.0 需每节点超过 640 GB/s，对 DRAM 是巨大挑战。**智能网络**：共封装光学、端点驱动拥塞控制与自适应路由。**内存语义定序**：写入后必须 fence 才能更新标志位，多出一次 RTT 且阻塞发起线程；建议硬件内建 acquire/release：接收端用包序号（PSN）保序，或用区域化 RAR 以位图与区域计数器跟踪区域状态而免除发送端 fence。**近网计算与压缩**：dispatch 形似小规模多播，硬件自动复制转发可省大量开销。**内存中心创新**：DRAM 堆叠（如 SeDRAM）适合访存受限的 MoE 推理；晶圆级系统（SoW）最大化密度与带宽。
+
+## 四、主要实验结果
+
+| 基准 / 任务 | 本模型 | 对比对象 | 说明 |
+|---|---|---|---|
+| 每 token KV 缓存（BF16） | DeepSeek-V3（MLA）70.272 KB，1× | Qwen-2.5 72B（GQA）327.680 KB，4.66×；LLaMA-3.1 405B（GQA）516.096 KB，7.28× | 论文 Table 1：MLA 把 KV 压为潜在向量 |
+| 每 token 训练计算量（序列长度 4096） | DeepSeek-V3 MoE（671B）250 GFLOPS/Token | DeepSeek-V2 MoE（236B）155；Qwen-72B Dense 394；LLaMa-405B Dense 2448 | 论文 Table 2：MoE 以少一个数量级算力达到相当性能 |
+| FP8 训练相对精度损失 | < 0.25% | BF16 基线 | 在 16B 与 230B 的 DeepSeek-V2 上消融 |
+| MTP 投机解码收益 | 第二后继 token 接受率 80%~90%，TPS 提升 1.8× | 无 MTP 模块 | 略损吞吐换取端到端延迟下降，并增大推理批量 |
+| 推理速度理论上限（双微批次重叠、计算开销可忽略） | H800 + 400G IB：14.76 ms TPOT ≈ 67 tokens/s | GB200 NVL72（900 GB/s）：0.82 ms TPOT ≈ 1200 tokens/s | 后者论文注明纯属理论，实际因小批量效率下降会显著更低 |
+| 网络拓扑规模与成本 | MPFT：16,384 端点、768 交换机、16,384 链路、72 M$、4.39 k$/端点 | FT2：2,048 端点、9 M$、4.39；FT3：65,536 端点、491 M$、7.5；SF：32,928 端点、4.4；DF：261,632 端点、5.8 | 论文 Table 3，成本估算沿用 Slim Fly 论文方法 |
+| V3 训练指标（2048 GPU） | MPFT：272.80 tokens/day（B）、19.926 s/step、TFLOPS(non-causal) 432、TFLOPS(causal) 385、MFU(non-causal) 43.73%、MFU(causal) 38.94% | MRFT：272.52、19.946、432、385、43.68%、38.90% | 论文 Table 4：差异在正常波动与测量误差内 |
+| NCCL all-to-all 与 EP 通信 | MPFT：每 GPU 超过 40 GB/s；32→128 GPU 性能与 MRFT 相近，16 GPU 延迟差异可忽略 | MRFT（单平面多轨） | 论文 Figure 5–7，PXN 机制使多平面同样受益 |
+| 端到端延迟（64B 传输，CPU 侧） | InfiniBand：同叶 2.8 μs、跨叶 3.7 μs | RoCE：同叶 3.6 μs、跨叶 5.6 μs；NVLink：3.33 μs | 论文 Table 5：IB 延迟最低，但更贵且交换机端口更少 |
+
+本文定位为架构反思而非模型评测，故无下游任务基准分数，上述测量集中在内存与算力开销、网络拓扑与延迟三类。MLA 的 KV 缓存领先 GQA 方案 4.66~7.28 倍，MoE 每 token 算力省约一个数量级，多平面 Fat-Tree 把端点从 2,048 扩至 16,384 而单价仍为 4.39 k$/端点；但论文承认推理上限的实际达成受通信开销与带宽利用制约，1200 TPS 仅为理论值。
+
+## 五、结论、局限与影响
+
+- **结论**：DeepSeek-V3 展示了软硬件协同设计在提升大规模 AI 系统可扩展性、效率与稳健性上的变革潜力，其路线图可直接指导下一代面向 AI 优化的硬件设计。
+- **局限性**（论文自述）：FP8 在 Hopper 上累加精度受限（等效 FP22），细粒度量化反量化开销大；LogFMT 虽有效，却因 log/exp 带宽不足与寄存器压力，融合 all-to-all 时开销达 50%~100% 而未被采用；H800 的 NVLink 被削至 400 GB/s，训练时最多 20 个 SM 被通信占用；MPFT 受 ConnectX-7 限制未达理想架构，跨平面通信需节点内转发；受监管约束集群只部署两千余张 GPU（拓扑理论上支持 16,384）；推理上限分析为理想化情形，1200 TPS 属理论推算；RoCE 在延迟与可扩展性上仍不满足需求。
+- **影响**：本文把「模型架构决策—硬件瓶颈—下一代硬件需求」的因果链公开化，给出可执行的协同设计清单（原生细粒度量化与可配置累加精度、scale-up/scale-out 统一与专用通信协处理器、内存语义通信的硬件定序、近网计算与压缩、DRAM 堆叠与晶圆级集成），并以 DeepEP、DeepGEMM 等开源实现降低复现门槛。
+
+## 六、关键术语对照表
+
+| English | 中文 |
+|---|---|
+| Multi-head Latent Attention (MLA) | 多头潜在注意力 |
+| Mixture of Experts (MoE) | 混合专家 |
+| Expert Parallelism (EP) / Tensor Parallelism (TP) / Pipeline Parallelism (PP) | 专家并行 / 张量并行 / 流水线并行 |
+| FP8 Mixed-Precision Training | FP8 混合精度训练 |
+| Fine-Grained Quantization (tile-wise / block-wise) | 细粒度量化（tile 级 / block 级） |
+| FP22 / Accumulation Precision | FP22 / 累加精度 |
+| LogFMT (Logarithmic Floating-Point Formats) | 对数浮点格式 |
+| Multi-Plane Fat-Tree (MPFT) / Multi-Rail Fat-Tree (MRFT) | 多平面胖树 / 多轨胖树 |
+| Node-Limited Routing | 节点受限路由 |
+| Multi-Token Prediction (MTP) | 多 token 预测 |
+| DualPipe / DeepEP / DeepGEMM | DualPipe / DeepEP / DeepGEMM（训练调度、通信库与矩阵乘库） |
+| InfiniBand GPUDirect Async (IBGDA) | InfiniBand GPU 直接异步通信 |
+| Remote Direct Memory Access (RDMA) / RoCE | 远程直接内存访问 / 融合以太网 RDMA |
+| Packet Spraying / PXN | 包喷洒 / NCCL 的 NVLink 转发优化（PXN） |
+| Time Per Output Token (TPOT) / Model Flops Utilization (MFU) | 每输出 token 耗时 / 模型算力利用率 |
+| Silent Data Corruption | 静默数据损坏 |
+| Memory-Semantic Communication / acquire-release ordering | 内存语义通信 / acquire-release 定序 |
+| System-on-Wafer (SoW) | 晶圆级系统 |
@@ -0,0 +1,94 @@
+# DualPath：打破智能体式 LLM 推理中的存储带宽瓶颈
+
+> **原文标题**：DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference
+> **arXiv**：[2602.21548](https://arxiv.org/abs/2602.21548) ｜ **发布**：25 Feb 2026（v1），26 Feb 2026（v2）
+> **作者/机构**：Yongtong Wu、Shaoyuan Chen、Yinmin Zhong、Rilin Huang、Yixuan Tan、Wentao Zhang、Liyue Zhang、Shangyan Zhou、Yuxuan Liu、Shunfeng Zhou、Mingxing Zhang、Xin Jin、Panpan Huang（北京大学计算机学院、清华大学、DeepSeek-AI）
+> **原文 PDF**：[03-DualPath-2602.21548.pdf](./03-DualPath-2602.21548.pdf)
+
+## 一、摘要（全文翻译）
+
+多轮、智能体式（agentic）LLM 推理的性能，正日益由 KV-Cache 的存储 I/O 而非计算所主导。在普遍采用的分离式（disaggregated）架构中，从外部存储加载海量 KV-Cache 造成了一种根本性的失衡：预填充引擎（prefill engine）上的存储网卡带宽被完全打满，而解码引擎上的存储网卡却处于空闲状态。这种不对称严重制约了系统整体吞吐。
+
+我们提出 DualPath，一个通过引入双路径 KV-Cache 加载来打破该瓶颈的推理系统。在传统的「存储到预填充」路径之外，DualPath 还启用了一条新颖的「存储到解码」路径：KV-Cache 先被加载进解码引擎，随后通过计算网络上的 RDMA 高效传输到预填充引擎。DualPath 将这条经过优化的数据路径——它本身就能避免网络拥塞，并避免干扰对延迟至关重要的模型执行通信——与一个在预填充与解码引擎之间动态均衡负载的全局调度器结合在一起。
+
+我们在三个模型上、使用真实的智能体式工作负载所做的评测表明，DualPath 在我们自研的推理系统上把离线推理吞吐最高提升 1.87×。它还能在不违反 SLO 的前提下，把在线服务吞吐平均提升 1.96×。
+
+## 二、核心贡献
+
+1. **指出智能体式负载的本质是 I/O 受限**：论文通过生产环境 trace 量化了「多轮 + 短追加 + 长上下文」带来的 98.7% KV-Cache 命中率与约 22 GB/PFLOP 的缓存-计算比，证明 KV-Cache 加载而非计算才是当代 PD 分离架构下的主导性能因素。
+2. **提出双路径 KV-Cache 加载（dual-path loading）**：在传统「存储→预填充（PE）」路径之外新增「存储→解码（DE）→RDMA→PE」路径，把全机群存储网卡带宽池化，解决既有系统只能用预填充侧网卡、造成预填充侧存储带宽长期饱和而解码侧闲置的根本性浪费。
+3. **给出无瓶颈可行性分析**：在合理的 PCIe 拓扑与负载均衡假设下推导出双路径不引入 CNIC 或 DRAM 新瓶颈的 P/D 比值区间 $\frac{s}{g-s}\le P/D\le\min\{\frac{g-2s}{s},\frac{g-s}{2s},\frac{M/Bs-3}{2}\}$，在 $g=8,s=1$ 的实际配置下覆盖 $1/7\le P/D\le 7/2$ 的绝大多数部署。
+4. **以 CNIC 为中心的流量管理与隔离**：让所有 GPU 进出的流量（含本地 H2D/D2H）统一走 GPU 配对的 CNIC 与 GPUDirect RDMA 路径，从而借用计算网络原生的 QoS（InfiniBand VL / RoCE TC+DSCP）把 KV-Cache 流量压到低优先级虚拟通道，避免干扰 EP AllToAll 等亚毫秒级集合通信。
+5. **面向负载的双层自适应调度器**：跨引擎调度同时均衡存储网卡队列、token 计数与 HBM 余量并动态选择读取路径；引擎内调度用计算配额与 chunked prefill 拉平注意力层执行时间，消除 GPU 空泡。
+6. **实测收益**：离线推理吞吐最高 1.87×（DS 660B，对未改造的自研基线 Basic），在线服务在 TTFT≤4s、TPOT≤50ms 的 SLO 下吞吐平均 1.96×，TTST 与 TPOT 基本无回退，并验证到 1152 张 GPU 的近线性扩展。
+
+## 三、方法与技术要点
+
+### 3.1 瓶颈诊断与动机
+
+论文从三个决定性因素论证瓶颈：其一，智能体负载天然高命中率——生产代码类任务 trace 显示平均 157 轮、平均上下文 32.7k、平均追加长度仅 429，命中率 98.7%，每轮都要从持久化存储读回全上下文 KV-Cache，缓存-计算比高达约 22 GB/PFLOP（DeepSeek-V3.2），而 KV-Cache 更大、未做 MLA 优化的模型（如 FP16 下的 Qwen2.5-32B 达 117–267 GB/PFLOP）情况更差；其二，硬件趋势不利，从 NVIDIA Ampere 到 Blackwell 的 I/O-计算比下降了 14.4×，网卡带宽与 HBM 容量落后于 GPU FLOPS 增长；其三，PD 分离架构下命中 KV-Cache 完全由预填充引擎从远端存储读取，把全部存储 I/O 压力集中在预填充侧 SNIC 上。论文同时观察到计算网络流量呈「亚毫秒突发、间歇」形态，存在大量闲置窗口，于是产生核心机会：用解码节点的 SNIC 读数据，再借更快的计算网络带宽送回预填充节点。
+
+### 3.2 双路径加载的数据流
+
+系统为每个 PE 与 DE 分配少量 DRAM 作为缓冲（PE Buffer / DE Buffer）。在 **PE 读路径**中，命中 token 的 KV-Cache 先从持久化存储读入 PE Buffer，在每层注意力计算前按层搬入 PE HBM 以计算未命中（miss）prompt token 的 KV-Cache，随后命中与未命中的 KV-Cache 一起传回 DE Buffer 组成完整 prompt KV-Cache；这一过程重复 $n_{layer}$ 次，且传输与计算重叠。在 **DE 读路径**中，命中 KV-Cache 先读入 DE Buffer，预填充期间逐层从 DE Buffer 取用（同样与计算重叠），某层算完后只把 miss token 的 KV-Cache 传到 DE Buffer 与已有命中部分合并。解码阶段开始前，DE 分配 HBM 并做 H2D 搬移，然后释放 CPU 内存；解码过程中每累积满一个 token 块（如 64 个 token）即落盘。选择 DE Buffer 中转而非直接 GPU Direct RDMA 绕开，是为了降低 GPU 显存占用、加快首 token 时延（TTFT 在本场景占端到端时间不可忽略），代价是额外的 DRAM 与一次 H2D 的 CNIC 压力。
+
+### 3.3 块布局与无瓶颈分析
+
+层式预填充把 KV-Cache 块大小降到原 $1/layer$、块数放大 $layer$ 倍，为此论文设计两种块：**Layer Block** 形状 $[1,tokens,bytes]$（单层）与 **Full Block** 形状 $[layer,tokens,bytes]$（全层）。与存储的交互一律用 Full Block，而 PE HBM 加载、PE↔DE Buffer 的层式流式传输用 Layer Block。无瓶颈分析取每个 PE-DE 对的流量 $T_p=Bs/(Dg^2)$（PE 读路径）与 $T_c=Bs/(Pg^2)$（DE 读路径），逐一约束 PE CNIC 的读/写方向与 DE CNIC 的读/写方向，并叠加 DRAM 半双工压力（PE MEM 为 $2sB$，DE MEM 为 $(3+2P/D)Bs$），最终得到 3.1 中给出的 P/D 合法区间；当 $g=8,s=1$、$M\approx500$ GB/s、$Bs\approx50$ GB/s 时区间为 $1/7 \le P/D \le 7/2$。
+
+### 3.4 以 CNIC 为中心的流量管理器
+
+CUDA copy engine 与 GPUDirect Storage 等既有手段的问题在于：它们走与计算网络不同的通道、不受同一套 QoS 管控，且现有 GPU 不支持 PCIe QoS，无法保护模型执行通信；而集合通信是亚毫秒级突发，软件流量整形器也无法把低优先级 I/O 塞进空隙。因此论文把所有 GPU 进出流量统一收敛到 CNIC 的 GPUDirect RDMA 路径：先用存储网把 KV-Cache 读入 host DRAM，再向配对的 CNIC 提交 RDMA Write 完成本地 H2D，写回对称处理，使 CNIC 成为全部 GPU PCIe 流量的集中 QoS 调度点。隔离上基于 InfiniBand 虚拟通道（VL），把模型通信放高优先级 VL、其余（含 KV-Cache）放低优先级 VL，配置加权轮询仲裁把约 99% 带宽留给高优先级 VL、余量给低优先级防饿死（附录给出 `qos_max_vls 4`、`qos_high_limit 240` 等参数；RoCE 可用 DSCP+TC 与 PFC 等价实现）。额外收益是：单次 `cudaMemcpyAsync` 提交开销约 5–7 μs，一次 RDMA Write 只需约 1 μs 且可用 doorbell batching 摊薄，故大量小块数据下 CNIC 辅助 H2D/D2H 反而优于 CUDA copy engine。
+
+### 3.5 自适应请求调度
+
+调度分两层。**跨引擎调度**把引擎分组，仅 rank 0（Leader Engine）与调度器交互，同节点引擎保证同组；引擎上报未完成请求数 $seq_e$、其 token 总量 $tok_e$ 与所属节点的磁盘读队列长度 $read\_q_{n(e)}$，并以 token 数作为 GPU、磁盘与网络负载的统一代理。PE 侧按 FIFO 取任务，把引擎分为过载（$tok_e>\beta$）、所在节点读队列短（$read\_q\le\alpha$）、读队列长三类：不给过载引擎派活，优先第二类（避免存储网卡闲置），在其中选 $tok_e$ 最小者，其次第三类；两类皆空则终止本次取任务。DE 侧为两级且不保全局 FIFO：组间把请求分给 token 总量最小的组；组内按剩余 HBM 估算可调度上界集合 $R$，取高 token 阈值 $Z=1.05\times(\sum_{r\in R}len_r+\sum_{e\in E}tok_e)/|E|$，优先选择不会越过 $Z$ 且 $seq_e$ 最小的 DE，否则退回高 token 组中 $tok_e$ 最小者以降低 HBM 耗尽与抢占风险。路径选择上挑读队列更短的一侧读取（把请求一分为二从两侧并行读留作未来工作）。**引擎内调度**只作用于 PE（DE 总是把全部请求入批）：以 (cached, bsz) 描述请求并预估注意力层执行时间（计算量与墙钟时间的关系通过离线 profiling 拟合），按 FIFO 持续加入请求直到逼近预设计算配额；超限时对 $bsz$ 做二分查找得到可塞入余量的 $bsz'$ 并执行 chunked prefill。
+
+## 四、主要实验结果
+
+实验平台为 8×NVIDIA Hopper GPU、双路 CPU、8 张 400 Gbps RDMA 网卡加 1 张连 3FS 的存储网卡、计算网与存储网物理隔离的机群；模型为 DS 660B（MoE + DeepSeek Sparse Attention）、DS 27B（内缩版本）与 Qwen2.5-32B（dense + GQA）；数据集为三个生产级智能体 RL 轨迹集（各 500 条轨迹）。
+
+| 基准 / 任务 | 本模型 | 对比对象 | 说明 |
+|---|---|---|---|
+| 离线批量推理 JCT（DS 660B） | 最高 **1.87×** | Basic（未改造自研框架） | 性能接近 Oracle（零 I/O 开销理论上界），说明 KV-Cache I/O 基本被消除 |
+| 离线批量推理 JCT（DS 27B） | 最高 **1.78×** | Basic | 仍比 Oracle 慢 1.09–1.85×，受 1P1D 存储带宽限制 |
+| 离线 JCT（追加长度变化，DS 660B/64K/1024 agents） | **1.82–1.99×** | Basic | 追加变长时 Basic 逐步逼近 DualPath 与 Oracle，瓶颈转回 GPU 计算压力 |
+| 离线 JCT（P/D 比值 1P1D、2P1D、1P2D，DS 27B） | 平均 **1.64×**（最高 2.46×） | Basic（对应配置） | Basic 1P1D≈Basic 1P2D、DualPath 1P1D≈Basic 2P1D，佐证存储带宽是主导瓶颈 |
+| 在线服务吞吐（DS 660B） | 最高 **2.25×** | Basic | 到达率上限由 APS 提升衡量 |
+| 在线服务吞吐（DS 27B） | 最高 **1.67×** | Basic | 与 DS 660B 趋势相似，两者 TPOT 均显著高于 Oracle（小模型基础 P-D 传输开销可观） |
+| 消融：层式预填充 | JCT 降低 **17.21%** | Basic | 缓解 PE HBM 瓶颈并掩盖传输开销 |
+| 消融：层式预填充 + 双路径加载 | JCT 降低 **38.19%** | Basic | 双路径贡献主要收益，请求可从 PE 或 DE 两侧读 KV-Cache |
+| 消融：再加调度算法 | JCT 降低 **45.62%** | Basic | 最好的组合，验证均衡调度对存储网卡的有效性 |
+| 负载均衡（存储网卡） | Max/Avg 由 **1.53 降至 1.18** | 轮询（round robin） | 注意力层执行时间 Max/Avg 在任务前 5% 低至 1.06，减少 GPU 空泡 |
+| 大规模离线（DS 660B） | 48P96D/4.8万 agents：**JCT 3,201s** | 2P4D/2千 agents：3,167s | 近线性加速，调度器 CPU 占用始终低于 10 核 |
+| 大规模在线（DS 660B） | 44P88D：**8.8 APS**（TTFT 1.847s / TTST 0.194s / TPOT 0.036s） | 2P4D：0.4 APS（1.739s / 0.228s / 0.039s） | 吞吐提升 22× 而时延基本不变 |
+
+离线场景下 DualPath 在更大批量和更长最大智能体长度（MAL）时受益更多；在线场景下 DualPath 的 TTST 与 Basic 相当、TPOT 不引入额外解码开销，并且 TTFT 的各分量在不同 APS 下保持稳定，而 Basic 的排队时间因存储带宽不足急剧增长。仍有差距之处在于：DS 27B 等小模型上基础 P-D 传输开销显著（TPOT 明显高于 Oracle），且 SGL(MC) 在部分大配置下报错未能完成（记为 N/A），与 SGL(MC) 的对比因实现差异被论文明确判定为不公平、只报告 Basic→Ours 的提升。
+
+## 五、结论、局限与影响
+
+- **结论**：DualPath 通过双路径 KV-Cache 加载重新分配存储网络负载，解决 PD 分离架构下 KV-Cache 读取不均衡问题，离线推理吞吐最高提升 1.87×，在线服务平均每秒智能体运行数提升 1.96×；理论上在常见 P/D 比下不引入新瓶颈，工程上通过 CNIC 集中 QoS 与双层调度把额外流量对推理通信的干扰降到可忽略。
+- **局限性**：作者自述的局限包括——大规模实验因缺少充分调优的并行度与 P/D 比值（需要大量实验预算），未展现出相比等价成本的多组小规模单元之外的额外 JCT 或服务容量收益；调度算法仍有改进空间，期望在大规模部署下取得更低的 TTFT 分位数；由于真实场景存在到达间隔与工具调用延迟，工作集将随 $r^2$ 放大，而验证这一点需要 $r$ 倍机器小时与 $r^2$ 倍存储（成本按 $r^3$ 增长），受资源限制无法承担；把小请求拆成两半从 PE/DE 两侧并行读取以及小模型上 P-D 传输开销的优化均留作未来工作；离线负载高度动态，需要更自适应的并行度与 P/D 比配置（如模拟器或在线调整机制）。
+- **影响**：该工作把「KV-Cache 必须由预填充引擎读取」这一隐含假设拆掉，将全机群存储网卡带宽变成可池化、可调度的全局资源，为智能体式（RL rollout、长会话编码助手）这类高缓存命中、I/O 受限负载提供了新的扩容维度；其「所有 GPU 流量统一走 CNIC 以借用计算网络原生 QoS」的做法与 RoCE/UnifiedBus/Ultra Ethernet 的 QoS 演进方向一致，具备向更广泛互连技术迁移的潜力。
+
+## 六、关键术语对照表
+
+| English | 中文 |
+|---|---|
+| Agentic LLM Inference | 智能体式 LLM 推理 |
+| KV-Cache | 键值缓存 |
+| Prefill-Decode (PD) Disaggregation | 预填充-解码分离 |
+| Prefill Engine (PE) / Decode Engine (DE) | 预填充引擎 / 解码引擎 |
+| Dual-Path Loading | 双路径加载 |
+| Layerwise Prefill | 层式预填充 |
+| Storage NIC (SNIC) / Compute NIC (CNIC) | 存储网卡 / 计算网卡 |
+| GPUDirect RDMA / GPUDirect Storage | GPU 直通 RDMA / GPU 直通存储 |
+| Virtual Lane (VL) / Weighted Round Robin (WRR) | 虚拟通道 / 加权轮询 |
+| Quality of Service (QoS) | 服务质量 |
+| Cache-Compute Ratio | 缓存-计算比 |
+| Time to First Token (TTFT) / Time to Second Token (TTST) / Time per Output Token (TPOT) | 首 token 时延 / 第二 token 时延 / 每输出 token 时延 |
+| Service Level Objective (SLO) | 服务等级目标 |
+| Job Completion Time (JCT) | 作业完成时间 |
+| Expert Parallelism (EP) / Data Parallelism (DP) | 专家并行 / 数据并行 |
+| Chunked Prefill / Compute Quota | 分块预填充 / 计算配额 |
+| Working Set | 工作集 |