llama.cpp 是什麼？本地LLM 部署與 RTX 5090 實測

作者 Nick TasiAds & Code 創辦人·發布 2026-10-23·約 14 分鐘讀完

llama.cpp 是 GitHub 上 ggml-org 維護的開源推論引擎，官方 README 寫它的目標是用最少的設定，在各種硬體上跑大型語言模型，本機和雲端都適用。用法是裝好 llama.cpp、準備一個 GGUF 格式的模型檔，再用 llama-server 開出 OpenAI 相容的 API，你的程式就能用呼叫雲端 AI 的寫法，呼叫自己電腦上的本地LLM。

2026 年 9～10 月，我們自己的測試與研究用的是本團隊一台 RTX 5090 32GB 主機，實測結果是：Qwen3.8-27B 的 Q6_K 量化檔每秒產生 57.9 個 token；同一版 llama.cpp 打開 MTP 推測解碼後，同一個短文任務從每秒 61 個 token 提高到 134 個，輸出逐字相同。這些數字都出自同一台主機，換顯示卡或換版本，結果會不一樣。

llama.cpp 是什麼？

llama.cpp 是 GitHub 上 ggml-org 維護的開源推論引擎，可以免費使用。它用純 C/C++ 寫成、不依賴其他套件，支援 1.5 到 8 位元的整數量化來縮小模型；NVIDIA、AMD、Apple 晶片和一般 CPU 都能跑，模型比 VRAM（顯示卡記憶體）大時，也能一部分放顯示卡、一部分交給 CPU。

名字裡的 cpp 指的就是 C++，README 開頭的標語是「LLM inference in C/C++」。它只讀 GGUF 格式的模型：官方模型說明 寫明 llama.cpp 要求模型存成 GGUF 檔，其他格式可以用專案裡的 convert 腳本轉換，Hugging Face 上也有大量現成的 GGUF 量化檔可以直接下載。

GitHub 官方文件列的基本規格：

伺服器的完整功能列在 llama-server 說明文件，包括多人同時連線的平行解碼、連續批次處理和推測解碼。推測解碼正是 MTP 加速的基礎。

本地LLM 要多大的顯示卡？RTX 5090 實測數據

要看模型大小、量化程度和上下文長度三件事。以我們 2026 年 9～10 月自己的測試與研究（RTX 5090 32GB）：Qwen3.8-27B Q6_K 檔案 22.43GB，上下文開 64K 時 VRAM 用到 25.9GB，192K 用到 30.9GB；Qwen3-8B Q4_K_M 全放顯示卡約 6.3GB，Qwen3-4B 約 3GB。

速度方面，27B 在這張卡上每秒產生 57.9 個 token，讀取輸入每秒 2,999 個。token 是模型切文字的單位。我們讓模型輸出一篇 4,186 字的繁體中文長文，用掉 3,499 個 token，大約每個中文字 0.84 個 token，估算長度時可以拿來換算。

同一個模型檔，Hugging Face 寫 22.43GB、Windows 檔案總管寫 20.89GB，差在單位：前者 1GB 算 10 億位元組，後者把 1,073,741,824 位元組當成一個 GB。估 VRAM 夠不夠的時候，兩邊要換成同一種單位再比。

網路上有人說 RTX 5090 跑 27B 每秒可以到 157 個 token，我們用 Q6_K 測不出這個數字；也有第三方文章寫每秒 30～35 個，對照實測又太保守。速度數字要跟模型、量化和上下文設定放在一起看。

VRAM 不夠的時候，Windows 上不一定會跳出錯誤。官方編譯說明 的 CUDA 段提到，NVIDIA 控制面板裡有一個 System Memory Fallback 設定，VRAM 用完時改用系統記憶體，而不是直接當掉；我們這台主機碰到時的症狀是不報錯、只變慢。文字模型、產圖和影片怎麼分用同一張卡，寫在地端 AI 主機的規格與實測；ComfyUI 那邊爆 VRAM 怎麼處理，寫在 ComfyUI 教學。

MTP 推測解碼：同一張卡快一倍以上

