Qwen 3.6 27B 推論需要多少 GPU VRAM？包含 KV Cache 的算法

jia@jiatool.com (Jia) — Sun, 26 Jul 2026 13:45:00 +0800

前言

你在布署 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 長度：

Context Length (上下文長度)	KV Cache (BF16/FP16)	總 VRAM 需求
8K (8,192 tokens)	~0.5 GB	~34 GB
32K (32,768 tokens)	~2.0 GB	~36 GB
64K (65,536 tokens)	~4.0 GB	~38 GB
128K (131,072 tokens)	~8.0 GB	~42 GB
262K (262,144 tokens)	~16.0 GB	~50 GB

* 我自己透過 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，可以算出以下表格：

Context Length (上下文長度)	KV Cache (BF16/FP16)	最多併發人數
8K (8,192 tokens)	~0.5 GB	214 人
32K (32,768 tokens)	~2.0 GB	53 人
64K (65,536 tokens)	~4.0 GB	26 人
128K (131,072 tokens)	~8.0 GB	13 人
262K (262,144 tokens)	~16.0 GB	6 人

* 此表計算有忽略 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，以上表格會有些微的調整：

Context Length (上下文長度)	KV Cache (BF16/FP16)	最多併發人數
8K (8,192 tokens)	~0.5 GB	200 人
32K (32,768 tokens)	~2.0 GB	50 人
64K (65,536 tokens)	~4.0 GB	25 人
128K (131,072 tokens)	~8.0 GB	12 人
262K (262,144 tokens)	~16.0 GB	6 人

補充

以上是以 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 共同創辦人暨執行長)

GPU on IT 空間

Qwen 3.6 27B 推論需要多少 GPU VRAM？包含 KV Cache 的算法

前言

需要多少 VRAM？

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

補充

結語