SLM 小型語言模型是什麼？跟 LLM 的差異與選擇判斷一次看

SLM（Small Language Model，小型語言模型）是參數規模明顯小於大型語言模型、仍能理解與生成自然語言的模型。它能在手機、筆電、邊緣裝置或公司自有的伺服器執行，適合摘要、分類、資料抽取等範圍清楚的任務；需要大量知識或複雜推理時，LLM 通常仍有優勢。

小模型換來較低的硬體需求、較短的延遲、離線能力與更容易控制的資料流向，代價是知識容量與通用能力。判斷該用 SLM 還是 LLM，不能只看參數量，也要看任務、量化版本、可用記憶體與資料能不能離開裝置。想先補生成式 AI 的整體輪廓，可以看生成式 AI 從原理到應用場景的完整指南；這裡只處理小模型的技術與選型。

現行產品狀態、版本名稱、支援條件與介面路徑均查證於 2026 年 8 月 20 日；歷史效能數字保留當時的裝置、版本與量測條件。

這個區分跟一般使用者也有關。手機顯示「摘要」或「改寫」時，工作可能在本機完成，也可能轉交私有雲或一般雲端；畫面名稱相同，不代表資料路徑相同。對開發者而言，模型能不能下載、授權是否允許商用、量化版能讀多長文字，往往比排行榜名次更早決定一個方案能否上線。

重點先看

• SLM 是參數規模明顯小於大型語言模型、仍能理解與生成自然語言的模型，產業沒有統一的參數門檻。
• SLM 跟 LLM 的差異主要在成本、延遲、隱私、離線與能力上限。小模型佔了前四項優勢，大模型通常有較高的能力上限。
• 知識蒸餾、剪枝與量化能縮小模型；縮小後的品質、context 長度和實際記憶體需求仍要逐版本測試。
• Apple、Microsoft 與 Google 都保留端側和雲端路徑，Meta 也提供 1B、3B 邊緣模型；SLM 並非 LLM 的全面替代品。
• 花 5 分鐘查裝置的 NPU 與系統支援，再花 10 分鐘對照模型卡的記憶體需求，比只看模型名稱可靠。

SLM 是什麼：參數小一號的語言模型，界線靠慣例

SLM 是參數規模明顯小於大型語言模型、仍能理解與生成自然語言的模型。參數是訓練期間調整的數值，會影響模型容量與推論所需資源；參數量很重要，卻不能單獨代表正確率、速度或實際檔案大小。

「幾 B 以下才算 SLM」沒有統一答案。2024 年更新的 IBM SLM 專題頁把範圍描述為數百萬到數十億參數，相對於數千億甚至上兆參數的 LLM；2025 年 1 月發布的一項約 160 篇論文調查則採 1B 到 8B。兩個口徑都能使用，但都不是產業標準。

實際命名比論文範圍更寬。Google 於 2025 年 8 月發布的 Gemma 3 270M 有 2.7 億參數，Microsoft 於 2024 年 12 月發布的 Phi-4 有 14B 參數，兩家公司都把產品放在小模型脈絡下。Apple 的 2024 年端側模型約 3B，Meta Llama 3.2 的輕量文字版則有 1B 與 3B。模型名稱裡的 small、mini 或 nano 是廠商定位，不是共同規格。

小模型、端側模型和 on-device 模型不能完全劃等號。SLM 描述的是模型相對規模，端側與邊緣運算描述的是執行位置；SLM 可以部署在雲端，較大的模型也可能透過量化、記憶體卸載或其他技術在裝置上執行。讀規格時，至少要確認參數量、量化格式、context window、硬體需求與部署位置。

B 代表 billion，也就是十億。3B 是約 30 億參數，270M 則是 2.7 億。量化會改變每個權重占用的位元數，不會把 3B 模型變成 1B；稀疏架構只啟動部分參數，也不會改掉模型的總參數。這三件事常在產品介紹中被壓成一句「模型更小」，實際代表的工程作法不同。

參數量也不是模型檔大小的直接答案。同樣 3B，FP16 權重的理論空間約是 INT4 的四倍；執行時還需要 KV cache、輸入內容與框架本身的記憶體。拿到一個模型名稱後，先找檢查點格式和執行期量測，才能判斷自己的機器是否跑得動。

