分而治之：全面解析分布式分离 Inference 系统 - 链载Ai

一、背景

大模型，如大语言模型（LLM）和大型多模态模型（LMM），正在改变自然语言处理和多模态任务的格局。然而，这些模型的 Inference 过程面临大计算、大内存、高时延等诸多挑战。为了应对这些问题，分布式分离 Inference 系统应运而生，旨在通过将模型的不同部分分开处理来优化性能。

大体来说，大模型 Inference 经历了从单体到分布式，再到分离式的演进，并在继续发展中：

单体 Inference 阶段（2020 年前）：

模型完整加载至单个设备（CPU 或 GPU），Inference 过程在同一设备完成
适用于小型模型（如 BERT、ViT、早期 GPT-2）
局限性：受单设备内存和计算能力限制

分布式并行阶段（2020 - 2023）：

采用模型并行（Tensor Parallel）和流水线并行（Pipeline Parallel）
模型仍作为整体处理，但计算分布在多设备

分离式阶段（2024 至今）：

按特性将模型拆分为独立组件
组件可独立部署和优化
引入专门的调度和 Cache 管理

当前的大模型正在经历探索突破智能上限的阶段，受到硬件的制约，架构由简到繁是迫不得已的选择。随着硬件的快速迭代以及模型和算法的不断演进，也必将经历由繁到简的过程。本文中我们基于之前关注的一系列工作，从几个方面分别介绍当前大模型 Inference 系统的几个关键技术：

分离式 Inference：

模态分离：Vision/Language 单独处理
PD 分离：Prefill 和 Decoding 分布式扩展
Attention/MoE 分离：提升资源利用

分布式并行：

TP 及优化（MultiShot，Flux 等）
PP/EP/SPP

分布式 KV Cache存储和管理：

阿里 DistKV，Transfer Engine，NIXL，EIC 等。

调度策略

相关工作可以参考我们之前的介绍：

LLM 推理框架之上：10 种常见 LLM 推理系统总结
字节 MegaScale-Infer：分离式专家并行 MoE 服务系统
LLM 推理的 Attention 计算和 KV Cache 优化：PagedAttention、vAttention 等
揭秘 LLM 推理：全面解析 LLM 推理性能的关键因素
字节 TileLink：编译生成高效的计算和通信 Overlap Kernel
DeepSeek Infra/V1/MoE/V2/V3/R1 & 开源关键技术" data-itemshowtype="0" target="_blank" linktype="text" data-linktype="2">综述：DeepSeek Infra/V1/MoE/V2/V3/R1 & 开源关键技术

二、分离式 Inference 系统

2.1 概述

随着大模型被广泛应用，Inference 服务场景变得高度多样化，输入/输出模态和长度、请求到达频率、SLO（服务级别目标，主要包括首 Token 时延 TTFT 和输出 Token 间延迟 TBT）均有很大差异。

然而，当前主流 GPU 服务器节点资源高度一体化。单纯以节点为单位分配任务，容易造成资源利用不足，难以兼顾高吞吐与低延迟。因此，需要对集群资源（CPU/DRAM/SSD/GPU）进行更细粒度的解耦与重组。分离技术应运而生，包括模态分离、PD（Prefill & Decoding）分离以及 Attention/MoE 分离：

模态分离：涉及将不同模态分开处理，例如在 Vision-Language 模型中，Vision Encoder 可以独立优化。
PD 分离：将 LLM 的 Prefill 和 Decoding 阶段分开，允许在不同硬件上运行，从而提高吞吐量，降低成本。
Attention & MoE 分离：在 Decoding 阶段，通过将 Attention 计算和 FFN（MoE）模块分开，优化 MoE 模型的资源利用率。

2.2 模态分离

2.2.1 多模态模型范式

随着大模型的发展，多模态大模型（LMM, Large Multimodal Models）——能处理文本、图像、视频、音频等多种输入模态的模型——在各类任务（如图像描述、视觉问答等）中表现出了强大能力，也逐步进入生产环境。

广义的多模态模型包括各种模态，比如语言（Language）、视觉（Vision）、音频（Audio）甚至深度（Depth）信息。Meta 早在 23 年 5 月就发表过一个大统一的多模态模型 ImageBind（[2305.05665] ImageBind: One Embedding Space To Bind Them All [1]），不过当时还处于大模型的早期阶段，效果并不是特别出色。

本文中我们提到的多模态模型主要指狭义的 Language + Vision 模型，也是目前最常见的。Language + Vision 多模态模型有两种常见范式，如下图 Figure 2 所示。本质还都是由 Vision Encoder 将图像/视频帧编码为 Image Token，并和 Text Token 一起输入 LLM 模型，用于理解或生成。不同的点是融合的方式：

左侧（Decoder-Only）：Image Token 和 Text Token 一起作为 Input Token 输入 LLM，在模型结构上与常见的 LLM 没有本质区别。这种方式也是当前最常见的。

优势：可以充分利用预训练好的 LLM 模型，适配的成本低，效果好。
劣势：常见场景的 Image Token 比较多，并且图像越多，分辨率越高也往往意味着越多的 Image Token，导致较大的 Inference 成本。

右侧（Cross-Attention）：在 Transformer Block 中添加 Cross-Attention 模块，Image Token 只在 Cross-Attention 模块实现与 Text Token 的信息交互。Meta 去年的LLaMA 3（[2407.21783] The Llama 3 Herd of Models [2]）中采用了这种Cross Attention 的方案，但是在最近的LLaMA 4（The Llama 4 herd: The beginning of a new era of natively multimodal AI innovation [3]）中放弃了这种方案，转向上述的早期模态融合方案。

