大模型推理 CPU-GPU 异构计算协同调度深度调研报告

调研日期： 2026-03-20 所属域： 大模型框架 版本： 1.0

目录

1. 第一部分：概念剖析
2. 第二部分：行业情报
3. 第三部分：方案对比
4. 第四部分：精华整合

第一部分：概念剖析

1. 定义澄清

通行定义

大模型推理 CPU-GPU 异构计算协同调度是指在大型语言模型（LLM）推理服务中，通过智能调度算法动态分配计算任务到 CPU 和 GPU 两类异构计算资源上，以实现内存容量扩展、计算效率优化和成本控制的技术体系。其核心思想是打破"所有计算必须在 GPU 上完成"的传统范式，利用 CPU 的大内存容量和 GPU 的高计算吞吐能力，通过精细化的任务切分、数据布局和流水线调度，在满足延迟约束的前提下最大化系统吞吐。

常见误解

1. 误解一："CPU-GPU 协同就是简单地把部分层放到 CPU 上" 实际上，协同调度涉及复杂的内存管理（如 PagedAttention）、算子融合、通信隐藏和预测性预取，远非简单的层分配问题。

2. 误解二："CPU 参与计算一定会显著降低性能" 在内存受限场景下，合理的 CPU offloading 可以通过避免 GPU OOM 和减少数据重传，反而提升整体吞吐。对于 decode 阶段的部分算子，CPU 执行可能不会成为瓶颈。

3. 误解三："异构调度只适用于超大模型" 实际上，在高并发多租户场景下，即使是 7B-13B 模型也能通过异构调度实现更好的资源利用率和 QoS 保障。

边界辨析

2. 核心架构

┌─────────────────────────────────────────────────────────────────────┐
│                    大模型推理 CPU-GPU 异构调度系统                    │
├─────────────────────────────────────────────────────────────────────┤
│  ┌─────────────┐                                                    │
│  │  请求接入层  │ ← HTTP/gRPC 请求，批处理管理                       │
│  └──────┬──────┘                                                    │
│         ▼                                                           │
│  ┌─────────────────────────────────────────────────────────────────┐│
│  │                      调度决策引擎                                ││
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐          ││
│  │  │ 内存预测器   │  │ 负载评估器   │  │ 成本优化器   │          ││
│  │  │ (预测 KV 需求) │  │ (GPU 利用率)  │  │ (延迟/吞吐)  │          ││
│  │  └──────────────┘  └──────────────┘  └──────────────┘          ││
│  └─────────────────────────────────────────────────────────────────┘│
│         ▼                                                           │
│  ┌─────────────────────────────────────────────────────────────────┐│
│  │                      执行引擎层                                  ││
│  │  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐         ││
│  │  │ GPU 计算单元  │←→→ │ 通信协调器   │←→→│ CPU 计算单元  │         ││
│  │  │ (Attention,  │    │ (PCIe/NVLink│    │ (Offload,   │         ││
│  │  │  FFN, Norm)  │    │  数据搬运)  │    │  预处理)    │         ││
│  │  └─────────────┘    └─────────────┘    └─────────────┘         ││
│  └─────────────────────────────────────────────────────────────────┘│
│         ▼                                                           │
│  ┌─────────────────────────────────────────────────────────────────┐│
│  │                      存储管理层                                  ││
│  │  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐         ││
│  │  │ GPU HBM     │    │ CPU DRAM    │    │ NVMe SSD    │         ││
│  │  │ (KV Cache)  │←→→│ (Offload)   │←→→│ (Swap)      │         ││
│  │  └─────────────┘    └─────────────┘    └─────────────┘         ││
│  └─────────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────────┘

组件职责说明：

3. 数学形式化

3.1 异构调度优化目标

解释： 最小化端到端延迟，其中 $a_l \in \{G, C\}$ 表示第 $l$ 层的分配决策（GPU 或 CPU），$t_l^G$ 和 $t_l^C$ 分别是 GPU 和 CPU 上的执行时间，$t_{\text{transfer}}$ 是跨设备数据传输时间。

3.2 内存容量约束

解释： 总 KV Cache 需求不能超过 GPU 显存加上可 offload 的 CPU 内存（$\alpha$ 为 offload 比例系数）。其中 $H$ 是注意力头数，$S_r$ 是序列长度，$D$ 是 head dimension，$B$ 是每个 token 的字节数。

3.3 吞吐 - 延迟权衡模型

解释： 系统吞吐随请求率 $\lambda$ 变化，$P_{\text{offload}}$ 是触发 offload 的概率，$\beta_{\text{overhead}}$ 是 offload 带来的额外开销系数。该模型揭示了高负载下 offload 对吞吐的影响。

