SLM 優先架構：削減 AI 成本 75% 的 80/20 路由策略

大多數生產 AI 工作負載都很簡單。分類、提取、格式化、短文件摘要、基於模板的生成。這些任務消耗了您 80% 或更多的推理預算，它們不需要擁有超過 2000 億參數的前沿模型。

SLM 優先架構顛轉了默認假設。不是將所有請求路由到雲端 API 並在之後優化，而是從微調的小型語言模型（7B-14B 參數）作為默認路徑開始，僅在請求確實需要時才升級到雲端 API。

結果：在重要任務上沒有可測量的質量損失，成本降低 60-75%。

SLM 優先的真正含義

在傳統 AI 架構中，請求流如下所示：

用戶請求 → 雲端 API（GPT-4o / Claude）→ 響應

每個請求，無論複雜性如何，都進入最昂貴的選項。這是默認的，因為它是最簡單的構建方式。一個端點，一個模型，一個集成。

SLM 優先顛轉了默認：

用戶請求 → 路由器 → [80%] 微調 SLM（7B-14B，本地）→ 響應
                   → [20%] 雲端 API（GPT-4o / Claude）  → 響應

路由器檢查每個請求並做出決定：微調的小模型能夠充分處理這個嗎，還是它確實需要前沿級別的推理？對於大多數 SaaS 工作負載，答案是小模型可以很好地處理它。

成本計算

讓我們計算一下每月處理 500,000 個 AI 請求的 SaaS 產品。我們將使用 2026 年初的代表性定價。

場景 A：所有請求都發送到 GPT-4o

場景 B：使用微調 7B 模型的 80/20 路由

這是 70% 的成本降低。在每月 100 萬次請求時，節省接近 75%，因為本地基礎設施成本幾乎保持不變，而僅 API 的成本翻倍。

每月 AU$1,200 的本地基礎設施成本包括能夠以每秒數百個請求的速度為量化 7B 模型提供服務的 GPU 實例。在每月 400,000 個請求——平均每分鐘約 9 個請求——這遠在容量範圍內。

哪些請求去哪裡

路由決策並不複雜。它遵循清晰映射到請求類型的模式。

路由到本地 SLM（80% 的流量）：

• 文本分類和分類
• 命名實體提取
• 情感分析
• 基於模板的內容生成（電子郵件、摘要、描述）
• 數據格式化和轉換（JSON 結構化、CSV 解析）
• FAQ 和知識庫響應
• 短格式摘要（不到 500 字的源材料）
• 意圖檢測和路由

這些任務有共同特徵：定義明確的輸出、有限的推理深度、一致的模式。在您特定任務的 2,000-5,000 個示例上訓練的微調 7B 模型將在這些任務上匹配或超越 GPT-4o，因為它已學習了您確切的格式、術語和質量標準。

路由到雲端 API（20% 的流量）：

• 複雜輸入的多步驟推理
• 新穎性和風格重要的創意寫作
• 長文件分析（超過 10,000 個 token 的源材料）
• 需要廣泛、最新世界知識的任務
• 本地模型未被訓練過的邊緣案例
• 您尚未針對其進行微調的首次任務類型

實現路由器

路由器本身可以很簡單。您不需要單獨的 ML 模型來做出路由決策。按複雜性排序的三種實用方法：

1. 基於規則的路由（從這裡開始）

直接在代碼中將 API 端點或任務類型映射到層級：

if task_type in ["classify", "extract", "format", "summarize_short"]:
    route_to_local_slm()
elif task_type in ["reason", "create", "analyze_long"]:
    route_to_cloud_api()

當您的任務類型定義明確且穩定時，這效果很好。大多數 SaaS 產品有 5-15 種不同的 AI 任務類型，您可以手動對每種進行分類。

2. 基於置信度的路由

首先通過本地 SLM 運行請求。如果模型的輸出置信度（通過 token 概率或單獨的質量分類器測量）超過閾值，則使用它。如果不是，則回退到雲端 API。

隨著您改進微調模型，這會隨時間在本地捕獲更多請求，並自動將真正困難的請求路由到前沿模型。

3. 帶有影子評分的混合路由

基於規則路由，但定期向雲端 API 發送本地 SLM 響應的樣本進行質量比較。使用比較數據調整路由規則並識別本地模型需要更多訓練數據的任務。

大多數團隊應該從基於規則的路由開始。它是明確的、可調試的，並且以 20% 的實現工作量獲得 80% 的成本節省。

微調本地層

本地 SLM 的質量取決於其微調。基礎 Llama 3.3 或 Qwen 2.5 模型不會在您的特定任務上開箱即用地匹配 GPT-4o。但在您的生產數據上微調的版本會。

本地層的微調過程：

1. 收集生產示例。 從您現有的 GPT-4o 使用中導出 2,000-5,000 個請求-響應對。這些是您的訓練數據——雲端 API 已經生成了金標準輸出。

2. 微調 7B 或 14B 基礎模型。 使用 QLoRA，這在單個 GPU 上需要 30-90 分鐘。結果是一個已學習了您特定任務模式、輸出格式和質量標準的模型。

3. 對您的雲端 API 輸出進行評估。 在保留的測試集上運行微調模型並比較輸出。對於定義明確的任務，預計 92-98% 的質量對等。

