环境：i7-10700K（8C16T，无 AVX-512）+ 2× RX 7900 XTX 24GB + 64GB DDR4 + Ubuntu 22.04 / ROCm 7.2.1
模型：Qwen3.8-Flash-Next-AD-4.27bpw-Q4_K_M-M64（33 分片，89GB，512 专家）
引擎：Strata v0.1.38 HIP 后端 · 32K 上下文 · int8 KV · --spec 4 投机解码
实测日期：2026-10-04

首先说明，这是ai生成的报告，如果不想看内容，建议直接复制丢给ai总结

TL;DR

1. 能跑。 单卡 7900 XTX 就能带起 89GB 的 MoE —— 专家权重常驻内存、最热的缓进显存。单卡稳态 decode ≈ 63~66 tok/s、prefill 600+ tok/s。
2. 双卡只在 prefill 上赢。 多轮对话的追加延迟从 1444ms 砍到 754ms（快 1.9 倍）；decode 反而略降（66 → 63），因为 decode 是显存带宽瓶颈，layer-split 每步多一次跨卡同步。
3. prefill 原本比官方低 35%，根因是自己踩的坑：hipBLASLt 调优表按「架构 + 库版本」精确匹配，官方 gfx1100 只给了 100100/100200 两张，我这台是 100202 → 无表可用 → dense GEMM 走默认路径。自己标定一张接进去，fresh 8.8K prefill 722 → 1016 tok/s（+41%），直接反超官方。
4. 一共踩了 7 个坑，第 5 个（调优表）是最大的性能损失，第 7 个（大页）是「看起来该做、实测完全没用」的反面教材。

1. Strata 是什么

Strata 是一个 MoE 专用推理引擎（https://github.com/Niko1221/Strata）。核心思路和 llama.cpp 不一样：

• 专家权重不像传统做法那样全塞进显存，而是常驻主机内存，只把路由最频繁的一小撮专家缓存进显存；
• 显存里的专家直接由 GPU 算，没命中的走 CPU/SSD 路径；
• 于是 24GB 的消费级卡也能跑 89GB 的大模型。

它还带一个 opt-in 的 gfx1100 HIP 后端，让 RDNA3 的 A 卡能用上 MMQ、校准过的 hipBLASLt dense GEMM、MTP 投机解码这些优化。

对「双 7900 XTX + 大内存」这种配置来说，这是目前少数能让两张 XTX 真正一起干活的路径 —— llama.cpp 跑这种体量的 MoE，要么装不下、要么慢到没法用。

2. 硬件配置（全部实测，非标称）

两个先天短板（后面会反复出现）：

1. CPU 没有 AVX-512 —— 引擎启动时直接点名：

   strata generate: this CPU has no AVX-512: the expert kernels run on AVX-2
   

   官方测试机是 Ryzen 9 7950X3D（16C32T + AVX-512），CPU 侧算专家比我快不少。
2. 内存只有 64GB 且无 swap —— 而模型光专家就要 47.17 GiB。双卡全驻留会压到危险线。

3. 模型与引擎：真实的加载方式

这部分我一开始理解错了，写出来给后来人少走弯路。

模型：Qwen3.8-Flash-Next-AD-4.27bpw-Q4_K_M-M64，33 个分片共 89GB，架构 qwen4exp，512 个专家。

Strata 不是把 89GB 全重新打包一遍。 它生成的 pack 目录只有 1.4 GiB：

packs/iq3_xxs/
  dense.bin          1.42 GiB   ← 只有非专家的 dense/attention 权重
  native_experts.txt     8 KB   ← 48 层专家的清单（偏移表）
  index.txt             91 KB
  tokenizer/

native_experts.txt 的头两行说明了关键机制：

# strata native experts v4: ... (n_expert 512, total 50646220800;
#   absolute offsets in Qwen3.8-Flash-Next-AD-4.27bpw-Q4_K_M-M64-00001-of-00033.gguf ...)
0 21 20 0 2329600 1193596736 1561038656 719996736 ...00003-of-00033.gguf

专家权重根本没被搬走 —— 它们原样留在原来的 33 个 GGUF 分片里，引擎记下每层每专家 gate/up/down 的绝对偏移，运行时直接从分片读。50646220800 字节 = 47.17 GiB，正好等于引擎启动时那句 loaded 47.17 GiB。

另外两个附件：

磁盘预留：原 GGUF 89GB + Strata-data 41GB ≈ 130GB，而且原 GGUF 必须留着（专家从它读）。

引擎：Strata v0.1.38，HIP 后端。实测启动参数：

--expert-cache auto --prefill auto --spec 4 --spec-min-p 0.5
--mtp .../mtp/rt --max-context 32768 --kv int8 --ple-gguf .../ple-q5_0.gguf
--layer-split auto

