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

# CPU 推理和编排
<a name="aiml-cpu-inference"></a>

## 概述
<a name="_overview"></a>

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

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

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

 **本指南适用于：**
+  **平台工程师**为 AI 工作负载设计多租户 EKS 集群。
+  **机器学习从业者**评估300B参数下的模型的推理后端。
+  FinOps 在不牺牲 SLO 的情况下寻找具体的成本杠杆的@@ **团队**。

 **你将学到什么：**
+ 哪些 AI 工作负载属于 CPU，哪些地方需要 GPU 或 Trainium。
+ 如何将四维决策框架应用于任何新的工作负载。
+ 两种生产模式：代理SLM预过滤和高密度模型农场。
+ 优化最佳实践：量化、装箱、Spot 调度和自动缩放。

**警告**  
本指南中的每一项建议都应根据经验进行验证。正确的实例系列（arm64、x86、GPU 或 Trainium）取决于您的模型、数据和延迟预算。使用本指南作为明智的起点，然后在提交之前进行基准测试。

## 为什么 CPU 用于 AI 工作负载？
<a name="_why_cpus_for_ai_workloads"></a>

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

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

### 容量可用性
<a name="_capacity_availability"></a>

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

### 经济学
<a name="_economics"></a>

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

### 操作简单
<a name="_operational_simplicity"></a>

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

### 代理管道中的 CPU 表面越来越大
<a name="_growing_cpu_surface_in_agentic_pipelines"></a>

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

## CPU 与 GPU /Trainium：何时选择每个
<a name="_cpu_vs_gpu_trainium_when_to_choose_each"></a>


| 因素 | 选择 CPU | 选择 GPU/Trainium | 
| --- | --- | --- | 
| 模型大小 | SLM 1-8B（量化）；嵌入；分类器 | 8B\+ 用于低延迟在线推理；一般为 70B \+ | 
| 延迟 SLO | p95 100-500ms 可以接受 | p95 需要 < 50 毫秒 | 
| 并发 |  req/s 每个端点 < 100 | > 100 req/s 持续 | 
| 工作负载类型 | 编排、检索、ETL、批量评分 | 在线推理、微调、训练 | 
| Capacity | 即时可用，无需预订 | 通常需要预留容量 | 
| 成本敏感度 | CPU 为符合条件的工作负载提供最优惠的美元/代币 | GPU 在高利用率时摊销 | 
| 团队专业知识 | 标准的 Kubernetes 操作 | 需要 GPU 操作知识 | 
| 数据主权 | VPC 中的 SLM 推理；完整的审计跟踪；数据永远不会离开您的账户 | 自行管理则相同；不适用于外部 API | 

**提示**  
这些阈值是起点。我们建议在提交计算层之前，使用实际模型和流量模式在候选实例系列（arm64 和 x86）上运行目标推理引擎。

## 工作负载决策框架
<a name="_workload_decision_framework"></a>

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

1.  **模型大小和精度**：量化能否将质量保持在可接受的范围内？

1.  **延迟和吞吐量 SL** O：您的 p50/p95 目标和峰值请求速率是什么？

1.  **工作负载类型**：在线推理、批量评分、检索还是编排？

1.  **成本和容量限制**： FinOps 预算、区域供应情况、预订策略？

使用下表作为决策矩阵。


| 工作负载 | CPU | GPU/Trainium | 注意 | 
| --- | --- | --- | --- | 
| SLM（1-8B 参数，量化） | 默认选择。在 100-500 毫秒延迟下具有很强的性价比，QPS 适中。跨实例系列进行基准测试。 | 当 p95 <50ms or concurrency >100 req/s 的时候。 | 推荐 Q4\_K\_M 或 Q8\_0 量化 | 
| 中型模型（8-30B 参数） | Batch、异步、离线评分。测试第 4 季度的量化。 | 在线推理、较长的上下文、极短的延迟。 | 跨实例系列的第 4 季度基准测试 | 
| 大型 LLM（70B 以上的参数） | Non-real-time 只是，大量量化 | 生产在线推理的默认值 | 即使是 70B 也能在 CPU 上运行；预计延迟会很高 | 
| 古典机器学习/嵌入/简历 | High-density 服务；跨节点装箱。 | 大视野或大规模多模式。 | TorchServe，CPU 上的 Triton 可以处理数千个模型。 | 
| 数据管道/ETL/合成数据 | CPU 上的 Ray 和 Spark 用于数据准备和功能工程。 | N/A | CPU 支撑了整个数据准备阶段 | 
| 代理编排/RAG 检索 | Network-bound 服务：API 网关、代理层、检索器、区块器。 | N/A | 受益于高带宽 CPU 实例。 | 
| Fine-tuning /训练 | 数据准备和管道编排。 | 模型训练和提炼。 | 混合动力：CPU 准备、GPU 训练、CPU 推断。 | 
| Compliance-sensitive 推断（金融服务业、医疗保健、政府） | CPU 上的 VPC 中的 SLM。数据保留在账户中，完整审计跟踪。 | 如果在 GPU 上进行自我管理，则相同。 | 在受监管的环境中，CPU 凭借低于 8B 的机型的成本获胜。 | 

