2026 年部署 RAG 檢索服務需要多少 GPU 顯存

在 2026 年，一個生產級 RAG 檢索服務，在單張 GPU 上以 50 個併發代理、少於 500 萬文件語料為規模，大約會佔用 42 GB 的GPU 顯存，剩餘約 38 GB 可用於 KV Cache。這個數字涵蓋了三個主要的顯存消耗方：一個小型嵌入模型（1–14 GB）、一個 GPU 加速索引，以及 LLM 推理引擎。你的實際需求取決於語料規模、模型選擇、量化方式和併發數。本部署指南提供了容量規劃公式和三種現成配置，用來規劃 GPU 基礎設施，無論你是在美國伺服器上進行伺服器租用，還是部署在其他地區。要理解 RAG 流水線需要多少 GPU 顯存，首先要從這些元件入手。你需要為 LLM 準備一塊獨立 GPU。為嵌入計算單獨使用 GPU 也非常有幫助。LLM 的模型權重和 KV Cache 是最大的顯存消耗方。GPU 加速索引用於儲存嵌入向量，是檢索流水線的一部分；嵌入維度會影響索引大小。KV Cache 為每個會話儲存 Token。在推理過程中，Token 的規劃需要格外謹慎。請使用 2026 年的推理框架來高效管理 Token。本檢索指南包含一套顯存容量規劃指引，幫助你確定部署需要多少 GPU 顯存。

關鍵資訊總結

• 一個標準的、具有 50 個併發代理的 RAG 服務，大約使用 42 GB GPU 顯存。
• 嵌入模型和向量索引合計通常佔用不到 2 GB 的 GPU 顯存。
• LLM 的模型權重和 KV Cache 消耗掉了大部分 GPU 顯存。
• 你可以在三種硬體層級中選擇：入門級、標準級和生產級。
• 在採購更多 GPU 之前，一定要用真實流量對你的部署方案進行測試。

RAG 技術堆疊中的 GPU 顯存分配

你的 RAG 技術堆疊會把 GPU 顯存在三個部分之間進行劃分。其中有兩個部分在 2026 年的體量出乎意料地小：嵌入模型和向量索引加在一起，往往不到 2 GB。這樣你就可以把餘下的大部分顯存留給 LLM。

嵌入模型的顯存佔用

將嵌入模型與 LLM 部署在同一張 GPU 上，在今天通常只需要 1–14 GB 顯存。舊版指南給出的 2–8 GB 估計已經不再準確。現代嵌入模型是緊湊的編碼器，你通常會以 FP16 或 INT8 精度執行它們。嵌入模型與檢索流水線共享上下文，因此不需要為其單獨劃出一大塊顯存。它所產生的單條嵌入向量很小，而模型本身長駐顯存，不會激烈擠佔空間。

向量索引的顯存佔用

向量索引的顯存使用會隨語料規模線性成長。一個實用的經驗值是：在 768 維嵌入下，每 100 萬條向量大約需要 3 GB 顯存。你的 GPU 加速索引會將這些向量長駐 GPU，以支撐快速檢索。在這裡，是否將索引長駐 GPU，還是部分或全部下放到 CPU，會形成重要的效能權衡。

存取模式往往高度偏斜：最熱的 20% 叢集，承擔了約 60% 的 Wiki-All 存取量，以及超過 93% 的 ORCAS 存取量。分層設計會將熱點叢集快取在 GPU，冷資料則放在 CPU。自適應分區策略可以找到一個最優分界點，例如在 400ms SLO 下選擇約 31.5% 的 GPU 常駐比例。這樣的平衡既能保持 LLM 生成效能，又能將在 SLO 約束下的吞吐量提升到 1.5 倍。只要把這兩個消費者保持得足夠精簡，你的 Token 和 KV Cache 就能擁有足夠的空間。

RAG 中的 LLM 推理與 KV Cache

LLM 推理引擎會消耗你絕大多數的 GPU 顯存預算。這部分可以拆分為兩類：模型權重和 KV Cache。理解它們各自的擴展方式，可以讓你根據目標併發數和上下文長度來合理規劃硬體。

按規模劃分的模型權重

你選擇的模型決定了基礎顯存需求，你可以透過量化來縮小模型體積。下表展示了 Llama 3.3 70B 這一在生產 RAG 堆疊中非常流行的模型，在不同量化設定下的顯存範圍。

