跳转至内容
  • 版块
  • 最新
  • 标签
  • 热门
  • 用户
  • 群组
皮肤
  • 浅色
  • 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. LLM讨论区
  4. X99+7900 XTX+7700 XT 跑 vLLM实测

X99+7900 XTX+7700 XT 跑 vLLM实测

已定时 已固定 已锁定 已移动 LLM讨论区
x997900xtxvllm
1 帖子 1 发布者 136 浏览
  • 从旧到新
  • 从新到旧
  • 最多赞同
回复
  • 在新帖中回复
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • zhenyu huangZ 离线
    zhenyu huangZ 离线
    zhenyu huang
    编写于 最后由 编辑
    #1

    已改成精简版帖子,只保留 vLLM 操作和实测。注释 1


    X99+7900 XTX/7700 XT 跑 vLLM:128K、缓存及 MTP 实测

    配置:X99-AD4、E5-2686 v4、64GB、7900 XTX 24GB+7700 XT 12GB。

    模型:Vishva007/Qwen3.8-27B-W4A16-AutoRound-GPTQ,vLLM 0.28.0、ROCm 7.2.3 wheel。

    1. 做了哪些修改

    操作 实验结果
    开启 Above 4G Decoding、ReBAR 双卡进入 Ubuntu,大 BAR 生效
    给主机桥 8086:6f00 加 P2PDMA 白名单,编译实验内核 缺 gawk 失败一次,补齐后完成,累计编译约54分钟;HIP peer 双向由0变1,复制和IPC校验通过
    换用 AMD RCCL build 38,移除 LD_PRELOAD 解决原库双卡 AllReduce 段错误,集合通信通过
    修正 GPTQ 零点传参、按显卡读取CU数量、开启decode graph,并加入MTP3 TP2下1K输入TG从5.87提高到47.26
    移植 JartX 的 RDNA3 prefill 调度参数 16K PP提高21.4%,32K提高42.2%
    改为不等量分层,让XTX承担更多层 长上下文PP提高,跑通128K

    注意:最终 RCCL 仍走 SHM,不能宣称高速P2P已打通;也未证明实验内核是最终方案的必要条件。

    2. PP/TG 实测

    JartX prefill 调整前后,保持TP2+MTP3:

    输入 调整前PP 调整后PP 调整后TG
    16K 561.8 682.2 29.23
    32K 452.9 644.0 17.89

    之后改成 TP1+PP2、7700 XT前20层/XTX后44层,无MTP、无缓存。单请求生成256 token:

    实际输入token PP(tok/s) TG(tok/s)
    4,096 1,016.56 27.55
    16,384 995.61 24.94
    32,768 933.16 24.78
    130,816 670.88 18.06

    最后一项输入+输出共131,072,整次请求209.1秒。分层后短上下文TG不如早期TP2+MTP3,但PP更高,32K生成也更快。

    3. 最终使用配置

    接入视觉后重新平衡显存,改成 18/46分层、128K、前缀缓存、最多4并发。batch预算1024,显存预算0.948,无MTP。

    测试 结果
    约3K输入/256输出 TG 28.74/28.93 tok/s
    7,552 token文本首次/重复请求 首token 7.451秒/0.788秒
    图片首次/重复请求 首token 2.146秒/0.591秒,均识别出数码管Ab
    保留视觉编码器,131,008输入+64输出 满128K请求186.1秒完成

    并发调优阶段,约7.5K输入/160输出、缓存已热:

    并发 每路TG 首token延迟
    2 18.83–20.46 0.828–1.630秒
    4 15.02–18.59 0.928–3.092秒

    这组并发数据使用0.94显存预算。前面的完整长上下文表属于纯文本20/44方案,不是最终视觉配置的成绩。四并发也不代表能同时容纳四个独立满128K请求。

    4. 为什么最终没留MTP

    适配PP+MTP后,约3K输入、256输出:

    配置 两次TG(tok/s)
    无MTP 28.62/28.80
    MTP1 14.88/15.06
    MTP2 16.59/16.50
    MTP3 18.55/18.83

    MTP实验为8K、无缓存,基线为128K+缓存,是部署方案对比而非严格单变量实验。虽然成功运行,但TG下降,因此撤回。

    DFlash2也试过:1K输入TG从30.01到32.58,但受显存限制,完成测试的上下文上限只有2304;runner与缓存配置也不同,不能视为严格加速对照,最终放弃。

    目前保留无MTP的128K+视觉+缓存方案,DSH和公网接口均已接通。单流约3K上下文TG为29 tok/s,多会话主要依靠前缀缓存减少重复处理。

    以上均为短期实测:128K验证的是容量,不是长期稳定性或长上下文语义能力。

    1 条回复 最后回复
    0

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

    厌倦了每次访问都刷到同样的帖子?您注册账号后,您每次返回时都能精准定位到您上次浏览的位置,并可选择接收新回复通知(通过邮件或推送通知)。您还能收藏书签、为帖子顶,向社区成员表达您的欣赏。

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

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


    • 登录

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