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

# CPU 推論和協調
<a name="aiml-cpu-inference"></a>

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

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

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

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

 **本指南適用於：**
+  為 AI 工作負載設計多租用戶 EKS 叢集的**平台工程師**。
+  **ML 從業人員**評估 30B 參數下模型的推論後端。
+  **FinOps 團隊**在不犧牲 SLOs 的情況下尋找具體的成本控制桿。

 **您將學到什麼：**
+ 哪些 AI 工作負載屬於 CPUs以及哪些 GPUs 或 Trainium 是必要的。
+ 如何將四維決策架構套用至任何新的工作負載。
+ 兩種生產模式：代理式 SLM 預先篩選和高密度模型陣列。
+ 最佳化最佳實務：量化、bin-packing、Spot 排程和自動擴展。

**警告**  
本指南中的每個建議都應以經驗驗證。正確的執行個體系列 (arm64、x86、GPU 或 Trainium) 取決於您的模型、資料和延遲預算。使用本指南作為明智的起點，然後在遞交之前進行基準測試。

## 為什麼選擇適用於 AI 工作負載的 CPUs？
<a name="_why_cpus_for_ai_workloads"></a>

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

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

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

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

### 經濟效益
<a name="_economics"></a>

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

### 操作簡單性
<a name="_operational_simplicity"></a>

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

### 在代理管道中增長 CPU 表面
<a name="_growing_cpu_surface_in_agentic_pipelines"></a>

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

## CPU 與 GPU/ Trainium：何時選擇每個
<a name="_cpu_vs_gpu_trainium_when_to_choose_each"></a>


| Factor | 選擇 CPU | 選擇 GPU/Trainium | 
| --- | --- | --- | 
| 模型大小 | SLMs1-8B （量化）；內嵌；分類器 | 8B\+ 用於低延遲線上推論；一般為 70B\+ | 
| 延遲 SLO | 可接受 p95 100-500ms | 需要 p95 < 50 毫秒 | 
| 並行 | 每個端點 < 100 要求/秒 | > 100 請求/秒持續 | 
| 工作負載類型 | 協調、擷取、ETL、批次評分 | 線上推論、微調、訓練 | 
| Capacity | 立即可用性，無保留 | 通常需要預留容量 | 
| 成本敏感度 | CPU 為符合資格的工作負載提供最佳的 $/Token | GPU 以高使用率攤銷 | 
| 團隊專業知識 | 標準 Kubernetes 操作 | 需要 GPU 操作知識 | 
| 資料主權 | VPC 中的 SLM 推論；完整稽核追蹤；資料永遠不會離開您的帳戶 | 如果自我管理則相同；不適用於外部 APIs | 

**提示**  
這些閾值是起點。建議您在候選執行個體系列 (arm64 和 x86) 上執行目標推論引擎，並搭配實際模型和流量模式，再遞交至運算層。

## 工作負載決策架構
<a name="_workload_decision_framework"></a>

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

1.  **模型大小和精確度**：量化是否將品質保持在可接受的範圍內？

1.  **延遲和輸送量 SLOs**：您的 p50/p95 目標和尖峰請求率是多少？

1.  **工作負載類型**：線上推論、批次評分、擷取或協同運作？

1.  **成本和容量限制**：FinOps 預算、區域可用性、保留策略？

使用下表做為決策矩陣。


