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% 的碎片与框架开销。本指南将容量规划公式视为起点，而不是精确承诺。