优势：即使 Image Token 比较多，也不会明显增加 Inference 的成本。
劣势：训练和适配的成本较高，并且相应的效果可能不如上述早期融合方案。

除了上述的方案外，也有一种不太主流的大统一方案，如下图 Figure 2 所示，EVE（[2406.11832] Unveiling Encoder-Free Vision-Language Models [4]）中作者采用了无 Vision Encoder 的方案，增加一个轻量级的 Patch Embedding Layer 将 Image Patch 直接转换为 Image Token，并和 Text Token 一起输入统一的 Large Vision-Language Model 中。EVE 也不是最早采用这种范式的，更早可以追溯到Fuyu-8B: A Multimodal Architecture for AI Agents [5]。

2.2.2 Vision 模态分离

最近的论文 ModServe（[2502.00937] ModServe: Scalable and Resource-Efficient Large Multimodal Model Serving [6]）中，作者们对上述的两类主流 LMM 架构（Decoder-only 和 Cross-attention）在真实生产负载下作了详尽的系统层面分析和实验，获得了若干深刻的洞察，揭示了 Inference 瓶颈、各阶段资源特征以及生产环境中 LMM 请求的流量模式。

洞察一：各阶段性能异质，Vision Encoder 成为 TTFT 瓶颈。
洞察二：Vision 与文本处理可以并行，解耦有巨大加速潜力。
洞察三：架构不同（Decoder-Only 和 Cross-Attention），LLM 后端的 Prefill 延迟差异巨大。
洞察四：Batching 策略、并行度对每一阶段的影响大不相同。
洞察五：单体架构限制了分阶段独立伸缩，导致大幅资源浪费。
洞察六：路由与排队策略必须模态感知，否则极易形成 HoL 阻塞和尾部延迟。
洞察七：动态负载需按 Token 级吞吐速率而非简单 QPS 衡量与扩缩容。

总的来说，Inference 系统面临如下挑战：

多阶段 Inference 流水线：典型的 LMM 推理包含 Vision 预处理、Vision 编码和 LLM 后端生成等多个环节，计算特征与资源消耗各不相同。

预处理：包括 Image/Video 下载（网络密集型）和 Image/Video 解码和预处理（比如 Crop、Resize 等，通常使用 CPU，是 CPU 密集型）。
Vision 编码：将 Image 和 Video 帧编码为 Vision Token，通常使用 Vision Encoder 模型，GPU 密集型。此外，不需要缓存中间状态（比如 KV Cache），因此对 GPU 显存的需求不大。
LLM 后端：分为 Prefill 和 Decoding 阶段，计算特性稍有不同，Prefill 通常是 GPU 计算密集，而 Decoding 通常是 GPU 内存密集，并且往往需要分布式。

多模态输入的异质性：不同请求间输入内容（图片数、文本长度）和流量模式变动极大，会带来负载预测和资源管理的挑战。
现有 Inference 服务系统的局限：主流 LMM 服务往往采用“单体”架构，即所有子模块（Vision、Text 等）在同一进程（设备）内共同调度、伸缩，难以针对具体环节和突发流量实现精细资源分配，导致高延迟和资源浪费。

为此，ModServe 论文中作者提出了对应的 ModServe 架构，如下图 Figure 13 所示：

将 LMM Inference 分模块化解耦，Vision 和 Text 相关计算在不同实例资源上独立调度和优化。
支持自适应自动伸缩、模型切分与 Batching 策略，动态匹配真实时变流量，降低成本并精准满足延迟 SLO。
设计模态感知调度与路由，有效应对图像流量突发、请求异构性，降低尾部延迟。

PS：尽管 ModServe 不是最早探讨模态分离研究的，但其在系统层面的深入分析非常具有代表性。

2.3 PD 分离

2.3.1 早期研究

Google 早在 22 年 11 月（[2211.05102] Efficiently Scaling Transformer Inference [7]）就对 Prefill 和 Decoding 进行了深入和系统的分析：

Prefill 阶段：输入序列（通常为用户输入上下文/提示）全部一次性送入模型，可以对所有输入 Token 同时并行计算，也就是高度并行化，通常是 Compute Bound。

Decoding 阶段：模型一步步生成新 Token，每生成一个 Token，都需要依赖前面（包括Prefill 阶段）已生成/输入的所有 Token，因而必须严格序列化，也就是并行化很低，通常是 Memory Bound。

如下图 Figure 1 和 Table 3 所示，Prefill 的 Cost 相比 Decoding 更低，并且 Prefill 在比较小的 Batch Size 就能达到比较高的 MFU，而 Decoding 阶段往往需要非常大的 Batch Size 才能达到比较大的 MFU。如红框所示，Prefill 在 Batch Size 16-32 左右的 MFU 和 Decoding 阶段 Batch Size 512-1024 的 MFU 相当。

不过上述工作中并没有真的将 Prfill 和 Dcoding 进行分离部署。直到 23 年 11 月，微软和华盛顿大学提出 Splitwise（[2311.18677] Splitwise: Efficient generative LLM inference using phase splitting [8]），其为 LLM Inference 不同阶段选择不同的 GPU 类型。Prefill阶段为 Compute 密集型，选择高算力 GPU，而Decoding阶段为 Memory 密集型，使用算力不是特别强而访存带宽比较大的 GPU。同时为了两个阶段 KV Cache 的共享，需要在 GPU 间有高速的 IB 网络互联。

如下图 Figure 10 所示为 Splitwise 的架构概览。Splitwise 会维护两个独立节点池：Prompt Pool和Token Pool，用于 Prefill 和 Decoding 的处理。第三个混合池（Mixed Pool）根据工作负载的情况来扩展 Prompt Pool 和 Token Pool。