4. 部署步骤

# 1) 编译（用系统已装的 ROCm 7，不必再下 10GB 的 wheel）
./setup.sh --backend hip --family qwen --model IQ3_XXS \
  --gguf-dir /path/to/Qwen3.8-Flash-Next-AD-4.27bpw-Q4_K_M-M64 \
  --data-dir /path/to/Strata-data --context 32768 \
  --gpu 0 --build --no-start --yes

# 2) 单卡启动
run-iq3_xxs.sh
#    内部即 serve/server.py --engine strata --config strata-iq3_xxs.json --port 8080

# 3) 双卡：setup 时把 --gpu 0 换成 --gpus 1,0（自动 layer split）

我这台 8C16T 编译耗时 8 分钟（官方标称 10~20 分钟）。

5. 实测速度

方法：用官方 tools/hip/bench_prefill.py，同一份合成 prompt（140/280 个 rule 函数），每档先 warmup 一次、再跑 2 轮，每轮先 fresh（零复用 KV）、紧跟一个 followup（带缓存追加）。输出固定 128 token，温度 0 / top-k 1。每组配置独立重启引擎后测量。

单位 tok/s，括号内是波动范围。

加调优表之后（见坑 5）：

引擎日志里的关键指标（同一批请求）：

• 显存专家缓存命中率：96.9% ~ 99.5%（第一个冷请求 87.7%，长 prompt 越接近 99.5%）
• 投机解码接受率：70.6%（3116/4412）
• layer split 决策：K=22，CUDA1 跑第 22~47 层 + head，CUDA0 跑第 0~21 层；CUDA1 专家缓存 8704 槽（16.81 GiB）
• PCIe 探测：单卡 6.9 GB/s → pcie_frac 0.19（默认 0.55）

6. 三个反直觉的结论

① 双卡的收益全在 prefill，decode 甚至倒退。

decode 阶段每生成一个 token 只算一遍专家，瓶颈是显存带宽；layer-split 让每层之后都要跨卡同步一次，纯亏。而 prefill 是把上万 token 一次性塞进去算，compute-bound，两张卡并行摊分，稳赚。

所以 「双卡加速」是有条件的：看你负载是长 prompt（RAG / 代码库分析 / 长文档）还是长输出（写作 / 聊天）。

② followup 那一行的 78.6 → 149.8，不是「吞吐翻倍」，是「每轮固定开销减半」。

它只处理 113 个新 token，却花了 1444ms（单卡）/ 754ms（双卡）—— 这是 prompt 分块的固定成本。换成体感：多轮对话里，第二轮开始每轮只等 1.44s 还是 0.76s，差一倍。这个才是双卡对聊天场景的实际价值。

③ low-RAM 模式掉得比想象中多。

4.2K prefill 只有 479，比单卡的 607 还低 21%，比双卡 native 低 32%。它换来的是内存安全垫 —— 如果你内存不够又要开双卡，这是唯一能稳跑的选择。

7. 踩的 7 个坑（含解法）

坑 1：Strata 不直接吃 GGUF，下载又慢到不能看

引擎要自己的 pack 目录（见第 3 节）。同时还要额外拿 PLE（32.78 GiB）和 MTP 草稿层（787 MiB）。

解法：预留 130GB 磁盘，下载走本地代理（我这边是 2080 端口的本地代理），直连速度没法看。原 GGUF 千万别删 —— 专家是从它读的。

坑 2：引擎要现场编译

./setup.sh --backend hip --build。我这台 8C16T 编了 8 分钟（官方标称 10~20 分钟）。依赖 build-essential git；系统要是已经装了 ROCm 7，可以直接复用，不用再下 10GB 的 TheRock wheel。

坑 3：47GB 常驻内存是硬门槛

引擎启动时把专家权重常驻主机内存：

strata generate: loaded 47.17 GiB at 2.58 GiB/s

64GB 的机器单卡勉强够；双卡同时做全量驻留会直接把内存压到危险线。官方为此提供了低内存模式（自适应驻留、装不下就退回 mmap），代价是 prefill 掉 32%（见对照表）。

注意：双卡 layer-split 模式下引擎还会警告：

WARNING: the resident RAM mode (--resident-experts) does not support a layer split yet:
the experts the GPUs do not hold are read through the OS file cache (--mmap-experts),
and RAM may fill up during long prompts

也就是 GPU 不持有的专家会走 OS 文件缓存，长 prompt 下 RAM 可能要涨。

坑 4：hipBLASLt 调优表没有可用的（本次最大性能损失）

官方的调优表是按 (架构 + hipBLASLt 版本) 精确匹配的，表头直接写着版本：

STRATA_HIPBLASLT_TUNING_V1 gfx1100 100200

引擎会硬校验架构和版本号，对不上就整张拒绝：

