在之前的技术博客中，我们介绍了低延迟和高吞吐场景的优化方法。对于生产部署，用户还关心在满足特定延迟约束的情况下，每个 GPU 的吞吐表现。本文将围绕“吞吐量-延迟”性能场景，介绍 TensorRT-LLM 分离式服务的设计理念、使用方法，以及性能研究结果。
初衷
LLM 推理通常分为上下文 (prefill) 和生成 (decode) 两个阶段。在上下文阶段，模型会根据提示词计算键值 (KV) 缓存，而在生成阶段，则利用这些缓存值逐步生成每一个 Token。这两个阶段在计算特性上存在显著差异。
LLM 推理请求的服务方式有两种：
- 聚合式 LLM 服务（在本文中有时也称为 IFB）：上下文和生成阶段通常在同一个 GPU 上运行。
- 分离式 LLM 服务：上下文和生成阶段通常在不同 GPU 上运行。
图 1. 聚合式 LLM 服务执行时间线
（该图片来源于 NVIDIA 团队论文：Beyond the Buzz: A Pragmatic Take on Inference Disaggregation，若您有任何疑问或需要使用该图片，请联系该文作者）
在聚合式 LLM 服务中，上下文和生成阶段共享相同的 GPU 资源和并行策略。这种资源耦合会干扰上下文阶段的 Token 生成速度，并且增加 Token 间延迟 (TPOT)，从而影响用户交互体验，正如图 1：聚合式 LLM 服务的执行时间线所示。聚合式 LLM 服务还强制两个阶段使用相同的 GPU 类型和并行配置，尽管它们的计算需求并不相同。在这种耦合约束下，优化某一项指标（如首 Token 生成时间 TTFT）往往会以牺牲另一项指标 (如 TPOT) 为代价。
图 2. 分离式 LLM 服务执行时间线
（该图片来源于 NVIDIA 团队论文：Beyond the Buzz: A Pragmatic Take on Inference Disaggregation，若您有任何疑问或需要使用该图片，请联系该文作者）
分离式服务通过解耦上下文阶段与生成阶段有效解决了上述问题。两个阶段可分别运行在不同的 GPU 池上，并采用各自优化的并行策略，从而避免了资源干扰。如图 2 所示，这种分离式的运行方式消除了上下文和生成阶段之间性能冲突，使得 TTFT 和 TPOT 能够分别进行针对性优化。尽管在两个阶段之间传输 KV 缓存块会带来一定开销，但在输入序列较长、输出长度适中的工作负载下，这种架构的优势依然十分显著——尤其是在此类场景中，IFB 干扰最为严重。
关于更多分离式服务的原理和设计细节，请参考这篇论文。
使用 TensorRT-LLM 执行分离式服务
使用 TensorRT-LLM 进行 LLM 分离式推理共有三种不同方法，每种方法在架构设计和运行特性上各具优势，适用于不同的部署场景。
trtllm-serve
trtllm-serve 是一个命令行工具，用于部署与 OpenAI 兼容的 TensorRT-LLM 服务。
使用 TensorRT-LLM 进行 LLM 分离式推理的第一种方法是通过 trtllm-serve 为每个上下文和生成实例分别启动独立的 OpenAI 服务。同时，trtllm-serve 还会启动一个称为“分离式服务器”的调度器，用于接收客户端请求，并通过 OpenAI REST API 将请求分发至对应的上下文或生成服务器。图 3 展示了该方法的工作流程。当上下文实例完成提示词的 KV 缓存生成后，会将结果返回给分离式服务器，其中包含提示词 token、首个生成 token 以及与上下文相关的元数据（称为 ctx_params）。这些参数随后被生成实例用于与上下文实例建立连接，并检索与请求相关的 KV 缓存块。
图 3. 使用 trtllm-serve 进行分离式服务
在以下示例中，上下文阶段的服务分别运行在端口 8001 和 8002 上，生成阶段的服务则分别在端口 8003 和 8004 上。分离式服务器监听端口 8000，用于接收客户端请求，并在上下文与生成阶段之间进行调度。
# Launching context servers
trtllm-serve TinyLlama/TinyLlama-1.1B-Chat-v1.0 --host localhost --port 8001 --kv_cache_free_gpu_memory_fraction 0.15 &> output_ctx0 &
trtllm-serve TinyLlama/TinyLlama-1.1B-Chat-v1.0 --host localhost --port 8002 --kv_cache_free_gpu_memory_fraction 0.15 &> output_ctx1 &
# Launching generation servers
trtllm-serve TinyLlama/TinyLlama-1.1B-Chat-v1.0 --host localhost --port 8003 --kv_cache_free_gpu_memory_fraction 0.15 &> output_gen0 &
trtllm-serve TinyLlama/TinyLlama-1.1B-Chat-v1.0 --host localhost --port 8004 --kv_cache_free_gpu_memory_fraction 0.15 &> output_gen1 &
# Launching disaggregated server
trtllm-serve disaggregated -c disagg_config.yaml# disagg_config.yaml
hostname: localhost
port: 8000
context_servers:
num_instances: 2
router:
type: round_robin
urls:
- "localhost:8001"
- "localhost:8002"
generation_servers:
num_instances: 2
urls:
- "localhost:8003"
- "localhost:8004"分离式服务支持多种负载均衡策略，包括轮询 (round-robin) 及基于 KV 缓存的路由。此外，该架构已支持动态扩缩容，能够灵活应对不同规模的推理负载。
了解更多信息，请参见示例。
Dynamo
第二种方法是使用 Dynamo —— 一个专为 LLM 工作负载设计的数据中心级推理服务器。Dynamo 提供了许多高级功能，包括预处理与后处理线程的解耦，特别适用于高并发场景。其工作流程如图 4 所示。
图 4. 使用 Dynamo 进行分离式服务
在 Dynamo 的工作流程中，首先由预处理和后处理工作线程处理请求，随后它们会查询智能路由器，以确定将请求路由到哪个最优的生成器。根据 KV 缓存块的可用性，生成器可能跳过上下文阶段，或将请求转发至上下文工作线程。一旦上下文阶段完成提示词的处理，KV 缓存块即可通过上图所示的 ctx_params 元数据发送至生成阶段，用于后续的 Token 生成。
Dynamo 还内置了对 Kubernetes 部署、监测和指标采集的支持。我们正在积极推进动态实例扩展，进一步提高其在生产环境中的适用性与弹性。
更多有关如何将 Dynamo 与 TensorRT-LLM 集成的信息，请参见此文档。
Triton 推理服务
第三种方法是使用 Triton 推理服务器，通过 Triton 的 ensemble 模型实现分离式推理。该模型由预处理器、调度器（基于 Python BLS 后端）和后处理器组成。如图 5 所示，调度器负责将客户端请求路由至上下文和生成实例，管理提示 Token 的流转，并处理生成 Token 的返回结果。该方法依赖于 Triton 的 TensorRT-LLM 后端及其 Executor API，目前仅支持 TensorRT 后端。如需了解更多信息，请参阅此文档。
图 5. 使用 Triton 进行分离式服务
KV 缓存传输
多后端支持
如图 6 所示，在 TensorRT-LLM 中，KV 缓存交换模块、KV 缓存管理器及底层通信库采用模块化解耦设计。KV 缓存交换模块负责高效传输缓存、及时释放缓存空间，并在交换过程中按需转换缓存布局。目前，TensorRT-LLM 支持主流通信协议，包括 MPI、UCX 和 NIXL，其底层通信协议采用 RDMA / NVLink。我们推荐使用 UCX 和 NIXL 后端，因为它们支持动态扩缩容功能，使用户能够根据流量需求调整负载，或在上下文和生成角色之间进行动态切换。
图 6. KV 缓存交换架构
并行优化
为了提高分离式服务的整体性能，TensorRT-LLM 将 KV 缓存传输与请求计算过程重叠。如图 7 所示，当一个请求正在发送或接收其 KV 缓存块时，其他请求可以继续进行计算。此外，如果上下文或生成阶段使用了多个 GPU，不同 GPU 之间的 KV 缓存传输也可以并行进行。
图 7. KV 缓存交换时序图
缓存布局转换
为了最大限度地降低 KV 缓存传输延迟，TensorRT-LLM 采用在设备显存间直接传输缓存的方式。KV 缓存传输支持在上下文和生成阶段采用不同的并行策略，此时需谨慎地映射两个阶段间的对 KV 缓存块布局。图 8 通过一个示例进行了说明：上下文阶段采用 TP2 并行策略，而生成阶段采用 PP2 并行策略。在这种异构并行配置下，缓存块的正确布局映射至关重要。
图 8. KV 缓存布局转换
KV 缓存传输所需的优化策略会因具体部署环境而异，例如单节点多 GPU、多节点多 GPU 或 不同 GPU 种类。为此，TensorRT-LLM 提供了一组环境变量，供用户根据实际运行环境灵活选择和配置，以实现最佳性能。详情请参见此文档。
性能分析
测量方案
如果要生成 LLM 分离服务的性能曲线，需全面覆盖并行化策略的组合，比如 TP（张量并行）、EP（专家并行）、DP（数据并行）、PP（流水线并行），以及其他优化方法，如投机采样（例如 MTP）。这些组合必须分别在上下文阶段和生成阶段进行评估。随着上下文 (CTX) 和生成 (GEN) 服务器数量的增加，可能的配置数量呈指数级增长，评估复杂度也随之提升。
为了确定最佳配置，我们将测量过程分为两步：
- 速率匹配
- 测量上下文服务器的请求吞吐量（以请求数 / 秒 / GPU 为单位），针对满足 TTFT 约束的不同 TP / EP / DP / PP 映射，选择最优配置。
- 针对不同的 TP / EP / DP / PP 映射、并发级别，以及投机采样开关的情况，测量生成服务器的总吞吐量（以 Token / 秒为单位）和延迟（以 Token / 秒 /用户为单位）。
- 确定上下文服务器与生成服务器的比例，使得在给定工作负载的输入序列长度 (ISL) 和输出序列长度 (OSL) 下，上下文服务器的总吞吐量与生成服务器的总吞吐量相匹配。
- 使用以下公式计算每个 GPU 的吞吐量：
- 一旦计算出上下文与生成服务器的最佳比例，即可构建“速率匹配”帕累托曲线 (Pareto curve)，以便在不同延迟（Token / 秒 / 用户）下识别最佳配置。
- 端到端性能测量
- 在考虑可用 GPU 总数量的实际限制的前提下，对最具优势的配置进行 trtllm-serve 分离式部署的基准测试。
DeepSeek R1
我们在 ISL 和 OSL 不同的数据集上对 DeepSeek R1 进行了性能测试。以下所有实验均在 NVIDIA GPU 上进行。
ISL 4400 – OSL 1200（机器翻译数据集）
图 9. 关闭 MTP 时的 DeepSeek R1“速率匹配”帕累托曲线
图 9 是 DeepSeek R1 在关闭 MTP 时的速率匹配帕累托曲线。该曲线考虑了 ADP 和 ATP 配置，每个实例使用 4、8、16 或 32 个 GPU。分离式实现的加速比为 1.4 至 1.8 倍，尤其在低并发水平下效果更为显著。
图 10. 启用 MTP 时的 DeepSeek R1 帕累托曲线
我们在性能曲线中选取一些数据点标注了上下文 / 生成实例的数量和并行策略。例如，CTX=1xTEP-4|GEN=2xDEP-8 表示由 1 个 TEP4 上下文实例和 2 个 DEP8 生成实例组成一个完整的 LLM 处理实例。
如图 10 所示，启用 MTP 后，分离式服务相较于聚合式服务的加速比进一步提升，平均比关闭 MTP 时高出 20% 至 30%。
ISL 8192 – OSL 256（合成数据集）
图 11. DeepSeek R1 4-GPU 帕累托曲线。ctx/gen=4.5 表示上下文与生成阶段的 SOL 速率匹配，该配置仅用于 SOL 性能收集。c4dep4_g1dep4 表示 4 个 DEP4 上下文实例加上 1 个 DEP4 生成实例组成一个完整的 LLM 服务实例。
图 12. DeepSeek R1 8-GPU 帕累托曲线
图 11 和图 12 分别是在每个生成实例使用 4 个 GPU (GEN4) 和 8 个GPU (GEN8) 的情况下，在 DeepSeek R1 上运行 ISL8192-OSL256 数据集的性能曲线。我们同时绘制了分离式服务的“速率匹配”结果（基于上下文与生成阶段之间的理想速率匹配）和端到端结果（用户可在生产部署环境中直接复现该结果）。
结果显示，在此 ISL / OSL 设置下，分离服务的性能明显优于合并服务——在 GEN4 配置下加速比最高可达 1.73 倍，GEN8 配置下最高可达 2 倍。
通过将分离式服务的端到端结果与“速率匹配”曲线进行比较，我们观察到性能差距在 0%–25% 之间。这种差异是符合预期的，因为 SOL 性能依赖于理想化假设，例如 ctx:gen 比例极小、KV 缓存传输不产生开销等。
ISL 4096 – OSL 1024（机器翻译数据集）
图 13. DeepSeek R1 端到端帕累托曲线，MTP = 1、2、3。在此图中，ctx1dep4-gen2dep4-mtp3 表示 1 个 DEP4 上下文实例加 2 个 DEP4 生成实例，且 MTP = 3。
图 14. 关闭 MTP 时的 DeepSeek R1 端到端帕累托曲线
图 13 和 14 分别为合并服务和分离服务在开关 MTP 时的端到端帕累托曲线。
在 MTP = 1、2、3 的帕累托曲线上，可以观察到，在 50 Token / 秒 / 用户（20 毫秒延迟）时，分离服务的性能提升达 1.7 倍。随着并发度的提高，启用 MTP 能够带来更大的性能收益。
Qwen 3
ISL 8192 – OSL 1024（机器翻译数据集）
图 15. Qwen 3 帕累托曲线
我们还对 Qwen 3 进行了性能评估。数据显示，分离服务实现的加速比在 1.7 至 6.11 倍之间。
性能复现
我们提供了一组脚本用于复现本论文中展示的性能数据。请参见此文档中的使用说明。
工作展望
我们已经通过使用 TensorRT-LLM 进行 LLM 分离式推理获得了性能优势，我们还将会进一步提高性能和易用性，所需的工作包括：
● 提供详细的步骤和脚本，以自动化生成用于比较聚合式与分离式服务的吞吐量-延迟性能曲线。
● 继续提升大规模部署场景下的性能（如大规模 EP）。
● 支持根据流量负载动态调整上下文和生成实例。
● 支持按层计算传输 KV 缓存。
致谢
在 TensorRT-LLM 中增加分离式服务支持是一个典型的跨团队协作项目，需要在内核级优化、运行时增强以及系统化性能分析与调优等方面紧密配合。我们为这支敬业乐群的工程师团队感到骄傲，正是他们深厚的专业知识大幅提升了 TensorRT-LLM 的整体性能。除本文作者外，我们诚挚感谢 Iman Tabrizian、张顺康、段政和网络团队等同事为项目所作的代码贡献。通过此次协作，团队在进一步提升大语言模型推理的 GPU 利用率方面积累了宝贵经验。我们希望本文能够为开发者社区提供有益参考，助力大家在关键 LLM 推理应用中更充分地释放 NVIDIA GPU 的潜力。