当新的推理请求到达时，调度进程会将其分配给一对节点（Prompt 和 Token）。Prompt 节点还会将 KV Cache 发送给Token 节点。在 Token 节点上使用 Continuous Batching，以最大限度地提高其利用率。
为了满足 SLO 并避免在较高负载下由于碎片而导致性能突降，Splitwise 维护了一个特殊的 Mixed Pool，该 Pool 根据输入和输出 Token 的请求速率和分布动态增长和收缩。Mixed Pool 中的节点仍然保留其作为 Prompt 节点或 Token 节点的标记，并在其挂起队列中没有相反类型的任务时返回其原始 Pool。

Splitwise 使用分层的两级调度，Cluster 级调度（CLS）进程 1 负责将输入请求路由到特定节点并重新调整节点的用户。Machine 级调度（MLS）进程 2 维护挂起的队列并管理每个节点上的批量请求。在较低的请求速率下，目标是在 Splitwise 中实现更好的延迟，而在更高的请求速率下，目标是避免由于 Prompt 节点和 Token 节点池之间的碎片而导致的任何性能或吞吐量降低。

2.3.2 MoonCake

24 年中期，Moonshot AI 团队与清华大学共同提出 MoonCake（[2407.00079] Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving [9]），它是 Kimi（Moonshot 旗下 AI应用）使用的核心 LLM Inference 系统。该系统以 KV Cache 为中心，采用解耦（Disaggregated）架构，专为支撑多样化、海量、具有高时延需求的 Inference 流量而设计。由于其已经在生成环境大规模部署落地，在国内引起了大规模讨论。

MoonCake 的核心创新点包括：

KVCache 为中心的调度与存储（KV Cache-centric）：将模型 Inference 过程中的 KV Cache 单独管理、分片、调度和分布式存储，实现不同请求之间的最大化重复利用，减少重复计算。
Prefill 与 Decoding 阶段解耦：Inference 流程解耦为 Prefill 与 Decoding，分别由单独的异构节点池负责，实现各自资源的最优调度。
分布式 KV Cache 池：充分利用 GPU 集群中未被完全利用的 CPU/DRAM/SSD 资源，通过 RDMA 实现节点间 KV Cache 高速转移与副本复制，极大提升 Cache 命中率与带宽利用。
Cache 感知与超载导向调度算法：结合 KV Cache 分布和机器负载，实现“最大重用+最优负载”调度，针对高并发、高负载场景，还引入预测驱动的请求提前拒绝机制，保障 SLO 并减少无效资源消耗。
流水线分块 Prefill 与层级 KV Cache 转存：对长上下文输入，采用分块+流水线 Prefill（Chunked Pipeline Parallelism），降低 TTFT；同时 Prefill 过程中 KV Cache 分层异步加载/存储与转移，最大程度释放宝贵 VRAM 空间。

如下图 Figure 1 所示为其主要架构和流程：

Conductor（全局调度器）：根据 KV Cache 分布与预估请求负载，智能选择 Prefill 节点与 Decoding 节点。
KV Cache 复用：输入经过 Token 分块，优先复用已有 KV Cache 块，需远程拉取时平衡吞吐与时延。
Prefill 分块流水处理：对长输入流按 Chunk 分发多节点串行处理，计算与 KV Cache 传输可并行化，显著降低延迟。
KV Cache 传输与存储：KV Cache Pool 子模块通过 RDMA 在 CPU 内存/GPU 显存/SSD 间实现 KV Cache 高效传递与副本冗余，支持冷热数据分级与 Cache 淘汰。
Decoding 与批处理：Prefill 结束后，KV Cache 转到预选 Decoding 节点，加入 Continuous Batching，高效生成后续 Token。

2.3.3 DeepSeek

24 年底，DeepSeek V3（[2412.19437] DeepSeek-V3 Technical Report [10]）发布，其中的 PD 分离部署及专家并行（Expert Parallelism）优化进一步引起大家对分离式部署方案的讨论。其在 H800 集群上部署 DeepSeek-V3，为了同时确保在线服务的 SLO 和高吞吐量，采用 Prefill 阶段和 Decoding 阶段分离部署。

Prefill 阶段：最小部署单元由 4 个节点组成，共 32 个 H800 GPU。

Attention 部分采用 4 TP 结合 SP（Sequence Parallelism），并与 8 DP（Data Parallelism）相结合。其较小的 TP 规模（4）限制了 TP（Tensor Parallelism）通信的开销。
MoE 部分采用 32 EP，确保每个专家处理足够大的 Batch Size，从而提升计算效率。

为了实现 MoE 部分不同 Expert 间的负载均衡，需确保每个 GPU 处理大致相同数量的 Token。引入了冗余 Expert 部署策略，即对高负载 Expert 进行复制并冗余部署。高负载 Expert 基于在线部署期间收集的统计数据检测并定期调整（如每 10 分钟一次）。确定冗余 Expert 集合后，根据观察到的负载情况，在节点内的 GPU 间精心重新安排 Expert，力求在不增加跨节点 All2All 通信开销的前提下，尽可能平衡各 GPU 的负载。对于 DeepSeek-V3 的部署，作者为 Prefill 阶段设置了 32 个冗余 Expert。每个 GPU 除了原本承载的 8 个 Expert 外（256/32），还将额外承载一个冗余 Expert。

此外，在 Prefill 阶段，为了提高吞吐量并隐藏 All2All 和 TP 通信的开销，同时处理两个计算工作量相近的 Micro Batch，将一个 Micro Batch 的 Attention 和 MoE 计算与另一个 Micro Batch的 Dispatching 和 Combining Overlap 执行。

