来源：GitHub (★104)
URL: https://github.com/RobTand/prismaquant
精读日期：2026-09-14
模型：DeepSeek V4 Flash（AI 生成，人工未审校）
正文获取：全文

一、核心论点/事实

  • PrismaQuant 是一个面向 LLM 的混合精度量化工具，核心主张是"每个权重矩阵按其敏感度折射成不同格式"，而非统一精度。
  • 在 Qwen3.6-35B-A3B 4.75 bpp 上，对比 RedHatAI 的统一 NVFP4（含 342 个手工挑选的 BF16 忽略层），PrismaQuant 的分配方案体积小 2 GB、BF16 层数少约 90 个，平均 zero-shot delta 为 −0.56 pp，而统一 NVFP4 为 −2.21 pp，接近 BF16 的程度约高 4 倍。
  • Qwen3.6-27B PrismaAURA 5.5 bpp 的 served KL-vs-BF16 为 0.0342，相比同 bpp 的上一版 AURA 降低 40.9%，来源是加入 FP8 中间档位及渲染/导出保真度修复。
  • Ornith-1.0-35B-A3B PrismaAURA 4.75 bpp 将 70 GB 压到 23 GB，KL 0.0143，top-1 一致率 98.6%，嫁接的 MTP 头在 position 0 的投机解码接受率为 91.3%。
  • Tencent Hy3 295B-A21B 被量化到 103.7 GB GGUF（2.80 bpp），可在单台 DGX Spark 上服务；该规模无法在目标硬件上与 BF16 教师做 KL 验证，只能做加载+连贯生成冒烟测试和位精确打包校验。
  • 作者声称跨层交互建模（CLADO 的成对 IQP、HAWQ-V3 的二阶 ILP 等）在同一 A/B 上收益约 0，真正的杠杆是逐 Linear 的成本保真度。
  • 默认 COST_MODE=aura 自 2026-07-30 起生效，可用 COST_MODE=production-render-score 复现翻转前的产物。

二、方法/架构拆解

  • 整体流水线：probe → cost → allocator → export → serve-smoke，每阶段可独立运行；分配器接受与导出相同的格式菜单，重新求解无需重新测量。
  • 成本模型：逐 Linear 的 KL-Fisher 探针（全模型端到端 KL 目标的伴随，而非层局部代理）乘以实际出货字节的权重误差，求解为多选背包问题，发布前在留出集上用真实 KL 把关。
  • 三种输出容器：compressed-tensors（NVFP4/FP8/BF16 逐 Linear，Blackwell 上用 CUTLASS 内核）、GGUF（k-quant + IQ 全菜单，逐张量混合，imatrix 加权）、Tessera（仅用原生内核，未 fork 的 vLLM，按 pin 文件锁定 commit，不满足设备资格则 fail-closed）。
  • 生产保真度作为不变量：分配器测量的成本、验证器测量的 KL、导出器出货的字节来自同一渲染；GGUF 通道上校准加权与打包加权位精确一致（对照 gguf-py 参考解码器）。
  • 加性代理仅作候选生成器，出货点由留出集上的真实 KL 前沿决定；在 27B 上代理自身的拐点选 5.86 bpp/KL 0.056，而验证选择选 5.31 bpp/KL 0.015，后者更小且好 3.7 倍。
  • 路由专家单独处理：平滑的逐 Linear 成本对 router flip 结构性失明，因此非专家权重用平滑成本分配，打包的路由专家按端到端打分的专家层级选择，合并进同一背包。
  • 大模型（200B+ MoE）走流式逐层路径，峰值内存约 1 层加可调缓存；Hy3 295B 即用此路径，字节预算直接对准目标机器而非曲线启发式。
  • 验证口径：仅认 served 端点的真实 KL-vs-BF16 或确定性基准，不认本地屏幕结果。

三、值得注意的局限/争议

  • 作者承认：Hy3 295B 规模无法在目标硬件上与 BF16 教师做 KL 验证，只能做加载与连贯生成冒烟测试及位精确打包（这是规模带来的硬约束，非方法缺陷）。
  • 作者承认：加性代理存在信任域，域外 bpp 顺序不等于 KL 顺序（27B 上代理拐点与验证选择差 3.7 倍），因此代理不能作为出货决策。
  • 作者承认：平滑逐 Linear 成本对 router flip 结构性失明，必须对路由专家单独端到端打分。
  • 作者主动记录负面结果：跨层交互建模收益约 0，成对 QUBO、Lagrangian λ 二分选择器、top-K Hessian 覆盖、在真实 KL 门下退化的 polish DP 均被否决。
  • AI 判断：核心对比（vs RedHatAI 统一 NVFP4）中，对手含 342 个手工 BF16 忽略层，属于人工调优基线，对比公平性取决于该基线是否代表统一精量的最佳实践。
  • AI 判断：Tessera 通道要求安装的 commit 与 pin 完全一致且设备资格通过，否则 fail-closed，这提高了可复现性但也限制了部署灵活性。
  • AI 判断：多数关键数字（KL、接受率、zero-shot delta）来自项目自述与自建基准（ToolEvalBench），缺少第三方独立复现。

四、与 RRLab 研究的关联

  • Harness 工程：probe → cost → allocator → export → serve-smoke 的分阶段可独立运行设计，以及"fail-fast 门禁 + 明确告知原因与所需设置"的契约式流水线，可直接借鉴为 RRLab 评测/导出 harness 的组织范式。
  • 模型评测：其"只认 served 端点真实 KL 或确定性基准、不认本地屏幕"的验证口径，以及留出集与成本阶段数据不相交的纪律，对 RRLab 的评测可信度设计有直接参考价值。
  • 多模型协同：逐 Linear 混合格式 + 路由专家单独端到端打分的思路，可类比到多模型/多专家路由场景中"平滑成本对路由翻转失明"的问题。
  • Agent 落地：Qwen3.6-27B PrismaAURA 5.5 bpp 声称工具使用保真度高于全精度，说明量化配方可按 agent 工具调用场景定向优化，对 RRLab 的 agent 部署选型有参考意义。
  • AI 原生产品：295B MoE 压到 103.7 GB 单机可服务、35B 从 70 GB 到 23 GB，这类"单机可服务大 MoE"的量化产物直接影响 RRLab 的本地部署与成本模型。
  • 可借鉴点：负面结果目录（跨层交互建模收益约 0）提示 RRLab 在量化/压缩方向应优先投入逐单元成本保真度而非层间耦合建模。

本笔记由 DeepSeek V4 Flash 自动生成，未经人工审校。原文链接：https://github.com/RobTand/prismaquant