双 R9700 TP. SGlang 部署qwen3.8-27b-fp8踩坑记录
-
【硬件】
cpu：5700x
主板：rog crosshair VIII hero
内存：ddr4 128g
显卡：r9700 * 2【部署全历程】
1. 初始部署失败（开箱即挂） - 直接跑 sglang 起服务：权重加载、cache 分配都正常，但第一次 forward（多模态 warmup）就卡死，300s 看门狗超时，模型从未成功跑完一次 forward - 原因：R9700 无 P2P（PCIe 2 hops），sglang logits 的 TP all-gather 无条件走 triton_symm_mem_ag（NVIDIA PTX kernel + symmetric memory peer IPC），rendezvous 从 C++ 抛 hipErrorIllegalAddress 直接 std::terminate，Python 兜底抓不到 → 硬崩 2. Cursor 调 opus5 改源码 → 部署成功 - 光靠配置参数救不活，是 Cursor 里的 opus5 深入 sglang 源码：定位到 logits_processor.py:333 创建 MultimemAllGatherer 时缺平台门禁，参照同目录 torch_symm_mem.py 的既有约定补上 is_cuda() 判断，非 CUDA 平台回退到常规 all-gather - 验证通过：warmup 首次出现 "The server is fired up and ready to roll!"，文本 + 图片推理都正常 - patch 已打成文件可提上游 PR（分支 fix/rocm-disable-symm-mem-logits-allgather） 3. 速度 0.94 tok/s → 23 tok/s（NCCL_PROTO=Simple） - RCCL 的 LL/LL128 低延迟协议在无 P2P 时走主机共享内存病态回退（10KiB all-reduce 要 8.2ms），每 token 光通信就 1045ms - opus5 实测对比四种协议，NCCL_PROTO=Simple 快 187 倍 4. 23 → 52 tok/s（MTP steps=3 + KV fp8_e4m3） - 启用模型自带的 mtp.safetensors 做 NEXTN 投机解码（必须 topk=1）（为什么用cursor不是Claude code，因为账号稀里糊涂被封了，也没充钱，使用deepseek-v4-flash一直说无法部署，sglang不支持消费级显卡，部署就挂，使用opus5拆解源码，发现了这个bug，修改后能正常部署）
【响应速度】
短 prompt（日常交互）： - 思维链关闭：TTFT 141ms，生成 35.6 tok/s - 思维链开启：TTFT 167ms，生成 40 tok/s 满 ctx（预填充主导，TTFT≈prefill 总时长）： - 173K 冷启动：TTFT 243s，prefill ~713 tok/s - 217K（radix 缓存命中）：TTFT 137s - 260,028 tokens / 262,144（99.2% 满）冷启动：TTFT 473s（7.9 分钟），生成 3.6 tok/s，prefill ~549 tok/s 【上下文召回命中率】3/3 全中 ✅ - 200K 长文中间埋 needle → 准确返回 - 217K → 准确返回 - 260K 满 ctx（needle 埋在开头，即最远端）→ 准确返回 GOLDEN_NEEDLE_77113 【结论】 - 召回能力优秀：99.2% 满 ctx 仍能精确找回远端信息，长文检索没问题 - 短上下文很流畅（首 token <200ms），适合日常对话 - 满 ctx 基本不可交互：等首 token 要 8 分钟、生成只有 3.6 tok/s，只适合离线批处理场景 - 生成速度随上下文增长衰减明显：40 → 5.3 → 4.3 → 3.6 tok/s（长序列 decode 每 token 要扫全部 KV） - prefill 吞吐 550-713 tok/s 偏慢（ROCm 上 cuda graph 未启用）；radix cache 对重复前缀有效（217K 场景 TTFT 直接减半）A卡使用 SGlang能用，但是速度还是较慢
-
目前没找到4bit的，4bit应该会快一些
-
-
【硬件】
cpu：5700x
主板：rog crosshair VIII hero
内存：ddr4 128g
显卡：r9700 * 2【部署全历程】
1. 初始部署失败（开箱即挂） - 直接跑 sglang 起服务：权重加载、cache 分配都正常，但第一次 forward（多模态 warmup）就卡死，300s 看门狗超时，模型从未成功跑完一次 forward - 原因：R9700 无 P2P（PCIe 2 hops），sglang logits 的 TP all-gather 无条件走 triton_symm_mem_ag（NVIDIA PTX kernel + symmetric memory peer IPC），rendezvous 从 C++ 抛 hipErrorIllegalAddress 直接 std::terminate，Python 兜底抓不到 → 硬崩 2. Cursor 调 opus5 改源码 → 部署成功 - 光靠配置参数救不活，是 Cursor 里的 opus5 深入 sglang 源码：定位到 logits_processor.py:333 创建 MultimemAllGatherer 时缺平台门禁，参照同目录 torch_symm_mem.py 的既有约定补上 is_cuda() 判断，非 CUDA 平台回退到常规 all-gather - 验证通过：warmup 首次出现 "The server is fired up and ready to roll!"，文本 + 图片推理都正常 - patch 已打成文件可提上游 PR（分支 fix/rocm-disable-symm-mem-logits-allgather） 3. 速度 0.94 tok/s → 23 tok/s（NCCL_PROTO=Simple） - RCCL 的 LL/LL128 低延迟协议在无 P2P 时走主机共享内存病态回退（10KiB all-reduce 要 8.2ms），每 token 光通信就 1045ms - opus5 实测对比四种协议，NCCL_PROTO=Simple 快 187 倍 4. 23 → 52 tok/s（MTP steps=3 + KV fp8_e4m3） - 启用模型自带的 mtp.safetensors 做 NEXTN 投机解码（必须 topk=1）（为什么用cursor不是Claude code，因为账号稀里糊涂被封了，也没充钱，使用deepseek-v4-flash一直说无法部署，sglang不支持消费级显卡，部署就挂，使用opus5拆解源码，发现了这个bug，修改后能正常部署）
【响应速度】
短 prompt（日常交互）： - 思维链关闭：TTFT 141ms，生成 35.6 tok/s - 思维链开启：TTFT 167ms，生成 40 tok/s 满 ctx（预填充主导，TTFT≈prefill 总时长）： - 173K 冷启动：TTFT 243s，prefill ~713 tok/s - 217K（radix 缓存命中）：TTFT 137s - 260,028 tokens / 262,144（99.2% 满）冷启动：TTFT 473s（7.9 分钟），生成 3.6 tok/s，prefill ~549 tok/s 【上下文召回命中率】3/3 全中 ✅ - 200K 长文中间埋 needle → 准确返回 - 217K → 准确返回 - 260K 满 ctx（needle 埋在开头，即最远端）→ 准确返回 GOLDEN_NEEDLE_77113 【结论】 - 召回能力优秀：99.2% 满 ctx 仍能精确找回远端信息，长文检索没问题 - 短上下文很流畅（首 token <200ms），适合日常对话 - 满 ctx 基本不可交互：等首 token 要 8 分钟、生成只有 3.6 tok/s，只适合离线批处理场景 - 生成速度随上下文增长衰减明显：40 → 5.3 → 4.3 → 3.6 tok/s（长序列 decode 每 token 要扫全部 KV） - prefill 吞吐 550-713 tok/s 偏慢（ROCm 上 cuda graph 未启用）；radix cache 对重复前缀有效（217K 场景 TTFT 直接减半）A卡使用 SGlang能用，但是速度还是较慢
-
@stormaround 要不要参考flyer666大神的魔改SGLang那个帖子再试试？我在我的双卡7900XTX上引用了，效果飞起。
@Ben-Lee 这个模型是FP8
7900xtx 跑的是低精度模型。楼主应该用
tcclaviger/Qwen3.8-27B-DFlash2-FP8这个模型，不应该用MTP3，层数太深也影响效率。
如果一定要用MTP，可以改成1
https://github.com/magiccodingman/vllm-radiance
https://github.com/StevenChenSE/sglang/tree/gfx1100-support#chinese