MTP（多 token 預測）推測解碼，是讓模型每一步先多猜幾個 token，再一次驗證，猜對的直接收下。我們 2026 年 10 月 21 日在同一版 llama.cpp 加上 --spec-type draft-mtp 測試，同一個短文任務從每秒 61 個 token 提高到 134 個，四組輸出的雜湊完全相同，VRAM 只多 1GB。

Qwen3.8-27B 官方模型頁 寫明這個模型訓練時就帶有多步 MTP。測試條件：32K 上下文、KV 快取 q8_0、關閉思考、固定種子 42，每組輸出 201 個 token，VRAM 從 24.6GB 變 25.6GB。只測了 1 篇短文，換成長文、寫程式或別的模型，命中率要自己再量。每次多猜幾個，新版官方參數叫 --spec-draft-n-max，llama-server 說明文件 寫預設是 3，--spec-type 的可選值裡也列了 draft-mtp。

猜得越多，命中率越低，但這次的總速度還是一路往上，多猜 3 個時是關閉時的 2.2 倍。輸出沒變，是因為猜錯的 token 會在驗證時被丟掉，不會混進答案；四組雜湊相同，就是這次實測的對照證據。

要確認 MTP 真的有開，看伺服器記錄：要出現 creating MTP draft context 和 draft acceptance = … 這兩行。如果只看到 unused tensor blk.64.nextn ... ignoring，只代表啟動時沒加參數，不代表這個模型或這版 llama.cpp 不支援。MTP 也會吃 VRAM，這次多了 1GB，上下文已經開到接近塞滿的話，要先留出這個空間。

如何在 Windows 上安裝 llama.cpp？

Windows 上最省事的做法，是到官方 GitHub 釋出頁下載預先編好的版本。以 2026 年 10 月 23 日的 b11836 為例，Windows x64 有 CPU、CUDA 12、CUDA 13、Vulkan、SYCL、ROCm、OpenVINO 幾種版本，NVIDIA 顯示卡選 CUDA 版，旁邊附有對應的 CUDA DLL 壓縮檔。

想自己編譯，官方編譯說明 是先裝好 CUDA Toolkit，再用 CMake 加 -DGGML_CUDA=ON 編。官方 README 列的其他裝法還有官方安裝腳本和 Docker。釋出頁 的版號是 b 開頭往上編，更新很頻繁，2026 年 10 月 23 日這天就出了 b11835 和 b11836 兩版，照著網路教學操作時，參數名稱要以當下版本的說明文件為準。

我們的做法是這樣：主機上裝的是 b10930 版，用 CUDA 13.3 編譯，配合 RTX 5090 的 Blackwell 架構；llama-server 交給 Windows 工作排程器常駐、開機自動啟動，27B 由排程啟動約 12 秒就能接請求。判斷有沒有起來，看 VRAM 用量和 /health 的回應，不看排程顯示的狀態。

llama.cpp 怎麼用？參數要照模型官方建議

llama.cpp 的用法是先用 llama-server 載入模型，開出 OpenAI 相容的 API，再讓程式照呼叫雲端 AI 的格式送請求。程式本身改動不大，要注意的是參數：Qwen3 系列預設開著思考模式，不處理的話 token 會全部花在思考內容，回覆正文變成空字串，看起來像模型壞了；輸出上限、取樣參數和思考力度，也都要照模型官方的建議設。

我們碰過的四種情況，和對應要調的參數：

思考模式。 Qwen3.8-27B 官方模型頁 寫明思考模式預設開啟，可以逐次請求關掉；llama-server 支援把思考內容放在 reasoning_content 欄位回傳，所以思考把 token 用光時，正文就是空的。我們在舊桌機跑 MoE 推理模型時，思考開著，1,600 個 token 全花在思考、答案空白；寫程式的任務改用 chat_template_kwargs: {enable_thinking: false}，就直接出程式碼。伺服器端也可以用官方參數 --reasoning off 整個關掉。

輸出上限。 一篇 4,186 字的繁中長文用掉 3,499 個 token，上限設 4,000 時已經用掉 87%，再長一點就會被截斷，而且不會報錯。我們改成用 max(4000, 字數×1.2＋512) 推算上限，並偵測回應裡的 finish_reason: length；把上限故意壓到 64 做負面測試，確認截斷真的擋得下來。