| 工作負載 | CPU | GPU / Trainium | 備註 | 
| --- | --- | --- | --- | 
| SLMs(1-8B 參數，量化） | 預設選擇。100-500ms 延遲、中等 QPS 時的強大價格優惠。跨執行個體系列的基準。 | 當 p95 <50ms 或並行 >100 要求/秒時。 | 建議 Q4\_K\_M 或 Q8\_0 量化 | 
| 中型模型 (8-30B 參數） | 批次、非同步、離線評分。測試Q4 量化。 | 線上推論、長內容、緊密延遲。 | 跨執行個體系列的基準 Q4  | 
| 大型 LLMs (70B\+ 參數） | 非Non-real-time、繁重的量化 | 生產線上推論的預設值 | 即使 70B 也可以在 CPU 上執行；預期高延遲 | 
| 傳統 ML/嵌入/CV | 高密度服務；跨節點的 bin-pack。 | 大規模的重視或多模態。 | TorchServe，CPU 上的 Triton 處理數千個模型。 | 
| 資料管道/ETL/合成資料 | CPU 上的 Ray 和 Spark 用於資料準備和功能工程。 | N/A | CPUs錨定整個資料準備階段 | 
| 代理程式協同運作/RAG 擷取 | 網路繫結服務：API 閘道、代理層、擷取器、區塊。 | N/A | 高頻寬 CPU 執行個體的優點。 | 
| 微調/訓練 | 資料準備和管道協調。 | 模型訓練和分割。 | 混合：CPU 準備、GPU 訓練、CPU 推論。 | 
| 合規敏感推論 (FSI、醫療保健、政府） | CPU 上 VPC SLMs。資料會保留帳戶內的完整稽核線索。 | 如果在 GPU 上自我管理，則相同。 | CPU 在受管制環境中獲得 sub-8B模型的成本。 | 

**警告**  
雖然在技術上可以在具有大量量化 (Q4 或更低） 的 CPU 上執行 70B\+ 模型，但這僅適用於non-real-time、離線或批次工作負載。低單位數 (1-5 個字符/秒） 的字符產生率、即使在第 4 Q4也超過 40GB 的記憶體需求，以及長輸出的每個回應的延遲，以分鐘為單位。對於任何互動式或延遲敏感的使用案例，70B\+ 模型屬於 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：代理式 AI — 使用 LLM 升級的 CPU 上的 SLM 預先篩選
<a name="_pattern_1_agentic_ai_slm_pre_filter_on_cpu_with_llm_escalation"></a>

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

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

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

 **在 CPU 上執行的元件：**
+ API 閘道/代理層 — 處理身分驗證、路由、速率限制
+ 客服人員協調人員 — 管理工具呼叫和狀態
+ SLM 推論服務 — 在 CPU 上使用 [llama.cpp](https://github.com/ggerganov/llama.cpp)、[Ollama](https://ollama.com) 或 [vLLM](https://docs.vllm.ai) 等推論引擎來量化 1-8B 模型
+ 向量擷取 — CPU 節點上的 OpenSearch 

 **GPU/Trainium 上的元件：**
+ 用於複雜合成、長內容推理的大型 LLM

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

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

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

### 模式 2：高密度 CPU 模型陣列
<a name="_pattern_2_high_density_cpu_model_farm"></a>

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

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

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

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

## 最佳化最佳實務
<a name="_optimization_best_practices"></a>

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

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


| 量化 | 品質影響 | 輸送量與 BF16 | 使用案例 | 
| --- | --- | --- | --- | 
| Q4\_K\_M | 低 (1-3% 的多工差異，取決於模型） | \~4-5 倍的速度 | SLMs生產預設值 | 
| Q8\_0 | 可忽略 | \~2 倍快 | 對品質敏感的任務 | 
| Q5\_K\_M | 非常低 | \~3.5 倍速度 | 品質和速度的平衡 | 
| BF16 | 無 | 1x （基準） | 避免在 CPU 上使用 7B\+ 模型 | 

對於 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，但仍有助於更長的輸入。

**提示**  
Q4\_K\_M 品質降級因模型和任務而異。在部署到生產環境之前，請務必先評估自己的資料集。

### 密集服務的 Bin-packing
<a name="_bin_packing_for_dense_serving"></a>

對於傳統 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 個執行緒。

### 排程和成本最佳化
<a name="_scheduling_and_cost_optimization"></a>

兩種實務可大幅降低 CPU 推論成本：具有 Karpenter 整合的 Spot 執行個體，以及多封存容器映像。

Karpenter 的整合非常適合 CPU 推論，因為佇列或負載平衡器後方的無狀態推論 Pod 會容錯中斷。設定整合以對預算限制並行中斷的未充分利用節點 （例如，一次 20% 的節點） 採取行動，以避免在縮減規模期間容量下降。Karpenter 的`nodePool`規格可讓您在單一集區中混合 Spot 和隨需容量，並以 Spot 做為偏好選項，並以隨需做為備用。

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

### 容器啟動最佳化
<a name="_container_startup_optimization"></a>

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

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

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

### 可觀測性
<a name="_observability"></a>

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

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

 **要檢測的關鍵指標：**


| 指標類別 | Description | 警示閾值 | 
| --- | --- | --- | 
| 請求處理/處理中 | 伺服器目前正在處理的請求數量。 | 使用 進行擴展 （請參閱下面的自動擴展一節） | 
| 已排入佇列/延遲的請求 | 等待處理槽的請求數量。 | 擴展觸發。任何持續佇列表示延遲即將降低。 | 
| 字符輸送量 | 每秒產生的字符數。 | 如果輸送量低於負載下基準的 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 使用率是飽和指標。在延遲已降低*之後*，它會遽增。在以使用率為基礎的自動調整規模反應時，使用者已經在等待。

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

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 優先工作負載的模型品質
<a name="_evaluating_model_quality_for_cpu_first_workloads"></a>

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

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

### 要評估的內容
<a name="_what_to_evaluate"></a>

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


| 工作負載 | 哪些項目可能會降級 | 要測量的內容 | 
| --- | --- | --- | 
| 意圖或票證分類 | 輸入不明確時發生錯誤 | 準確度，每個類別的 F1  | 
| 結構化擷取 (JSON) | 缺少欄位或結構描述錯誤 | 完全相符，結構描述有效性 | 
| RAG 答案 | 幻覺或忽略內容 | 誠實、回答相關性 | 
| 摘要 | 缺少事實或涵蓋範圍不佳 | ROUGE-L、BERTScore、人工審核 | 
| 客服人員轉接 | 選取錯誤的工具 | 工具準確度 | 
| 嵌入項目 | 較差的擷取品質 | Recall@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 個已標記的範例，通常會縮小分類和擷取任務的差距。
+  **使用更高品質的量化格式**：從 Q4 移至 Q8 通常會以大約 2 倍的記憶體和更低的輸送量來還原大部分遺失的品質。
+  **使用混合路由**：讓 SLM 處理簡單的案例，並將困難的輸入傳送至較大的模型。這是架構變更，但大多數流量的 CPU 成本都很低。
+  **微調網域上的模型**：最昂貴的選項，但最有效。來自 LoRA Land ([arXiv：2405.00732](https://arxiv.org/abs/2405.00732)) 的研究發現，經過微調的 7B 模型在大多數測試的網域特定任務上都優於 GPT-4。

## 參考
<a name="_references"></a>
+  [Amazon 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) 
+  [Ray 服務文件](https://docs.ray.io/en/latest/serve/) 
+  [Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/) 
+  [AWS Spot 最佳實務](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) 
+  [LoRA Land：效能優於 GPT-4 的微調開放原始碼 LLMs ](https://arxiv.org/abs/2405.00732) 
+  [模型內容通訊協定 (MCP) 規格](https://modelcontextprotocol.io) 
+  [客服人員 AI (NVIDIA) 的小型語言模型](https://arxiv.org/abs/2506.02153) 
+  [SOCI 快照](https://github.com/awslabs/soci-snapshotter) 
+  [Bottlerocket 作業系統](https://bottlerocket.dev) 
+  [AI on EKS：容器啟動最佳化](https://awslabs.github.io/ai-on-eks/docs/guidance/container-startup-time/accelerate-pull-process)