tuning architecture mismatch: file=... runtime=...
hipBLASLt version mismatch: file=... runtime=...

仓库里 gfx1100 只有两张表：-100100.txt 和 -100200.txt。我这台是 hipBLASLt 1.2.2 = 版本号 100202 —— 两张都对不上。（有意思的是同一个目录里 gfx1200 / gfx1201 都有 100202 的表，唯独 gfx1100 没有。）

结果：配置里根本没有 STRATA_HIPBLASLT_TUNING，dense 矩阵乘法走默认 GEMM 路径。

官方在 gfx1200 上量化过这张表的收益：2.4K prompt 提速 1.5x，65K/130K prompt 约 2x。gfx1100 官方没给数字，但机制相同。

解法 —— 自己标定一张（官方工具就摆在仓库里）：

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)
./build-hip/tune_hipblaslt $CASES --tuning-out tools/hip/gfx1100-hipblaslt-100202.txt

几个要点：

• 形状集取仓库两张 gfx1100 表的并集（30 个形状，100200 那张是它的子集），覆盖更全；
• 工具自带精度门（relative L2 / max abs / padding 写入检查），跑完 30 条全过、零 reject；
• 产出的表头就是运行时的真实版本：STRATA_HIPBLASLT_TUNING_V1 gfx1100 100202；
• 跑完几分钟，然后接进配置（strata-iq3_xxs.json 加一个 env 键）：

"env": {
  "STRATA_HIPBLASLT_TUNING": ".../tools/hip/gfx1100-hipblaslt-100202.txt"
}

重启后引擎日志会确认（两张卡各一行）：

prefill gemm: hipBLASLt tuning enabled (30 rows, gfx1100, version 100202)

效果：fresh 8.8K prefill 722 → 1016 tok/s（+41%），一次把「比官方低 35%」打成反超。

️ 别被工具自己的输出骗了：它报的 speedup_vs_blas 中位数是 5x（最高 18x），那是单条 GEMM 对 plain hipBLAS 的微基准，不是端到端收益。端到端看上面那张表。

️ 维护提醒：表是绑死 (架构 + hipBLASLt 版本) 的。升级 ROCm 后版本号一变，表就被拒，要重跑一次标定。

坑 5：冷启动第一枪很慢

第一次请求（显存专家缓存未热）decode 只有 39.9 tok/s（warmup 那枪甚至 19），第二枪才回到 64+。

解法：做基准测试必须先 warmup，否则平均分被第一枪拖死。这也是很多「评测翻车」的来源。

坑 6：NVMe 卷是 NTFS，断电后拒挂

这块数据盘是 NTFS 格式。强制断电后重新开机，Linux 会因为 dirty bit 直接拒绝挂载（$MFTMirr does not match $MFT）。

解法：sudo ntfsfix -d /dev/nvmeXnY，再 mount 即可。盘本身没坏，只是上次没正常卸载。

坑 7：大页 —— 看起来该做，实测完全没用（反面教材）

引擎启动时会抱怨：

expert arena: cudaHostRegister PORTABLE ok;
  MAP_HUGETLB unavailable (needed 24152 2 MiB pages, vm.nr_hugepages=0); using 4 KB pages

4KB 页下 47 GiB 要 1200 万个 TLB 项，任何 TLB 都装不下。官方的设计注释也说大页能把 TLB 覆盖翻倍以上。看起来是个大便宜 —— 我去试了，结论是：不值得。

第一关：运行时根本开不起来。

引擎要 24152 个 2 MiB 页（= 47.17 GiB，正好等于专家 arena），而 MAP_HUGETLB 是全有全无：池子少一页，整个映射就跟没有池子一样失败。

根因在 /proc/buddyinfo：运行中的内核 order-9（2 MiB 连续块）恒为 0。内存虽然有 15 GiB 空闲，但已被切碎到没有 2 MiB 连续块，压缩也合并不出来。只能开机预留（内存未碎片化时才能一次拿到）：

# /etc/sysctl.d/99-strata-hugepages.conf
vm.nr_hugepages = 24152

第二关：代价太大。 62.64 GiB 里内核/驱动先占掉约 9.8 GiB（iommu=pt + amdgpu），能给人用的只有 53 GiB。预留 47.17 GiB 后只剩 5.7 GiB 给整个系统（还没 swap）—— 开个浏览器就可能 OOM，ComfyUI / vLLM 全废。等于把这台机改成「Strata 专用机」。

第三关：就算成了，也没用。 我换了条零成本的路验证 —— 把 THP（透明大页） 从 madvise 切成 always，arena 的匿名内存在分配时就直接拿 2 MiB 页，不占任何预留：

引擎进程 RSS 49.56 GiB，其中 AnonHugePages = 38.38 GiB（77%）

覆盖率和预留大页池能给到的 38.5 GiB 几乎一样。但压测结果：