4. 量化和部署。 轉換為 GGUF 格式（Q4_K_M 或 Q5_K_M 量化）以實現高效推理。通過 Ollama 或 llama.cpp 在 OpenAI 兼容 API 端點後面部署。

5. 監控和重新訓練。 在生產中跟蹤質量指標。當您收集到模型處理不好的新邊緣案例時，將它們添加到訓練數據並重新訓練。每次迭代都會提高覆蓋率。

Ertas 在單個工作流程中處理步驟 2-4——上傳您的數據集，選擇基礎模型，並獲得準備好部署的微調 GGUF 文件。微調在託管基礎設施上運行，因此您不需要自己的訓練 GPU。

完整棧的架構

以下是完整 SLM 優先架構在生產中的樣子：

┌─────────────────────────────────────────────┐
│                您的 SaaS 應用                │
│                                             │
│  ┌─────────┐    ┌──────────────────────┐    │
│  │ 請求隊列  │───▶│      路由層           │    │
│  │          │    │ (規則 / 置信度)       │    │
│  └─────────┘    └──────────┬───────────┘    │
│                    ┌───────┴───────┐         │
│                    ▼               ▼         │
│           ┌──────────────┐  ┌───────────┐   │
│           │  本地 SLM    │  │ 雲端 API  │   │
│           │ (Ollama /    │  │ (GPT-4o / │   │
│           │  llama.cpp)  │  │  Claude)  │   │
│           │  微調        │  │           │   │
│           │  7B-14B      │  │           │   │
│           └──────────────┘  └───────────┘   │
│                    │               │         │
│                    ▼               ▼         │
│              ┌──────────────────────┐       │
│              │     響應處理器        │       │
│              │   (標準化格式)        │       │
│              └──────────────────────┘       │
└─────────────────────────────────────────────┘

關鍵實現細節：

• 兩個層級都公開 OpenAI 兼容端點。 您的應用程序代碼對兩者使用相同的客戶端庫——唯一的區別是基礎 URL 和模型名稱。
• 響應處理器標準化輸出。 不同的模型可能返回略有不同的格式。一個薄薄的標準化層確保無論哪個層級處理了請求，輸出都是一致的。
• 日誌記錄捕獲每個請求的層級、延遲和成本。 這些數據為您的路由優化和識別模型改進候選提供支持。

當 80/20 變成 90/10

隨著您在更多生產數據上微調本地模型，它處理好的請求百分比會增加。從 80/20 路由開始的團隊通常在 3-6 個月內達到 90/10，因為：

• 邊緣案例被捕獲到訓練數據中並微調到模型中
• 新任務類型一旦定義明確就被添加到本地層
• 隨著模型的改善，基於置信度路由的質量閾值可以收緊

在 90/10 路由下，相同的每月 500,000 次請求場景降至：

與完全 API 使用相比，這是 80% 的成本降低，質量配置已經過數月生產數據的驗證。

常見異議

「如果本地模型給出了糟糕的響應怎麼辦？」

實現質量檢查。對於結構化輸出，根據模式驗證。對於自由文本，使用輕量分類器標記低置信度輸出以進行雲端 API 重試。這在被標記的約 2% 的請求上增加了幾百毫秒的延遲，但消除了質量風險。

「我們沒有 GPU 基礎設施。」

量化的 7B 模型在沒有 GPU 的 AU$80/月 VPS 上運行。現代硬件上的 CPU 推理為 Q4 量化 7B 模型處理每秒 2-5 個請求。對於每月不到 200,000 個請求的大多數 SaaS 工作負載，這已足夠。只有更高的吞吐量才需要 GPU 實例。

「我們的任務對小模型來說太複雜了。」

其中一些確實如此。大多數不是。進行評估。取您最近的 1,000 個 API 請求，按複雜性分類，並在簡單的請求上測試微調的小模型。數據會告訴您您的流量中實際複雜的百分比是多少。

「管理兩個推理路徑太多操作開銷了。」

兩個路徑都使用 OpenAI 兼容 API。您的應用程序代碼不知道也不關心哪個處理了請求。路由層是 50-100 行代碼。操作開銷是一個需要監控的額外服務，這與添加緩存層相當。

開始

遷移路徑是增量的。您不需要在第一天就實現完整的架構。

1. 第 1 週： 審計您當前的 AI API 使用情況。按類型分類請求。識別 2-3 個最高流量、最簡單的任務類型。
2. 第 2 週： 使用您現有的 API 輸出作為訓練數據，在這些特定任務上微調 7B 模型。
3. 第 3 週： 在本地部署模型並將這些特定任務類型路由到它。保持其他所有任務在雲端 API 上。
4. 第 4 週： 監控質量和成本。根據結果調整路由規則。

每月重複，隨著您驗證質量，將更多任務類型移到本地層。在 3 個月內，您將有 80/20 分割在生產中運行，並有清晰的路徑達到 90/10。

---

延伸閱讀

• 微調小型模型 vs GPT-4 — 微調 7B 模型與前沿 API 在特定任務上的正面比較
• 2026 年 AI 推理成本比較 — 雲端 API、GPU 實例和本地硬件的當前定價
• 2026 年企業最佳小型語言模型 — 為本地層選擇哪些基礎模型