本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

CPU 推理和编排

概述

CPU 实例是 Amazon EKS 上各种 AI 工作负载的一流计算选项。从小型语言模型 (SLM) 和经典的机器学习推理到数据管道和代理编排，CPU 提供了强大的性价比、广泛的容量可用性和熟悉的 Kubernetes 调度语义。

CPU 和 GPU 是互补的，没有竞争力。随着代理人工智能管道的复杂性增加，CPU 工作负载也随之增长：每个推理调用都被工具执行、上下文汇编、矢量搜索、护栏和编排逻辑所包围，所有这些都在 CPU 上运行。我们建议在设计架构时刻意使用两种计算类型，将每种工作负载放在可提供最佳性价比的层级。

并非每个工作负载都需要 GPU。路由、分类、检索、嵌入、编排以及越来越多的语言模型推理都在 CPU 上有效运行。 Current-generation 跨越arm64和x86的CPU实例为机器学习推理提供了强大的性价比。再加上 Karpenter 的节点整合、KEDA 的事件驱动扩展和量化模型服务，这提供了一个生产就绪型堆栈，平台团队无需深厚的 GPU 专业知识即可运行该堆栈。

本指南适用于：

你将学到什么：

为什么 CPU 用于 AI 工作负载？

生产 AI 管道将工作分散到多个计算层。CPU 处理路由、分类、检索、编排和越来越多的推理。 Current-generation CPU 实例具有很高的性价比和熟悉的 Kubernetes 调度，使其成为许多 AI 工作负载的实用选择。

有三个因素使 CPU 对这些工作负载具有吸引力：

容量可用性

GPU 实例通常需要提前几周预留容量。CPU 实例可在所有 AWS 地区广泛使用，没有专门的设备插件，没有 DRA 配置，也没有 MIG 分区。当您需要快速扩展时，CPU 容量是最容易获得的选择。

经济学

Current-generation CPU 实例为机器学习推理提供了强劲的性价比。对于运行 FinOps 审查或管理多租户集群的团队来说，CPU 和 GPU 之间的成本差异很大，特别是对于量化的 SLM 而言，GPU 加速带来的回报会越来越少。我们建议对可用实例系列（Graviton、AMD、Intel）进行基准测试，以找到最适合您的工作负载的每代币成本。

操作简单

CPU 容器使用标准的 Kubernetes 调度（requests、、节点亲和性limits、拓扑分布）。没有设备插件，没有自定义调度器，没有nvidia.com/gpu资源类型。想要在没有深厚的 GPU 专业知识的情况下运行 AI 工作负载的团队可以更快地使用 CPU 实现生产。

代理管道中的 CPU 表面越来越大

在代理人工智能管道中，每个 GPU 推理调用都被 CPU 工作所包围：工具执行、上下文组装、矢量搜索、嵌入查询、护栏、响应验证、内存管理和编排逻辑。随着代理变得越来越复杂（更多的工具、更长的链、多步推理），这些 CPU 工作负载会以超线性方式增长。像 MCP（模型上下文协议）这样的协议进一步放大了这一点：每个 MCP 工具调用都会触发完全在 CPU 上运行的数据检索、转换和格式化。

CPU 与 GPU /Trainium：何时选择每个

工作负载决策框架

为 AI 工作负载选择正确的计算可归结为四个维度：

使用下表作为决策矩阵。

快速基准测试工作流程

在提交实例系列之前，我们建议您运行结构化基准测试，将候选的 CPU 系列（arm64 和 x86）与 GPU 进行比较，并使用一个可比指标：目标 p95 延迟下的每 1,000 次查询成本。每个系列部署一个具有相同模型配置（相同的量化、上下文大小、线程数）的节点，对每个节点进行负载测试并进行比较。如果 CPU 实例符合你的 p95 SLO，它很可能会在成本上获胜。如果漏掉的幅度很小，请在迁移到 GPU 之前尝试该系列中的最新一代产品。如果您的并发目标延迟仍然过高，那就是将工作负载转移到 GPU 的信号。

生产模式

模式 1：Agentic AI — CPU Pre-Filter 上的 SLM 和 LLM 升级

大多数代理工作流程都会重复执行相同的狭窄模式：对请求进行分类、选择工具、提取结构化数据、验证响应。这些任务不需要 70B 参数模型。

对 SLM (ar Xiv:2506.02153) 的研究表明，在 100B 参数下的模型，当专门用于某个域时，可以在受限的子任务上匹配或超过大型 LLM，同时以显著降低的成本和延迟在 CPU 上高效运行。当模型针对特定领域进行微调时，其较小的占用空间可以使其比调用通用 LLM 更准确、更便宜。

在这种模式下，CPU 上的 SLM 可以端到端地处理大多数请求。路由层（也在 CPU 上运行）只能将真正复杂的情况升级为 GPU-hosted LLM。

在 CPU 上运行的组件：

开启的组件 GPU/Trainium：

为什么这种模式起作用：在许多代理工作流程中，60-80% 的请求可由 SLM 分类或提取。对于您避免的每个 LLM 调用，您还可以避免周围的 CPU 工作，例如组装大型上下文窗口、在长响应中运行护栏以及管理复杂状态。CPU 层独立于 GPU 层进行扩展。

