前两天unsloth 的qfn3.8模型进行了一些升级，现在是ud3.1格式，号称有一定的智力提升。 我这套配置和使用场景比较适合使用IQ4_XS,所以下载来跑了一下，后来又看到模型卡的ngram文件夹有Q8_0的分片，于是想着把当前IQ4_XS的NGRAM表换成Q8_0的试试。

以下是DEEPSEEK V4.1 FLASH 1017折腾了1小时的结果：

主线：engram / PLE 表是什么，四档精度怎么选

Qwen3.8-Flash-Next 有一个巨大的 per-layer n-gram 表（张量名 per_layer_token_embd.weight，160 × 320,001,536 = 51.2B 个值）。它单独占一个 shard，因此可以脱离模型主体单独换精度。

unsloth 在 2026-11-04 把它单独发布成「可混搭」的 engram 文件（unsloth/Qwen3.8-Flash-Next-GGUF/engram/），官方 README 给的数据：

关键对比：我们原来用的是内嵌 IQ4_NL（7.57%），换 Q8_0（0.53%）相当于表精度提升 14 倍，代价只是 RAM 多占 23 GB（51 GB vs 28 GB，本机 247 GB 内存完全吃得下）。

插一句：下载走 ModelScope 比 HF 快得多。aria2c -x8 -s8 -k8M 拉了 50.7 GiB，平均 65 MiB/s，10 分钟。HF 直连/镜像都不稳定。

3. 六次失败，每次都卡在不同的地方（这是全文最有价值的部分）

尝试	做法	引擎报错	真正原因
1	直接用 unsloth 原文件做 --ple-gguf	additional shard must match the architecture-validated first shard's split metadata	缺 general.architecture，被当成模型附加分片
2	补 general.architecture = qwen4exp	missing qwen4exp.block_count	架构名对了，但引擎还要 6 个几何键
3	补全模型全部 50 个 general.*/qwen4exp.* 键	duplicate split shard number	文件还带着 split.no，与模型分片撞号
4	把 split.no 改成 0	同上 duplicate	撞的是模型第一片
5	把 split.no 改成 3	同上 duplicate	撞的是模型第四片（=死结）
6	去掉所有 split.* 键 + arch 改 strata-ple	PLE table size mismatch: ... from data_start 160	数据段还在旧 header 之后（2912），偏移不对
	数据段前移到 160	PLE on, table 320001536 rows of .../PLE_flash_Q8_fixed.gguf	成功

3.1 三条硬条件（源码依据）

源码就这十几行（src/program/generate.cpp:4374-4381）：

o.native_dense_gguf = o.native_shards;
bool ple_only = false;
try {
    strata::GgufFile pg(o.ple_gguf);
    if (const strata::MetaValue* v = pg.get("general.architecture"))
        ple_only = v->s == "strata-ple";          // ← 决定性的一行
} catch (...) {}
if (!ple_only && std::find(...) == end())
    o.native_dense_gguf.push_back(o.ple_gguf);    // 不是 strata-ple → 被当 dense 分片 → 撞 split 检查

duplicate 检查则在分支之外：

if (number && !split_numbers.insert(number->u).second) {
    err = "native dense: duplicate split shard number"; return false;
}

模型 4 个分片已占 no=0..3，所以 PLE 表只要带 split.no，无论填 0/1/2/3 都会撞 —— 这就是第 4、5 次失败的原因，唯一出路是完全不写这个键。

3.2 官方也是这个格式

官方工具 tools/ple_fp8_pack.py 产出的就是 strata-ple：

The output is a one-tensor GGUF: per_layer_token_embd.weight, ne = [160, 320001536], type I8 ... with strata.ple.format = "f8_e4m3" and strata.ple.scale (F32).

代码注释也直接写着：a PLE-only table (tools/ple_fp8_pack.py: architecture strata-ple) holds no projections。

3.3 社区三个 request 都还没合入

结论：在 0.1.57 上，想换表只能自己把文件转成 strata-ple 格式，别指望改 set_split.py（那是 llama.cpp 的路子，只改 shard 槽位）。

3.4 造文件的三个脚本（本机验证过）

