32卡CMP170HX组256GB显存池：vLLM多卡推理机完整拆解

大模型推理vLLM多卡并行
于 2026-08-30 04:26:02 修改
·本内容遵循CC 4.0 BY-SA版权协议

做本地大模型推理，最痛苦的事情是什么？很多人会脱口而出“显存不够”。一张消费级旗舰卡哪怕堆到 24GB，面对 72B 甚至 671B 的模型，也只能靠量化、上下文裁剪和推理加速库反复“凑合”。于是，越来越多人在想另一条路：能不能用便宜的专业卡，通过多卡并联，凑出一台显存容量远超常规的“家用超级计算机”，再用 vLLM 这类推理引擎把它物尽其用。

这个思路听起来很美好，但网上流传的“32 块 Nvidia CMP170HX 打造 2TB 显存”这类说法，恰恰需要先泼一盆冷水。CMP170HX 是一张很特殊的卡：它有 HBM2e 显存、有安培架构的计算核心，但单卡显存只有 8GB。32 块卡严格按硬件容量相加是 256GB，不是 2TB。真正的 2TB 显存，需要的是 32 块 64GB 级别的计算卡，那成本和供电规模完全是另一回事。

但这并不意味着“32 块 CMP170HX”没有价值。256GB 显存已经能让你非常从容地跑 72B 级模型、开大上下文、同时服务多个模型实例。这篇文章不是去复述“矿卡神教”的营销话术，而是从硬件选型、PCIe 通道、供电散热，到 vLLM 部署、TP 并行和排错，完整拆解一台多卡 DIY 推理机的真实工程路径。如果你正在规划自己的多卡显存池，或者只是想知道“堆显卡跑 vLLM 到底靠不靠谱”，这篇可以直接作为你的第一份参考。

1. 为什么有人要 DIY 一台“32 卡推理机”

1.1 大模型为什么如此“吃显存”

大模型推理时，显存主要有三块去向：模型权重、激活值、KV Cache。

以 72B 模型为例，BF16 格式下仅权重就需要约 144GB。即便用 INT4/AWQ 量化，权重也要压缩到 40 到 50GB 左右。KV Cache 则和请求并发数、上下文长度线性相关。上下文越长、并发越高，KV Cache 增长越迅猛。

所以当你只有一张 24GB 显卡时，能做的选择非常有限：要么选 7B 到 14B 的小模型，要么把 72B 模型量化到极低精度，要么牺牲并发和上下文长度。这本质上不是“优化”，而是显存天花板带来的妥协。

1.2 为什么要多卡并联

多卡并联不是“多买几块显卡插上去”这么简单，它的核心目的有两个：

第一，把模型权重摊到多张卡上，让显存容量足够容纳大模型。vLLM 的 tensor parallel 会把 Transformer 层切分到多张 GPU 上，每一层都分布在多卡中，因此总显存需求被均摊。

第二，通过并发和连续批处理，提高推理吞吐。单卡一次只能处理有限的 batch，多卡并行可以让更多请求同时得到计算资源。

因此，多卡系统的意义不在于“单卡跑得有多快”，而在于“同时能装下多大模型、服务多少并发”。

1.3 先纠正标题：32 块 CMP170HX 到底有多少显存

CMP170HX 的常见公开参数是 8GB HBM2e，那么：

TEXT
32 张 × 8GB = 256GB

距离“2TB 显存”差了整整 8 倍。如果目标是 2TB 显存，应该换成 32 块 64GB 的卡，或者至少是 8 块 256GB 的集成平台。两者成本和供电完全不是一个量级。

所以在读后面的内容之前，请你先建立准确预期：这篇文章里讨论的 32 卡方案，实际显存池是 256GB。但 256GB 已经足够覆盖 72B 模型的 FP16 推理、多模型并行部署、中长上下文批量请求等常见场景。真正的“2TB 显存跑超大模型”，是另一个量级的工程问题。

2. CMP170HX 核心参数与选型逻辑

2.1 它到底是一张什么卡

CMP170HX 是 NVIDIA 早期为加密货币算力市场推出的专业卡，完整名称是 CMP 170HX。它的几个关键公开参数如下：

