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 和 VLLM

1.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 年面向加密货币挖矿市场发布的专用卡，核心规格如下：

它和同代游戏卡相比，最大的优势是 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 卡的参考配置，适合先搭建单机验证，后续再扩展多机：

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 nvidia

lspci应该能看到 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 modeset=0' >> /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.4，VLLM 对这两个版本的支持比较成熟。安装时只装 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_PATH

3.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 pip

4.2 安装 VLLM

VLLM 提供 PyPI 安装包，正常情况直接安装即可：

pip install vllm

如果需要安装最新开发版或指定版本，可以加版本号：

pip install "vllm>=0.6.0"

安装完成后验证：

python -c "import vllm; print(vllm.__version__)"

4.3 安装 PyTorch

VLLM 会自带匹配的 PyTorch 版本，但如果你想自己控制版本，可以先安装对应 CUDA 版本的 PyTorch，再安装 VLLM：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

安装完成后最好检查一下 PyTorch 是否能正常识别 GPU：

import 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-utilization：VLLM 允许使用的显存比例，矿卡显存小，建议 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 多节点推理。

首先安装 Ray：

pip install ray

在主节点启动 Ray：

ray start --head --port=6379 --dashboard-host=0.0.0.0

在副节点执行：

ray start --address=<主节点IP>:6379

所有节点加入 Ray 集群后，在主节点启动 VLLM：

python -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-utilization

CMP 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. 常见问题与排查思路

多卡矿卡集群最容易踩坑的地方，下面整理了几个高频问题。

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 跑通，再逐步放大模型和多机规模。矿卡虽然便宜，但折腾成本并不低，一步步来，反而更快。