取樣參數。 我們評測 27B 時，一開始自訂 max_tokens 8,192、溫度 0.6，有兩題寫到上限沒交卷；改用 Qwen3.8 官方的思考模式參數（temperature 1.0、top_p 0.95、top_k 20、min_p 0），上限拉到 30,000 後，這兩題各只用 1,418 和 4,702 個 token 就答對。

思考力度。 官方模型頁列了 xhigh、medium、low 三種 reasoning_effort，xhigh 是預設，llama-server 也有對應的 --reasoning-effort 參數。我們在 125B 混合專家模型那組測試裡，有一題在思考進度 5.8% 時就算出正確答案，剩下 94% 都在驗算，到 58K 上限還沒交卷；改成 medium 後 2 分鐘答對，但寫程式的題目變粗心，出現先呼叫、後定義的錯誤。

上下文要開多長？太短時只會看到 400

上下文長度（llama-server 的 -c）決定模型一次能讀多少 token，開太短時，客戶端通常只看到一個看不出原因的錯誤。我們有個服務原本設 -c 8192，一篇長文換算是 9,412 個 token，直接被伺服器拒絕，客戶端只顯示 HTTP 400，要讀伺服器記錄才知道是上下文不夠；改設定之後，VRAM 只從 22.3GB 變成 22.5GB。

伺服器記錄寫的是 request (9412 tokens) exceeds the available context size (8192 tokens)。我們改成 -c 32768 --parallel 1 -fa on --cache-type-k q8_0 --cache-type-v q8_0：上下文開到 32K、一次只處理一個請求、開 Flash Attention，KV 快取改用 q8_0，VRAM 只多 236MB。這個服務的設定跟前面 64K～262K 那組不同，兩組數字不要互相換算。

程式代理也會碰到同樣的事。VS Code 的程式代理 Cline 每一輪會送約 19,000 個 token 的系統提示，伺服器設 -c 16384 直接回 400，要開到 32,768 才跑得動。

不設 -c 的話，官方說明 寫預設是 0，代表照模型本身的長度。Qwen3.8-27B 官方標的原生長度是 262,144 個 token，就是我們量到剛好塞滿 32GB 的那一檔，而且那是 KV 快取用 q8_0 的結果，官方預設的 KV 型別是 f16。顯示卡比較小，就要自己把 -c 設小。

16GB 顯示卡怎麼跑？MoE 模型與加速參數

顯示卡只有 16GB 時，我們的做法是改跑混合專家（MoE）模型，再把一部分專家權重留在 CPU。舊桌機（AMD RX 9070 XT 16GB）跑 Qwen3.6-35B-A3B Q4_K_M，加上四個加速參數之後，讀取提示從每秒 215 個 token 變 702 個，重複內容命中快取時從 14.3 秒縮到 0.4 秒，產生速度從每秒 27 個變 37 個。

完整寫法是 --n-cpu-moe 28 --cache-reuse 256 -np 1 -b 4096 -ub 1024。

加速最明顯的是讀取：提示讀取快 3.3 倍，重複內容命中快取時每秒 25,800 個 token，省下 97% 的時間。產生速度的提升比較小，從每秒 27 個到 37 個。16GB 卡跑 MoE 和跑密集模型的速度差，整理在地端 AI 主機那篇。參數說明都出自 llama-server 說明文件，不同版本的預設值可能會變。

大模型一定比較強嗎？27B 和 125B 同題對照

不一定。我們 2026 年 9 月 30 日用同一批題目，比較 llama.cpp 上的密集模型 Qwen3.8-27B Q6_K 和一個 125B 的混合專家模型（每個字只用到 6B 參數，壓成 IQ3_XXS，約 3 位元）。推理 12 題、程式 8 題兩邊全對；推理難題 27B 10 題全對、125B 對 8 題；一道自己出的 6×6 邏輯謎題只有 27B 解出來。

在這組題目裡，125B 壓到約 3 位元之後沒有贏 27B，還要先停掉文字模型和產圖才跑得動。想換更大的模型，先拿自己的題目對照再決定。125B 那組是用另一套推論引擎 Strata 跑的，它一次只處理一個請求，不串流的請求在客戶端斷線後也不會停，會一直算到上限；測試時中途放棄的請求，要確認伺服器那邊真的停了。

