0
0

GLM-5 3-Flash 精度异常复盘：从 GPQA 反馈到分层定位

2026-10-17
工程实践与复盘

整理日期：2026-09-14（晚间增量）。依据当天新增问题、可见对话摘录与一手资料整理，不是完整逐字稿。教学推导与用户反馈分别注明，未执行服务器操作。

已知进展与缺失信息

依据你晚间的反馈：单机混部可以部署推理，但 GPQA 结果约 62～65，你判断明显低于预期。这是用户报告的实验现象，不是本次复测结果。

目前没有完整测试日志、单位、子集、参考分数、镜像 commit、权重 revision 和提示模板。因此暂不把 62～65 强行写成某个标准榜单准确率，也不补造“正常值”。

三道独立验收

服务能启动、可以返回文本、达到预期模型质量，是三道不同验收。部署文档提供一个可运行配置，不自动证明用户环境与文档一致。

按最小变量定位

先固定权重、tokenizer、聊天模板、数据集子集、答案提取器、输出预算及采样方式。核对是否截断、超时、错误返回或解析失败，被计入错误答案。

随后在可行条件下逐项比较：参考实现与当前后端、已有量化格式与对照格式、KV dtype、eager 与图模式、投机解码开关、单请求与批量。每次只改变一个主要变量，保存逐题差异。

若完整高精度模型放不下，可先用少量样例、中间张量或子模块对照，不应把“无法跑全精度整模”理解为完全无法排错。

优先纠正的假设

W8A8 不决定 C8；INT8 scale 和 FP8/MXFP 的数值表达也不同。混合 Attention 中可能有多类缓存状态。先读模型量化说明和加载日志，再归因。

投机解码、图模式和后端内核是待验证变量，不能未经对照就认定其中一个是根因。

可用于进展汇报的表述

“当前已完成单机混部推理跑通；GPQA 测试结果约 62～65，与预期存在差距，精度验收尚未通过。正在核对评测口径、模型/量化配置与执行路径，并通过控制变量定位。根因与修复时间尚未确认。”

这段只保留现有事实，不补入未看到的后续工作进度。

参考：GLM-5.3-Flash 官方部署配置、W8A8C8 与 GPQA：把量化位宽、数值误差和模型能力分开看。

2026-09-16 补录：9 月 15 日的量化代码排障追问

来源：9 月 15 日 14:30 的可见提问摘录。你提到 ModelSlim 的 glm53_flash_quant 分支早于合并时间存在，并追问如果量化代码有问题如何定位，以及是否可能超过一两天。当前没有具体 PR 编号、commit diff、权重生成记录和完整异常日志，因此不能认定该提交有缺陷，也不能确认现有权重是否使用了它。

先建立产物来源，而非根据合并日期归因

分支提交时间、合并时间、发布版本时间和权重生成时间是不同事实。旧分支可以被提前用于量化，合并也可能经过 squash 或 rebase；“较早存在”不能证明当前产物包含某项修复。应记录量化时实际 checkout 的 commit、未提交修改、recipe、原模型 revision、校准数据和产物哈希。ModelSlim 项目入口

沿五个边界查第一次偏离

  1. 导出产物：比较 tensor 名称、shape、dtype、scale/zero-point、分组维度、转置和 packing 约定。格式不匹配可能发生在生产者与消费者之间，不等同于算法本身错误。
  2. 量化参考计算：使用同一输入，对比浮点层输出与量化再反量化后的参考输出，量化误差本来就允许存在，需按层和格式评估。
  3. 后端实现：比较真实量化 kernel 与采用相同量化参数的参考计算。若此处首先明显偏离，重点查 scale 广播、累加精度、布局和内核。
  4. 整模型行为：固定 token IDs，比较逐层输出及下一 token logits。为避免生成路径分叉掩盖原因，可采用相同已知前缀做逐步对照。MoE 路由也可能被数值差异影响。
  5. 评测链路：固定聊天模板、reasoning_effort（若模型和服务支持）、生成预算、数据集、答案提取与重试策略，保留逐题响应。

这是一套建议排查流程，不是已执行实验，也没有确认故障层级。

回归与工期

在最小复现稳定后，才能用已知好/坏 commit 二分；测试必须覆盖重新生成量化产物，否则只切换推理代码可能错过问题。修复后依次验证产物、单层、固定前缀 logits、小样本任务和完整评测。

