步骤 2：瓶颈分析与方案选择

目标：根据基线判断该优化该改哪里，避免盲目写汇编或盲目加 unroll。

2.1 先分类瓶颈

类型	常见信号	优先方向
memory bound	eff GB/s 接近 memcpy roofline	减少字节、改善连续访问、减少 metadata
unpack/issue bound	eff GB/s 低但指令很多	减少 bit unpack、常量复用、调整 layout
compute bound	GFLOPS 接近指令峰值	更大 tile、更多 accumulator、ISA 指令
postprocess bound	dot 快但 scale/minmax/store 慢	合并后处理、缩短 min/max live range
dispatch/pack 错配	质量错或某 ISA 独坏	检查 packer、unit、kernel pointer

w2/w3 常见是 unpack/issue bound，不是单纯 bandwidth bound。

2.2 低 bit kernel 专项分析

分析以下问题：

packed cell 的真实字节数是多少？是否有 padding？
block32、block64、per-channel 的 metadata stride 是否不同？
OC split 时 weightPtr 是否按真实 cell stride 前进？
i8mm 和 sdot 是否共享 packer？共享是否安全？
sdot/smmla 的 lane 分组和 pack layout 是否完全匹配？
fp32 min/max、scale、bias、zp 是否被 unpack 临时寄存器覆盖？
E=1 decode 是否走了和 E>1 不同的 kernel？

如果质量问题只出现在一个 ISA，优先查 dispatch/pack/register lifetime。如果 no-thinking/greedy 正常但 mixed sampling 复读，先不要判定 kernel 错。

2.3 方案优先级

按风险从低到高选择：

修正确认的 correctness bug：stride、tail、register clobber、dispatch 错配。
复用已有 CoreFunctions 或已有 kernel 分支。
C++ 层减少拷贝、修正线程拆分、避免 onExecute 分配。
block64/default case 专用分支。
常量 hoist、ld1r replicate load、减少重复 unpack。
调整 pack layout，但不增加 packed bytes。
扩大 unroll 或新增 asm tile。
增加 packed bytes 或改变量化格式，只有用户明确接受时才做。

2.4 写方案时必须包含

markdown

## 方案

目标路径：
当前瓶颈：
不优化的路径：

Correctness guard:
- C++ oracle:
- op tests:
- model sanity:

实现计划:
1.
2.
3.

性能目标:
- metric:
- expected direction:

风险:
- register lifetime:
- pack/dispatch:
- tail/block:

性能目标可以是方向性的，例如减少 unpack 指令或提升 eff GB/s，不要编造未实测数字。

通过标准

已用数据解释瓶颈，而不是凭直觉。
已明确哪些路径不在本次范围。
已有 correctness guard，能在每个小改动后快速验证。
方案没有依赖用户未接受的格式变化，例如扩大 w2/w3 字节。