SLM 仍然是語言模型，不是所有在手機執行的 AI 都算 SLM。相機的人臉偵測、降噪模型與傳統分類器也能在端側執行，但它們未必理解或生成自然語言。反過來說，文字模型即使放在資料中心，只要相對規模與產品定位符合，仍可能被稱為 SLM。部署位置與模型類型要分兩層閱讀。

SLM 跟 LLM 差在哪：五個維度的實際差異

大型語言模型的訓練方式與風險，可交給站上的 LLM 說明；選型時，把兩種模型放在同一組條件下比較更有用。

成本差在算力與計費方式。 SLM 需要的記憶體和運算資源通常較少，可以放在手機、筆電或自有環境。端側推論不會產生逐次雲端 API 費用，但裝置升級、模型整合、測試與維運仍是成本。IBM 把降低成本列為 SLM 的效益之一，沒有可信且可套用所有情境的「便宜幾倍」數字。

延遲差在運算量與網路往返。 Apple 於 2024 年 6 月公布首代約 3B 端側模型的實機結果：在 iPhone 15 Pro、尚未使用投機解碼時，每個 prompt token 的 time-to-first-token 約 0.6 毫秒，生成速率每秒 30 tokens。1,000 token 的提示依該口徑約需 600 毫秒才開始回應，不能把這組結果套到別的手機或模型。Apple 的技術說明保留了完整條件；token 的切分與計算方式可看 AI Token 解析。

隱私取決於資料實際送到哪裡。 模型若完全在裝置或公司內部執行，提示與檔案不必交給外部服務。Apple 的做法是端側能處理就留在端側，需要較大模型時改用 Private Cloud Compute；後者仍會離開使用者裝置，只是送到 Apple 設計的私有雲環境。端側、私有雲與一般雲端 API 是三種不同資料邊界。

本機推論也不會自動解決所有隱私問題。App 仍可能保存提示、輸出、錯誤紀錄或分析事件，下載 adapter 與模型更新也可能需要連線。採購或開發時要看的不是「on-device」標籤，而是完整資料流程：輸入在哪裡處理、紀錄留多久、誰能存取、什麼情況會切換雲端。

離線是端側部署的直接優勢。 Google 的 Gemini Nano 文件說明，模型經 Android 的 AICore 在裝置上推論，不需要把提示送到雲端，也能在沒有網路時工作。離線是否可用仍受相容裝置、模型下載狀態與功能限制影響，不能只因產品用了 SLM 就推定所有功能都離線。

能力上限是小模型的主要代價。 Microsoft 的 Phi-4-mini 模型卡明寫，3.8B 模型沒有容量儲存太多事實知識，可能產生事實錯誤，建議用搜尋或 RAG 補足。參數少不必然表示推理差，卻會限制能裝進權重的知識量。

延遲還要拆成兩段。time-to-first-token 是送出提示到第一個 token 出現的等待，生成速率是開始輸出後每秒產生多少 tokens。長提示會拉高前者，長答案更受後者影響；只報「每秒幾個 token」不能完整描述使用感受。雲端模型也可能因批次處理、快取或較快的伺服器硬體取得高生成速率，所以「模型小」不等於任何情況都比較快。

這張表要一起看。前四列說明小模型為何適合本機與高頻任務，第五列提醒它不能因速度快就被當成旗艦模型。所謂「追平大模型」，通常只在特定基準或任務成立。

比較成本時也要固定工作量。高頻短文字分類、日常郵件摘要與偶爾分析長文件，三種用量的硬體攤提和雲端費用完全不同。沒有輸入長度、輸出長度、併發量與硬體價格，任何「SLM 便宜幾倍」都只是缺條件的宣傳數字。

小模型是怎麼做出來的：知識蒸餾、剪枝與資料

小模型不一定由大模型壓縮而來，常見做法包含直接訓練較小架構、知識蒸餾、剪枝與量化；同一個模型可以同時用上數種方法。

知識蒸餾（knowledge distillation）讓大型 teacher 模型提供軟化輸出分布，小型 student 模型不只學標準答案，也學候選答案之間的相對機率。Hinton、Vinyals 與 Dean 在 2015 年的論文系統化描述這種做法。2019 年的 DistilBERT 是公開範例：論文測得模型比 BERT 小 40%、快 60%，並在其語言理解評測口徑保留 97% 能力。這三個百分比屬於 DistilBERT 與 BERT 的特定比較，不能外推到所有蒸餾模型。