参数项 常见公开参数
架构 Ampere，GA100 系列核心
CUDA 核心 约 2560
显存 8GB HBM2e
TDP 约 250W
供电接口 1 个 8pin
视频输出 无
NVLink 不支持
官方定位 无图形输出，面向计算/采矿场景

这张卡最让人心动的是 HBM2e 显存。HBM 显存的核心优势是带宽极高，比普通 GDDR6 高很多，对 LLM 推理来说，显存带宽往往比算力更能决定“能不能跑得动”大模型。

但它的短板也很明显：单卡 8GB 容量太小，无视频输出，二手卡普遍来自矿场，没有官方质保，而且对普通主板来说，插一块两块还能玩，插 8 块以上就不是普通消费级平台能支撑的了。

2.2 和常见消费卡、计算卡对比

型号 显存 显存类型 是否支持 NVLink 二手流通情况
CMP170HX 8GB HBM2e 否 矿卡市场较多
RTX 3090 24GB GDDR6X 否 较多
RTX 4090 24GB GDDR6X 否 少
A100 40GB 40GB HBM2e 支持 渠道稳定但贵
A100 80GB 80GB HBM2e 支持 极贵

从性价比看，CMP170HX 在二手市场曾以极低价格提供 HBM2e 高带宽，这让它成为很多“显存容量敏感型”项目的组装基础。但注意，价格波动极大，而且矿卡稳定性差，不适合直接用在生产环境。

2.3 为什么 CMP170HX 适合 vLLM 推理

vLLM 是当前非常流行的 LLM 推理引擎，它通过 PagedAttention 优化 KV Cache，并通过 continuous batching 让 GPU 吞吐量大幅提升。对多卡环境，vLLM 支持 tensor parallel，可以把模型均匀分布到多张显卡上。

CMP170HX 恰好提供了一个极低成本的“安培架构计算核心 + 高带宽显存”组合。单卡 8GB 虽小，但 8 张、16 张、32 张放到一起后，总容量就变得可观。虽然不是每张卡都能完全跑满 vLLM 的算子，但对显存占用为主要瓶颈的推理场景，这套组合的方向是对的。

前提是：你愿意接受矿卡的物理状态，有耐心处理驱动、供电和散热问题。

3. 整机硬件设计：不是 “显卡插满” 就行

3.1 真正的第一个瓶颈：PCIe 通道

很多人以为 DIY 多卡机箱就是把显卡插进主板的 PCIe 插槽，实际上最大的坑在“通道数不够”。

消费级主板，比如 Z790、X670E，通常只有 20-24 条 PCIe 通道。插一张 x16 显卡、一张 NVMe SSD，通道就非常紧张。想插 4 张、8 张、16 张显卡，必须考虑以下方案：

  • AMD TRX40 / TRX50 平台：Threadripper / Threadripper Pro 提供大量 PCIe 通道。
  • AMD EPYC 单路/双路平台：通道数更多，适合服务器机箱。
  • Intel Xeon W 系列：也提供较多通道。
  • 通过 PCIe 交换机扩展：适合机架式多 GPU 模块。

对于 32 卡目标，单块主板直接插 32 张卡完全不现实。更稳妥的设计是：8 卡一个节点，用 4 个节点组成总集群，或者使用支持 PCIe Switch 的 8-GPU 机箱。

3.2 主板、CPU、内存选型建议

组件 建议方向
主板 服务器或工作站板，确认 PCIe 拆分功能支持
CPU 高核心数工作站 CPU 或服务器 CPU，至少提供足够 PCIe 通道
内存 大容量 DDR4/DDR5 内存，多卡启动时内核参数、模型缓存和系统本身都会显著占用内存
系统盘 NVMe SSD 或企业级 SSD，模型文件建议放一个独立的大容量 NVMe
网络 至少千兆管理网口，多节点时建议 10G 或更高

内存很容易被忽视。多卡加载模型时，如果先把权重从硬盘读到内存再分发到不同 GPU，那么内存太小会直接卡死启动过程。以 72B AWQ 模型为例，模型文件大约 40GB 到 50GB，系统进程、CUDA context、加载中间态叠加后，64GB 内存只能说“勉强”，建议至少 128GB。

