SmolLM2 的三個尺寸：135M、360M 與 1.7B

有一類模型被大多數開發人員忽視。它們太小，無法出現在排行榜上。它們無法寫文章或解微分方程。它們沒有數十億的參數或數萬億的訓練 token。

但它們在手機上運行。它們在瀏覽器標籤頁上運行。它們在售價 $45 的 Raspberry Pi 上運行。它們在微控制器上運行。當您針對一個特定任務對其進行微調時，它們的執行表現足夠好，可以在生產應用中發布。

不到 3B 參數的模型——少於 30 億參數的模型——是在沒有服務器、沒有網絡連接且沒有按請求 API 成本的情況下工作的 AI 功能的實用基礎。它們是讓「無處不在的 AI」真正成為可能的東西，不是作為營銷口號，而是作為在真實硬件上部署的軟件。

本指南涵蓋 2026 年的不到 3B 模型格局、如何有效微調這些微型模型，以及如何在從 iPhone 到 Raspberry Pi 再到瀏覽器標籤頁的所有設備上部署它們。

不到 3B 模型格局

以下是小參數規模端的可用選項：

由 Hugging Face 開發的 SmolLM2 值得特別關注。1.7B 模型專門為邊緣部署設計——它使用具有共享嵌入、分組查詢注意力和緊湊的 49K 詞彙表的高效架構。結果是一個在專注任務上表現超出其重量級別的模型。

Phi-3.5 Mini 在技術上超過了 3B 截止值，但包含在內，因為它適合類似的部署目標，並且是此規模的最強推理模型。

不到 3B 模型能做什麼和不能做什麼

它們擅長什麼

單標籤分類。 給定一個輸入，將其分配到 N 個類別之一。在 200-500 個示例上微調後，不到 3B 模型在最多 15 個類別的分類任務上達到 88-95% 的準確性。這涵蓋了意圖檢測、情感分析、主題分類、垃圾郵件過濾和內容審核。

命名實體提取。 從文本中提取特定字段：姓名、日期、金額、電子郵件地址、產品 ID。1.5-3B 模型在微調後在提取任務上達到 85-92% 的字段級準確性。不到 1B 的模型是可用的（78-85%）但在複雜或模糊的輸入上表現下降。

短格式文本生成。 生成 1-3 句話作為對輸入的響應。自動補全建議、表單字段推薦、短摘要、樣板文本。將輸出保持在 50 個 token 以下以獲得可靠的質量。

意圖檢測。 從短輸入中理解用戶想要什麼。「我的餘額是多少？」映射到 check_balance。「我想取消」映射到 cancellation。不到 3B 模型非常擅長這個——這是它們最擅長的模式匹配。

二元決策。 是/否、有效/無效、垃圾郵件/非垃圾郵件、適當/不適當。即使是 135M 的 SmolLM2 在微調後也能處理 90% 以上準確率的二元分類。

它們不能做什麼

多步驟推理。 如果任務需要鏈接 3 個以上的邏輯步驟，準確性降至有用閾值以下。1.7B 模型可以處理「這封電子郵件是垃圾郵件嗎？」（一步）。它無法可靠地處理「讀取這份合同，識別所有義務，根據我們的合規政策檢查每一項，並標記違規」（四步）。

長格式生成。 生成超過 100-150 個 token 時，質量下降。模型開始重複自己、失去連貫性或偏離主題。如果您需要段落文本，請使用 7B 以上的模型。

複雜的結構化輸出。 簡單的 JSON 對象（3-5 個字段）可以正常工作。帶有數組、條件字段和複雜模式的嵌套 JSON？不到 3B 模型的錯誤率超過 15-20%。保持輸出模式扁平和簡單。

通用知識問答。 這些模型沒有足夠的參數來存儲廣泛的世界知識。它們可以回答關於您特定領域的問題（微調後），但不能回答關於任意主題的開放式問題。

多輪對話。 不到 3B 模型在多輪對話中很快失去上下文。它們適用於單輪請求/響應模式，而不是聊天機器人。

微型模型的微調策略

微調不到 3B 模型與微調 7B 以上模型不同。更小的參數計數意味著吸收新知識的容量更少，因此您需要對訓練什麼和如何訓練更加深思熟慮。

質量勝於數量

在 7B 以上的參數時，您可以接受嘈雜的訓練數據——模型有足夠的容量從噪聲中學習信號。在不到 3B 時，噪聲會破壞性能。

目標：200-500 個高質量示例。 每個示例應該：

• 明確——正確的輸出顯然是正確的答案
• 有代表性——涵蓋您在生產中將看到的輸入分佈
• 乾淨——輸出中沒有錯別字，格式一致，沒有矛盾

對於最小的模型（135M-500M），200 個示例通常是最佳點。超過 500 個並不有太大幫助，可能導致過擬合。對於 1.5B-3B 模型，300-500 個示例能產生最佳結果。

訓練配置

與 7B 以上訓練的關鍵差異：

• 更多訓練輪數。 小模型需要更多次通過數據才能學習模式。7B 模型可能在 3 輪後收斂，而 1.7B 模型需要 6-8 輪。
• 更小的 LoRA rank。 基礎模型的參數更少，因此適配器應該按比例更小。不到 1B 模型 8 就足夠了；1-3B 模型 16。
• 更短的最大序列長度。 不到 3B 模型為短輸入任務部署。設置最大序列長度以匹配您的實際數據分佈。256 個 token 足以用於分類和意圖檢測。512 用於提取。不要為了「以防萬一」而設置 2048——這浪費了訓練計算。
• 更高的學習率。 小模型可以容忍稍高的學習率，因為要破壞穩定性的參數更少。