軟化分布有用，是因為它保留了「錯答案有多接近」的訊息。若標準答案只有一個類別，小模型只知道哪個是對的；teacher 提供完整機率後，小模型也能看見其他類別的相似程度。這能提高小模型每筆訓練資料得到的訊息量，但 student 的容量、資料品質與訓練配方仍會限制成果。

剪枝（pruning）會移除貢獻較低的權重、神經元或層，之後通常要微調以補回精度。IBM 整理的四種壓縮方法是剪枝、量化、低秩分解與知識蒸餾；低秩分解把大型權重矩陣近似成較小矩陣，減少參數與計算量。剪得越多不代表越好，過度剪枝會直接傷害表現。

Meta 的 Llama 3.2 1B 與 3B 把兩種做法接在一起。Meta 於 2024 年 9 月說明，模型先由 Llama 3.1 8B 做結構化剪枝，預訓練又把 8B 與 70B 的 logits 當成 token 級目標，剪枝後再用蒸餾補回效能。官方模型卡記載預訓練資料最多 9 兆 tokens。

Apple 的 2024 年端側模型也用了剪枝與蒸餾。官方論文寫的是：模型由一顆 6.4B 剪枝模型初始化，再用蒸餾損失完成 6.3 兆 tokens 的核心預訓練。論文沒有明說 teacher 是哪一顆，因此不能把 6.4B 初始化模型直接稱為 teacher。

直接訓練小架構則把重點放在資料。Microsoft 的 Phi-3 技術報告記載，phi-3-mini 使用 3.3 兆 tokens，內容由高度篩選的公開網路資料與合成資料組成。這能說明資料配方為何重要，卻不能推出「資料好就一定勝過大模型」；論文的比較仍綁定 MMLU、MT-Bench 等測項。

Google Gemma 3n 則把伸縮能力放進架構。2025 年文件顯示，E2B 標準執行會載入超過 5B 參數；透過 Per-Layer Embedding 快取與 MatFormer 的參數跳過，等效記憶體負載可降到 1.91B。它還有 MobileNet-V5 視覺編碼器與 32K context。這裡的 E2B 是有效參數口徑，不是總參數。

模型量化是什麼：用位元換記憶體的技術與代價

量化（quantization）是用較少位元表示權重或中間數值。粗略估算模型權重記憶體，可以用「參數量 × 每參數位元數 ÷ 8」；FP16 每個參數 16 位元，INT4 是 4 位元。只看權重的理論比值，INT4 只需 FP16 的四分之一空間；實際檢查點還有嵌入、快取與執行框架開銷，不能保證整體剛好縮成四分之一。

這個公式只估權重。提示越長，KV cache 通常越大；批次同時處理多個請求，記憶體也會跟著增加。作業系統、顯示驅動程式和推論框架還會占空間，因此模型卡寫「權重需要 14.1GB」時，不應把 14.1GB 當成顯示卡最低容量。

QAT（quantization-aware training，量化感知訓練）在訓練時模擬低精度運算，通常比訓練完成後才壓縮的 PTQ（post-training quantization，訓練後量化）更能保住精度，但訓練成本較高。原廠有提供 QAT 檢查點時，可以先測該版本；沒有合適版本才自己做 PTQ，並用真實任務檢查錯誤率。

Apple 於 2024 年採 2-bit 與 4-bit 混合配置，量產設定平均 3.7 bits per weight；官方稱壓到 3.5 bits per weight 仍沒有顯著品質損失。不同任務使用 rank-16 adapter，單一 adapter 為數十 MB。2025 年模型改用 2-bit QAT，並共享部分 KV cache，使該快取的記憶體用量降低 37.5%。這些都是 Apple 自家模型與評測條件，不能當成量化的通則。

Google 於 2025 年 4 月發布 Gemma 3 QAT。官方量測顯示，27B 的 BF16 權重需 54GB VRAM，INT4 版為 14.1GB；Google 的 QAT 說明也記載 QAT 在 llama.cpp perplexity 評測中，把轉成 Q4_0 時的品質退化減少 54%。這是權重載入需求，不含所有執行期記憶體。

