7900XTX双卡TP，SGLang & VLLM 多Agent多并发测试对比
-
这个帖子本来是发在 @flyer666 大佬的《魔改 SGLANG 支持 7900XTX 双卡 TP，TTFT <1s，平均 TG 80–100，4 并发 TG 200/sec》这篇神级帖子下面的一条我的水贴：
https://lcz.me/topic/1532?_=1789171714063
受宠若惊，被老特分叉置顶到了这里。既然单独成帖了，我也顺手把前面几处容易误导大家的地方补充和勘误一下。
-
首先要特别说明，魔改 SGLANG 支持 7900XTX 双卡 TP 这条路线，是 @flyer666 9 月 6 日发的高含金量原创，链接就是上面这篇。大家一定要先去拜读，然后狠狠点赞。
-
其次，回复 @geekyang 和 @懒人烘培 两位朋友：不好意思哈，我前面把主板型号写错了。我的实际主板是 GIGABYTE B850 AI TOP，当时大约 $320，并不是 GIGABYTE X870E AORUS Xtreme AI TOP（约 $1070）。
-
我选 B850 AI TOP 最主要的原因，就是双显卡同时插上以后，两条槽可以跑 x8/x8，对双 7900 XTX 这种玩法比较合适。缺点也很明显：DDR5 现在这个价格确实有点离谱。不过考虑到后面本地部署，尤其是 MoE、CPU offload、HiCache 这类玩法都会越来越吃系统内存，最后还是狠狠心上了 2×32GB，总共 64GB DDR5。现在回头看，这 64GB 还真没白上。要是只有 32GB，后面很多新玩法，包括大模型 CPU offload、长上下文缓存、HiCache L2 这类东西，基本就玩不开了。
然后补充下上面那个帖子的背景，希望对感兴趣的朋友有所参考和帮助。
我原来一直用的是7900XTX双卡 + vLLM，也是跟着 @flyer666 大佬之前这篇帖子折腾的：https://lcz.me/topic/1363 。用得非常顺手。
上周末看到 @flyer666 大佬这篇双 7900 XTX + SGLang 的帖子，测试数据实在太漂亮，当时确实有点兴奋，马上就想把自己的双卡也迁过去试试。结果 SGLang 部署起来以后，很快就碰到了一个特别明显的问题：
一个 Agent 正在正常输出时，另一个 Agent 一旦进来做长 prompt prefill，前面的 Agent 会出现几十秒完全没有 token 输出。也就是说我的两个Hermes Agent同时卡死无反应，短则几十秒，长达几分钟。但是单Agent完全没有问题，提升明显。
对我自己的使用场景来说，这个问题很严重。我平时不是只跑一个请求，而是有两个长期 Hermes Agent。一个 Agent 正在正常工作的时候，另一个 Agent 很可能突然带着很长的上下文进来。双卡跑不了并发，钱岂不是白花了？
最开始我还以为是双 7900 XTX 的算力不够，或者是 TP、ROCm、speculative decoding 哪一层出了问题。后来一路查资料、翻 issue 和 PR，才发现 SGLang 上游其实已经有人专门处理过这个问题。关键就是：PR #34058 https://github.com/sgl-project/sglang/pull/34058
这里面有一条和 scheduler 调度有关的改动，同时还有一个刚刚发布的的新参数：
--max-consecutive-prefill-batches N它的作用可以简单理解为：
限制 scheduler 连续执行 prefill 的次数，给已经处于 decode 状态的请求留出调度机会。
这个开关对我的实际使用体验产生了非常明显的变化。我当时专门设计了一个双并发测试来模拟自己的真实场景。
测试环境：
双 7900 XTX + SGLang gfx1100 + TP2 + MTP3 + BF16 KV
场景是：
Agent A 已经带着 64K 上下文持续 decode
→ 5 秒后 Agent B 加入
→ Agent B 执行 64K fresh prefill在原始状态下（不加这个参数，或者这个参数N=0），A 会出现非常明显的 starvation(算力饿死），就是卡死不动了。对我这种双长期 Agent 的工作方式来说，这基本就等于：
SGLang 在默认调度下不可用。
找到 PR #34058 以后，我把
--max-consecutive-prefill-batches从 N=1 一直测试到 N=16。实测结果如下：
N A 最大断流 B 64K TTFT 0（原版） 47.23s 49.43s 
14.04s 49.48s 2 7.70s 49.21s 3 11.70s 49.05s 4 13.80s 49.37s 8 25.76s 49.24s 16 47.05s 49.24s 结果非常直观可观。
N=1 基本就是我这个场景下的甜点位。
B 的 64K TTFT 几乎没有受到明显影响：
- 原版：49.43s
- N=1：49.48s
但 A 的最大断流时间：
- 原版：47.23s
- N=1：4.04s
等于从接近 50 秒，直接压到了约 4 秒。也就是说，现在我的B Agent如果带着64K上下文进来，原来的A只卡顿4秒，然后恢复吐字，这几乎不可察。
当然了，这里有一点我觉得特别值得强调。
打开 N=1 以后，并不是说 A 就完全不受影响了。B 在做 64K fresh prefill 的时候，两张 7900 XTX 的算力还是要被抢走，所以 A 的 decode 速度还是会明显下降（实测值 80 tok/s 降到 15 tok/s）。
也就是说：
N=1 解决的是 starvation，不是 compute contention。
但是，它解决的是行不行的问题：
“另一个长 prefill 一进来，我这个 Agent 几十秒完全不出字。”
至此确定SGLang在我的这种“双7900XTX”加“双Hermes Agent各196K上下文”这个环境中完全可用了，这才引发了上面那个帖子的定量分析，到底vLLM和SGLang哪个更适合我，以及数据是多少。
换个说人话的版本，请勿对号入座哈
老特当年也风光过，坐奔驰，开宝马，最爱秋天的第一杯奶茶。
所谓时来天地皆同力，运去英雄不自由。如今龙游浅水，潜龙伏渊，论成败，人生豪迈，大不了重头再来。
于是招兵买马，雇了帅哥小特跑业务，请了一个漂亮小姐姐做财务。
一个负责挣钱，一个负责管钱。这算是 -- 双卡并行？
小特是真正的劳动模范，财务小姐姐也是秀外慧中。按理说，这男女搭配，干活不得效率翻倍？
都怪老特太抠门，不舍得团建投入，破冰不到位，怪不得小特这两天总是浮想联翩。
从大门到小姐姐工位的距离大约是49秒。每天早晨财务小姐姐带着一阵小香风款款经过，小特的CPU就瞬间被某个高优先级进程劫持。
小姐姐49秒不入座，小特的心49秒不降落。
财务小姐姐也是宝宝心里有苦倒不出。
每当小特经过，小姐姐的心里也总是一阵七上八下，小特又不是老特，他要是来加微信，我是拒绝呢，还是拒绝呢？
小特的工位到厕所的距离是49秒，小姐姐的魂也跟着柳飘飘了49秒。
感情你俩互相给自己心里加戏，让老子我的钱包白白受到一万点暴击是吧。
老特的人生，本来已经修炼到了莫听穿林打叶声，何妨吟啸且徐行的新境界。谁怕？怕谁？老子花钱雇了你们两个人，怎么着加法还变成减法了？是可忍，孰不能忍？
老特于是口吐莲花，感化得小特心服口服，心悦诚服。小特也是很有潜质的好苗子，老特本来的大招是老子蜀道山，结果根本不用数到三，数到一小特就已经脱胎换骨，改头换面，重新做人了。
从此小姐姐再进办公室，小特的心坚硬到只会跟着高跟鞋清脆的咔哒声动 4 秒。剩下的 45 秒里，风动，心不动。小特心无旁骛的样子——那真是，认真的男人最帅。
小特这一投入，小姐姐对他也顿时另眼相看。以后走过路过不怕错过，相看两不厌，只有敬亭山。
从此天下太平，工作融洽。男女搭配，终于成果加倍。
老特端着泡满枸杞的保温杯站在门口，看着两个人终于各司其职，露出了资本家久违的微笑。
这，就叫 结构化浪起来(SGLang) 的管理调度。
这，就是我 Scheduler 的硬实力。
问题基本不在双卡链路，在 SGLang 的调度：一条长 prefill 会整段占住 GPU，期间 decode 请求排不进去，所以你看到的「另一个 Agent 几十秒没 token」是 prefill 抢跑，不是卡死。
先查启动参数里的 chunked prefill：
--chunked-prefill-size调小（比如 2048/4096，别用 -1），让长 prompt 分块跑，decode 在块与块之间插队，卡顿会从「几十秒」压到单块量级- 看你这版有没有
--enable-mixed-chunk，开了才能 prefill/decode 同批 --max-prefill-tokens也压低，防止单批过大- 顺手对比
--schedule-policy lpm和fcfs：lpm 命中前缀省算力，但新请求做长 prefill 时更容易抢
你测 vLLM 那轮体感更稳，很大概率就是 vLLM 默认开了 chunked prefill。压测时同时看
sglang:num_queue_reqs和 TTFT 分位，如果卡顿期间排队数在涨，就坐实是调度而不是 hang。B850 AI TOP 的 x8/x8 对 TP2 没问题，TP 每层一次 AllReduce，PCIe 5.0 x8 足够；两卡贴太近降频会把 prefill 拖长，反而放大这个卡顿，你加风扇、锁 305W 的方向是对的。
-
-
@Geekyang 9600X 不是给两张卡各 16 lanes，而是把 CPU 的 16 条显卡 lanes 拆成 x8/x8；B850 AI TOP 支持这种 bifurcation。
Ryzen 5 9600X 本身有 24 条可用 PCIe 5.0 lanes；其中 16 条 PEG lanes 可以由主板做 bifurcation，拆成 x8 + x8。AMD 官方给 9600X 的规格也是 28 条 native / 24 条 usable PCIe lanes。:contentReference[oaicite:0]{index=0}
我这块 GIGABYTE B850 AI TOP 正好支持这种分法：
- 第一条 PCIEX16：单卡时最高 x16
- 第二条 PCIEX8：最高 x8
- 两张卡同时插时，第一条会从 x16 降到 x8
- 最终就是 PCIe 5.0 x8 + x8
技嘉官方手册也明确写了：PCIEX16 和 PCIEX8 共享带宽，双卡时 PCIEX16 最高以 x8 运行。:contentReference[oaicite:1]{index=1}
是不是我前面如果哪里写成了“双 x16”，那是表达不严谨，准确说法应该是：
双物理 x16 插槽，CPU 直连，双卡运行时 x8/x8。
对 7900 XTX 做 TP2 来说，这也是我当初选这块板的主要原因之一。
-
@Geekyang 9600X 不是给两张卡各 16 lanes，而是把 CPU 的 16 条显卡 lanes 拆成 x8/x8；B850 AI TOP 支持这种 bifurcation。
Ryzen 5 9600X 本身有 24 条可用 PCIe 5.0 lanes；其中 16 条 PEG lanes 可以由主板做 bifurcation，拆成 x8 + x8。AMD 官方给 9600X 的规格也是 28 条 native / 24 条 usable PCIe lanes。:contentReference[oaicite:0]{index=0}
我这块 GIGABYTE B850 AI TOP 正好支持这种分法：
- 第一条 PCIEX16：单卡时最高 x16
- 第二条 PCIEX8：最高 x8
- 两张卡同时插时，第一条会从 x16 降到 x8
- 最终就是 PCIe 5.0 x8 + x8
技嘉官方手册也明确写了：PCIEX16 和 PCIEX8 共享带宽，双卡时 PCIEX16 最高以 x8 运行。:contentReference[oaicite:1]{index=1}
是不是我前面如果哪里写成了“双 x16”，那是表达不严谨，准确说法应该是：
双物理 x16 插槽，CPU 直连，双卡运行时 x8/x8。
对 7900 XTX 做 TP2 来说，这也是我当初选这块板的主要原因之一。
-
@懒人烘培 不好意思，写错了，我的主板其实是 GIGABYTE B850 AI TOP。两张 7900 XTX 装上去还是太挤了，卡间距连一个槽位都不到。双卡满载时发热很严重，连带着 CPU 温度也跟着遭殃。目前的解决方案是加装两个高压风扇：一个从两卡缝隙中间往里吹风，另一个顺着 CPU 风扇的气流方向，同时兼顾吹 CPU 和中间那张 7900 XTX 的背面。这样调整后，满载长时间跑推理时，显卡和 CPU 温度都能稳定在警戒线以下，不会触发降频。另外，我7900XTX锁功耗墙了，大概是从330W降到了305W（最低能降的数字）。
-
5mm 间距基本等于没有风道，两卡夹缝里的空气被反复加热，上面那张吸的是下面卡的排气，热是必然。尾部加风扇有帮助，但要看是「往夹缝送风」还是「往外抽热风」：
- 夹缝只有 5mm，14cm 扇塞不进去，风压也不够，效果有限；开放式散热的卡，最有效的是从机箱前面往两卡之间送一股定向风，或用导风罩把夹缝热气引出去。
- 根本解法是拉开间距（PCIe 延长线/转接、换板距更大的机箱），或上水冷/涡轮卡。垂直、吊装主要是避免热空气堆积，有用但不是根因。
- 别靠手感判断，看数据：nvidia-smi dmon -s pucvt，分别看两卡温度、功耗和降频原因。一般到 80-83℃ 才开始明显降频，先确认是不是真撞了温度墙。
建议先只把一张卡拉开距离跑一次对比，数据比加扇子直观。
-
-
@懒人烘培 我也是，随时准备搞根PCI延长线把显卡移出来，我是开放式机架，方便。 https://lcz.me/topic/1363/3 flyer666大佬这个帖子里有发图，他的双7900XTX就是延长线引出来了，放在机架上方，四面通风。
-
，系统 取消固定了此主题
-
@Geekyang 我再研究研究哈，网上说法不一，我的理解是B850 AI TOP 的两个 GPU 插槽是 CPU-direct x8/x8，物理拓扑具备 P2P 的前提；但 Gigabyte 并没有把它定义为一个保证 PCIe P2P 的功能。我估计消费级主板上这个功能够呛能实现。我找时间自己实测一下到时候拿数据说话。
-
@Ben-Lee 消费级CPU都没有P2P,因为CPU里没有root complex，但是并不影响TP，TP可走sharememory, 也就是，数据在内存交换。我问了Intel 工程师了。也就是X99 可以TP，但是消费级的就只能sharememory,其实效率也很高，毕竟PCIE带宽高了
-
@张光璞 这两天填了无数坑，折腾出一篇水文 https://lcz.me/topic/1740 7900XTX双卡TP，SGLang & VLLM 多Agent多并发测试对比（续一）- 山重水复）， 多批评指正。
或者看下面这个快速简短总结，谨供参考。
**硬件：**2× RX 7900 XTX + Ryzen 9600X + 64G DDR5 + GIGABYTE B850 AI TOP + ADATA SX8200PNP1TB （PCIe Gen3 x4、NVMe 1.3）
**平台：**Ubuntu，SGLang TP2，Qwen3.8-27B GPTQ长上下文唤醒：分钟级重算 → 秒级恢复
SGLang TP2 / MTP3，HiCache size16。首 token 延迟：
上下文档位 冷预填 显存 L1 命中 内存 L2 恢复 L2 比 L1 多等 64K 50.78s 0.431s 0.546s 115ms 120K 121.49s 0.711s 0.896s 185ms 192K 243.81s 1.055s 1.406s 351ms 驱逐对照，64K 回访：
配置 首 token 结果 无 HiCache 48.129s cached tokens = 0，重新计算 有 HiCache 0.546s L2 恢复，避免完整重算 单路历史基准
方案 测试口径 解码速度 单卡 llama.cpp Vulkan + MTP Qwen3.6-27B Q4_K_M，短请求 约 44 tok/s 双卡 vLLM Qwen3.8-27B GPTQ，64K 77.185 tok/s 双卡 SGLang 同轮、同模型，64K 88.815 tok/s 单卡仅作演进背景，不同模型、量化与长度，不计算跨组加速比。
多路 64K 冷预填
并发 引擎 各请求首 token：秒 聚合预填：tok/s¹ 2 路 SGLang 48.15／48.15 2720 2 路 vLLM 48.39／97.38 1346 3 路 SGLang 48.26／48.26／48.26 4070 3 路 vLLM 48.46／97.49／100.20 1962 4 路 SGLang 48.23／48.23／48.23／48.45 5408 4 路 vLLM 48.40／97.44／100.15／102.87 2547 当前进度
技术模块 状态 双 7900 XTX + SGLang TP2 
已跑通MTP3 / DFlash2 投机解码 均已测试HiCache L1 命中 / L2 恢复 已验证L3 的 FULL KV + Mamba 完整恢复 
研究中多 Agent 长期循环联合验收 
待完成 -
@张光璞 这两天填了无数坑，折腾出一篇水文 https://lcz.me/topic/1740 7900XTX双卡TP，SGLang & VLLM 多Agent多并发测试对比（续一）- 山重水复）， 多批评指正。
或者看下面这个快速简短总结，谨供参考。
**硬件：**2× RX 7900 XTX + Ryzen 9600X + 64G DDR5 + GIGABYTE B850 AI TOP + ADATA SX8200PNP1TB （PCIe Gen3 x4、NVMe 1.3）
**平台：**Ubuntu，SGLang TP2，Qwen3.8-27B GPTQ长上下文唤醒：分钟级重算 → 秒级恢复
SGLang TP2 / MTP3，HiCache size16。首 token 延迟：
上下文档位 冷预填 显存 L1 命中 内存 L2 恢复 L2 比 L1 多等 64K 50.78s 0.431s 0.546s 115ms 120K 121.49s 0.711s 0.896s 185ms 192K 243.81s 1.055s 1.406s 351ms 驱逐对照，64K 回访：
配置 首 token 结果 无 HiCache 48.129s cached tokens = 0，重新计算 有 HiCache 0.546s L2 恢复，避免完整重算 单路历史基准
方案 测试口径 解码速度 单卡 llama.cpp Vulkan + MTP Qwen3.6-27B Q4_K_M，短请求 约 44 tok/s 双卡 vLLM Qwen3.8-27B GPTQ，64K 77.185 tok/s 双卡 SGLang 同轮、同模型，64K 88.815 tok/s 单卡仅作演进背景，不同模型、量化与长度，不计算跨组加速比。
多路 64K 冷预填
并发 引擎 各请求首 token：秒 聚合预填：tok/s¹ 2 路 SGLang 48.15／48.15 2720 2 路 vLLM 48.39／97.38 1346 3 路 SGLang 48.26／48.26／48.26 4070 3 路 vLLM 48.46／97.49／100.20 1962 4 路 SGLang 48.23／48.23／48.23／48.45 5408 4 路 vLLM 48.40／97.44／100.15／102.87 2547 当前进度
技术模块 状态 双 7900 XTX + SGLang TP2 已跑通MTP3 / DFlash2 投机解码 均已测试HiCache L1 命中 / L2 恢复 已验证L3 的 FULL KV + Mamba 完整恢复 研究中多 Agent 长期循环联合验收 待完成
，我还一直在这儿装蒜
。以后多多指教哈。