2080 Ti 魔改交火--本地部署大模型（3）

第一篇介绍了两张"变异"显卡的来历，上一篇则是 Intel 显卡的失败尝试。这一篇记录双 RTX 2080 Ti 22GB 时期的部署实践，以及那张非 A 核心（TU102-300）魔改卡从首次故障到最终退役的完整过程。

为什么是双卡

目标模型是 Qwen3.8-27B 的 UD-Q6_K_XL 量化，权重 23.6GB——单张 22GB 的 2080 Ti 连权重都装不下，更不用说 KV 缓存和计算缓冲区。两张 22GB 拼出 44GB，是这台机器上唯一可行的方案，双卡张量拆分（tensor split）因此成为标配：模型层被切分到两张卡上，每步推理跨卡交换激活值。

平台

承载这一切的主机，本身也是同一条低成本路线的产物：

• 主板：华南金牌 X99-TF，提供两条 PCIe 3.0 x16 插槽，容纳两张显卡加 NVLink 桥；
• CPU：Xeon E5-2696 v3（18 核 36 线程，2.30GHz），服务器拆机件。推理的重活在显卡上，它只负责调度、KV 管理与 MoE 模型的专家层 offload 计算；
• 内存：四条 32GB DDR3 ECC REG（共 128GB，1866MT/s），四条插槽各占一个内存通道，四通道全开，理论带宽约 60 GB/s——比普通台式机的双通道 DDR4 还要快。这类服务器内存价格低廉，却为超大模型的内存卸载留足了空间与带宽——104GB 的 Flash-Next 模型正是靠 mmap 驻留内存、按需分页才得以在这台机器上运行；
• 系统与服务化：Ubuntu 26.04 LTS，NVIDIA 专有驱动（当时为 595 系）。推理服务注册为 systemd 用户单元开机自启，对外暴露 OpenAI 兼容 API（127.0.0.1:8080），日常通过 opencode 交互——一个运行在终端里的 AI 编程 agent，8 月中旬装上后就成了这套服务的主要客户端，配置方法见第五篇。

部署实践

llama.cpp 双卡张量拆分

后端最初是 llama.cpp 的 CUDA 构建（--split-mode tensor，经 NVLink 互联）。2026 年 8 月 25 日双卡首次跑通，短上下文下 decode 峰值达到 61 t/s。过程中踩过几个值得记录的坑：

• NCCL 跨卡归约会崩溃，必须设置 GGML_CUDA_ALLREDUCE=internal 改用 llama.cpp 内部实现；
• 2080 Ti 没有 Resizable BAR，开启 mmap 时 llama.cpp 会尝试分配约 1GB 的 host-visible 显存缓冲区，在这张卡上必然失败，报出的却是具有误导性的 “out of memory”——27B 方案必须 --no-mmap；
• GSP 固件需整体关闭（NVreg_EnableGpuFirmware=0，仅适用于专有驱动），否则稳定性欠佳；
• CUDA 会按在位显卡重新编号，一张卡掉线后脚本里的设备序号全部错位，排查时务必以 PCI 地址为准。

调优后的最终形态：单槽位 262K 上下文（该模型的训练长度上限），KV 缓存 q8_0 + flash-attention 分摊于双卡，MTP 投机采样接受率约 60%，decode 稳定在 48～54 t/s，prefill 约 800 t/s。

FastLLM：意外之喜

之后评估了 FastLLM（ftllm）作为替代引擎。它移植了 TurboMind 的 SM70 HMMA kernel，可以原生运行在 sm_75 的 2080 Ti 上，效果显著：decode 51.5 t/s（+20%），prefill 约 1350 t/s（+68%），视觉输入（mmproj）同样可用。KV 池最终定在 220160 tokens，长上下文下也测过：200K 上下文时 decode 仍有 25.8 t/s，全程无异常。此后 ftllm 成为日常方案，llama.cpp 退居备用。

被否决的路线

• vLLM 的 SM75 fork：当时（2026 年 8 月）实测过 Definitive 分支的早期版本，单路与 llama.cpp 打平，并发与 TTFT 全面落后，定案放弃。9 月下旬该项目发布 v0.2.1 后局面有所改写，详见下文「vLLM 2080 Ti Definitive」一节；
• Arc A770 + 2080 Ti 的 Vulkan 混插：第二张卡故障退场期间的应急尝试，27B decode 仅 13.1 t/s，与双卡的 61 t/s 差距过大；Intel 显卡的完整经历见上一篇；
• 180B MoE（Flash-Next）：双卡能跑，但 decode 约 17 t/s，日常使用偏慢，仅保留单卡版本用于超长文档场景。