可以看到，單張 80 GB 顯存的 GPU（例如 H100）足以輕鬆容納 Q4_K_M 量化版本，同時還能留出空間給其他元件。Q3_K_M 版本可以裝入 L40S 48 GB，但品質下滑會非常明顯，因此不建議在高要求的檢索任務中使用 Q3_K_M。更小的模型，例如 Qwen3-8B，在 FP16 下通常只需要 16 GB；其 INT4 量化版本僅需 4–5 GB，非常適合作為低成本的嵌入 + 生成一體化方案。

KV Cache 與併發

模型權重是靜態的，而 KV Cache 會隨著每個活動會話的成長而動態擴張。你必須把這一變數考慮進去，才能在高峰負載下避免顯存 OOM。

KV Cache 總顯存的公式其實很直接：

Total KV cache bytes = 2 × num_layers × num_key_value_heads × head_dim × cached_tokens × active_sequences × bytes_per_element

其中 2 這個係數，來自於 Key 與 Value 張量需要分別儲存的事實。以上文提到的 42 GB 基線為例，在 50 個併發代理的場景下，大約會把其中 38 GB 分配給 KV Cache。假設你使用一個 32 層、8 個 KV 頭、Head 維度為 128、快取 8,000 個 Token 的 LLM，那麼每個序列的每個 Token 大約會佔用 64 KB。將其乘以 50 個代理，會在任何填充或批處理開銷之前，就得到 25 GB 以上的 Cache 體量。

當你計畫支撐 200 個併發使用者時，即使是 7B 參數的模型，其 KV Cache 也可能輕鬆突破 100 GB，這會把你推向多 GPU 節點。此時必須進行多卡分散式部署，不可能再把所有內容都塞進一張卡裡。同時你還要記住，共址的嵌入模型不過消耗 1–14 GB 顯存，因此主要的顯存瓶頸依然是 LLM 的模型權重與峰值併發下的 KV Cache 疊加。

模型與 GPU 顯存的對照參考表

現在你已經理解了模型權重和 KV Cache 的擴展關係。下一步就是把具體模型映射到顯存需求上。下表將 2026 年最常用的一些 LLM 選項匯總成了一張參考表。所有數值都已經包含 15% 的冗餘開銷，但不包含 KV Cache，因此你可以在此基礎上加上自己的併發緩衝量。

8B–70B 的稠密模型

稠密模型仍然是 RAG 檢索服務的預設選擇。每個 Token 都會啟用所有參數，因此模型能力與規模近似線性相關。權衡也很直接：更大的模型需要更多 GPU 顯存，但能提供更強的推理能力。

規律非常清晰：4-bit 量化將顯存佔用壓縮到 FP16 的大約三分之一。這樣的壓縮可以讓 70B 模型從原本需要兩張 GPU 的配置，轉而適配到單卡。更小的稠密模型，例如 Qwen3-8B，在 FP16 下只需要 16 GB 顯存。這些中等規模的模型可以很輕鬆地部署在 L40S 48 GB 上，並且仍有空間用於嵌入模型和向量索引。

MoE 與量化變體

混合專家（MoE）模型會改變顯存的計算方式。MoE 模型會把所有參數都放在記憶體中，但每個 Token 只啟用其中一小部分。你的 GPU 顯存佔用更接近於「總參數量」，而不是「每個 Token 啟用的參數量」。因此，一個 30B 參數量的 MoE 模型和一個 30B 的稠密模型，大致都會需要 60 GB 左右的顯存。真正的差異在於：你把這些 GB 換成了什麼——稠密模型把它們轉化為模型能力，而 MoE 則把它們轉化為吞吐量。

Mixtral 8x7B 很好地體現了這種權衡。該模型總共有 46.7B 參數，但每個 Token 實際只啟用約 12.9B 參數。在 4-bit 量化下，Q4_K_M 構建版本需要 26.44 GB 顯存，最大 28.94 GB 記憶體。只要把部分層 Offload 出去，這樣的體量就可以安裝在一塊 24 GB 的 GPU 上。Mixtral 8x22B 則完全不同，它擁有 176B 總參數，顯存需求迫使你使用擁有 80 GB 以上總顯存的多 GPU 伺服器。

