双 RTX 2080 Ti 22GB 部署 Qwen3.8-27B：一次 llama.cpp 实践

我在一台超微服务器上做了 Qwen3.8-27B 的本地服务。硬件并不新：两颗 Xeon E5-2643 v3、64GB 内存、两张扩容到 22GB 的 RTX 2080 Ti，显卡之间有 NVLink。这里的 22GB 是改装卡容量，不是原版 2080 Ti 的 11GB；想复现相同配置，首先要确认自己手里的显存与互联条件。

最终运行路线是 Qwen3.8-27B Q4_K_M GGUF + llama.cpp CUDA + 双卡切分，默认使用 MTP 草稿模型。服务通过兼容 OpenAI 的接口供局域网客户端调用。

把可变化的部分放进容器

宿主机只负责 NVIDIA 驱动、Docker、NVIDIA Container Toolkit 和持久化模型目录；llama.cpp 与 CUDA 运行环境固定在镜像中。这样可以保留已验证版本，也方便在试验失败时切回原镜像。主模型、草稿模型和多模态投影文件放在 SSD，容器以只读方式挂载。

我为 RTX 2080 Ti 的 sm_75 固定了 llama.cpp 源码提交与 CUDA 镜像版本，并在部署后逐一检查模型文件大小和 SHA-256。这里的重点不是“必须使用某个旧提交”，而是记录实际跑通的版本与文件；跟着最新版本重建时，应重新做同样的检查。

服务的核心配置可以概括为：

主模型：Qwen3.8-27B Q4_K_M GGUF
显卡：CUDA0 + CUDA1
切分：tensor，比例 1:1
上下文：262144 token
主 KV Cache：K 为 Q8_0，V 为 Q5_1
草稿 KV Cache：Q8_0 / Q8_0
并发槽：1
图片输入：加载对应 mmproj 文件

实际 Compose 文件还包含模型路径、设备、API 鉴权和运维配置。不要把任何密钥写进公开配置示例；部署时应由自己的私有配置或 secret 文件注入。

按层切分与张量切分差别很大

在同一台机器上，按层切分的基础版约 25.97 token/s；实验性的张量切分基础版约 41.12 token/s。正式 CUDA 12.4 镜像的 128K 单次验收中，张量切分基础版约 41.55 token/s，加入 MTP 后约 63.96 token/s。测试使用相同中文提示词、温度 0、256 token 输出；数字适合比较这次部署的几种配置，不能当作跨机器基准。

我也试了 DFlash2。它在这套 llama.cpp 构建中与 tensor 切分发生后端断言，只能使用 layer；因此它没有成为默认方案。最终保留一个可切换的 DFlash2 实验配置，而日常服务采用 MTP + tensor split。这也说明“推测解码技术更先进”不等于在每个硬件和引擎组合上都更快。

256K 和图像输入的验收

把上下文提升到 256K 后，我将主缓存调整为 Q8_0/Q5_1，并加载图像投影文件。容器能够完成 262,144 token 槽位预分配，文本、单图、工具调用和接口鉴权的基础测试通过。当时静态显存占用约为 GPU0 17.4 GiB、GPU1 16.7 GiB，各自仍有余量。

有一次客户端的复杂 SVG 任务生成了约 44,498 token，结束时上下文约 81,544 token，并未碰到当时 128K 的上限；后续图片输入失败，是因为那时服务尚未加载 mmproj。查清楚是哪一层出了问题，比直接把“上下文不够”当结论更重要。

部署完成不等于所有任务完成

2026-09-23，我曾尝试切换到定制 vLLM 路线；它在短请求性能测试中明显更快，但 WorkBuddy 实际答复出现严重异常，最终又切回这套 llama.cpp 服务。切回后，健康检查、中文短答、单图识别和一个简单工具调用恢复正常；长时间思考和复杂工具链任务仍需单独验收。

所以我现在把验收分成三层：服务能否启动、接口能否完成单项功能、真实客户端能否完成完整任务。第三层才决定它是否适合日常使用。

资料：Qwen GGUF 模型文件 · llama.cpp 项目