本地LLM 還能做什麼？翻譯、程式代理與判斷小模型

在我們自己的測試與研究裡，除了 27B，也試過幾種其他模型的用法。翻譯用 Qwen3-8B Q4，用純 CPU 一句約 2 秒、不用付 API 費；程式代理接 VS Code 的 Cline，能完成簡單到中等的除錯；另有一個 0.8B 的判斷小模型 kev-0.8b，單題判斷約 60 毫秒，信心高的題目自己收，信心低的才交給大模型，大模型的呼叫少了 48%。

翻譯：8B 夠用，4B 會漏

Qwen3-8B Q4 用純 CPU 跑（-ngl 0，完全不碰顯示卡），一句約 2 秒、零費用，取代原本的付費翻譯 API。4B 會把句子壓短、漏掉細節；8B 偶爾夾雜簡體字，要逐段兜底，抓到再重翻。

程式代理：簡單到中等的除錯可以

舊桌機上的 35B MoE 模型接 Cline，能完成讀程式碼、執行、修改、驗證這一整輪的簡單到中等除錯，7 項邊界壓測全過；複雜任務的工具呼叫會崩。

0.8B 判斷小模型：先分流，再交給大模型

kev-0.8b 用 bf16 約佔 1.6GB，跑在 PyTorch 上，不是 llama.cpp。它專門做是非判斷，例如一段文字符不符合某個條件，2026 年 9 月 22 日的實測：

它的輸入上限約 4,700 個 token，長文一定要切段問，整篇丟進去會漏抓。同一題連問 20 次結果完全一樣，所以能拿來當建置時的自動檢查；算數和比日期是弱項，日期要改成從文字裡抽出來再比的問法。

踩過的坑：現象、原因、怎麼修

我們 2026 年 8～10 月在兩台 Windows 主機上跑本地LLM，碰過的問題多半不在模型本身，而在排程、遠端連線和編碼這些周邊工具，症狀卻很像模型品質差或伺服器壞了。最常見的三種，是 SSH 斷線把伺服器一起帶走、排程顯示在執行但模型沒起來，以及遠端失敗卻回結束碼 0。

SSH 一斷，伺服器跟著停 現象：從遠端用排程啟動 llama-server，SSH 一斷線，伺服器就結束，結束碼 3221225786（0xC000013A）。 原因：排程動作寫成 cmd /c xxx.bat，斷線時被當成按了 Ctrl+C。 怎麼修：排程動作直接指向 llama-server.exe，並設定失敗時重啟 5 次。

整台主機的記憶體被吃光 現象：遠端測試幾次之後，64GB 系統記憶體用完，整台癱瘓。 原因：llama-cli -n 0 會進互動模式等人輸入，不會自己結束，重複執行就一個個堆著。 怎麼修：遠端只用 llama-server，不用 llama-cli。

排程顯示在執行，模型卻沒起來 現象：排程狀態看起來正常，送請求卻沒有回應。 原因：排程設定成工作已在執行時就不啟動新的，上次殘留的殭屍任務讓這次的啟動指令被靜默忽略。 怎麼修：看 VRAM 用量和 /health，官方說明 寫載入中回 503、準備好回 200，不看排程狀態。

遠端失敗，看起來像模型品質差 現象：回來的答案對不上這次的問題。 原因：SSH 對 PowerShell 的錯誤一律回結束碼 0，遠端其實失敗了，腳本卻把上一輪留在遠端的回應檔當成這次的答案。 怎麼修：每次跑之前先刪掉遠端的回應檔，跑完確認它重新出現。

遠端指令裡的中文讀壞 現象：指令含中文、空格或引號時，遠端執行結果不對，還會吃掉下一行輸出。 原因：.ps1 檔裡的中文會被 PowerShell 5.1 用系統編碼讀壞。 怎麼修：指令寫成 .ps1，轉成 UTF-16LE 再轉 base64，用 powershell -EncodedCommand 送過去。

