跳转至内容
  • 版块
  • 最新
  • 标签
  • 热门
  • 用户
  • 群组
皮肤
  • 浅色
  • 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 广场
Benjy LeiB

Benjy Lei

@Benjy Lei
取消关注 关注
关于
帖子
3
主题
1
分享
0
群组
0
粉丝
0
关注
0

帖子

最新 最佳 有争议的

  • 双 7900 XTX 跑 Strata 的生产基线、坑全记录,外加和 Strix Halo halogen 的同 prompt 对决
    Benjy LeiB Benjy Lei
    AI硬件 7900xtx strata 多卡部署

    双 7900 XTX 跑 Strata 的生产基线、坑全记录,外加和 Strix Halo halogen 的同 prompt 对决

    环境:Ryzen 5 3500X(6C/6T,Zen2,无 AVX-512)+ 2× RX 7900 XTX 24GB + 62GB DDR4(X570)+ NVMe,Ubuntu,ROCm 10 userspace(HIP 7.15.26333)

    模型:Qwen3.8-Flash-Next GSQ-RCO IQ3_S(83.6 GB,2 分片,48 层 × 512 专家)

    引擎:Strata v0.1.41 HIP 后端 · 131K 上下文 · int8 KV · layer split K=21 · --batch-groups auto(2 groups of 2 slots)· parallel 4 · 自标定 30 行 hipBLASLt 调优表 · WMMA prompt attention ON · CPU vision encoder

    实测日期:2026-10-09。这台机器是 7×24 生产服务(systemd strata-llm.service),下面所有数字都是实机跑出来的,不是官方转述。

    TL;DR

    • 生产稳态基线:fresh prefill 1,628–1,939 tok/s(7K–28K prompt),decode 53–60 tok/s,显存专家缓存命中 99.0–99.4%,MTP draft 接受率 60–75%。
    • 和 Strix Halo(128GB 统一内存)跑 halogen 的同 prompt 对决:长 prompt prefill 双 XTX 赢 10%(1,918 vs 1,744);短 prompt TTFT halogen 赢(0.31s vs 0.83s);decode 两边打平在 ~55 tok/s。48GB 分立式显存 + 62GB DDR4 ≈ 128GB 统一内存,在这个 workload 上等价。
    • 最大的坑不是部署,是「静默损失」:hipBLASLt 调优表版本对不上会静默退回默认 GEMM(无报错,prefill 少 30–40%);262K 上下文会静默吃掉专家缓存(decode 命中率 93%→61%)。两个都不弹错。
    • 版本迭代约每周一版,别照旧帖抄 flag:--mtp-window 在 0.1.39+ 已经不存在了。

    1. 配置与启动关键日志

    引擎启动日志里的关键行(复现时拿这些当 checklist):

    layer split auto: K=21 ... the caches hold 19136 of 24576 profiled pairs (~99.2%)
    layer split: CUDA0 runs layers 0-20 / CUDA1 runs layers 21-47, expert cache 6238 slots
    expert cache 8615 slots, 15.43 GiB of VRAM
    loaded 46.84 GiB at 1.66 GiB/s
    --batch-groups auto: 2 groups of 2 slots
    prefill gemm: hipBLASLt tuning enabled (30 rows, gfx1100, version 100202)   ← 两张卡各一行
    STRATA_HIP_WMMA: the prompt attention on matrix cores on (gfx1100)
    WARNING: prompt chunk 27392 tokens, not 32768: CUDA1 has 6238 expert-cache slots ... (#448)
    

    config json 要点:"gpu": [0, 1]、"layer_split": "auto"、"parallel": 4、env 三件套 STRATA_HIP_WMMA=1 / STRATA_PREFILL_AUTO_MAX=32768 / STRATA_IO_THREADS=32、STRATA_HIPBLASLT_TUNING 指向自标定表。

    RAM 实况:131K 上下文 + parallel 4 常驻 55/62 GiB,缓冲只剩 ~7 GiB。启 Strata 前必须停掉其他 GPU/RAM holder(我们之前 SGLang 27B 常驻时 RAM 只剩 15 GiB,IQ3_S 的 46.8 GiB 专家 arena 根本起不来)。

    2. 生产基线(v0.1.41,131K,实测)

    方法:同一份中文 prompt(材料 + 固定问题,全文见下),temp 0,reasoning_effort: none,固定输出 256 token,每枪前缀加随机 nonce 保证零缓存复用,warmup 一枪丢弃后测 2 轮,速率全部取 API usage 计数(不数 SSE chunk)。

    测试 prompt(short 档 = 只发问题;medium 档 = 材料重复至 ~12,000 字符(约 55 遍)+ 问题,tokenize 后 ~7.0K tok;long 档 = 重复至 ~48,000 字符 + 问题,~27.8K tok):

    在分布式系统的共识算法中,Raft 通过领导者选举、日志复制与安全性三条规则保证状态机一致。实现者需要处理选举超时、预提交与提交索引、网络分区下的多数派约束,以及快照压缩带来的日志截断问题。本节讨论的工程细节包括:心跳周期与随机化超时的取值、日志批量化对尾延迟的影响、成员变更采用联合共识的原因,以及读线性化与租约机制的权衡。调试点包括领导者抖动、磁盘 fsync 与批量提交的交互、跨机房 RTT 对选举稳定性的冲击,以及运维侧的可观测性设计。

    问题:请分点说明 Raft 在网络分区下如何保证已提交日志不会被覆盖,并给出工程上验证这一性质的测试方法。

    每枪实际发送的内容前面还有一行 [<12 位随机字母数字>] nonce 前缀(例:[K7X2M9QA4T1B]),同一档内每枪都不同——这是为了强制 cached_tokens: 0,两个引擎谁也别想吃到 prompt cache。token 数按引擎各自 tokenizer 计(CJK 约 0.58 tok/字符),两引擎对同一文本的 prompt_tok 差异 <0.1%。

    prompt 档 prompt tok TTFT prefill decode
    short ~170 0.80–0.83s (固定开销主导,无意义) 55.7–57.1
    medium ~7.0K 4.19–4.28s 1,628–1,671 54.1–60.3
    long ~27.8K 14.35–14.51s 1,915–1,939 53.5–57.0

    独立清场复测一次,两批数据全部在 ±5% 内互相吻合——上面是两批合并区间。

    引擎日志侧证(同一批请求):prompt 27819 tokens = 0 reused + read in 14381 ms (1934.5 tok/s), 256 generated in 4467 ms (57.3 tok/s), drafts accepted 143 of 231。

    更长的档位(此前 v0.1.39 实测,同一台):65K prefill 2,339 tok/s(TTFT 27.8s)、100K 2,360 tok/s(TTFT 42.3s)、decode 55–63。prefill 随 prompt 变长反而变快——chunk 摊薄了固定开销,这是 MoE + 大 batch chunk 的正常形态。

    3. 对决:双 XTX Strata vs Strix Halo halogen(同 prompt)

    对面机器:Strix Halo(Ryzen AI Max+ 395,128GB LPDDR5x 统一内存),halogen-flash-server 0.17.3,v2 checkpoint(66.7 GiB + 51.2 GiB n-gram 表),KV pool 524,288,262K ctx。两边都是各家引擎的调优满血态。

    档位 指标 Strata(2×XTX + 62G) halogen(Strix Halo 128G)
    short ~170 tok TTFT 0.83s 0.31s
    decode 56.9 55.0
    medium ~7K tok TTFT 4.28s 4.10s
    prefill 1,635 1,706
    decode 59.0 53.1
    long ~27.8K tok TTFT 14.51s 15.95s
    prefill 1,918 1,744
    decode 53.9 53.7

    怎么读:

    • decode 打平在 ~55。Strata 的 decode 是显存专家缓存命中 bound(99%+ 命中),halogen 是投机解码 bound——两条完全不同的路径撞到同一个数字,挺有意思。
    • 长 prompt 双 XTX 赢:960 GB/s GDDR6 ×2 的算力在 compute-bound 的 prefill 上兑现成 +10%。
    • 短 prompt TTFT halogen 赢 2.7 倍:Strata 每次请求要过 batch window + 跨卡 hand-off,固定开销 ~0.5s;halogen 单 die 无跨卡同步。聊天体感上 halogen 更「跟手」。
    • 公道话:这不是干净对照——不同引擎、不同量化(IQ3_S vs halogen v2)、不同 CPU。但「48G 分立式显存 + 62G DDR4 ≈ 128G 统一内存」这个结论在两个方向上都被社区数据支持:统一内存机 decode 不吃亏,分立式显存机 prefill 不吃亏。
    • 成本侧:双 XTX 是洋垃圾路线(二手卡 + DDR4),Strix Halo 整机贵一个档次;Strata 这条路的意义就是让旧平台吃下 83.6GB 的 MoE。

    4. 踩过的坑(含解法)

    坑 1:setup 检测到两张卡,写出来的 config 还是单卡。 setup.sh 带 --gpus 0,1 也可能写出 "gpu": 0;引擎运行时又不接受 --gpus flag(unknown argument + help dump)。解法:setup 后必 grep config json 的 "gpu" 字段,手动改成 [0, 1]。

    坑 2:hipBLASLt 调优表静默失效(历史最大性能损失)。 表按(架构 + hipBLASLt 版本)精确匹配,对不上整张拒绝、dense GEMM 静默走默认路径,没有任何请求期报错,只有 prefill 慢 30–40%。两个变体:(a) 升级 ROCm 后版本号变了,旧表被拒;(b) 上游自带的 gfx1100-100202 表只有 26 行,自己标定的并集表是 30 行——git checkout 会把你的表覆盖回 26 行。解法:每次升级后看引擎日志有没有 hipBLASLt tuning enabled (30 rows, gfx1100, version <当前>),行数不对就重跑 tune_hipblaslt(~10 分钟,形状集取上游两张 gfx1100 表的并集)。另外工具打印的 speedup_vs_blas(中位 5x)是单条 GEMM 微基准,端到端只有 +10~41%,别引用。

    坑 3:--prefill auto 在 layer split 下会 clamp chunk。 日志 prompt chunk 27392 tokens, not 32768 ... (#448) 不是错配,是引擎算出小卡能外借的专家缓存上限,这就是有效值。

    坑 4:262K 上下文在 layer-split 机器上不是白送的。 启动时专家缓存直接缩水(CUDA0 −25%、CUDA1 −43%),所有请求的 decode 命中率 93%→61–69%,prefill chunk 再 clamp 到 14080。fresh prefill 本身不衰减(204K 仍 2,650 tok/s),但 262K 满上下文 TTFT 要 180–270s。结论:131K 是 keeper,262K 是偶尔读超长文档的逃生门。「262K 白送」的说法在单卡机上成立,layer split 上代价落在专家缓存。

    坑 5:冷启动第一枪 decode 掉到 40 以下。 专家缓存没热,第一枪能把平均分拖死一半。任何 benchmark 先 warmup。

    坑 6:./update.sh 换不掉正在运行的引擎二进制。 ninja 编译成功,copy 到 engine/ 时 [Errno 26] Text file busy,但 update.sh 照样打印 "Strata is updated",版本号还是旧的。解法:先 sudo systemctl stop strata-llm(system unit,普通 systemctl 会撞 Interactive authentication),再 update,完事验证 engine/BUILD.json 的 version 真的变了。

    坑 7:flag 会随版本蒸发。 --mtp-window 在 0.1.39 起不存在(旧帖「32K 以上加 --mtp-window 65536」只对 ≤0.1.38 有效);社区帖引用的 STRATA_HIP_PROMPT_F16 在 0.1.39/0.1.40.4 二进制里 grep 都是 0 hits。引用任何 flag/env 前先 grep 本机二进制的 --help。

    坑 8:RAM 是零和的。 131K + parallel 4 常驻 55/62 GiB。31GB RAM 的机器上 IQ3_S 结构性饿死(decode 27 vs 62),换 IQ3_XXS 才舒服;48GB 是社区验证过的地板,64GB 才从容。--resident-cpu-experts 和 layer split 不兼容(引擎直接退出),layer split 下 GPU 不持有的专家走 OS file cache,长 prompt 时 RAM 会涨。

    坑 9:parallel slot 每个都从专家缓存偷地。 每 slot ~0.56–1.8 GiB,4 slot 时串行请求也长期变慢 20%+。0.1.41 的 --batch-groups auto(每卡一组 slot 并行流水线)是双卡机的正解,+32~68% 多客户端吞吐且答案逐位一致。

    坑 10:CPU 没有 AVX-512(Zen2 及以前全都没有)时,走 CPU 的专家层慢 30–40%。 命中率 99% 时体感不明显,一旦命中率掉(比如坑 4 那种场景)差距立刻显形。

    坑 11:大页警告——直接无视。 0.1.39 之前引擎启动会抱怨 MAP_HUGETLB unavailable,看着像该去开大页。#2076 作者已经实测证伪:预留池全有全无、碎片化内核凑不满,开机预留 47 GiB 后整个 OS 只剩 ~5.7 GiB,换 THP 实测零差异——专家缓存命中 99% 时主机 TLB 根本没被压到。0.1.39+ 引擎已自动启用 THP largepages,这条现在连警告都没有了。

    5. ROCm 版本矩阵(gfx1100,社区交叉验证)

    • 已知好:ROCm 7.1–7.2 系(官方 gfx1100 参考数字是 7.1 测的)
    • 嫌疑:Ubuntu 26.04 上 setup 自动拉的 TheRock 7.10 wheel → 有帖子 decode 崩到 0.76 tok/s(~70x),同栈 llama.cpp 正常——新 AMD 机器先钉死 ROCm 7.1 系,用 llama.cpp HIP 跑对照来分离「引擎问题 vs 环境问题」。
    • hipBLASLt 100500 没有随包 gfx1100 表 → 静默退回 plain GEMM,必须自标定。

    6. 复现清单

    # 编译(复用系统 ROCm)
    ./setup.sh --backend hip --family qwen --model IQ3_S \
      --gguf-dir /path/to/IQ3_S --data-dir /path/to/Strata-data \
      --context 131072 --gpus 0,1 --build --no-start --yes
    # 必查:config json 里 "gpu": [0, 1]、"layer_split": "auto"
    
    # 自标定调优表(关键)
    cmake --build build-hip --target tune_hipblaslt
    CASES=$(awk 'NR>2 {printf " --case %s,%s,%s,%s,%s", $1,$5,$2,$3,$4}' \
            tools/hip/gfx1100-hipblaslt-100100.txt)   # 并集两张上游表 = 30 形状
    ./build-hip/tune_hipblaslt $CASES --tuning-out tools/hip/gfx1100-hipblaslt-<version>.txt
    # config env 加 STRATA_HIPBLASLT_TUNING 指向它;日志确认 "30 rows"
    
    # 升级
    sudo systemctl stop strata-llm
    git fetch --tags && git checkout v<新>            # 上游改过 history 时 ff-only 会失败
    # 把自标定表盖回上游自带的那份,再 ./update.sh,验证 BUILD.json 版本变了
    sudo systemctl restart strata-llm                # 启动 ~90s
    
    # benchmark:清场 + nonce 防缓存 + warmup + usage 计数
    

    7. 结论

    1. 双 XTX + Strata 是旧平台吃 80GB+ MoE 的正解:decode ~54–57、prefill 1,915–1,939(27.8K 档),和 128GB 统一内存的 Strix Halo 同 prompt 打平手(长 prompt prefill 还赢 10%)。
    2. 131K 是 keeper,262K 是逃生门;代价不在 VRAM-per-context,在专家缓存。
    3. 每次升级后必查两行日志:hipBLASLt tuning enabled (30 rows...) 和 batch-groups 生效行。静默损失比崩溃危险得多。
    4. benchmark 三件套:清场、warmup、usage 计数。缺一个都会得出错误结论。
    5. 追求 prefill 的场景(RAG/长文档)双卡稳赚;纯聊天生成双卡相对单卡没优势(layer split 每层多一次跨卡同步),#2076 实测 decode 66→63。

    数据来源:全部数字来自本机同 prompt A/B 原始输出(两轮独立清场测量,互差 ±5% 内)+ Strata v0.1.41 引擎日志 + halogen /health、/metrics 交叉核对。未引用任何第三方帖子的公开数字。

  • 登录

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