RAG 系统的算力规格怎么估

一句话结论

RAG 的算力规划不能只按主模型显存来估。一个可用的企业级 RAG 系统至少要把 数据抽取 / Embedding / 检索 / 重排 / 生成 / 服务层 分开估算，然后再决定是单机部署、分层部署，还是独立集群化。

官方可确认的信息

根据 NVIDIA 对 RAG 的官方说明，完整的 RAG 工作流至少包含三大阶段：

• Data Extraction：数据抽取、清洗、切分、Embedding 与索引
• Retrieval：向量检索、关键词检索、查询改写、重排
• Generation：把检索结果与用户问题一并送入 LLM 生成最终回答

这意味着从系统角度看，RAG 不是“一台跑大模型的机器”，而是一条多组件协同的数据与推理链路。

为什么 RAG 比“单模型部署”更难估

1. 瓶颈不一定在主模型

如果知识库很大、索引频繁更新，系统瓶颈可能出现在 Embedding 和索引构建，而不是生成模型本身。

2. 在线路径是多阶段串联

一次 RAG 请求通常要经过：

• 查询预处理
• 检索
• 重排
• 拼接上下文
• 生成

任何一段耗时过长，都会拖慢整体响应时间。

3. 离线任务和在线任务资源模式不同

离线建库关注的是批量吞吐；在线问答关注的是时延、并发和稳定性。这两者通常不应该用同一条配置逻辑硬凑。

正确的估算方法

第一步：先拆成 5 层

建议至少拆成：

1. 数据抽取与清洗
2. Embedding 与索引构建
3. 检索与重排
4. 生成模型推理
5. API / 网关 / 权限 / 观测层

第二步：分别看资源特征

Embedding 层

• 关注吞吐
• 关注文本长度
• 关注是否需要 GPU 加速

检索与重排层

• 关注索引规模
• 关注召回数量
• 关注重排模型耗时

生成层

• 关注模型大小
• 关注上下文长度
• 关注并发、时延和 KV Cache

第三步：把离线和在线拆开

企业实践中，最稳的方式通常是：

• 离线建库任务单独规划
• 在线问答服务单独规划

不要把“白天在线服务”和“夜间大批量重建索引”全部压在同一台机器上。

工程估算说明

以下不是官方固定规格，而是工程上更稳妥的估算方式：

小型企业知识问答

• 单模型
• 中小规模文档库
• 并发较低

这类场景通常可以把 Embedding、检索和生成放在同一套资源里先跑通。

中型企业 RAG 平台

• 文档规模更大
• 需要权限隔离
• 有更稳定的并发要求

这时建议把：

• 向量库 / 检索
• 生成模型服务

至少做成逻辑分层。

大型企业多租户 RAG

• 多业务线
• 多知识域
• 多模型
• 高频更新

这类场景通常要把 Embedding、检索、重排、生成和服务治理分层部署，并引入缓存、异步任务与审计链路。

你真正需要先测的 4 个指标

1. 单次检索耗时
2. 单次重排耗时
3. 单次生成耗时
4. 峰值并发下的整体响应时间

如果这 4 个指标没有先测清楚，直接买 GPU 往往只会把问题从“估不准”变成“买错了”。

常见误区

误区 1：只看主模型参数量

很多团队只问“用 7B 还是 72B”，但真正决定系统体验的，常常是检索质量和服务链路设计。

误区 2：忽略重排开销

Reranker 往往是提升准确率的重要组件，但它也会带来额外时延和算力成本。

误区 3：把离线和在线混在一起

白天在线服务和夜间大规模重建索引的资源模式完全不同，混在一起会造成性能波动和运维复杂度上升。

RAG 落地评估

正在规划企业 RAG 知识库？

从文档接入、权限边界、向量库、Embedding、重排和模型推理评估落地路径。

评估 RAG 落地方案查看相关方案