3.3 供电和电源：一切 DIY 项目的分水岭

核算电功非常重要：

TEXT
GPU 总功耗 = 250W × 32 = 8000W
加上 CPU、主板、散热等，整机功耗很容易超过 9000W。

9000W 对一个“家用”环境意味着什么？普通家庭墙插通常只有 220V 10A 或 16A 的供电能力，10A 约 2200W，16A 约 3520W。吹风机、空调和电暖器同时开都会跳闸，更不用说 9000W 的 GPU 集群。

所以，如果你真的想搭建 32 卡系统，请不要把它当作家用电器。你需要：

  • 独立工业配电箱；
  • 至少 32A 或更高规格的空气开关；
  • 多路独立供电，而不是把所有电源插到一个排插；
  • 建议使用服务器机柜、理线架，避免线材过热。

在后续系列文章中，如果你看到“#001”，第一个验证目标应该是 1 卡或 4 卡系统，而不是盲目上 32 卡。

3.4 散热与机箱

CMP170HX 多为涡轮散热设计，有利于在 1U/2U 服务器中统一进风出风。但矿卡长期运行后，散热鳍片积灰严重，风扇轴承磨损，硅脂可能干裂。上机前建议：

  • 拆开检查风扇是否正常；
  • 重新涂抹硅脂；
  • 清理散热鳍片；
  • 测试满负载温度，避免长期超过 85 度。

如果是裸机架，务必保证足够的风道，否则 GPU 之间的热浪会互相影响。

4. 软件环境与驱动部署

4.1 操作系统选择

vLLM 目前对 Linux 的支持最成熟。建议使用 Ubuntu 22.04 LTS 或 Ubuntu 24.04 LTS。Windows 10/11 下跑 vLLM 的老问题依然存在：vLLM 原生不支持 Windows，WSL2 下能用但 GPU 通信、NCCL 行为、并行性能都会打折。如果你只是想跑 Ollama 或者 llama.cpp，Windows 没问题；但你要跑 vLLM 多卡 tensor parallel，就老实上 Linux。

TEXT
Ubuntu 24.04 LTS

说明：具体版本不是必须最新，关键是稳定和驱动兼容。NVIDIA 官方长期支持分支的驱动更适合服务器。

4.2 安装 NVIDIA 驱动

CMP170HX 没有图形输出，也没有消费级游戏驱动的定位。在 Linux 下，你通常需要从 NVIDIA 官方数据中心/计算驱动分支中选择合适的版本。安装前建议先卸掉系统自带的 nouveau 驱动。

常用安装流程：

BASH
sudo apt update
sudo apt install -y build-essential
# 先禁用 nouveau 模块（写入 /etc/modprobe.d/blacklist-nouveau.conf）
echo "blacklist nouveau" | sudo tee /etc/modprobe.d/blacklist-nouveau.conf
echo "options nouveau modeset=0" | sudo tee -a /etc/modprobe.d/blacklist-nouveau.conf
sudo update-initramfs -u
sudo reboot

重启后，使用 NVIDIA 官方 .run 安装包或 apt 仓库安装驱动。这里不写死版本号，因为 NVIDIA 驱动版本更新很快，且不同 CUDA 版本对驱动版本有最低要求，请以官方页面给出的稳定版本为准。

BASH
wget https://us.download.nvidia.com/X.Y.Z/NVIDIA-Linux-x86_64-X.Y.Z.run
sudo bash NVIDIA-Linux-x86_64-X.Y.Z.run --no-cc-version-check

安装完成后执行：

BASH
nvidia-smi

正常会看到多张 CMP170HX 卡。如果你看到卡但显示“No supported devices”或“Unknown”，先检查驱动版本和卡是否被正确供电。

4.3 安装 Docker 与 NVIDIA Container Toolkit

推荐使用 Docker 来部署 vLLM，避免污染宿主机 Python 环境。

BASH
# 安装 Docker Engine 略，不同发行版命令有差异
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
 
sudo apt update
sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

验证：

