这次我们要看的是一个比较“硬核”的 DIY 项目用 32 块 Nvidia CMP170HX 矿卡攒一台显存容量非常夸张的家用级推理服务器专门跑 vLLM 大模型推理。先对齐一个关键点CMP170HX 的公开规格是 16GB HBM2e 显存32 张卡全部识别且显存未屏蔽时总容量是 512GB不是 2TB。如果项目标称 2TB要么用的是更高显存版本要么把后续扩容计划也算进去了。这篇文章里我们按“32 卡多卡推理服务器”来理解重点验证 vLLM 能不能在这种矿卡上跑起来、多卡并行怎么配置、显存怎么观察、批量任务怎么测。矿卡的优点和缺点都很明显。优点是大显存、低价、存量足二手市场好找单卡 16GB 的 HBM2e 显存带宽非常可观缺点是完全没有视频输出驱动适配要花时间而且 vLLM 这类推理框架对多卡之间的通信拓扑有要求。所以这个项目真正的价值不是“2TB”这个数字而是把高显存推理的成本打下来让更多人有机会在本地跑更大的模型。本文是系列第一篇会完成四件事说清楚 CMP170HX 的核心规格和适用边界。给出一套 Ubuntu Docker vLLM 的部署流程。演示 4 卡、8 卡张量并行的启动方式以及如何用 OpenAI 风格接口调用。整理显存观测、批量任务、常见故障排查和最佳实践。如果你正打算用矿卡攒一台本地推理服务器或者已经在折腾多卡 vLLM 部署这篇文章可以直接收藏。1. 核心能力速览能力项说明项目类型DIY 多卡 GPU 推理服务器目标软件栈为 vLLM硬件核心Nvidia CMP170HX × 32材料标注实际按单卡 16GB HBM2e 核算显存规模32 卡原样识别为 512GB标题中“2TB”需要结合具体硬件版本确认软件框架vLLM开源的 LLM 推理与服务框架主要功能多卡张量并行推理、OpenAI 风格 API、高并发请求、批量离线推理硬件门槛需要 PCIe 通道充足的主板/服务器平台单机建议 4 到 8 卡起步操作系统Linux 推荐Ubuntu 22.04 / 24.04Docker 部署启动方式命令行 / Docker Compose / systemd 服务是否支持 API支持vLLM 默认提供 OpenAI 兼容接口是否支持批量任务支持可通过并发请求或离线批量推理实现适合场景本地大模型部署、多卡显存实验、中小规模推理服务自建这里先做一个重要提醒CMP170HX 是挖矿专用卡没有显示输出不能当普通显卡接显示器用。系统里必须保留一张带显示输出的显卡作为主卡或者使用服务器主板的板载显示输出。另外矿卡长期高负载运行风扇、散热、供电接口状态都不确定购买二手卡之后要逐张做压力测试。2. 适用场景与使用边界2.1 适合谁手里已经有多张 CMP170HX想组一台低成本高显存推理机器的人。做 LLM 推理服务的小团队想用开源框架 vLLM 跑 Qwen、Llama 等模型对显存容量敏感。想做 4 卡、8 卡张量并行实验验证模型吞吐、显存利用率和接口稳定性的技术玩家。CMP170HX 的核心优势是显存带宽。HBM2e 的带宽远高于同价位 GDDR6 显卡对解码长上下文、高并发推理都有帮助。16GB 单卡容量在同价位卡里也不吃亏4 张卡拼 64GB8 张卡拼 128GB跑 70B 模型量化版就有机会。2.2 不适合谁想拿来打游戏、做视频剪辑、跑图形渲染的人不建议买因为这卡没有显示输出。想插进普通家用主板的人先数一数主板 PCIe 通道和物理插槽再决定是否入坑。想用 Windows 直接跑 vLLM 的人vLLM 对 Windows 的支持有限生产环境基本都跑在 Linux 上。2.3 使用边界与合规提醒矿卡来源复杂购买二手硬件时要注意来源合法性不要助长盗抢或来路不明的硬件交易。跑大模型推理时输入数据可能包含个人隐私、商业信息或版权内容部署前要确认数据使用授权。如果服务暴露到公网必须在 vLLM 前置反向代理和身份认证避免未授权访问。不要用这个项目去挖矿或参与任何违反平台规则的算力活动本文只讨论 vLLM 推理服务器的技术搭建。3. 环境准备与硬件规划3.1 操作系统选择从热词和社区实践来看vLLM 部署最稳的还是 Linux尤其是 Ubuntu 22.04 和 24.04。为什么要强调 LinuxvLLM 官方镜像和 Docker 部署都以 Linux 为第一支持对象。NVIDIA 驱动在多卡环境下管理更灵活。CPU 内存页、共享内存、进程数限制在 Linux 下更容易调优。Windows 下跑 vLLM 不是完全不行但会遇到编译依赖、CUDA 图优化、共享内存限制等问题只适合做轻量测试不建议作为多卡推理生产环境。3.2 硬件规划32 张卡不是简单插进一块主板的。先算 PCIe 通道数普通消费级 CPU 只提供 20 到 28 条 PCIe 通道。一块显卡至少需要 x8 通道才能发挥完整推理性能x4 也能跑但通信会慢。32 张卡需要至少 256 条 PCIe 通道这种规模只有双路服务器平台或专门的多卡扩展方案才能满足。所以更现实的路线是先组一台 4 卡到 8 卡的机器跑通 vLLM 多卡并行。单机容量不够时再考虑多机扩展。vLLM 支持多节点张量并行但节点间网络延迟和带宽要求很高普通千兆网不够建议 100G 以上高速网络或 InfiniBand 才适合生产。对大多数人来说一台 4 卡机器已经能覆盖大部分本地推理需求。7B 模型 4 卡并行非常轻松32B 模型 4 卡量化版也能跑70B 模型则建议 8 卡。3.3 软件前置条件不管是裸机还是 Docker都需要先准备好NVIDIA 驱动版本要支持你使用的 CUDA 版本。Docker 引擎以及 NVIDIA Container Toolkit。HuggingFace 模型文件提前下载到本地目录。足够大的系统内存和磁盘空间。模型文件本身要占磁盘运行时的临时缓存也要注意。4. 安装部署与启动方式4.1 安装 NVIDIA 驱动Ubuntu 下最简单的方式是使用 ubuntu-driverssudo apt update sudo apt install -y ubuntu-drivers-common sudo ubuntu-drivers autoinstall sudo reboot重启后检查nvidia-smi如果能看到所有 GPU说明驱动安装成功。这里有两个常见情况显示“No devices were found”说明卡没被系统识别先检查供电线和 PCIe 插槽。显示卡数量少于实际数量说明 PCIe 通道不足或转接卡有问题需要缩小规模或更换平台。4.2 安装 Docker 和 NVIDIA Container ToolkitDocker 部署 vLLM 是最省心的方式不用手动解决 Python 依赖冲突。curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER newgrp docker安装 NVIDIA Container Toolkitsudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker验证 Docker 能否调用 GPUdocker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi如果能看到 GPU 列表说明容器内 GPU 透传正常。4.3 拉取 vLLM 镜像并启动以 Qwen2.5-7B 为例先把模型下载到本机mkdir -p /data/models cd /data/models git lfs install git clone https://www.modelscope.cn/models/Qwen/Qwen2.5-7B-Instruct.gitModelScope 下载对国内用户更友好具体仓库地址以实际为准。启动 vLLMdocker run --gpus all --ipchost \ -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:latest \ --model /models/Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.92 \ --max-model-len 8192 \ --host 0.0.0.0 \ --port 8000参数说明--tensor-parallel-size 4表示 4 卡张量并行。--gpu-memory-utilization 0.92限制 GPU 显存使用率防止模型加载后显存不足。--max-model-len 8192限制最大序列长度长文本需要更多 KV Cache。--host 0.0.0.0允许外部访问生产环境建议改成内网 IP 或 127.0.0.1。启动后日志里会出现类似“Starting vLLM server”和“Uvicorn running on http://0.0.0.0:8000”的信息说明服务已就绪。4.4 低显存运行模型的调整方式如果你的卡数量少或显存不足可以先降低并行度docker run --gpus all --ipchost \ -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:latest \ --model /models/Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.7 \ --max-model-len 4096 \ --enforce-eager--enforce-eager的作用是关闭 CUDA Graph 优化牺牲部分性能换取更低的启动显存和峰值显存。如果遇到 OOM 或模型加载失败可以先开这个参数试跑跑通后再关闭。5. 功能测试与效果验证5.1 基础对话接口测试服务启动后先测一个最基础的 chat 请求curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /models/Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: 你好请简单介绍一下你自己}], max_tokens: 128 }预期返回一段 JSON其中包含choices数组和生成的文本。判断成功的标准返回 HTTP 200。响应内容完整不是空文本。单次请求延迟在接受范围内通常在几秒内。如果请求超时先看 vLLM 日志有没有报错再看 GPU 是否真的被占用。5.2 多轮对话测试多轮对话测试能验证 KV Cache 是否有问题curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /models/Qwen/Qwen2.5-7B-Instruct, messages: [ {role: user, content: 11等于几}, {role: assistant, content: 等于2}, {role: user, content: 那再加1呢} ], max_tokens: 128 }正确输出应该是“等于3”。如果模型答非所问或重复可能是上下文长度设置过大导致 KV Cache 溢出或模型文件本身有问题。5.3 并发请求测试vLLM 的强项是并发推理。多个请求同时进来时vLLM 会做 continuous batching而不是排队等待。可以用简单的 Python 脚本压一下import requests from concurrent.futures import ThreadPoolExecutor url http://127.0.0.1:8000/v1/chat/completions headers {Content-Type: application/json} def send_request(idx): payload { model: /models/Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: f第{idx}个请求请重复这句话}], max_tokens: 64 } resp requests.post(url, jsonpayload, timeout60) return resp.status_code with ThreadPoolExecutor(max_workers16) as pool: results list(pool.map(send_request, range(50))) print(results.count(200), 个请求成功)如果 50 个请求全部返回 200说明并发基本没问题。如果出现大量超时或 429需要检查--max-num-seqs和显存余量。5.4 显存占用验证另开一个终端实时观察显存nvidia-smi dmon -s pucvmet -d 2这个命令会持续刷新 GPU 利用率、显存使用、温度、功耗数据。重点关注显存使用是否接近--gpu-memory-utilization设置的上限。是否存在某张卡显存明显高于其他卡说明张量并行切分不均匀。温度是否过高尤其是挖矿卡长期高负载后散热能力下降的情况。6. 接口 API 与批量任务vLLM 默认提供 OpenAI 兼容 API很多现有工具可以直接把 URL 换成http://localhost:8000/v1就能用。6.1 获取模型列表curl http://127.0.0.1:8000/v1/models返回的data数组里包含当前加载的模型名。这个接口也是验证服务是否正常运行最快速的方法。6.2 批量离线推理离线推理适合处理大批量文本比如给一批文章生成摘要、批量翻译、批量分类。思路是把所有输入放到一个列表里用并发线程或异步协程请求 vLLM 接口。示例代码import asyncio import aiohttp API_URL http://127.0.0.1:8000/v1/chat/completions MODEL_NAME /models/Qwen/Qwen2.5-7B-Instruct async def chat(session, text): payload { model: MODEL_NAME, messages: [{role: user, content: text}], max_tokens: 256, temperature: 0.7 } async with session.post(API_URL, jsonpayload, timeout120) as resp: data await resp.json() return data[choices][0][message][content] async def main(): inputs [] with open(./input_texts.txt, r, encodingutf-8) as f: inputs [line.strip() for line in f if line.strip()] async with aiohttp.ClientSession() as session: tasks [chat(session, text) for text in inputs[:20]] results await asyncio.gather(*tasks) with open(./output_results.txt, w, encodingutf-8) as f: for text, result in zip(inputs[:20], results): f.write(text result \n) if __name__ __main__: asyncio.run(main())批量任务的判断标准是所有请求都返回 200并且生成内容完整。单条文本生成长度与max_tokens设置一致。在一段时间内显存利用率稳定没有持续上涨。如果批量任务卡住先看是不是请求超时设置太短再看并发数是否超过--max-num-seqs限制必要时降低并发数量。6.3 接口生产化建议在 vLLM 前加 Nginx 反向代理做 HTTPS 和访问认证。用OPENAI_API_KEY环境变量设置访问密钥。对单 IP 做请求频率限制防止接口被滥用。7. 资源占用与性能观察7.1 显存怎么观察最直接的方式是nvidia-sminvidia-smi --query-gpuindex,memory.used,memory.total,utilization.gpu,temperature.gpu --formatcsv -l 2这个命令每 2 秒输出一次方便看多卡状态。需要重点观察的是模型加载后显存是否被完整分配。推理过程中显存是否接近上限。并发升高后是否出现 OOM。7.2 vLLM 显存占用构成vLLM 的显存主要分为三部分模型权重模型参数本身的大小。KV Cache每个请求的键值缓存随max_model_len和并发数线性增长。计算图和其他运行时缓存。所以同样的模型--max-model-len越大KV Cache 占用越高并发请求越多需要的 KV Cache 越大。如果显存不够优先调低--max-model-len或--max-num-seqs。7.3 如何降低显存占用常见手段量化模型用 AWQ、GPTQ 量化版权重显存占用明显下降。开启--enforce-eager关闭 CUDA Graph降低峰值显存性能有一定损失。降低--gpu-memory-utilization显式限制 vLLM 可用显存。减少--max-model-len限制单条请求的最大长度。使用--max-num-seqs限制同时处理的序列数。7.4 CPU 推理与 GPU 推理的差异vLLM 主要面向 GPU 推理也支持 CPU 后端但吞吐差距很大。CMP170HX 的优势就是显存带宽没必要退回 CPU 推理。如果你只有一张小显存显卡可以考虑 Ollama 这类轻量工具而不是强行上 vLLM。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后服务无法访问端口被占用或服务未启动检查 vLLM 日志和 port 8000 监听状态换端口或重启容器nvidia-smi 看不到 GPU驱动未装好或供电问题执行 nvidia-smi 查看错误重装驱动检查供电和 PCIe 插槽卡数量少于实际数量PCIe 通道不足查看 lspci 和系统日志减少卡数量更换主板平台模型加载显示显存不足模型权重太大或 gpu-memory-utilization 过高查看日志中的显存分配信息使用量化模型调低显存利用率推理时 OOM并发数过高或 max-model-len 过大观察 nvidia-smi 显存曲线调低 max-num-seqs 和 max-model-lenDocker 内无法调用 GPUNVIDIA Container Toolkit 未安装运行 nvidia-smi 容器测试安装 nvidia-container-toolkit 并重启 Docker批量任务中部分请求失败超时时间不足或并发过高查看服务端日志增加 timeout降低并发数输出结果重复或乱码量化参数不合适或模型文件损坏对比官方模型输出重新下载模型检查生成参数温度过高矿卡散热系统老化检查风扇转速和机箱风道清灰换硅脂调整风扇策略9. 最佳实践与使用建议9.1 第一次不要直接上 32 卡先拿一张卡跑通 CMP170HX 的驱动验证再逐步扩展到 4 卡、8 卡。32 卡涉及供电、散热、PCIe 通道、系统稳定性和网络拓扑问题排查难度是几何级上升。先掌握一张卡的行为再谈规模。9.2 保留一套最小可运行配置把单卡启动 vLLM 的命令保存为一个脚本作为最小可运行配置。后续任何卡数量或模型版本调整都在这个基础上改。这能帮你快速定位是硬件问题还是配置问题。9.3 模型文件、输入素材、输出结果分目录管理建议目录结构/data ├── models ├── inputs └── outputs模型文件放在 models 目录临时输入素材和生成结果分开管理避免容器挂载权限混乱。9.4 批量任务要加日志和失败重试批量推理过程中网络抖动、GPU 显存波动、单次请求超时都可能发生。建议每条请求记录输入 ID、状态码、耗时。失败请求自动重试 2 到 3 次。实时写入进度日志避免任务中断后从头开始。9.5 接口服务控制访问范围vLLM 默认绑定0.0.0.0时局域网内所有人都能访问。如果只做本地测试建议--host 127.0.0.1如果需要局域网访问建议加一层反向代理和访问密钥。9.6 数据合规与授权处理任何文本、图片、声音数据之前先确认是否有权使用这些数据。如果涉及用户个人信息必须遵守相关隐私法规。不要用这个推理服务处理来源不明的内容或生成违法内容。9.7 关注硬件状态矿卡长期高负载运行PCB 和显存老化程度不好判断。建议每张卡单独跑 30 分钟压力测试确认无花屏、无掉卡、无温度异常。检查供电线缆是否老化机箱电源功率是否足够。用nvidia-smi -q -d TEMPERATURE,PERFORMANCE查看每张卡的详细状态。10. 总结与下一步这个项目的核心价值是把“大显存推理”这个原本需要专业服务器硬件才能做到的事情拉回到 DIY 玩家能接触的范围。CMP170HX 单卡 16GB HBM2e搭配 vLLM 做 4 卡或 8 卡张量并行确实能跑很多消费级显卡跑不动的大模型。最先要验证的不是“能不能跑出 2TB”而是三点手头的 CMP170HX 在 Ubuntu 下能否全部被 nvidia-smi 识别。单卡加载一个 7B 模型能否稳定输出。4 卡并行后吞吐有没有明显提升。最容易踩的坑也在三个地方一是 PCIe 通道不足导致卡数量识别不全二是供电和散热不达标导致掉卡三是 vLLM 参数设置不合理导致显存不足或性能不升反降。这个系列后续可以继续做下去。比如CMP170HX 与正常显卡在 vLLM 推理下的性能差异、多机多卡张量并行的网络配置、AWQ 量化模型在矿卡上的显存占用对比、vLLM 与 sglang 的多卡推理体验对比都可以在已经有机器的基础上逐步展开。如果你手里正好有这批卡建议先把 4 卡配置跑通再想 32 卡的事。毕竟“能跑起来”和“能持续稳定跑”之间差着一整套工程化的工作量。先把单卡流程吃透这个项目就成功了一大半。 
长河君 · 2026/8/27 5:03:27 · 阅读 1.2k 32块CMP170HX矿卡搭建vLLM多卡推理服务器实战指南
这次我们要看的是一个比较“硬核”的 DIY 项目用 32 块 Nvidia CMP170HX 矿卡攒一台显存容量非常夸张的家用级推理服务器专门跑 vLLM 大模型推理。先对齐一个关键点CMP170HX 的公开规格是 16GB HBM2e 显存32 张卡全部识别且显存未屏蔽时总容量是 512GB不是 2TB。如果项目标称 2TB要么用的是更高显存版本要么把后续扩容计划也算进去了。这篇文章里我们按“32 卡多卡推理服务器”来理解重点验证 vLLM 能不能在这种矿卡上跑起来、多卡并行怎么配置、显存怎么观察、批量任务怎么测。矿卡的优点和缺点都很明显。优点是大显存、低价、存量足二手市场好找单卡 16GB 的 HBM2e 显存带宽非常可观缺点是完全没有视频输出驱动适配要花时间而且 vLLM 这类推理框架对多卡之间的通信拓扑有要求。所以这个项目真正的价值不是“2TB”这个数字而是把高显存推理的成本打下来让更多人有机会在本地跑更大的模型。本文是系列第一篇会完成四件事说清楚 CMP170HX 的核心规格和适用边界。给出一套 Ubuntu Docker vLLM 的部署流程。演示 4 卡、8 卡张量并行的启动方式以及如何用 OpenAI 风格接口调用。整理显存观测、批量任务、常见故障排查和最佳实践。如果你正打算用矿卡攒一台本地推理服务器或者已经在折腾多卡 vLLM 部署这篇文章可以直接收藏。1. 核心能力速览能力项说明项目类型DIY 多卡 GPU 推理服务器目标软件栈为 vLLM硬件核心Nvidia CMP170HX × 32材料标注实际按单卡 16GB HBM2e 核算显存规模32 卡原样识别为 512GB标题中“2TB”需要结合具体硬件版本确认软件框架vLLM开源的 LLM 推理与服务框架主要功能多卡张量并行推理、OpenAI 风格 API、高并发请求、批量离线推理硬件门槛需要 PCIe 通道充足的主板/服务器平台单机建议 4 到 8 卡起步操作系统Linux 推荐Ubuntu 22.04 / 24.04Docker 部署启动方式命令行 / Docker Compose / systemd 服务是否支持 API支持vLLM 默认提供 OpenAI 兼容接口是否支持批量任务支持可通过并发请求或离线批量推理实现适合场景本地大模型部署、多卡显存实验、中小规模推理服务自建这里先做一个重要提醒CMP170HX 是挖矿专用卡没有显示输出不能当普通显卡接显示器用。系统里必须保留一张带显示输出的显卡作为主卡或者使用服务器主板的板载显示输出。另外矿卡长期高负载运行风扇、散热、供电接口状态都不确定购买二手卡之后要逐张做压力测试。2. 适用场景与使用边界2.1 适合谁手里已经有多张 CMP170HX想组一台低成本高显存推理机器的人。做 LLM 推理服务的小团队想用开源框架 vLLM 跑 Qwen、Llama 等模型对显存容量敏感。想做 4 卡、8 卡张量并行实验验证模型吞吐、显存利用率和接口稳定性的技术玩家。CMP170HX 的核心优势是显存带宽。HBM2e 的带宽远高于同价位 GDDR6 显卡对解码长上下文、高并发推理都有帮助。16GB 单卡容量在同价位卡里也不吃亏4 张卡拼 64GB8 张卡拼 128GB跑 70B 模型量化版就有机会。2.2 不适合谁想拿来打游戏、做视频剪辑、跑图形渲染的人不建议买因为这卡没有显示输出。想插进普通家用主板的人先数一数主板 PCIe 通道和物理插槽再决定是否入坑。想用 Windows 直接跑 vLLM 的人vLLM 对 Windows 的支持有限生产环境基本都跑在 Linux 上。2.3 使用边界与合规提醒矿卡来源复杂购买二手硬件时要注意来源合法性不要助长盗抢或来路不明的硬件交易。跑大模型推理时输入数据可能包含个人隐私、商业信息或版权内容部署前要确认数据使用授权。如果服务暴露到公网必须在 vLLM 前置反向代理和身份认证避免未授权访问。不要用这个项目去挖矿或参与任何违反平台规则的算力活动本文只讨论 vLLM 推理服务器的技术搭建。3. 环境准备与硬件规划3.1 操作系统选择从热词和社区实践来看vLLM 部署最稳的还是 Linux尤其是 Ubuntu 22.04 和 24.04。为什么要强调 LinuxvLLM 官方镜像和 Docker 部署都以 Linux 为第一支持对象。NVIDIA 驱动在多卡环境下管理更灵活。CPU 内存页、共享内存、进程数限制在 Linux 下更容易调优。Windows 下跑 vLLM 不是完全不行但会遇到编译依赖、CUDA 图优化、共享内存限制等问题只适合做轻量测试不建议作为多卡推理生产环境。3.2 硬件规划32 张卡不是简单插进一块主板的。先算 PCIe 通道数普通消费级 CPU 只提供 20 到 28 条 PCIe 通道。一块显卡至少需要 x8 通道才能发挥完整推理性能x4 也能跑但通信会慢。32 张卡需要至少 256 条 PCIe 通道这种规模只有双路服务器平台或专门的多卡扩展方案才能满足。所以更现实的路线是先组一台 4 卡到 8 卡的机器跑通 vLLM 多卡并行。单机容量不够时再考虑多机扩展。vLLM 支持多节点张量并行但节点间网络延迟和带宽要求很高普通千兆网不够建议 100G 以上高速网络或 InfiniBand 才适合生产。对大多数人来说一台 4 卡机器已经能覆盖大部分本地推理需求。7B 模型 4 卡并行非常轻松32B 模型 4 卡量化版也能跑70B 模型则建议 8 卡。3.3 软件前置条件不管是裸机还是 Docker都需要先准备好NVIDIA 驱动版本要支持你使用的 CUDA 版本。Docker 引擎以及 NVIDIA Container Toolkit。HuggingFace 模型文件提前下载到本地目录。足够大的系统内存和磁盘空间。模型文件本身要占磁盘运行时的临时缓存也要注意。4. 安装部署与启动方式4.1 安装 NVIDIA 驱动Ubuntu 下最简单的方式是使用 ubuntu-driverssudo apt update sudo apt install -y ubuntu-drivers-common sudo ubuntu-drivers autoinstall sudo reboot重启后检查nvidia-smi如果能看到所有 GPU说明驱动安装成功。这里有两个常见情况显示“No devices were found”说明卡没被系统识别先检查供电线和 PCIe 插槽。显示卡数量少于实际数量说明 PCIe 通道不足或转接卡有问题需要缩小规模或更换平台。4.2 安装 Docker 和 NVIDIA Container ToolkitDocker 部署 vLLM 是最省心的方式不用手动解决 Python 依赖冲突。curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER newgrp docker安装 NVIDIA Container Toolkitsudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker验证 Docker 能否调用 GPUdocker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi如果能看到 GPU 列表说明容器内 GPU 透传正常。4.3 拉取 vLLM 镜像并启动以 Qwen2.5-7B 为例先把模型下载到本机mkdir -p /data/models cd /data/models git lfs install git clone https://www.modelscope.cn/models/Qwen/Qwen2.5-7B-Instruct.gitModelScope 下载对国内用户更友好具体仓库地址以实际为准。启动 vLLMdocker run --gpus all --ipchost \ -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:latest \ --model /models/Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.92 \ --max-model-len 8192 \ --host 0.0.0.0 \ --port 8000参数说明--tensor-parallel-size 4表示 4 卡张量并行。--gpu-memory-utilization 0.92限制 GPU 显存使用率防止模型加载后显存不足。--max-model-len 8192限制最大序列长度长文本需要更多 KV Cache。--host 0.0.0.0允许外部访问生产环境建议改成内网 IP 或 127.0.0.1。启动后日志里会出现类似“Starting vLLM server”和“Uvicorn running on http://0.0.0.0:8000”的信息说明服务已就绪。4.4 低显存运行模型的调整方式如果你的卡数量少或显存不足可以先降低并行度docker run --gpus all --ipchost \ -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:latest \ --model /models/Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.7 \ --max-model-len 4096 \ --enforce-eager--enforce-eager的作用是关闭 CUDA Graph 优化牺牲部分性能换取更低的启动显存和峰值显存。如果遇到 OOM 或模型加载失败可以先开这个参数试跑跑通后再关闭。5. 功能测试与效果验证5.1 基础对话接口测试服务启动后先测一个最基础的 chat 请求curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /models/Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: 你好请简单介绍一下你自己}], max_tokens: 128 }预期返回一段 JSON其中包含choices数组和生成的文本。判断成功的标准返回 HTTP 200。响应内容完整不是空文本。单次请求延迟在接受范围内通常在几秒内。如果请求超时先看 vLLM 日志有没有报错再看 GPU 是否真的被占用。5.2 多轮对话测试多轮对话测试能验证 KV Cache 是否有问题curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /models/Qwen/Qwen2.5-7B-Instruct, messages: [ {role: user, content: 11等于几}, {role: assistant, content: 等于2}, {role: user, content: 那再加1呢} ], max_tokens: 128 }正确输出应该是“等于3”。如果模型答非所问或重复可能是上下文长度设置过大导致 KV Cache 溢出或模型文件本身有问题。5.3 并发请求测试vLLM 的强项是并发推理。多个请求同时进来时vLLM 会做 continuous batching而不是排队等待。可以用简单的 Python 脚本压一下import requests from concurrent.futures import ThreadPoolExecutor url http://127.0.0.1:8000/v1/chat/completions headers {Content-Type: application/json} def send_request(idx): payload { model: /models/Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: f第{idx}个请求请重复这句话}], max_tokens: 64 } resp requests.post(url, jsonpayload, timeout60) return resp.status_code with ThreadPoolExecutor(max_workers16) as pool: results list(pool.map(send_request, range(50))) print(results.count(200), 个请求成功)如果 50 个请求全部返回 200说明并发基本没问题。如果出现大量超时或 429需要检查--max-num-seqs和显存余量。5.4 显存占用验证另开一个终端实时观察显存nvidia-smi dmon -s pucvmet -d 2这个命令会持续刷新 GPU 利用率、显存使用、温度、功耗数据。重点关注显存使用是否接近--gpu-memory-utilization设置的上限。是否存在某张卡显存明显高于其他卡说明张量并行切分不均匀。温度是否过高尤其是挖矿卡长期高负载后散热能力下降的情况。6. 接口 API 与批量任务vLLM 默认提供 OpenAI 兼容 API很多现有工具可以直接把 URL 换成http://localhost:8000/v1就能用。6.1 获取模型列表curl http://127.0.0.1:8000/v1/models返回的data数组里包含当前加载的模型名。这个接口也是验证服务是否正常运行最快速的方法。6.2 批量离线推理离线推理适合处理大批量文本比如给一批文章生成摘要、批量翻译、批量分类。思路是把所有输入放到一个列表里用并发线程或异步协程请求 vLLM 接口。示例代码import asyncio import aiohttp API_URL http://127.0.0.1:8000/v1/chat/completions MODEL_NAME /models/Qwen/Qwen2.5-7B-Instruct async def chat(session, text): payload { model: MODEL_NAME, messages: [{role: user, content: text}], max_tokens: 256, temperature: 0.7 } async with session.post(API_URL, jsonpayload, timeout120) as resp: data await resp.json() return data[choices][0][message][content] async def main(): inputs [] with open(./input_texts.txt, r, encodingutf-8) as f: inputs [line.strip() for line in f if line.strip()] async with aiohttp.ClientSession() as session: tasks [chat(session, text) for text in inputs[:20]] results await asyncio.gather(*tasks) with open(./output_results.txt, w, encodingutf-8) as f: for text, result in zip(inputs[:20], results): f.write(text result \n) if __name__ __main__: asyncio.run(main())批量任务的判断标准是所有请求都返回 200并且生成内容完整。单条文本生成长度与max_tokens设置一致。在一段时间内显存利用率稳定没有持续上涨。如果批量任务卡住先看是不是请求超时设置太短再看并发数是否超过--max-num-seqs限制必要时降低并发数量。6.3 接口生产化建议在 vLLM 前加 Nginx 反向代理做 HTTPS 和访问认证。用OPENAI_API_KEY环境变量设置访问密钥。对单 IP 做请求频率限制防止接口被滥用。7. 资源占用与性能观察7.1 显存怎么观察最直接的方式是nvidia-sminvidia-smi --query-gpuindex,memory.used,memory.total,utilization.gpu,temperature.gpu --formatcsv -l 2这个命令每 2 秒输出一次方便看多卡状态。需要重点观察的是模型加载后显存是否被完整分配。推理过程中显存是否接近上限。并发升高后是否出现 OOM。7.2 vLLM 显存占用构成vLLM 的显存主要分为三部分模型权重模型参数本身的大小。KV Cache每个请求的键值缓存随max_model_len和并发数线性增长。计算图和其他运行时缓存。所以同样的模型--max-model-len越大KV Cache 占用越高并发请求越多需要的 KV Cache 越大。如果显存不够优先调低--max-model-len或--max-num-seqs。7.3 如何降低显存占用常见手段量化模型用 AWQ、GPTQ 量化版权重显存占用明显下降。开启--enforce-eager关闭 CUDA Graph降低峰值显存性能有一定损失。降低--gpu-memory-utilization显式限制 vLLM 可用显存。减少--max-model-len限制单条请求的最大长度。使用--max-num-seqs限制同时处理的序列数。7.4 CPU 推理与 GPU 推理的差异vLLM 主要面向 GPU 推理也支持 CPU 后端但吞吐差距很大。CMP170HX 的优势就是显存带宽没必要退回 CPU 推理。如果你只有一张小显存显卡可以考虑 Ollama 这类轻量工具而不是强行上 vLLM。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后服务无法访问端口被占用或服务未启动检查 vLLM 日志和 port 8000 监听状态换端口或重启容器nvidia-smi 看不到 GPU驱动未装好或供电问题执行 nvidia-smi 查看错误重装驱动检查供电和 PCIe 插槽卡数量少于实际数量PCIe 通道不足查看 lspci 和系统日志减少卡数量更换主板平台模型加载显示显存不足模型权重太大或 gpu-memory-utilization 过高查看日志中的显存分配信息使用量化模型调低显存利用率推理时 OOM并发数过高或 max-model-len 过大观察 nvidia-smi 显存曲线调低 max-num-seqs 和 max-model-lenDocker 内无法调用 GPUNVIDIA Container Toolkit 未安装运行 nvidia-smi 容器测试安装 nvidia-container-toolkit 并重启 Docker批量任务中部分请求失败超时时间不足或并发过高查看服务端日志增加 timeout降低并发数输出结果重复或乱码量化参数不合适或模型文件损坏对比官方模型输出重新下载模型检查生成参数温度过高矿卡散热系统老化检查风扇转速和机箱风道清灰换硅脂调整风扇策略9. 最佳实践与使用建议9.1 第一次不要直接上 32 卡先拿一张卡跑通 CMP170HX 的驱动验证再逐步扩展到 4 卡、8 卡。32 卡涉及供电、散热、PCIe 通道、系统稳定性和网络拓扑问题排查难度是几何级上升。先掌握一张卡的行为再谈规模。9.2 保留一套最小可运行配置把单卡启动 vLLM 的命令保存为一个脚本作为最小可运行配置。后续任何卡数量或模型版本调整都在这个基础上改。这能帮你快速定位是硬件问题还是配置问题。9.3 模型文件、输入素材、输出结果分目录管理建议目录结构/data ├── models ├── inputs └── outputs模型文件放在 models 目录临时输入素材和生成结果分开管理避免容器挂载权限混乱。9.4 批量任务要加日志和失败重试批量推理过程中网络抖动、GPU 显存波动、单次请求超时都可能发生。建议每条请求记录输入 ID、状态码、耗时。失败请求自动重试 2 到 3 次。实时写入进度日志避免任务中断后从头开始。9.5 接口服务控制访问范围vLLM 默认绑定0.0.0.0时局域网内所有人都能访问。如果只做本地测试建议--host 127.0.0.1如果需要局域网访问建议加一层反向代理和访问密钥。9.6 数据合规与授权处理任何文本、图片、声音数据之前先确认是否有权使用这些数据。如果涉及用户个人信息必须遵守相关隐私法规。不要用这个推理服务处理来源不明的内容或生成违法内容。9.7 关注硬件状态矿卡长期高负载运行PCB 和显存老化程度不好判断。建议每张卡单独跑 30 分钟压力测试确认无花屏、无掉卡、无温度异常。检查供电线缆是否老化机箱电源功率是否足够。用nvidia-smi -q -d TEMPERATURE,PERFORMANCE查看每张卡的详细状态。10. 总结与下一步这个项目的核心价值是把“大显存推理”这个原本需要专业服务器硬件才能做到的事情拉回到 DIY 玩家能接触的范围。CMP170HX 单卡 16GB HBM2e搭配 vLLM 做 4 卡或 8 卡张量并行确实能跑很多消费级显卡跑不动的大模型。最先要验证的不是“能不能跑出 2TB”而是三点手头的 CMP170HX 在 Ubuntu 下能否全部被 nvidia-smi 识别。单卡加载一个 7B 模型能否稳定输出。4 卡并行后吞吐有没有明显提升。最容易踩的坑也在三个地方一是 PCIe 通道不足导致卡数量识别不全二是供电和散热不达标导致掉卡三是 vLLM 参数设置不合理导致显存不足或性能不升反降。这个系列后续可以继续做下去。比如CMP170HX 与正常显卡在 vLLM 推理下的性能差异、多机多卡张量并行的网络配置、AWQ 量化模型在矿卡上的显存占用对比、vLLM 与 sglang 的多卡推理体验对比都可以在已经有机器的基础上逐步展开。如果你手里正好有这批卡建议先把 4 卡配置跑通再想 32 卡的事。毕竟“能跑起来”和“能持续稳定跑”之间差着一整套工程化的工作量。先把单卡流程吃透这个项目就成功了一大半。