逐轮看，差值全在 run-to-run 噪声里（THP 组 8.8K 第二轮反而更高），followup 和 decode 两边几乎完全一致。

为什么？ 因为官方讲 TLB reach 的前提是「专家 arena 就是工作集」（小显存卡、流式取专家）。而这台机器 --expert-cache auto 拿了 8704~9724 个显存槽、命中率 96.9%~99.5% —— 绝大多数专家访问直接命中显存，主机 arena 的 TLB 根本没被压到。

结论：大页（预留池也好、THP 也好）在这台机器上没有可测收益，不值得拿 47 GiB 去换。

（THP 已还原成 madvise，机器状态和之前一致。）

8. 我的数字 vs 官方：差距在哪

官方在同型号 IQ3_XXS 上的数据（单卡 RX 7900 XTX / Ryzen 9 7950X3D 16C32T / 64GiB / Fedora / ROCm 7.1 / 272W 功耗墙 / 已启用 100100 调优表 / --resident-cpu-experts --mmap-experts 路径 / --max-context 262144 / --pool-workers 15）：

修好调优表之前，我的 prefill 低约 35%，decode 反而略高。 根因：

1. hipBLASLt 调优表无表可用 —— 主因，现已修复（+41%）；
2. CPU 没有 AVX-512 —— 官方是 Zen4，CPU 侧算专家吃亏；
3. CPU 核心数只有一半（8C16T vs 16C32T），引擎默认开 7 个 expert-pool worker；
4. 官方配置里还有 STRATA_PREFILL_MMQ=1、STRATA_PREFILL_RING=96、STRATA_IO_THREADS=32 这些运行时变量，我没启用；
5. 专家的驻留路径不同（官方 --mmap-experts --resident-cpu-experts，我是 pinned arena）。

公道说一句：这个对比不是干净的对照。官方是单卡 + 开了表 + 完全不同的专家路径 + 一个核心数是我两倍的 CPU。所以「我反超了官方」只在 8.8K fresh prefill 这一格成立，别当普遍结论。

decode 我略高的原因：24GB 单卡就能全量缓存最热专家（命中率 96.9~99.5%），加上投机解码接受率 70.6%，恰好把官方在更大上下文下的缓存优势抹平了。

9. 复现清单

# 1) 编译（HIP 后端，复用系统 ROCm 7）
./setup.sh --backend hip --family qwen --model IQ3_XXS \
  --gguf-dir /path/to/Qwen3.8-Flash-Next-AD-4.27bpw-Q4_K_M-M64 \
  --data-dir /path/to/Strata-data --context 32768 \
  --gpu 0 --build --no-start --yes

# 2) 单卡启动
run-iq3_xxs.sh
# 3) 双卡：setup 时用 --gpus 1,0（layer split 自动分配）

# 4) 标定本机 hipBLASLt 调优表（关键！）
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)
./build-hip/tune_hipblaslt $CASES --tuning-out tools/hip/gfx1100-hipblaslt-<arch>-<version>.txt
#    然后在 config 的 "env" 里加 STRATA_HIPBLASLT_TUNING 指向它

# 5) 压测（每档会 warmup 一次）
python3 tools/hip/bench_prefill.py --model MODEL_NAME --url http://127.0.0.1:8080 \
  --engine-log engine.log --label candidate --output candidate.json

引擎关键参数：

--expert-cache auto --prefill auto --spec 4 --spec-min-p 0.5 
--mtp .../mtp/rt --max-context 32768 --kv int8 --ple-gguf .../ple-q5_0.gguf

10. 结论

• 单卡就够用：不跑长文档/代码的话，7900 XTX 单卡 + Strata 是能真正把 89GB MoE 跑起来、而且速度可用的方案（decode 63~66 tok/s 对本地大模型来说相当体面）。
• 双卡要挑场景：长 prompt（RAG、代码库分析、长文档）收益显著（fresh prefill +15%，多轮追加延迟 −48%）；纯聊天生成没收益，还多占内存。
• 务必自己标定 hipBLASLt 调优表：这是投入产出比最高的一步（+10%~41%），官方工具就在仓库里，几分钟的事。不做的代价是 prefill 直接少三分之一。
• 大页别折腾：运行时开不起来，开机预留要拿 47 GiB 换，而且实测零收益。这条是省时间，不是省事。
• 写评测先 warmup：冷启动第一枪 decode 掉到 40 以下，不 warmup 的跑分会误伤一半结论。

数据来源：bench-single.json / bench-dual-native.json / bench-dual.json / bench-dual-table.json / bench-dual-table-thp.json 原始输出 + 引擎 v0.1.38 运行日志。每组配置独立重启引擎，每档 warmup 1 次 + 2 轮，同一台机器、同一份 prompt。