Decoding 阶段：将共享 Expert 视为路由 Expert 之一。由此视角出发，每个 Token 在路由时会选择 9 个 Expert，其中共享 Expert 被视为高负载 Expert，始终被选中。Decoding 阶段的最小部署单元由 40 个节点组成，共 320 H800 GPU。

Attention 部分采用 4 TP 结合 SP，并与 80 DP 协同工作，而 MoE 部分则采用 320 EP。
MoE 部分，每个 GPU 仅承载一位 Expert，其中 64 个 GPU 负责承载冗余 Expert 及共享 Expert。Dispatching 与 Combining 部分的 All2All 通信通过 IB Direct P2P 传输实现，以实现低时延。此外，还利用 IBGDA 技术进一步降低时延，提升通信效率（PS：DeepSeek 开源了对应的代码库DeepEP: an efficient expert-parallel communication library [11]）。

与 Prefill 阶段类似，基于在线服务的 Expert 负载统计数据，在特定间隔内定期确定冗余专家集合。然而，由于每个 GPU 仅承载一位 Expert，因此无需重新安排 Expert。

2.3.4 NVIDIA Dynamo

Dynamo（Dynamo Inference Framework | NVIDIA Developer [12]）是 NVIDIA 新开源的 Inference 服务框架（GitHub - ai-dynamo/dynamo: A Datacenter Scale Distributed Inference Serving Framework [13]），专为生成式 AI 和大模型的大规模部署而设计。Dynamo 同样支持 Prefill 和 Decoding 的分离式部署，可以无缝兼容常见的 Inference Engine，比如 TensorRT-LLM、vLLM 和 SGLang 等。其核心模块采用 Rust 编写以获得高性能，同时提供 Python 接口以便灵活控制。

如下图 Figure 1 所示为 Dynamo 的架构示意图，其中包含多个组件，每个组件都可以独立伸缩：

包含 4 层：

API Server：接收用户请求，兼容 OpenAI API 等主流接口，也会提供相应的 Metric 信息。
Smart Router：根据实际指标（比如每个 Worker 的 KV Cache 命中率和负载）对请求进行调度，尽可能平衡 KV Cache 复用和负载均衡。
Disaggregated Serving：真正的执行引擎，分为 Prefill Worker 和 Decoding Worker（PD 分离，也许后续还会有 Vision Worker）。
NVIDIA Inference Transfer Engine：也就是 NIXL（NVIDIA Inference Xfer Library），这是一个专门为 Inference 场景设计的高性能异步数据传输引擎。Prefill Worker 和 Decoding Worker 之间的 KV Cache 传输需要通过 NIXL。

其他组件：

Planner和Event Plane组件负责动态资源调度和监控。系统通过一个事件总线收集实时指标（例如请求队列长度、Worker 利用率等），供 Planner 参考。当检测到负载变化时，Planner 可实时增加或减少 Prefill/Decoding Worker 的数量，实现弹性扩展。
KV Cache Manager：Dynamo 还提供了一个全局 KV Cache Manager，负责跨节点维护和调度所有 KV Cache。KV Cache Manager 记录全局的 Cache 命中信息，并支持多层次内存卸载：当 GPU 显存不足时，将冷数据卸载到 CPU 内存、SSD 或远程存储等更便宜的存储介质上。这种分级 Cache 策略使得系统可以支持比单机显存容量更长的上下文长度，同时保持较低的时延。

2.3.5 其他

PD 分离的推理系统还很多，这里就不一一介绍，其思路基本类似，可以参考：

[2406.17565] MemServe: Context Caching for Disaggregated LLM Serving with Elastic Memory Pool [14]
[2406.01566] Helix: Serving Large Language Models over Heterogeneous GPUs and Network via Max-Flow [15]

2.4 Attention & MoE 分离

MoE 模型在扩展 LLM 能力方面展现出巨大潜力，既能提升性能又可降低计算复杂度。然而，其稀疏激活架构使得 Inference 过程中 FFN 从 Compute Bound 转变为 Memory Bound，导致 GPU 利用率显著下降并增加运营成本。

字节跳动提出 MegaScale-Infer（[2504.02263] MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism [16]）：一个高效且经济的 MoE 模型服务系统。该系统在 LLM 的Decoding 阶段，对各模型层中的 Attention 模块与 Expert 模块解耦，实现独立扩展、定制化并行策略及异构部署。

除此之外，MegaScale-Infer 创新性地采用 Ping-Pong 流水线并行技术，将请求 Batch 划分为 Micro-Batch 并在 Attention 与 Expert 模块间动态调度以完成 Inference。结合各模块专属的模型并行策略，该系统可以有效隐藏通信开销并最大化 GPU 利用率。针对解耦后的 Attention 与 Expert 模块特性，为最小化数据传输开销（如 Token Dispatch），MegaScale-Infer 实现了高性能 M2N 通信库，消除了不必要的 GPU-CPU 数据拷贝、Group 初始化开销及 GPU 同步等待开销。

如下图 Figure 3 所示为 MegaScale-Infer 的架构，作者依然会采用常见的 PD 分离方案，也就是 Prefill 和 Decoding 有单独的集群。本文的重点是 Decoding 阶段，进一步对 Decoding 集群进行切分，包含 Attention 节点和 Expert 节点：

Attention 节点：

每个节点包含全部 Attention 参数，采用 TP（Tensor Parallelism）。

Expert 节点：

每个节点多个 GPU 存储一个 Expert，采用 TP。
所有专家节点一起组成一个 EP（Exert Parallelism）组。