故障全记录：一张非 A 核心卡的死亡

两张卡中，采用非 A 核心的那张（PCI 04:00 槽位）从入手起就故障不断。以下时间线摘自当时的排障日志。

2026-08-26：首次掉卡

显卡报出 Xid 62 → Xid 45 → Xid 154 的一串错误后从系统里消失。诱因的规律很明确：空闲到负载的功耗瞬变——持续满载反而稳定，轻载和负载突然变化时最容易触发。

2026-09-05：复发与拆修

短暂恢复数日后，这张卡再次从 PCIe 总线上消失。9 月 7 日拆修发现两个装配缺陷：

1. VRM 供电区域完全没有贴导热垫——改卡商家漏装，供电模块长期在高温下运行，负载瞬变时电压失稳，这正对应此前的故障规律；
2. PCB 已被压弯，原因是散热器螺丝拧得过紧。

补装导热垫、重涂硅脂、松开螺丝后，各轮压力测试一度零 Xid，看似痊愈。

拆修时的故障卡：中部一排 LR22 电感即 VRM 供电区域，改卡时此处未贴导热垫。

2026-09-08：功耗墙实验

为避开该卡在功耗瞬变下的短板，我给两张卡设置了功耗墙并做了对照测试（27B UD-Q6_K_XL，约 5K token prefill + 300 token decode）：

双 150W 相比双 200W 仅损失 10.9% 的 decode 与 7.5% 的 prefill，整机功耗却下降 100W。还有一个更关键的原因：双 200W 下一段 20K token 的持续 prefill 会直接触发故障卡的 Xid 31（MMU fault）并使服务崩溃，而 150W 下长上下文全程稳定。最终定为双 150W，写入脚本开机生效。

2026-09-09：实锤与退役

9 月 9 日，故障重现，这次证据更硬：memtest_vulkan 跑了不到 2 秒，就在约 3.6GB 的位置（地址 0xE76E7138）抓到单比特错误，同一秒内核再次报出 Xid 62 → 45 → 154 并掉卡。更关键的是，这次 Xid 62 附带的数据签名，和上一次开机驱动加载时报出的一模一样——同一块显存地址反复出错，基本可以断定是物理坏点，不是偶发的软错误。

为排除 SM 核心的嫌疑，我用一个几乎不占显存的纯计算压测程序（core_stress）分别打满两张卡的全部 SM：GPU0 通过 1194 轮校验，故障卡也通过 1248 轮，全程零 Xid。核心无恙，故障锁定在显存、显存供电或颗粒焊点。

到这里，之前的零星故障也都能解释了：Xid 13 报的"非法指令"，其实是指令数据流经坏显存时被污染；跨卡拷贝偶发的 CUDA 719 错误也是一回事。这张卡时好时坏——某次开机驱动初始化直接失败，下一次又看起来正常，也是硬件不稳定的典型表现。

考虑到显存颗粒重植的维修成本与不确定性，这张卡就此退役，其槽位由第一篇介绍的 CMP 170HX 接替。

vLLM 2080 Ti Definitive：亲测与后续

专为 SM75 打造的 vLLM 定向分支 vLLM-2080Ti-Definitive，我们其实亲手测过。8 月 22 日发现它时，双卡的 NVLink 桥还没到货，纸面评估的结论是"本机不可复现"；8 月 25 日桥到货装好，当天就部署了当时的 v0.1-pre2（基于上游 vLLM 0.27.1，源码构建约 13 分钟，另需安装 CUDA 13.3 工具链，FlashQLA 的 SM75 扩展编译成功）。

启动就费了周折：连续四次失败（KV 显存 OOM、FlashInfer prefill 工作区 OOM、expandable_segments 与 CUDA IPC 冲突），最后把显存占用率压到 0.945 才起来（FP8 权重 + fp16 KV、128K 上下文、TP=2、MTP3）。跑起来之后，实测与当时文档宣称的 84.7 t/s 差距不小：

