利用矿卡改装搭建本地AI服务器实战与踩坑复盘

| 我需要一款相对简单但性能尚可的 AI，用于处理一个项目。我没有特别重的需求，只是需要让 AI 访问项目文件，以便它能在其中搜索 bug 等问题。我手头有一台旧电脑，我决定不把它扔掉，而是让它焕发新生，用作 git 服务器（有时也兼作 Minecraft 服务器）。按今天的标准来看，这台 PC 的配置非常老旧：CPU：i7-4790K 4.6 GHz；主板：MSI Z97 Gaming 7；内存：32 GB DDR3 2400；电源：750 W。好吧，我的计划原本只限于维护这台电脑，因为显卡 GTX 1070 过热了。显卡需要彻底重新涂抹硅脂，但散热器的螺丝已经完全滑丝，所以在尝试拆卸散热器时，我不小心用螺丝刀碰掉了几个重要的 SMD 元件。R.I.P. GPU。没有 GPU 的情况下，推理完全依赖 CPU，只有 MoE（混合专家）模型勉强可用，速度约为每秒 10–20 个 token，而密集模型连每秒 3 个 token 都达不到。我甚至还没来得及在 GTX 1070 上测试它，因为我决定先对它进行维修 lol。我开始在二手市场寻找替代品，但很快意识到，对于我想用来实验 AI 的最低预算来说，这成本太高了。直到我把目光投向了矿卡。市面上有很多 cmp40hx、cmp50hx、cmp70hx 和 cmp90 在售，价格相当合理（那是一个月前的事了），考虑到我原本只是在寻找一个便宜的替代品来替换我那块报废的显卡。接近实际装机阶段，我开始计算为了获得 ± 可接受的 AI 性能且速度在可接受范围内，我需要多少显存。受本版块启发，我决定更进一步，选择了一块改装过的 cmp50hx，拥有 20GB 显存并通过 PCIe 改造为 16 通道。很快之后我又买了另一块，这次是未改装的（10GB，仅支持 4 条 PCIe 通道）。所以，总共就是 30GB 显存。这两张卡总共花费了我 250 美元（也是一个月前的事，现在它们的價格突然翻倍了）。幸运的是，就在那时出现了新的驱动程序补丁，几乎完全消除了对它们计算性能的限制，甚至添加了 PCIe 2.0 支持（这些卡原本只有 PCIe 1.1）。我最初尝试了一个新发布的 CMP50HX 驱动补丁，但结果很糟糕，我不得不花大量时间试图让驱动程序正常工作。这些补丁是新的，没有考虑到 20GB 版本。后来作者修复了这个问题，但即便如此，由于其他一些我不想深入讨论的问题，驱动程序对我来说仍然无法工作。我深入挖掘了该驱动的 GitHub Issues，并很快在那里找到了另一位用户发布的一份指南。是的，现在驱动程序可以工作了，显卡被检测到，甚至 PCIe 2.0 也能用，但并非没有问题。指南的作者表示，PCIe 2.0 支持仅在 X99 芯片组上得到确认。好吧，它在 Z97 上也有效，然而从睡眠状态唤醒计算机后，驱动程序会完全崩溃。经过一番调查，我很快得出结论，问题 specifically 出在 PCIe 补丁上。完全禁用睡眠功能解决了我使用它们时遇到的唯一问题。:) 在没有特别修补的驱动程序的情况下，Qwen 3.6 27B 在不启用 MTP 的情况下每秒大约生成 15–20 个 token。MoE 模型更快，每秒给出 45–50 个 token。使用新驱动程序后，性能翻了一番。对于 Qwen 3.8 27B（MTP 开启），我现在每秒大约能得到 30–35 个 token，提示处理速度约为 300–400 个 token（包括随着 token 数量增加而产生的性能下降）。Ornith 1.5 35BA3B (Heretic-MTP-APEX-I-Balanced) 每秒大约给出 80–100 个 token。由于我的电源供应器限制，我将 GPU 的功耗上限设定为 180W，我不希望它们在极限状态下运行，但如果让它们以 225W 运行，肯定会提升速度。总的来说，我为不同量化方式、不同质量和 KV 缓存大小制作了许多预设（我仍需要在实际工作中测试所有这些内容），但如果我们选取较好的选项，我成功获得了一个具有 130k 上下文长度的 Q6K 模型（K – Q8_0 和 V – Q5_1）。我还参考了一份在有限显存下运行具有长上下文的 27B Qwen 模型的指南。采用相同的一般方法，我成功实现了 256k 上下文，并使用 K 和 V 的 Q8_0 量化。不过速度较慢，大约每秒 10–14 个 token，提示处理速度约为每秒 40–50 个 token。也许我可以进一步调整参数。我需要这种预设配置来执行可以留到夜间生成的任务 :3 总体而言，我对结果感到满意。现在我遇到的主要问题（不包括驱动程序）：显存不足。理想的方案是拥有两张显存容量相同的相同显卡。你可以以张量模式运行密集模型，均匀分配权重，从而几乎免费获得更高的生成速度 + 容纳完整上下文。我尝试了多种 Qwen 3.8 27B 量化变体，但在 1,1 张量分割下唯一能正常运行的只有 Q4KM（Unsloth 版本），配合 mtp = 约每秒 40 个 token。然而，留给 KV 缓存的空间严重不足，因为它与模型权重一起分配，而第二张 10GB 显卡成为了瓶颈。如果不使用 mtp，以 1,1 分割运行模型基本上就失去了意义。PCIe 2.0 和通道数量可能也在此处发挥了重要作用。原则上可以通过向第二块 GPU 增加更多 PCIe 通道并购买 NVLink 线缆（谁真的会这么做？）来解决这个问题，但我决定为了每秒多获得 5–6 个 token 并不值得。没有 NVMe SSD。是的，所有模型都从 SATA SSD 加载，因此速度约为 500MB/s。这太糟糕了。主板实际上有一个带有 PCIe 2.0 x2 接口的 M.2 SATA 插槽，但即使其每秒 1GB 的速度对于快速加载模型来说也太慢了。这可以通过在其中一个 PCIe 插槽中安装扩展卡来解决（有一个空闲的 PCIe 3.0 x4 插槽），但考虑到我正在利用现有硬件构建一个廉价系统，并且只为获得可接受的结果进行最低限度的额外支出，目前这些设备（包括 SSD）的价格太高了。模型切换需要 1–2 分钟。不过无所谓。（并非无所谓，我要买一块便宜的二手 256GB NVMe SSD :D）RAM 容量和 Linux（Ubuntu Server 24.04）。除了 AI，我还在服务器上运行 GitLab。这里的问题在于：加载模型后，系统会将所有可用 RAM 用于缓存模型文件。我说的是文件缓存，而不是 KV 缓存。系统为其他用途仅留下约 200–300MB 的空闲 RAM。因此，openwebui 和 gitlab 在模型加载后开始变得卡顿，我安装的 kde plasma 界面也是如此。我不太明白为什么 linux 决定将缓存保留到最后时刻，而不是将其释放给其他程序使用。我尝试在模型预设中添加 no-mmap 参数，但没有任何帮助，我不得不在加载模型后手动清除缓存，这显然是不可接受的。我和 chatgpt（还有谁呢？）一起编写了一个命令，该命令会启动模型然后清除缓存。结果发现这破坏了 llama-server，导致模型切换时不再卸载之前加载的模型。llama-server 的灵活性在于：预设列表定义在 models.ini 文件中，每个参数都以键值对格式存在。根据指南，为了以 256k 上下文运行 Q6K，我需要设置 GGML_CUDA_DISABLE_GRAPHS=1，这会应用于整个 cuda 环境，并且在卸载模型后仍然保持激活状态。这是不可取的，因为启用它会导致我在其他预设上每秒损失 1–2 个 token。因此，对于某一个特定的预设，我需要启用 cuda graphs，而对于其他预设，则需要禁用它们。llama-server 的解析器不支持此类操作，手动处理也不是一个可行的选择。加上 ram 缓存卡住的其他问题，这促使我开发了一种替代方式来启动模型并将请求代理到 llama-server。为了解决第 3 和第 4 个问题，我制作了一个启动器（好吧，chat

原文超出正文长度上限，此处截断——上游还有内容，完整版见上方「原文 ↗」。