# 下一代推理优化技术：高性能网络驱动的PD分离与KV Cache Offload测试（上）

> **来源**：超擎数智（官网博客）  
> **作者**：超擎数智  
> **发布日期**：2026-08-05（原文未标注，按下载日期）  
> **原文链接**：https://chaoqing-i.com/blog/next-gen-inference-optimization-pd-separation-kv-cache-offload-test

---

近年来，大规模模型在各类应用场景中快速落地，带动了推理需求的高速增长。随着模型参数量不断提升和用户请求并发数持续攀升，如何提升推理性能成为业界关注的核心问题，在众多优化方向中，PD分离与KV Cache Offload被认为是当前对推理性能提升最具突破性的两项关键技术，前者通过计算与通信解耦，实现更高效的资源利用，后者则通过缓存卸载，极大降低了显存占用并提升大模型长文本推理的效率。

为全面验证高性能网络与PD分离、KV Cache Offload这两项技术的性能优势与应用价值，**NVIDIA、超擎数智、联想、DaoCloud、纳多德五家公司联合投入总计数千万元的设备与资源，在超擎数智高性能计算和人工智能研发测试中心开展跨厂商协作测试。**本次测试旨在为业界提供权威的技术验证结果，探索推理优化的最佳实践，并为未来的大规模部署提供参考。

在大模型推理场景中，传统架构面临两大挑战：

- 计算效率瓶颈：传统的一体化部署模式中Prefill和Decode在同一设备上执行会出现严重的资源竞争问题，两个阶段的资源需求特性无法得到针对性优化导致计算资源利用率低。
- 显存带宽压力：KV Cache的显存开销随上下文长度增长线性膨胀，显存带宽成为性能瓶颈。

**PD分离（Prefill & Decode Separation）与KV Cache Offload是当前大模型推理中的核心优化技术，可显著提升推理吞吐和并发能力：**

- **提升推理效率、降低延迟：**通过拆分Prefill和Decode阶段并部署到不同设备，避免计算资源冲突，使推理**Token延迟显著降低、Token吞吐提升 2～3 倍。**
- **显著降低显存占用、支持更多用户并发：**KV Cache Offload将大量上下文缓存从显存转移至CPU/SSD，大幅节省GPU显存，使同一模型能够支持更多并发用户或更长的上下文长度。
- **提高资源利用率、降低成本：**PD分离+Offload让高性能GPU更专注在重计算任务上，普通硬件即可承担缓存任务，整体推理集群性价比提升明显。

## PD分离与KV Cache Offload技术介绍

### 1. 什么是PD分离？为什么要选择PD分离？

在大语言模型（LLM）的推理过程中，通常会经历两个阶段：

**1）Prefill阶段（输入处理）**

a. 模型一次性读取并并行处理全部输入Token，建立上下文理解  
b. 计算模式：高并行度的矩阵乘法，计算密集，显存占用相对较低  
c. 特点：更适合高吞吐量的GPU、多卡并行运行

**2）Decode阶段（输出生成）**

a. 模型基于上下文（以及 KV Cache）逐个生成Token  
b. 计算模式：顺序生成，一个Token接一个Token，延迟敏感  
c. 显存占用：会随着上下文长度增长而迅速增加（因为要存KV Cache）

在传统部署中，这两个阶段通常运行在同一批GPU上。但问题是Prefill和Decode的资源需求完全不同——一个追求高并行算力，一个追求低延迟和大显存。把它们混在同一批GPU上跑，往往两边性能都打折扣。

**PD分离（Prefill–Decode Separation）**

顾名思义，就是把Prefill和Decode分开部署在不同的硬件资源池中：

- Prefill阶段使用高算力、高吞吐的GPU
- Decode阶段使用显存更大、延迟更低的GPU

这样做的好处：

- 针对性优化：让每个阶段用最合适的硬件，发挥最佳性能
- 资源独立扩展：Prefill和Decode各自可以根据负载独立增加或减少GPU
- 提升整体吞吐量：避免一种任务拖慢另一种任务