curl 送中文回 500 現象：用 curl 送含中文的請求，伺服器回 500 ill-formed UTF-8。 原因：Windows PowerShell 的 curl 其實是 Invoke-WebRequest 的別名；在 cp950 主控台送中文，問題出在送出端的編碼，伺服器沒壞。 怎麼修：一律打 curl.exe，看到 ill-formed UTF-8 先查主控台編碼。

頭一次請求慢到像當機 現象：舊桌機的 MoE 模型，頭一次請求等了 118.8 秒才吐出 4 個 token。 原因：冷啟動。用 mmap 載入時 /health 3 秒就回 200，我們的判斷是權重要到真正用到時才讀進來。 怎麼修：第二次請求起就正常，不要用頭一次的速度判斷模型壞了。

多個工作的結果互相蓋掉 現象：同時跑好幾個工作，拿回來的結果混在一起。 原因：大家共用遠端同一個暫存請求檔和回應檔。 怎麼修：改開 SSH 通道直接打 API，不經過暫存檔，一段約 4 秒。

自己寫的中介層讓客戶端報錯 現象：在 llama-server 前面加一層自己寫的 OpenAI 相容中介層，客戶端報 Invalid API Response，或 JSON 黏成一團。 原因：中介層自己組了簡化版的 SSE 串流，少了 finish_reason、id、role、index 這些欄位，或把事件之間的空行吃掉。 怎麼修：串流原樣透傳，不要自己重組。

顯示卡沒在用，torch 變回 CPU 版 現象：判斷小模型的 Python 環境明明裝了 CUDA 版 torch，跑起來只用 CPU。 原因：套件工具 uv 會照鎖定檔把 torch 換回 CPU 版，uv pip install 修不好。 怎麼修：在 pyproject.toml 釘 cu128 的套件索引，驗收看 torch.cuda.is_available() 回 True。

我們的方案：AI 影片製作與自動化工具

我們提供兩種服務：AI 影片製作，以及把重複工作寫成程式的客製自動化。AI 影片按支計價，單支 15 秒 $100 USDT、30 秒 $180 USDT、60 秒 $300 USDT，每支含 2 輪修改；也有月包 Starter $350 USDT，每月 4 支 15 秒額度。客製工具或自動化，例如資料整理、內容檢查、排程通知，依功能報價，評估不收費。

AI 影片的版位、字幕與修改規則在 AI 影片製作服務；客製工具與自動化看 自動化開發。

常見問題

llama.cpp 名字裡的 cpp 是什麼意思？ cpp 指的是 C++。官方 README 的標語是 LLM inference in C/C++，整個引擎用純 C/C++ 寫成、不依賴其他套件，所以能編譯到不同的作業系統和硬體上。

llama.cpp 要錢嗎？ 不用。llama.cpp 是開源軟體，可以免費下載使用；硬體和電費則是自己的成本。

本地llm 要多大的顯示卡？ 要看模型和上下文長度。在我們自己的測試裡，Qwen3.8-27B Q6_K 開 64K 上下文就用掉 25.9GB VRAM，用的是 32GB 的 RTX 5090；Qwen3-8B Q4_K_M 約 6.3GB、Qwen3-4B 約 3GB，需求小很多。只有 16GB 的卡，可以改跑 MoE 模型，把部分專家權重放到 CPU。

llama.cpp 可以用 AMD 顯示卡嗎？ 可以。官方 README 列出 AMD 顯示卡走 HIP，也支援 Vulkan；Windows 釋出頁有 Vulkan 和 ROCm 的預先編譯版。我們的舊桌機就是 AMD 16GB 顯示卡，用 Vulkan 版跑 MoE 模型。

用 llama.cpp 跑本地模型，程式要改很多嗎？ 通常不用改很多。llama-server 提供 OpenAI 相容的 API，原本呼叫雲端的程式多半換掉網址和模型名稱就能接上；真正要改的是參數，例如 Qwen3 系列要處理思考模式、照官方取樣參數設定，輸出上限也要依內容長度推算。

開 MTP 推測解碼會讓答案變差嗎？ 在我們那次測試沒有。同一個短文任務、固定種子，關閉 MTP 和每次多猜 1、2、3 個 token 的四組輸出雜湊完全相同，速度從每秒 61 個 token 到 134 個；這只測了 1 篇，長文或其他模型要自己再對照。