TP：节点内 TP 可以充分利用高带宽的 NVLink 通信。

为了解决资源浪费问题，作者引入了Ping-Pong 流水线并行方案，与分布式训练中的流水线并行思路完全类似。如下图 Figure 4 所示，类似 Interleaved 1F1B，不过只有两个设备，共 2*L 个 Stage（L 表示层数，每层都是 2 个 Stage）；此外，Stage 间的通信方式也稍有不同。

采用分离式架构后，Attention 和 Expert 是相互独立的节点，并且数量可能不同。假设 M 个 Attention 节点，N 个 Exert 节点，则 Dispatch（A2E）变成 M2N 操作，而 Combine（E2A）变成 N2M 操作。为此，作者也开发了高效的 M2N 通信库。

三、分布式并行 Inference 系统

3.1 概述

在单体 Inference 系统中，由于模型较大，使用单一设备进行 Inference 往往会导致 Latency 过高、性能不加，甚至出现无法部署的情况。而分布式并行技术可以有效的缓解上述问题，通过合理的并行策略，可以充分利用分布式计算资源，提高系统的吞吐量和响应速度。

虽然分离式 Inference 系统可以在一定程度上缓解了上述问题，但依然无法完全避免，这也是为什么在上述的分离式系统中还往往穿插着各种分布式并行技术。

3.2 Tensor Parallelism

3.2.1 原理

TP 是大模型 Inference 中最常使用的分布式并行策略。其将模型权重矩阵沿特定维度切分，这样 Tensor 计算可以分散到多个设备上并行执行，这也是其能降低时延的最主要原因。如下图所示为 MLP 和 Self-Attention 中 TP 的常见切分方案：

使用 TP 也会带来一定的通信开销，在 TP 的特定阶段通常需要引入额外的 AllReduce 通信。对于标准的 Transformer Layer 而言，如果只是采用 TP 分布式 Inference，则每一层会引入 2 次 AllReduce 通信，并且常见的实现中这些 AllReduce 通信并不能被很好的 Overlap。也有一些列工作在优化这个问题。

3.2.2 NVIDIA MultiShot

NVIDIA 在 TensorRT-LLM 中利用 NVSwitch 的 MultiCast 能力对 AllReduce 进行优化（3x Faster AllReduce with NVSwitch and TensorRT-LLM MultiShot | NVIDIA Technical Blog [17]），可以有效降低 AllReduce 操作的时延（降低时延和增加吞吐是非常不一样的场景，NCCL 中的 AllReduce 更关注吞吐，而 LLM Inference 中的 AllReduce 更希望降低时延）。

TensorRT-LLM 中的 MultiShot 实际上是真正的将 AllReduce 分成 ReduceScatter + AllGather，并且都进行了相应的优化。（PS：NVIDIA 的 Blog 中没有详细介绍这个优化，下面是我们的推测）

如下图所示为 ReduceScatter 的优化：

如下图所示为 AllGather 的优化：

3.2.3 美团 Flash Communication

美团在[2412.04964] Flash Communication: Reducing Tensor Parallelization Bottleneck for Fast Large Language Model Inference [18]中提出一种两步量化策略，以替代传统的 Ring AllReduce 方法，称为 Flash AllReduce。

如下图 Figure 6 展示了 Flash Communication 的通信原理：

首先，将每个 GPU 上的激活值按 Rank 的数量进行划分。
在激活值上进行细粒度量化后，执行All2All通信（与我们猜测的 TRT-LLM 的 MultiShot 实现类似），使得每个设备接收其规约所需的计算负载。当然，接收后也需要反量化操作。
在设备内完成 Reduce，不涉及通信操作。
对得到的结果再次进行量化以加速传输。然后进行AllGather以汇总所有结果，并在每个设备上进行反量化以恢复浮点数值。

当然，量化可能影响精度，这也是该方案的最大问题。

3.2.4 字节跳动 Flux

字节跳动在[2406.06858] FLUX: Fast Software-based Communication Overlap On GPUs Through Kernel Fusion [19]中提出 Flux，其将通信和计算操作分解为更细粒度的操作，并进一步融合成更大的 Kernel，从而在不损害 Kernel 效率的前提下有效隐藏通信。在融合 Kernel 的情况下，Flux 有望重叠高达 96% 的通信时间。

在 Flux 中，同样是将 ReduceScatter 与 GEMM 进行 Overlap 和 Kernel 融合。ReduceScatter 操作可以分解为一个 AlltoAll 操作和一个 local 的 Reduce 操作。这里只有 AlltoAll 需要设备间通信，因此，将 All2All 融合到 GEMM 的尾部通常足以 Overlap 通信。与 ReduceScatter 不同，AllGather 的实现采用首部融合方式，直接嵌入 GEMM Kernel 中。具体而言，AllGather 的信号检查功能被融合至 GEMM 内核的前序阶段。

如下图 Figure 5 展示了 ReduceScatter 中 Overlap 之间的主要差异：

现有 Overlap 方案 Tm理论上可能比原始方法 Tc执行得更快，但通常情况下，Tm仍慢于原始 GEMM 操作时间 Tg。主要原因在于，将一个 GEMM Kernel 拆分为一系列较小的 GEMM Kernel 会降低 GPU GEMM 的执行效率。GEMM 通常需要合理大小的矩阵才能充分利用 GPU 的计算能力。这些具有数据依赖性的小型 GEMM 操作序列进一步阻碍了 GEMM Kernel 通过 GPU 多路复用技术并行运行，因此，Tensor 并行度越高，GPU 上的 GEMM 效率越低。
相比之下，作者提出的技术不存在上述限制。其Tf能够在极小开销下实现与原始 GEMM 操作 Tg相当的性能。其细粒度分解策略完美契合现代 GPU 设计特性，即通过上下文切换的 Warp 和数百个在 SM 间并发活跃的 Warp 来隐藏延迟，如下图 Figure 5 底部所示。最终，作者的方法在不影响 GEMM 计算效率的前提下，仅在执行末尾引入少量通信开销。

