跳转至内容
  • 版块
  • 最新
  • 标签
  • 热门
  • 用户
  • 群组
皮肤
  • 浅色
  • 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. 双 A10 运行:Qwen3.8-Flash-Next 非统一内存异构推理实测

双 A10 运行:Qwen3.8-Flash-Next 非统一内存异构推理实测

已定时 已固定 已锁定 已移动 LLM讨论区
多卡部署qwen
3 帖子 1 发布者 229 浏览
  • 从旧到新
  • 从新到旧
  • 最多赞同
回复
  • 在新帖中回复
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • BunseiB 在线
    BunseiB 在线
    Bunsei
    劳动模范
    编写于 最后由 Bunsei 编辑
    #1

    前排提醒:楼主社畜今天要上班,所以这些测试是交给 Codex 完成的,具体细节没有完全核实。

    昨天 Qwen3.8-Flash-Next 正式发布,官方公布的能力和效率数据都很亮眼,鉴于Qwen3.8-27B优秀的表现,所以我产生了在本地部署的想法。

    不过,这个模型即使采用 Q4_K_XL 量化,文件仍有约 103.69 GiB,已经远超普通消费级显卡或双卡平台的总显存。我的本地机器目前内存容量也不够,如果决定长期运行,还需要再增加一组内存。

    在直接购买硬件之前,我权衡了一下,决定先租用一台双 A10 24GB、128GB 系统内存的服务器,做一次完整的异构推理测试。

    省流:

    配置 Prompt 512 生成速度
    单 A10+CPU,12/48 层进显存 305.71 tok/s 10.66 tok/s
    双 A10+CPU,24/48 层进显存 361.66 tok/s 13.91 tok/s
    双 A10+CPU,但总共仍只放12层 292.12 tok/s 8.91 tok/s
    完全 CPU 55.29 tok/s 9.07 tok/s
    双 A10+CPU-MoE 73.65 tok/s 12.76 tok/s

    双卡主配置相对单卡:

    • Prefill 提升约 18.3%
    • 生成速度提升约 30.4%
    • 但双卡本身不会自动加速。相同12层拆到两张无 P2P 的显卡后,反而比单卡更慢。

    双卡主配置的长上下文速度:

    上下文 Prefill 生成速度
    32K 211.59 tok/s 9.41 tok/s
    64K 136.42 tok/s 7.74 tok/s
    130K 85.01 tok/s 4.45 tok/s

    一句话总结:单 A10+CPU 约 10.7 tok/s,双 A10+CPU 约 13.9 tok/s;到 130K 上下文时双卡约 4.45 tok/s。双卡的收益来自装入更多权重,而不是两张卡的算力直接叠加。

    1 条回复 最后回复
    0
    • BunseiB 在线
      BunseiB 在线
      Bunsei
      劳动模范
      编写于 最后由 Bunsei 编辑
      #2

      本地平台与升级目标

      我的本地平台配置如下:

      项目 配置
      CPU AMD Ryzen 7 9700X,8 核 16 线程
      主显卡 AMD Radeon AI PRO R9700,32GB GDDR6
      第二张显卡 AMD Radeon RX 9070,16GB GDDR6
      显存总容量 48GB,但两卡容量为非对称的 32GB+16GB
      当前系统内存 2×24GB DDR5-6000 C28,双通道,标称共 48GB
      计划升级 再增加一组 2×24GB,达到 96GB 系统内存
      操作系统 Ubuntu 26.04 64 位
      GPU 计算环境 ROCm 7.14

      因此,我真正想模拟的本地部署环境并不是“双 R9700”,而是:

      Ryzen 7 9700X
      ├─ R9700 32GB
      ├─ RX 9070 16GB
      └─ 计划升级至 96GB DDR5 系统内存
      

      两张本地显卡合计也是 48GB 显存,与云服务器的双 A10 24GB+24GB在总容量上非常接近。不过两者的显存分布不同:双 A10 是对称的 24GB+24GB,本地则是非对称的 32GB+16GB。

      因此,云端测试使用的 1:1 分层比例不能直接照搬到本地。实际部署时,需要让 R9700 承担更多模型层和运行缓冲区,RX 9070 承担较少部分,同时继续把 PLE 表及放不下的权重留在系统内存中。

      云端测试平台

      项目 云服务器配置
      云平台 阿里云 ECS,KVM 虚拟机
      CPU Intel Xeon Platinum 8369B
      CPU 规模 16 个物理核心、32 个逻辑线程
      NUMA 单 NUMA 节点
      系统内存 标称 128GB,系统可见约 123.3GiB
      持续内存带宽 Copy 约 112.56GB/s,Triad 约 133.42GB/s
      GPU 2×NVIDIA A10 24GB
      CUDA 可用显存 每卡约 24,115MiB
      GPU 互联 无 NVLink,不支持 CUDA P2P
      PCIe 两卡均为 PCIe 4.0 x16
      Host→GPU 约 23.9–24.1GB/s
      GPU→Host 约 26.3GB/s
      GPU 间主机中转 单向约 20.2GB/s
      操作系统 Ubuntu 22.04.5 LTS
      推理引擎 llama.cpp Flash-Next 开发分支
      模型 Unsloth UD-Q4_K_XL,四分片 GGUF
      模型大小 103.688GiB

      两个平台的可比性

      对比项 本地目标平台 云端测试平台
      GPU R9700 32GB+RX 9070 16GB A10 24GB+A10 24GB
      标称总显存 48GB 48GB
      显存分布 非对称,32GB+16GB 对称,24GB+24GB
      系统内存 计划升级至 96GB 128GB,系统可见约 123.3GiB
      内存类型 双通道 DDR5,升级后为四根 DIMM 多通道服务器 DDR4
      内存带宽 尚需升级后实测 持续 Copy 约 112.56GB/s
      GPU 软件栈 ROCm CUDA
      主要用途 最终本地部署 验证架构可行性与性能边界

      DDR5-6000 双通道的理论带宽为 96GB/s,而云服务器实测的持续 Copy 带宽已经达到约 112.56GB/s,超过了本地当前内存配置的理论上限。实际应用带宽通常还会低于理论值。

      此外,AM5 平台插满四根 DDR5 DIMM 后,内存频率和时序可能需要降低。因此,升级到 96GB 后虽然容量足够,但 CPU offload 和 CPU-MoE 的实际速度很可能低于此次云服务器测试。

      从容量上看,计划中的 96GB 系统内存加48GB显存,标称总容量约为144GB,容纳103.69GiB模型、运行缓冲区和长上下文缓存具有现实可能性。但 RAM 与 VRAM 并不是可以无条件相加的统一内存池,还会受到单卡显存余量、模型层边界、KV 缓存、计算图缓冲区以及 ROCm placement 支持情况的限制。

      因此,这次双 A10 测试能够回答的是:

      103.69GiB 的 Q4_K_XL 模型,在总显存约48GB、其余权重驻留系统内存的条件下,能否通过 llama.cpp 稳定运行,以及这种方案大致存在怎样的性能边界。

      它不能直接保证本地 R9700+RX 9070 能得到完全相同的速度。正式迁移时,仍需重新验证非对称双卡分层、ROCm 支持、PCIe 拓扑、P2P 状态和升级后的真实内存带宽。

      1 条回复 最后回复
      0
      • BunseiB 在线
        BunseiB 在线
        Bunsei
        劳动模范
        编写于 最后由 编辑
        #3

        完整测试数据表

        测试类型 配置/上下文 GPU层数 CPU-MoE Prompt/Prefill Generation 峰值RSS/资源 备注
        短基准 双A10主配置 24 否 361.66 tok/s 13.907 tok/s RSS约67.7 GiB;显存约19/19 GiB 当前综合最优
        单卡对照 单A10 12 否 305.71 tok/s 10.663 tok/s RSS约86.4 GiB;GPU1未使用 单卡+CPU异构
        双卡流水对照 双A10,总计仍为12层 12 否 292.12 tok/s 8.909 tok/s RSS约86.5 GiB 比单卡更慢,decode波动较大
        纯CPU对照 完全CPU 0 否 55.29 tok/s 9.065 tok/s RSS约104.36 GiB;显存0 验证高速内存影响
        CPU-MoE 双A10,全部routed experts在CPU 24 48层 73.65 tok/s 12.759 tok/s RSS约102.18 GiB;显存约1.5/2.1 GiB 保留91.7%主配置decode
        API短提示 18-token prompt 24 否 31.03 tok/s 13.58 tok/s 双卡+CPU 固定开销占比较高
        重复文本 2,207-token prompt 24 否 354.79 tok/s 12.43 tok/s 双卡+CPU 重复度高,只作乐观上界
        长上下文 32,768 tokens 24 否 211.59 tok/s 9.41 tok/s 增量耗时156.5秒 从空slot开始
        长上下文 65,536 tokens 24 否 136.42 tok/s 7.74 tok/s 新增32,772 tokens,耗时242.2秒 复用前32,764 tokens
        极限上下文 130,000 tokens 24 否 85.01 tok/s 4.45 tok/s 新增64,468 tokens,耗时765.4秒 最终slot约130,031 tokens
        满上下文资源 130K填充完成 24 否 — 4.45 tok/s RSS约72.54 GiB;显存22.2/21.4 GiB 系统仍约47 GiB available
        内存带宽 1线程 — — Copy 14.60 GB/s — Triad 15.41 GB/s 单线程
        内存带宽 8线程 — — Copy 77.34 GB/s — Triad 91.30 GB/s —
        内存带宽 16线程 — — Copy 110.12 GB/s — Triad 130.82 GB/s 物理核心数
        内存带宽 32线程 — — Copy 112.56 GB/s — Triad 133.42 GB/s SMT增益很小
        PCIe GPU0 Host→Device — — 23.95 GB/s — PCIe 4.0 x16 —
        PCIe GPU1 Host→Device — — 23.91 GB/s — PCIe 4.0 x16 —
        PCIe GPU0/1 Device→Host — — 26.30/26.29 GB/s — PCIe 4.0 x16 —
        本地显存 GPU0/GPU1 — — 558.04/558.06 GB/s — ECC关闭 两卡对称
        跨卡能力 GPU0↔GPU1 — — P2P不支持 — 无NVLink,经主机桥接 单向中转约20.2 GB/s
        1 条回复 最后回复
        3

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

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

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

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


        • 登录

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