perplexity 是模型對文字序列不確定程度的一種量測，不等於摘要是否忠實、分類是否正確或繁中語氣是否自然。QAT 在 perplexity 上保住品質，只能當候選版本的依據。真正要上線前，仍要用目標語言、實際提示長度與任務評分規則重新測試。

量化的代價不只精度。Meta Llama 3.2 1B 與 3B 的 BF16 版 context 是 128K，官方量化版降為 8K。SpinQuant 1B 在 OnePlus 12、Arm CPU 與 ExecuTorch 條件下佔 1,083MB，解碼每秒 50.2 tokens，速度是 BF16 版的 2.6 倍。省空間、變快與可讀長度縮短，可能同時發生。

位元數也不是越低越划算。模型某些層對精度較敏感，Apple 才會採混合位元配置；不同硬體對 INT4、2-bit 或特定量化格式的加速支援也不同。同一個檢查點在 CPU、GPU 與 NPU 上的速度可能差很多，格式相容性應在下載大型檔案前先確認。

2024 到 2026 年：四家大廠把 SLM 推進裝置的時間線

2024 到 2026 年的小模型增加，不能歸因於單一突破。手機和 PC 的 NPU 變強，蒸餾、剪枝與 QAT 有了可下載成品，高品質合成資料改善小模型訓練，隱私與雲端推論成本也推動端側需求。時間線裡的「發表」「開放開發者使用」和「正式上機」是不同狀態。

這張表最容易誤讀的是評測與上市狀態。Phi-3 的「可比大型模型」是微軟在特定基準上的判斷；Apple 2024 年 6 月是發表，第一批功能到 10 月 28 日才正式上線。2026 年第三代模型雖已公開規格，Apple 的頁面仍說測試期間會繼續改善，不能當成所有相容裝置都已收到更新。

2024 年 10 月那批 Apple Intelligence 有明確邊界：iPhone 端限 iPhone 15 Pro、15 Pro Max 與 iPhone 16 系列，iPad 需 A17 Pro 或 M1 以上，Mac 需 M1 以上，語言先從美式英文開始。這是當時的首發名單，不是 2026 年的完整相容清單。引用歷史上市資訊時，應保留「當時」與系統版本，避免把舊限制誤寫成現況。

Google 的規格也要分尺寸。Gemma 3 的 4B、12B、27B 支援圖片輸入與 128K context；1B 是文字模型與 32K context。Google 在 2025 年發布時引用 LMArena 初步人類偏好評測，27B 當時 Elo 為 1338。Elo 量的是回答偏好，且排行榜會變動，不代表事實正確率。

Apple 2026 年公布的 AFM 3 Core Advanced 有 20B 總參數，會依請求啟動 1B 到 4B。完整權重放在快閃儲存體，請求需要的專家權重才載入 DRAM。AFM 3 Core 仍是 3B 密集模型。Apple 內部並排人類評測中，新 Core 在 45.6% 提示上勝出，2025 基線為 23.3%；這是自家世代比較，不是跨廠能力排名。

Microsoft 的 Phi-4-mini 也示範了同一件事。2025 年模型卡的內部綜合分數是 63.5，對照 Llama 3.2 3B 的 56.2；表內同時包含 BoolQ、GPQA、MATH、多語 MMLU 等不同測項。把多項測驗彙整成總分，只適合閱讀該模型卡的比較，不能拿去和另一份排行榜的總分直接相減。

把模型塞進手機與電腦的六個代價

第一個代價是記憶體。手機與輕薄筆電的 RAM 要同時留給作業系統與 App，模型不能把空間占滿。量化減少每個權重的位元數，Gemma 3n 把部分嵌入移到快速儲存，Apple 的稀疏模型只把當次需要的專家載入 DRAM，三種方法解的是同一個物理限制。

第二個是電池。Google 的 0.75% 電量結果只適用於 2025 年 Gemma 3 270M INT4、Pixel 9 Pro 與 25 段對話的內部測試。它能證明極小模型可在手機低耗電執行，不能拿來估算 3B、20B 或其他裝置的耗電。

第三個是延遲條件。Apple 每秒 30 tokens 的數字綁定 2024 年首代模型、iPhone 15 Pro 與未啟用投機解碼；Meta 每秒 50.2 tokens 則綁定 OnePlus 12、SpinQuant 1B、Arm CPU 與 ExecuTorch。只比較每秒 token 數，卻漏掉硬體和解碼方式，結論會失真。