3.2.5 字节跳动 TileLink
在上述的 Flux 中需要手写 Kernel，成本比较高。为此，字节跳动进一步提出了 TileLink（[2503.20313] TileLink: Generating Efficient Compute-Communication Overlapping Kernels using Tile-Centric Primitives [20]），旨在高效编译并生成计算-通信 Overlap 执行的 Kernel。TileLink 由前端（Frontend）和后端（Backend）构成：

在前端，系统通过以 Tile 为中心的原语将通信与计算的设计空间解耦并建立关联。
在后端，将这些原语转换为底层指令，整合通信与计算组件以实现 Overlap 执行。

我们在之前的文章中已经详细介绍过，这里不再赘述。最近作者也开源了相应的代码，具体可以参考：GitHub - ByteDance-Seed/Triton-distributed [21]。

3.3 Pipeline Parallelism

3.3.1 原理

PP 通过将模型按层切分到不同设备上，形成 Inference 流水线，是处理超大规模模型的另一种分布式并行策略。

然而，对于每个 Query/Batch 而言，PP 中的不同层仍是串行执行，在系统没有明显瓶颈时并不会降低时延，因而在 Online 场景用用的并不是特别多，反而由于切分方式简单、通信开销少等优势在 Offline 场景广泛使用。

3.3.2 TP + PP 混合——微软 DeepSpeed Inference

微软在 DeepSpeed Inference（[2207.00032] DeepSpeed Inference: Enabling Efficient Inference of Transformer Models at Unprecedented Scale [22]）中探讨了各种分布式策略混合的部署方案。也明确探讨了 TP 和 PP 的优劣：

优点：高带宽利用率，相邻设备间通信延迟低（例如，单机多卡通过 NVLink 通信）
局限：跨节点大规模扩展时，受限于带宽瓶颈和 AllReduce 通信；无法单独用来突破单节点内存限制。

优点：适合多节点大规模扩展，通信只发生在相邻 Pipeline Stage 间，通讯量小，易于横向扩展；可以突破单节点内存上限。
局限：推理时存在 Pipeline Bubble（气泡），尤其在自回归生成场景，每步都要同步。自回归依赖导致不可完全并行，Pipeline 难以100% 饱和；需要对 Batch size/Micro-batch 数量做精细调度才可最大化利用率，否则延迟较高。

3.3.3 TP + PP 混合——北大 FastServe

北大在 FastServe（[2305.05920] Fast Distributed Inference Serving for Large Language Models [23]）中也探索了 TP + PP 进行混合并行 Inference 的方案。其没有通过实验对 TP 和 PP 的性能进行详细的对比，不过也确实提到了各自的优劣，也重点说明当不得不进行多机多卡分布式 Inference时，考虑到跨节点通信成本很高，可以采用 TP + PP 的混合方案。

3.4 Expert Parallelism

3.4.1 原理

MoE 模型显著提升了参数规模和表达能力，其关键做法是将 FFN 层由多个 “Expert（FFN）” 的组合，每次只激活其中少数 K 个 Expert，“稀疏” 地利用更大的参数空间。然而，MoE 模型参数极大，单一 DP 或 TP 已无法高效扩展和利用资源。

MoE 结构进一步进一步放大了 Decoding阶段的 Memory Bound 问题。这主要是每次只激活个别专家，假设激活专家与总专家的比例是 1/16：

对于Dense 模型，可能在 Batch Size 为 156（A100：312T FLOPS / 2TB/s = 156）即可以达到 Compute Bound。
对于MoE 模型，需要 Batch Size 为 156*16=2496 才能达到 Compute Bound，并且由于负载不均，可能会更加严重。

EP 就是为了解决上述问题，其把每个 Expert 分别放在不同 GPU 上。每个 GPU 只负责一部分 Expert。这样一个 Batch 的 Token 只被路由（分配）到需要激活的 Expert，从而减少显存需求，同时每个设备都有更大 Batch Size 的可能，帮助提升 GPU 利用率。

3.4.2 DeepSpeed Inference

微软在 DeepSpeed Inference（[2207.00032] DeepSpeed Inference: Enabling Efficient Inference of Transformer Models at Unprecedented Scale [24]）中创新性地将 EP 与 TP 和 DP 结合，通过新的通信和 Kernel 优化，实现稀疏大模型的极致扩展。

3.5 Sequence Pipeline Parallelism

3.5.1 背景

随着 LLM 应用拓展，如论文、书籍总结、长电影分析等， Inference 时对上下文长度的需求已提升到百万级甚至千万级 Token。然而，现有的大部分 Inference 系统在面对这种场景时存在显著瓶颈：

自注意力计算复杂度为 O(n^2)，计算和内存需求都飙升。
现有 Inference 系统（如 LoongServe）容易出现头阻塞（Head-of-Line, HOL）：短请求被长请求严重阻塞。
训练时用到的一些长上下文并行技术（如 Ring Attention/Context Parallelism）在 Inference 阶段并不适用，特别是面对变长请求和对时延 SLO 严格要求时。

为了解决上述问题，一系列工作将序列并行（Sequence Parallelism）的思路引入到了 Inference 中，并将其与 Pipeline Parallelism 的思路结合，提出了 Sequence Pipeline Parallelism（也称作 Chunked Pipeline Parallelism）的方案。

