本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

CPU 推論和協調

概觀

CPU 執行個體是 Amazon EKS 上各種 AI 工作負載的一級運算選項。從小型語言模型 SLMs) 和傳統 ML 推論到資料管道和代理程式協同運作，CPUs 提供強大的價格效能、廣泛的容量可用性和熟悉的 Kubernetes 排程語意。

CPU 和 GPU 是互補的，而非競爭性。隨著代理式 AI 管道的複雜性增加，CPU 工作負載表面也會隨之增加：每個推論呼叫都被工具執行、內容組合、向量搜尋、護欄和協同運作邏輯包圍，這些邏輯全都在 CPU 上執行。我們建議刻意設計使用兩種運算類型的架構，將每個工作負載放在提供最佳成本效能的 層。

並非每個工作負載都需要 GPU。路由、分類、擷取、內嵌、協同運作，以及不斷增加的語言模型推論，全都在 CPU 上有效執行。跨 arm64 和 x86 的新一代 CPU 執行個體為 ML 推論提供強大的價格效能。結合 Karpenter 的節點整合、KEDA 的事件驅動擴展和量化模型服務，這提供了一個生產就緒的堆疊，平台團隊無需深厚的 GPU 專業知識即可操作。

本指南適用於：

您將學到什麼：

為什麼選擇適用於 AI 工作負載的 CPUs？

生產 AI 管道會將工作分散到許多運算層。CPUs處理路由、分類、擷取、協同運作，以及越來越多的推論。新一代 CPU 執行個體提供強大的價格效能和熟悉的 Kubernetes 排程，使它們成為許多 AI 工作負載的實用選項。

讓 CPU 吸引這些工作負載的三個因素：

容量可用性

GPU 執行個體經常需要提前幾週保留容量。CPU 執行個體可在所有 AWS 區域中廣泛使用，無需特殊化裝置外掛程式、DRA 組態，也無需 MIG 分割。當您需要快速擴展時，CPU 容量是最容易使用的選項。

經濟效益

新一代 CPU 執行個體為 ML 推論提供強大的價格效能。對於執行 FinOps 檢閱或管理多租用戶叢集的團隊，CPU 和 GPU 之間的成本差異很重要，尤其是 GPU 加速提供降低回報SLMs。我們建議跨可用執行個體系列 (Graviton、AMD、Intel) 進行基準測試，以尋找工作負載的最佳cost-per-token。

操作簡單性