BASH
docker run --rm --gpus all nvidia/cuda:12.3-base-ubuntu22.04 nvidia-smi

此时 Docker 容器内应能看到全部 GPU。

5. vLLM 部署与模型加载

5.1 模型准备

以 Qwen2.5-72B-Instruct 为例，FP16 权重约 144GB，INT4/AWQ 卷积后约 40GB 到 50GB。对 8 卡 x 8GB = 64GB 的节点，只能用 AWQ/GPTQ 量化模型。对 32 卡 x 8GB = 256GB 的完整目标，FP16 也有机会跑，但要预留 KV Cache，所以依然建议量化。

下载模型可以使用 ModelScope，国内网络更稳定：

BASH
pip install modelscope
modelscope download --model Qwen/Qwen2.5-72B-Instruct-AWQ --local_dir /data/models/Qwen2.5-72B-Instruct-AWQ

5.2 启动 vLLM 服务

项目需要创建一个模型目录并挂载进容器：

BASH
mkdir -p /data/models
docker run -d --name vllm-gpu \
--gpus all \
--shm-size=16g \
-p 8000:8000 \
-v /data/models:/models \
vllm/vllm-openai:latest \
--model /models/Qwen/Qwen2.5-72B-Instruct-AWQ \
--tensor-parallel-size 8 \
--gpu-memory-utilization 0.90 \
--max-model-len 8192 \
--enforce-eager

这条命令是一次最小可运行示例。如果你确认某个节点只有 8 张卡，可以先试 --tensor-parallel-size 8。如果卡多，可以换成 --tensor-parallel-size 16 或 32，但并不是越大越好，原因在 6.2 节会详细讲。

5.3 关键启动参数说明

参数 作用 注意点
-p 8000:8000 暴露 OpenAI 兼容 API 如果不用 Docker，直接 --port 8000
-v /data/models:/models 挂载模型目录 保证容器内可读取模型文件
--tensor-parallel-size 张量并行卡数 必须是 GPU 总数的约数
--gpu-memory-utilization 每张卡显存占用比例 默认 0.9，如果 OOM 可降到 0.8
--max-model-len 最大序列长度 设置过大极易 OOM
--enforce-eager 禁用 CUDA graph 捕获 首次启动或显存不足时更稳，但性能略降

--enforce-eager 是一个很实用的调试选项。vLLM 默认会用 CUDA graph 来降低算子调用开销，但在驱动兼容性不佳、显存紧张或首次启动时，CUDA graph capture 可能失败，导致 OOM。显式加上 --enforce-eager 后，vLLM 会跳过这层优化，能更稳定地启动和加载。代价是请求延迟会变高，推理吞吐也会下降。排障时先用它，稳定后再去掉。

5.4 测试 OpenAI 兼容接口

启动日志末尾会显示类似：

TEXT
INFO: Started server process [1]
INFO: Uvicorn running on http://0.0.0.0:8000

调用模型列表：

BASH
curl http://localhost:8000/v1/models

调用对话接口：

BASH
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "/models/Qwen/Qwen2.5-72B-Instruct-AWQ",
"messages": [{"role": "user", "content": "写一段 python 代码计算斐波那契数列"}],
"max_tokens": 128,
"temperature": 0.3
}'

Python 端请求也很简单：

PYTHON
import requests
 
url = "http://localhost:8000/v1/chat/completions"
payload = {
"model": "/models/Qwen/Qwen2.5-72B-Instruct-AWQ",
"messages": [
{"role": "user", "content": "解释一下 vLLM 的 PagedAttention 是什么"}
],
"max_tokens": 256,
"temperature": 0.5,
}
resp = requests.post(url, json=payload, timeout=120)
print(resp.json()["choices"][0]["message"]["content"])

6. 运行验证与性能观察

6.1 确认多卡被正确使用

启动后，在宿主机执行：

BASH
nvidia-smi

你会看到每张卡的显存占用、进程 PID 和功率。正常状态下，每张卡都应有 vLLM 进程占用显存。

也可以使用 nvidia-smi top -u 观察利用率：

BASH
nvidia-smi top -u -l 2

