Linux部署大模型如何配置显卡显存

约 6 分钟读完 12 阅
文章导读
Linux 上部署大模型的显存配置，本质是把「权重 + KV cache + 框架开销 + 余量」四块放进单卡或多卡的显存里，再让推理框架的显存参数有一个可回退的落点。判断顺序建议是：先确认模型精度和上下文长度，再确认并发量，最后才决定用单卡、层卸载还是多卡切分。直接照抄别人的启动参数，通常会在长上下文或并发上来时遇到显存不足（OOM）。
📋 目录
  1. 一 先确认当前场景和目标
  2. 二 按这个顺序处理
  3. 三 改完后怎么验证
  4. 四 容易忽略的边界
A A

Linux 上部署大模型的显存配置，本质是把「权重 + KV cache + 框架开销 + 余量」四块放进单卡或多卡的显存里，再让推理框架的显存参数有一个可回退的落点。判断顺序建议是：先确认模型精度和上下文长度，再确认并发量，最后才决定用单卡、层卸载还是多卡切分。直接照抄别人的启动参数，通常会在长上下文或并发上来时遇到显存不足（OOM）。

显存配置的核心不是把卡插满，而是先固定模型精度、上下文长度、并发数三个变量，再让框架的显存参数留出余量。单卡放不下时优先降量化或减上下文，其次才是多卡切分；每一步都要用 nvidia-smi 和框架日志确认实际占用，而不是只看理论估算。

先确认当前场景和目标

在改任何参数前，先把下面几项记录下来，它们决定了后面所有取值：

  • 硬件条件：显卡型号、单卡显存、卡数、是否有 NVLink。没有 NVLink 也能做多卡切分，但卡间通信会走 PCIe，需要结合主板和带宽一起看。
  • 软件基线：nvidia-smi 显示的驱动版本、框架要求的 CUDA 运行时版本、是否在容器里跑（容器需要 nvidia-container-toolkit）。
  • 模型变量：参数量、权重精度（FP16 / INT8 / 4bit 量化）、最大上下文长度、期望并发数。
  • 用途：只做推理，还是要微调。微调还要额外算优化器状态和梯度，显存需求和纯推理不是一个量级。

判断条件可以用一句粗算来锚定：权重大小约等于参数量乘以每参数字节数（FP16 约 2 字节，INT8 约 1 字节，4bit 约半个字节），再叠加 KV cache 和框架预留。这个粗算只用来判断「单卡够不够」这个方向性问题，最终取值仍以实测为准。

按这个顺序处理

第一步，记录显卡基线，避免把驱动问题误判成显存问题：

nvidia-smi
nvidia-smi --query-gpu=index,name,memory.total,memory.used,driver_version --format=csv

注意 memory.used 在空载时是否已经不为零。带显示输出、ECC 开启或已有残留进程时，可用显存会少于标称值，这部分差额要在预算里先扣掉。

第二步，选精度。显存放不下时，先把 FP16 换成 INT8 或 4bit 量化，这是对显存占用影响最直接的一步。量化会带来一定的质量损失，需要用自己的任务样本比对输出，不要只看能不能跑起来。

Linux部署大模型如何配置显卡显存

第三步，单卡装不下时再考虑切分。用 llama.cpp 一类框架时，可以先把部分层放到 GPU、其余留在 CPU，代价是速度明显下降：

./llama-server -m /models/your-model-Q4_K_M.gguf \
  --n-gpu-layers 999 \
  --ctx-size 8192 \
  --host 0.0.0.0 --port 8080

其中 --n-gpu-layers 是要替换的关键项，从较小值逐步上调，直到显存接近上限但仍有剩余。--ctx-size 直接决定 KV cache 大小，长上下文场景下这一项往往比量化更吃显存。

用 vLLM 这类推理服务时，走多卡张量并行并给显存利用率留出余量：

python -m vllm.entrypoints.openai.api_server \
  --model /models/your-model \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.85 \
  --max-model-len 8192 \
  --max-num-seqs 8

需要替换的是模型路径、卡数、上下文长度和并发上限。--gpu-memory-utilization 不建议一上来就压到接近 1，留出的空间用于应对显存碎片和请求波动；--tensor-parallel-size 要与实际卡数一致，否则启动阶段就会报错。

第四步，把验证过的参数写进启动脚本或 systemd 单元，避免每次手敲导致参数漂移。

Linux部署大模型如何配置显卡显存

改完后怎么验证

验证要分「加载期」和「请求期」两段看：

  • 加载期观察框架日志，确认权重加载完成、KV cache 分配成功，没有出现 fallback 到 CPU 或自动降级上下文长度的提示。不同框架打印的字段不同，以日志里实际出现的显存或 block 信息为准。
  • 用 watch -n 1 nvidia-smi 或 nvidia-smi dmon 持续观察，重点看峰值占用是否稳定、有没有贴近上限后回落。
  • 发一个接近最大上下文长度的请求，再叠加并发请求，观察是否出现 OOM 或请求被拒绝。能正常返回且显存有余量，才算配置成立。
  • 对比一次改动前后的输出质量，确认量化没有把任务效果压到不可用。

预期信号是：峰值显存低于卡容量、运行一段时间后不持续上涨、长上下文请求能正常结束。如果显存随时间缓慢上涨，优先怀疑请求未释放或并发过高，而不是继续调大显存参数。

容易忽略的边界

几个常被跨过的限制：驱动版本与框架要求的 CUDA 运行时不一致时，问题往往表现为初始化失败而不是显存不足，需要先对齐版本再调参数；容器部署要确认 GPU 设备已正确挂载，否则 nvidia-smi 在容器内看不到卡；非 root 用户运行时要确认对显卡设备节点的访问权限。

层卸载到 CPU 和内存只能算让模型跑起来的折中方案，不是性能提升手段，长期使用建议换更小的模型或更强的卡。多卡切分在缺少高速互联时，收益会受限于卡间通信，卡数增加到一定程度后不如单卡降量化。

回退建议：保留一份已验证可用的启动参数，出现 OOM 时按「降并发 → 降上下文 → 降精度 → 减少 GPU 层数或卡数」的顺序回退，每次只改一个变量并重新验证，避免多个变量同时变动后无法定位原因。