CPU Pod 使用標準 Kubernetes 排程 (requests、limits、節點親和性、拓撲分散）。沒有裝置外掛程式、沒有自訂排程器、沒有nvidia.com/gpu資源類型。想要在沒有深度 GPU 專業知識的情況下執行 AI 工作負載的團隊可以更快地在 CPU 上實現生產。

在代理管道中增長 CPU 表面

在代理式 AI 管道中，每個 GPU 推論呼叫都被 CPU 工作包圍：工具執行、內容組件、向量搜尋、內嵌查詢、護欄、回應驗證、記憶體管理和協同運作邏輯。隨著客服人員的成長更複雜 （工具越多、鏈結越長、多步驟推理），這些 CPU 工作負載會以超線性方式成長。例如 MCP （模型內容通訊協定） 的通訊協定會進一步擴增：每個 MCP 工具呼叫都會觸發完全在 CPU 上執行的資料擷取、轉換和格式化。

CPU 與 GPU/ Trainium：何時選擇每個

工作負載決策架構

選擇適合 AI 工作負載的運算，有四個維度：

使用下表做為決策矩陣。

快速基準工作流程

在遞交執行個體系列之前，我們建議在單一可比較指標上，執行比較候選 CPU 系列 (arm64 和 x86) 與 GPU 的結構化基準測試：在目標 p95 延遲時每 1，000 個查詢成本。使用相同的模型組態 （相同量化、內容大小、執行緒計數）、負載測試每個系列部署一個節點，並進行比較。如果 CPU 執行個體符合您的 p95 SLO，它可能會降低成本。如果略微遺漏，請先嘗試該系列中最新一代的 ，再移至 GPU。如果並行目標的延遲仍然太高，則表示將工作負載移至 GPU 的訊號。

生產模式

模式 1：代理式 AI — 使用 LLM 升級的 CPU 上的 SLM 預先篩選

大多數客服人員工作流程會重複執行相同的窄模式：分類請求、挑選工具、擷取結構化資料、驗證回應。這些任務不需要 70B 參數模型。

對 SLMs的研究 (arXiv：2506.02153) 顯示，在 10B 參數以下的模型專門用於網域時，可以在受限子任務上比對或超過大型 LLMs，同時以顯著較低的成本和延遲有效率地在 CPU 上執行。針對特定網域微調模型時，相較於叫用一般用途 LLM，其佔用空間更小可讓模型更準確且更便宜。

在此模式中，CPU 上的 SLM 會end-to-end請求。路由層 （也在 CPU 上執行） 只會將真正複雜的案例升級到 GPU 託管的 LLM。

在 CPU 上執行的元件：

GPU/Trainium 上的元件：

此模式的運作原因：在許多代理工作流程中，60-80% 的請求可由 SLM 分類或擷取。對於您避免的每個 LLM 呼叫，您也可以避免組裝大型內容視窗、對長回應執行護欄和管理複雜狀態的周邊 CPU 工作。CPU 層會獨立於 GPU 層進行擴展。

典型代理管道中的 CPU 工作負載類別包括：工具執行 (MCP 伺服器呼叫、API 呼叫、資料庫查詢）、內容組件、向量搜尋和內嵌查詢、協調和規劃邏輯、護欄和安全篩選、回應驗證和格式化、代理記憶體和狀態管理，以及記錄/可觀測性。

此模式也適合微調生命週期：收集 CPU 節點上的網域資料、微調 GPU，然後將量化模型部署回 CPU 以進行推論，成本遠低於 LLM 端點。LoRA Land (arXiv：2405.00732) 的研究顯示，經過微調的 7B 模型在大多數測試的網域特定任務上都優於 GPT-4，使得「微調小型模型並在 CPU 上執行」路徑在許多生產使用案例中可行。

模式 2：高密度 CPU 模型陣列

生產 ML 管道會定期部署數百或數千個較小的模型：內嵌、推薦者、分類器、BERT 式評分器和電腦視覺模型。個別輕量型，這些模型會在每個模型指派自己的 GPU 資源時變得昂貴。

我們建議使用高密度 CPU 服務 （在 CPU 上使用 TorchServe 或 Triton 來封裝每個節點的多個模型），並對觀察到的負載進行 Karpenter 管理節點生命週期和 KEDA 擴展。

此模式自然延伸至 RAG 架構：從 OpenSearch 內嵌產生、文件區塊化和擷取都會以經濟實惠的方式在 CPU 節點上執行，僅在最終產生步驟將結果饋送至 GPU 託管的 LLM。CPU 陣列會處理磁碟區；GPU 會處理複雜性。

對於受管制的產業 （金融服務、醫療保健、政府），此模式特別吸引人：數百種在 CPU 上於 VPC 中執行的特殊模型，其中包含從不離開帳戶的完整稽核線索和資料。自我管理推論的合規要求自然符合 sub-8B以下模型 CPU 的成本優勢。

最佳化最佳實務

量化

在 CPU 上以完整的 BF16 執行 7B 模型並不切實際；在 Q4 量化時執行模型是可行且符合成本效益的。了解為什麼量化有助於 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 for arm64、AVX-512/AMX for x86)、設定執行緒計數等於 vCPU 計數，以及選取 Q4_K_M 或 Q8_0 量化格式。

對於 sub-2B模型，CPU 在價格效能與 GPU 方面獲勝。這些模型非常小，足以讓 GPU 加速提供最低效益，同時每小時成本也明顯較高。如果您的工作負載可以使用 sub-2B 模型，則建議使用 CPU。

架構特定的最佳化：在 arm64 上，目前世代的 Graviton 執行個體支援 SVE2。為您的目標建置具有適當-march旗標的推論引擎。在 x86 上，AMD EPYC 執行個體支援 AVX-512，Intel Xeon 執行個體新增 AMX 進行矩陣加速。由於推論是記憶體頻寬繫結，因此具有更多 DDR5 記憶體通道的較新 CPU 世代即使在相同的時鐘速度也能產生更快的推論。選擇執行個體類型時，請優先考慮核心計數的記憶體頻寬。

內容視窗大小：對於分類和路由工作負載，輸入通常低於 200 個字符，而輸出為 2-3 個字符。設定小型內容視窗 （例如 512 個權杖） 而非預設的 2048，可減少 KV 快取記憶體用量，並改善每個請求的延遲。只有在您的輸入確實很長時，才會增加內容視窗。

Flash 注意：如果您的推論引擎支援，請啟用 Flash 注意。Flash Attention 透過避免完全注意力矩陣的具體化，減少注意力運算的記憶體使用量。在 CPU 上，優點小於 GPU，但仍有助於更長的輸入。

密集服務的 Bin-packing

對於傳統 ML 和內嵌模型 （通常每個模型 <500 MB)，目標是在穩定的尾部延遲下每個節點的最大 Pod 密度。兩件事會決定您是否實現這一點：準確的資源請求和受控執行緒。