**PD分离的挑战**

- 额外的通信开销：如果Prefill和Decode放在不同的GPU上，需要传输KV Cache，网络延迟和带宽会成为瓶颈。
- 调度复杂度增加：系统要实时协调两列任务的分配，否则Decode阶段可能会空等Prefill的结果，或者Prefill资源被Decode阻塞。
- 实现复杂：框架和任务调度器需要支持流水线，KV Cache输出，异步执行等操作，难度要比单机单卡推理更难维护。
- 内存占用高：Prefill阶段可能会同时处理多个请求，Decode阶段需要保留全部的KV Cache，内存压力会很大。

PD分离就是"分工合作"，让Prefill和Decode各自使用最适合的GPU，从而提升效率和吞吐量，但也需要解决通信、调度、内存等方面的挑战。

### 2. 什么是KV Cache？为什么我们要offload？

如果把大语言模型（LLM）比作一个写小说的作家，那么Transformer就是他的"思考方法"。

作家写故事时，会一边看之前写的内容，一边决定接下来写什么。同样，Transformer 在生成文本时，也是一边参考之前生成的Token，一边预测下一个Token。

**从Transformer说起**

在Transformer的自注意力（Self-Attention）机制里，每个Token（可以理解为一个词或字的编码）都会生成三种向量：

- Q（Query）：我现在要找的信息是什么？
- K（Key）：我是谁？（特征坐标）
- V（Value）：我带来的内容是什么？（特征内容）

在Transformer生成文本时，每次只会生成一个新Token，模型会用这个Token的Q去和所有历史Token的K做匹配，找到相关性，然后用这些相关的V计算输出，但是标准Transformer在推理时是逐个Token生成的，比如：

输入："我想要读一"  
生成："我想要读一本"  
继续生成："我想要读一本书"

但在生成第三个Token时，它又会重新计算前面所有Token的K和V，哪怕这些数据早就算过了！

这种重复计算会导致推理的计算量随着Token数量呈二次方增长，速度很慢。

**KV Cache的核心宗旨"别重复干活"**

KV Cache的核心思想是：历史的K和V早就算好了，直接存起来，别每次都重算。

这样，每次生成新Token时，只需：

- 计算新Token的K和V
- 把它们拼到之前缓存的结果中
- 用缓存+新Token一起继续生成

这样一来，推理的计算量就从二次方降到线性，大大加快速度。

**为什么要Offload**

KV Cache虽然能加速，但它有个副作用：特别占显存。

举个例子：

- 假设你的模型上下文长度是8万个Token
- 每个Token的K和V都要存
- 可能光KV Cache就能占用几十GB的显存

显存是GPU上最宝贵的资源，除了KV Cache，还需要存模型权重、中间计算结果等。如果显存被占满，推理就会崩溃或者无法运行。

**Offload 的作用**

Offload就是把一部分数据从显存（GPU Memory）挪到其他存储介质，比如：

- CPU内存（RAM）：容量大，但带宽比GPU慢
- SSD：容量更大，但速度更慢
- 高带宽内存（HBM）：速度快，但昂贵且容量有限

在KV Cache场景下，Offload的好处是：

- 把暂时用不到的历史KV数据移到CPU/SSD
- 腾出GPU显存，保证当前推理不卡
- 在需要时再把数据搬回来（当然搬运有代价，所以要权衡速度和显存占用）

## 联合测试概述

### 1. 测试目标

验证PD分离和KV Cache Offload在大模型推理场景下的性能优化效果，具体包括：

- 降低端到端延迟：解耦Prefill与Decode阶段，减少资源争抢。
- 扩展上下文长度：通过KV Cache分层存储（显存→主机内存/NVMe），突破显存容量限制。
- 提升硬件利用率：优化计算单元和存储介质的协作效率。

### 2. 测试拓扑与环境

测试拓扑见图1，环境信息如下：