最终文件形态：

文件大小：54,400,261,280 = 160 + 320,001,536 × 170
字典：{general.architecture: "strata-ple"}
张量：per_layer_token_embd.weight [160, 320001536] Q8_0 offset=0
尾部 64 MiB sha256 与原 engram 文件一致（数据一个字节没动）

一、这个表不是「冷专家」，是 n-gram 上下文查表

源码：include/strata/kernels/ngram.hpp:5
  "ngram_rows — the HOST hash. Sixteen row indices per token from the last three token ids"

拆开说：

所以它既不是「冷专家」，也不是「常用词表」——它是模型训练时学出来的 trigram → 2560 维嵌入映射，作用是给每个 token 补一个「结合前两个词的上下文先验」，然后逐层参与计算。这也是为什么它能有 51.2B 个值却几乎不占算力：纯查表。

二、生成 100 万 token 要读多少次表

对比生成 100 万 token 本身要花的时间（134 t/s ≈ 2 小时），这点读取是百万分之五量级，纯噪声。所以在 --ple-io ram 下，换 Q8 表对速度没有可测影响 —— 与实测吻合（换表前后都是 134 t/s）。

三、对生成质量到底有没有影响

先给理论量级：

表级相对误差：IQ4_NL 7.57% → Q8_0 0.53%
每个 token 受影响的是那个 2560 维向量（16 行 × 160 值全部参与）
7.57% 的向量误差不算小，但模型每层有归一化/投影会吸收一部分

再给实测（刚跑的，同一套题、temp=0）：

DEEPSEEK 的判断（诚实版）：

1. 没有可测的退化，还略高 3 分 —— 但 15 题里就差 1 道题从 partial 变 pass，这属于统计噪声，不能宣称「Q8 更好」。
2. 真正的价值是消除一个已知的系统性误差源：7.57% 的表误差在长文、需要精确措辞或推理链的任务上可能放大，而 0.53% 基本无损。

fix_ple_header2.py ple_move_data.py ple_to_strata.py

原版编程非常久。 32分钟还没写完，中途截图。

前两天unsloth 的qfn3.8模型进行了一些升级，现在是ud3.1格式，号称有一定的智力提升。 我这套配置和使用场景比较适合使用IQ4_XS,所以下载来跑了一下，后来又看到模型卡的ngram文件夹有Q8_0的分片，于是想着把当前IQ4_XS的NGRAM表换成Q8_0的试试。

以下是DEEPSEEK V4.1 FLASH 1017折腾了1小时的结果：

主线：engram / PLE 表是什么，四档精度怎么选

Qwen3.8-Flash-Next 有一个巨大的 per-layer n-gram 表（张量名 per_layer_token_embd.weight，160 × 320,001,536 = 51.2B 个值）。它单独占一个 shard，因此可以脱离模型主体单独换精度。

unsloth 在 2026-11-04 把它单独发布成「可混搭」的 engram 文件（unsloth/Qwen3.8-Flash-Next-GGUF/engram/），官方 README 给的数据：

关键对比：我们原来用的是内嵌 IQ4_NL（7.57%），换 Q8_0（0.53%）相当于表精度提升 14 倍，代价只是 RAM 多占 23 GB（51 GB vs 28 GB，本机 247 GB 内存完全吃得下）。

插一句：下载走 ModelScope 比 HF 快得多。aria2c -x8 -s8 -k8M 拉了 50.7 GiB，平均 65 MiB/s，10 分钟。HF 直连/镜像都不稳定。

3. 六次失败，每次都卡在不同的地方（这是全文最有价值的部分）

尝试	做法	引擎报错	真正原因
1	直接用 unsloth 原文件做 --ple-gguf	additional shard must match the architecture-validated first shard's split metadata	缺 general.architecture，被当成模型附加分片
2	补 general.architecture = qwen4exp	missing qwen4exp.block_count	架构名对了，但引擎还要 6 个几何键
3	补全模型全部 50 个 general.*/qwen4exp.* 键	duplicate split shard number	文件还带着 split.no，与模型分片撞号
4	把 split.no 改成 0	同上 duplicate	撞的是模型第一片
5	把 split.no 改成 3	同上 duplicate	撞的是模型第四片（=死结）
6	去掉所有 split.* 键 + arch 改 strata-ple	PLE table size mismatch: ... from data_start 160	数据段还在旧 header 之后（2912），偏移不对
	数据段前移到 160	PLE on, table 320001536 rows of .../PLE_flash_Q8_fixed.gguf	成功

