去年冬天我接手了一个推理服务的性能优化模型本身没改动端到端延迟却比预期高了将近一倍。排查到最后发现问题不在框架、不在量化、也不在内存拷贝而是几个核心算子用的 schedule 是照搬开源示例的默认参数——分块尺寸、向量化宽度、并行粒度全是别人机器上跑得通的值放到我这块 CPU 上完全不合适。这件事让我彻底转向了 AutoTVM 这套基于 Python API 的自动调优方案它做的事很朴素就是把该用多大的分块循环怎么拆什么时候向量化这些原本靠经验和反复试错决定的参数交给一个搜索器去自动跑分数。AutoTVM 的 Python API 就是这套机制暴露给使用者的全部入口搞清楚它你才能把任意一个自己写的 te 算子接进调优流程而不是只能调官方预置好的那几个模板。这篇内容面向的是已经能用 TVM 写出基本 schedule、但还没系统用过 AutoTVM 的开发者也适合那些用过一次apply_history_best却始终没搞清楚日志里到底存了什么的老手。我会从模板的定义方式一直讲到测量后端、调优器选型、日志复用和最后的收益验证中间夹着我自己踩出来的坑。1. AutoTVM 在整条编译链里到底替谁干活很多人第一次接触 AutoTVM会把它理解成自动写 schedule 的工具这个理解偏差挺大容易导致后面用错方向。AutoTVM 并不会帮你决定用不用te.compute、要不要做算子融合、要不要做 reduction 拆分这些结构性决策仍然要人来做。它真正负责的是在你已经搭好的 schedule 骨架里把那些数值型的选择分块因子、展开因子、并行轴位置、向量化宽度作为搜索变量通过实际测量执行时间来打分找出你这块硬件上最快的那组取值。这个定位决定了使用 AutoTVM 的正确姿势是先有模板再谈调优。模板质量差搜索空间设计得不合理再强的搜索器也救不回来。我见过有人把整个 schedule 结构都做成条件分支塞进搜索空间结果空间大到 10 的十几次方跑一晚上只能采到边角料这种情况还不如老老实实手工调几个关键参数。1.1 手写 schedule 卡在哪个环节手写 schedule 的问题不在于写不出来而在于没有反馈闭环。你按经验写一组参数编译、运行、测时间如果不好就再改一组。这个循环单次成本可能是几分钟而值得尝试的组合动辄几百上千种。更麻烦的是参数之间是耦合的你把tile_x从 4 调到 8最优的tile_y可能也跟着变了手工调本质上是在一个高维非凸空间里做坐标下降很容易停在局部最优点上。AutoTVM 干的事就是把这个循环自动化并且用代价模型来引导搜索——它不需要把每个点都测一遍而是根据已经测过的点去预测哪些区域更可能有收益优先采样那些区域。对 XGBoost 这类基于树的代价模型来说通常测几百个点就能收敛到接近最优的配置相比穷举的上万点节省了一个数量级。还有一层隐性价值调优日志是可复用的资产。同一块硬件、同一个算子形状调一次可以反复用。这在多模型、多批次上线的场景里非常划算。1.2 Task、ConfigSpace、Tuner 三件套之间的依赖关系抛开代码AutoTVM 的 Python API 在概念上只有三个东西理清它们的关系后面所有 API 调用都是顺理成章的事。Task是一个待调优的计算任务由算子名、参数形状、数据类型和目标平台三者唯一确定。它包含信息这是什么算子、在什么形状下、编译到哪个 target。同一个算子在不同 shape 下是不同的 Task不同 target 下也是不同的 Task。ConfigSpace是这个任务允许调哪些旋钮、每个旋钮取值是什么。它是在模板函数内部通过cfg.define_split、cfg.define_knob这些调用动态构建出来的是模板的副产品。也就是说搜索空间不是单独定义的而是定义模板时顺手长出来的。Tuner是搜索器它拿着 Task 和 ConfigSpace反复挑一个候选配置交给测量后端跑一遍拿到时间然后根据结果更新自己的策略再挑下一个。这三者的关系可以类比成Task 是考题ConfigSpace 是选项集合Tuner 是答题策略。测量后端measure_option是判卷老师日志是答题卡。这一整套流程在代码上的入口就是autotvm.task.create()加上tuner.tune()。2. 模板函数怎么写把可调旋钮嵌进 te 算子里模板函数是整件事的地基写错了后面全白费。它的契约很简单接收一组算子参数形状、dtype 等返回(schedule, [输入张量列表])二元组。函数内部既要用te把计算定义出来又要通过autotvm.get_config()拿到配置对象在构建 schedule 的过程中把配置项应用到具体的循环上。这里最容易混淆的一点是同一个模板函数会以两种身份被调用。调优阶段get_config()返回的是一个ConfigSpace对象cfg[tile_x].apply(...)这种调用会往搜索空间里注册一个可调项并且随便取一个值让 schedule 能建起来应用阶段get_config()返回的是一个ConfigEntity里面装的是从日志里读出来的具体数值apply就是老老实实把那个值用上。理解这个双身份机制你就明白为什么模板函数里绝对不能有副作用也不能依赖任何外部可变状态。2.1 一份能跑通的矩阵乘模板骨架下面这段是我常用的最小可用模板矩阵乘法两个可调项分块因子和一个展开因子。参数不是最优的但结构完整可以直接改。import tvm from tvm import te, autotvm autotvm.template(tutorial.matmul) def matmul(M, N, K, dtypefloat32): A te.placeholder((M, K), dtypedtype, nameA) B te.placeholder((K, N), dtypedtype, nameB) k te.reduce_axis((0, K), namek) C te.compute( (M, N), lambda i, j: te.sum(A[i, k] * B[k, j], axisk), nameC, ) s te.create_schedule(C.op) cfg autotvm.get_config() y, x s[C].op.axis # 注册一个二维拆分把 y 轴拆成 yo, yix 轴拆成 xo, xi cfg.define_split(tile_yx, y, num_outputs2) cfg.define_split(tile_xx, x, num_outputs2) # 注册一个离散取值内层循环展开多少 cfg.define_knob(unroll, [1, 2, 4, 8]) yo, yi cfg[tile_yx].apply(s, C, y) xo, xi cfg[tile_xx].apply(s, C, x) s[C].reorder(yo, xo, yi, xi) s[C].unroll(xi, cfg[unroll].val) s[C].vectorize(xi) return s, [A, B, C]几个细节值得单独说。第一define_split的第一个参数是旋钮名第二个是要拆的那个迭代变量不是维度下标。很多人一开始会传x这个 Python 元组变量里的某个位置写错了会直接抛类型错误。第二apply的返回值才是拆出来的新轴必须用返回值去reorder不能用原来的y、x。第三cfg[unroll].val在调优阶段取的是候选值之一在应用阶段取的是日志里的值两处代码完全一致不需要条件分支。2.2 define_split 与 define_knob哪些参数值得暴露出去搜索空间的大小直接决定调优时间而空间大小等于各个旋钮取值个数的乘积。上面那份模板里define_split默认会把所有能整除的因子都枚举出来对于 1024 这种高度合数的维度单个define_split就可能产生几十个候选两个一乘就是上千再乘上unroll的 4 个取值总空间就到几千了。我一般遵循三条经验其一只暴露真正影响性能的轴比如 reduction 轴的拆分对矩阵乘影响很大而 batch 维如果只有 1拆它毫无意义直接写死。其二用define_knob手工给候选值不要图省事让define_split全量枚举比如分块因子只给[1, 2, 4, 8, 16]这几档空间立刻降一个数量级。其三候选值要贴合硬件向量化宽度给到 8 而你的平台只支持 4 路 SIMD那一半候选值纯属浪费测量次数。define_split还有一个filter参数可以传一个 lambdas 去剔除不合理的组合cfg.define_split(tile_yx, y, num_outputs2, filterlambda x: x.size[0] 64 and x.size[1] 16)这个filter里的x是一个候选拆分方案x.size是拆出来的各级因子。用它来排除外层因子过大导致缓存装不下或者内层因子过大导致寄存器溢出的明显坏解能省掉大量无效测量。我通常会给内层因子设一个上限因为内层因子直接决定寄存器压力和向量化宽度超出硬件能力的解测都不用测。另外别忘了cfg.add_flop(...)把算子的浮点运算次数告诉 AutoTVM这样日志和进度条里就能显示 GFLOPS调优过程中你能一眼看出当前最优配置的性能水平比只看毫秒数直观得多。矩阵乘的 flop 就是2 * M * N * K。3. 测量后端怎么挑本机跑与远程跑的真实差别模板写完下一步是告诉 AutoTVM 怎么编译、在哪跑、跑几次。这一整套配置通过autotvm.measure_option传进去由两个组件组成builder 负责把 schedule 编译成可执行模块runner 负责执行并计时。API 上看起来只是两个参数实际选型时踩的坑最多。最基础的写法长这样measure_option autotvm.measure_option( builderautotvm.LocalBuilder(timeout10), runnerautotvm.LocalRunner(number10, repeat3, min_repeat_ms500, timeout10), )这段代码的含义是在本地编译在本地跑每次测量内部执行 10 遍取平均整个测量重复 3 次取最小值每次测量至少耗时 500 毫秒。3.1 LocalRunner最短路径与三个必调参数本机测量适合调优目标和调优环境是同一台机器的情况比如给服务器 CPU 调优或者给本机的 GPU 调优。它的优点是零配置、启动快缺点是测量精度受系统噪声影响大尤其是共享机器上。number、repeat、min_repeat_ms这三个参数是控制精度的核心很多人直接抄默认值结果调出来的配置在不同时间跑出来的分数差异很大其实问题出在测量本身不稳。number是单次测量内部的执行次数取平均。它的作用是摊薄单次调用的计时误差因为time.time()或者 CUDA event 的精度有限算子跑一次可能只有几十微秒直接测一次误差能到 20% 以上。repeat是整个测量重复的次数取最小值它的作用是规避系统噪声带来的偶发慢速比如某次测量恰好遇到调度抖动或缓存被换出取最小值就把这种偶发因素过滤掉了。min_repeat_ms是一个自适应的兜底如果一次测量总耗时不到这个值runner 会自动加大内部执行次数直到超过为止这样能保证测量的信噪比。我的经验取值是CPU 上调优number10、repeat3、min_repeat_ms500GPU 上调优number10、repeat1、min_repeat_ms1000因为 GPU 单次 kernel 太短靠min_repeat_ms自动放大执行次数比手动设number更靠谱。如果调优时间预算紧张可以降到min_repeat_ms200但代价是选出来的配置可能不是真正的最优只是在噪声里看起来最优的那一个。还有一点容易忽略LocalRunner默认在 CPU 上跑如果你的 target 是 GPU必须显式传device参数或者在环境变量里配好。不传的话它会拿 CPU 的计时去给 GPU 的 kernel 打分结果完全失真而且不报错这是最阴险的一类问题。3.2 RPCRunner交叉编译链路和 device_key 的对应关系真正上生产的场景调优机往往不是目标设备。给嵌入式板子或者手机调优只能交叉编译之后把产物推过去跑这时候要用RPCRunner。它的工作方式是目标设备上跑一个 RPC server调优机上跑一个 RPC tracker调优程序通过 tracker 找到设备、把编译好的模块推过去、远程执行并取回耗时。配置上需要三方信息对齐measure_option autotvm.measure_option( builderautotvm.LocalBuilder( n_parallel4, build_funcndk, # 交叉编译工具链 ), runnerautotvm.RPCRunner( device_key_xxx, # 必须与设备端 server 的 key 一致 host127.0.0.1, port9190, number10, repeat3, timeout60, ), )device_key是三处必须完全一致的字符串目标设备启动 server 时传的 key、调优程序里RPCRunner的 key、以及 target 字符串里的-device参数如果你的 target 是这种写法。任何一处不一致表现都是连接超时或者找不到设备而不是给出明确的配置错误排查起来很耗时间。build_func这一项决定用哪套工具链编译。可选值包括default本地编译器、ndk用环境变量里的TVM_NDK_CC指定的交叉编译器、cc通用靠 target 里的-mtriple指定架构。我一般用cc配合完整的 target 字符串比如llvm -mtripleaarch64-linux-android -mattrneon这样 target 里的架构信息和编译器的架构信息只在一个地方维护不容易错配。n_parallel是并行编译的进程数调大能显著减少编译等待时间但要看你调优机的内存是否扛得住每次编译都要加载完整的 TVM 运行时。4. Tuner 选型与调优预算分配模板和测量后端就位后最后一步是选搜索器。AutoTVM 提供的那几个 tuner 在 API 上几乎可以互换差别全在搜索行为上选错会导致该收敛的时候在瞎逛或者过早收敛到坏解。4.1 随机、网格、XGBoost 三种搜索行为的差异Tuner搜索行为适合场景缺点RandomTuner在空间内均匀随机采样空间小、想快速摸底不看历史结果收敛慢GridSearchTuner按顺序穷举所有组合空间极小几十个点以内组合爆炸后完全不可用XGBTuner用梯度提升树做代价预测引导采样空间大、trial 预算有限冷启动阶段偏慢前几十个点近似随机GridSearchTuner的实际用途比想象中少它更适合做验证实验比如你想确认某个新加的旋钮到底有没有用用网格把它的取值全跑一遍成本可控结论明确。RandomTuner在小空间里表现不比 XGBoost 差而且实现简单、没有额外依赖。如果你的搜索空间只有一两百个点直接用随机就够了没必要上模型。XGBTuner是默认选择实测下来几百个 trial 通常能收敛到接近最优。它内部区分kindknob和kindcurve两种模式前者把每个旋钮当成离散类别特征后者利用拆分因子的数值连续性做更细的建模。对于大量使用define_split的模板kindcurve往往效果更好。tuner autotvm.tuner.XGBTuner(task, kindcurve)还有一点XGBoost 的代价模型是按 log(cost)建模的也就是它对相对误差更敏感这对调优来说是好事因为性能优化关注的通常也是相对提升。4.2 number、repeat、timeout 与 early stopping 的组合tuner.tune()的参数里除了n_trial和measure_option还有两个是控制搜索节奏的tuner.tune( n_trial1000, measure_optionmeasure_option, callbacks[ autotvm.callback.progress_bar(1000), autotvm.callback.log_to_file(matmul_tune.log), ], early_stopping200, )n_trial是试验总次数上限。注意每次 trial 是一次采样 测量实际编译和执行的总时间等于 trial 数乘以单次测量耗时再加编译时间。一千个 trial 在 CPU 上可能要跑几个小时时间预算要从这里倒推。early_stopping是连续多少次没有刷新最优值就停。这个参数设得太大浪费预算设得太小容易过早停在一个次优解上。我一般设成n_trial的 1/5 到 1/3比如一千个 trial 配 200 到 300 的 early stopping。如果搜索空间本身很平滑比如只有一个旋钮可以更激进一些因为这类空间里一旦找到局部最优附近基本就是全局最优。callbacks里的进度条是可选的但强烈建议保留不是为了好看而是进度条上会显示当前最优记录的耗时和 GFLOPS你能实时判断还在明显下降还是已经一动不动了这比调优结束后再看日志要直观得多。5. 日志是调优的资产读写、续调和合并调优跑一次成本不低日志的价值不在跑完那一刻而在于后续所有复用。很多人调优时随手把日志扔在临时目录模型上线后想排查某个算子为什么变慢发现原始调优记录早没了只能重跑。我自己维护一个目录结构按硬件型号 / 算子名 / shape 哈希分层存日志一套硬件上跑过的日志基本可以一直用下去。5.1 record 的四元素结果字段日志的每一行是一个 JSON 对象解开看大概是这个结构{ i: [[tutorial.matmul, 1024, 1024, 1024, float32], llvm -keyscpu ...], c: {tile_yx: [[4, 8], [16, 2]], tile_xx: [[2, 4], [10, 4]], unroll: [1, 8]}, r: [[0.00123], 0, 0.045, 1690000000.0], v: 0.4 }i是 task 标识包含算子名、参数列表和 target 字符串这也是为什么 target 变了日志就用不上——匹配是全字段匹配。c是配置每个旋钮的值记录成[当前值在候选列表中的下标, 候选列表长度]这种紧凑格式省空间。r是结果四个元素分别是第一个测得的执行耗时秒是number次执行的平均值、repeat次的最小值第二个错误码0 表示正常非 0 表示编译失败或运行失败第三个这次测量的总耗时秒包含编译和执行用于统计调优成本第四个时间戳理解r里第一个值是什么尤其重要因为它不是跑一次的时间而是统计之后的值。你如果在别处手工计时做对比数字对不上是正常的比较的基准不一样。autotvm.record.load_from_file()会把这些 JSON 解析成(state, config)的列表state里有task、cost、error_no等属性你可以写脚本自己做筛选比如剔除 error_no 非 0 的记录、按 cost 排序取前十个看看它们的配置有没有共性。这种手工分析在大空间调优之后特别有用能帮你发现某个旋钮的某个取值区间普遍表现好这类规律进而收缩搜索空间重调比盲目加 trial 有效得多。5.2 多进程调优的日志竞争log_to_file默认是追加模式这个默认值意味着你可以安全地分批调优、追加到同一个日志。我常用这个特性把长时间的调优拆成几个晚上的批次中间机器要用就中断第二天接着跑日志自动累积。但多进程并发写同一个日志文件时要注意每一行是独立写入的通常不会出现半行撕裂因为单行长度远小于缓冲区大小且是追加写但如果进了不同的文件系统或者用了某些容器挂载方式理论上存在风险。更稳妥的做法是每个进程写各自独立的日志文件调优结束后用cat合并成一个日志格式是逐行 JSON合并天然安全。续调还有个技巧如果某个 task 的日志里已经有几千条记录重新调优时 tuner 并不会自动读旧日志继续你需要先把旧日志里的记录加载进 tuner 的 history。XGBTuner提供了一个内部的 history 容器可以通过遍历旧记录手动灌进去但更简单的做法是把旧日志当成一次预采集直接用旧日志跑apply_history_best看效果如果已经够用就不再调如果不够用就在同一个日志文件上继续追加调优结束后整体重新选最优即可——因为apply_history_best是在整个日志里全局取最优追加的内容会自动参与比较不需要特殊处理。6. 把最优配置接回构建apply_history_best 的作用域调优跑完日志里躺着几千条记录最终的落地代码只需要一行上下文管理器with autotvm.apply_history_best(matmul_tune.log): with tvm.transform.PassContext(opt_level3): lib tvm.build(s, [A, B, C], targetllvm)这一行的效果是在这个with块内部的所有tvm.build或relay.build调用遇到模板函数时不再走get_config()的调优分支而是走应用分支把日志里该 task 的最优配置注入进去。6.1 with 块内部发生了什么apply_history_best的实现是一个上下文管理器进入时把当前线程的 dispatch context 换成一个从日志构建的DispatchContext退出时恢复原样。这个 context 里维护着task key → 最优 config的映射表。关键在于匹配规则日志里的 task 标识是(算子名, 参数元组, target 字符串)构建时用同样的规则生成查询 key三者全等才算命中。这意味着算子名必须完全一致autotvm.template(tutorial.matmul)里的字符串就是 key参数的类型和顺序必须一致(1024, 1024, 1024, float32)和(1024, 1024, 1024)算不同的 keytarget 字符串必须一致多一个空格或者少一个-mattr参数都算不同的 key命中失败时不会报错静默走模板里的get_config()默认路径用一个随机的候选配置。这是最坑的一点你满心以为调优生效了实际测出来性能没变原因是 key 没对上。我一般会在with块里加一句断言式的调试输出把命中的 task 数打出来from tvm.autotvm import task as _task with autotvm.apply_history_best(matmul_tune.log): ctx autotvm.DispatchContext.current for k, v in ctx.query_imported_fallback.items(): print(hit:, k) # 再进行 build不同版本的内部属性名可能不同但思路是通用的构建前先确认命中了再谈性能。6.2 验证调优是否真的生效的三个办法第一看编译产物。调优生效前后生成的函数体lib.get_source()或者反汇编里循环结构会明显不同分块和展开会体现在代码里。这是最直接的证据。第二做 A/B 计时。同一份代码一次不加with一次加上用足够多次的执行取平均值对比。差异在 5% 以内的话说明调优收益不明显可能是这个算子的瓶颈不在 schedule 参数上而在内存带宽或者算法选择上这时候继续调参是徒劳的。第三看端到端。单算子调优的收益不等于端到端收益算子在整体耗时里占的比重决定了上限。我遇到过一个算子调优提升 40%但它在推理流程里只占 5% 的时间端到端只提升了 2%。所以在投入大量调优时间之前先做性能剖析找出真正的大头把调优预算花在占比最高的几个算子上。7. 踩坑实录模板污染、target 错配与缓存假象写到这里API 的主链路已经完整了。但真正让我吃亏的都不是 API 用法而是几个看起来无关紧要的实现细节。7.1 模板函数里藏了可变全局对象有一次我为了复用几个中间结果在模块顶层定义了一个列表在模板函数里往里 append。表现是调优阶段跑得好好的测量数据也正常但应用阶段生成的代码和日志里的最优配置对不上。排查了很久才发现模板函数在一个进程里会被调用非常多次每次调用都往那个列表里塞东西导致 schedule 的构建过程依赖了之前调用的状态。AutoTVM 的模板函数必须是纯函数同样的输入必须产出同样的 schedule 结构唯一的变量是get_config()给出的配置值。任何跨调用的状态——全局变量、类的实例属性、闭包捕获的列表——都会污染结果。我后来的做法是模板函数里所有中间变量都在函数内部新建需要共享的东西通过参数传进去宁可多写几行也不留隐患。还有一个变体用lru_cache缓存模板函数的编译结果。这个做法在调优阶段是灾难性的因为调优就是要用不同配置反复构建同一个算子缓存直接让所有配置返回同一份结果实测数据全是假的。如果你确实想加速缓存的粒度应该是编译产物而且要在配置层面做 key不是简单的参数 key。7.2 target 与物理设备不一致的隐蔽失败生成 task 时的 target 字符串必须和实际运行时的硬件严格对应包括 CPU 特性。我犯过一次错target 写成llvm不带任何-mattr但实际机器支持 AVX2。结果是编译出来的代码只用了 SSE 级别的指令调优器在一个错误的指令集假设下找最优配置找出来的最优在启用 AVX2 之后完全不是最优——搜索空间里那些向量化宽度为 8 的候选因为编译器生成不出对应指令而全部被判为慢速实际上它们才是真正该选的。正确的写法是把机器特性显式写进 targettarget llvm -mcpuskylake-avx512 # 具体型号 # 或者 target llvm -mattravx2,fma # 特性列表用具体型号-mcpu比手工列特性更省心因为型号里隐含了一整套特性组合。但对跨机器分发的产物用-mattr更可控你可以明确知道用了哪些指令避免在不支持的机器上崩溃。还要注意 target 字符串会进日志的匹配 key调优时用的 target 和部署时用的 target 必须完全一致。我现在的做法是把它定义成一个模块级常量调优脚本和构建脚本从同一个地方导入从源头上杜绝不一致。还有一个更隐蔽的场景在容器里调优容器的 CPU 特性和宿主机不一致尤其是通过 cgroup 限制或者做了 CPU 亲和性绑定之后暴露给编译器的特性列表可能变窄。这种情况下的调优结果拿到宿主机上用可能反而变慢。我现在调优前会先跑一个探测脚本打印当前进程可见的 CPU 特性确认和部署环境一致再开跑。最后说一个关于调优预算的心得AutoTVM 的搜索效率在 trial 数达到几百之后边际收益急剧下降继续加 trial 大概率只是在噪声里打转。与其把一千个 trial 加到五千不如把搜索空间的候选值重新审视一遍砍掉明显不合理的挡位或者针对性地给某个关键旋钮更细的取值粒度。我在实际项目里最有效的一次优化是把某个旋钮的候选值从均分的 8 个改成贴合缓存行大小的 5 个trial 数减半最终选出来的配置反而快了 6%。