奖励凭证：优秀 +3 分 · 编号 e2885-1233-1

回帖草稿（lcz.me/topic/2885）

标题建议：换 unsloth engram 还有第三条路：不改文件、不前移数据段，一个字节都不用动

楼主这份六次失败的记录很有价值 —— 第 1 条报错跟我这边一模一样，我照着往下试的时候也在同一个地方卡住。不过后来发现还有一条路走通了，原文件一个字节都不用改，贴上来供参考。

报错的真正原因不是"缺 general.architecture"

additional shard must match the architecture-validated first shard's split metadata 之所以出现，是因为 --native 模式下引擎会把 --ple-gguf 追加进 native dense 的分片列表，然后所有分片一起过 split 校验。而这一步在主档的 if (o.native_dense_gguf.empty()) 块里面（src/program/generate.cpp:4370-4382）：

if (o.native_dense_gguf.empty()) {
    o.native_dense_gguf = o.native_shards;
    bool ple_only = false;
    try { ... ple_only = v->s == "strata-ple"; } catch (...) {}
    if (!ple_only && std::find(...) == end())
        o.native_dense_gguf.push_back(o.ple_gguf);   // ← 就是这一步把表卷进 dense
}

--native-dense-gguf 的 help 写得很直白：

--native-dense-gguf PATH   native GDN/QSA/shared projections; repeat for each source model shard

所以只要你自己把 dense 分片列全，上面整块逻辑就跳过了，--ple-gguf 从此只被 PLE 读取器按张量名 per_layer_token_embd.weight 打开，不参与任何分片校验、也不需要任何架构键。

具体做法

在你的配置里加这 6 组参数（分片数按你自己的模型来，几片就写几条 --native-dense-gguf）：

"--ple-gguf", ".../Qwen3.8-Flash-Next-engram-Q8_0.gguf",
"--ple-io",   "direct",
"--native-dense-gguf", ".../Qwen3.8-Flash-Next-UD-IQ4_XS-00001-of-00004.gguf",
"--native-dense-gguf", ".../Qwen3.8-Flash-Next-UD-IQ4_XS-00002-of-00004.gguf",
"--native-dense-gguf", ".../Qwen3.8-Flash-Next-UD-IQ4_XS-00003-of-00004.gguf",
"--native-dense-gguf", ".../Qwen3.8-Flash-Next-UD-IQ4_XS-00004-of-00004.gguf"

你帖子里那三条硬条件（arch = strata-ple / 不带 split.* / 数据段前移到 160）一条都不需要 —— 它们只在"把文件改造成纯 PLE 表"那条路上成立。

启动后日志里应该看到：

PLE direct read probe: 126405 rows/s (fine)
PLE on, table 320001536 rows of .../Qwen3.8-Flash-Next-engram-Q8_0.gguf_file

并且 experts loaded / 槽位数 / prompt chunk / VRAM free 与换表前逐项一致（我这边 4 项全对得上），这就说明接线是等价的。

三个注意点

1. 分片要列全，包括装着 PLE 表那一片（我这边是第 4 片，Swift 那边是第 1 片）。少列一片，模型就缺投影。
2. 模型换版本、分片数变了必须同步改，否则又回到原报错。这是这条路唯一的维护成本。
3. Q8_0 本来就是引擎的一等 PLE 格式，不用 repack：src/kernels/ngram.cpp:191 里 {Q8_0, "Q8_0", "Q8_0", 170, false, dequant_blocks<dequantize_q8_0,34>}，注释原文是「Unsloth's UD-Q6_K_XL and Swift-1.5 Q4_K_L as Q8_0」。所以问题从来不在读表，只在分片校验。

另外，这条路与 --ple-io 三模式是正交的：我实测过 direct（v31 档）和 mmap / direct（Swift 档）。ram 没测，你的 247 GB 内存想锁表应该也能用。

我这边的数据（131K × 3，4080S 32G）

档位：QFN3.8 UD-IQ4_XS-v31，4 分片，自带 engram 是第 4 片的 IQ4_NL 28.80 GB / 90 B 行，换成外置 Q8_0 50.66 GiB。

两个结论：

• 换 Q8 表本身代价 −0.5%（3,216 → 3,200，噪声内），跟你说的"对速度无可测影响"完全一致；
• 真正 +11% 的是 chunk 从 16,384 回到 32,768：表不锁 RAM 了，RAM 守卫才肯放行大 chunk 环。这一项跟换表无关，单独把 --ple-io 改成 direct 就能拿到。如果你现在还是 ram 模式，光这一项就值得切。

另外顺手修正我自己 11-06 的一个误判：之前我判定这个档"比主档慢 19~20%"，其中一大块其实是锁表挤掉 RAM 导致 chunk 腰斩，不是模型慢。改 direct 之后只剩 −11%，差距才回到真实水平（arena 56.24 GiB ⇒ 槽位 9,259 vs 11,371）。

顺带两个坑

① 用官方 benchmark.py 的注意：配置里有 effort_position: "end" 时，请求带 reasoning_effort: "none" 会让服务端在答案前多渲染一个 effort 短末回合（+42 token），而客户端 count() 走朴素模板数不到它，脚本直接 token count mismatch 退出。指纹很明显：warmup 的 prompt_tokens 从 19 变成 61，131K 变 131,114。要么改请求的 effort，要么放宽这条断言（prefill_tok_s 用的是引擎自报的 token 数，放宽不影响结果）。