3.4 计算 - 通信重叠效率

解释： 重叠效率衡量计算与数据传输的并行程度。理想情况下 $T_{\text{transfer}} < T_{\text{compute}}$，$\eta_{\text{overlap}} \approx 100\%$；否则通信成为瓶颈。

3.5 成本效益比

解释： 每单位成本产生的 token 吞吐量，其中 $C_G$ 和 $C_C$ 分别是 GPU 和 CPU 的单位时间成本。该指标用于评估异构调度的经济性。

4. 实现逻辑（Python 伪代码）

class HeterogeneousScheduler:
    """
    CPU-GPU 异构调度核心类
    负责动态决策每层计算应该分配到 GPU 还是 CPU
    """
    def __init__(self, config):
        self.gpu_memory = config.gpu_hbm_size      # GPU 显存容量 (GB)
        self.cpu_memory = config.cpu_dram_size     # CPU 内存容量 (GB)
        self.pcie_bandwidth = config.pcie_bw       # PCIe 带宽 (GB/s)
        self.model_config = config.model           # 模型配置 (层数、隐藏维度等)
        self.memory_pool = PagedMemoryPool(config) # 分页内存池
        self.profiler = OperationProfiler()        # 算子性能剖析器

    def schedule_request(self, requests: List[Request]) -> ExecutionPlan:
        """
        为核心请求生成执行计划，决定每层的设备分配
        """
        # 步骤 1: 预测内存需求
        kv_demand = self._predict_kv_demand(requests)

        # 步骤 2: 评估 GPU 剩余容量
        gpu_available = self.gpu_memory - self.memory_pool.allocated

        # 步骤 3: 决定 offload 策略
        if kv_demand <= gpu_available:
            # GPU 足够，全 GPU 执行
            plan = self._all_gpu_plan(requests)
        else:
            # 需要 offload，计算最优分配
            plan = self._heterogeneous_plan(requests, kv_demand, gpu_available)

        return plan

    def _heterogeneous_plan(self, requests, kv_demand, gpu_available) -> ExecutionPlan:
        """
        生成异构执行计划：将部分层 offload 到 CPU
        """
        layers_to_offload = self._select_layers_to_offload(
            kv_demand - gpu_available
        )

        plan = ExecutionPlan()
        for layer_id in range(self.model_config.num_layers):
            if layer_id in layers_to_offload:
                plan.add_stage(
                    layer_id,
                    device="CPU",
                    compute_fn=self._cpu_layer_forward,
                    pre_fetch=True,  # 预取权重和数据
                    post_transfer=True  # 结果传回 GPU
                )
            else:
                plan.add_stage(
                    layer_id,
                    device="GPU",
                    compute_fn=self._gpu_layer_forward
                )

        # 优化：尝试重叠通信和计算
        plan.optimize_overlap(self.pcie_bandwidth)
        return plan

    def execute_plan(self, plan: ExecutionPlan, inputs: Tensor) -> Tensor:
        """
        执行异构计划，管理跨设备数据流
        """
        intermediate = inputs
        for stage in plan.stages:
            if stage.device == "GPU":
                intermediate = stage.compute_fn(intermediate)
            else:
                # CPU 执行：需要处理数据传输
                gpu_data = intermediate
                cpu_data = self._transfer_to_cpu(gpu_data)
                cpu_result = stage.compute_fn(cpu_data)
                intermediate = self._transfer_to_gpu(cpu_result)

        return intermediate

    def _select_layers_to_offload(self, excess_memory: int) -> Set[int]:
        """
        选择要 offload 的层：优先 offload 计算密度低的层
        """
        layer_costs = []
        for layer_id in range(self.model_config.num_layers):
            mem_cost = self._estimate_layer_memory(layer_id)
            compute_cost = self.profiler.get_compute_time(layer_id, "GPU")
            transfer_cost = self._estimate_transfer_time(layer_id)

            # offload 代价 = 额外传输时间 / GPU 计算时间
            offload_penalty = transfer_cost / compute_cost
            layer_costs.append((layer_id, mem_cost, offload_penalty))

        # 按单位内存收益排序，优先 offload 代价小的层
        layer_costs.sort(key=lambda x: x[2] / x[1])

        layers_to_offload = set()
        freed_memory = 0
        for layer_id, mem_cost, _ in layer_costs:
            if freed_memory >= excess_memory:
                break
            layers_to_offload.add(layer_id)
            freed_memory += mem_cost

        return layers_to_offload


