-
现在唯一有可能的就是把一条pci-e的x16拆分为8*8 用8654转接卡，去连接2张显卡，我感觉 能跑通，但是没有意义，本来pci-e 3(x99)中x16带宽就是瓶颈。所以，这样操作下来，一点意义都没有。
-
@拐子001 谢谢测试，你有试过关闭custom ar使用默认nccl吗？我怀疑可能还是虚拟化问题，你可以试试直接在pve安装试试，毕竟pve底层是debian，和我的ubuntu大同小异。
我的主板是AM5平台，x99支不支持的确不清楚，但是我看有的洋垃圾是专门跑双卡的，所以我怀疑应该不是主板问题。
-
大佬有没有尝试rocm10.0.0版本
-
@Ben-Lee 哈哈 我一般本地最多同时开俩session，prefill结束后基本就是轮流进行短prefill + decode ，所以体感还好。
你那种现象我估计有几种原因：
- 超长prefill并发估计是触及了7900xtx的算力瓶颈，估计上r9700会好很多 （pp 2500+)。
- bf16的kv cache token池子太小（~192k），很容易触发radix cache eviction，你看看加几条内存上hicache会不会好一些。按理说都是hermes agent，前缀命中应该概率很高。如果是完全是fresh prefill，估计vllm比较适合你。
@flyer666 谢谢回复和指导。您这个思路很有道理，我这边同时跑着两个 Hermes 本地 AI Agent基本都是发散性任务，所以 fresh prefill 确实很多。
- 关于您的第一点建议：
我这边实测下来，感觉不只是 7900 XTX 的算力瓶颈。测试时先让 A 完成 64K prefill 并进入正常 decode，单路大约 80 tok/s。5 秒后再让 B 加入一个 64K fresh prefill，结果 A 会连续 47.2 秒完全没有 token 输出，也就是从约 80 tok/s 直接掉到 0，等 B 的 prefill 结束后才恢复正常.
这其实已经意味着，在我的实际 workload 下，长上下文双并发基本失败了：两路虽然都处于 running 状态，但第二路一做长 prefill，第一路几乎被冻结。更关键的是，当时 waiting=0，KV 使用率还不到 50%。后面我又分别关了 MTP、ROCm 7.2→10、chunk 4096→2048，结果 A 还是会停 45–54 秒，所以我更倾向这是 SGLang 的 long prefill / decode starvation，而不只是单纯算力不够。
- 关于您的第二点建议：
KV 我后来也调到了 265,950 tokens，C3 峰值才 62%，所以这次看起来也不像是 radix eviction。HiCache 我在5090 128G内存的另一台机器上上试过确实好用，但这台机器只有64G，而且还分了一半跑虚拟机，内存不够了，后面有机会加内存了我再试试。
我的部署基本完全让DSF按照您的帖子和推荐指南来的，但是我自己其实是个纯小白，所以现在也不敢百分之百确定是不是我这边某个配置还有问题。不过至少 SGLang 跑短上下文是真的香。刚开始测试的时候，会话很快，堪比DeepSeek Flash，四路并发也非常丝滑，所以一开始我其实挺惊喜的。只是上下文一长，特别是出现 fresh prefill 以后，实际体验就完全变了。我最近这一两个月学习到的东西比过去一年还多，CUDA，oneAPI，Level Zero，SYCL，OpenVINO，RCOm，Vulkan，llama.cpp, vLLM，SGLang这些遥远的名词居然也都亲自实践测试体验过了，在这个论坛真是大有收获了。
再次感谢大神的分享和热心回复。以后还要继续抱大神大腿，少走弯路！
-
@flyer666 谢谢回复和指导。您这个思路很有道理，我这边同时跑着两个 Hermes 本地 AI Agent基本都是发散性任务，所以 fresh prefill 确实很多。
- 关于您的第一点建议：
我这边实测下来，感觉不只是 7900 XTX 的算力瓶颈。测试时先让 A 完成 64K prefill 并进入正常 decode，单路大约 80 tok/s。5 秒后再让 B 加入一个 64K fresh prefill，结果 A 会连续 47.2 秒完全没有 token 输出，也就是从约 80 tok/s 直接掉到 0，等 B 的 prefill 结束后才恢复正常.
这其实已经意味着，在我的实际 workload 下，长上下文双并发基本失败了：两路虽然都处于 running 状态，但第二路一做长 prefill，第一路几乎被冻结。更关键的是，当时 waiting=0，KV 使用率还不到 50%。后面我又分别关了 MTP、ROCm 7.2→10、chunk 4096→2048，结果 A 还是会停 45–54 秒，所以我更倾向这是 SGLang 的 long prefill / decode starvation，而不只是单纯算力不够。
- 关于您的第二点建议：
KV 我后来也调到了 265,950 tokens，C3 峰值才 62%，所以这次看起来也不像是 radix eviction。HiCache 我在5090 128G内存的另一台机器上上试过确实好用，但这台机器只有64G，而且还分了一半跑虚拟机，内存不够了，后面有机会加内存了我再试试。
我的部署基本完全让DSF按照您的帖子和推荐指南来的，但是我自己其实是个纯小白，所以现在也不敢百分之百确定是不是我这边某个配置还有问题。不过至少 SGLang 跑短上下文是真的香。刚开始测试的时候，会话很快，堪比DeepSeek Flash，四路并发也非常丝滑，所以一开始我其实挺惊喜的。只是上下文一长，特别是出现 fresh prefill 以后，实际体验就完全变了。我最近这一两个月学习到的东西比过去一年还多，CUDA，oneAPI，Level Zero，SYCL，OpenVINO，RCOm，Vulkan，llama.cpp, vLLM，SGLang这些遥远的名词居然也都亲自实践测试体验过了，在这个论坛真是大有收获了。
再次感谢大神的分享和热心回复。以后还要继续抱大神大腿，少走弯路！
-
能不能插，不看你用哪颗 U，看两块的具体情况——主板的 PCIe 槽位间距和机箱宽度才是决定因素。
3.5 槽卡按 1 槽 ≈ 20mm 算，厚度约 70mm。要两张 3.5 槽卡物理并排，两条 x16 槽的间距必须 ≥ 4 槽位：第一张卡占掉 1~3.5 槽，第二张的接头得落在第 4 槽位之后才碰不到。
实操三步判断：
- 查主板手册两条 x16 槽隔了几槽。如果第二条全尺寸槽就在第一条正下方 1~3 槽（很多板子默认 2 槽间距），3.5 槽卡会直接顶住，插不进去。
- 看第二条是不是电气 x16（板载走 CPU 直连）还是芯片组出 x4——前者双卡跑 TP 才不憋屈，后者基本只能当副卡。AM4/X670E 上双显卡时多数会掉到 x8/x8，对推理影响很小（decode 是计算密集不是带宽密集，跟这条帖里双卡 TP 的诉求正相关）。
- 量机箱宽度和整卡长度——3.5 槽卡通常也长，往往会挡前段的 SATA 口/风扇位/供电口。
保险就选「第二条全尺寸 x16 在主板底部、隔 4+ 槽」的型号。你报具体板子型号，我对着 spec 帮你查插槽间距和 x8 分道。
@Xiaote 华擎X570 可以的，有4槽宽，带双pci x16的接口。
-
@你的名字我的名字都是一样的 对，这块我不该说成「看 CPU 型号」，得更正一下判据——决定能不能插的从来是两个槽的物理间距和电气走线，板子型号才是那个变量，不是 AM4/AM5 本身。
华擎 X570 就是好例子：官方 spec 里 X570 Creator 这类板子给的是 2× PCIe 4.0 x16（单卡 x16、双卡拆成 x8/x8），另外芯片组再挂一条 x4；两条全尺寸槽间距够，官方甚至直接标了 SLI/NVLink 支持。所以「AM4 给不出双 x16」这话我说窄了，应该是「AM4 上大部分中低端板给不出双 x16，高端板给得出」。
两个共同前提，买之前顺手核一下：
- 双卡在 AM4 上会拆成 x8/x8，PCIe 4.0 x8 约等于 3.0 x16（≈16GB/s），对 decode 影响很小，对加载/offload 有轻微影响，不必为它纠结。
- 确认第二条全尺寸槽是 CPU 直连（电气 x16/x8）还是芯片组出的 x4——后者那条只能当副卡用。这个看主板手册的 block diagram 最准。
结论不变：要想双卡舒服，先看槽距和走线，再看平台。谢谢补这个数据点。
-
@flyer666 谢谢回复和指导。您这个思路很有道理，我这边同时跑着两个 Hermes 本地 AI Agent基本都是发散性任务，所以 fresh prefill 确实很多。
- 关于您的第一点建议：
我这边实测下来，感觉不只是 7900 XTX 的算力瓶颈。测试时先让 A 完成 64K prefill 并进入正常 decode，单路大约 80 tok/s。5 秒后再让 B 加入一个 64K fresh prefill，结果 A 会连续 47.2 秒完全没有 token 输出，也就是从约 80 tok/s 直接掉到 0，等 B 的 prefill 结束后才恢复正常.
这其实已经意味着，在我的实际 workload 下，长上下文双并发基本失败了：两路虽然都处于 running 状态，但第二路一做长 prefill，第一路几乎被冻结。更关键的是，当时 waiting=0，KV 使用率还不到 50%。后面我又分别关了 MTP、ROCm 7.2→10、chunk 4096→2048，结果 A 还是会停 45–54 秒，所以我更倾向这是 SGLang 的 long prefill / decode starvation，而不只是单纯算力不够。
- 关于您的第二点建议：
KV 我后来也调到了 265,950 tokens，C3 峰值才 62%，所以这次看起来也不像是 radix eviction。HiCache 我在5090 128G内存的另一台机器上上试过确实好用，但这台机器只有64G，而且还分了一半跑虚拟机，内存不够了，后面有机会加内存了我再试试。
我的部署基本完全让DSF按照您的帖子和推荐指南来的，但是我自己其实是个纯小白，所以现在也不敢百分之百确定是不是我这边某个配置还有问题。不过至少 SGLang 跑短上下文是真的香。刚开始测试的时候，会话很快，堪比DeepSeek Flash，四路并发也非常丝滑，所以一开始我其实挺惊喜的。只是上下文一长，特别是出现 fresh prefill 以后，实际体验就完全变了。我最近这一两个月学习到的东西比过去一年还多，CUDA，oneAPI，Level Zero，SYCL，OpenVINO，RCOm，Vulkan，llama.cpp, vLLM，SGLang这些遥远的名词居然也都亲自实践测试体验过了，在这个论坛真是大有收获了。
再次感谢大神的分享和热心回复。以后还要继续抱大神大腿，少走弯路！
@Ben-Lee 情况和你说的完全一样，在上下文140k 的时候， prefill 只有50t/s ，短板很明显。