没有最小复现和依赖链时，无法承诺一两天解决。多个 Agent 可并行阅读源码、审查格式和设计对照，但共享不可靠基线会放大噪声；更多 Agent 不自动消除硬件实验、校准和评测耗时。

相关学习笔记：量化学习路线与可复现性。

2026-09-16 深化：Eco-Tech W8A8 与最新 msModelSlim 的 B/C 对照

vLLM-Ascend 当前 GLM-5.3-Flash 教程在 A3/A2 上明确使用 Eco-Tech/GLM-5.3-Flash-w8a8，同时也注明可以直接使用 msModelSlim 对模型进行量化。因此，在 910C/A3 环境里，最有诊断价值的对照不是强行让官方原始 FP8 checkpoint 直接 serving，而是保持相同 runtime，比较两份 W8A8 产物：vLLM-Ascend GLM-5.3-Flash 教程

B = Eco-Tech 发布的 GLM-5.3-Flash-w8a8
C = 官方原始 checkpoint → 当前最新 msModelSlim → 自行重新量化 W8A8

固定相同硬件、vLLM-Ascend/CANN、prompt、sampling、GPQA doc_id 与 extractor，只改变 W8A8 产物来源。

  • B 异常、C 正常：优先怀疑 Eco-Tech checkpoint 的生成流程、版本或产物。
  • B 与 C 都异常：不能继续把问题归咎于“旧权重”，应转查当前量化算法、ModelSlim adapter 或 vLLM-Ascend W8A8 runtime。
  • B 与 C 都正常：原先异常更可能来自评测参数、服务配置或其他运行时变量。
  • C 异常而 B 正常：优先排查当前重新量化环境、recipe 和版本差异。

这个 B/C 实验的信息增益高于一开始跑完整 198 题。建议先固定原来 32 个 Diamond 样本进行快速定性。

不要用 master 合并日期推断权重生成版本

本次进一步核对发现，glm53_flash_quant feature branch 在 merge 到 master 之前已经存在，因此“Eco-Tech 权重发布时间早于 master 合入”并不能证明权重使用了旧实现。

当前 msModelSlim master 的 GLM-5.3-Flash W8A8 适配记录显示，merge request !912 最终包含至少两个关键提交：

  • 771bcdd8102d5172a3a222ca8c7e570667c9851c：新增 GLM-5.3-Flash（glm_5_next）适配、量化配置、文档与 UT；
  • 6434cad668fa2c512c3b91589e01b93277a09291：补充 KDA 门控投影与 kpool compress_gate 的平滑/fold/旋转 targets，并修复相关 gate 包装与校验问题。

upstream 的修改说明明确写到，适配过程中发现 KDA/DSA 层门控投影未参与正确的平滑补偿与 γ-fold 会造成导出后门控分数错误；index_kpool_compress_gate 还是一个需要特殊处理的裸 nn.Parameter。msModelSlim GLM-5.3-Flash 适配记录

因此目前只能建立两个竞争假设：

H1：Eco-Tech 权重使用较早 feature-branch 代码，未包含后续修复。
H2：Eco-Tech 已经使用较新的代码，但当前最新量化方案本身仍有未暴露的精度问题。

公开的 merge 时间不足以区分 H1/H2。真正需要的是 artifact provenance：量化时 checkout 的 commit、recipe/YAML、原始模型 revision、calibration 数据、依赖版本和产物 hash。

如何反推出 Eco-Tech 更接近哪个代码版本

如果发布页没有保存 commit provenance，可以使用“权重指纹”思路。因为后续修复并非纯文档改动，而是会改变部分 gate/fold/rotation 的导出数值。

最强的实验是构造：

C0 = checkout 初始适配提交后重新量化
C1 = checkout 后置 fix 后重新量化
B  = Eco-Tech 现有权重

优先比较受修复影响的 tensor/scale，例如 indexer.index_kpool_compress_gate 以及 KDA 中 b_proj、forget_gate.f_a_proj、g_a_proj。如果 B 与 C0 的关键产物显著更接近，而与 C1 不同，可增强“旧流程产物”的证据；反之则削弱该假设。

不要只比较整个 safetensors 文件 hash。序列化、分片和 calibration 的确定性都可能影响 bitwise 一致性；更有价值的是比较指定 tensor 的 shape、dtype、scale、norm、cosine 与数值分布。

