先聊一个很现实的问题大模型推理到底卡在哪儿做过本地部署的朋友应该都有体会GPU 显存就是最硬的瓶颈。想跑 Qwen2.5-72B、DeepSeek-R1 这类模型一张 24GB 显存的 RTX 3090 或 4090 只能勉强塞下量化版想开长上下文、想同时服务多个请求直接 Out of Memory。租云服务器A100/H100 价格常年高企个人玩家很难承担。于是今年开始国内外不少玩家把目光转向了被“矿难”淘汰的 Nvidia CMP 系列矿卡。其中 CMP 170HX 因为显存高达 16GB HBM2E、价格极低、功耗可控成了 DIY 大显存推理机的热门选择。本文要聊的就是一套相对激进的方案用 32 块 CMP 170HX 拼出 2TB 总显存的“家用超级计算机”并围绕 VLLM 完成大模型推理部署。先说清楚这套方案不适合所有人。它需要一定的硬件改造能力、Linux 系统操作经验也需要接受矿卡没有视频输出、散热需要自己动手、质保基本为零这些现实。但如果你喜欢折腾想用最低成本获得一个 2TB 显存的本地推理集群这篇文章会是一份很完整的参考。1. 这套方案的基本逻辑为什么是 CMP 170HX 和 VLLM1.1 大模型推理为什么吃显存大模型推理时显存主要花在三个地方模型权重以 FP16 为例每 10 亿参数大约需要 2GB 显存。一个 70B 模型光权重就要 140GB。KV Cache推理过程中每个历史 token 的 Key 和 Value 都要暂存序列越长、并发越高KV Cache 占用越大。中间激活值前向计算过程中的临时张量。其中模型权重是固定开销KV Cache 是动态开销。一张 24GB 的卡连一个 70B 模型都装不下更别提同时处理多个用户请求。而如果把多张卡拼在一起总显存达到 2TB那么从 7B 到 70B 甚至更大规模的模型都能轻松装下还能留出大量空间给 KV Cache 提升并发能力。这就是这套方案的核心价值用低成本的矿卡堆显存用并行的方式解决显存不足的问题。1.2 CMP 170HX 是一块怎样的卡Nvidia CMP 170HX 是 2021 年面向加密货币挖矿市场发布的专用卡核心规格如下参数CMP 170HX架构Ampere显存16GB HBM2E显存带宽约 1.46 TB/sCUDA 核心数4480供电接口8Pin 8Pin功耗250W TDP视频输出无它和同代游戏卡相比最大的优势是 HBM2E 显存带来的超高带宽这对大模型推理的访存密集型场景非常有利。因为没有视频输出所以它不适合游戏、不适合日常桌面显示但用于纯计算和推理反而没有浪费。价格方面二手市场这类卡的价格波动较大但通常远低于同显存容量的游戏卡和专业计算卡。这也是大家愿意折腾它的根本原因。1.3 VLLM 在其中的作用VLLM 是一个高吞吐量、易用的大模型推理服务框架。它底层基于 PyTorch但通过 PagedAttention、Continuous Batching、张量并行等机制大幅提升了 GPU 利用率和并发处理能力。简单说VLLM 能把 2TB 显存的硬件能力真正释放出来。在本方案中VLLM 扮演的角色是加载和运行模型。通过张量并行把模型权重切分到 32 张卡上。管理 KV Cache支持多用户并发请求。提供兼容 OpenAI 格式的 HTTP API方便业务系统接入。所以整套方案可以概括为用 CMP 170HX 矿卡堆出大显存池用 VLLM 把显存池高效利用起来跑大模型推理服务。2. 硬件选型与系统架构设计如果你准备复制这套方案硬件部分需要提前做好规划。盲目买 32 张卡回来发现装不上就晚了。2.1 为什么强调主板和 CPU 的 PCIe 通道数量32 张独立显卡意味着至少需要 32 条 PCIe 插槽。常规家用主板只有 1 到 2 条 PCIe x16 插槽根本不够用。目前可行的路线有两条多台服务器/工作站每台插 4 到 8 张卡通过以太网组集群。单台机器使用服务器主板加 PCIe 转接扩展方案。考虑到 CMP 170HX 是双槽卡单机插 32 张无论散热还是供电都非常困难。更现实的方案是用 4 台机器每台 8 卡然后用 VLLM 的多节点推理能力统一对外提供服务。在选 CPU 时要重点关注 PCIe Lane 数量。例如 AMD Threadripper Pro 系列或 Intel Xeon 系列通常能提供 64 条以上的 PCIe 通道配合 PCIe 拆分卡可以在一台机器上插 4 到 8 张卡。普通消费级平台通道数太少不建议使用。2.2 单机 8 卡配置参考这里给出一个单机 8 卡的参考配置适合先搭建单机验证后续再扩展多机部件建议配置说明CPUAMD Threadripper Pro 3965WX 或同级 Xeon保证 64 条以上 PCIe 通道主板WRX80 或 C621 工作站主板需要有足够 PCIe 插槽和供电能力内存至少 128GB DDR4 ECC系统运行和数据预处理需要系统盘1TB NVMe SSD安装系统和模型文件缓存数据盘4TB 以上 SATA SSD 或 HDD存放模型权重和数据集GPUCMP 170HX x8每张 16GB HBM2E电源2000W 以上钛金电源按整机功耗至少留 30% 余量散热暴力风扇或水冷改造矿卡散热普遍弱必须处理2.3 多机集群架构单机 8 卡的显存总量是 128GB已经能跑很多 70B 量化模型。如果目标是 2TB那就需要 16 台 8 卡机器或者 4 台 32 卡机器。考虑到机箱、供电、散热推荐按 4 台 8 卡机器规划。多机之间建议使用万兆以上内网互联。VLLM 的多节点推理通过 Ray 集群来实现节点间通信量不低千兆网络会成为严重瓶颈。整体架构如下客户端 / 业务系统 | | OpenAI 兼容 HTTP API v ----------------------- | VLLM 推理服务 | | (主节点 副节点) | ----------------------- | | Ray / NCCL v --------------------- | Node1 | Node2 | ... | | 8x GPU | 8x GPU | ... | ---------------------这么设计的好处是控制单机复杂度后续哪台机器出问题可以单独下线维修不影响整个集群的推理任务。3. 系统环境准备与操作系统配置3.1 操作系统选择对于多卡推理环境推荐使用 Ubuntu Server 22.04 LTS。原因很简单NVIDIA 驱动、CUDA 工具链、PyTorch、VLLM 对 Ubuntu 的支持最完善安装资料也最多。不建议使用桌面版 Ubuntu因为不需要图形界面纯 Server 版可以减少内存开销和潜在驱动冲突。3.2 基础软件环境安装系统后先更新软件源并安装基础工具sudo apt update sudo apt upgrade -y sudo apt install -y build-essential git curl wget vim net-tools然后检查 CPU、内存、PCIe 设备是否正常识别lscpu free -h lspci | grep -i nvidialspci应该能看到 8 张 CMP 170HX。如果数量不对先排查插槽接触和 PCIe 拆分设置。3.3 NVIDIA 驱动与 CUDA 安装CMP 170HX 属于 Ampere 架构可以使用与 RTX 30 系列相同的主流驱动版本。安装驱动有两种方式从 NVIDIA 官网下载 runfile 安装或通过 apt 安装发行版仓库驱动。这里以 runfile 方式为例稳定性和可控性更好# 先禁用默认的 nouveau 驱动 sudo bash -c echo blacklist nouveau /etc/modprobe.d/blacklist-nouveau.conf sudo bash -c echo options nouveau modeset0 /etc/modprobe.d/blacklist-nouveau.conf sudo update-initramfs -u sudo reboot重启后登录系统安装驱动。驱动版本建议选择 535 或更高版本具体以 NVIDIA 官网当前支持为准chmod x NVIDIA-Linux-x86_64-535.154.05.run sudo ./NVIDIA-Linux-x86_64-535.154.05.run安装完成后执行nvidia-smi如果能看到所有 CMP 170HX说明驱动正常。注意观察温度和功耗矿卡 nvidia-smi 显示的功耗是实际运行值待机时通常很低。CUDA 建议安装 CUDA 12.1 或 12.4VLLM 对这两个版本的支持比较成熟。安装时只装 Toolkit 即可不需要安装驱动驱动已经装好。wget https://developer.download.nvidia.com/compute/cuda/12.1.1/local_installers/cuda_12.1.1_530.30.02_linux.run sudo sh cuda_12.1.1_530.30.02_linux.run --toolkit --silent装完后在~/.bashrc中追加export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH3.4 磁盘与模型存储规划模型权重文件动辄几十 GB 到几百 GB建议单独挂载一块大容量数据盘并做好目录规划/data ├── models # 模型权重 ├── logs # 推理日志 └── cache # Hugging Face 缓存如果有多台机器每台机器都要能访问模型文件。最简单的方式是每台机器本地存放一份模型副本如果模型太大可以搭建 NFS 共享存储但要注意网络带宽。4. Python 虚拟环境与 VLLM 安装4.1 创建虚拟环境VLLM 依赖的 Python 包较多强烈建议使用虚拟环境避免污染系统 Python。python3 -m venv /data/venv/vllm-env source /data/venv/vllm-env/bin/activate pip install --upgrade pip4.2 安装 VLLMVLLM 提供 PyPI 安装包正常情况直接安装即可pip install vllm如果需要安装最新开发版或指定版本可以加版本号pip install vllm0.6.0安装完成后验证python -c import vllm; print(vllm.__version__)4.3 安装 PyTorchVLLM 会自带匹配的 PyTorch 版本但如果你想自己控制版本可以先安装对应 CUDA 版本的 PyTorch再安装 VLLMpip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121安装完成后最好检查一下 PyTorch 是否能正常识别 GPUimport torch print(torch.__version__) print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0))如果device_count返回 8说明 PyTorch 正确识别到了 8 张 CMP 170HX。5. VLLM 推理部署完整实战接下来是本文的核心部分如何用 VLLM 在 CMP 170HX 集群上启动大模型推理服务。5.1 选择适合的模型CMP 170HX 的算力在 Ampere 架构中属于中低水平单卡算力无法和 A100、H100 相比因此不适合跑实时性要求极高的超大模型。但显存总量大非常适合离线批量推理、中低并发在线服务。推荐先选择以下几类模型验证7B 到 14B 参数的对话模型例如 Qwen2.5-7B、Qwen2.5-14B。32B 到 72B 参数的通用模型例如 Qwen2.5-72B建议使用 AWQ 或 GPTQ 量化版本降低显存压力。多模态模型例如 Qwen2-VL-7B但需要额外确认算子兼容性。对于首次部署建议先用 Qwen2.5-7B-Instruct 跑通全流程再逐步切换到更大模型。5.2 下载模型权重使用 Hugging Face CLI 或git lfs下载模型。以 Qwen2.5-7B-Instruct 为例pip install huggingface_hub huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir /data/models/Qwen2.5-7B-Instruct如果网络环境无法直接访问 Hugging Face可以通过 ModelScope 下载。5.3 单卡或多卡启动 VLLM硬件上有多张卡但第一次调试建议先限制成单卡或双卡确认模型能正常加载避免一次性把所有卡都卷进来出现问题难以排查。单卡启动python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --host 0.0.0.0 \ --port 8000参数说明--model模型路径。--tensor-parallel-size张量并行度单卡填 1。--gpu-memory-utilizationVLLM 允许使用的显存比例矿卡显存小建议 0.9 以上。--host监听地址0.0.0.0 表示所有网卡可访问。--port服务端口。多卡启动python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.9 \ --host 0.0.0.0 \ --port 8000此时 VLLM 会把模型权重切分到 4 张卡上同时 KV Cache 也会分布在这 4 张卡中能支持的并发数和上下文长度会明显提升。5.4 32 卡配置与多节点启动要真正用满 2TB 显存需要在多台机器上启动 Ray 集群然后通过 VLLM 多节点推理。首先安装 Raypip install ray在主节点启动 Rayray start --head --port6379 --dashboard-host0.0.0.0在副节点执行ray start --address主节点IP:6379所有节点加入 Ray 集群后在主节点启动 VLLMpython -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-72B-Instruct-AWQ \ --tensor-parallel-size 32 \ --host 0.0.0.0 \ --port 8000注意--tensor-parallel-size 32表示 32 张卡并行VLLM 会自动识别 Ray 集群中的 GPU 资源。5.5 启动后的服务验证服务启动后用 curl 测试接口curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /data/models/Qwen2.5-7B-Instruct, messages: [{role: user, content: 你好请介绍一下自己}], max_tokens: 200, temperature: 0.7 }正常会返回类似下面的 JSON{ id: chatcmpl-xxxx, object: chat.completion, created: 1735689600, model: /data/models/Qwen2.5-7B-Instruct, choices: [ { index: 0, message: { role: assistant, content: 你好我是Qwen一个语言模型... }, finish_reason: stop } ], usage: { prompt_tokens: 10, completion_tokens: 50, total_tokens: 60 } }到这里VLLM 推理服务已经跑起来了。6. 性能调优与显存优化建议6.1 合理设置 gpu-memory-utilizationCMP 170HX 只有 16GB 显存能容纳的 KV Cache 有限。--gpu-memory-utilization这个参数决定 VLLM 最多使用多少比例的显存。建议单卡跑 7B 模型时设为 0.9 或更高。跑 72B 大模型时因为权重占用大KV Cache 空间会被压缩建议结合--max-model-len和--max-num-seqs调整。VLLM 加载模型时会预留模型权重空间剩余空间用于 KV Cache。如果gpu-memory-utilization设置过低即使显存总量很大并发也上不去。6.2 控制单请求最大 token 数每个请求的上下文越长KV Cache 占用越大。通过--max-model-len可以限制模型最大的序列长度避免个别请求把整个显存池打爆。--max-model-len 8192如果业务场景主要是短文本对话可以设置为 4096 或 2048显著提升并发能力。6.3 使用 Continuous Batching 提升吞吐VLLM 默认启用了 Continuous Batching也就是动态批次调度。多个请求同时到达时VLLM 会不断把新请求插入到当前正在执行的批次中而不是等前一批全部结束后再开启新批次。这种方式对当前这类多卡拼接的“显存大、算力相对弱”的机器特别适合因为算力不是强项但显存足够大可以把吞吐量拉高来弥补单请求延迟的不足。6.4 关于 --enforce-eager 的取舍VLLM 默认会使用 CUDA Graph 来加速推理减少 Kernel 启动开销但代价是加载时需要额外显存。搜索热词里反复出现--enforce-eager很多人问它的影响。如果显存非常紧张可以加上--enforce-eager关闭 CUDA Graph换取更多 KV Cache 空间python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --tensor-parallel-size 4 \ --enforce-eager \ --gpu-memory-utilization 0.95但要注意关闭 CUDA Graph 后推理速度会有所下降。在显存和速度之间需要按实际场景权衡。6.5 多节点通信瓶颈32 张卡分布在多台机器上节点间的 AllReduce 通信是性能关键。理想情况是每个节点使用支持 RDMA 的网络至少也要万兆以太网。如果使用千兆网络张量并行规模一大通信开销会严重拖慢整体推理速度。更稳妥的做法是单机内多卡优先使用 NVLink 或 PCIe Switch跨节点尽量降低张量并行度把模型按层或按请求拆分减少节点间通信频率。7. 常见问题与排查思路多卡矿卡集群最容易踩坑的地方下面整理了几个高频问题。问题现象常见原因解决思路nvidia-smi只识别到部分显卡PCIe 插槽接触不良或者 BIOS 未开启 PCIe 拆分检查物理插卡进入 BIOS 确认 PCIe Bifurcation 设置启动 VLLM 时提示 CUDA out of memorygpu-memory-utilization设置过高或模型权重太大降低显存利用率或改为更小的量化模型多机 VLLM 启动后节点间通信超时Ray 集群网络配置错误或防火墙拦截端口检查防火墙确保 6379 等端口互通模型推理速度远低于预期PCIe 通道数不足或节点间网络带宽不足查看nvidia-smi topo -m确认卡间拓扑运行时 GPU 温度过高矿卡散热器积灰或风扇风压不足清理灰尘增加机箱风扇必要时改造水冷VLLM 加载 72B 模型时提示权重内存不足显存总量不够或模型格式不兼容使用 AWQ/GPTQ 量化模型确认tensor-parallel-size正确7.1 显存不足问题很多人第一次在 VLLM 里加载大模型时会看到CUDA OOM或torch.OutOfMemoryError。原因可能是单卡或总显存不足以容纳模型权重。没有正确使用张量并行模型只加载到了一张卡上。gpu-memory-utilization设得太低导致可用 KV Cache 空间过小。排查顺序先看nvidia-smi确认总量再看模型仓库里的config.json确认模型大小最后看 VLLM 启动日志里实际分配显存的情况。7.2 VLLM 在多节点上加载慢多节点推理首次加载模型时需要把权重拷贝到每个节点时间会比较长。如果权重存储在共享磁盘速度取决于网络。建议先复制到每个节点的本地磁盘再启动 VLLM。7.3 矿卡驱动兼容性问题CMP 170HX 是专用卡新驱动基本都兼容但极老版本驱动可能缺少支持。遇到Unknown Error或nvidia-smi不显示卡时优先升级到 NVIDIA 官方最新版驱动。8. 最佳实践与工程建议8.1 硬件规划的复用思路不建议上来就按 32 卡一次性投入。更稳的路径是先搭 1 台 4 卡机器验证模型兼容性再扩展到 8 卡最后再考虑多机集群。每一阶段都要验证 VLLM 推理正确性和性能表现避免问题集中爆发。8.2 模型与权重管理模型文件通过 Hugging Face CLI 或 ModelScope 统一管理。大模型建议保留原始 FP16 版本和量化版本两套日常开发用量化版测试用 FP16 版。定期检查模型文件完整性huggingface-cli支持校验但实际要以官方文档为准。8.3 安全边界与运维推理服务监听 0.0.0.0 时一定要考虑鉴权。VLLM 提供 OpenAI 兼容接口如果不加保护任何能访问端口的人都可以调用你的 GPU 资源。建议在反向代理层增加 API Key 校验。不要把推理服务直接暴露到公网除非你有完善的认证和防火墙。生产环境变更前先做备份模型切换前先在小范围验证。8.4 监控与告警多卡集群的运维压力不小。建议部署简单的监控脚本定期检查每张卡的显存使用率。GPU 温度和风扇转速。推理服务是否存活。节点间网络延迟和丢包率。可以用nvidia-smi配合dmesg做日常检查也可以用 Prometheus Grafana 做更完整的监控具体结合团队条件决定。8.5 关于算力瓶颈的预期管理CMP 170HX 定位是矿卡不是为 AI 推理设计的。它的大带宽、大显存是优势但单卡算力有限。用 32 张卡拼出来的 2TB 显存集群跑离线批量推理、高吞吐并行请求是合适的但如果追求单请求极低延迟它很难与 A100/H100 相比。理性对待这一点才能发挥这套方案的最大价值。9. 总结与后续学习路线这套“32 块 Nvidia CMP170HX 打造 2TB 显存 VLLM 推理”的方案本质上是用低成本硬件换大显存池再借助 VLLM 的调度能力把显存变成实际的推理吞吐。文章从硬件选型、系统环境、VLLM 安装、单机多卡到多节点集群完整拆解了部署路径也给出了常见问题的排查方式和工程上的注意事项。对于想进一步深入的朋友下一步可以优先研究这几块内容VLLM 的 PagedAttention 原理理解 KV Cache 的管理方式能帮你更好地设置并发和上下文参数。AWQ/GPTQ 量化原理在显存有限时通过更低的量化位宽腾出更多 KV Cache 空间。Ray 集群的调度机制多节点 VLLM 依赖 Ray掌握 Ray 的资源配置和故障恢复能力会很有帮助。性能基准测试建议使用 vllm-bench 或 vllm bench 相关工具对不同模型、不同并行度、不同并发数做压测找到当前硬件的最佳配置。如果你打算动手复现这套方案建议从 4 卡起步先把 Qwen2.5-7B 跑通再逐步放大模型和多机规模。矿卡虽然便宜但折腾成本并不低一步步来反而更快。 32块CMP 170HX矿卡拼出2TB显存：VLLM大模型推理集群实战
先聊一个很现实的问题大模型推理到底卡在哪儿做过本地部署的朋友应该都有体会GPU 显存就是最硬的瓶颈。想跑 Qwen2.5-72B、DeepSeek-R1 这类模型一张 24GB 显存的 RTX 3090 或 4090 只能勉强塞下量化版想开长上下文、想同时服务多个请求直接 Out of Memory。租云服务器A100/H100 价格常年高企个人玩家很难承担。于是今年开始国内外不少玩家把目光转向了被“矿难”淘汰的 Nvidia CMP 系列矿卡。其中 CMP 170HX 因为显存高达 16GB HBM2E、价格极低、功耗可控成了 DIY 大显存推理机的热门选择。本文要聊的就是一套相对激进的方案用 32 块 CMP 170HX 拼出 2TB 总显存的“家用超级计算机”并围绕 VLLM 完成大模型推理部署。先说清楚这套方案不适合所有人。它需要一定的硬件改造能力、Linux 系统操作经验也需要接受矿卡没有视频输出、散热需要自己动手、质保基本为零这些现实。但如果你喜欢折腾想用最低成本获得一个 2TB 显存的本地推理集群这篇文章会是一份很完整的参考。1. 这套方案的基本逻辑为什么是 CMP 170HX 和 VLLM1.1 大模型推理为什么吃显存大模型推理时显存主要花在三个地方模型权重以 FP16 为例每 10 亿参数大约需要 2GB 显存。一个 70B 模型光权重就要 140GB。KV Cache推理过程中每个历史 token 的 Key 和 Value 都要暂存序列越长、并发越高KV Cache 占用越大。中间激活值前向计算过程中的临时张量。其中模型权重是固定开销KV Cache 是动态开销。一张 24GB 的卡连一个 70B 模型都装不下更别提同时处理多个用户请求。而如果把多张卡拼在一起总显存达到 2TB那么从 7B 到 70B 甚至更大规模的模型都能轻松装下还能留出大量空间给 KV Cache 提升并发能力。这就是这套方案的核心价值用低成本的矿卡堆显存用并行的方式解决显存不足的问题。1.2 CMP 170HX 是一块怎样的卡Nvidia CMP 170HX 是 2021 年面向加密货币挖矿市场发布的专用卡核心规格如下参数CMP 170HX架构Ampere显存16GB HBM2E显存带宽约 1.46 TB/sCUDA 核心数4480供电接口8Pin 8Pin功耗250W TDP视频输出无它和同代游戏卡相比最大的优势是 HBM2E 显存带来的超高带宽这对大模型推理的访存密集型场景非常有利。因为没有视频输出所以它不适合游戏、不适合日常桌面显示但用于纯计算和推理反而没有浪费。价格方面二手市场这类卡的价格波动较大但通常远低于同显存容量的游戏卡和专业计算卡。这也是大家愿意折腾它的根本原因。1.3 VLLM 在其中的作用VLLM 是一个高吞吐量、易用的大模型推理服务框架。它底层基于 PyTorch但通过 PagedAttention、Continuous Batching、张量并行等机制大幅提升了 GPU 利用率和并发处理能力。简单说VLLM 能把 2TB 显存的硬件能力真正释放出来。在本方案中VLLM 扮演的角色是加载和运行模型。通过张量并行把模型权重切分到 32 张卡上。管理 KV Cache支持多用户并发请求。提供兼容 OpenAI 格式的 HTTP API方便业务系统接入。所以整套方案可以概括为用 CMP 170HX 矿卡堆出大显存池用 VLLM 把显存池高效利用起来跑大模型推理服务。2. 硬件选型与系统架构设计如果你准备复制这套方案硬件部分需要提前做好规划。盲目买 32 张卡回来发现装不上就晚了。2.1 为什么强调主板和 CPU 的 PCIe 通道数量32 张独立显卡意味着至少需要 32 条 PCIe 插槽。常规家用主板只有 1 到 2 条 PCIe x16 插槽根本不够用。目前可行的路线有两条多台服务器/工作站每台插 4 到 8 张卡通过以太网组集群。单台机器使用服务器主板加 PCIe 转接扩展方案。考虑到 CMP 170HX 是双槽卡单机插 32 张无论散热还是供电都非常困难。更现实的方案是用 4 台机器每台 8 卡然后用 VLLM 的多节点推理能力统一对外提供服务。在选 CPU 时要重点关注 PCIe Lane 数量。例如 AMD Threadripper Pro 系列或 Intel Xeon 系列通常能提供 64 条以上的 PCIe 通道配合 PCIe 拆分卡可以在一台机器上插 4 到 8 张卡。普通消费级平台通道数太少不建议使用。2.2 单机 8 卡配置参考这里给出一个单机 8 卡的参考配置适合先搭建单机验证后续再扩展多机部件建议配置说明CPUAMD Threadripper Pro 3965WX 或同级 Xeon保证 64 条以上 PCIe 通道主板WRX80 或 C621 工作站主板需要有足够 PCIe 插槽和供电能力内存至少 128GB DDR4 ECC系统运行和数据预处理需要系统盘1TB NVMe SSD安装系统和模型文件缓存数据盘4TB 以上 SATA SSD 或 HDD存放模型权重和数据集GPUCMP 170HX x8每张 16GB HBM2E电源2000W 以上钛金电源按整机功耗至少留 30% 余量散热暴力风扇或水冷改造矿卡散热普遍弱必须处理2.3 多机集群架构单机 8 卡的显存总量是 128GB已经能跑很多 70B 量化模型。如果目标是 2TB那就需要 16 台 8 卡机器或者 4 台 32 卡机器。考虑到机箱、供电、散热推荐按 4 台 8 卡机器规划。多机之间建议使用万兆以上内网互联。VLLM 的多节点推理通过 Ray 集群来实现节点间通信量不低千兆网络会成为严重瓶颈。整体架构如下客户端 / 业务系统 | | OpenAI 兼容 HTTP API v ----------------------- | VLLM 推理服务 | | (主节点 副节点) | ----------------------- | | Ray / NCCL v --------------------- | Node1 | Node2 | ... | | 8x GPU | 8x GPU | ... | ---------------------这么设计的好处是控制单机复杂度后续哪台机器出问题可以单独下线维修不影响整个集群的推理任务。3. 系统环境准备与操作系统配置3.1 操作系统选择对于多卡推理环境推荐使用 Ubuntu Server 22.04 LTS。原因很简单NVIDIA 驱动、CUDA 工具链、PyTorch、VLLM 对 Ubuntu 的支持最完善安装资料也最多。不建议使用桌面版 Ubuntu因为不需要图形界面纯 Server 版可以减少内存开销和潜在驱动冲突。3.2 基础软件环境安装系统后先更新软件源并安装基础工具sudo apt update sudo apt upgrade -y sudo apt install -y build-essential git curl wget vim net-tools然后检查 CPU、内存、PCIe 设备是否正常识别lscpu free -h lspci | grep -i nvidialspci应该能看到 8 张 CMP 170HX。如果数量不对先排查插槽接触和 PCIe 拆分设置。3.3 NVIDIA 驱动与 CUDA 安装CMP 170HX 属于 Ampere 架构可以使用与 RTX 30 系列相同的主流驱动版本。安装驱动有两种方式从 NVIDIA 官网下载 runfile 安装或通过 apt 安装发行版仓库驱动。这里以 runfile 方式为例稳定性和可控性更好# 先禁用默认的 nouveau 驱动 sudo bash -c echo blacklist nouveau /etc/modprobe.d/blacklist-nouveau.conf sudo bash -c echo options nouveau modeset0 /etc/modprobe.d/blacklist-nouveau.conf sudo update-initramfs -u sudo reboot重启后登录系统安装驱动。驱动版本建议选择 535 或更高版本具体以 NVIDIA 官网当前支持为准chmod x NVIDIA-Linux-x86_64-535.154.05.run sudo ./NVIDIA-Linux-x86_64-535.154.05.run安装完成后执行nvidia-smi如果能看到所有 CMP 170HX说明驱动正常。注意观察温度和功耗矿卡 nvidia-smi 显示的功耗是实际运行值待机时通常很低。CUDA 建议安装 CUDA 12.1 或 12.4VLLM 对这两个版本的支持比较成熟。安装时只装 Toolkit 即可不需要安装驱动驱动已经装好。wget https://developer.download.nvidia.com/compute/cuda/12.1.1/local_installers/cuda_12.1.1_530.30.02_linux.run sudo sh cuda_12.1.1_530.30.02_linux.run --toolkit --silent装完后在~/.bashrc中追加export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH3.4 磁盘与模型存储规划模型权重文件动辄几十 GB 到几百 GB建议单独挂载一块大容量数据盘并做好目录规划/data ├── models # 模型权重 ├── logs # 推理日志 └── cache # Hugging Face 缓存如果有多台机器每台机器都要能访问模型文件。最简单的方式是每台机器本地存放一份模型副本如果模型太大可以搭建 NFS 共享存储但要注意网络带宽。4. Python 虚拟环境与 VLLM 安装4.1 创建虚拟环境VLLM 依赖的 Python 包较多强烈建议使用虚拟环境避免污染系统 Python。python3 -m venv /data/venv/vllm-env source /data/venv/vllm-env/bin/activate pip install --upgrade pip4.2 安装 VLLMVLLM 提供 PyPI 安装包正常情况直接安装即可pip install vllm如果需要安装最新开发版或指定版本可以加版本号pip install vllm0.6.0安装完成后验证python -c import vllm; print(vllm.__version__)4.3 安装 PyTorchVLLM 会自带匹配的 PyTorch 版本但如果你想自己控制版本可以先安装对应 CUDA 版本的 PyTorch再安装 VLLMpip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121安装完成后最好检查一下 PyTorch 是否能正常识别 GPUimport torch print(torch.__version__) print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0))如果device_count返回 8说明 PyTorch 正确识别到了 8 张 CMP 170HX。5. VLLM 推理部署完整实战接下来是本文的核心部分如何用 VLLM 在 CMP 170HX 集群上启动大模型推理服务。5.1 选择适合的模型CMP 170HX 的算力在 Ampere 架构中属于中低水平单卡算力无法和 A100、H100 相比因此不适合跑实时性要求极高的超大模型。但显存总量大非常适合离线批量推理、中低并发在线服务。推荐先选择以下几类模型验证7B 到 14B 参数的对话模型例如 Qwen2.5-7B、Qwen2.5-14B。32B 到 72B 参数的通用模型例如 Qwen2.5-72B建议使用 AWQ 或 GPTQ 量化版本降低显存压力。多模态模型例如 Qwen2-VL-7B但需要额外确认算子兼容性。对于首次部署建议先用 Qwen2.5-7B-Instruct 跑通全流程再逐步切换到更大模型。5.2 下载模型权重使用 Hugging Face CLI 或git lfs下载模型。以 Qwen2.5-7B-Instruct 为例pip install huggingface_hub huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir /data/models/Qwen2.5-7B-Instruct如果网络环境无法直接访问 Hugging Face可以通过 ModelScope 下载。5.3 单卡或多卡启动 VLLM硬件上有多张卡但第一次调试建议先限制成单卡或双卡确认模型能正常加载避免一次性把所有卡都卷进来出现问题难以排查。单卡启动python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --host 0.0.0.0 \ --port 8000参数说明--model模型路径。--tensor-parallel-size张量并行度单卡填 1。--gpu-memory-utilizationVLLM 允许使用的显存比例矿卡显存小建议 0.9 以上。--host监听地址0.0.0.0 表示所有网卡可访问。--port服务端口。多卡启动python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.9 \ --host 0.0.0.0 \ --port 8000此时 VLLM 会把模型权重切分到 4 张卡上同时 KV Cache 也会分布在这 4 张卡中能支持的并发数和上下文长度会明显提升。5.4 32 卡配置与多节点启动要真正用满 2TB 显存需要在多台机器上启动 Ray 集群然后通过 VLLM 多节点推理。首先安装 Raypip install ray在主节点启动 Rayray start --head --port6379 --dashboard-host0.0.0.0在副节点执行ray start --address主节点IP:6379所有节点加入 Ray 集群后在主节点启动 VLLMpython -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-72B-Instruct-AWQ \ --tensor-parallel-size 32 \ --host 0.0.0.0 \ --port 8000注意--tensor-parallel-size 32表示 32 张卡并行VLLM 会自动识别 Ray 集群中的 GPU 资源。5.5 启动后的服务验证服务启动后用 curl 测试接口curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /data/models/Qwen2.5-7B-Instruct, messages: [{role: user, content: 你好请介绍一下自己}], max_tokens: 200, temperature: 0.7 }正常会返回类似下面的 JSON{ id: chatcmpl-xxxx, object: chat.completion, created: 1735689600, model: /data/models/Qwen2.5-7B-Instruct, choices: [ { index: 0, message: { role: assistant, content: 你好我是Qwen一个语言模型... }, finish_reason: stop } ], usage: { prompt_tokens: 10, completion_tokens: 50, total_tokens: 60 } }到这里VLLM 推理服务已经跑起来了。6. 性能调优与显存优化建议6.1 合理设置 gpu-memory-utilizationCMP 170HX 只有 16GB 显存能容纳的 KV Cache 有限。--gpu-memory-utilization这个参数决定 VLLM 最多使用多少比例的显存。建议单卡跑 7B 模型时设为 0.9 或更高。跑 72B 大模型时因为权重占用大KV Cache 空间会被压缩建议结合--max-model-len和--max-num-seqs调整。VLLM 加载模型时会预留模型权重空间剩余空间用于 KV Cache。如果gpu-memory-utilization设置过低即使显存总量很大并发也上不去。6.2 控制单请求最大 token 数每个请求的上下文越长KV Cache 占用越大。通过--max-model-len可以限制模型最大的序列长度避免个别请求把整个显存池打爆。--max-model-len 8192如果业务场景主要是短文本对话可以设置为 4096 或 2048显著提升并发能力。6.3 使用 Continuous Batching 提升吞吐VLLM 默认启用了 Continuous Batching也就是动态批次调度。多个请求同时到达时VLLM 会不断把新请求插入到当前正在执行的批次中而不是等前一批全部结束后再开启新批次。这种方式对当前这类多卡拼接的“显存大、算力相对弱”的机器特别适合因为算力不是强项但显存足够大可以把吞吐量拉高来弥补单请求延迟的不足。6.4 关于 --enforce-eager 的取舍VLLM 默认会使用 CUDA Graph 来加速推理减少 Kernel 启动开销但代价是加载时需要额外显存。搜索热词里反复出现--enforce-eager很多人问它的影响。如果显存非常紧张可以加上--enforce-eager关闭 CUDA Graph换取更多 KV Cache 空间python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --tensor-parallel-size 4 \ --enforce-eager \ --gpu-memory-utilization 0.95但要注意关闭 CUDA Graph 后推理速度会有所下降。在显存和速度之间需要按实际场景权衡。6.5 多节点通信瓶颈32 张卡分布在多台机器上节点间的 AllReduce 通信是性能关键。理想情况是每个节点使用支持 RDMA 的网络至少也要万兆以太网。如果使用千兆网络张量并行规模一大通信开销会严重拖慢整体推理速度。更稳妥的做法是单机内多卡优先使用 NVLink 或 PCIe Switch跨节点尽量降低张量并行度把模型按层或按请求拆分减少节点间通信频率。7. 常见问题与排查思路多卡矿卡集群最容易踩坑的地方下面整理了几个高频问题。问题现象常见原因解决思路nvidia-smi只识别到部分显卡PCIe 插槽接触不良或者 BIOS 未开启 PCIe 拆分检查物理插卡进入 BIOS 确认 PCIe Bifurcation 设置启动 VLLM 时提示 CUDA out of memorygpu-memory-utilization设置过高或模型权重太大降低显存利用率或改为更小的量化模型多机 VLLM 启动后节点间通信超时Ray 集群网络配置错误或防火墙拦截端口检查防火墙确保 6379 等端口互通模型推理速度远低于预期PCIe 通道数不足或节点间网络带宽不足查看nvidia-smi topo -m确认卡间拓扑运行时 GPU 温度过高矿卡散热器积灰或风扇风压不足清理灰尘增加机箱风扇必要时改造水冷VLLM 加载 72B 模型时提示权重内存不足显存总量不够或模型格式不兼容使用 AWQ/GPTQ 量化模型确认tensor-parallel-size正确7.1 显存不足问题很多人第一次在 VLLM 里加载大模型时会看到CUDA OOM或torch.OutOfMemoryError。原因可能是单卡或总显存不足以容纳模型权重。没有正确使用张量并行模型只加载到了一张卡上。gpu-memory-utilization设得太低导致可用 KV Cache 空间过小。排查顺序先看nvidia-smi确认总量再看模型仓库里的config.json确认模型大小最后看 VLLM 启动日志里实际分配显存的情况。7.2 VLLM 在多节点上加载慢多节点推理首次加载模型时需要把权重拷贝到每个节点时间会比较长。如果权重存储在共享磁盘速度取决于网络。建议先复制到每个节点的本地磁盘再启动 VLLM。7.3 矿卡驱动兼容性问题CMP 170HX 是专用卡新驱动基本都兼容但极老版本驱动可能缺少支持。遇到Unknown Error或nvidia-smi不显示卡时优先升级到 NVIDIA 官方最新版驱动。8. 最佳实践与工程建议8.1 硬件规划的复用思路不建议上来就按 32 卡一次性投入。更稳的路径是先搭 1 台 4 卡机器验证模型兼容性再扩展到 8 卡最后再考虑多机集群。每一阶段都要验证 VLLM 推理正确性和性能表现避免问题集中爆发。8.2 模型与权重管理模型文件通过 Hugging Face CLI 或 ModelScope 统一管理。大模型建议保留原始 FP16 版本和量化版本两套日常开发用量化版测试用 FP16 版。定期检查模型文件完整性huggingface-cli支持校验但实际要以官方文档为准。8.3 安全边界与运维推理服务监听 0.0.0.0 时一定要考虑鉴权。VLLM 提供 OpenAI 兼容接口如果不加保护任何能访问端口的人都可以调用你的 GPU 资源。建议在反向代理层增加 API Key 校验。不要把推理服务直接暴露到公网除非你有完善的认证和防火墙。生产环境变更前先做备份模型切换前先在小范围验证。8.4 监控与告警多卡集群的运维压力不小。建议部署简单的监控脚本定期检查每张卡的显存使用率。GPU 温度和风扇转速。推理服务是否存活。节点间网络延迟和丢包率。可以用nvidia-smi配合dmesg做日常检查也可以用 Prometheus Grafana 做更完整的监控具体结合团队条件决定。8.5 关于算力瓶颈的预期管理CMP 170HX 定位是矿卡不是为 AI 推理设计的。它的大带宽、大显存是优势但单卡算力有限。用 32 张卡拼出来的 2TB 显存集群跑离线批量推理、高吞吐并行请求是合适的但如果追求单请求极低延迟它很难与 A100/H100 相比。理性对待这一点才能发挥这套方案的最大价值。9. 总结与后续学习路线这套“32 块 Nvidia CMP170HX 打造 2TB 显存 VLLM 推理”的方案本质上是用低成本硬件换大显存池再借助 VLLM 的调度能力把显存变成实际的推理吞吐。文章从硬件选型、系统环境、VLLM 安装、单机多卡到多节点集群完整拆解了部署路径也给出了常见问题的排查方式和工程上的注意事项。对于想进一步深入的朋友下一步可以优先研究这几块内容VLLM 的 PagedAttention 原理理解 KV Cache 的管理方式能帮你更好地设置并发和上下文参数。AWQ/GPTQ 量化原理在显存有限时通过更低的量化位宽腾出更多 KV Cache 空间。Ray 集群的调度机制多节点 VLLM 依赖 Ray掌握 Ray 的资源配置和故障恢复能力会很有帮助。性能基准测试建议使用 vllm-bench 或 vllm bench 相关工具对不同模型、不同并行度、不同并发数做压测找到当前硬件的最佳配置。如果你打算动手复现这套方案建议从 4 卡起步先把 Qwen2.5-7B 跑通再逐步放大模型和多机规模。矿卡虽然便宜但折腾成本并不低一步步来反而更快。