第四個是能力上限。模型容量越小，儲存大量冷門事實越困難，開放式問答要準備搜尋或 RAG。第五個是 context，量化版可能主動縮短可讀長度。第六個是硬體門檻：截至 2026 年 8 月 20 日，Microsoft 對 Copilot+ PC 的定義仍是 NPU 具備 40+ TOPS，可在 Microsoft Learn 裝置文件核對。

裝置還有資源競爭。模型推論會和相機、遊戲、瀏覽器分頁及背景程序共用記憶體與電力；短時間跑得動，不代表長時間持續生成仍能維持同樣速度。手機可能因溫度或電量管理降低效能，筆電也會因插電狀態改變功耗上限。原廠單次測試是起點，長時間工作負載要另做量測。

TOPS 只描述處理器每秒可完成的運算量級，不保證某個模型檔一定相容。驅動程式、資料型別、執行框架與可用記憶體都會影響結果。40+ TOPS 能判斷電腦是否符合 Copilot+ PC 的硬體分類，不能拿來直接換算每秒生成多少 tokens。

這張表是粗略硬體階梯，不是保證可執行的最低規格。應用還要容納 KV cache、context、執行框架與其他程序；顯示卡剛好有 14.1GB VRAM，不代表 27B 模型一定能在所有設定下順利工作。

容量留有餘裕後，還要確認模型格式能否使用硬體加速。相同 INT4 權重可能因封裝格式、核心實作或驅動程式而走 CPU，不一定用到 GPU 或 NPU。驗收時同時看工作管理員、系統監控或框架的裝置紀錄，確認推論實際跑在哪個處理器；只看到答案成功產生，不能證明加速路徑已正確啟用。

三個容易誤讀的地方：參數口徑、偏好評測與能力上限

參數量至少有三種口徑：總參數、當次啟動參數、等效記憶體負載。Apple AFM 3 Core Advanced 是 20B 總參數，每次啟動 1B 到 4B；Gemma 3n E2B 標準執行載入超過 5B，透過快取和跳過參數後的等效負載是 1.91B。這些數字不能互換。看到「某模型只有幾 B」，要追問它算的是哪一種參數、何種量化版本與哪一年規格。

context 的口徑也要拆清楚。它是一次請求可容納的 token 範圍，通常包含提示與既有對話，部分產品還會限制最大輸出。128K 不等於能穩定理解任何 128K 長文件，也不代表量化版沿用相同長度。模型卡若分 base、instruct、BF16 與 quantized，應逐一對照你下載的檔名。

偏好評測也不是能力評測。LMArena Elo 與 Apple 的並排人類評測都在問「哪個回答較受偏好」，不直接等於知識量、事實正確率或你的任務成功率。要做選型，從真實工作抽一批樣本，固定提示、context 與評分規則，盲測候選模型。新聞排名只能幫你縮小名單。

盲測時可以把失敗拆成幾類：漏掉必要欄位、引用不存在的事實、格式無法解析、拒答過多、速度超過容許時間。每類錯誤的代價不同，團隊要先寫清楚哪些錯誤可以重試、哪些結果必須交由人工確認，再看模型分數。

能力上限不能靠行銷名稱判斷。Microsoft 的 Phi-4-mini 模型卡同時列出 3.8B、128K context、63.5 的內部綜合分數，也明寫模型因容量有限而可能答錯事實。綜合分數是微軟自選測項的結果，對照 Llama 3.2 3B 的 56.2 不代表所有任務都領先。知識不足會增加事實錯誤風險，但 AI 幻覺還可能來自提示、檢索、解碼與訓練資料，不能只怪參數少。

怎麼判斷該用 SLM 還是 LLM：五個該用、三個別做

選型先問任務需要穩定的窄域判斷，還是大量外部知識與通用推理。模型大小只是後面的條件。

適合 SLM 的五種情況：

1. 任務範圍清楚、呼叫量高。 分類、情感分析、實體抽取、查詢路由與固定格式摘要，都容易建立測試集。Google 對 Gemma 3 270M 的定位就是任務級微調，不是複雜對話。
2. 資料不能離開裝置或機房。 端側或自有環境能縮小資料外流面，但仍要檢查紀錄、更新與遙測機制。
3. 互動延遲很敏感。 鍵盤建議、即時改寫、遊戲對話等功能不能等雲端往返，裝置端模型較適合。
4. 需要離線工作。 網路不穩的現場工具、旅行或機房環境，可把基本能力留在本機。
5. 硬體與系統已提供模型。 Apple Foundation Models、Windows AI APIs 與 Android ML Kit GenAI APIs 都能減少自行散布權重的工作。