② 探针读数抖动很大：同一天、同一张盘，Q8 表我见过 90,886 和 126,405 rows/s，IQ4_NL 是 117,913。偶尔 Q8 比 IQ4_NL 还快，所以别拿单次 PLE direct read probe 判断盘快慢（门槛 15,000，本机都在 6 倍以上余量）。

最后，你那个 tooleval 90 → 93 的判断我同意是噪声；Q8 表的真正价值还是把 7.57% 的已知系统性误差压到 0.53%，不是那 3 分。

本机 PLE_flash_Q8_fixed.gguf            @行0              sha 35d2284228d77d00
                                        @行160,000,768    sha cbee976b5c9f8170
                                        @行319,995,367    sha 680ee28fd267373e

unsloth 基座 engram/Q8_0.gguf_file      @三处            同 同 同  ✅（数据起点 192）
ukisai Swift Q8_0 shard2                @三处            同 同 同  ✅（数据起点 192）


三处采样（开头 / 中间 / 结尾各 1 MiB）sha256 全部一致。

这里要澄清一个概念，因为它解释了"为什么必然相同"：

engram/ 里的 PLE 表不属于"量化档"，它属于基座权重。 Swift 1.5 那次重训的目标是"省思考 token"（thinking -63.4%），动的是 attention/专家/输出头这些参与推理路径的权重，PLE 表（per_layer_token_embd.weight，51.2B 个值 n-gram 查表）根本没被碰。所以：

- unsloth UD 各版本（v3.1 的 Q2_0/IQ2_XS/IQ3_XXS/Q3_K_XL/IQ4_XS…）共用同一张 engram/Q8_0
- Swift 1.5 微调版共用同一张
- huihui abliterated、OrcaRouter、SC117 这些第三方改版也一样（1104/1020 的 byte-identical 结论现在彻底确立了）

也就是说：整个 Qwen3.8-Flash-Next 生态里，那 51.2B 的 n-gram 表只有一份，永远只有"用哪个精度档"的问题，没有"用哪个模型的表"的问题。

顺带纠正我自己一条旧记录（1106 留的）：unsloth engram 原文件的数据段起点是 192，不是 2912。我第一次比对用了 2912，结果三块全"不同"——纯错位假象，改成 192 后立刻全同。这个坑已经写进 skill，免得下次又白折腾一轮。数值上也自洽：


原文件  = 192 + 320001536×170 = 54,400,261,312 字节
strata-ple 版 = 160 + 同一数据段 = 54,400,261,280 字节   （只差 32 字节 header 对齐）


所以对你现在的部署，结论没变、还更强了：

1. Q4_K_XL 那档挂的 Q8 表，就是官方（任何来源）唯一的那张 Q8 表 —— 不用换、不用下、不会有"更正确的版本"。
2. 唯一还剩的升级空间就是精度档：Q8_0（0.53% 残余误差）→ BF16（102.4 GB，RMSE 0）。这笔账不划算（/n2 只剩 49 G，锁页要 ~96 GiB 内存），除非哪天你把 /n1 腾出 100 G 并且愿意用 45 分钟等数据前移，收益是抹掉 0.53% —— 官方数据也说不感知。
3. 将来若要下 engram/ 其它档（Q5_1 38.4 G / IQ4_NL 28.8 G），记住都是同一份权重换精度，Strata 侧必须转 strata-ple（改 arch、去 split.*、数据前移到 160），工具和三条硬条件都在 ~/docs/strata-upgrade-1106/。

@J-Z-0 说:

@stxpnet 能请教下，iq4xs + 你的新表，一共占多少vram+ram？ 不知道7900xtx+ 128g能不能塞下

这个表，如果你的NVME速度足够快，可以不放RAM里面的，这个表在STRATA的设计 里面就是放NVME的。 对速度影响也挺小的。 我只是RAM空闲较多才放RAM的，以后我可能也要改回直接放在NVME。

• 这张 per_layer_token_embd 是纯查表，量化误差会以固定偏置进入每层输入；RMSE 7.57% → 0.53% 是实打实的系统性误差源消除，不是随机波动，这点你的判断没问题。
• 但 15 题里 1 题 partial→pass 就是 6.7 个百分点，二项分布的 95% 区间大约 ±20 个百分点，判不了优劣。要证明 Q8_0 更好，至少：同一批 prompt 配对跑（温度 0、固定 seed）、题量 100+、报 pass 率差的 bootstrap 置信区间；再补两类更能暴露表误差的任务——长文精确引用/复制专有名词，以及含大量生僻 token 的检索问答。
• 成本侧：Q8_0 表 54.4G vs 内嵌 IQ4_NL 28.8G，多占约 25.6G 内存/磁盘；速度几乎不受影响（每 token 每层只读一行，带宽可忽略），但 mmap 加载和 page cache 压力会变大，内存紧的机器要算这笔账。
• 主体仍是 IQ4_XS，换表只消掉一个误差源，别把整体精度提升都归给它；建议固定主体，做 IQ4_NL / Q5_1 / Q8_0 三档表的同题对照，再决定长期用哪档。

@stxpnet said:

DEEPSEEK 的判断（诚实版）：

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

可能要高難度的考題 才能測出差距

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