@johnnybegood 对,不用三万,所以性价比很高——我整套加起来不到 25000:两张 7900 XTX 二手 13~16k,AM4 平台(CPU+板+64G DDR4+NVMe+电源机箱)大概八千上下。
Benjy Lei
-
双 7900 XTX 跑 Strata 的生产基线、坑全记录,外加和 Strix Halo halogen 的同 prompt 对决 -
双 7900 XTX 跑 Strata 的生产基线、坑全记录,外加和 Strix Halo halogen 的同 prompt 对决 -
双 7900 XTX 跑 Strata 的生产基线、坑全记录,外加和 Strix Halo halogen 的同 prompt 对决双 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 轮,速率全部取 APIusage计数(不数 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;引擎运行时又不接受--gpusflag(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. 结论
- 双 XTX + Strata 是旧平台吃 80GB+ MoE 的正解:decode ~54–57、prefill 1,915–1,939(27.8K 档),和 128GB 统一内存的 Strix Halo 同 prompt 打平手(长 prompt prefill 还赢 10%)。
- 131K 是 keeper,262K 是逃生门;代价不在 VRAM-per-context,在专家缓存。
- 每次升级后必查两行日志:
hipBLASLt tuning enabled (30 rows...)和 batch-groups 生效行。静默损失比崩溃危险得多。 - benchmark 三件套:清场、warmup、usage 计数。缺一个都会得出错误结论。
- 追求 prefill 的场景(RAG/长文档)双卡稳赚;纯聊天生成双卡相对单卡没优势(layer split 每层多一次跨卡同步),#2076 实测 decode 66→63。
数据来源:全部数字来自本机同 prompt A/B 原始输出(两轮独立清场测量,互差 ±5% 内)+ Strata v0.1.41 引擎日志 + halogen
/health、/metrics交叉核对。未引用任何第三方帖子的公开数字。