requests 以實際負載下觀察到的 p50-p90 用量為基礎。使用負載測試中的金絲雀、VPA 建議或 Prometheus 長條圖。兩個方向的預設值幾乎一律錯誤。

ML 程式庫 (PyTorch、ONNX 執行期、MLK、OpenBLAS) 會在節點上看到 vCPUs，而不是配置給 Pod 的 CPUs，產生任意數量的執行緒。在具有 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 和隨需容量，並以 Spot 做為偏好選項，並以隨需做為備用。

建置多封存映像 (arm64 和 amd64) 會進一步解除鎖定。使用這兩種架構時，Karpenter 可以根據即時價格和可用性，從完整的執行個體系列 (Graviton、AMD、Intel) 中進行選擇。這對於跨執行個體類型和架構多樣化降低中斷頻率的 Spot 工作負載特別有用。將 docker buildx或 CI 管道與多平台建置搭配使用，以產生涵蓋兩種架構的單一資訊清單。

容器啟動最佳化

當 Karpenter 佈建新節點 （向上擴展、Spot 取代） 時，容器執行時間需要先提取推論映像，Pod 才能啟動。對於多 GB 推論映像，這可能會為 Pod 啟動增加 30-60 秒。

我們建議您使用 Bottlerocket 做為推論工作負載的節點作業系統，並在平行提取/解壓縮模式中結合 SOCI 快照器。SOCI 會以平行區塊型下載取代預設的循序層擷取，大幅縮短大型映像的映像提取時間。您不需要變更容器映像。

如需詳細的組態指引，請參閱本指南的效能一節，其中涵蓋 SOCI 組態、EBS 快照預先提取和容器執行期快取策略。

可觀測性

如果模型層沒有可觀測性，您會以盲目方式擴展。我們建議為每個推論服務公開 Prometheus 指標，並使用它們來驅動 KEDA 擴展和操作儀表板。

大多數推論伺服器 (llama.cpp、vLLM、Triton、TorchServe) 會在/metrics端點公開 Prometheus 相容指標。指標名稱因伺服器而異，但概念相同。

要檢測的關鍵指標：

自動擴展：擴展佇列深度，而非 CPU 使用率

CPU 使用率是飽和指標。在延遲已降低之後，它會遽增。在以使用率為基礎的自動調整規模反應時，使用者已經在等待。

佇列深度 （請求延遲/等待） 是主要指標。它會在延遲降低之前上升，因為當所有處理插槽忙碌時，請求會開始佇列。在佇列深度上擴展表示在現有複本仍正常回應時佈建新的複本。

KEDA 支援使用 將多個指標合併為單一擴展公式 scalingModifiers（需要 KEDA 2.12+)。推論工作負載的建議模式是結合處理中的請求與排入佇列的請求，大幅加權佇列指標：

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

公式running + (waiting * 10)表示即使是 3 個排入佇列的請求也會將合併指標推送至 55，遠高於目標 25。擴展會在延遲降低之前開始。5 activationTarget的 可防止雜訊觸發不必要的scale-from-zero事件。

評估 CPU 優先工作負載的模型品質

在 CPU 上部署量化 SLM 是一項成本和延遲決策。只有在模型仍為您的工作負載產生正確、有用的輸出時才有意義。

較小的模型或量化會降低運算成本，但可能會降低品質。影響會有所不同。在 CPU 上運作良好的工作負載 （分類、擷取、路由、摘要、內嵌） 通常會在 3B-7B 範圍內保持良好的品質，並具有適當的量化和提示。

要評估的內容

不同的工作負載會以不同的方式降級：

實際的評估工作流程

我們建議您在生產前建立品質檢查，類似於在選擇執行個體類型之前執行負載測試的方式。工作流程有四個階段：

如何復原品質

如果模型效能不佳，請依序嘗試這些動作：

參考