前言

你在布署 LLM 時，也遇過這些疑惑嗎：

• 需要多少 GPU VRAM 才夠？
• 可以支持多少人 "同時" 使用？
• KV Cache 的 VRAM 佔用該如何計算？

最近在公司內要布署 Qwen3.6-27B (FP8) 模型，所以想知道推論時需要多少 GPU VRAM 才夠，我將查資料並計算出來的過程整理成此篇文章。

就讓我們一起來了解一下吧~

在文章一開始，有幾點要先補充說明：

• Qwen3.6-27B 採用混合架構 (Gated DeltaNet 線性注意力 + Gated Attention 全注意力，3:1)，所以 KV Cache 比同尺寸的傳統全注意力 Transformer 模型小很多 (降低了 75%)，Context Length 越長差異就會很明顯。
• 以下以 Qwen3.6-27B-FP8 為例，如果是 BF16/FP16 原生精度，占用大小要再 x2。
• KV cache dtype 預設 BF16，如果改成 FP8，占用數值可再砍半。

需要多少 VRAM？

需要的 VRAM 主要分成四個部分：模型權重、框架開銷、Recurrent State、KV Cache。

以 Qwen3.6-27B-FP8 模型為例：

• 模型權重 (Model Weights)：約 30.9 GB
• 框架消耗：粗估抓個 3 GB 左右
• Gated DeltaNet 線性注意力的「Recurrent State」：固定大小，而且很小 (以下計算)
• Gated Attention 全注意力的「KV Cache」：隨著 Context Length、精度而有所不同 (以下計算)

前面有提到，Qwen3.6-27B 採用混合架構 (Gated DeltaNet 線性注意力 + Gated Attention 全注意力) 共有 64 層，其中 48 層線性注意力 + 16 層全注意力。

Gated DeltaNet 線性注意力的「Recurrent State」

Gated DeltaNet "不會" 隨著 context 長度而增加，而且全部層加起來也不到 100 MB，所以佔總用量的很小部分而已。

總共 Recurrent State 大小：

= num_V_heads x head_dim_k x head_dim_v x bytes_per_element x num_deltanet_layers
= 48 x 128 x 128 x 2 bytes(BF16) x 48 層
= 786,432 elements/層 x 2 bytes x 48 層
= 1,572,864 bytes/層 x 48 層
= 75,497,472 bytes
≈ 72 MB

Gated Attention 全注意力的「KV Cache」

Gated Attention 全注意力就會隨著 context 長度而增加，這也是 KV Cache 會較大的原因。

全部 Attention 層合計 KV Cache 大小 (一個 token)：

= 2 (K 和 V) x num_KV_heads x head_dim x bytes_per_element x num_attention_layers
= 2 x 4 x 256 x 2 bytes(BF16) x 16 層
= 2,048 elements/層 x 2 bytes x 16 層
= 4,096 bytes/層 x 16 層
= 65,536 bytes
≈ 64 KB

看起來超小對吧，但可別忘了，KV Cache 會隨著 context 長度而增加，以上是單一個 token 的 KV Cache 大小。
看你送進來的 context 多長，就要再乘上幾：

= 64 KB x context_length

* 以上 V heads、head_dim_k、num_KV_heads、…之類參數的數值可以從模型官方說明文章或模型設定檔內找到。

所以 Qwen3.6-27B-FP8 總消耗 VRAM 大約是：

= 模型權重 + 框架消耗 + Recurrent State + KV Cache
= 30.9 GB + 3 GB + 0.072 GB + (0.064 GB x context_length)
≈ 34 GB + (0.064 GB x context_length)

例如不同的 context_length 長度：

* 我自己透過 OpenCode 在用，起始大概就 10 幾 K (Harness 框架的 system prompt、tool、skill…等等)，單一 Session 的 Context Length 要到達 100 K 也是很有可能的事~

以下列出一些常用來執行 LLM 的 GPU/主機 供參考 (括號內為 VRAM 大小)：

• RTX 4090 (24GB)
• RTX 5090 (32GB)
• RTX 6000 Ada (48GB)
• RTX PRO 6000 (96GB)
• H100 (80GB)
• H200 (141GB)
• Mac mini (24GB / 32GB / 64GB)
• Mac Studio (36GB / 96GB / 256GB / 512GB)
• NVIDIA DGX Spark (128GB)

因為 Qwen3.6-27B-FP8 模型本身權重就約 31 GB 了，所以如果你的 GPU 在 32GB 以下 (例如 4090、5090)，是無法運行此模型。
除非改用更低量化版本 (例如 INT4)，或多張 GPU，再或者用 GPU + CPU 混合 (llama.cpp / Ollama) 的方式。