最新 upstream 自验能说明什么，不能说明什么

当前适配记录给出 W8A8 多卡量化链路验证，并报告 AIME2026 上的 GPU baseline、A3 vLLM、SGLang、A5 vLLM 结果接近，同时 53 个 UT 覆盖 loader、MTP、KDA/kpool gate 的平滑/fold/rotation targets 等逻辑。msModelSlim GLM-5.3-Flash 自验记录

这能够说明当前实现至少通过了一组功能与精度回归，但不能推出 GPQA 一定正常。AIME 与 GPQA 测试的是不同任务分布；一个量化问题也可能只在特定长推理、科学问答或某些结构路径上暴露。因此“upstream AIME 正常”不是对当前 GPQA 异常的反证。

如果最终确认是量化代码问题：定位路径

不要继续从 GPQA 分数直接猜源码，而应沿数值链找第一次 divergence：

source
→ post-rotation
→ post-smooth/fold
→ fake-quant
→ export/reload
→ vLLM-Ascend runtime

每一步固定相同 token 前缀，比较 logits；发现异常后再做 layer-wise hidden-state diff，继续缩到 module/tensor。对于 GLM-5.3-Flash，优先观测 KDA gate、DSA indexer、MoE router/top-k expert 与 MTP/mHC 特殊路径。

如果本应数学等价的 rotation/smooth/fold 阶段在真正 INT8 量化前就造成明显输出偏差，应优先视为 adapter/变换实现问题，而不是“正常量化损失”。如果内存中的量化模型正常但 export/reload 后异常，转查 saver；如果 reference quant 正常但真实 runtime 异常，转查 loader/layout/kernel。

通用方法已独立整理为：大模型量化精度异常定位：从 Benchmark 掉点到逐层数值二分。

工期与 Agent 使用：1～2 天的合理目标不是“彻底修好”

这类问题跨模型结构、量化算法、权重格式、runtime 与硬件 kernel，彻底修复可能需要数天甚至更久。更现实的短期目标是把问题压缩到：某个阶段、某一层、某个 module，最好形成固定输入下可重复的 numerical divergence。

多个 Agent 适合并行完成 PR/commit 历史、Eco-Tech provenance、KDA/DSA/MoE adapter 阅读、saver/runtime 审查和 diff harness 编写；但核心实验链具有强因果依赖，应由一个主线串行推进。几十个 Agent 同时猜原因会增加噪声，不能替代硬件实验与数值二分。

2026-09-17 增量：为什么 GLM-5.3-Flash 又叫 glm5next

公开官方 config.json 的顶层 model_type 为 glm5_next，文本子配置为 glm5_next_text，视觉子配置为 glm5_next_vision。这些是实现和配置分派标识；GLM-5.3-Flash 是模型发布名称，两者不要求字符串一致。官方配置（核查：2026-09-18）

排障要同时记录仓库/revision、architectures、model_type、子配置和量化元数据。代码类名里出现 Next，不等于装错另一个产品；同样，出现对应类名也不保证当前后端、量化格式和 PD 状态恢复已完整适配。

该配置还使用特定 router 打分及 Top-K 设置，说明 MoE 训练教学中的 softmax 版本不能直接宣称是所有 GLM 路由实现。概念推导与真实配置应分别核对。

2026-09-18 状态更新：正确权重重新量化后精度已恢复

用户当日21:11周报反馈：GPQA-Diamond从初始W8A8的62.1%，在更换正确版本权重并重新量化后恢复到91.1%。这是用户实验反馈，本次未取得完整评测产物、样本配置和权重哈希，不能当作公开独立评测；但工作状态应更新为“精度问题已按用户反馈解决”，前文未定位、仍需排查的文字保留为历史过程。

归因边界：这次恢复支持优先检查权重来源和版本一致性，不证明所有W8A8路径均无问题，也不能把差距归因于INT8本身。今后保存原始权重revision/哈希、量化脚本commit、校准设置、导出文件哈希、runtime版本和评测配置，使来源链可复验。

用户同时反馈两台机器驱动和固件已升级至HDK26.1.1；双机PD及nightly main、TP16单机混部在推进；“单机当前不支持MTP”仅记录为其当时环境状态，不泛化成所有版本限制。PD性能偏差仍待定位，与精度恢复是不同验收项。

当日性能实测与下一步矩阵。