五項不需要全部成立。任務很窄但資料可上雲，仍可能因大量呼叫而選本機模型；資料高度敏感但工作複雜，也可能選公司自有伺服器上的較大模型。部署位置、模型大小與資料治理要分開決定，再組成同一個系統。

落到決策表時，可以依序填四個欄位：可接受的錯誤、最長回應時間、資料允許的位置、每月工作量。任何一欄寫不出來，都還不適合比較模型。模型排行榜只能回答測試集上的相對表現，無法替團隊決定漏一筆資料與慢兩秒哪個代價更高。

三種情況不要直接用小模型硬撐：

1. 開放式事實問答。 模型權重裝不下足夠知識時，應接搜尋或 RAG 檢索增強生成，並驗證引用內容。
2. 複雜通用推理。 廠商可能公布單一基準勝過大模型，實際工作仍要用自己的測試集比較。
3. 長文件直接丟給量化版。 先核對該檢查點的 context；Llama 3.2 就有 128K 與 8K 兩種截然不同版本。

任務混合時可做分層路由：格式整理與分類交給 SLM，需要外部知識或複雜推理再送往 LLM。IBM 稱這類設計為 hybrid AI 與 intelligent routing。路由本身也要測試，因為判錯任務類型會把難題送給能力不足的模型。

RAG 也不是把文件接上去就完成。檢索可能找錯段落，context 可能塞入互相衝突的資料，小模型也可能忽略證據。至少要分別評估「有沒有找對內容」與「模型有沒有根據內容回答」，並在輸出中保留可追溯的文件位置。

開發者怎麼開始：四條接入管道與授權差異

Apple 走系統框架。 Foundation Models framework 自 iOS 26、iPadOS 26 與 macOS 26 起提供 guided generation、tool calling 和串流輸出。guided generation 可把回應約束成 Swift 型別；tool calling 讓模型呼叫 App 提供的程式。端側推論可離線，官方稱不收推論費，但權重不能下載。要做端側 AI Agent，仍要處理工具權限、錯誤回復與版本更新後的提示測試。

Apple 文件也提醒模型會隨系統更新。開發者應在執行前檢查 SystemLanguageModel 可用狀態，對不支援裝置提供替代流程；提示最好有版本，系統模型更新後重新跑測試。若訓練 LoRA adapter，每一代基礎模型更新還需要重新訓練相容版本。

Windows 走 Windows AI APIs。 截至 2026 年 8 月 20 日，Phi Silica 在 Copilot+ PC 的 NPU 上預先安裝，也能在部分 NVIDIA 與 AMD GPU 執行；GPU 路徑需要指定 Windows Insider build、Windows App SDK 2.2.2-experimental9 或更新實驗版、Developer Mode 與相容驅動程式。Phi Silica API 仍屬 Limited Access Feature，需要 LAF token。Microsoft 已公告 Aion Instruct 將在 2026 年 10 月起測試、11 月取代 Phi Silica；這是預定時程，正式上線前仍可能變動。

Android 走 AICore 與 ML Kit。 Gemini Nano 由 AICore 管理模型更新與硬體加速，開發者可用 ML Kit GenAI APIs 做提示、摘要、校對、改寫、圖片描述與語音辨識。功能受相容裝置與 token 限制，不是每台 Android 手機都有相同能力。Google 的 Gemini Nano 文件於 2026 年 4 月更新，現行路徑仍是 AICore 加 ML Kit。

AICore 的好處是 App 不必把大型模型一起封裝，系統會處理散布、更新與硬體介面；代價是模型版本與可用性由裝置環境決定。App 啟動時仍要查功能狀態，不能假設安裝新版作業系統就一定已有所需模型。