- **H20服务器 ×1**：超擎数智元景系列AI服务器CQ7688-L，搭载 NVIDIA H20 GPU，8U8卡 NVLink，8U空间内搭载1块NVIDIA Hopper架构HGX-8GPU模组，系统支持4.0Tbps网络带宽，满足万亿级参数超大模型并行训练需求。
- **L20服务器 ×3**：超擎数智擎天系列L20 AI 服务器CQ7458-L（4U8卡 PCIe）支持4卡或8卡配置，用户可以基于应用模型按需配置/灵活切换，并且支持丰富的AI加速卡和智能网卡，从而适应不同人工智能场景的需求，满足各种 AI 业务场景下的应用需求。
- **RoCE交换机 ×6**：采用NVIDIA Spectrum™ SN5000系列第五代Spectrum以太网交换机，计算网络和存储网络均采用SN5600进行组网。
- **存储服务器**：采用联想问天WR5220 G3高性能存储服务器。
- **软件平台**：采用DaoCloud d.run平台。
- **光连接器件**：采用纳多德高性能光模块和光纤跳线，保障性能和稳定性的同时可以大幅度降低成本。
- **存储节点 ×3**：采用3台分布式存储节点，每台节点均搭配NVMe硬盘。

关键组件如下：

- **Prefill单元**：部署在1台高算力H20 GPU（高速PCIe 5.0/NVLink）上，充分利用强大算力，专注生成初始KV Cache。
- **Decode单元**：使用3台L20 GPU，专注于GPU执行自回归生成。
- **存储层级**：
  - 显存（HBM）：存储活跃KV Cache（热数据）。
  - 主机内存（DDR）：卸载历史KV Cache（温数据）。
  - NVMe SSD：硬盘存储极低频访问的KV Cache（冷数据）。
- **网络连接**：H20和L20 400G计算网络、H20、L20、StorageNode 200G存储网络分别使用不同的高速交换机互联传输数据。

### 3. 测试设计

**3.1 PD分离测试**

- 对照组：传统耦合架构（Prefill与Decode共享H20 GPU）。
- 实验组：PD分离架构（Prefill由H20 GPU处理，Decode由L20 GPU处理）。
- 指标：
  - Prefill延迟：从输入Prompt到生成首个Token的时间。
  - Decode吞吐量：Tokens/Second（TPS）。
  - GPU利用率：nvidia-smi监控计算负载。

**3.2 KV Cache Offload测试**

- 对照组：全量KV Cache驻留显存。
- 实验组：分层卸载策略（显存→内存→SSD）。
- 指标：
  - 显存占用峰值：dcgm记录HBM使用量。
  - Offload延迟：冷数据加载至显存的平均耗时。
  - 最大支持上下文：通过逐步增加Prompt长度测试崩溃点。

**3.3 联合测试**

验证PD分离与Offload协同效果：

- 场景：8K上下文 + 100轮对话。
- 关键指标：端到端延迟、系统总功耗。

### 4. 预期结果

**4.1 PD分离**

预期结果：

- Decode阶段延迟降低30%-50%（L20 GPU处理避免H20 GPU阻塞）。
- H20 GPU利用率从60%提升至85%（专注计算密集型Prefill）。

**4.2 KV Cache Offload**

预期结果：

- 显存占用减少60%（8K上下文下从16GB→6.4GB）。
- 支持上下文长度从2K扩展至16K。

**4.3 联合优化**

预期结果：

- 系统总吞吐量（QPS）提升2倍，功耗降低20%。

### 5. 数据收集与分析

- 工具：
  - 性能分析：Nsight Systems、perf。
  - 资源监控：Prometheus（GPU/CPU/内存指标）。
- 分析方法：
  - 对比对照组/实验组的延迟分布。
  - 显存带宽与计算效率的相关性分析。

> **注**：本文为系列文章"上"篇，主要介绍技术背景、测试方案设计与预期结果；实测数据与分析拟在"下"篇呈现。