**警告**  
虽然从技术上讲，在大量量化的 CPU 上运行 70B 以上的模型是可能的（第四季度或更低），但这仅适用于非实时、离线或批处理工作负载。预计代币生成率将保持在较低的个位数（1-5 tokens/sec），即使在第四季度，内存需求也将超过40GB，对于较长的输出，每次响应的延迟以分钟为单位。对于任何交互式或对延迟敏感的用例，700亿以上的模型属于GPU或Trainium。

### 快速基准测试工作流程
<a name="_quick_benchmark_workflow"></a>

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

## 生产模式
<a name="_production_patterns"></a>

### 模式 1：Agentic AI — CPU Pre-Filter 上的 SLM 和 LLM 升级
<a name="_pattern_1_agentic_ai_slm_pre_filter_on_cpu_with_llm_escalation"></a>

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

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

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

 **在 CPU 上运行的组件：**
+ API 网关/代理层 — 处理身份验证、路由、速率限制
+ 代理协调器-管理工具调用和状态
+ [https://ollama.com](https://ollama.com)
+ 向量检索- OpenSearch 在 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](https://arxiv.org/abs/2405.00732)）的研究表明，经过微调的7B模型 GPT-4 在测试的大多数特定领域任务中表现优于其他领域，这使得许多生产用例都可行 “微调小型模型并在CPU上运行” 路径。

### 模式 2： High-Density CPU 模型群
<a name="_pattern_2_high_density_cpu_model_farm"></a>

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

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

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

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

## 优化最佳实践
<a name="_optimization_best_practices"></a>

### 量化
<a name="_quantization"></a>

在 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 量化格式。


| 量化 | 质量影响 | 吞吐量与 BF16 对比 | 使用场景 | 
| --- | --- | --- | --- | 
| Q4\_K\_M | 低（1-3% 的困惑度增量，视型号而定） | 速度提高大约 4-5 倍 | SLM 的生产默认值 | 
| Q8\_0 | 可以忽略不计 | 速度提高了大约 2 倍 | Quality-sensitive 任务 | 
| Q5\_K\_M | 非常低 | 速度提高了大约 3.5 倍 | 质量和速度的平衡 | 
| BF16 | 无 | 1x（基准） | 对于 7B 以上的机型，请避免在 CPU 上使用 | 

对于低于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，但对于较长的输入，它仍然有帮助。

**提示**  
Q4\_K\_M 质量下降因模型和任务而异。在部署到生产环境之前，请务必对自己的数据集进行评估。

### Bin-packing 适合密集食用
<a name="_bin_packing_for_dense_serving"></a>

对于经典机器学习和嵌入模型（通常每个模型 <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 个线程几乎总是会获胜。

### 日程安排和成本优化
<a name="_scheduling_and_cost_optimization"></a>

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

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

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

### 容器启动优化
<a name="_container_startup_optimization"></a>

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

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

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

### 可观测性
<a name="_observability"></a>

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

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

 **仪器的关键指标：**


| 指标类别 | 说明 | 警报阈值 | 
| --- | --- | --- | 
| 请求处理/正在处理中 | 服务器当前正在处理的请求数。 | 用于缩放（参见下面的自动缩放部分） | 
| 请求已排队/已延迟 | 等待处理时段的请求数。 | 缩放触发器。任何持续的队列都意味着延迟即将降低。 | 
| 代币吞吐量 | 每秒生成的代币。 | 如果负载下吞吐量降至基准的 50% 以下，则发出警报 | 
| 请求延迟 | End-to-end 延迟直方图（提示处理\+令牌生成）。 | 在 p95 超出你的 SLO 时发出警报 | 
| KV 缓存利用率 | 键值缓存的填满程度（0.0 到 1.0）。接近 1.0 意味着服务器将开始拒绝请求或排队请求。 | 85% 以上时发出警报 | 
| 容器内存 | 每个 pod 的 RSS 内存 (`container_memory_working_set_bytes`)。 | 在限制的 85% 时发出警报 | 

### 自动扩展：根据队列深度进行扩展，而不是 CPU 利用率
<a name="_autoscaling_scale_on_queue_depth_not_cpu_utilization"></a>

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 工作负载的模型质量
<a name="_evaluating_model_quality_for_cpu_first_workloads"></a>

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

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

### 要评估什么
<a name="_what_to_evaluate"></a>

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


| 工作负载 | 什么可能会降解 | 要衡量什么 | 
| --- | --- | --- | 
| 意图或门票分类 | 输入模棱两可时出错 | 精度，每级 F1 | 
| 结构化提取 (JSON) | 缺少字段或架构错误 | 精确匹配，架构有效性 | 
| RAG 答案 | 出现幻觉或忽视背景 | 忠诚，答案的相关性 | 
| 总结 | 事实缺失或报道不佳 | ROUGE-L，bertScore，人工评论 | 
| 代理路由 | 选择了错误的工具 | 刀具精度 | 
| 嵌入 | 检索质量较差 | 回想一下 @K，NDCG | 

### 实用的评估工作流程
<a name="_a_practical_evaluation_workflow"></a>

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

1.  **构建评估数据集** — 根据您的实际工作负载构建一个小型评估数据集（100-300 个带标签的示例）。避免使用像 MMLU 这样的通用基准来衡量一般推理，而不是你的实际任务。

1.  **建立基准**-根据可信模型运行数据集（例如，你知道的大型 LLM 会产生正确的结果）。

1.  **测试 CPU 模型** — 在量化的 SLM 上运行相同的数据集并进行比较。

1.  **评估**-在测试之前定义质量阈值，例如，“SLM 准确度在基线的 5 个百分点以内”。正确的阈值取决于任务：与自动决策的系统相比，由人类审查的分类器可以容忍更多的错误。

### 如何恢复质量
<a name="_how_to_recover_quality"></a>

如果模型表现不佳，请按努力顺序尝试以下方法：
+  在@@ **提示中添加少量示例**：零成本，即时。在提示中包含 3-5 个带标签的示例通常可以缩小分类和提取任务的差距。
+  **使用更高质量的量化格式**：从第 4 季度移动到第 8 季度通常会恢复大部分丢失的质量，代价是内存增加大约 2 倍，吞吐量会降低。
+  **使用混合路由**：让 SLM 处理简单的案例，并将困难的输入发送到更大的模型。这是一项架构变更，但对于大多数流量，可以保持较低的 CPU 成本。
+  **Fine-tune 您所在域名的模型**：最昂贵的选择，但最有效。LoRa Land（[ar Xiv:2405.00732](https://arxiv.org/abs/2405.00732)）的研究发现，经过微调的7B模型在测试的大多数特定领域任务中表现优 GPT-4 于其他领域。

## 参考
<a name="_references"></a>
+  [亚马逊 EKS 文档](https://docs.aws.amazon.com/eks/) 
+  [AWS Graviton 开发者指南](https://github.com/aws/aws-graviton-getting-started) 
+  [Karpenter 文档](https://karpenter.sh/docs/) 
+  [KEDA 文档](https://keda.sh/docs/) 
+  [llama.cpp](https://github.com/ggerganov/llama.cpp) 
+  [vlLM 文档](https://docs.vllm.ai) 
+  [奥拉玛](https://ollama.com) 
+  [射线服务文档](https://docs.ray.io/en/latest/serve/) 
+  [亚马逊 OpenSearch 服务](https://docs.aws.amazon.com/opensearch-service/) 
+  [AWS Spot 最佳实践](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) 
+  [LoRa Land：跑赢大盘的 Fine-Tuned Open-Source 法学硕士 GPT-4](https://arxiv.org/abs/2405.00732) 
+  [模型上下文协议 (MCP) 规范](https://modelcontextprotocol.io) 
+  [Agentic AI 的小型语言模型 (NVIDIA)](https://arxiv.org/abs/2506.02153) 
+  [SOCI 快照器](https://github.com/awslabs/soci-snapshotter) 
+  [Bottlerocket 操作系统](https://bottlerocket.dev) 
+  [EKS 上的 AI：容器启动优化](https://awslabs.github.io/ai-on-eks/docs/guidance/container-startup-time/accelerate-pull-process)