播面

CPU 推理（Inference）与 GPU 推理在基础设施（Infrastructure）设计上的差异，本质上源于硬件架构特性的不同（延迟敏感 vs. 吞吐敏感）以及成本模型的不同。

以下是从 Infra 架构师角度出发，对两者在设计上的核心差异进行的详细对比：

1. 核心设计理念与场景定位

• CPU Infra：追求低延迟与灵活性
  • 定位： 适用于小模型（如推荐系统、搜索排序、OCR）、复杂控制流模型、以及对实时性要求极高（Latency Sensitive）但吞吐量要求不大的场景。
  • 设计哲学： Batch Size = 1。CPU 擅长处理串行指令和分支预测，Infra 设计通常侧重于让单个请求以最快速度跑完。
• GPU Infra：追求高吞吐与并行度
  • 定位： 适用于大模型（LLM, Stable Diffusion）、计算机视觉（CV）、以及离线批量处理任务。
  • 设计哲学： Dynamic Batching（动态批处理）。GPU 核心数成千上万，必须凑够一定数量的数据（Batch）才能打满算力，Infra 设计侧重于“攒批”和流水线掩盖。

---

2. 调度与资源隔离 (Scheduling & Isolation)

这是 K8s 层面的核心差异：

CPU 推理

• NUMA 亲和性 (NUMA Affinity)： CPU 推理极其依赖内存带宽。在双路/多路服务器上，Infra 必须保证 Pod 被调度到同一 NUMA 节点的 CPU 核上，且内存也分配在同侧，否则跨 Socket 访问内存会导致性能下降 20%-30%。
• 绑核 (Core Pinning)： 为了减少上下文切换（Context Switch）和 L1/L2 缓存失效，Infra 通常需要使用 cpuset 将推理进程绑定到具体的物理核上。
• 干扰隔离： 主要关注 L3 缓存争用（Noisy Neighbor）。

GPU 推理

• 独占 vs. 共享：
  • 独占模式： 以前通常是一个 Pod 独占一张卡。
  • MIG (Multi-Instance GPU)： A100/H100 允许将物理 GPU 切割成多个独立的硬件实例（显存和计算单元物理隔离），Infra 需要管理这些切片资源。
  • MPS (Multi-Process Service)： 对于算力需求小的小模型，利用 MPS 可以在同一张卡上运行多个进程，提高利用率，但显存无物理隔离，Infra 需处理潜在的 OOM 风险。
• 拓扑感知： 在多卡推理（如大模型）场景下，Infra 必须感知 GPU 的 NVLink 拓扑，确保同一 Pod 申请的 GPU 之间有高速互联，避免跨 PCIe Switch 通信。

---

3. 流量处理与批处理策略 (Traffic & Batching)

CPU 推理

• 请求处理： 通常采用同步阻塞或简单的异步模式。
• Batching： 往往不需要 Batching，或者 Batch Size 很小（2-4）。因为 CPU 的 SIMD（AVX-512/AMX）并行度有限，过大的 Batch 反而导致延迟增加且无法显著提升吞吐。
• 并发控制： 主要通过水平扩容（增加 Pod 数量）来应对高并发。

GPU 推理

• 请求处理： 必须有一个中间层（如 Triton Inference Server, TGI, vLLM）来接管流量。
• Dynamic Batching（核心差异）： Infra 必须实现动态攒批机制。请求到达后不会立即执行，而是等待几毫秒（Time Window）凑够一个 Batch 再送入 GPU。
• KV Cache 管理 (LLM 特有)： 对于大模型，Infra 还需要关注显存中的 KV Cache 管理（如 PagedAttention），这直接影响并发量（Concurrency）。

---

4. 数据传输与 IO (Data Transfer)

• CPU：
  • 零拷贝 (Zero-copy)： 数据就在主存中，模型直接读取，没有额外的数据搬运开销。
  • 瓶颈： 内存带宽（Memory Bandwidth）。Infra 选型时更看重内存通道数和频率（如 DDR5）。
• GPU：
  • Host-to-Device 开销： 数据必须从 CPU 内存拷贝到 GPU 显存（H2D），推理完再拷回（D2H）。
  • Infra 优化： 需要利用 Pinned Memory（锁页内存）加速传输；在图像处理中，常使用 NVIDIA DALI 等库在 GPU 上直接做预处理，减少 CPU-GPU 传输的数据量。

---

5. 弹性伸缩与冷启动 (Autoscaling & Cold Start)

• CPU：
  • 冷启动快： 模型加载通常只需几百毫秒到几秒。
  • Serverless 友好： 非常适合 Scale-to-Zero（缩容到0）的场景，流量来了瞬间拉起。
  • 扩容策略： 线性扩容，基于 CPU 利用率或 QPS 扩容即可。
• GPU：
  • 冷启动慢： 大模型加载到显存可能需要几十秒甚至分钟级。需要预热（Warmup）。
  • 资源池化： 由于 GPU 昂贵且启动慢，通常不建议频繁销毁 Pod。Infra 设计倾向于维护一个“热池”（Warm Pool）或使用模型热切换（Model Swapping）技术。
  • 扩容指标： 显存利用率通常不是好指标（因为会预分配），通常基于“待处理队列长度”或“KV Cache 使用率”进行扩容。

---

6. 成本与选型 (Cost & SKU)

• CPU：
  • 通用性： 使用现有的 Web 服务集群即可，闲时可混部离线任务。
  • 指令集优化： Infra 需关注 CPU 是否支持 AVX-512, VNNI, AMX (Intel Sapphire Rapids) 等加速指令集。
• GPU：
  • 专用性： 昂贵，闲置成本极高。
  • 量化差异： GPU 推理目前主流是 FP16/BF16，甚至 FP8/INT4。Infra 需要确保驱动版本、CUDA 版本与模型量化精度的兼容性。

总结对比表

一句话总结：
CPU Infra 设计关注的是如何减少干扰以跑得更快（低延迟），而 GPU Infra 设计关注的是如何塞进更多数据以填满算力（高吞吐）以及如何管理昂贵的显存资源。