典型代理管道中的 CPU 工作负载类别包括：工具执行（MCP 服务器调用、API 调用、数据库查询）、上下文汇编、矢量搜索和嵌入查询、编排和规划逻辑、护栏和安全筛选、响应验证和格式化、代理内存和状态管理，以及。 logging/observability

这种模式也适合微调生命周期：在 CPU 节点上收集域数据，在 GPU 上进行微调，然后将量化模型部署回 CPU 进行推理，成本比 LLM 端点低得多。LoRa Land（ar Xiv:2405.00732）的研究表明，经过微调的7B模型 GPT-4 在测试的大多数特定领域任务中表现优于其他领域，这使得许多生产用例都可行 “微调小型模型并在CPU上运行” 路径。

模式 2： High-Density CPU 模型群

生产机器学习管道通常会部署成百上千个较小的模型：嵌入模型、推荐模型、分类器、 BERT-based 评分器和计算机视觉模型。这些模型单独轻量级，当为每个模型分配自己的 GPU 资源时，它们就会变得昂贵。

我们建议使用高密度 CPU 服务（使用 TorchServe 或 Triton 在 CPU 上为每个节点打包多个模型），由 Karpenter 管理节点生命周期，Keda 根据观察到的负载进行扩展。

这种模式自然延伸到 RAG 架构中：嵌入生成、文档分块和检索 OpenSearch 都在 CPU 节点上经济实惠地运行，仅在最后生成步骤中将结果提供给 GPU-hosted LLM。CPU 群负责处理音量；GPU 负责处理复杂性。

对于受监管的行业（金融服务、医疗保健、政府）来说，这种模式尤其引人注目：数百种专门的模型在CPU上运行在VPC内，具有完整的审计跟踪和永远不会离开账户的数据。自我管理推理的合规性要求自然符合低于 8B 模型的 CPU 成本优势。

优化最佳实践

量化

在 CPU 上以完整的 BF16 运行一个 7B 模型是不切实际的；在第 4 季度量化时运行它既可行又具有成本效益。了解量化为何对 CPU 有帮助，是做出正确基础设施决策的关键。

为什么量化对 CPU 推断很重要。CPU 推断受内存带宽限制，而不是计算限制。在解码阶段（一次生成一个代币），每个生成的代币都会从 RAM 中读取模型的全部权重。CPU 大部分时间都在等待数据从内存中到达，而不是进行数学运算。BF16的7B机型大约为14GB；在Q4_K_M，它缩小到大约 4GB。由于瓶颈是将字节从RAM转移到CPU内核，因此小3.5倍的模型的读取速度提高了3.5倍，这几乎直接意味着令牌生成速度提高了3.5倍。这就是为什么量化是最有影响力的 CPU 推理优化的原因，也是为什么具有更多内存通道的新一代 CPU 即使在相同的时钟速度下也能产生更快的推理的原因。

我们建议使用架构优化的后端（ARM NEON/SVE2 适用于 arm64，对于 x86）构建推理引擎， AVX-512/AMX 将线程数设置为 vCPU 计数，然后选择 Q4_K_M 或 Q8_0 量化格式。

对于低于2b的机型，CPU在性价比上胜过GPU。这些模型足够小，GPU 加速带来的好处微乎其微，而每小时的成本要高得多。如果您的工作负载可以使用低于 2B 的模型，则建议使用默认配置 CPU。

Architecture-specific 优化：在 arm64 上，当前一代 Graviton 实例支持 SVE2。使用适合目标的-march标志来构建您的推理引擎。在 x86 上，AMD EPYC 实例支持 AVX-512，英特尔至强实例添加了 AMX 以实现矩阵加速。由于推理受内存带宽的限制，因此即使在相同的时钟速度下，具有更多 DDR5 内存通道的新一代 CPU 也能产生更快的推理。选择实例类型时，应优先考虑内存带宽而不是核心数量。

上下文窗口大小：对于分类和路由工作负载，输入通常低于 200 个标记，输出为 2-3 个标记。设置较小的上下文窗口（例如 512 个令牌）而不是默认的 2048，可降低 KV 缓存内存使用量并改善每个请求的延迟。只有当您的输入确实很长时，才会增加上下文窗口。

Flash 注意：如果您的推理引擎支持 Flash Attention，请启用。Flash Attention 通过避免实现完整的注意力矩阵来减少注意力计算的内存使用量。在CPU上，其优势要小于GPU，但对于较长的输入，它仍然有帮助。

Bin-packing 适合密集食用

对于经典机器学习和嵌入模型（通常每个模型 <500MB），目标是在稳定的尾部延迟下每个节点的最大 pod 密度。有两个因素决定你能否实现这一目标：准确的资源请求和受控的线程。

requests根据实际负载下观察到的 p50-p90 使用情况。使用负载测试中的 Goldilocks、VPA 推荐或 Prometheus 直方图。两个方向的默认值几乎总是错误的。