如果只有一张卡在跑、其他卡全部闲置，大概率是 --tensor-parallel-size 设置不正确，或者模型被重复加载到单卡导致 OOM。

6.2 张量并行并不是卡数越多越好

这里要说一个很多人容易误解的点：tensor parallel 需要卡与卡之间频繁同步梯度、激活值和 KV Cache。CMP170HX 不支持 NVLink，跨卡通信依赖 PCIe 总线。当 TP 规模超过 8 甚至 16 张时，通信开销可能抵消多卡带来的吞吐提升，而且会让单次请求变慢。

因此，如果你的实际目标是“同时服务更多用户”，多复制几个 vLLM 实例、每个实例用 4 卡或 8 卡，往往比把所有卡塞进一个 TP 实例更划算。只有当单个模型大到必须用 16 卡、32 卡才能放进显存时，再考虑大 TP 规模。

6.3 通过 vLLM 日志判断成功

vLLM 启动时如果出现类似日志，说明模型加载成功：

TEXT
(Benchmark) Input throughput: ...
Output token throughput: ...

如果看到 RuntimeError: NCCL error、CUDA error: out of memory 或 No available memory for KV cache，说明显存或通信环境有问题。

7. 常见问题与排查思路

问题现象 可能原因 排查方式 解决方案
启动后只有 1 张卡被识别 PCIe 供电不足或主板通道不够 `lspci grep NVIDIA，nvidia-smi` 对比
报 CUDA error: out of memory 模型权重大，KV Cache 峰值超过显存 观察启动日志中 KV Cache 大小 减小 --max-model-len，降低 --gpu-memory-utilization，改用量化模型
报 NCCL error: unhandled cuda error 多卡通信失败，可能 P2P 受限 用 nvidia-smi topo -m 查看拓扑 关闭 P2P 或改用 pipeline parallel，调整 TP 规模
首次启动卡在 CUDA graph capture 驱动或运行环境兼容性问题 去掉 --enforce-eager 复现 先加 --enforce-eager 启动，确认稳定后去掉
显卡温度超过 85 度 矿卡硅脂老化、风扇积灰 nvidia-smi -q -d TEMPERATURE 清理散热、换硅脂、改善机箱风道
请求响应很慢 TP 规模过大，跨卡通信瓶颈 对比不同 TP 规模压测 减小 --tensor-parallel-size，增加多实例并行
Windows 下无法启动 vLLM vLLM 原生不支持 Windows 查看日志中的 CUDA/NCCL 报错 用 Linux / WSL2 / Docker，推荐 Linux

8. 成本、安全与工程边界

8.1 电费账，一定要提前算

8 卡节点大约 GPU 功耗 2000W，加上 CPU 和散热，整机按 2300W 算。一天 24 小时：

TEXT
2300W × 24h = 55.2kWh

如果一度电 0.6 元到 1 元，一天电费就是 33 到 55 元，一个月约 1000 到 1600 元。这只是 8 卡节点。32 卡则要翻四倍，每月电费接近 4000 到 6000 元甚至更高。这还没算空调散热、机柜、维护时间成本。

所以，“家用”应该被理解为“非数据中心环境下的试验性质部署”，而不是“像家用电脑一样随便放”。

8.2 矿卡不是生产级卡

CMP170HX 是矿卡，二手流通时往往已经经历长时间高负载运行。它们没有官方质保，显存颗粒体质可能不一致，风扇、供电模块也可能有隐性故障。我个人建议：

  • 不要用矿卡搭建生产环境；
  • 不要用矿卡存放没有任何冗余的关键业务；
  • 实验环境测试模型、学习部署、跑通流程，可以接受。

8.3 安全边界

涉及大功率供电，务必遵守最小权限和安全原则。接线要合格，机房或机柜要接地，不要私拉乱接。涉及任何生产服务器、数据库或线上系统时，所有变更必须先备份、先验证、可回滚。本文的配置和命令都应在独立测试环境中执行。

9. 这个项目的真正价值在哪里

回到标题中的“VLLM 推理”和“DIY 超级计算机”。如果你想从这篇文章里带走一个判断，那就是：

