[MLC-04] Automated Program Optimization and Meta-Schedule

手工写 schedule 很适合理解优化，但很难覆盖所有 shape、硬件和算子组合。第四讲把问题改写为：既然有许多语义等价的 TensorIR 版本，能否定义变换空间，再通过测量自动选择更好的版本？

1. 从一个 schedule 到一族程序#

对 matmul 而言，tile 大小、loop order、并行轴、vector width、unroll 因子都可能不同：

same TensorIR semantics
        |
        +-> tile M/N/K = (16, 16, 32)
        +-> tile M/N/K = (32, 8, 16)
        +-> different reorder / cache placement / unroll

这些选择组成程序搜索空间。关键不是随便改代码，而是只使用被证明保持语义的 schedule primitive。

2. Stochastic Schedule Transformation#

随机调度变换把“固定选择一个参数”替换成“从候选中采样”：

tile = sch.sample_perfect_tile(loop=j, n=2)
j0, j1 = sch.split(j, factors=tile)
sch.bind(j0, "blockIdx.x")
sch.vectorize(j1)

同一段 schedule script 可生成多个候选模块。它描述的不是单一实现，而是一个由规则约束的实现家族。

3. 自动调优的闭环#

课程给出的自动优化流程可以写成：

IRModule
  -> generate schedule candidates
  -> build candidate
  -> run on target and measure latency
  -> record result / update search policy
  -> select the best implementation

成本模型可以减少无意义候选的测量次数，但最终性能仍需要目标环境的实测确认。因为缓存行为、编译器生成代码和硬件资源竞争通常无法被简单静态公式准确覆盖。

4. 搜索空间比搜索算法更重要#

自动调优有两个问题：

如果搜索空间不包含有效的 memory tiling 或硬件映射，再聪明的搜索器也找不到高性能版本；如果空间过大、无效候选过多，测量预算会被浪费。

因此 Meta-Schedule 的实际价值不只是“自动找参数”，而是把领域知识编码进 schedule rule、post-processing 和测量策略。

5. 回到端到端图#

调优得到的新 primitive function 需要回填到端到端模块：

Relax graph
  call_tir("matmul")
          |
          +-> replace with tuned matmul implementation

这说明 kernel tuning 和图执行不是两件孤立的事。图层负责引用哪个函数；程序层负责让该函数在目标上更快；构建系统负责把二者打包成同一部署产物。

6. 学习笔记#

自动优化并不消灭人工经验，它改变人工经验出现的位置：从手工指定一个唯一实现，变为设计可解释的变换空间、合法性约束和测量指标。

对于 LLM 推理也一样：block size、attention backend、CUDA Graph shape 或 batch policy 可能需要调优，但实验设计必须先保证比较的 workload 和资源约束一致。

参考#

• MLC 课程：Automated Program Optimization
• TVM Meta-Schedule