跨平台使用可下載權重。 Gemma、Llama 與 Phi 系列可從 Hugging Face 取得，常見本機執行環境包含 Ollama、llama.cpp 與相容框架。2026 年微軟平台現名是 Microsoft Foundry，已歷經 Azure AI Studio、Azure AI Foundry 兩次命名。授權不能混用：Phi-4 與 Phi-4-mini 是 MIT；Gemma 使用 Google 的 Gemma 條款；Llama 3.2 使用 Meta Llama 3.2 Community License。商業發布前要讀當下版本條款，不要把「可下載權重」直接等同 OSI 開放原始碼授權。想把權重、執行環境與授權這三件事串成一次完整的自架評估，可以參考Hermes Agent 自架評估的做法。

模型頁標示 open model 或 open weights，只能說明權重取得方式，未必允許毫無條件地再散布、改名或用輸出訓練其他模型。公司內部測試與把模型包進商業產品也是不同使用情境。授權頁有版本日期時，評估紀錄應連同日期保存，避免日後只記得模型名稱。

Phi-4-mini 模型卡還列出訓練規模：512 張 A100-80G、21 天、5 兆 tokens，訓練發生在 2024 年 11 到 12 月。這組數字描述從頭訓練，不是一般微調需求。小模型雖比旗艦模型容易部署，從頭訓練仍是大型專案；多數團隊更實際的起點是選現成權重、量化版本或 adapter。

你的手機與電腦裡可能已經有一個

一般使用者不必看到「SLM」字樣才算使用小模型。Apple Intelligence 的端側語言模型、Windows 的 Phi Silica、Android AICore 管理的 Gemini Nano，都是公開產品例子。是否真的在本機執行，要看裝置、系統版本與該功能的處理路徑。

判斷資料路徑時，產品的隱私說明與開發文件比功能名稱可靠。把網路關掉後測試，可以確認某項功能是否具備離線能力，卻不能證明連網時永遠不會使用雲端。若工作包含醫療、財務、客戶名單或未公開文件，應依組織的資料規範確認，而不是靠一次離線測試推定。

Apple Intelligence 的機型名單會隨新品更新。最可靠的檢查方式是看 Apple 當下的相容清單，並在 iPhone 或 iPad 打開「設定」>「Apple Intelligence 與 Siri」；這條介面路徑查證於 2026 年 8 月 20 日。Windows 可先查產品是否標為 Copilot+ PC，再核對 NPU 是否達 40+ TOPS。Android 則要查 ML Kit 各項 GenAI API 的相容裝置，不要只看手機是否叫 Pixel。

端側處理能減少資料上傳、支援離線並省去網路往返，但「裝置有小模型」不代表每次請求都留在本機。Apple 會在端側能力不足時使用 Private Cloud Compute；Android 官方也建議大型 PDF 或需要額外知識的工作改用雲端模型。App 若做混合路由，應清楚告知使用者資料何時離開裝置。

端側模型不會全面取代雲端模型。兩邊受不同限制：裝置有記憶體、耗電與散熱上限，雲端有連線延遲、費用與資料治理問題。要理解能力上限那一端，可對照 GPT-5.6 雲端模型家族；實際產品更常把兩者組合，而不是只留一種。

下一步：兩個檢查與一個小實驗

查裝置規格，約 5 分鐘。 iPhone、iPad 或 Mac 看 Apple Intelligence 相容清單與設定頁；Windows 看 Copilot+ 標章與 NPU TOPS；Android 查特定 ML Kit API 的相容機型。找不到 NPU 或端側模型支援，不妨礙使用雲端 AI，只表示不能假設功能在本機完成。

查模型卡，約 10 分鐘。 打開候選模型的原廠模型卡，記下參數口徑、量化格式、context、權重記憶體、授權與測試硬體。若頁面只寫「可在手機執行」，卻沒寫手機型號與框架，先把效能視為未知。

跑一個可重複的小實驗。 開發者可以挑 1B 到 4B 的量化模型，在 Ollama、llama.cpp 或對應原廠框架跑固定的 20 到 50 筆真實樣本，記錄正確率、首字延遲、生成速率與尖峰記憶體。這組結果才適合拿來做自己的部署決定。

測試紀錄要附模型完整 ID、檢查點、量化格式、框架版本、硬體、提示與日期。少了其中一項，幾個月後很難重現。測試資料若含敏感內容，先去識別化或在核准環境執行；為了評估本機隱私而把真實機密貼進公開服務，方向就反了。

模型尺寸與支援裝置會持續更新，五個比較維度不會失效：成本、延遲、隱私、離線與能力上限。規格有年份、數字有量測條件，才有比較價值。