多卡 CMP170HX 的价值是把“显存容量”和“单卡显存带宽”做了一个极高性价比的组合。你不需要花几十万买 A100，就能在 256GB 总显存上跑 72B 甚至更大规模的推理模型。但代价是物理机房的折腾、功耗管理、矿卡的不稳定性和大量时间。

如果你是一名个人开发者，想在本地跑通 Qwen2.5-72B、DeepSeek 蒸馏模型或者多路 RAG 服务，可以先用 4 卡或 8 卡节点验证，把 vLLM 的 TP 集群摸熟，再决定要不要向 16 卡、32 卡扩展。如果你是一位团队负责人，想用这套方案支撑线上服务，我的建议是不要省这笔算力成本，云上按需租用弹性实例可能更划算。

这套 DIY 项目的本质，是用工程经验换硬件成本。你要先确定自己有多余的时间、动手能力和风险承受能力，再决定是否入坑。

10. “#001 中配”系列下一步

这一篇其实只完成了“需求分析、硬件事前规划、vLLM 最小部署”三件事。后续系列至少还有这几个方向值得继续深入：

  1. 8 卡节点的完整硬件组装与温度压力测试；
  2. 多节点 vLLM 部署，包括 Ray、NCCL、网络配置；
  3. vLLM 参数调优，从 --max-model-len、--gpu-memory-utilization 到量化格式选择；
  4. 多模型同时服务与 API 网关层设计；
  5. 如果未来真的以 2TB 显存为目标，需要换哪一类 64GB 单卡计算卡，以及整套供电和机架方案该怎么重构。

我建议先从“4 卡或 8 卡跑通一个 72B AWQ 模型”这一步开始。不要一上来就幻想 32 卡。硬件和软件都验证通过后，再做扩容，这样踩坑成本最低，也最符合工程迭代的节奏。如果你也在折腾多卡 vLLM 推理，可以收藏这篇文章，下一期我们会进入实际组装和压力测试环节。

