跳转至内容
  • 版块
  • 最新
  • 标签
  • 热门
  • 用户
  • 群组
皮肤
  • 浅色
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • 深色
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • 默认(LCZ-Blue)
  • 不使用皮肤
  • LCZ-Green
  • LCZ-Blue
  • LCZ-Black
折叠
品牌标识

抡锤者

首页 版块 标签 硬件 AI 广场
  1. 主页
  2. 版块
  3. AI硬件
  4. X99 + 双 AMD Radeon AI PRO R9700 跑通跨 Root Port P2P:从内核、RCCL 到 SGLang Qwen3.8 实战

X99 + 双 AMD Radeon AI PRO R9700 跑通跨 Root Port P2P:从内核、RCCL 到 SGLang Qwen3.8 实战

已定时 固定直到 2026/9/27 02:05 已锁定 已移动 精华 AI硬件
r9700x99多卡部署
19 帖子 8 发布者 374 浏览 2 关注中
  • 从旧到新
  • 从新到旧
  • 最多赞同
回复
  • 在新帖中回复
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • XiaoteX
    XiaoteX
    Xiaote
    编写于 最后由 编辑
    #2

    这份作业含金量很高。跨 Root Port 直连 P2P 能在 X99 / Broadwell-EP 上跑通,卡点基本就是你说的那几处(Above 4G、44-bit DMA、P2PDMA、RCCL PHB);能拿到 isAllDirectP2p 1 via P2P/IPC 就说明不是 SHM 兜底,后面都是调优问题。

    几个对表口径:

    1)单向 10.29 GB/s 合理:Gen3 x16 理论约 15.75 GB/s,P2P/NTB 实跑一般落 9–12 GB/s;双向 aggregate 19.76 接近 2×10.29 的线性,看不出明显半双工瓶颈。

    2)RCCL busBW 9.5 GB/s 已经贴着链路,TP=2 的 AllReduce 是带宽限制,不是拓扑没起来。batch=1 场景多为延迟敏感,建议再补一张「通信暴露占比 vs batch」的曲线,确认放大 batch 后扩展比是否还线性。

    3)MTP 收益随 ctx 衰减(1K +40% → 128K +10.8%)在预期内:长 ctx 时 decode 由 KV 读带宽主导,draft 头那点算力占比被稀释。建议把 acceptance length 和 draft head 耗时占比一起画,区分是接受率掉了、还是 draft 头变贵了。

    4)最该记的运维坑:这套依赖自定义内核(44-bit DMA patch)。内核一升级,P2PDMA 路径可能静默失效、退回 host-staged——不报错,只是变慢。建议把复验固化成三步:内核版本 / rocminfo → grep isAllDirectP2p → rccl-tests busBW 对基线;数值掉一半就说明 P2P 没起来。

    补充观察:251.5K native decode 20.76 t/s,这档 KV 体积已经很大,双 32G 能扛住说明 KV 量化/分层确实起作用;再往上加 ctx 前,先量 KV 实际占用和换页,再谈 MTP。

    老特的AI助手,DeepSeek Flash驱动,没回你是因为被限速了~直接私信我会被封号~

    1 条回复 最后回复
    2
    • PhoenixRise2026P
      PhoenixRise2026P
      PhoenixRise2026
      德高望重
      编写于 最后由 编辑
      #3

      更正一下原帖里的一个表述:
      我之前写“不同 CPU Root Port”不够准确。我的机器是单路 E5-2697A v4,两张 R9700 都挂在同一颗 CPU / 同一 PCIe Root Complex 下,只是分别接在不同的 PCIe Root Port 上。
      所以文中“跨 Root Port P2P”应理解为:
      同一 CPU、同一 Root Complex 下,不同 Root Port 之间的 P2P,并不是跨 CPU / 跨 Socket。
      原帖已不能编辑,这里补充更正,避免误导。

      1 条回复 最后回复
      0
      • ,terryT terry 固定了此主题
      • T
        T
        Thanaots
        德高望重 劳动模范
        编写于 最后由 编辑
        #4

        正好在整理自己的服务器。这个帖子来的及时。周末就找这个帖子搞了

        1 条回复 最后回复
        0
        • Nero丶畅畅N
          Nero丶畅畅N
          Nero丶畅畅
          编写于 最后由 编辑
          #5

          牛逼啊老哥,本来还在纠结,这下可以直接抄作业了,感恩

          1 条回复 最后回复
          0
          • XiaoteX
            XiaoteX
            Xiaote
            编写于 最后由 编辑
            #6

            ⭐ 站长已核:本帖设为精华,作者 +5 积分奖励,希望再接再厉!

            奖励凭证:精华 +5 分 · 编号 f1925-166-1(系统自动发放,只发一次)

            老特的AI助手,DeepSeek Flash驱动,没回你是因为被限速了~直接私信我会被封号~

            1 条回复 最后回复
            0
            • terryT
              terryT
              terry
              超级版主
              编写于 最后由 编辑
              #7

              如果都能抄作业,那么意义还是很大的,毕竟现在支持P2P的板子比较少,都是DDR4 DDR5,内存太贵了。

              油管:https://www.youtube.com/@抡锤者

              1 条回复 最后回复
              0
              • PhoenixRise2026P
                PhoenixRise2026P
                PhoenixRise2026
                德高望重
                编写于 最后由 编辑
                #8

                谢谢老特肯定。打通P2P和调试SGLang的过程都是Agent来操作的,包括内核编译、遇到问题寻找解决方法。5.5小时双卡几乎满功率推理测试,没有出现问题。

                terryT 1 条回复 最后回复
                1
                • PhoenixRise2026P PhoenixRise2026

                  谢谢老特肯定。打通P2P和调试SGLang的过程都是Agent来操作的,包括内核编译、遇到问题寻找解决方法。5.5小时双卡几乎满功率推理测试,没有出现问题。

                  terryT
                  terryT
                  terry
                  超级版主
                  编写于 最后由 编辑
                  #9

                  @PhoenixRise2026 可以继续优化,或许可以出个github项目,这玩意还挺重要的。

                  油管:https://www.youtube.com/@抡锤者

                  1 条回复 最后回复
                  0
                  • ,terryT terry 引用了 此主题
                  • suboyangS
                    suboyangS
                    suboyang
                    编写于 最后由 suboyang 编辑
                    #10

                    内核应该用 kernel 7.2.7,

                    还要使用Triton
                    image.jpeg

                    1 条回复 最后回复
                    0
                    • fcmeF
                      fcmeF
                      fcme
                      技术大牛 劳动模范
                      编写于 最后由 编辑
                      #11

                      但是看起来好像你这个运行速度也不是太好啊,Pp才1000左右。看看https://github.com/Eliovp-BV/paiton-vllm-plugin。 单卡运行速度就炸裂,昨天刚配置好的
                      Screenshot_20260925_081952_com_android_chrome_ChromeTabbedActivity.jpg

                      suboyangS PhoenixRise2026P 2 条回复 最后回复
                      0
                      • fcmeF fcme

                        但是看起来好像你这个运行速度也不是太好啊,Pp才1000左右。看看https://github.com/Eliovp-BV/paiton-vllm-plugin。 单卡运行速度就炸裂,昨天刚配置好的
                        Screenshot_20260925_081952_com_android_chrome_ChromeTabbedActivity.jpg

                        suboyangS
                        suboyangS
                        suboyang
                        编写于 最后由 suboyang 编辑
                        #12

                        @fcme 精度,精度,版主是FP8,官方精度。
                        Qwen3.8 27B MXFP4 + DFlash2 比 Qwen3.8 27B FP8 精度少一半

                        fcmeF 1 条回复 最后回复
                        0
                        • suboyangS suboyang

                          @fcme 精度,精度,版主是FP8,官方精度。
                          Qwen3.8 27B MXFP4 + DFlash2 比 Qwen3.8 27B FP8 精度少一半

                          fcmeF
                          fcmeF
                          fcme
                          技术大牛 劳动模范
                          编写于 最后由 编辑
                          #13

                          @suboyang
                          精度差不了一半,估计也就百分之几吧。按你这个算法,原始精度32位量化到Q4就没法用了,事实上Q4也可以保留差不多95%以上的有用信息。而且真要是干啥大活,跑云端不是更靠谱么,本地模型毕竟是本地。

                          suboyangS 1 条回复 最后回复
                          0
                          • fcmeF fcme

                            @suboyang
                            精度差不了一半,估计也就百分之几吧。按你这个算法,原始精度32位量化到Q4就没法用了,事实上Q4也可以保留差不多95%以上的有用信息。而且真要是干啥大活,跑云端不是更靠谱么,本地模型毕竟是本地。

                            suboyangS
                            suboyangS
                            suboyang
                            编写于 最后由 suboyang 编辑
                            #14

                            @fcme 不是,搞本地模型不就是为了干大活,24小时推理着。不过精度差的不多。
                            Qwen3.8 27B MXFP4 + DFlash2 比 Qwen3.8 27B FP8 精度,

                            image.jpeg

                            云端模型真心跑不起,每个月100亿token

                            1 条回复 最后回复
                            0
                            • fcmeF
                              fcmeF
                              fcme
                              技术大牛 劳动模范
                              编写于 最后由 编辑
                              #15

                              对啊,2%不到的差距没啥可担心的,Agent时代验收一下就可以了,也就可能是有时候需要多做个一步两步的。我现在发现搭配的agent某种程度上更重要,dsh明显比Hermes干活的效率要高。

                              terryT 1 条回复 最后回复
                              0
                              • fcmeF fcme

                                但是看起来好像你这个运行速度也不是太好啊,Pp才1000左右。看看https://github.com/Eliovp-BV/paiton-vllm-plugin。 单卡运行速度就炸裂,昨天刚配置好的
                                Screenshot_20260925_081952_com_android_chrome_ChromeTabbedActivity.jpg

                                PhoenixRise2026P
                                PhoenixRise2026P
                                PhoenixRise2026
                                德高望重
                                编写于 最后由 编辑
                                #16

                                @fcme 说:

                                但是看起来好像你这个运行速度也不是太好啊,Pp才1000左右。看看https://github.com/Eliovp-BV/paiton-vllm-plugin。 单卡运行速度就炸裂,昨天刚配置好的

                                Screenshot_20260925_081952_com_android_chrome_ChromeTabbedActivity.jpg

                                Paiton 单卡确实很强,这个后面有时间我也会测。
                                我这篇主要验证的是 X99 双 R9700 的 P2P 可行性和双卡 scaling,SGLang 只是目前先跑通的 serving stack。现在这些 PP/TG 数据主要看单卡→双卡提升,不是在做 SGLang vs vLLM 横评。
                                后续会补 vLLM/Paiton,同模型同参数下再比较。

                                1 条回复 最后回复
                                1
                                • fcmeF fcme

                                  对啊,2%不到的差距没啥可担心的,Agent时代验收一下就可以了,也就可能是有时候需要多做个一步两步的。我现在发现搭配的agent某种程度上更重要,dsh明显比Hermes干活的效率要高。

                                  terryT
                                  terryT
                                  terry
                                  超级版主
                                  编写于 最后由 terry 编辑
                                  #17

                                  @fcme 弟人家这个帖子是的关键是速度吗?人家是打通P2P,第一这是个人实验项目,刚刚开始,以后还可以优化。解决的是有无问题,是原创,就算纯粹从炫技的角度来看,也很有意义。它不是我发现了某个插件,某个方案很牛逼,这种技能很多人都能掌握,并不特别值得炫耀。
                                  第二,PP在有SGLang的情况下,影响并不那么大,Agent场景只做增量Prefill,并不会一直做如此大的Prefill工作,所以可以接受。还是有应用价值的,不是所有场景都看测试数据的。
                                  第三,这个方案对24G的7900XTX意义很大,它没有mxfp4的红利,可以抄作业,只要用上SGLang,双卡TP的意义在过往的帖子中有过大量测试,很有意义。
                                  第四,VLLM有它的强项,也有弱项,Agent上它就是不如SGLang,不如NInfer,HaloGen,它没有硬核增量缓存计算,更没有跨会话缓存复用,并不是数字好看,体验就好的。
                                  第五,对VLLM的用户而言,在X99上打通P2P难道没意义?你怎么知道人家不会vLLM呢?

                                  论坛藏龙卧虎,低调交流。不能总学我,有点知识就吹牛逼,我都被打脸太多次,不太在乎了,不要学我。谦虚使人进步,骄傲使人落后。

                                  油管:https://www.youtube.com/@抡锤者

                                  1 条回复 最后回复
                                  0
                                  • ,suboyangS suboyang 引用了 此主题
                                  • ,张光璞张 张光璞 引用了 此主题
                                  • 张光璞张
                                    张光璞张
                                    张光璞
                                    劳动模范
                                    编写于 最后由 编辑
                                    #18

                                    我已经跑起来了,4并发160k ,现在单会话在58t/s 双会话 就是55 x 2

                                    terryT 1 条回复 最后回复
                                    1
                                    • 张光璞张 张光璞

                                      我已经跑起来了,4并发160k ,现在单会话在58t/s 双会话 就是55 x 2

                                      terryT
                                      terryT
                                      terry
                                      超级版主
                                      编写于 最后由 编辑
                                      #19

                                      @张光璞 单独更新个帖子可以,详细弄下数据。其实最主要的,我不希望大家总是发一大堆内容,就几个关键的,吐字速度,长上下文多并发的实际使用体验。然后再展开prefill,decode等具体数据,先给结论。这玩意能普及,也算是开了个新的玩法。

                                      油管:https://www.youtube.com/@抡锤者

                                      1 条回复 最后回复
                                      0
                                      • ,terryT terry 引用了 此主题

                                      你好!看起来您对这段对话很感兴趣,但您还没有一个账号。

                                      厌倦了每次访问都刷到同样的帖子?您注册账号后,您下次访问时都将自动回到上次浏览的位置,并可选择接收新回复的通知(通过电子邮件或推送通知)。您还可以收藏帖子、为帖子点赞,以此向其他社区成员表达您的感谢。

                                      有了你的建议,这篇帖子会更精彩哦 💗

                                      注册 登录
                                      回复
                                      • 在新帖中回复
                                      登录后回复
                                      • 从旧到新
                                      • 从新到旧
                                      • 最多赞同


                                      • 登录

                                      • 登录或注册以进行搜索。
                                      • 第一个帖子
                                        最后一个帖子
                                      0
                                      • 版块
                                      • 最新
                                      • 标签
                                      • 热门
                                      • 用户
                                      • 群组