量化的 MoE 變體在「每 GB 吞吐量」上極具優勢。以 Qwen3.5-35B-A3B MoE 模型的 Q4_K_M 版本為例，它僅使用 7.6 GB 顯存，卻可以達到 8.61 Token/s 的生成速度。相同量化下，一個稠密的 Qwen3.5-27B 模型需要 7.7 GB，卻只能達到 3.57 Token/s。該 MoE 架構在 256 個專家中，大約會為每個 Token 啟用 3B 參數；同時只路由 8 個專家再加 1 個共享專家。這樣的設計讓 99 層都能在 GPU 上執行，顯存只需要 7.6 GB，比一個稠密 9B 模型僅多 0.1 GB，卻能提供 2.4 倍的速度。

對於規模較小的部署，Mistral 7B 可以在單塊 8 GB 消費級 GPU 上，甚至在筆電 CPU 上執行。Mistral NeMo 12B 則是單工作站卡中規中矩的中階選擇。當語料與併發都不算龐大時，這些方案可以有效壓低推理成本。

無論是哪種架構，KV Cache 的計算公式都保持不變：你可以用 2 × layers × kv_heads × head_dim × bytes × context × batch ÷ 1e9 進行估算。以帶分組查詢注意力（GQA）的 Llama 3.1 8B 為例，在 FP16 下，每個序列每 1,000 個 Token 大約需要 0.13 GB 的 KV Cache。在 8K 上下文、32 個併發會話下，單 KV Cache 就可以達到約 33 GB。將這一冗餘需求加到前面權重的顯存需求上，才能在真正採購硬體前做出合理決策。

2026 年 RAG 的三種 GPU 配置

入門級、標準級與生產級

你可以將檢索服務與以下三類硬體層級進行匹配。入門級採用單塊 NVIDIA L4 24 GB。這張卡可以執行 7B–14B 的 FP16 模型，顯存佔用大致在 12–16 GB，並能與嵌入模型共存。L4 透過原生 FP8 支援可提供 242 TFLOPS，推理吞吐量是 FP16 的兩倍，是資料中心場景中服務 7B–13B 模型時每 Token 成本最低的 GPU。一個 70B 模型在 4-bit 下大約需要 35 GB 顯存，已經超出了 L4 的 24 GB。若你使用該層級，請務必保持語料規模較小、併發量較低。

標準級使用單塊 L40S 48 GB 或 H100 80 GB，與前文提到的「在單卡上為 50 個併發代理大約佔用 42 GB 顯存」的基線高度匹配。生產級則使用多張 H100 或 H200，以因應 200+ 併發使用者和多個不同用例。具體顯存需求，還要取決於模型大小與併發目標。

每查詢成本對比

每次查詢的成本由 Token 數量與硬體成本共同決定。對輕量負載而言，入門級在價格上更具優勢：單塊 L4 在資料中心級 GPU 中，為 7B–13B 模型提供了最低的每 Token 成本。標準級按小時計價更高，但可以支援更多的 Token/s。生產級則將整體成本攤薄至大量使用者，因而在高吞吐場景下，每次查詢成本反而會降低。在決定上多 GPU 之前，一定要根據自己真實的業務負載做基準測試。

你究竟需要多少 GPU 顯存？兩條容量規劃公式

現在你可以把上面的拆解轉換成兩條公式。第一條用於估算索引顯存，第二條用於估算全域部署的總顯存。

索引顯存公式

從原始向量儲存開始。公式為：vectors × dimensions × bytes-per-value × (1 + overhead) ÷ 1e9 = GB。在每值 4 位元組、10% 額外開銷的假設下，500 萬條向量在 1024 維時需要 20.48 GB 顯存。相同語料在 768 維時僅需 15.36 GB，在 384 維時則只需 7.68 GB。如果將語料翻倍到 1,000 萬條向量，則每個數字也會翻倍，1024 維的顯存需求會達到 40.96 GB。

原始向量還不是全部。實際系統還需要索引結構，例如 HNSW 圖邊或 IVF 倒排列表，這會為每條向量額外增加 10–100+ 位元組。你還需要向量 ID 來把檢索結果映射回文件，通常每個 ID 需要 8 位元組。時間戳、權限、過濾欄位等中繼資料會疊加更多空間。對記憶體配置器開銷、碎片、對齊和填充的預留，則可能再吃掉 5–15%。如果你關心可靠性，還需要做資料副本，這會使總記憶體翻倍。

總顯存公式