最后一行很说明问题：自回归模式下本机比官方验证机还快，GPU 本身并不慢，差距出在别处。根因在这个 fork 的 README 问答里自己写着：同一软件栈在双路 X5675 老至强上只有 56 t/s，换 i3-9100T 则是 91 t/s——vLLM 的 Python 控制面吃 CPU 单核性能，本机 X99 平台的老至强喂不动它，实测约 50 t/s 与 X5675 的数据几乎重合。另外文档的 84 t/s 出自 4K 合成 prompt 的最佳值，真实中文文本下 MTP 平均接受长度只有 2.3～2.7，反推 84 t/s 需要约 3.4，在这台机器上达不到。

与同机的 llama.cpp Q6_K（53～61 t/s）对比，单路打平，其余全面落后：TTFT 4.4 秒对 0.7 秒；3 并发在默认配置下因 CUDA graph capture sizes 的 padding bug 直接崩到聚合 5.3 t/s，手动修正后也只有 56.6 t/s（llama.cpp 88 t/s）；fp16 KV 的上下文上限约 128～142K，低于 llama.cpp 的 180～220K。期间服务还两次被 systemd-oomd 杀掉。8 月 26 日凌晨定案"不值得迁移"，27 日删除环境。当夜那张非 A 核心卡开始掉驱动，双卡 TP=2 的前提也很快不复存在。

9 月 19 日，项目发布 v0.2.1，官方数字更新为（TP=2，NVLink，单请求）：

它对「FP8」的处理方式值得说明：Turing 没有 FP8 张量核这一点并未改变，项目走的是 W8A16/W4A16 路线——权重以 FP8 或 NVFP4 存储以节省显存、减轻解码时的带宽压力，计算时反量化至 FP16。换言之，FP8 在此是显存与带宽层面的优化而非计算路径的优化，与第 4 篇 170HX 上 W4A16 的思路一致。

这组数字发布时故障卡已经退役、本机已转向 170HX，未能亲测。两个口径问题需要注意：其一，测速脚本的所有请求均硬编码 temperature=0（greedy 采样），DFlash2 的数字还基于高投机命中率的合成输入，属方案上限，与第 4 篇两张表的分歧如出一辙；其二，官方测试主机是双路 Xeon E5-2673 v4，单核性能强于本机的老至强，而官方也明确指出老旧 CPU 平台会拉低 decode 吞吐——这与本机的实测归因一致。v0.2.1 的数字在 X99 这类平台上能复现多少，仍要打个问号。社区已有独立复现：zyYuc 的可复现部署仓库将 180K 上下文配置完整公开，博客园的八篇实战系列复盘了 GGUF 路线为何走不通与 KV 量化对比，亦有玩家实测 FP8 + MTP3、128K 上下文约 80 t/s；B 站上双卡 + NVLink 的实测视频则展示了该方案在单流与高并发下的完整表现。

对本文结论的修正：以当时的生态，llama.cpp/FastLLM 是这台机器上双 2080 Ti 的最优解——这一点有实测支撑，不只是纸面评估；v0.2.1 之后的专用分支在 CPU 更强的平台上展现出数倍优势，仍在用这套硬件的读者值得一试，只是建议先掂量一下自己 CPU 的单核性能。老硬件上，软件栈的演进速度往往比硬件本身更值得跟踪。

小结

双 2080 Ti 时期的最终形态：FastLLM 引擎跑 27B UD-Q6_K_XL，decode 51.5 t/s、prefill 约 1350 t/s、220K tokens 的 KV 池，双卡功耗墙 150W——以总计不到四千元的显卡成本，获得了可用度相当高的本地推理服务。

这一时期的教训：魔改卡个体差异很大，到手先跑显存压力测试（memtest_vulkan 两分钟就能暴露问题）；非 A 核心和来路不明的组装卡风险明显更高；功耗墙则几乎是零成本的稳定性手段，10% 的性能换数倍的稳定运行时间，很值。

另外一条想单独写给读者：如果你也打算在双 2080 Ti 这类老卡上跑 vLLM，先确认自己 CPU 的单核性能。这次的实测已经说明，同样的显卡和软件栈，老至强和桌面 CPU 之间能差出近一倍——显卡买回来跑不出别人晒的数字，问题很可能不在卡上。CPU 单核偏弱的平台，llama.cpp/FastLLM 这类控制面更轻的引擎是更稳的选择。

双 2080 Ti 的故事到这里并没有结束。故障卡退役、170HX 接替之后（第四篇），幸存下来的这张 2080 Ti 也没有闲置——它后来与 170HX 组成异构搭档，借助 Strata 的专家分流把 125B 的 MoE 模型跑在了 62GB 显存加 128GB 内存上，那是第五篇的内容。