可以支持多少人 "同時" 使用？

以上的計算我們都是以 Batch Size = 1 為例 (同時一個人)，也就是如果需要 "同時" 給多個人使用，或自己 "同時" 會執行多個推論，則就還要再乘上 Batch Size。

至於能支援多少併發推論人數，也取決於使用者的 Context Length (也就是影響 KV Cache)。

例如同時有五個人在使用，每個人送出的 Context Length 為 32K tokens：

= 模型權重 + 框架消耗 + (Recurrent State x Batch Size) + (KV Cache x Batch Size)
= 30.9 GB + 3 GB + (0.072 GB x 5) + (2 GB x 5)
= 30.9 GB + 3 GB + 0.36 GB + 10 GB
≈ 44 GB

再例如同時有五個人在使用，但每個人送出的 Context Length 提升到 128K tokens：

= 模型權重 + 框架消耗 + (Recurrent State x Batch Size) + (KV Cache x Batch Size)
= 30.9 GB + 3 GB + (0.072 GB x 5) + (8 GB x 5)
= 30.9 GB + 3 GB + 0.36 GB + 40 GB
≈ 74 GB

可以看到「模型權重」是固定的，「框架消耗」也差異不大，「Recurrent State」可忽略，主要就是「KV Cache」的變動。

我們再來看看，
假如我們超有錢，再加上廠商大發慈悲，願意出貨給我們一張新台幣約 150 萬的 H200 (141 GB)，可以同時支援多少人使用。

依照剛剛的計算，總共 141 GB 扣掉基本的固定消耗後，剩下約 107 GB 留給 KV Cache (141 - 30.9 - 3)，依照不同的 Context Length，可以算出以下表格：

* 此表計算有忽略 Recurrent State，如果併發人數較多，Recurrent State 也是會佔一點 VRAM。例如 100 人會占用 0.072 GB x 100 = 7.2 GB。

不過通常要留一些 VRAM 給像是 CUDA Runtime、Driver或系統其他服務，vLLM 有個 --gpu-memory-utilization 參數 (預設 0.9，也就是 90%)，指的是允許 vLLM 使用多少 VRAM。

假如我們設定 --gpu-memory-utilization 0.95 的話，等於 141 GB x 0.95 = 134 GB 扣掉基本的固定消耗後，變成剩下約 100 GB 留給 KV Cache，依照不同的 Context Length，以上表格會有些微的調整：

補充

以上是以 BF16/FP16 精度(預設) 計算，如果將其降為 FP8 (--kv-cache-dtype fp8)，可以降低一半的 VRAM 占用 (併發人數 x2)。

如果有開啟 MTP (例如 {"method":"qwen3_next_mtp","num_speculative_tokens":3})，雖然會讓最大並發數稍稍下降 5-10%，不過推論生成速度可以提升不少，建議開啟~

強烈建議開啟 Prefix Caching 共享前綴快取 (--enable-prefix-caching，vLLM 預設開啟)，如果新來的 request 跟之前某個 request (或同一個 session 的前幾輪) 有相同的開頭，則這段 prefix 的 KV Cache 不用重新跑一次 prefill，直接拿之前計算好存在 VRAM 裡的結果來用，可以節省 TTFT (首字延遲時間) 和這部分 GPU 算力。

釐清：
KV Cache 解決「同一輪對話中，生成下一個 Token 時不需要重新算前面的 Token。」
Prefix Caching 解決「跨輪次、跨請求、跨不同使用者，如果前綴內容相同，直接重用先前算好的 KV Cache。」

如果完全不使用視覺 (圖片/影片)，可加上 --language-model-only 參數，稍微節省 vision encoder 的權重佔用 VRAM (但只有節省 1~2 GB 左右，差異不大) 和多模態分析 (multimodal profiling)，把省下來的 VRAM 留給更多 KV cache。

vLLM 參數說明可參考官方文章：https://docs.vllm.ai/en/latest/configuration/engine_args/

結語

以上計算結果跟你想像的有落差嗎？

經過這次找資料、詢問 AI，也讓我稍微搞清楚 LLM 所需 VRAM 和 KV Cache 的計算方式了，希望也能讓你對此有些概念。

對於生成式 AI 感興趣的讀者，歡迎追蹤 FB 粉專『 IT空間 』，避免錯過最新的發文通知呦~🔔

參考：
Qwen3.6-27B-FP8 | Hugging Face
vLLM Engine Arguments

「速度比完美重要。」
越想等到完美，越容易停在原地。
反而是那些願意先跨出去的人，邊做邊學，邊錯邊改，最後走得比想像中還遠。

—— 黃仁勳 (NVIDIA 共同創辦人暨執行長)