双Radeon R9700——在llama.cpp上运行Qwen 3.6 27B Q8 MTP

关于使用R9700的多GPU设置的信息不多，所以我写这篇文章，希望能帮助到遇到同样情况的人。以下是我的设置、运行过的测试以及服务器日志中的数字。 设置：ThinkStation P7，Xeon w7-3455，128 GB RDIMM，2× Gigabyte Radeon AI PRO R9700 32 GB（总计64 GB显存），Ubuntu 24.04 LTS，Docker 29.5.3，容器通过Komodo（komo.do）管理，ROCm 7.2.1，镜像：llamacpp-rocm:gfx1201，模型：unsloth/Qwen3.6-27B-MTP-GGUF/Qwen3.6-27B-Q8_0.gguf，上下文长度131072 测试：根据Markdown规范生成代码：用Python、Go和PHP搭建同一个应用。长文本处理：处理2000–3000行的输入（医学文本、思科手册、文学作品），进行翻译、重新格式化和纠错。记忆检查：总结一个长混合会话，看它是否保持主题连贯并能回忆早期内容。 解码（令牌生成） 上下文填充 解码（t/s） MTP草稿接受率 ~3–6k 46–61 0.36–0.54 ~10–13k 64–67 0.60–0.61 ~17k ~59 0.54 ~33k ~49 0.45 ~96k ~40 0.42 ~102k ~44 0.50 ~125k ~45 — 预填充吞吐量 提示大小 吞吐量 <10k ~1,200–1,500 t/s ~30k ~1,175 t/s ~63k ~617 t/s ~100k+ ~410–435 t/s MTP草稿接受率：所有运行中为0.33–0.61。 --spec-draft-n-max：还在试验这个参数。降低它会提高高上下文时的令牌生成速率，所以我会继续测试不同的值。提示缓存：服务器会保留滚动KV检查点（最多32个，每个约150–580 MiB），并在新轮次与缓存的前缀大部分相同时，在约60–300毫秒内恢复它们，而不是重新处理整个提示。PCIe带宽（Intel PCM）：解码期间每个方向低于200 MB/s；预填充期间峰值达到5–7 GB/s。 Compose yaml服务配置： llamacpp-qwen36-27b: image: llamacpp-rocm:gfx1201 pull_policy: never container_name: llamacpp-qwen36-27b network_mode: host ipc: host privileged: true security_opt: - seccomp=unconfined group_add: - "44" - "993" devices: - /dev/kfd:/dev/kfd - /dev/dri:/dev/dri ulimits: memlock: -1 stack: 67108864 environment: - HIP_VISIBLE_DEVICES=0,1 - ROCR_VISIBLE_DEVICES=0,1 volumes: - /data/models_ai:/models:ro command: - --model - /models/unsloth/Qwen3.6-27B-MTP-GGUF/Qwen3.6-27B-Q8_0.gguf - --host - 0.0.0.0 - --port - "8002" - --alias - qwen36-27b - --n-gpu-layers - "999" - --ctx-size - "131072" - --split-mode - tensor - --kv-unified - --cache-type-k - f16 - --cache-type-v - f16 - --batch-size - "2048" - --ubatch-size - "1024" - --parallel - "1" - --cont-batching - --flash-attn - "on" - --threads - "8" - --spec-type - draft-mtp - --spec-draft-n-max - "5" - --reasoning-budget - "0" - --temp - "1.0" - --top-k - "20" - --top-p - "0.95" - --jinja