环境：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%。

独立清场复测一次，两批数据全部在 ±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。两边都是各家引擎的调优满血态。

怎么读：

• 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 交叉核对。未引用任何第三方帖子的公开数字。