抡锤者

@张光璞 !

我用flash跑出来是这样的 6分钟左右

双卡实测输入会变快

我的话是双电源，选择另外一个电源750单独供应，然后开放式的，直接弄个十来块的大风扇对着吹，温度压在80左右，我是用pice延长线延长出来的，然后功耗我看了下基本是300附近，很少能一直突破出去 电感是在模型输出的时候就会有，停止输出了就没有了

环境：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. 硬件配置（全部实测，非标称）

项	值
CPU	Intel Core i7-10700K @ 3.80GHz，8C/16T，L3 16MB，无 AVX-512（只有 AVX2）
主板	ASUS ROG STRIX Z590-A GAMING WIFI
内存	64GB（2×32GB Corsair DDR4-3200），无 swap，系统可用 62.64 GiB
GPU	2× Radeon RX 7900 XTX 24GB，gfx1100，PCIe host→device 实测 6.9 GB/s
存储	aigo NVMe SSD P7000Z 2TB（数据都在这块盘上）
系统	Ubuntu 22.04.5 LTS，内核 6.8.0-138
ROCm	7.2.1（HIP 7.2.53211，AMD clang 22）
hipBLASLt	1.2.2，版本号 100202 ← 记住这个数，坑 5 全靠它

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

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。

另外两个附件：

文件	大小	作用
ple-q5_0.gguf	32.78 GiB	PLE（per-layer embedding 表），放 SSD 上按需读
mtp/rt	787 MiB	MTP 草稿层，投机解码用

磁盘预留：原 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，括号内是波动范围。

指标	单卡	双卡 native	双卡 low-RAM
fresh prefill 4.2K	607 (537~677)	702 (701~703)	479 (439~519)
fresh prefill 8.8K	628 (621~634)	722 (722~722)	543 (542~543)
followup prefill（113 token 追加）	78.6	149.8	107.8
↳ 这一轮的实际耗时	1444 ms	754 ms	1053 ms
fresh decode 4.2K	52.0 (40~64)	57.5 (54~60)	52.5 (46~59)
fresh decode 8.8K	66.0 (65~67)	62.9 (62~64)	60.7 (60~61)
followup decode 4.2K / 8.8K	50.2 / 61.7	58.3 / 55.8	53.3 / 56.1
稳态 decode（去掉每档第一枪）	~63	~59	~57
额外内存	~47GB 常驻，最省	双卡全驻留，最紧	自适应退回 mmap
VRAM 剩余	624 MiB	598 MiB	—

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

指标	双卡 native	双卡 native + 调优表	变化
fresh prefill 4.2K	702	773 (710~836)	+10%
fresh prefill 8.8K	722	1016 (992~1040)	+41%
followup prefill 4.2K	150	221	+47%
followup prefill 8.8K	153	175	+14%
decode（各档）	55.8~62.9	55.2~58.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 是全有全无：池子少一页，整个映射就跟没有池子一样失败。

尝试	拿到的页数
sysctl vm.nr_hugepages=24152	12557
丢 page cache + 反复补池	搬到 19570，然后每次只 +几页
内存压缩（compact_memory）+ 丢缓存 + 反复补	卡在 19698（38.5 GiB）
整池释放、压缩、一次性要满	还是 19698（复现两次，非随机）

根因在 /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 几乎一样。但压测结果：

档位	有调优表	+ THP
fresh 8.8K prefill（第 1 / 第 2 轮）	1040.1 / 991.5	900.0 / 1035.9
fresh 4.2K prefill（第 1 / 第 2 轮）	710.2 / 835.6	512.6 / 703.6
followup 4.2K prefill	270.3 / 171.3	269.9 / 170.5
decode（各档）	52.0~60.0	51.4~59.8

逐轮看，差值全在 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）：

指标	官方（单卡，有表）	我这台（单卡，原先无表）	我这台（双卡 + 自标表）
4.2K fresh prefill	447.5 首次 / 901.1 热	607 (537~677)	773
8.8K fresh prefill	873.7 首次 / 966.5 热	628 (621~634)	1016
decode	55.5 ~ 59.2	66 (65~67)	58.5 (双卡) / 66 (单卡)

修好调优表之前，我的 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。

@David-Wang 是的没错，双卡跑的

@kos-or 模型不推理的话甚至温度降到35度左右风扇都不带转的，之前不知道还以为显卡坏了怎么风扇不转了

@kos-or 是呀，二十多的那种风扇怼着吹，然后温度的话稳在80左右，核心温度差不多90

@kos-or 我直接用普通风扇怼着两张卡直吹

折腾下来你也是值了

我是用z590吹雪跑起来的，不过温度一直是个问题我就加了pcie延长线

我原本的游戏机场景然后现在就是单独加了张卡，如果专门跑ai的话那真的得去计算成本了，我就是7900xtx

我现在用着z590 用ddr4跑着速度勉强可以

好家伙，兄弟你是啥主板来着

@Kang-Benyuan 卧槽，现在都这么贵了？

具体是什么显卡，我看着不太明白

@imbiplaza-ASUS 那你慢慢等把，我没做，思路给到你了，要不要做你自己决定

@cc-tgo 感谢

@imbiplaza-ASUS 让ai自己做不就好，把你想法说出来，这也不是啥难事

不不，首先你得问下自己，这个事情做的时候，你喜欢么，你会不会因为这张卡的到来而欣喜，你把未来价值和单纯的兴趣爱好绑定在了一起，你担心你为了兴趣而买东西的时候，是对自己的资源造成浪费，但是你要知道，这其实就是用钱，买了你的快乐，你既然已经花出去了，为什么还要纠结价值损失，你已经有付出了，而且得到收获了，后面你就算不要买了，就算只价值一半，其实就可以认为你用更少的钱提前获取了当前的快乐，你要理清楚，我需要什么？我改付出什么

@imbiplaza-ASUS 那弄一个telegram对接智能体插件就行了，本质只是换了个对话方式