简单讲一下他们的特性，两个引擎都靠"专家放内存、显卡只装稠密权重和最热的专家"把 125B MoE 塞进一张 24 GB 消费卡。这份数据在同一台
机器上、用完全相同的 prompt 原文、让两个引擎各跑自己的最佳配置测出来。

测试平台

（我已经把我的VM拆出来分别给几台电脑，现在这台服务器就只是拿来跑AI而已了，之前的64GB有点勉强够用。）

两套引擎

两个引擎加载的是不同的权重文件（Avalon 的 GGUF 用了它自有的 IQ3_K/IQ3_KS 类型和打包布局，stock llama.cpp
和 Strata 都打不开），所以这份对比是"引擎 + 它对应量化"的对比，不是量化对比。这一点请勿误读。

测试方法

• prompt 使用 Strata 自带的基准脚本（rdna3/bench.py）：N token 的合成仓储记录，开头、中间、结尾各埋一个密码，
  最后要求长回答；用模型自己的 tokenizer 和 chat template 构造，长度精确为 32,768 / 65,536 / 131,072 / 261,632 token。
• 每档跑 3 次，输出固定 256 token，温度 0，种子 42，不开 prompt 缓存，关闭思考模式。
• 每个请求必须报告精确的 prompt token 数（无缓存命中）、256 个输出 token，并且取回三个密码（检索校验，来自
  基准脚本本身，不是我另加的）。
• 速率取引擎自报的 prompt_per_second / predicted_per_second，每格为 3 次的中位数。
• 同一批 12 条 prompt 原文分别喂给两个引擎（Avalon 走 /completion，Strata 走它自带服务），保证文本完全一致。

测试结果

* = prefill 时间 + 生成 256 token 的时间，也就是一个请求从发出到答完的实际耗时。

数据解读

两个引擎优化的是请求的两端。 Strata 的 prefill 快 1.6 倍，而且在 256k 满上下文时仍有 2,714 tok/s —— 因为
这个 RDNA3 分支是围绕"喂 prompt"设计的：K-quant 的 MMQ prefill kernel、STRATA_PREFILL_CPU_SHARE 把一部分
prompt 计算交给 CPU、29 GB 的 n-gram 表常驻内存让新 prompt 不必等 SSD、KV 缓存放内存让整张 24 GB 卡都留给专家。
Avalon 则赢在解码：GPU 专家缓存让一个 token 的大部分专家不必落到 CPU，MTP 草稿头把一个验证窗口变成约 2.5 个 token。

"谁更快"完全取决于 prompt 与回答的比例。 喂一份 256k 文档、只要一段总结（agent、RAG、代码审查）：Strata
端到端快 64 秒，省掉近 40% 时间。短 prompt、长回答的聊天：Avalon 每秒多 10–25% token，而聊天里 token 数才是
主要成本，prefill 只占开头。

满上下文只有一方可靠。 32k / 64k / 128k 两个引擎都把三个密码全部取回（各 3/3）。到 261,632 token 时，
Avalon 全部请求通过；Strata 在两轮独立的基准运行里都是 3 次挂 2 次、只过 1 次。两边的速度在这个长度上
差不多（解码 101.9 vs 111.7），所以如果你要用 Strata 跑 256k，请先用自己的数据验证。

Strata 的"最佳配置"验证：它的 setup 会提示加 --prefill auto:32768（社区报告快 21–35%）。实测：
2,942 / 2,976 / 2,894 / 2,700 tok/s，对比原配置 2,992 / 3,010 / 2,912 / 2,714 —— 没有提升，反而低 0.5–1.7%，
所以下表用的是它出厂的 --prefill auto。

关于宿主差异的校准说明。 Strata 分支的作者是在 9950X3D + DDR5 平台上测的。在这台 DDR4 + Zen 2 的机器上，
Strata 只有他参考值的 0.81–0.84 倍（prefill） 和 0.88–0.93 倍（解码）。表里 Avalon 的数字是同一台机器
测的，所以引擎对比本身没有被这一点污染；但请不要把我的 Strata 数字直接去对他的表。

中文场景实测（出乎意料的一组）

英文是"各有胜负"，中文则是 Strata 明显更好。同一批 5 条 prompt（3 中文 + 2 英文）、300 输出 token、温度 0：

