Strata 0.1.27 · ROCm 10.0 · 256K 上下文 · 1K~256K 八档实测 + hipBLASLt Prefill 调优

结论先行

• AMD RX 7900 XTX（24GB）+ 64GB DDR3，跑 Qwen3.8-Flash-Next（125B MoE） IQ3_XXS
• Prefill：峰值 1,602 tok/s，256K 超长 prompt 仍有 1,258 tok/s（读满 26 万 token 约 3.5 分钟）
• Decode：16K 以内 ~84 tok/s；32K 以上掉到 48–64 tok/s（可调优，见文末）
• hipBLASLt 调优：prefill 743 → 1179 tok/s（+58.7%），回退率 55.1% → 0%
• 全程 ROCm / HIP，不是 NVIDIA

一、配置

启动脚本：

#!/bin/sh
cd "~/Strata-main"
exec ".venv/bin/python" "serve/server.py" --engine strata \
  "--config" "strata-swift-iq3_xxs.json" "--port" "8080" "--open"

引擎参数（strata-swift-iq3_xxs.json）：

{
  "exe": "~/Strata-main/engine/strata",
  "args": [
    "--pack", "~/Strata-data/packs/swift-iq3_xxs",
    "--native", "~/Strata-data/models/swift-IQ3_XXS/Swift-....gguf",
    "--ple-gguf", "~/Strata-data/models/swift-IQ3_XXS/Swift-....gguf",
    "--expert-profile", "~/Strata-main/data/expert-profile.bin",
    "--expert-cache", "auto",
    "--prefill", "auto",
    "--spec", "4",
    "--spec-min-p", "0.5",
    "--mtp", "~/Strata-data/mtp/rt",
    "--max-context", "262144",
    "--kv", "int8"
  ],
  "port": 8080,
  "backend": "hip",
  "api_key": "<你的 API key>",
  "env": {
    "STRATA_HIPBLASLT_TUNING": "~/Strata-main/tools/hip/gfx1100-hipblaslt-100401.txt"
  }
}

二、实测结果

方法：每档用全新随机 prompt（cache_n=0，真全量 prefill），固定生成 256 token，temperature=0，顺序执行。

同配置跑两遍，prefill 偏差仅 ±0.2%（最大 1.9%），decode 偏差 ±1.4%。

三、Prefill 调优（hipBLASLt）

上面的 prefill 不是开箱就有的。 官方调优表版本是 100200，本机 hipBLASLt 是 100401，版本不等 → 引擎静默回退 hipBLASEx：

prefill gemm: hipBLASLt version mismatch: file=100200 runtime=100401; using hipBLASEx

用项目自带的 tools/hip/tune_hipblaslt.cpp 重新调优，三次迭代：

三个关键点：

1. 迭代 1 是弯路：调优器默认只覆盖 3 个形状，其余的仍在回退。当时以为"+12% 就是全部"，其实官方文档说的 +40–60% 是真的，是我的表不完整。
2. 迭代 3 才是大头：跑 STRATA_HIPBLASLT_VERBOSE=1 才发现仍有 55.1% 的调用在回退，根因只是 f16 N=1280 K=2560（出现 528 次）等两个盲区形状。
3. 查表是精确匹配：dtype/N/K/ldy 四项必须全等（只有 token 桶做最近邻），所以差一个维度就完全回退——必须用真实负载复查覆盖率。

调优表不与模型绑定，只绑「GPU 架构 + hipBLASLt 版本」，所以换模型直接沿用，不用重调。
decode 几乎不受影响（+2.8%）：hipBLASLt 优化的是大 M 的 prefill，decode 瓶颈在专家路由与显存带宽。

四、两个值得注意的现象

1. Decode 在 32K 处有断崖，是因为 MTP 草稿窗口默认只有 32K

16K 时 83.6 tok/s，32K 掉到 48.8，接受率从 93% 崩到 58%。原因是草稿层默认只看最后 32,768 个 cell，超出后"看不见"开头，草拟质量下降。

加 --mtp-window 65536 复测：

显存代价几乎为零（MTP 层 +13 MiB，专家缓存 −10 槽位）。

2. 上下文翻倍会吃掉专家缓存

从 128K 改到 256K，KV 从 1.55 → 3.10 GiB，这部分直接从专家缓存扣：10,198 → 9,026 槽位（−11.5%）。后果是短 prompt 变慢（1K 档 prefill −25%），因为少掉的专家得让 CPU 算。

五、总结

一张 24GB 消费卡 + 64GB DDR3，跑 125B MoE：短上下文 83 tok/s、256K 长上下文仍有 47–64 tok/s，读 prompt 峰值 1,602 tok/s。

两个最值得动手的优化：

• --mtp-window 65536：长上下文 decode 白赚 7–32%，显存几乎零成本
• hipBLASLt 调优：prefill +58.7%，且必须用 VERBOSE=1 复查覆盖率，否则会漏掉一半以上的回退

实测环境：Ubuntu 24.04.4 / RX 7900 XTX 24GB / Xeon E5-2678 v3 / 64GB DDR3 / ROCm 10.0 / Strata 0.1.27 (HIP)

参考：Strata（MIT，github.com/Niko1221/Strata）· Qwen/Qwen3.8-Flash-Next · ISTA-DASLab GSQ-RCO GGUF