3.5.2 MoonCake Chunked Pipeline Parallelism

我们在之前的 MoonCake PD 分离中提到，MoonCake 实现了 Chunked Pipeline Parallelism，也就是对长上下文输入，采用分块+流水线 Prefill，降低 TTFT。具体过程如下图所示（C 表示 Chunk，L 表示 Layer，这里表示模型包含 6 个 Layer，Request 分为 4 个 Chunk）：

Request 切分：将长上下文 Request 的输入 Token 按照预设的 Block 大小（如 1024）切分成多个 Chunk。
节点分组、流水线分配：将 Prefill 节点划分为一组，采用流水线方式处理各 Chunk。假如分为 4 个节点，第一个节点处理第一个 chunk，处理结束传至第二节点，以此类推，每个节点之间只有 Chunk 交接点存在通信。
并行执行、流水线推进：各节点可并行处理属于自身的 Chunk，有效利用集群的并行能力并最大化吞吐。

其中每个 Chunk 的前向计算需要依赖前一个 Chunk 同层的 KV Cache，因为自回归模型生成某 Token 的输出时，Attention 的 “key/value” 都必须包含前序所有 Token 的上下文。所以第 i 个 Chunk 进入第 L 层时，必须等第 i−1 个 Chunk 在同一层 L 的 KV Cache 计算完成。换言之，流水线是以 Chunk 维度并行，但跨 Chunk 内有 “层级同步” 依赖，如上图中的箭头所示。虽然需要 “层级同步”，但是其成本要比标准序列并行中的全局同步成本要低得多，并且可以和相邻层的计算充分 Overlap。

当然 MoonCake 不是首先提出这种方案的，早在 21 年 2 月的[2102.07988] TeraPipe: Token-Level Pipeline Parallelism for Training Large-Scale Language Models [25]中就提到过类似思路。

3.5.3 MoonCake Sequence Pipeline Parallelism

Microsoft 在[2409.17264] Medha: Efficiently Serving Multi-Million Context Length LLM Inference Requests Without Approximations [26]中也提出了类似的方案。具体来说，Medha 系统提出三大核心创新，打造了 3D 并行 Inference 架构，实现了千万级 Token Inference 的高效率和低时延。

自适应分块（Adaptive Chunking）+松散调度（Slack-aware Scheduling）

核心思想：把大的 Prefill 请求拆成 Chunk，使用 Slack-aware 优先级调度算法排队处理，能实现在长请求处理中灵活 “穿插” 短请求，不再出现长请求堵死管道。
Slack-aware（紧迫度优先）：优先处理 “剩余时间比最少” 的请求，保障 SLO。

序列流水并行（Sequence Pipeline Parallelism, SPP）

与传统 PP 相比：Medha 发现长请求 Prefill 各 Chunk 间实际上是“无依赖”的（不像 Decoding 有自回归依赖），因此可以对 Prefill 各 Chunk 做 Pipeline “密集排布”，让每个 Chunk 在流程中一阶段结束后，马上用新 Chunk 补位，因而 Prefill 总时延几乎能随 Pipeline 深度线下缩短，显著降低首 Token 时延 (TTFT)。
效能显著：在 128 张 H100 上 Prefill 百万 Token，TTFT 降至 15s 以内。

KV Cache 并行（KV Cache Parallelism, KVP）

核心思想：Decode 阶段主要瓶颈在于大量 KV Cache 读取带宽。Medha 提出 KVP，把 KV Cache 沿序列切分，各 Server 持有部分 KV，每次 Decode 将 Q 片段广播后，聚合 Partial Attention 结果，实现并行 Decoding，加速输出 Token 速率（TPOT）。
优势：KVP 通信开销与 “Query Token 数” 而非 Cache 长度相关，适宜大上下文。

如下图 Figure 12 是 Medha 对应的 3D 并行 Inference 系统：

PS：Meta 也在[2411.01783] Context Parallelism for Scalable Million-Token Inference [27]中提出了类似的方案，在 128 个 H100 GPU 实验，LLaMA 3 405B 模型 1M Token 的 Inference 时间仅有 77s，达到 93% 的并行率以及 63% 的 FLOPs 利用率。

四、分布式 KV Cache

4.1 概述

现代大模型（如 GPT-4、Gemini、LongRoPE 等）支持越来越长的上下文窗口，序列长度可达几十万甚至上百万 Token。而当前的主要 LLM 都是 Decoder Only 的 Transformer 模型，其自回归特性需要 KV Cache 的存在，而 KV Cache 随序列长度线性增加，单卡或单节点可能无法容纳足够的 KV Cache。

除此之外，即使 Request 结束，也可以保留热点 KV Cache 用于 Prefix Caching 的加速，进一步加剧 KV Cache 存储的压力。比如，LLaMA-7B 模型，在 Context 长度为 1000K 时，其 KV Cache 可达数百 GB，远超单 GPU 的显存。为了解决这个问题，分布式 KV Cache 应运而生。

4.2 阿里 DistKV-LLM

阿里在[2401.02669] Infinite-LLM: Efficient LLM Service for Long Context with DistAttention and Distributed KVCache [28]中提出了DistAttention，这是一种分布式注意力算法，可将 KV Cache 分割为更小的、可管理的单元，从而实现注意力模块的分布式处理和存储。基于此，作者也提出了DistKV-LLM，它是一个分布式 LLM Serving 系统，可以动态管理 KV Cache，并有效地协调整个数据中心中所有可以访问的 GPU 显存和 CPU 内存，确保其可以适应各种上下文长度，提供高性能的 LLM 服务。