3.1 三条硬条件（源码依据）

源码就这十几行（src/program/generate.cpp:4374-4381）：

o.native_dense_gguf = o.native_shards;
bool ple_only = false;
try {
    strata::GgufFile pg(o.ple_gguf);
    if (const strata::MetaValue* v = pg.get("general.architecture"))
        ple_only = v->s == "strata-ple";          // ← 决定性的一行
} catch (...) {}
if (!ple_only && std::find(...) == end())
    o.native_dense_gguf.push_back(o.ple_gguf);    // 不是 strata-ple → 被当 dense 分片 → 撞 split 检查

duplicate 检查则在分支之外：

if (number && !split_numbers.insert(number->u).second) {
    err = "native dense: duplicate split shard number"; return false;
}

模型 4 个分片已占 no=0..3，所以 PLE 表只要带 split.no，无论填 0/1/2/3 都会撞 —— 这就是第 4、5 次失败的原因，唯一出路是完全不写这个键。

3.2 官方也是这个格式

官方工具 tools/ple_fp8_pack.py 产出的就是 strata-ple：

The output is a one-tensor GGUF: per_layer_token_embd.weight, ne = [160, 320001536], type I8 ... with strata.ple.format = "f8_e4m3" and strata.ple.scale (F32).

代码注释也直接写着：a PLE-only table (tools/ple_fp8_pack.py: architecture strata-ple) holds no projections。

3.3 社区三个 request 都还没合入

结论：在 0.1.57 上，想换表只能自己把文件转成 strata-ple 格式，别指望改 set_split.py（那是 llama.cpp 的路子，只改 shard 槽位）。

3.4 造文件的三个脚本（本机验证过）

最终文件形态：

文件大小：54,400,261,280 = 160 + 320,001,536 × 170
字典：{general.architecture: "strata-ple"}
张量：per_layer_token_embd.weight [160, 320001536] Q8_0 offset=0
尾部 64 MiB sha256 与原 engram 文件一致（数据一个字节没动）

一、这个表不是「冷专家」，是 n-gram 上下文查表

源码：include/strata/kernels/ngram.hpp:5
  "ngram_rows — the HOST hash. Sixteen row indices per token from the last three token ids"

拆开说：

所以它既不是「冷专家」，也不是「常用词表」——它是模型训练时学出来的 trigram → 2560 维嵌入映射，作用是给每个 token 补一个「结合前两个词的上下文先验」，然后逐层参与计算。这也是为什么它能有 51.2B 个值却几乎不占算力：纯查表。

二、生成 100 万 token 要读多少次表

对比生成 100 万 token 本身要花的时间（134 t/s ≈ 2 小时），这点读取是百万分之五量级，纯噪声。所以在 --ple-io ram 下，换 Q8 表对速度没有可测影响 —— 与实测吻合（换表前后都是 134 t/s）。

三、对生成质量到底有没有影响

先给理论量级：

表级相对误差：IQ4_NL 7.57% → Q8_0 0.53%
每个 token 受影响的是那个 2560 维向量（16 行 × 160 值全部参与）
7.57% 的向量误差不算小，但模型每层有归一化/投影会吸收一部分

再给实测（刚跑的，同一套题、temp=0）：

DEEPSEEK 的判断（诚实版）：

1. 没有可测的退化，还略高 3 分 —— 但 15 题里就差 1 道题从 partial 变 pass，这属于统计噪声，不能宣称「Q8 更好」。
2. 真正的价值是消除一个已知的系统性误差源：7.57% 的表误差在长文、需要精确措辞或推理链的任务上可能放大，而 0.53% 基本无损。

fix_ple_header2.py ple_move_data.py ple_to_strata.py