先确认为什么需要两张卡

Qwen3-32B约320亿参数。BF16权重仅按参数乘2字节就接近64GB，还未包含量化元数据、CUDA上下文、临时工作区和KV Cache，因此单张24GB或48GB卡无法直接承载完整BF16服务。双48GB卡可用张量并行保留较高精度；双24GB卡通常还需使用经过验证的AWQ/GPTQ等量化权重。

硬件与拓扑检查

nvidia-smi -L
nvidia-smi topo -m
nvidia-smi --query-gpu=index,name,memory.total,pci.bus_id,power.limit --format=csv

两卡应尽量同型号、同显存并处于较近PCIe/NVLink路径。跨CPU插槽的SYS路径会提高集合通信开销。供电和散热也要按双卡持续满载验证，不能只确认系统点亮。

下载与版本固定

python3 -m venv /opt/venvs/qwen32
source /opt/venvs/qwen32/bin/activate
pip install -U huggingface_hub vllm
mkdir -p /data/models/qwen3-32b
huggingface-cli download Qwen/Qwen3-32B \
 --local-dir /data/models/qwen3-32b

保存仓库提交版本、文件清单与磁盘占用。下载完成前不要让服务读取同一目录，避免把半成品当成有效模型。

双卡启动基线

CUDA_VISIBLE_DEVICES=0,1 vllm serve /data/models/qwen3-32b \
 --served-model-name qwen3-32b \
 --tensor-parallel-size 2 \
 --max-model-len 8192 \
 --gpu-memory-utilization 0.85 \
 --host 127.0.0.1 --port 8000

先用8192上下文和保守显存比例建立基线。`tensor-parallel-size=2`把矩阵计算和部分权重切分到两张卡，每一步生成都需要通信。它解决容量并可能增加吞吐，但不会让单请求速度自然翻倍。

模型与接口验收

curl -sS http://127.0.0.1:8000/v1/models | python -m json.tool
curl -sS http://127.0.0.1:8000/v1/chat/completions \
 -H 'Content-Type: application/json' \
 -d '{"model":"qwen3-32b","messages":[{"role":"user","content":"给出双GPU推理的三个通信风险。"}],"temperature":0.2,"max_tokens":256}' \
 | python -m json.tool

用固定中文、代码、数学和工具调用题集保存结果，后续量化或升级都与该基线比较。检查两卡显存占用是否接近，若严重不均衡，应核对可见设备、并行参数和模型架构支持。

从单请求扩展到容量测试

准备2K/8K输入与256/1024输出的组合，以1、2、4、8并发阶梯运行。记录首Token、逐Token、P95、聚合吞吐、显存和GPU功率。长输入主要考验prefill与缓存，长输出更暴露decode和跨卡同步成本。

将`max-model-len`提高到32K前先计算KV Cache，并保留显存余量。能把一个32K请求跑完，不代表可以支撑多个长请求。

双24GB卡怎么办

不要让框架自动把BF16层大量卸载到CPU后仍宣称“双GPU高性能”。更实际的路线是选择来源明确、与vLLM兼容的量化检查点，记录量化算法和基线质量；或改用较小模型。第三方量化文件必须核对许可证、作者、哈希和模型配置。

高频故障

  • 两卡只用一张：检查`CUDA_VISIBLE_DEVICES`与进程启动日志。
  • NCCL初始化卡住：先用nccl-tests验证两卡通信与共享内存。
  • 显存足够仍OOM：降低上下文和比例，检查工作区及其他进程。
  • 多卡速度低：比较单卡小模型基线，检查拓扑、请求规模和通信占比。
  • 输出异常：锁定Tokenizer、聊天模板、模型提交与vLLM版本。

上线时在反向代理后提供认证和限流，并保存完整启动命令。模型升级应在新端口并行验证，不能覆盖唯一可运行版本。

来源、翻译与版权说明

来源：网昱原创。第三方内容版权归原作者或发布机构所有；本站仅在许可证或明确授权允许时提供本地原文。

原文语言
ZH-CN
原文更新时间
未提供
许可证
未登记
核对官方来源 ↗