地端模型指的是把大型語言模型的權重檔下載到自己的機器上，用本機的 CPU 或 GPU 做推論。問題和答案都不會離開這台電腦，也不會產生 API 帳單。在企業語境裡，地端模型通常指部署在自家機房或私有雲的 LLM；在個人語境裡，它就是筆電上跑起來的 Ollama 或 LM Studio。規模差很多，底層邏輯是同一套。
能不能跑，取決於一個數字：可用的記憶體。8 GB VRAM 大致能跑 8B 參數的四位元量化模型，24 GB 能推到 32B，要跑 70B 通常需要 48 GB 以上，或是一台記憶體夠大的 Apple Silicon Mac。跑得快不快，取決於另一個數字：記憶體頻寬。這兩個數字是整篇文章的骨架，其他都是延伸。
如果只想要一句判斷：資料規定不能外流、或每月 API 帳單已經高到足以攤提硬體，地端模型值得投入；如果只是想省錢、又沒有隱私需求，先把後面那段攤提算式跑一遍再決定——多數個人使用者算完會發現雲端 API 還是比較便宜。
地端模型到底是什麼：三層結構要先分清楚
很多教學文把地端模型講成「安裝一個軟體」，這會讓人在第一次卡關時完全不知道問題出在哪。實際上它是三層疊起來的：
- 模型權重：一個幾 GB 到幾百 GB 的檔案，裡面是訓練好的參數。常見格式是 GGUF（給 llama.cpp 家族用）和 safetensors（給 PyTorch、vLLM 用）。
- 推論引擎：真正做矩陣運算的程式，負責把權重載入記憶體、跑出下一個 token。llama.cpp、MLX、vLLM 都在這一層。
- 介面層：讓人用得下去的殼——命令列、圖形介面、或一個 HTTP API。Ollama 和 LM Studio 主要活在這一層。
分清楚這三層之後，很多問題會自動有答案。「Ollama 和 llama.cpp 哪個快」這個問題本身就有點怪，因為 Ollama 官方 README 明說它的推論基礎就是 llama.cpp；速度差異只會來自外殼開銷。「換一個工具會不會跑得比較好」也一樣——如果引擎沒換，通常不會。
地端模型與雲端 API 的結構性差異
| 面向 | 地端模型 | 雲端 API |
|---|---|---|
| 資料流向 | 不離開本機或自家機房 | 送到服務商伺服器處理 |
| 成本結構 | 一次性硬體 + 電費 + 時間 | 按 token 用量計費 |
| 模型版本 | 權重存在本機，不會被下架或悄悄換掉 | 服務商可能更新、棄用或調整模型 |
| 可及的品質天花板 | 受限於自己的硬體 | 可用到當下最強的前沿模型 |
| 離線可用 | 可以 | 不行 |
| 維運責任 | 全部在自己身上 | 服務商負責 |
| 並發能力 | 單機通常只服務一到少數幾個請求（並發數受 KV cache 排擠） | 幾乎無上限 |
這張表最容易被忽略的一列是「維運責任」。雲端 API 出問題有狀態頁和客服，地端出問題只有自己。這件事在評估階段幾乎不會被算進成本，但它是實務上最大的隱藏支出。
同一份權重，跑在誰的機器上：為什麼開放模型還要付 token 費
這是最常見的一個誤解，而且會直接影響採購判斷：既然 Kimi、DeepSeek、Qwen 都被稱為開源或開放權重模型，為什麼實際用起來還是按 token 計費？
因為「開放權重」講的是能不能拿到模型檔案，跟誰出運算資源是兩件完全獨立的事。
以 Kimi K2.6 為例：它是 1 兆參數的 MoE 模型，權重公開在 Hugging Face 上，授權是修改過的 MIT（只有在月活躍使用者超過一億、或月營收超過兩千萬美元時才要求標示）。任何人都能下載。但官方放在 Hugging Face 上的權重是原生 INT4（在後訓練階段就用 QAT 做出來的，不是事後才壓縮），檔案本身就有約 594 GB；換成 FP16 大約是 2 TB。這跟前面算的「70B 要 48 GB」差了超過一個數量級，不是消費級硬體的世界。順帶一提，這也說明量化不只是個人玩家在用的技巧——連模型作者自己發布的預設版本都是量化過的。絕大多數人不可能在自己機器上跑它。
所以大家實際上是透過官方 API 或代管平台在用。付出去的錢不是模型授權費（那確實免費），而是租用別人的 GPU 叢集。同一份權重，自己跑就只有電費，請別人跑就按 token 計價。
看到「Q4 量化版也要付費」也是同一回事。量化只是把模型壓小，讓部署更便宜更快，但它不改變這次推論跑在誰的硬體上。平台提供量化版本，是因為對他們來說成本更低、可以賣得更便宜，不是因為量化版有什麼額外的授權費。
判斷方式很單純：看推論發生在哪台機器上，不要看模型叫什麼名字。
- 跑在你的機器 → 沒有 token 費用，成本是硬體攤提加電費
- 跑在別人的機器 → 按 token 計費，跟它是不是開放權重無關
順帶一提，這也解釋了為什麼 MoE 模型特別容易造成誤解：宣傳會強調「只啟用 32B 參數」，聽起來像消費級硬體跑得動，但權重仍然要整包載入記憶體。後面〈模型怎麼選〉那節會再談這個坑。
官方定價可以拿來感受一下量級。以 Moonshot 目前的 Kimi K3 為例，輸入每百萬 token 是 3 美元、命中快取降到 0.30 美元，輸出則是 15 美元：
這裡有個實務上常被忽略的細節：輸出比輸入貴得多。K3 的輸出單價是輸入的五倍、是快取命中輸入的五十倍。所以真正讓帳單失控的通常不是「餵了很長的文件進去」，而是「叫它產出很長的內容」——這也是為什麼摘要、分類這類任務相對便宜，而長篇生成類任務貴得多。要估自己划不划算，這個比例比總 token 數更值得先看。
為什麼有人要自己跑：四個理由，但不是每個都適用你
一、資料不出門
這是唯一一個「其他方案無法替代」的理由。客戶名單、病歷、製程參數、未公開的財務數字、合約全文——這些送進雲端 API，就等於交給第三方處理。多數服務商有明確的資料使用政策，但政策是承諾，不是物理限制。地端模型可以做到物理限制——推論在本機發生，封包不需要離開這台機器。但要說清楚：「可以做到」不等於「預設就是」。工具本身仍會為了更新檢查之類的目的連線，而且現在主流工具都同時提供雲端模型選項，選錯就等於把內容送出去了。這篇後面有一節專門講怎麼實際驗證。
如果你的工作有法遵要求（個資法、醫療資料、金融監理），這一條通常就直接決定了答案，後面的成本計算只是在挑實作方式。反過來說，如果處理的都是本來就要公開的內容——部落格草稿、社群貼文、公開資料整理——這條理由對你不成立，不要拿它當說服自己買顯卡的藉口。
二、成本結構從「用量」變成「一次性」
雲端 API 的帳單跟用量成正比，用越多付越多。地端模型是先付一筆硬體錢，之後的邊際成本只有電費。對於量大而穩定的工作——每天跑幾萬次分類、批次翻譯整個資料庫、大量文件摘要——這個結構會在某個用量之後翻轉成本優勢。
關鍵字是「量大而穩定」。零星使用的話，硬體攤提永遠追不上。這篇後面會給一個具體的損益兩平算式。
三、離線與版本可控
權重檔在自己的硬碟上，就不會遇到「服務商把這個版本下架了」或「模型悄悄更新，同一個 prompt 突然給出不同結果」。對於已經把 prompt 調到堪用、不想再重調的流程，這個穩定性有實際價值。離線可用則是少數場景才用得到的加分項——飛機上、沒有網路的工地、隔離網段。
四、可改
開放權重模型可以微調、可以改 system prompt 的底層設定、可以自己決定要不要保留內容過濾。這條的門檻比想像中高：微調需要的顯示記憶體遠大於推論，而且需要準備資料集。對多數人來說，這個理由停留在「理論上可以」的階段。
地端模型需要連網嗎？資料真的不會出去嗎？
前面把「資料不出門」列為地端最強的理由，這一節要把它講精確，因為「跑在本機」和「完全不連網」並不是同一件事。
推論本身不需要網路
模型下載完成之後，產生回覆這個動作完全在本機發生，把網路關掉照樣運作。這是地端模型真正的物理性質，不是廠商的承諾。需要連網的只有這幾件事：第一次下載模型權重、更新模型或軟體版本、以及在工具裡搜尋模型。
但工具本身還是會連線
兩大工具的官方隱私政策對「內容」講得很明確。LM Studio 寫的是「If you download and run models locally, none of your messages, chat histories, and documents are ever transmitted from your system」——本機執行時，訊息、對話紀錄與文件不會離開你的系統。Ollama 則寫「We do not collect, store, transmit, or have access to your prompts, responses, model interactions, or other content you process locally」——不收集、不儲存、不傳輸，也無法存取你在本機處理的內容。
但兩者都會發出跟內容無關的連線：更新檢查會送出應用程式版本、作業系統資訊與 IP；在工具內搜尋模型會把查詢字串送到伺服器。LM Studio 另外有匿名使用統計，可以在 Settings → Privacy 關掉「Send anonymous usage data」。
對多數人來說這些連線不構成問題。但如果是法遵情境——處理病歷、個資、受監理的財務資料——「這台機器有沒有對外連線」本身可能就是稽核項目，那時候該做的是網路層隔離，而不是相信軟體設定。
真正該注意的是混合模式
這是目前最容易出事的地方，而且跟遙測完全無關：Ollama 和 LM Studio 現在都同時提供本機模型與雲端模型，而且是同一個介面。
選到雲端模型時，內容就是會送到對方伺服器——兩家的政策都寫明雲端模式下內容會被暫時處理（transiently processed）、請求完成後不留存。這在功能上完全合理，但它意味著「用的是 Ollama」不等於「資料沒有出去」，決定權在於你選了清單裡的哪一個模型。
同樣的陷阱也出現在各種本機聊天介面上：UI 跑在本機，不代表它背後接的是本機模型。很多開源 UI 預設就能同時接雲端 API，一個下拉選單就切換過去了，畫面上不見得有明顯提示。
怎麼真的確認
不要靠讀說明書，用行為驗證：
- 斷網測試：模型下載完成後，關掉 Wi-Fi 或拔掉網路線，再跑一次完整的工作流程。能正常產出回覆，代表推論確實在本機；跑不動，代表某個環節其實在呼叫外部服務。
- 用防火牆確認：在作業系統或路由器層封鎖該程式的對外連線，觀察哪些功能失效。這比看設定畫面可靠，因為它擋的是實際封包。
- 確認模型來源：檢查目前選用的是本機權重（硬碟上有實體檔案），而不是同一份清單裡長得很像的雲端選項。
做完斷網測試，「資料不出門」才從一句廠商承諾變成一件你自己驗證過的事——而這正是選擇地端的整個意義所在。
硬體門檻：VRAM 到底怎麼算
這是整篇最實用的一節。多數人問的「這台電腦能不能跑」，其實是可以算出來的。
基本公式
模型權重佔用的記憶體，等於參數量乘上每個參數的位元數再除以 8：
權重大小（GB）≈ 參數量（B）× 每參數位元數 ÷ 8
Hugging Face 的 GGUF 文件列出了各種量化格式實際的每參數位元數（bits-per-weight），這不是概數，是規格：
| 量化格式 | 每參數位元數 | 8B 模型約需 | 32B 模型約需 | 70B 模型約需 |
|---|---|---|---|---|
| F16（未量化） | 16 | 16 GB | 64 GB | 140 GB |
| Q8_0 | 8 | 8 GB | 32 GB | 70 GB |
| Q6_K | 6.5625 | 6.6 GB | 26 GB | 57 GB |
| Q5_K | 5.5 | 5.5 GB | 22 GB | 48 GB |
| Q4_K | 4.5 | 4.5 GB | 18 GB | 39 GB |
| Q3_K | 3.4375 | 3.4 GB | 14 GB | 30 GB |
| Q2_K | 2.625 | 2.6 GB | 10.5 GB | 23 GB |
算完權重之後還沒結束，要再加兩塊：
- KV cache：模型記住前文用的快取，會隨著 context 長度線性成長。它不需要查表，可以直接算：2 × 層數 × KV head 數 × head 維度 × context 長度 × 每個元素的位元組數。以 Llama 3.1 8B 為例（32 層、8 個 KV head、head 維度 128、FP16 存放），每個 token 約 128 KB，換算下來 4k context 約 0.5 GB、32k 約 4 GB、128k 約 16 GB。這是很多人「明明算好裝得下卻爆掉」的原因——他們算了權重，沒算 context。多數工具支援把 KV cache 也量化成 8-bit，需要長 context 時可以再省一半。
- 框架開銷：啟用中的中間結果、程式本身佔用的空間，一般抓權重的 15% 到 20%。
把三塊加起來，一個 8B 模型跑 Q4_K_M、開 8k context，實際佔用大約在 6.5 GB 上下（權重 4.5 GB、KV cache 約 1 GB、其餘是框架開銷）。8 GB 的顯卡跑得動，但不會有太多餘裕。
不同記憶體級距實際跑得動什麼
| 可用記憶體 | 合理的模型規模 | 使用感受 |
|---|---|---|
| 8 GB | 7B–8B，Q4_K_M，context 4k–8k | 能跑，適合摘要、改寫、簡單問答 |
| 12–16 GB | 12B–14B Q4，或 8B 用 Q6 拉高品質 | 日常助理級別，開始堪用 |
| 24 GB | 27B–32B Q4，context 8k–16k（要拉到 32k 得把 KV cache 量化成 8-bit） | 明顯感覺得到品質跳升 |
| 32 GB | 32B Q5–Q6，或 70B 的低位元量化（勉強） | 單卡消費級的實用上限 |
| 48–64 GB | 70B Q4，或多個中型模型同時載入 | 需要雙卡或大記憶體 Mac |
| 96 GB 以上 | 70B 高品質量化、100B 以上的 MoE 模型 | 已經是工作站或伺服器等級 |
裝不下會怎樣？
不會直接失敗。llama.cpp 支援混合推論，模型放不進 VRAM 的部分會留在系統記憶體，由 CPU 負責計算。程式跑得起來，但速度是斷崖式下降——不是慢 20%，是慢好幾倍。因為系統記憶體的頻寬通常只有顯示記憶體的十分之一左右。
實務上的判準是：如果有超過一兩層必須 offload 到 CPU，不如換一個小一號的模型，或降一階量化。一個跑得順的 8B，體感上比一個一秒吐兩個字的 32B 有用得多。
量化：用一點品質換掉一半以上的記憶體
量化就是把模型參數從 16 位元浮點數壓成更少的位元數。這是地端模型能在消費級硬體上跑起來的唯一原因——沒有量化，8B 模型要 16 GB，70B 要 140 GB，這個題目根本不存在。
GGUF 是目前地端最主流的格式，由 llama.cpp 的作者 Georgi Gerganov 開發，特點是把權重和描述模型的中繼資料包在同一個檔案裡，載入快、好搬。llama.cpp 本身支援 1.5 位元到 8 位元的整數量化，實務上會用到的大約是 2 到 8 位元。
為什麼 Q4_K_M 幾乎是預設答案
命名規則拆開來看：Q4 是四位元，_K 表示 k-quant 系列（用 super-block 結構，同一個區塊內混用不同精度），_M 是這個系列裡的中等變體。它的每參數位元數是 4.5 而不是剛好 4，多出來的 0.5 就是那些 block scale 和 block minimum。
它之所以成為預設，是因為它落在曲線的轉折點上：相對 F16 省掉約七成記憶體，但品質衰退在多數任務裡不明顯。往下降到 Q3、Q2，記憶體省得越來越少（從 4.5 降到 3.4 只省 24%），品質掉得越來越快；往上升到 Q6、Q8，品質提升的幅度小於記憶體代價。
什麼時候該偏離預設
- 往上（Q5_K_M、Q6_K）：記憶體有餘裕、任務對精確度敏感（寫程式、數字計算、結構化輸出）。同樣的記憶體預算下，「小模型高位元」和「大模型低位元」哪個好沒有通則，值得自己兩邊都試。
- 往下（Q3_K_M 以下）：只有在「跑得動比跑得好重要」時才考慮，例如硬體實在裝不下、或只是要驗證流程能不能通。Q2 級別的輸出品質通常已經不適合正式使用。
- IQ 系列：用 importance matrix 做的量化，同樣位元數下品質比傳統量化好，代價是製作成本高、不是每個模型都有現成檔案。記憶體吃緊時值得找找看。
要提醒的是，量化造成的品質損失很難用單一數字描述。benchmark 分數掉個一兩分，實際使用時可能完全沒感覺，也可能在某個特定任務上壞得很明顯。官方文件不會告訴你「Q4 會讓中文寫作變差幾 %」，因為沒有人量得出來。唯一可靠的方法是拿自己真正的任務去跑。
速度的真相：決定 tokens/s 的是記憶體頻寬，不是算力
這一節是選硬體時最容易搞錯的地方。直覺會說「顯卡越強越快」，但 LLM 推論在生成階段是記憶體頻寬受限（memory-bandwidth-bound），不是算力受限。
原因在於自迴歸生成的機制：每產生一個 token，都要把模型的權重從記憶體讀過一遍。讀十幾 GB 的權重才吐一個字，運算量相對讀取量小得多。所以：
每秒 token 數 ≈ 記憶體頻寬 ÷ 每個 token 需要讀取的權重位元組數
用一組裝得下的硬體驗算：32B 模型 Q4_K_M 約 18 GB，放進 24 GB 的 RTX 4090（頻寬 1,008 GB/s），理論上限是 1008 ÷ 18 ≈ 56 tokens/s。要強調的是，這是公式推得的上限，不是實測值——實際還要扣掉 KV cache 的讀寫、取樣與框架開銷，一定會低於這個數字。它的用途是比較不同硬體之間的量級差異，不是拿來預期自己能跑多快。
公式失效的那條線：模型裝不進記憶體的時候
上面的公式有一個前提：權重必須整包待在那塊高頻寬記憶體裡。一旦裝不下，公式就不適用了。
舉個具體的例子：70B 模型 Q4_K_M 約 39 GB，而 RTX 4090 只有 24 GB。這個組合不是「慢一點」，而是會退化成完全不同的運作方式——裝不下的層被推到系統記憶體，每產生一個 token 都要透過 PCIe 來回搬運，實際速度會掉到個位數 tokens/s。把 1,008 GB/s 套在一個根本裝不下的模型上，算出來的數字沒有任何意義。
所以順序是固定的：先確認裝得下，再談頻寬。裝不下的時候，加記憶體容量遠比換更快的顯卡有用。這也是為什麼下一節要把統一記憶體跟獨立顯卡分開談——它們解決的是不同的問題。
常見硬體的頻寬對照
| 硬體 | 記憶體容量 | 記憶體頻寬 | 特性 |
|---|---|---|---|
| RTX 4090 | 24 GB GDDR6X | 1,008 GB/s | 單卡速度基準線 |
| RTX 5090 | 32 GB GDDR7 | 約 1,792 GB/s | 頻寬比 4090 高約 78% |
| M4 Pro | 最高 64 GB 統一記憶體 | 273 GB/s | 容量換速度 |
| M4 Max | 最高 128 GB 統一記憶體 | 546 GB/s | 大模型的入場券 |
| 一般 DDR5 系統記憶體 | 視主機板 | 約 60–100 GB/s | 純 CPU 推論會很慢的主因 |
把公式套進去就能預判：同一個 8B Q4 模型（約 4.5 GB），4090 理論可以到每秒兩百多個 token，M4 Max 大約一半，純 CPU 跑 DDR5 大概十幾個。這也解釋了一個常見的困惑——為什麼有人說 Mac 跑 LLM 很好用，有人說很慢。他們講的是不同的事：Mac 的優勢是「裝得下」，不是「跑得快」。
Mac 統一記憶體 vs 獨立顯卡：兩種完全不同的取捨
統一記憶體的邏輯
Apple Silicon 的 CPU 和 GPU 共用同一塊實體記憶體，沒有「把資料從系統記憶體搬到顯示記憶體」這個步驟。對 LLM 來說，直接的好處是模型大小的上限不再是顯卡的 24 GB 或 32 GB，而是接近整台機器的記憶體。一台 128 GB 的 Mac 可以載入需要 90 GB 的模型，這在消費級顯卡上要疊三張卡才做得到。
但有個細節常被忽略：macOS 預設不會讓 GPU 用滿全部記憶體。系統會把 GPU 可以「wire」（鎖定、不可置換）的記憶體限制在大約七成五，剩下留給核心與其他行程。這個比例不是固定的——依機型與系統版本，實測從三分之二到接近八成都有人量到，要精確知道自己這台的值，可以在程式裡讀 Metal 的 recommendedMaxWorkingSetSize。這個上限可以用 sysctl 調整 iogpu.wired_limit_mb 這個參數來提高，但兩件事要知道：一是重開機後會還原成預設值，二是不要把記憶體幾乎全部鎖給 GPU，常見的建議是至少留 8 到 16 GB 給系統與其他行程——鎖得太多，系統本身會開始不穩。
獨立顯卡的邏輯
顯卡的優勢在頻寬。GDDR6X 或 GDDR7 的頻寬是統一記憶體的兩到六倍，同樣的模型跑起來就是快。CUDA 生態也成熟得多，微調、量化工具、vLLM 這類服務框架都優先支援 NVIDIA。
代價是容量。消費級顯卡的顯示記憶體是焊死的，24 GB 就是 24 GB，要更多只能加卡，而加卡會連帶推高機殼、電源、散熱和噪音的需求。多卡推論還會遇到 PCIe 通道與模型切分的問題，不是插上去就能線性加速。
怎麼選
| 你的情況 | 比較合理的方向 |
|---|---|
| 想跑 70B 以上、速度可以接受每秒十幾個字 | 大記憶體 Mac |
| 主力跑 8B–32B、要快、要即時互動 | 單張高階顯卡 |
| 要微調模型，不只是推論 | NVIDIA 顯卡（CUDA 生態） |
| 要服務多個使用者或做成內部 API | NVIDIA 顯卡 + vLLM |
| 已經有一台 Mac，只是想試試看 | 先用現有機器跑小模型，不要先買 |
| 筆電、在意續航與噪音 | Apple Silicon |
最後一項值得展開：獨立顯卡在滿載時的功耗、風扇噪音和房間溫度是真實的生活成本。這件事在規格表上看不到，但會直接影響你到底會不會天天用它。
四套工具怎麼選：Ollama、LM Studio、llama.cpp、vLLM
回到前面講的三層結構，這四個名字其實不在同一層，所以「哪個最好」是個沒有答案的問題。
| 工具 | 層級 | 介面 | 授權 | 適合誰 |
|---|---|---|---|---|
| llama.cpp | 推論引擎 | 命令列 + 內建 server | MIT | 要最大控制權、特殊硬體、想調參數的人 |
| Ollama | 介面層（底層用 llama.cpp） | 命令列 + REST API | MIT | 開發者、要接自動化流程 |
| LM Studio | 介面層（llama.cpp / MLX 雙後端） | 圖形介面 + 本機 server | 免費（含商用） | 不想碰終端機、想先試模型的人 |
| vLLM | 服務系統 | Python + OpenAI 相容 server | 開源 | 要服務多人、跑正式服務 |
Ollama：最省事的起點
MIT 授權，支援 macOS、Windows、Linux 與 Docker。核心體驗是兩個指令——ollama pull 抓模型、ollama run 開始對話——模型庫在 ollama.com/library。裝完之後它會在本機 11434 埠開一個 REST API，官方也提供 Python 和 JavaScript 套件。
對個人品牌經營者最實際的價值是這個 API：把它接到自動化流程裡，就能做出「不需要 API key、不會產生帳單、資料不外流」的內容處理節點。如果你已經在用自動化工具，可以參考 n8n 是什麼 裡的節點概念，把地端模型當成流程中的一個 HTTP 節點來用。
要留意的是 Ollama 官方文件沒有明確列出各尺寸模型的硬體需求，這部分得自己用前面的公式估。
LM Studio：完全不碰終端機的路
圖形介面工具，可以直接在裡面瀏覽、下載、切換模型，也能開本機 server。它同時支援 llama.cpp 和 Apple 的 MLX 兩種後端，在 Mac 上會用到 MLX——多份公開測試顯示 MLX 在 Apple Silicon 上比 llama.cpp 快，幅度視模型而定。
系統需求要看清楚，這是它最容易踩雷的地方：
- macOS 14.0 以上，只支援 Apple Silicon（M1/M2/M3/M4），Intel Mac 目前不支援。
- Windows 支援 x64 與 ARM（Snapdragon X Elite），x64 需要 CPU 支援 AVX2 指令集。
- Linux 支援 x64 與 ARM64，官方標示 Ubuntu 20.04 以上，22 之後的版本測試較不完整。
- 記憶體建議至少 16 GB；8 GB 的 Mac 只能跑小模型並縮短 context。Windows 建議至少 4 GB 獨立顯示記憶體。
授權方面，LM Studio 從 2025 年 7 月 8 日起改為在家與在公司都免費使用，不再需要另外申請商用授權；付費的部分留在企業版（SSO、模型與 MCP 管控、私有協作）。這對想在公司內部試水溫的人是個實際的差別。
llama.cpp：引擎本身
MIT 授權，目標是「用最少的設定在各種硬體上做 LLM 推論」。它的後端支援範圍是四者裡最廣的：Apple Silicon 的 Metal 與 ARM NEON、NVIDIA CUDA、AMD HIP、Intel SYCL、通用的 Vulkan 與 WebGPU，以及 x86 的 AVX/AVX2/AVX512/AMX 和 RISC-V 的 RVV。它也支援 CPU + GPU 混合推論，讓超過顯示記憶體的模型仍然跑得起來。
附帶的工具有 llama-cli（命令列對話）和 llama-server（OpenAI 相容 API server，內建網頁介面），還有 GBNF 語法約束輸出的功能——需要模型穩定吐出特定格式時很有用。
什麼時候該直接用它而不是 Ollama？硬體特殊（非主流 GPU、嵌入式裝置）、需要調到 Ollama 沒開放的參數、或是要壓榨最後一點效能的時候。代價是要自己編譯、自己管參數。
vLLM：給多人用的那一個
vLLM 出自 UC Berkeley 的 Sky Computing Lab，定位跟前三個完全不同——它不是給一個人用的，是給一個服務用的。兩個關鍵技術：PagedAttention 把 KV cache 切成區塊動態配置與釋放，避免記憶體碎片；continuous batching 讓多個請求的 token 生成交錯進行，把 GPU 利用率拉滿。
差距有多大？Red Hat 的比較測試裡，在 64 個並發使用者的情境下，vLLM 每秒產生的 token 數大約是 llama.cpp 的 44 倍。原因不是單次推論比較快——llama.cpp 也能並發，llama-server 有 –parallel 可以開多個 slot，同樣支援 continuous batching。差距在批次處理的效率：vLLM 的 PagedAttention 把 KV cache 切成小塊動態配置，同一批請求能塞得更滿、記憶體浪費更少，所以並發數一拉高，吞吐量就拉開。
它支援 200 個以上的模型架構，量化格式涵蓋 FP8、MXFP8/MXFP4、NVFP4、INT8、INT4、GPTQ、AWQ 到 GGUF；硬體上支援 NVIDIA 與 AMD GPU、x86/ARM/PowerPC CPU，另有 Google TPU、Intel Gaudi、Apple Silicon 等外掛。
代價是門檻：要 Python 環境、實務上要一張真正的資料中心或高階 GPU、設定時間從三分鐘變成半小時起跳。單人使用完全沒必要。
一句話選型
- 第一次接觸，想在十分鐘內看到模型講話 → LM Studio
- 要把地端模型接進自己的程式或自動化流程 → Ollama
- 硬體特殊、要調參數、要最後那 15% 效能 → llama.cpp
- 要開一個內部服務給團隊或多個應用共用 → vLLM
模型怎麼選：先看裝不裝得下，再看做什麼
選模型的順序不是「哪個最強」，而是「在自己的記憶體預算裡，哪個最強」。這兩個問題的答案通常不一樣。
目前地端常見的模型家族
以 Ollama 模型庫的下載量來看，幾個主要家族與可用尺寸大致是這樣：
| 家族 | 可用尺寸 | 特點 |
|---|---|---|
| Qwen 系列（qwen3、qwen3.5、qwen2.5） | 0.6B 到 235B，含 dense 與 MoE | 尺寸選擇最完整，中文表現受評價高 |
| Gemma 系列（gemma3、gemma4） | 270M 到 31B | 主打單卡可跑，新版含多模態 |
| Llama 系列（llama3.1、llama3.2） | 1B 到 405B | 生態最廣，微調範例最多 |
| DeepSeek-R1 | 1.5B 到 671B | 推理型模型，小尺寸多為蒸餾版 |
| Qwen2.5-Coder | 0.5B 到 32B | 專做程式碼生成與修補 |
三個容易踩到的坑
坑一：MoE 模型的參數量不能直接拿來算記憶體。混合專家（MoE）架構的模型，總參數量和每次推論實際啟用的參數量是兩回事。啟用參數少代表算得快，但權重仍然要全部載入記憶體。看到「235B 但只啟用 22B」不要以為 24 GB 顯卡跑得動。
坑二：授權不等於開源。「開放權重」和「開源」是不同的事。Qwen 系列多數採 Apache 2.0，商用限制少；Llama 和 Gemma 各有自己的使用條款，不符合 OSI 對開源的定義，商用前要實際讀過條款。這跟自動化工具圈的授權爭議是同一類問題——n8n 和 Make 的比較裡有一段完整解釋 fair-code 這類「看起來開源但不是」的授權模式，邏輯可以直接套用。
坑三：不要把某個型號當結論。開放權重模型的更迭速度是以月計的，今天的最佳選擇三個月後大概率不是。可以帶走的是方法：算出自己的記憶體預算 → 篩出裝得下的尺寸 → 在那個尺寸裡挑當下評價好的 → 拿自己真正的任務測。型號會過期，方法不會。
從零開始的實際路徑
這個順序刻意把「買硬體」放在最後，因為那是唯一不可逆的一步。
- 先定義任務：要它做什麼？摘要、翻譯、改寫、寫程式、還是回答內部文件的問題？不同任務對模型規模的要求差很多，摘要和改寫用 8B 就很夠，寫程式和推理則會明顯感受到大模型的差別。
- 用現有機器跑最小可行版本：裝 LM Studio 或 Ollama，抓一個 8B 的 Q4_K_M，用真正的任務測十次。這一步花不到一小時，卻能淘汰掉大部分不切實際的期待。
- 往上調到卡住為止：把模型尺寸或量化位元數往上加，直到速度掉到不能忍受。這個臨界點就是你現有硬體的實際能力，也是後續評估升級是否值得的基準線。
- 接上 API 做一次真的流程：用 Ollama 的 REST API 或 llama.cpp 的 server，把它串進一個實際會用到的流程——例如自動整理筆記、批次改寫社群貼文草稿。只有跑過真實流程，才知道品質夠不夠。
- 算損益兩平：把現在的雲端 API 月支出、預計的硬體價格、電費放進下一節的算式。
- 最後才決定要不要買硬體：如果前五步做完還是覺得值得，這時候的決定會比一開始準確得多。
值得單獨提醒第四步。地端模型最容易被高估的環節是「品質看起來還可以」——在對話框裡試幾句都不錯，接進真實流程跑一百次才會發現它在某些輸入上會壞掉。要用它取代雲端服務，這一步不能跳。順帶一提，如果你的需求其實是「整理大量資料並產生可查證的筆記」，先看看 NotebookLM 的使用方式可能更快，不見得要自己架模型。
誠實面：地端模型做不到什麼
品質天花板是硬的
能在單機跑的模型規模，跟前沿的商業模型之間存在客觀差距。開放權重模型這兩年進步很快，8B 到 32B 的模型在摘要、改寫、分類、簡單問答上已經相當可用，但在長鏈推理、複雜程式碼、細膩的中文寫作上，差距仍然感受得到。宣稱「地端模型已經追平雲端」的說法，通常是拿特定 benchmark 的特定分數在講。
並發是單機架構的天然限制
llama.cpp 不是不能並發——llama-server 有 –parallel 可以開多個 slot，也支援 continuous batching。真正的限制在於每個 slot 都要從同一塊記憶體裡分走自己的 KV cache，所以並發數、context 長度、模型大小這三件事會互相排擠：想同時服務三個人，等於把每人可用的 context 砍掉大半，或者退回更小的模型。
吞吐量的差距則是另一回事。前面提到 vLLM 在 64 並發下約有 44 倍的優勢，那個差距來自批次處理的效率（PagedAttention、更靈活的記憶體配置），不是「llama.cpp 做不到並發」。而 vLLM 的硬體要求又跳到另一個級距。結論不變：「架一台給全公司用」在成本上通常比想像中貴很多，只是原因是記憶體被並發吃掉，不是引擎不支援。
長 context 的代價比想像中高
前面算過 KV cache 會隨 context 線性成長，而且成長得比多數人預期的快。以 8B 級模型為例，開到 128k context 時光是 KV cache 就要額外約 16 GB，層數更多、KV head 更多的模型還會再高，而且處理速度會明顯變慢。「模型支援 128k」和「你的硬體跑得動 128k」是兩件事。
周邊能力要自己補
雲端服務附帶的網頁搜尋、檔案上傳、程式碼執行、多模態理解，地端模型多半只有模型本體。要有這些能力得自己組合工具鏈，每一項都是額外的工程與維護。
維運責任沒有出口
驅動程式版本、CUDA 相容性、模型更新、硬碟空間、系統崩潰——這些全部是你的事。這是地端模型最被低估的成本，而它是以時間計價的。
什麼時候雲端 API 才是正確答案
算一次損益兩平
用具體數字比爭論有用。假設一套能跑 32B 模型的主機（含高階顯卡）花費新台幣 60,000 元，以三年攤提：
- 硬體攤提：60,000 ÷ 36 ≈ 每月 1,667 元
- 電費：推論時整機約 500 W，每天實際運轉 4 小時，一個月約 60 度。依台電住宅累進電價，這 60 度落在哪個級距取決於全戶用電量——若整體用量落在 331 至 500 度的區間，非夏月費率為每度 3.13 元、夏月 3.80 元，約合每月 190 至 230 元；若全戶用量已經在 501 至 700 度區間，費率變成 4.24 元與 5.14 元，約合每月 250 至 310 元。
- 合計：約每月 1,900 至 2,000 元，還沒算你花在設定與排錯上的時間。
判準因此很清楚：如果目前的雲端 API 月支出明顯低於這個數字，而且沒有資料外流的顧慮，地端模型在純財務上不會回本。反過來，如果月支出已經穩定超過這條線，或者根本不能把資料送出去，那筆硬體錢就開始說得通了。
要注意這個算式對「電腦本來就要買」的人不成立——如果那台 Mac 或那張顯卡本來就要買來做別的事，跑 LLM 的邊際成本就只剩電費，門檻低很多。
這些情況直接選雲端
| 情況 | 建議 |
|---|---|
| 用量零星、每月幾百次以內 | 雲端 API，攤提永遠追不上 |
| 需要當下最強的推理或程式碼能力 | 雲端 API，品質差距是真的 |
| 需要網頁搜尋、多模態、工具呼叫等整合能力 | 雲端 API，自己組成本太高 |
| 要服務多個使用者但不想維護伺服器 | 雲端 API |
| 還在驗證「AI 到底能不能幫上忙」 | 雲端 API，先確認需求存在 |
| 資料有法遵限制，不能離開機房 | 地端，沒有其他選項 |
| 單一任務量大且穩定，模型不需要很強 | 地端，成本結構會翻轉 |
最務實的答案通常是「兩個都用」
把敏感資料的處理、高頻的簡單任務（分類、抽取、格式轉換）放地端；把需要最強推理、需要外部工具、量少但重要的任務放雲端 API。這個混合策略跟自動化工具的選擇邏輯幾乎一樣——輕量標準的流程放託管服務，重的或敏感的自己架——這在 n8n 和 Make 的比較裡是同一個結論。
實務上的常見路徑是：先用雲端 API 把流程跑通、確認價值，等到帳單裡出現某個「量大、重複、其實不難」的固定支出，再把那一塊搬到地端。這樣做的好處是每一步都有數據支撐，不會為了一個還沒驗證的需求先買硬體。
常見問題
8 GB 顯卡可以跑地端模型嗎？
可以，但要接受規模限制。8 GB 大約能容納 7B 到 8B 參數的 Q4_K_M 模型加上 4k 到 8k 的 context。摘要、改寫、翻譯、簡單分類都做得來，寫程式和複雜推理會明顯不夠。想跑更大的模型，llama.cpp 會把裝不下的部分交給 CPU，程式跑得動但速度會掉好幾倍。
16 GB 的 Mac 夠用嗎？
入門夠用。要注意 macOS 預設不會讓 GPU 用滿全部記憶體，這個上限依機型與系統版本落在大約三分之二到四分之三之間，16 GB 的機器實際能給模型的大概在 10 到 12 GB，扣掉系統與其他 App 之後更少。LM Studio 官方也建議至少 16 GB，並註明 8 GB 的 Mac 只能跑小模型並縮短 context。真的要把地端模型當主力，32 GB 起跳會舒服很多。
地端模型是完全免費的嗎？
軟體是。llama.cpp 和 Ollama 都是 MIT 授權，LM Studio 從 2025 年 7 月起連商用都免費，多數開放權重模型也免費下載。但硬體、電費和時間都是實際成本。前面算過，一套三年攤提的主機加電費大約是每月 1,900 元的等級——「免費」指的是授權費，不是總成本。
為什麼 Kimi、DeepSeek 這些開放權重模型還是要付 token 費？
因為付的是運算資源，不是模型授權。權重可以免費下載，但前沿的開放模型動輒上兆參數，光是官方發布的量化權重就有數百 GB（Kimi K2.6 的原生 INT4 版本約 594 GB），個人硬體跑不動，實際上都是透過官方 API 或代管平台使用——那等於租別人的 GPU。看到量化版（例如 Q4）也要付費是同樣的道理：量化改變的是模型大小，不是誰出機器。判斷標準只有一個，就是這次推論跑在誰的硬體上。
量化會讓模型變笨嗎？
會，程度取決於壓到多少位元。Q4_K_M（每參數 4.5 位元）在多數任務上的衰退不明顯，這也是它成為預設的原因；壓到 Q3 以下就開始明顯。沒有辦法給出一個通用的百分比，因為不同任務、不同語言的敏感度差很多。唯一可靠的驗證方式是拿自己真正的工作內容，同一個 prompt 在不同量化版本上各跑幾次比較。
公司要導入，該用 Ollama 還是 vLLM？
看使用人數。只有幾個人、各自在自己的機器上跑，Ollama 最省事。要架成一個內部服務讓多人或多個應用共用，就該用 vLLM——它的 PagedAttention 和 continuous batching 就是為並發設計的，在高並發情境下的吞吐量差距是數十倍等級。中間狀態（五到十人）建議先用 Ollama 試，撞到「並發把 KV cache 吃光、每個人的 context 被迫縮短」這個問題再換。
地端模型可以接進自動化流程嗎？
可以，而且這是它最實用的用法之一。Ollama 在本機 11434 埠提供 REST API，llama.cpp 的 llama-server 提供 OpenAI 相容介面，vLLM 也是 OpenAI 相容。任何能發 HTTP 請求的工具都串得上，包括自架的自動化平台。差別在於不需要 API key、不會產生用量帳單、資料不離開內網。