搭建本地知识库问答，先别急着堆显卡：真正影响体验的还有模型大小、上下文长度、并发请求，以及文档检索和重排。规划大模型本地知识库问答系统的计算节点配置时，单卡通常更简单，多卡则适合显存或吞吐需求超出单卡能力的场景。
可以把一次问答拆成两部分看：RAG（检索增强生成）先从向量数据库取回相关文本，再交给生成模型组织答案。计算节点需要承载哪些环节，取决于是否把 embedding 模型、重排序模型也放在本机运行。
先确定负载，再估算资源
模型与上下文决定显存底线
显存不仅用于存放模型权重，还要容纳运行时开销和对话上下文对应的 KV 缓存。模型量化方式、推理框架、上下文长度和并发数都会改变实际占用，因此不要只按模型文件大小选卡。对量化后的中小型模型、短上下文和低并发，单卡 16—24GB 显存可作为评估起点；模型更大、上下文更长或需要多个请求同时生成时，通常要考虑更大显存或多卡方案。这些范围是初筛参考，最终应以目标软件栈的实测为准。
别把检索资源都算到 GPU 上
向量检索的主要压力常在内存、存储和 CPU 上。用于试运行的节点可从 8—16 个 CPU 核、64GB 内存起步；文档量、索引规模或并发增长后，再评估增加内存与核心数。模型文件和索引建议放在本地 NVMe 存储，容量按模型、原始文档、索引及备份分别预留。若使用 PostgreSQL 的 pgvector 或 Qdrant，向量数据库也可以部署在独立节点，避免与生成服务争抢资源。
单卡和多卡：差别不只是显存
| 方案 | 适用条件 | 优势 | 限制 |
|---|---|---|---|
| 单卡 | 模型和目标并发能放入单卡资源范围，优先验证功能或控制部署复杂度 | 部署、监控和故障排查相对简单；无需配置跨卡通信 | 显存上限明确；高并发时可能排队，升级空间受卡型限制 |
| 多卡 | 单卡无法容纳目标模型，或需提高并行处理能力 | 可通过张量并行等方式分摊模型计算，也可将不同服务分配到不同卡 | 通信与配置更复杂；显存不会自动合并成一块，速度也不一定随卡数线性提升 |
多卡还要区分“拆分一个模型”和“多份服务各用一张卡”。张量并行适合单卡放不下或单卡吞吐不足的模型，但跨卡通信会带来额外开销；如果模型能单卡运行，把生成服务、embedding 模型或重排序模型分配到不同卡，可能更容易管理。应检查主板插槽、供电、散热及卡间互联条件，不能只看显卡数量。
按步骤做容量验证
- 列出目标负载：记录模型名称与量化方式、最大上下文、预计同时生成的请求数，以及文档更新频率。
- 拆分服务：确认生成模型、embedding 模型和重排序模型是否同机部署，并决定向量数据库是否独立运行。
- 先用单卡试跑：用接近真实长度的提问与文档，观察显存峰值、首字延迟、生成速度和等待队列，而非只测空载。
- 逐项增加压力：逐步提高并发或上下文长度，记录何时出现显存不足、延迟明显上升或检索服务变慢。
- 再决定扩容方式：模型装不下时评估张量并行；模型能装下但请求排队时，比较优化推理、增加服务副本或多卡分流的成本。
因此，大模型本地知识库问答系统的计算节点配置应由测试结果定型：低并发、单一模型优先评估单卡；模型显存需求超限或负载确有增长，再评估多卡，并把通信、散热和运维成本一并纳入。
常见问题
单卡显存足够，为什么回答仍然慢？
原因可能是并发排队、上下文过长、CPU 或存储成为瓶颈，也可能是检索与重排耗时。分别测量检索、生成和排队延迟，再定位环节。
两张卡的显存能直接相加吗？
不能简单相加。只有推理框架支持相应的模型切分方式，且权重、缓存和运行开销能合理分布，才能利用多卡资源；通信也会影响速度。
向量数据库要和模型放在同一台机器吗？
小规模验证可以同机部署以简化维护；当索引、检索并发或服务隔离要求提高时，可独立部署，并通过网络连接生成服务。
