實用工具
結果
結果會顯示在這裡。一個模型能不能在你的顯示卡上跑，取決於三個數字：量化後的權重、隨上下文長度增加的 KV 快取，以及執行環境本身的緩衝區。這個計算器針對 24 個熱門的開放權重模型——Llama、Qwen、DeepSeek-R1 蒸餾版、Mistral、Gemma 和 Phi——在任意 GGUF 量化、上下文長度與平行序列數下算出這些數字，演算方式依照 llama.cpp（ggml-org/llama.cpp，MIT）以及建立在它之上的 Ollama、LM Studio 等工具配置記憶體的方式。架構參數讀自各模型在 Hugging Face 上的 config.json。
它是怎麼運作的
- 權重 = 參數量 × 該量化的有效每權重位元數，數值取自 llama.cpp 的 quantize 工具所列的檔案大小：Q4_K_M 平均是 4.9 位元而不是 4 位元，因為 K 量化會讓部分張量保持較高精度。
- KV 快取 = 2 × 層數 × KV 頭數 × 頭維度 × 快取的 Token 數 × 每個元素的位元組數，因此分組查詢注意力（GQA）、快取類型和上下文長度都會反映在其中。Gemma 2 和 3 的滑動視窗層永遠只快取視窗內的內容。
- 額外開銷是 CUDA 或 Metal 上下文的 0.5 GB，加上依 llama.cpp 預設 512 Token 微批次大小計算的運算緩衝區，這也是詞彙表較大時記憶體會增加的原因。
- GPU 表中，使用率低於 90% 的顯示卡標為 ✓，介於 90% 到 100% 標為 ≈，放不下則標為 ✗ ×N，N 是分割模型所需的同款顯示卡數量；Mac 以統一記憶體的約四分之三計算，這是 macOS 預設允許 GPU 使用的比例。
你的資料去了哪裡
哪也沒去。本工具完全在你的瀏覽器裡執行：你貼上的文字由頁面處理，不會傳輸到任何伺服器，也不會寫進任何紀錄。
本工具免費且免登入，執行結果只存在於你目前的頁面裡，不會被儲存到任何地方。
它要花多少
本工具完全免費，不需要登入，也不消耗點數。
常見問題
- 估算有多準？
- 在單張 GPU 且所有層都卸載到 GPU 的情況下，權重與 KV 快取和 llama.cpp 實際配置的數量相差只有幾個百分點；以 Llama 3.1 8B、Q4_K_M、8,192 Token 為例，工具算出 4.58 GiB 權重和剛好 1 GiB 的 KV 快取，與 llama.cpp 回報的數字相同。請替驅動程式、桌面環境和其他程式預留 5–10% 的餘裕。
- 平行序列是什麼意思？和 Ollama 的上下文有什麼關係？
- 它是伺服器同時保留的對話數量，每個對話各有自己的 KV 快取：在 Ollama 中是 OLLAMA_NUM_PARALLEL，在 llama-server 中是 -np。上下文欄位是以每個序列計算的，所以 8,192 × 4 會快取 32,768 個 Token；換成 llama-server 的參數就是 -c 32768 -np 4。
- KV 快取該量化嗎？
- q8_0 能把快取減半，品質損失小到難以測量，對長上下文來說很划算；q4_0 能減到四分之一，但可能明顯影響品質。在 llama.cpp 中，量化 V 快取需要 flash attention，支援的 GPU 會自動開啟；本估算一律假設 flash attention 已開啟。
- 為什麼會出現原生上下文的警告？
- 每個模型都只訓練到某個長度——Qwen3 是 40,960 Token，Llama 3.1 是 131,072。超過之後記憶體估算依然成立，但模型必須靠 YaRN 之類的 RoPE 縮放才能運作，品質通常也會下降，所以超過時工具會提醒你。
背後的開源專案
本工具是獨立實作，並未打包第三方函式庫。ggml-org/llama.cpp（MIT）在程式碼層面做的是同一件事——如果你需要在自己的程式裡實作它，從那裡開始，而不是呼叫一個網頁。
ggml-org/llama.cpp也常被稱作
- llm vram 計算
- 顯示卡記憶體 需求
- 本地跑 llama 需要多少 vram
- gguf vram
- kv cache 計算
- ollama 顯示卡需求