CMP170HX矿卡跑vLLM：32卡≠2TB显存，多卡推理实战指南
本文深入解析NVIDIA CMP170HX矿卡在vLLM大模型推理中的实际应用，澄清'32卡=2TB显存'的常见误解，指出其单卡仅8GB HBM2e、无NVLink、PCIe x4带宽等硬件限制。重点阐述vLLM部署要点：单卡适配量化7B模型、--enforce-eager降显存技巧、数据并行优于张量并行、CPU Offload扩展逻辑内存池，以及多卡平台选型、驱动配置、监控与工程避坑指南。
weixin_30312563
398
32块CMP170HX矿卡搭建vLLM多卡推理服务器实战指南
本文详解使用32块NVIDIA CMP170HX矿卡搭建vLLM多卡推理服务器的完整实践，涵盖Ubuntu系统下NVIDIA驱动与Docker环境配置、4/8卡张量并行启动、OpenAI兼容API调用、显存占用分析（模型权重/KV Cache/运行时缓存）、并发测试与批量离线推理，并强调PCIe通道规划、供电散热限制及生产化部署建议（反向代理、访问控制、日志重试）。核心聚焦vLLM在高显存矿卡上的可行性验证与工程落地。
weixin_34198881
413
32块CMP 170HX矿卡拼出2TB显存：VLLM大模型推理集群实战
本文详细阐述如何利用32块NVIDIA CMP 170HX矿卡（单卡16GB HBM2E）构建总显存达2TB的大模型推理集群，并基于VLLM框架实现高效部署。内容涵盖硬件选型（强调PCIe通道与多机架构）、Ubuntu系统配置、CUDA/NVIDIA驱动安装、VLLM多卡及多节点启动、张量并行与Continuous Batching优化、显存利用率调优（gpu-memory-utilization）、KV Cache管理及常见问题排查。方案聚焦低成本大显存推理，适用于离线批量与中低并发在线服务。
weixin_33924220
502
【重磅】NVIDIA CMP 170HX 矿卡解锁：8GB→64GB、算力接近「真 A100」完整教程（含验证）
本文详解NVIDIA CMP 170HX矿卡通过cmpunlocker工具在nvidia-open驱动层实现SM启用、HBM显存扩容（8GB→64GB/10GB→40GB）及PCIe升频至Gen2的技术方案。核心依赖Linux环境、nvidia-open 610.43.0x驱动、关闭Secure Boot及冷重启。验证涵盖显存容量、PCIe链路速率与算力提升，使其逼近A100同芯性能表现。
毮㷣
908
矿卡CMP 170HX的AI推理性能优化实战
本文详述NVIDIA CMP 170HX矿卡在AI推理场景下的性能解锁与优化实践。通过禁用FMA指令、适配llama.cpp、调优内存子系统及混合精度策略，FP32性能提升15.9倍，Qwen2.5-1.5B模型4-bit推理达A100的78%。重点利用其1493GB/s HBM2e带宽优势，适用于边缘推理、轻量训练与带宽敏感型科学计算，并给出散热、供电与驱动适配等关键避坑指南。
Claire_ljy
548
用32块矿卡堆出2TB显存，DIY超级计算机跑vLLM推理
本文详细介绍了使用32块NVIDIA CMP170HX矿卡构建2TB显存系统，部署vLLM进行大模型推理的完整DIY方案。涵盖硬件选型、Linux环境配置、多卡驱动与CUDA适配、vLLM安装与Tensor Parallel启动、超长上下文与高并发测试、OpenAI兼容API调用、显存与PCIe通信性能观测，以及多卡常见问题排查与最佳实践。重点验证了vLLM在无NVLink、纯PCIe互联环境下的稳定性与扩展性。
weixin_33910759
311
NJI纽疆科技联合广普超算推出NVIDIA英伟达首款CMP 170HX最强矿卡
NJI纽疆科技与广普超算合作推出的NVIDIA CMP170HX矿卡，针对以太坊挖矿市场，拥有1320MH/s的强大性能，2200W低功耗，预估市场需求大。
越星河
1674
矿卡CMP 40HX实战：优化Stable Diffusion WebUI，实现AI绘画效率跃升
本文聚焦于NVIDIA矿卡CMP 40HX在Stable Diffusion WebUI中的高效部署与调优，涵盖PyTorch 2.0.1+cu118环境配置、xformers 0.0.20适配、关键启动参数（如--no-half、--xformers）、显存监控与SDXL模型低显存运行技巧，并验证其在512×512图像生成中3–5秒/图的性能表现，适用于8GB显存AI绘画场景。
谷桐羽
452
矿卡CMP 40HX跑SDXL 1.0实测：1024大图1分钟出，Stable Diffusion进阶玩法
本文详述基于NVIDIA CMP 40HX矿卡（8GB GDDR6显存、Turing架构）成功运行Stable Diffusion XL 1.0的全流程实践，涵盖Tensor Core利用、xformers与WebUI参数优化、DPM++ 2M采样器调优、Tile分块渲染及模型瘦身等关键技术，实现1024×1024图像平均58秒生成，验证低显存硬件适配SDXL的可行性。
mzhdsb
602
捡漏矿卡CMP 40HX，保姆级Stable Diffusion WebUI配置教程（含xformers避坑指南）
本文聚焦于NVIDIA CMP 40HX矿卡在Stable Diffusion WebUI上的完整部署与优化，涵盖硬件选购验证、Windows/Linux系统环境配置、定制化WebUI安装、xformers手动编译避坑、显存受限下的启动参数调优（如--medvram/--lowvram）、SDXL模型适配方案，以及LoRA加载、采样器选型、系统监控与自动化性能评估等关键技术点，专为预算有限但追求AI绘画生产力的用户设计。
死月絲卡蕾特
534
AI绘画 矿卡CMP 40HX 五秒出图（2023.8.6更新）
文章介绍了如何优化华硕CMP40HX矿卡在StableDiffusion的webui中的性能，包括更新pytorch到2.0.1版本，升级xformers库至0.0.20，以及调整命令行参数以提升运行效率。此外，建议使用systeminfo插件监控性能，并分享了在Ubuntu和Win11环境下不同采样器的出图速度。
germandai
7428
老黄刀法被破解：10GB老矿卡“开核”80GB，身价暴涨20倍
NVIDIA CMP 170HX专用矿卡被研究人员通过Falcon固件漏洞绕过OTP硬件限制，实现显存扩容（10GB→80GB）与算力恢复（FP32达12.2 TFLOPS），显著提升本地AI模型部署能力。该破解依赖DMA越界与栈溢出漏洞获取固件最高权限，但PCIe带宽、ECC、HBM等物理限制仍未解除，且稳定性与长期可靠性存疑。
电手
244
不到 300 元的高性价比显卡 CMP 40HX | 核显主机升级首选（含清灰、换硅脂）
本文介绍了如何对价格低于300元的NVIDIA CMP 40HX显卡进行整备，包括清灰、更换硅脂和导热垫等操作。通过实际测试，展示了清灰前后显卡温度的变化情况，并分析了其在游戏和视频处理方面的表现。
只抄
6512
咸鱼大量流出485元万丽90HX显卡，10G大显存容量，性能对标RTX 3080显卡，弊端同样明显，你敢入吗？
本文介绍了咸鱼市场上大量流出的万丽90HX矿卡，基于Ampere架构GA102核心，配备10GB GDDR6X显存，功耗320W，专为挖矿设计，无显示输出接口。虽参数接近RTX 3080，但无法直接用于游戏，魔改难度大，存在高溢价与风险问题，适合资深玩家谨慎入手。
二爷记
3668
矿卡40HX在linux下AI绘画简单流程
本文针对Linux初学者，指导如何利用Ubuntu23.04进行AI绘图性能提升。文章提到华硕CMP40HX显卡的安装注意事项，强调驱动程序选择和安装的复杂性，尤其是NvidiaCMP40HX的驱动问题，推荐使用DKMS以支持CUDA。还提供了一个简单的安装流程，并分享了优化显卡使用的技巧，包括开放端口、允许不安全插件访问等。
germandai
5382
矿卡40HX上跑stable Diffusion XL 1.0模型的方法
文章介绍了作者在尝试运行SDXL1.0时遇到的内存不足问题，通过将优化参数改为--lowvram并调整torch.autocast设置，解决了40HX卡在全精度下模型过大导致的内存问题。同时提到，基础模型大和40HX全精度下vram占用大是主要原因，以及后续的生成速度和时间数据。
germandai
2129
汇编语言 CMP指令
本文详细介绍了CMP指令在汇编语言中的使用，包括无符号数和有符号数的比较，并展示了如何通过CMP指令统计数据段中特定数值的个数。CMP指令会修改标志位，这些标志位可以用于后续的条件跳转，实现类似IF语句的功能。文章还提供了多个示例来解释不同比较结果时标志位的状态变化，以及如何根据标志位进行条件判断。
ʚVVcatɞ
95703
cmp_luasnip 与 nvim-cmp 集成：多源补全配置的最佳实践
本文详解cmp_luasnip与nvim-cmp的集成配置，涵盖安装、高级选项（如条件过滤禁用、自动片段控制、缓冲区级配置）、多源补全优先级设定、自定义片段管理、性能优化（缓存与延迟加载）及常见故障排查。重点突出其在React/JSX和Python开发中的实际应用，以及与LuaSnip、LSP、telescope.nvim等插件的协同机制，旨在构建高效、稳定、可扩展的Neovim智能补全环境。
田桥桑Industrious
612
物联网平台组成部分CMP、DMP、AEP、BAP
本文详细解析了物联网平台的四大分类：连接管理平台CMP、设备管理平台DMP、应用使能平台AEP和业务分析平台BAP。CMP负责连接性管理，DMP提供设备管理，AEP加速应用开发，BAP进行大数据分析。
_s牧之
24297
显卡杀手！超高性价比真矿渣显卡，砍掉输出接口的GTX 1660S矿卡！
本文介绍了30hx显卡，它是矿潮时期英伟达的专业矿卡，无显示接口。其性能与1660s相近，但有一定损失，需补电容保X16通道。制约游戏性能的主要是PCI - E版本问题。目前某鱼价位230元左右，不适合小白，还提及往期DIY装机等相关内容。
二爷记
19664