本地部署 AI 知识库时，显卡配置不能只看型号。真正决定你要买多大显存、要不要上专业卡的，是四件事：跑哪个生成模型、用什么量化精度、embedding 和 rerank 是否也占用同一块 GPU 显存，以及同时有多少人在提问、单次上下文能开多长。如果只是个人用几十份文档做检索问答，消费级 12GB～16GB 显存的卡通常能先跑起来；如果要多人在线、长上下文或 32B 级别模型，就要按每秒内存带宽和显存余量重新核算，不能靠“越大越好”下结论。
先确定模型参数量与量化方式，再按“权重大小 + KV cache + embedding/rerank 常驻”三项相加估算显存需求，最后才选卡。适用场景：单机自建、文档量在几百到几万份、并发数可控。操作动作：用估算脚本得出量级，再用小模型跑通链路。验证方式：加载后用 nvidia-smi 观察显存峰值和是否出现 OOM、Xid 报错。风险边界：估算只能判断量级，实际占用受框架、上下文长度、并发数量和桌面系统占用影响，必须以你自己环境加载后的读数为准。
先确认当前场景和目标
动手选卡前，先把下面几点确认清楚，否则很容易买回一块显存不够或者浪费一半的卡。
- 生成模型与量化：打算用 7B、14B 还是 32B 级别的模型；用 fp16、int8 还是 int4。量化越激进，权重占用越小，但回答质量会变化，需要你自己用业务问题对比。
- 检索链路里哪些环节在 GPU 上：embedding 模型、rerank 模型是否常驻显存，是否和生成模型共用一张卡。这两类模型通常不大，但常驻会吃掉一部分余量。
- 上下文长度与并发：单次送入的检索片段有多长、是否有对话历史累积、同时几个用户提问。KV cache 会随这两项线性增长。
- 可接受的回退：能不能接受部分层卸载到 CPU，或者在没有 GPU 的机器上只做小模型推理。
判断条件可以简化成一句：如果只是单人验证链路，优先保证显存能装下“量化后的权重 + 一段够用的上下文”；如果要多人同时用，显存带宽和并发下的峰值占用比单卡算力更关键。
按这个顺序处理
建议按“定模型 → 估显存 → 选卡 → 跑通链路”的顺序走，不要反过来先买卡再想模型。
第一步，用下面的估算脚本得出量级。脚本只是量级判断工具，参数需要按你要用的模型卡换成真实值，尤其是每 token 的 KV cache 开销，要查模型配置里的层数、隐藏维度和注意力头数，不同模型差异明显。
# 仅用于选卡前的量级估算，实际以加载后 nvidia-smi 读数为准
params_b = 14 # 模型参数量，单位：十亿
ytes_per_param = 0.55 # fp16≈2，int8≈1.05，int4≈0.55（含未量化层，偏保守）
kv_per_token_kb = 0.5 # 每 token 的 KV cache，按模型配置换算，不要直接套用
ctx = 8192
concurrency = 2
weights = params_b * tytes_per_param
kv = kv_per_token_kb * ctx * concurrency / (1024 * 1024) # 换算成 GB
print(f"权重约 {weights:.1f} GB，KV 约 {kv:.1f} GB，合计 {weights + kv:.1f} GB")
print("再预留 1~2 GB 给 embedding/rerank 与框架开销")第二步，按估算结果圈定显存档位。同一档位下，优先看显存容量和内存带宽，再看核心数量；知识库问答的瓶颈通常出现在“长上下文下生成速度”和“显存是否够装”，不是极限算力。
第三步，用容器把生成模型和 embedding 服务分开跑，便于单独限制显存占用。下面是通用骨架，镜像和参数需要替换成你实际使用的推理框架。
services:
llm:
image: <你的推理镜像> # vLLM / Ollama / llama.cpp server 等，按实际替换
ports: ["8000:8000"]
volumes: ["./models:/models"]
command: ["--model", "/models/<模型目录>",
"--max-model-len", "8192",
"--gpu-memory-utilization", "0.85"]
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 1
capabilities: [gpu]
embed:
image: <你的 embedding/rerank 服务镜像>
ports: ["8001:8000"]
volumes: ["./models:/models"]
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 1
capabilities: [gpu]把 --gpu-memory-utilization 这类参数先设在偏保守的位置，跑通之后再往上调；单卡同时放生成模型和 embedding 服务时，要给两者都留出余量，不要让它们争抢同一段显存。
改完后怎么验证
验证的核心是看峰值，不看空闲值。容器起来后，一边发起一次长上下文问答和一次批量文档入库，一边观察显存曲线。
nvidia-smi --query-gpu=index,name,memory.total,memory.used,utilization.gpu --format=csv -l 2同时检查内核层有没有卸载或驱动层报错：
dmesg -T | grep -i -E "xid|nvrm" | tail -n 20预期信号可以这样判断：文档批量入库阶段，显存占用应在一个稳定区间内波动，不应持续爬升；单次长上下文问答时，显存出现短时上升后回落；并发两三个请求时，显存不出现断崖式增长，服务日志里没有显存不足的分配失败记录。如果出现进程被系统杀掉、推理服务返回显存分配错误、或者 nvidia-smi 显示占用接近总量且延迟明显抖动，说明当前配置已经到边界，需要降上下文长度、降量化精度或换更大显存的卡。
功能层面还要单独验证一次端到端的问答：用几个你熟悉答案的文档问题，确认检索召回的片段正确、回答引用了正确内容。显卡够了但检索质量差，是另一条排查线。
容易忽略的边界
- 上下文不是免费加的：把最大上下文从 4K 提到 32K，KV cache 会成倍增长，同一块卡可能从够用变成不够用，建议按实际需要的检索片段长度设置，而不是直接拉满。
- 桌面环境会占显存：在带图形界面的机器上，显示输出和其他程序会常驻一部分显存，可用容量小于标称容量；长期跑服务建议用无图形界面的系统。
- 驱动与推理框架版本要匹配：CUDA 版本、驱动版本和推理框架之间不匹配时，常见表现是启动失败或运行中报错，而不是简单的性能下降；升级前先确认框架文档里写明的支持范围。
- 多卡不等于线性加速：跨卡切分模型会引入通信开销，对于知识库这类请求量不大的场景，一张大显存卡通常比两张小卡更容易调。
- 回退建议：显存不足时，可以先降低量化精度、缩短上下文、限制并发，或者把生成模型的部分层卸载到 CPU 换取更慢但可用的推理；如果完全没有 GPU，也可以只把 embedding 放在 CPU 上跑小模型，接受更长的入库时间。这些都属于让系统先跑起来的止血手段，不代表性能提升。