如下图所示为DistKV-LLM的概览，当 LLM 服务实例由于 KV 缓存增加而遇到内存不足时，DistKV-LLM 会主动识别并借用其他容量过剩的设备中的可用内存空间，这种自动化机制是通过两个主要组件（rManger 和 gManager）的协作操作来实现的：

gManager充当中心化管理器，维护所有实例的全局内存信息，如下图左图所示。每个实例定期向 gManager 发送心跳信号，发送有关其剩余可用内存空间的更新信息。gManager 利用这些信息构建了一个详细的表，称作Global Debt Ledger。
rManger提供统一的 API 接口，用于本地和远程内存操作，如下图右上所示。这些操作包括：

为新生成的 KV Cache 分配 Physical rBlock，并在不再需要时释放。
在收到 local 或 remote 的内存分配请求时，rManager 会查询 rBlock 表，以确定第一个可用的 Physical rBlock 空间。
在没有足够的空间时，rManager 会启动从其他实例空间借用过程，如下图右下所示。此时，如果分配请求来自 remote 实例，则 rManager 会返回错误响应，表示 remote 分配不可用，避免陷入死循环。
可以为分配给 remote 实例的 rBlock 数量设置上限，避免抢占 local 分配的空间。当然，该配置需要通过实验确定，并配置为超参。

4.3 Moonshot AI Transfer-Engine

Moonshot AI 在 Github（GitHub - kvcache-ai/Mooncake: Mooncake is the serving platform for Kimi, a leading LLM service provided by Moonshot AI. [29]）开源了 Transfer Engine 的具体实现，也在Mooncake: Trading More Storage for Less Computation [30]中有简单的介绍。

Transfer Engine 是 MoonCake 项目的核心组件，支持高速数据传输，特别是在分离架构中，专注于 KV Cache 数据的复用、管理和传输，以提高可复用性和效率。旨在解决分布式系统中数据移动的瓶颈，提升系统整体性能。Transfer Engine 能处理多种介质，包括 Local DRAM、Local GPU VRAM、Remote DRAM、Remote GPU VRAM 和 Remote NVMe 等，满足复杂分布式环境的需求。

Transfer Engine 围绕两个核心抽象设计：

Segment：表示一个连续的地址空间，支持远程读写，可分为 RAM Segment（非持久性存储，如 DRAM 或 VRAM）和 NVMe-of Segment（通过 NVMe over Fabrics 的持久存储）。
BatchTransfer：封装操作请求，负责在不同 Segment 的非连续数据空间之间同步数据，支持异步读写操作，类似于 AllScatter/AllGather，但更灵活。

Transfer Engine 实现了拓扑感知路径选择机制：各节点在处理请求前会生成拓扑矩阵并在集群广播，该矩阵根据内存注册时指定的类型，将网卡划分为不同内存类型的“首选”与“备选”列表。正常工作中会优先选择“首选”列表中的网卡进行传输。如下图 Figure 4 所示，若需要将 Local 节点中 Buffer 0（分配到 CPU:0）的数据传输到目标节点 Buffer 1（分配到 CPU:1），Engine 首先根据 Local 节点的拓扑矩阵确定 CPU:0 的首选网卡，并选定 mlx5_1 作为 Local 网卡。同理，基于目标内存地址选定目标网卡。为了最大化带宽利用率，单个请求的传输会被划分为 16KB 的切片，各个切片可能采用不同的传输路径，从而实现所有 RDMA 网卡的协同工作。

4.4 NVIDIA NIXL

我们在前面提到，NVIDIA 的 Dynamo 框架底层通过 NIXL（NVIDIA Inference Xfer Library）实现 KV Cache 的传输。NVIDIA 也开源了相应实现：GitHub - ai-dynamo/nixl: NVIDIA Inference Xfer Library (NIXL) [31]。NIXL 是专为分布式 AI Inference 场景设计的高性能 P2P 通信库，用于多节点/GPU Inference 框架中的数据传输。

如下图所示，NIXL 以 Transfer Agent 为核心，每个节点上通常都会创建一个Agent，负责管理该节点的 GPU、内存等存储资源，并同其他 Agent 协调数据传输。Agent 具有全局唯一表示，并由上层 Inference 平台分配。整个架构假定有一个上层协调进程负责 Inference 调度、内存分配、用户请求等，并负责调用 NIXL 接口以及在 Agent 之间交换元数据。

NIXL 位于 Inference 框架和物理通信层之间，为 Inference 框架提供所需的数据平面接口，其设计包含 3 个关键抽象组件：

Memory Section（内存区）：对内存和存储进行统一抽象。内存区由多个地址范围（segment）组成，支持类型包括 CPU DRAM、GPU HBM、NVMe-of、对象存储、文件等。每个内存区包含 Local 段信息和 Remote 访问标识，方便不同 Agent 间的数据访问。
Transfer Backend Interface（传输后端接口）：用于封装不同通信后端（如 UCX、GPUDirect Storage，S3 等）的具体实现。每种后端在 Agent 初始化时注册，Agent 会根据源/目标内存类型和双方可用后端，自动选择最优的传输路径。
Metadata Handler（元数据处理）：管理 Agent 之间传输所需的元信息，包括每个后端的连接信息和各 Memory Section 的远程标识符。

4.5 火山引擎-分布式 KV
前段时间火山引擎也发布了弹性极速缓存 EIC（Elastic Instant Cache），具体可以参考：推理加速新范式：火山引擎高性能分布式 KVCache （EIC）核心技术解读 [32]。做的事情都类似，这里不再赘述。

链载Ai

一、背景