class PagedMemoryPool:
    """
    分页内存池：类似 vLLM 的 PagedAttention 思想
    支持 GPU-CPU-SSD 三级存储的弹性扩展
    """
    def __init__(self, config):
        self.block_size = config.block_size  # 每 block 管理的 token 数
        self.gpu_blocks = self._allocate_gpu_blocks(config.gpu_memory)
        self.cpu_blocks = self._allocate_cpu_blocks(config.cpu_memory)
        self.block_tables: Dict[RequestID, List[int]] = {}

    def allocate(self, request_id: str, num_tokens: int) -> List[int]:
        """为请求分配物理 block，返回 block 表"""
        num_blocks = ceil(num_tokens / self.block_size)

        # 优先分配 GPU block
        gpu_blocks_needed = min(num_blocks, len(self.gpu_blocks.free))
        cpu_blocks_needed = num_blocks - gpu_blocks_needed

        allocated = []
        allocated.extend(self.gpu_blocks.allocate(gpu_blocks_needed))
        allocated.extend(self.cpu_blocks.allocate(cpu_blocks_needed))

        self.block_tables[request_id] = allocated
        return allocated

    def swap_out(self, request_id: str) -> bool:
        """将请求的 KV Cache 从 GPU swap 到 CPU/SSD"""
        if request_id not in self.block_tables:
            return False

        block_table = self.block_tables[request_id]
        for i, block_id in enumerate(block_table):
            if self._is_gpu_block(block_id):
                # 异步传输到 CPU
                self._async_transfer_gpu_to_cpu(block_id)
                # 回收 GPU block
                self.gpu_blocks.free_block(block_id)
                # 分配 CPU block
                new_block_id = self.cpu_blocks.allocate(1)[0]
                block_table[i] = new_block_id

        return True

    def swap_in(self, request_id: str) -> bool:
        """将请求的 KV Cache 从 CPU/SSD swap 回 GPU"""
        # 与 swap_out 对称的操作
        pass

5. 性能指标

6. 扩展性与安全性

水平扩展

异构调度系统的水平扩展主要通过以下方式实现：

1. 多 GPU 数据并行：通过请求分片将不同请求分配到不同 GPU，每个 GPU 独立进行 CPU-GPU 协同调度
2. 模型并行 + 异构：超大模型采用 tensor parallelism 跨多 GPU，同时在每个 GPU 节点上启用 CPU offload
3. 分布式 KV Cache：跨节点的 KV Cache 共享，利用远端 CPU 内存扩展本地容量
4. 弹性扩缩容：基于负载预测动态调整 CPU offload 比例，实现资源的弹性伸缩

扩展瓶颈主要在于：

• PCIe 带宽成为多 GPU 场景下的共享瓶颈
• 跨节点通信延迟影响分布式 KV Cache 效率
• 调度器的集中式决策可能成为单点瓶颈

垂直扩展

单节点垂直扩展的优化空间：

1. GPU 侧：

   • 使用 HBM3/HBM3e 提升显存带宽（3-3.5 TB/s）
   • 采用 Tensor Core 和稀疏化加速计算
   • 多实例 GPU (MIG) 实现细粒度资源隔离

2. CPU 侧：

   • 利用 AVX-512/AMX 指令集加速量化推理
   • 大页内存 (Huge Page) 减少 TLB miss
   • NUMA 感知的内存分配降低访问延迟

3. 互联侧：

   • PCIe 5.0/6.0 提升带宽（64-128 GB/s）
   • CXL 3.0 实现内存池化和相干访问
   • NVLink 桥接多 GPU 减少 CPU 中转

安全考量

异构调度系统特有的安全风险：

第二部分：行业情报

1. GitHub 热门项目（15+ 个）

2. 关键论文（12 篇）

3. 系统化技术博客（10 篇）

4. 技术演进时间线

2022 ─┬─ Orca (Microsoft) → 提出迭代式调度和动态批处理概念
      │
2023 ─┼─ vLLM (Stanford) → PagedAttention 革命性内存管理，开启高效推理时代
      │
2023 ─┼─ DeepSpeed-ZeRO Offload → 训练时 offload 技术迁移到推理场景
      │
2024 ─┼─ DistServe (PKU) → Prefill/Decode 解耦，异构部署新范式
      │
2024 ─┼─ FlexFlow Serve → 推测解码与异构调度结合
      │
2024 ─┼─ TensorRT-LLM GA → NVIDIA 官方推理引擎成熟，支持完整 offload
      │
2025 ─┼─ CXL-LLM → CXL 内存池化实现近零开销 offload
      │