接下來把所有消費者加總：Total VRAM = embedding（1–14 GB） + index + model weights + KV cache × concurrency + 10–20% buffer。共址嵌入模型的體量通常非常小，可以視作常數項；索引用上面的公式計算；模型權重則來自於你選定的量化方式；KV Cache 則會隨每個活動會話線性成長。

模型權重的顯存計算可以寫成 (params × bits) / 8，再加上 20% 的冗餘。以 70B 模型在 4-bit 下為例：70 × 4 / 8 = 35 GB，× 1.2 ≈ 42 GB 模型權重。這一體量可以裝入一張 80 GB 的顯存卡。餘下的約 38 GB 就可以作為 KV Cache 預算。這也對應了文章開頭的分配方式：大約 42 GB 被模型及基礎設施佔用，留下約 38 GB 給 KV Cache。

這個 Cache 預算需要涵蓋所有併發代理。例如，Qwen2.5-14B 在 FP16 下，每個併發使用者在 32K 上下文時大約需要 ~1.5 GB 的 KV Cache。8 個併發使用者在 128K 上下文下，單 KV Cache 就可以佔用 ~48 GB。若有 50 個併發代理，你的 38 GB Cache 預算就要被它們平分，這會直接限制每個會話可用的上下文長度。有資料指出，每個 Token 大約需要 800 KB 的 KV Cache，那麼在最壞情況下，一個 p99 請求的 15,700 個 Token 會消耗約 12.5 GB 的 Cache。儘管量化可以壓縮模型權重體積，但面對更長上下文、更大批量和更大模型時，GPU 總顯存仍然是硬性約束。

在購買硬體前，一定要先跑一遍這些數字。它們能告訴你：這套檢索服務是能塞進一張卡裡，還是必須上多卡節點。

用一份檢查清單來規劃你的 RAG 部署：估算語料向量總量、選擇嵌入維度、確定 LLM 規模與量化方式、為峰值併發預留 KV Cache 空間，並預留 10–20% 的冗餘緩衝。

整體範圍是清晰的：私有型 RAG 部署可以塞進 24 GB 顯存；標準化部署，在 50 個併發代理下大約會佔用 42 GB；生產級部署，在 200+ 併發使用者下往往會突破 320 GB 顯存。

忽略驗證是常見陷阱：容量規劃公式給出的只是估算，而不是保證。在擴展到生產環境之前，一定要先在單卡上用接近真實的流量做壓測。

把估算結果當作出發點：先在一塊獨立 GPU 上部署，用真實的提示詞和併發請求進行測試，然後測量實際顯存佔用和延遲，再決定後續擴容策略。

常見問題（FAQ）

入門級方案需要多少 GPU 顯存？

單塊 L4 24 GB 就能執行 7B–14B 的 FP16 模型，並可以在同一張卡上容納嵌入模型。只要保持語料規模較小、併發量較低，這一層級就很適合用於低流量的私有 RAG 部署。

為什麼嵌入模型的顯存佔用這麼小？

現代嵌入編碼器都很緊湊。你通常會以 FP16 或 INT8 精度執行嵌入模型，並讓它與檢索流水線共享上下文。現實中，嵌入側的顯存佔用大多在 1–14 GB，而不是舊指南中提到的 2–8 GB。與 LLM 相比，本指南將嵌入模型的顯存佔用視為「近似可以忽略的常數」。

我可以把向量索引下放到 CPU 記憶體嗎？

可以，這樣做可以為 LLM 騰出更多 GPU 顯存。代價是延遲變高：CPU 檢索耗時可能是 LLM 預填階段的兩倍。分層設計通常會把熱點叢集快取在 GPU、冷資料放在 CPU，本指南推薦這種方式。

併發會怎樣改變我的容量規劃？

KV Cache 會隨著每個活動會話線性成長。在 50 個併發代理的基線下，你會在總 42 GB 佔用之後，剩下大約 38 GB 給 KV Cache。當併發增加到 200 個使用者時，單 KV Cache 就可能輕鬆突破 100 GB，從而逼迫你採用多 GPU 節點。因此要盡量壓縮向量索引在 GPU 上的佔用。

在採購 GPU 基礎設施之前，如何驗證我的容量估算？

先在一塊獨立 GPU 上部署。用真實的輸入提示和併發請求進行測試，測量實際顯存佔用與延遲，並額外預留 10–20% 的碎片與框架開銷。本指南將容量規劃公式視為起點，而不是精確承諾。