系列目录 · 数值与量化 · Read in English
“上周还在补专用算子，这周怎么又删了？”在代码评审里，这句话容易带出一丝尴尬。可真正值得追问的不是“谁走了弯路”，而是：“我们发现哪条抽象边界放错了？”
编译器设计经常如此。第一次实现让问题出现，第二次实现才知道应该把问题放在哪层。
一、专用仿射算子最初有什么吸引力
逐通道仿射变换 y=a*x+b有明确的业务语义。保留一个专用节点，可以把参数广播、乘加顺序、工作区需求和可融合属性集中表达。
底层若有适合的执行方式，专用内核还能按通道或按行复用参数，控制循环和步长，避免提前把参数展开成整张特征图。高层分析也容易识别“这是一段仿射变换”，继续考虑与前后算子融合。
历史较早的实现确实补了专用配置、指令组合、代码生成注册和工作内存接口。其中一个草案使用旁路或占位式数值参数，另一个相关版本补充了实际量化乘加参数与更多布局处理。它们是不同历史快照，不能因为日期接近，就假定前者的所有限制自动沿直线修复到后者。
专用节点的代价，是需要为它单独回答全套工程问题：布局、分块、广播、量化、资源申报、错误诊断、注册和测试。若其中一项长期缺位，算子语义再漂亮，也可能在真实链路中成为特殊分支最多的地方。
二、拆成通用乘加，复用了什么？
把仿射降低为乘法和加法，可以利用已有的二元算子处理：形状合法化、广播、布局转换、调度、内存分配和发射路径。历史差异先出现了这种替换，随后删除了专用操作定义、内核、代码生成与资源实现，并清理布局规则中的特判。
这是一种实质性的维护面收缩。少一个需要长期同时跟进的算子，也减少了公共逻辑升级时漏掉专用路径的风险。
然而“通用”不天然意味着语义更完整。若仿射节点携带激活融合属性，拆分时必须实现等价激活或明确拒绝。历史后续 lowering直接检查并拒绝它不支持的融合条件，这是比悄悄丢属性更可靠的选择。
同理，专用节点可能承诺一次舍入；拆成两个量化节点可能多一个舍入点。参数原本紧凑存储，改为通用算子时可能需要完整展开。抽象简化省下的代码，并不自动等于省下运行成本。
三、做一个“语义资产清单”
在删除一个专用操作前，可以列出它携带的所有信息，并为每一项指定去处：
| 原语义或能力 | 拆分后的归属 | 必须检查 |
|---|---|---|
| 逐通道系数 | 常量类型与广播规则 | 轴与布局是否明确 |
| 乘加数值顺序 | 两个节点及中间类型 | 舍入、饱和是否变化 |
| 激活融合 | 独立激活或显式拒绝 | 属性不能无声丢失 |
| 临时工作区 | 通用内存规划 | 原 workspace是否仍残留 |
| 操作来源 | 派生位置与诊断关系 | 出错时能否回溯原模型 |
| 特殊快捷路径 | canonicalize或 lowering | 类型转换必须保留 |
这份清单比“搜索专用类名，全部删掉”更接近正确迁移。删除引用只能证明编译器可能还编得过；语义资产有归宿，才能说明原功能没有悄悄蒸发。
四、从一个 IR 节点拆成两个，错误定位反而可能更清楚
专用内核内部如果同时做乘法、加法和广播，数值错了只看到一个节点。拆成通用操作后，可以在 IR上区分是常量量化不对、乘法输出范围不对，还是偏置广播不对。
历史变化中还调整了派生位置命名，让乘法和加法具有可区分的来源。公开文章不需要保留内部命名方式，但通用原则值得保留：合成节点需要可追踪来源；多个节点不能都只有一个模糊的“生成于某处”。
当然，诊断清晰不要求最终程序永远保持拆分。编译器可以在语义可见的阶段使用通用节点，在目标相关阶段重新融合。理想的分层是先让优化和验证看见语义，再在有证据的条件下压缩执行形式。
五、文档删除为什么也值得记录，却不该冒充功能修复
关联历史中有一条标题看起来像更新归一化，实际差异只是删除一份临时审查文档。它没有改运行时代码，也没有新增测试。若仅凭标题写博客，就可能凭空讲出一次不存在的数值修复。
被删除的文档本身记录过局限、待验证项和设计建议，但这些内容不能当成执行结果。某份文档说“建议测试布局”，不等于布局测试已经通过；文档被删除，也不等于它列出的所有问题都已关闭。
一种更可靠的写作与工程归档方式是区分三类证据：代码实现、测试定义、实际执行结果。设计笔记属于第四类：它解释意图和疑问。它可以帮助提出问题，但不能替代前三类。
这个小插曲提醒我们，技术文章的戏剧性应该来自问题的结构，而不是把每个提交标题都写成英雄时刻。有时真正诚实的一句话就是：“这条记录只清理了临时说明。”
六、怎样评估设计转向是不是值得
至少建立两份对照。第一份是功能契约：布局、位宽、参数形式、融合属性、错误输入，在两条路径中分别如何处理。第二份是资源账：常量大小、局部内存峰值、中间张量次数、指令配置数量和实际运行时间。
建议的待执行回归包括：
- 相同模型分别经专用与分解路径，比较各个中间实数语义和最终整数输出。
- 让乘积先越界、偏置再抵消，检查额外饱和是否改变结果。
- 同时覆盖紧凑广播和物化广播，观察参数数据量。
- 对不支持的融合属性检查稳定、明确的诊断。
- 检查移除专用实现后，构建注册、接口声明与资源估算均无残留。
- 对不同分支分别确认支持状态，不用一条分支的测试推断另一条分支。
性能模型也不应预设赢家。专用路径可能更少中间物化，通用路径可能获得更好的分块与调度；在小张量上，指令配置占比可能较大，在大张量上，参数展开和额外读写可能主导。没有测量，就把它们写成竞争假设。
历史的价值，不是证明第一次设计错、第二次设计对，而是展示约束如何变得清晰：当维护成本集中在一个节点上时，拆开可能是进步；当执行代价集中在拆开的边界上时，适度融合又可能值得。好的抽象允许这两步在不同阶段同时成立。
七、设计退路，也是一种前进速度
在专用实现刚加入时，可以提前约定一个可退回的通用表达：它说明在不满足快速路径条件时，如何用已有操作保持同一语义。这样专用路径负责受控条件下的优化，通用路径负责可解释的覆盖，两者不会被迫同时承担所有新需求。
例如专用实现只支持某种布局和参数形式，就让匹配条件明确检查这些约束；条件不满足时回到通用乘加。不要先生成半套配置，再在深层内核中因为未知形状失败。越早划清适用域，越容易判断某次失败属于模型不支持、合法化缺失还是后端实现错误。
不过退路也必须测试。若通用路径采用两次舍入，专用路径采用一次舍入，二者可能只在允许误差范围内等价，而非逐位相同。应把等价级别写进测试规则：要求精确相同、绝对误差限制，还是某种有数学依据的误差界。否则选择快速路径的开关会让回归出现“时好时坏”的假象。
删除专用节点时，还可以做一次反向搜索：哪些优化曾依赖这个节点才能识别仿射结构？如果这些机会消失，是否需要在通用图上增加识别模式？这不一定要求立刻补回全部性能，但至少应让损失可见。代码删除的完成条件不只是链接成功，也包括确认被删除表示曾承担的分析角色。
文档的处理同样可以更精确。临时审查稿不适合一直充当规范，但它提出的关键未决问题值得转为稳定设计说明、测试项或已关闭结论。把草稿删掉有助于减少过时信息；把尚未解决的问题一起忘掉则没有。历史的一条文档删除记录无法告诉我们后续是否这样归档，因此文章只讨论原则，不补写不存在的过程。
一个好的设计复盘，不需要把每次转向包装成一开始就预料到的计划。承认“这个实现让约束变得可见，所以选择改变边界”，比事后把历史剪成完美直线更能帮助后来者。读者真正需要的是判断条件，而不是一段没有岔路的传奇。
If you like this blog or find it useful for you, you are welcome to comment on it. You are also welcome to share this blog, so that more people can participate in it. All the images used in the blog are my original works or AI works, if you want to take it,don't hesitate. Thank you !