2025 ─┼─ SchedRL → 强化学习驱动的自适应调度策略
      │
2025 ─┼─ Infinite-LLM → 外部记忆扩展突破单节点限制
      │
2026 ─┴─ 当前状态：异构调度成为生产级推理系统标配，CXL 和 AI 专用互联技术推动 offload 开销降至 5% 以下

第三部分：方案对比

1. 历史发展时间线

2020 ─┬─ 早期探索：模型并行训练技术开始应用于推理场景
      │
2021 ─┼─ DeepSpeed 提出 ZeRO 技术：内存优化从训练延伸到推理
      │
2022 ─┼─ Orca 系统发布：首次系统化提出迭代式调度框架
      │
2023 ─┼─ vLLM 横空出世：PagedAttention 将 GPU 利用率提升至 90%+
      │
2024 ─┼─ 异构调度成熟：CPU offload 成为应对大内存需求的标准方案
      │
2025 ─┼─ CXL 技术落地：硬件级内存池化将 offload 开销降至个位数
      │
2026 ─┴─ 当前状态：智能化、自适应的异构调度系统，支持无缝的 GPU-CPU-SSD 三级存储

2. 五种方案横向对比

3. 技术细节对比

4. 选型建议

成本估算说明：

• 基于 2026 年云服务商价格（AWS/GCP/Azure）
• 包含 GPU 实例、CPU 实例、内存和网络成本
• 未考虑预留实例和长期合约折扣
• 实际成本因地区和供应商而异

第四部分：精华整合

1. The One 公式

核心心智模型： 异构推理的本质是用智能调度换取内存容量，用计算 - 通信重叠抵消 offload 开销，最终实现"用 CPU 内存换 GPU 容量，几乎不损失性能"。

2. 一句话解释

大模型推理的 CPU-GPU 异构调度，就像餐厅的"前厅 - 后厨"协作：GPU 是高效的后厨负责核心烹饪（计算），CPU 是宽敞的前厅负责暂存订单和预处理（内存扩展），调度系统就是店长，决定哪些工作在哪儿做最划算，让餐厅在有限空间内服务更多顾客。

3. 核心架构图

┌─────────────────────────────────────────────────────────────────┐
│                     异构调度系统核心流程                         │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   请求队列 → [调度决策] → [内存分配] → [执行引擎] → 响应输出    │
│               ↓ ↓            ↓ ↓           ↓ ↓                 │
│           GPU/CPU 选择    HBM/DRAM     计算/通信重叠            │
│           基于负载预测    分页管理     流水线并行               │
│               ↓ ↓            ↓ ↓           ↓ ↓                 │
│           延迟<100ms     利用率>85%    重叠率>80%              │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

4. STAR 总结

5. 理解确认问题

问题： 为什么在某些高并发场景下，即使 GPU 显存足够容纳 KV Cache，系统仍可能主动选择将部分计算 offload 到 CPU？请从调度优化角度解释。

参考答案： 这涉及"计算密度"和"资源平衡"的权衡。在某些场景下：

1. 计算资源瓶颈：GPU 计算单元已达 100% 利用率，但 CPU 仍有空闲。将计算密度较低的层（如 LayerNorm）offload 到 CPU，可释放 GPU 用于更关键的 Attention 计算，提升整体吞吐。
2. 多租户隔离：为不同优先级的请求分配不同设备，高优先级请求独占 GPU，低优先级请求 offload 到 CPU，实现 QoS 隔离。
3. 批处理优化：offload 部分计算可减小 GPU 上的活跃 batch 大小，允许更大的连续批处理窗口，间接提升吞吐。
4. 能耗优化：在满足延迟 SLO 的前提下，将部分负载转移到更节能的 CPU，降低整体能耗成本。

这体现了异构调度的核心思想：不是简单地"显存不够才 offload"，而是基于全局优化目标的智能资源分配。

附录：参考文献与资源

核心论文

1. Kwon et al. "vLLM: Easy, Fast, and Cost-Effective LLM Serving." SOSP 2023.
2. Yu et al. "Orca: A Distributed Serving System." OSDI 2022.
3. Zhong et al. "DistServe: Disaggregating Prefill and Decoding." OSDI 2024.
4. Zheng et al. "FlexFlow Serve: Fast and Cheap LLM Serving." MLSys 2024.

开源项目

• vLLM
• TensorRT-LLM
• DeepSpeed
• SGLang

技术博客

• vLLM Blog
• NVIDIA Developer Blog
• Eugene Yan's Blog

报告版本： 1.0 调研完成日期： 2026-03-20 总字数： 约 8500 字