机器学习库（PyTorch、ONNX Runtime、MKL、OpenBLAS）在节点上生成尽可能多的线程，而不是分配给 pod 的 CPU。在拥有 20 个 pod 的密集节点上，每个 Pod 都会尝试生成 32 个线程。该节点在上下文切换和 p99 延迟峰值时大放异彩。明确修复这个问题：

env:
  - name: OMP_NUM_THREADS
    value: "2"          # match your cpu request (2000m = 2 threads)
  - name: MKL_NUM_THREADS
    value: "2"
  - name: OPENBLAS_NUM_THREADS
    value: "2"
  - name: INTRA_OP_NUM_THREADS    # PyTorch / ONNX Runtime
    value: "2"
  - name: NUM_INTER_THREADS
    value: "1"          # keep inter-op parallelism minimal

将每个值设置为等于或低于您的 CPU 请求。对于拥有 4 个以上内核的 pod，基准测试从 2-4 个线程开始。由于缓存效率高，许多小型模型在使用更少的线程时性能更好。如果您将 HPA 与许多薄 pod 一起使用，则每个 Pod 有 1-2 个线程几乎总是会获胜。

日程安排和成本优化

两种做法相结合，可以显著降低 CPU 推断成本：采用 Karpenter 整合的 Spot 实例和多架构容器映像。

Karpenter 的整合非常适合 CPU 推理，因为队列或负载均衡器后面的无状态推理 pod 可以优雅地容忍中断。将整合配置为对未充分利用的节点采取行动，预算限制并发中断（例如，一次只能有 20% 的节点），以避免在缩小规模期间容量下降。Karpenter 的nodePool规范允许你在单个池中混合 Spot 和 On-Demand 容量，将 Spot 作为首选选项和 On-Demand 备用选项。

构建多架构映像（arm64和amd64）可以进一步解锁这一点。由于这两种架构都可用，Karpenter 可以根据实时价格和可用性从全系列实例系列（Graviton、AMD、Intel）中进行选择。这对于竞价型工作负载特别有价值，在这些工作负载中，跨实例类型和架构进行多样化可以降低中断频率。使用docker buildx或具有多平台版本的 CI 管道来生成涵盖两种架构的单个清单。

容器启动优化

当 Karpenter 配置新节点（向上扩展、Spot 替换）时，容器运行时需要在 pod 启动之前提取推理图像。对于多 GB 的推理图像，这可能会延长 Pod 启动时间 30-60 秒。

我们建议使用 Bottlerocket 作为推理工作负载的节点操作系统，并在并行模式下与 SOC I 快照器结合使用。 pull/unpack SOCI 用基于并行区块的下载取代了默认的顺序图层提取，从而大大缩短了大图像的图像提取时间。无需更改您的容器镜像。

有关详细的配置指南，请参阅本指南的 “性能” 部分，其中包括 SOCI 配置、EBS 快照预提取和容器运行时缓存策略。

可观测性

如果模型层没有可观测性，你就是在盲目缩放。我们建议公开每项推理服务的 Prometheus 指标，并使用它们来推动 KEDA 扩展和操作仪表板。

大多数推理服务器（llama.cpp、vlLM、Triton 等 TorchServe）都会在端点上公开 Prometheus-compatible 指标。/metrics指标名称因服务器而异，但概念相同。

仪器的关键指标：

自动扩展：根据队列深度进行扩展，而不是 CPU 利用率

CPU 利用率是一个饱和度指标。延迟已经降低后，它会达到峰值。当基于利用率的自动缩放做出反应时，用户已经在等待。

队列深度（请求 deferred/waiting）是一个领先指标。它会在延迟下降之前上升，因为当所有处理插槽都处于繁忙状态时，请求就会开始排队。扩展队列深度意味着在现有副本仍能正常响应的情况下配置新的副本。

KEDA 支持使用将多个指标合并到单个缩放公式中scalingModifiers（需要 KEDA 2.12+）。推理工作负载的推荐模式是将正在运行的请求与排队的请求相结合，从而对队列指标进行大量加权：

advanced:
  scalingModifiers:
    formula: "running + (waiting * 10)"
    target: "25"
    activationTarget: "5"

该公式running + (waiting * 10)意味着，即使有 3 个排队的请求也会将合并后的指标推至 55，远高于 25 的目标。在延迟下降之前开始扩展。of activationTarget 5 可防止噪声触发不必要的从零缩放的事件。

评估 CPU-First 工作负载的模型质量

在 CPU 上部署量化 SLM 是一个成本和延迟的决定。只有当模型仍然能为你的工作负载生成正确、有用的输出时，这才有意义。

较小的模型或量化可以降低计算成本，但会降低质量。影响各不相同。在 CPU 上运行良好的工作负载（分类、提取、路由、汇总、嵌入）通常通过适当的量化和提示在 3 个B-7B 范围内保持良好的质量。

要评估什么

不同的工作负载会以不同的方式降级：

实用的评估工作流程

我们建议在生产之前创建质量检查，类似于在选择实例类型之前运行负载测试的方式。该工作流程分为四个阶段：

如何恢复质量

如果模型表现不佳，请按努力顺序尝试以下方法：

参考