• Avalon，MTP n-max 3 — 中文解码: 60.8 tok/s; 中文草稿接受率: 0.12; 英文解码: 106.0 tok/s; 英文草稿接受率: 0.49
• Avalon，MTP n-max 2 — 中文解码: 67.3; 中文草稿接受率: 0.17; 英文解码: 105.8; 英文草稿接受率: 0.62
• Avalon，关闭 MTP — 中文解码: 71.2; 中文草稿接受率: —; 英文解码: 72.7; 英文草稿接受率: —
• Strata（出厂配置，自带 draft_vocab_zh60k.bin） — 中文解码: 96.0; 中文草稿接受率: 0.47–0.59; 英文解码: 103.6; 英文草稿接受率: 0.61–0.64

四个要点：

1. Strata 的中文比 Avalon 最好的配置还快 35%（96.0 vs 71.2），比 Avalon 默认配置快 58%（96.0 vs 60.8）。
2. 原因是草稿词表。Avalon 的 MTP 头是按英文词频裁剪的 65k 词表，中文草稿大量落在表外，接受率只有 0.11–0.17，
   验证开销变成净损失；Strata 这个分支专门做了一个面向中文的 draft 词表（draft_vocab_zh60k.bin，含覆盖其自身
   中文回答 99.5% 的汉字 token），中文接受率 0.47–0.59，基本维持在英文水平。
3. 语言惩罚对比：Strata 的中文只比它的英文慢 7%（96.0 / 103.6）；Avalon 开着 MTP 时中文只有英文的 57%。
4. Avalon 没有可调的中文选项。 它的 draft 词表是烘进 MTP 那个 GGUF 的（draft_vocab / draft_vocab_size
   为模型内嵌字段，文件名里的 FR65k 就是 65k 裁剪），llama-server 没有 --spec-draft-vocab 一类参数，
   所以中文接受率低是固化的，只有"关掉 MTP"能绕开，代价是英文从 106 掉到 73。上面三档在 2026-11-09
   复测过一次，两轮差异在 3% 以内（中文 60.7 / 65.3 / 73.1，接受率 0.12 / 0.14），不是偶发波动。

所以如果你的主要用的是中文，直接选 Strata，而且它同时还赢着 1.6 倍的 prefill。

建议

一句话结论：Strata 的 prefill 快 1.6 倍，Avalon 的解码快 1.2 倍，而 256k 满上下文只有 Avalon 稳定取回了检索码。综合表现还是Strata占据上风

复现

Avalon

git clone https://github.com/freriadoc/Avalon && cd Avalon
cmake -B build -DGGML_HIP=ON -DAMDGPU_TARGETS=gfx1100 -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_C_COMPILER=/opt/rocm/bin/amdclang -DCMAKE_CXX_COMPILER=/opt/rocm/bin/amdclang++
cmake --build build -j24 --target llama-server

llama-server -m Qwen3.8-Flash-Next-Avalon-IQ3KS-00001-of-00033.gguf \
  -c 262144 -b 9536 -ub 9536 -fa on -ctk q8_0 -ctv q4_0 --jinja --parallel 1 \
  -md MTP/mtp-Qwen3.8-Flash-Next-shared-IQ3K-IQ4NL-FR65k.gguf \
  --spec-type draft-mtp --spec-draft-n-max 3 -ubd 256 -ctkd q8_0 -ctvd q8_0

（中文场景把 -md ... --spec-type ... -ubd ... -ctkd ... -ctvd ... 整段去掉即可，实测更快。）

Strata（RDNA3 fork）

git clone https://github.com/nicejunjie/Strata-rdna3 && cd Strata-rdna3
export XDG_CONFIG_HOME=$PWD/.config
./setup.sh --setup --build --backend hip --family qwen --model IQ3_S --vision cpu \
           --data-dir /path/to/Strata-data --no-start --yes
export STRATA_GGUF_PY=$PWD/third_party/llama.cpp/gguf-py
.venv/bin/python tools/iq_pack.py --gguf <data>/models/IQ3_S/...-00001-of-00002.gguf \
    --out <data>/packs/iq3_s --experts-bin      # 46.84 GiB，bench.py 必需
.venv/bin/python rdna3/bench.py iq3-1gpu --data <data> --gpus 0 \
    --lengths 32768,65536,131072,261632

几点说明

• 单卡、单机、每个引擎一种量化；每格 3 次取中位，这台机器单次运行本身有 ±10% 波动。
• 单卡就别想多并发了，就乖乖排队吧。
• 视觉通路未测。
• 内存与显存数字是运行期间实际观测值（RSS / VRAM），不是申请值。

各位也可以测试一下，如果有什么问题，也欢迎各位指点。毕竟我只是叫AI帮我测，我也不是专业评测和调试的。