訓練的 VRAM 要求

您可以在 RTX 3050（4 GB VRAM）或具有 8 GB 統一內存的 M1 MacBook 上微調最小的模型。訓練在幾分鐘而不是幾小時內完成。這使快速迭代變得實際——您可以微調、測試、調整數據並在一個下午重新訓練 10 次。

最小佔用空間的 GGUF 量化

對於邊緣部署，GGUF 文件大小是您的主要約束。以下是每個量化級別如何影響 SmolLM2 1.7B：

Q4_0 下的 SmolLM2 135M：85 MB 文件大小，150 MB RAM。小到可以捆綁在移動應用中而用戶不會注意到下載大小。它適合大多數現代網絡瀏覽器的緩存。

Q4_0 下的 Qwen 2.5 0.5B：350 MB 文件大小，500 MB RAM。對於移動設備仍然足夠小，但除非用戶期望下載，否則對於舒適的瀏覽器部署來說太大了。

各模型文件大小比較（Q4_K_M）

部署目標

iOS（Core ML 或 llama.cpp）

iPhone 12 及以後（4 GB RAM）的任何型號都可以以 Q4_K_M 運行 SmolLM2 1.7B。舊款 iPhone（3 GB RAM）可以運行 360M 或 135M 變體。

iPhone 15 Pro 上的性能：

對於實時 UI 功能（自動補全、輸入驗證、意圖檢測），不到 50ms 的延遲意味著 AI 響應在用戶完成打字之前就出現了。

Android（NNAPI 或 llama.cpp）

現代 Android 設備（6 GB 以上 RAM）可以舒適地處理所有不到 3B 模型。預算設備（4 GB RAM）應該使用不到 1B 的模型。

Pixel 8 Pro 上的性能：

瀏覽器（WebLLM / Transformers.js）

WebLLM 使用 WebGPU 在瀏覽器中進行硬件加速推理。當 WebGPU 不可用時，Transformers.js 使用 WebAssembly（WASM）作為回退。

M2 MacBook Air 上 Chrome 中的性能：

WebLLM 比 Transformers.js 快 2-3 倍，但需要 WebGPU 支持（Chrome 113+、Edge 113+）。對於瀏覽器部署，通過 WebLLM 使用 SmolLM2 135M 或 360M 是最實用的選項——快速加載、快速推理、最小內存。

Raspberry Pi（llama.cpp）

Raspberry Pi 5 以可用速度運行 SmolLM2 1.7B，適用於批量處理或延遲容忍應用。對於 Pi 上的實時分類，使用 135M 或 360M SmolLM2，或 0.5B Qwen——它們都提供不到 100ms 的響應。

真實使用案例

離線表單驗證（SmolLM2 360M）

一家公用事業公司在技術人員平板電腦上部署了 SmolLM2 360M 以進行離線電表讀數驗證。模型檢查輸入的讀數是否在預期範圍內，標記潛在的誤讀，並提出更正建議——所有這些都不需要連接網絡。在 250 個示例上微調。準確率：異常讀數的 93% 捕獲率。模型大小：220 MB。電池影響：可忽略不計。

設備上的意圖分類（Qwen 2.5 0.5B）

一款零售應用直接在手機上使用 Qwen 2.5 0.5B 將客戶消息分類為 8 種意圖（訂單狀態、退貨、產品問題等）。消息在發送到服務器之前被分類，使常見查詢能夠即時本地響應，複雜查詢能夠得到適當路由。在英語和西班牙語的 400 個示例上微調。準確率：91%。延遲：iPhone 15 上 24ms。

注重隱私的文本處理（SmolLM2 1.7B）

一款心理健康日記應用使用 SmolLM2 1.7B 在設備上按情緒分類日記條目、識別反復出現的主題並提出反思提示——所有這些都在設備上完成。沒有日記文本離開手機。在 300 個示例上微調。模型在 iOS 上以 Q4_K_M 運行，使用 1.4 GB RAM。用戶報告 AI 功能感覺「即時」，因為沒有加載轉圈或網絡延遲。

瀏覽器自動補全（SmolLM2 135M）

一家開發工具公司通過 WebLLM 在瀏覽器中運行 SmolLM2 135M，為其配置 DSL 提供自動補全建議。模型在 200 個從局部到完整配置片段的示例上進行了微調。以 85 MB 的大小，它在不到一秒內加載。建議在 15ms 內出現——比用戶能感知的速度更快。沒有服務器，沒有 API 密鑰，沒有使用費用。

IoT 異常檢測（Qwen 2.5 0.5B）

一個工廠監控系統在 Raspberry Pi 4 網關上運行 Qwen 2.5 0.5B。每個網關處理來自 8 台機器的傳感器數據，將每個讀數分類為正常/警告/危急。在 500 個傳感器數據示例上微調。模型每個網關每秒處理 10 個讀數。在每個網關 $45（Pi 硬件）和 400 MB RAM 使用的情況下，這比將所有傳感器數據發送到雲端進行處理便宜得多。

選擇您的模型

一般原則：從可能適用於您任務的最小模型開始。微調它，測試它，只有在準確性不足時才增大規模。許多開發人員驚訝地發現，一個 360M 模型，在適當微調後，以 90% 以上的準確率處理他們的任務。

---

延伸閱讀

• 2026 年邊緣 AI 和本地推理 — 邊緣 AI 部署格局的全面指南，從硬件到框架。
• AI 硬件小型化與微調 — 縮小的硬件如何在新形態的 AI 部署中啟用新可能。
• LoRA 適配器邊緣部署優化 — 最小化 LoRA 適配器大小和最大化設備上性能的技術。