Multi-GPU LLM 推理中，CPU 资源不足是隐藏的主导瓶颈：tokenization 占 TTFT 高达 50%，shared-memory broadcast dequeue 延迟膨胀 19×，barrier 同步将单核延迟放大为全局 GPU 停顿。增加 CPU 核心可在 ~1.5% 额外成本下获得 1.36–5.40× TTFT 改善。
Q1 痛点：Multi-GPU LLM 推理中，GPU 利用率低下的根因常被误归于 GPU 自身能力不足。实际上，CPU 在承担 tokenization、kernel dispatch、IPC 调度三类关键任务时，由于核心数不足产生 oversubscription，导致 GPU 空转。生产集群日志（4.65M 条 salloc 记录，覆盖 ~1,400 节点 / ~35,000 CPU 核心 / 数百 GPU）显示 H100 节点 P25 的 CPU-to-GPU ratio 仅为 0.25（1 核服务 4 GPU）。即便 vLLM V1 做了进程级隔离（API server / EngineCore / GPU workers 分属独立进程），所有进程仍竞争同一有限 CPU 核心池。
Q2 方法：本文通过 attacker-victim 实验设计系统性量化 CPU 瓶颈——向 vLLM v0.11.1 服务发送高负载 attacker 请求（1.8k–114k tokens，8/16 RPS），观测 victim 请求的 TTFT 退化。实验变量为 CPU 核心数（#GPUs+1 到 8×#GPUs）、GPU 数量（4/8）、模型（Llama 3.1 8B / Qwen 2.5 14B）、平台（H100 / H200 / RTX Pro 6000 Blackwell）。所有 GPU 侧优化开启：CUDA Graphs（full-and-piecewise）、chunked prefill、prefix caching、torch.compile、custom all-reduce。
根因分析识别两个结构性瓶颈：
/dev/shm）。Writer 必须 busy-wait 确认所有 $N$ 个 reader 已消费前一条消息才能写入下一条。CPU 核心不足时 writer 的 busy-wait 与 reader 进程争 CPU 时间，reader flag 更新延迟 → writer spin 更久 → 级联放大。竞争程度与 tensor parallelism degree 成正比。核心技术壁垒：broadcast 竞争是 1-writer-N-reader 模式的结构性属性——仅增加 CPU 核心无法完全消除，需要 async scheduling pipeline（IPC 与 GPU 执行重叠）、persistent GPU kernel（GPU 侧轮询 device-side queue）或 device-to-device signaling（绕过 CPU control plane）等架构变革。
Q3 结果：从最少 CPU（#GPUs+1 核）到充足 CPU，TTFT 改善 1.36–5.40×，跨三个平台 × 两个模型一致复现。5 核 → 32 核使 4-GPU 任务总时间从 68.4s 降至 7.7s（~9×，GPU 数量不变）。AWS pricing 下增加 16 vCPU 仅增加 ~1.5% 实例成本（$0.80/hr vs $55.04/hr）。CPU 不足配置下多个场景触发 200s timeout，表明系统进入 pathological state 而非仅仅变慢。
vLLM V1 架构下 CPU→GPU 的关键路径。CPU Host 内 API Server 的 Rayon 线程池执行 tokenization 后，EngineCore 通过 ZeroMQ 接收请求、经 shared-memory broadcast 向 $N$ 个 GPU worker 广播调度元数据。每个 worker 独立发起 kernel launch 驱动 GPU，GPU 间通过 NCCL all_reduce 做 barrier 同步。CPU 核心不足时：(a) Rayon 线程与 engine 进程争核心 → tokenization 延迟 + kernel launch 延迟；(b) broadcast 的 writer busy-wait 与 reader 争核心 → dequeue 膨胀；(c) barrier 将任一 rank 的延迟放大为全局停顿。
无形式化数学证明 — 本文以系统性实证 + 机理分析为主。
机理论证验证：
| # | 检查项 | 验证结果 |
|---|---|---|
| 1 | Straggler 放大一致性：单 rank 延迟 $\delta$ → 全局 barrier 延迟 $\geq \delta$。Fig.12 profiling trace 确认 4 GPU 共用 1–2 核心时 kernel launch 串行化、GPU busy-wait，与机理预测一致 | ✓ trace 匹配 |
| 2 | Broadcast 竞争 ∝ TP：writer 轮询 $N$ 个 reader flag，$N$ 越大竞争越严重。Fig.13 在 TP=4 下 dequeue 12 ms → 228 ms（19×）；Fig.7 中 8-GPU 比 4-GPU 更易 timeout | ✓ 定性一致 |
| 3 | Tokenization $O(L)$ 缩放：BPE 分词复杂度线性于输入长度 $L$。Fig.5 中 SL 1.6k→102.4k 时 tokenization 占 TTFT 持续 ~50%，与 chunked prefill 使 GPU 端也近线性一致 | ✓ 比值稳定 |
| 4 | 进程隔离不等于资源隔离：vLLM V1 将 API server / EngineCore / workers 拆分为独立进程，但共享 CPU 核心池。Fig.10 确认 5 核配置下 CPU 长时间 ~100% | ✓ 实验确认 |
| 5 | Cost-effectiveness 算术：16 vCPU × \$0.05/hr = \$0.80/hr ÷ \$55.04/hr ≈ 1.5% | ✓ 数值正确 |
| 6 | CUDA Graphs 覆盖边界：Graphs 可捕获静态 kernel 序列但无法覆盖 decode step 的动态控制流（EOS 检测、stop-condition、agent tool-call）。vLLM piecewise CUDA Graphs 仅部分覆盖；tokenization 完全在 CPU 侧不受 Graphs 影响 | ✓ 架构约束成立 |
Bandwidth budget（cluster-specific）：本文不提出新 collective 算法，而是观测 CPU 延迟如何叠加到 NCCL all_reduce 上。Barrier 同步使 collective 完成时间 = $\max(T_{\text{GPU-compute}}, T_{\text{slowest-CPU-dispatch}})$；当后者主导时 GPU 空转。Fig.11 验证此关系：5 核时 GPU 利用率极低（GPU 大部分时间等待 CPU dispatch），32 核时 GPU 满载（CPU dispatch 不再是瓶颈）。
Llama 3.1 8B, 4×H200, 16 CPU 核心。
| Batch × SL | Tokenization 占比 | 说明 |
|---|---|---|
| 1 × 1.6k | ~15% | 短序列时 GPU prefill 主导 |
| 1 × 102.4k | ~50% | 长序列时 tokenization 与 GPU 等量 |
| 16 × 25.6k | ~45% | 大 batch 放大 CPU 负载 |
Chunked prefill + FlashAttention 使 GPU prefill 近线性缩放（非二次），因此 tokenization 占比不随序列增长而下降——两端同步线性增长。
vLLM v0.11.1，从最少 CPU（#GPUs+1 核）到最佳 CPU 配置的加速比，Blackwell 平台：
| 模型 / GPU 数 / RPS | 加速比 |
|---|---|
| Llama-8B / 4 GPU / 8 RPS | 4.45× |
| Llama-8B / 4 GPU / 16 RPS | 4.38× |
| Llama-8B / 8 GPU / 8 RPS | 1.84× |
| Llama-8B / 8 GPU / 16 RPS | 3.14× |
| Qwen-14B / 4 GPU / 8 RPS | 5.40×（最大加速） |
| Qwen-14B / 4 GPU / 16 RPS | 3.51× |
| Qwen-14B / 8 GPU / 8 RPS | 2.29× |
| Qwen-14B / 8 GPU / 16 RPS | 1.36×（最小加速） |
H100 / H200 跨平台一致复现。最少 CPU 配置下多个场景触发 200s timeout（Fig.7 / Fig.9 红 × / ∞ 标记）。
4-GPU Llama 配置，attacker 负载下：
| CPU 核数 | 任务总时间 | CPU 100% 持续 | GPU 行为 |
|---|---|---|---|
| 5 | 68.4s | ~100s 持续饱和 | 利用率极低，长期空转 |
| 8 | 9.3s | 短暂尖峰 | 利用率显著提升 |
| 16 | 8.3s | 极短尖峰 | 接近满载 |
| 32 | 7.7s | 几乎无饱和 | 满载运行 |
5→32 核心约 9× 加速，GPU 数量始终为 4。边际收益递减：8→16 仅 12% 提升，16→32 仅 8%。
H100, TP=4, 5 RPS × 100k tokens：
| 指标 | 无负载 | 有负载 | 膨胀倍数 |
|---|---|---|---|
| dequeue() 延迟 | ~12 ms | 228 ms（峰值） | 19× |
| decode phase | 44 ms | 44 ms | 1×（GPU 不变） |
| dequeue / decode 比值 | 0.27× | 5.2× | — |
CPU control plane（dequeue）耗时从 GPU compute 的 27% 膨胀至 520%，完全主导 critical path。
4.65M salloc 记录，2024 年全年，两个机构集群：
| 集群 | GPU 类型 | P25 ratio | P50 ratio | 关键发现 |
|---|---|---|---|---|
| 教学集群 | H100 | 0.25 | 1.00 | 1 核服务 4 GPU |
| 教学集群 | A100 | 1.00 | 2.00 | 半数用户 ≤2 核/GPU |
| 科研集群 | H100 | — | 8.00 | ~60% 任务 ratio < 8 |
教学集群不强制 CPU-to-GPU 比例（Slurm 默认 --cpus-per-task=1），科研集群强制比例分配但仍有大量低 ratio 任务。
| Step | 论点 | 支撑证据 | 逻辑连接 |
|---|---|---|---|
| 1 | CPU 在 LLM 推理中承担 tokenization、kernel dispatch、IPC 三类关键工作，位于 GPU 计算的 critical path 上 | §2-A 架构分析；Fig.1 系统概览；Fig.2 推理流水线分解 | 建立 CPU 非旁观者的前提 |
| 2 | 生产集群中 CPU 普遍配置不足 | 4.65M salloc 记录；H100 P25 ratio=0.25（Fig.3）；~60% 任务 ratio<8（Fig.4） | Step 1 的理论风险在实践中广泛存在 |
| 3 | CPU 不足时 tokenization 主导 TTFT | Fig.5：tokenization 占 TTFT 高达 50%；BPE $O(L)$ 与 chunked prefill 均线性 → 比值不随 SL 下降 | 量化第一类 CPU 工作的延迟贡献 |
| 4 | CPU oversubscription 通过 NCCL barrier 同步放大为全局 GPU 停顿 | Fig.12 profiling trace：kernel launch 串行化 → GPU busy-wait；单 rank $\delta$ → 全局 $\geq \delta$ | 揭示第一个结构性根因（straggler 效应） |
| 5 | Shared-memory broadcast 的 1-writer-N-reader 竞争导致 IPC 延迟膨胀，且与 TP degree 成正比 | Fig.13：dequeue 19× 膨胀（12→228 ms），是 GPU decode 的 5× | 揭示第二个结构性根因 |
| 6 | 增加 CPU 核心是高性价比的缓解手段 | Fig.7/8/9：1.36–5.40× TTFT 改善；Fig.11：~9× 任务加速；AWS：~1.5% 成本增加 | 将根因分析转化为可操作建议 |
| 7 | Broadcast 竞争的结构性问题无法仅靠加核心解决，需要架构级变革 | §5-B 机理：lock-free busy-wait 即使核心充足仍有竞争，TP 越高越严重；提出 persistent GPU kernel / device signaling 等方向 | 限定 Step 6 适用边界，指出长期解法 |
vLLM V1 shared-memory broadcast（论文直接引用的代码路径）：
vllm/distributed/device_communicators/shm_broadcast.py：1-writer-N-reader broadcast queue。dequeue() 和 acquire_read() 是 Fig.13 profiling 的目标函数。Writer 通过 per-entry metadata flags + memory fence 实现 lock-free；reader 通过 busy-wait 轮询 writer flag。vllm/v1/engine/：V1 engine 架构，API server（tokenization + HTTP）与 EngineCore（scheduling）通过 ZeroMQ IPC 分离，EngineCore 到 GPU workers 通过 /dev/shm broadcast。HuggingFace Tokenizers：
tokenizers crate（Rust）：BPE / SentencePiece 实现，TOKENIZERS_PARALLELISM=true 启用 Rayon 多线程加速 subword 分割。多请求场景下 Rayon 线程数 × 并发请求数远超可用核心，形成 oversubscription。NCCL barrier 同步：
ncclAllReduce 要求所有 rank 同步到达。论文使用 PyTorch Profiler 在 4 GPU / 1–2 核心配置下捕获 kernel launch 串行化与 GPU busy-wait 行为（Fig.12）。关键实现细节：
TOKENIZERS_PARALLELISM 默认为 true，每次调用可 spawn 与物理核心数相当的 Rayon 线程。论文未测试 TOKENIZERS_PARALLELISM=false 或限制线程数的效果，留下一条未验证的低成本缓解路径。硬件层启示：论文 §6-A 指出三类架构解法方向：(1) GPU-initiated networking（NVSHMEM），GPU 直接发起通信绕过 CPU dispatch；(2) persistent GPU kernel，GPU 侧常驻 kernel 轮询 device-side queue 消除 per-step 的 CPU→GPU launch 开销；(3) GPU System Processor（NVIDIA RISC-V GSP），利用 GPU 片上控制处理器接管部分编排职责。共同目标是将 critical path 从 CPU control plane 迁移到 device 侧。