自动调优：调优空间定义

CH-19-02-038·约 21 分钟·AI编译器与系统软件·更新 2026-08-12

你买了一套毛坯房，准备装修改造。装修公司的第一句话往往不是“您喜欢什么风格”，而是“您打算改哪些地方”——能拆墙吗？能重新布线吗？卫生间能移位吗？这些问题看似煞风景，却是整个装修的地基。把“能改什么”划清楚，后续设计才有边界，施工才有方向，预算才不失控。如果“什么都不能动”，那再好的改造想法也只能咽回肚子里；如果“想怎么改就怎么改”，设计师光是排列组合方案就能画上一整年。在AI编译器的世界里，TVM等框架面对的任务和装修如出一辙。我们要把用深度学习框架写好的算子代码“装修”成在GPU上高效运行的程序。可优化的手段琳琅满目：循环怎么变换、数据怎么分块、线程怎么绑定……这些手段的总和，就是“调优空间”。而“调优空间定义”，就是那道决定“能改什么”的第一道工序。这篇文章，我们就用“装修”这个比喻做线索——拆墙对应循环变换，隔断对应分块，安排房间对应线程绑定——把调优空间定义的知识框架完整讲透。你会发现，边界划得好不好，直接决定了自动调优这个“装修工程”最终能交付一个什么样的“家”。

岗位关联

学透调优空间定义，等于掌握了AI编译器自动调优的“设计蓝图”能力。无论是做推理加速、训练优化还是端侧部署，你都能精准定位性能瓶颈并设计高效的搜索方案，这是AI系统工程岗位的核心竞争力。

可视化演示
1. 调优空间本质
2. 调度原语体系
3. 循环变换手段
4. 分块策略设计
5. 线程绑定映射
6. 空间设计原则
7. 工程实践应用
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示TVM如何用调度原语定义算子的调优空间：循环树结构、split/fuse/reorder变换，以及空间大小与搜索代价之间的权衡。

本节配有交互动效（进入视口后自动加载，约 3KB）。

循环树：加点变换根为输出计算，叶为最内循环调优空间=Σ合法schedule 调度原语作用于循环树节点生成全部候选。

1. 调优空间本质

装修的第一步，不是选沙发也不是挑窗帘，而是和设计师一起划“红线”：哪些墙能拆，哪些梁不能动，哪些管道可以移位。这份“允许改动清单”就像一道国境线，划定了整个装修的可能边界。边线划得保守，改造空间就小；划得激进，合同金额和工期就双双失控。调优空间定义在自动调优里的位置，正是这条“国境线”。

在TVM编译器中，一段算子代码的优化方案是多种多样的。有的方案把循环拆得更碎以利用并行性，有的方案把数据重新分块以提高缓存命中，有的方案把计算映射到不同的线程层级。这些方案组成的集合，就是“调优空间”。空间定义就是从这些维度出发，明确“编译器可以尝试哪些优化、不可以尝试哪些”。它直接决定了后续搜索算法能看到多大的“地图”。

调优空间的数学本质是一个多维参数空间的笛卡尔积。假设有分块大小、拆分因子、线程绑定三个维度，每个维度分别有a、b、c个候选值，那么空间大小就是a×b×c。空间大小直接与搜索成本挂钩：每增加一个维度、每扩大一档候选值，搜索的选项空间就成倍增长，这就是“维度灾难”的来源。因此，精确定义空间的目标，是把搜索算法的注意力聚焦在真正有希望的高性能区域。

空间定义就像给装修划红线：红线内的每一条线、每一度转角，都是设计师可以施展的天地。天地太窄，好方案无从谈起；天地太宽，光是看方案就要花上几个月。聪明的做法，是把红线划在“既有创意又不失控”的位置——这正是调优空间定义的功力所在。

\displaystyle |\mathcal{S}| = \prod_{i=1}^{n} |D_i|

调优空间大小等于各维度候选数量的乘积。每多一个维度、每多一档取值，总方案数都成倍膨胀。

调优空间S所有合法调度方案组成的集合，好比装修中“允许的改动组合”。
$\mathcal{S}$
维度D_i第i个可调维度，如分块大小、循环拆分因子、线程绑定方式。
$D_i,\; i = 1, 2, \dots, n$
候选数量|D_i|该维度上允许取值的个数。
$|D_i|$
连乘各维度候选数相乘，得到空间总方案数。
$\prod_{i=1}^{n} |D_i|$

2. 调度原语体系

装修公司会有一本“手艺手册”：拆墙、砌墙、改水电、做吊顶、铺地板……每一种手艺都对应一套工具和操作规范。设计师的所有方案，归根结底都是这些手艺的不同组合。调优空间的语言基础，同样是这样一本“手艺手册”——TVM中的调度原语。

调度原语（Schedule Primitive）是TVM提供给开发者描述循环结构变换的底层API。它们决定了“你能对代码做哪些类型的动作”。常见的调度原语包括：split（拆分循环）、fuse（融合循环）、reorder（重排循环顺序）、bind（绑定到线程）等。每一个原语就是对计算结构的一次“改写动作”。

以split为例，它把一个长度为N的循环拆成两段：外层循环每轮处理f个元素，内层循环负责具体处理这f个元素。这为后续绑定线程或并行化创造了条件。原语的参数化就构成了调优空间的维度：拆分因子f取什么值、融合哪些循环、绑定到哪个线程层级，都是空间中的坐标。原语越多、参数越灵活，空间表达的粒度越细，但参数组合数也会随之暴涨。

就像装修公司的“手艺手册”决定了你能给房子做哪些改造，调度原语体系决定了编译器能对代码做哪些“改造动作”。一栋毛坯房最终能变成一个多么舒适的家，首先要看手艺箱里到底有哪些工具。

\displaystyle N = N_{\text{outer}} \times f + N_{\text{remainder}}

拆分公式把总工作量N拆成“外循环轮数×每轮数+余数”，是split原语的数学表达。

原始长度N目标循环的迭代次数，相当于需要加工的总工作量。
$N$
外循环迭代数拆分后外层循环的迭代次数。
$N_{\text{outer}} = \left\lceil \frac{N}{f} \right\rceil$
拆分因子f每次外循环迭代时内层循环处理的元素数。
$f$
余项当N不能被f整除时产生的尾迭代。
$N_{\text{remainder}} = N \bmod f$

3. 循环变换手段

生活中我们经常调整房间的“动线”：把厨房和餐厅打通，让饭菜上桌的路更短；把大客厅隔出一个书房，让会客与工作互不打扰；把卧室门口的鞋柜移到玄关，让进门换鞋更顺手。这些调整不改变房子的总面积，却极大地改变了居住体验。循环变换就是程序世界的“动线设计”。

循环变换是调优空间中最核心的一类维度。它们不改变计算的总量，只改变计算的“顺序”和“粒度”。主要的变换手段包括：循环融合（fusion）把两个相邻循环合并，提高数据复用；循环拆分（split）把一个循环分成嵌套的多层，为并行化铺路；循环重排序（reorder）改变嵌套循环的执行次序，以提高访存局部性；向量化（vectorize）让同一时刻处理多个数据元素。

循环融合在深度学习中尤为常见。比如计算 y = (x × w) + b 时，逐元素乘法和加法是两个规模相同的循环。如果分别执行，需要两次读入x和w；融合成一个循环后，每个元素一次读入即可完成乘加，访存流量减半。循环重排序则常用于多维循环：把“按行优先”改成“按列优先”或更精细的遍历路径，使得对显存/缓存的访问模式更连续。

动线设计改变的是人在家中的行走路径，循环变换改变的是数据在处理器中的“行走路径”。路径短了、不绕路了，程序跑起来自然就轻快了。调优空间里每多一种循环变换维度，设计师手中的“户型图”就多一份可塑性。

\displaystyle I_{\text{fused}} = I_1 = I_2,\quad \text{Mem}_{\text{fused}} \approx \frac{1}{2} \text{Mem}_{\text{separate}}

融合前后迭代次数不变，但访存总量约减少一半。数据在寄存器中重用了，读内存的次数自然就少了。

迭代次数I_fused融合后循环的迭代次数，当两个循环规模相同时保持不变。
$I_{\text{fused}} = I_1 = I_2$
访存对比融合前需要两次读入同样数据，融合后只需一次，因此访存约为原来的一半。
$\text{Mem}_{\text{fused}} \approx \frac{1}{2} \text{Mem}_{\text{separate}}$

4. 分块策略设计

搬家的时候，把所有东西塞进一个大纸箱，你根本搬不动；于是你找来许多中小纸箱，每个纸箱贴上标签，分区摆放。大箱子进不了楼梯间，就拆成小箱分批搬上楼。分块策略，就是程序世界里的“打包搬家”。

在GPU等硬件上，数据需要从大容量、慢速的全局内存搬到小容量、快速的共享内存或寄存器中。一次搬动的数据量（即“块”的大小）必须合适：太大放不进缓存，太小又频繁搬运。分块策略（Tiling）就是把循环的迭代空间切成若干小块，让每个小块的计算能够在一个可容纳的存储层级中完成。

平铺分块是最基本的形式：假设一个二维循环空间为M×N，以b_m×b_n为块大小切分，得到 (M/b_m)×(N/b_n) 个块。每个块内部的数据在共享内存中复用，大幅减少全局内存访问。进一步地，多级分块会分别针对寄存器、共享内存、全局内存设计不同层级的块大小，形成嵌套的分块结构，能够显著提升数据局部性。分块大小这些参数，自然成为调优空间的重要维度。

打包的策略虽然不起眼，却直接决定搬家效率：箱子太大，搬不动也放不进车；箱子太小，来回跑的趟数让你崩溃。分块策略的每一个参数，都是调优空间里一个值得细调的“箱子尺寸”。

\displaystyle B = \left\lceil \frac{M}{b_m} \right\rceil \times \left\lceil \frac{N}{b_n} \right\rceil \times \left\lceil \frac{K}{b_k} \right\rceil

三维循环空间按块大小切分后，总的块数量是三个方向上块数的乘积——块数越多，可并行执行的粒度就越细。

矩阵维度M、N、K典型如矩阵乘或卷积中，输出行数、输出列数和归约维度的长度。
$M, N, K$
块大小b_m、b_n、b_k每个分块在三个方向上的尺寸。
$b_m, b_n, b_k$
向上取整当维度不能被块大小整除时，用上取整保证覆盖所有元素。
$\left\lceil \cdot \right\rceil$
块总数B所有分块的数量，也是可并行执行的块数上限。
$B$

5. 线程绑定映射

一家人住进新房子，谁住主卧、谁住次卧、谁睡书房，也是一门学问。卧室分配得好，孩子学习不被打扰，老人起夜不吵到别人。更妙的是，如果每间房都配有独立卫生间，“串门”的次数就大大减少。线程绑定，就是给程序的计算任务“分配房间”。

GPU的计算资源是按层级组织的：一个Grid包含若干Block，一个Block包含若干Thread。计算任务要跑得高效，必须把循环的各个维度“安排”到正确的层级上。线程绑定（binding）就是这种安排动作，通过bind原语把循环轴绑定到 blockIdx.x、threadIdx.x 等硬件索引上。

绑定策略直接影响执行效率。通常，外层循环适合绑定到Block，因为它们对应粗粒度的并行单元；内层循环绑定到Thread，对应细粒度的并行执行。如果绑定层级选反了，可能造成大量的线程间通信与同步开销，甚至降低资源利用率。此外，线程块的大小（如128、256）也会影响占用率：线程太多会限制每个线程可用的寄存器数，线程太少又不足以隐藏访存延迟。这些绑定方式与线程配置，同样是调优空间中的关键维度。

房间分配看起来是小事，住起来才发现处处是学问。线程绑定也是这样：把计算任务安排到合适的“房间层级”，数据搬运和指令执行的路径就顺了，整个程序的“家庭生活”才和谐高效。

\displaystyle T_{\text{total}} = B_x \times B_y \times T_x \times T_y

总线程数等于网格（Grid）和线程块（Block）两个层级的线程数乘积。配置不同，占用率和执行效率差异巨大。

网格维度B_x、B_y线程块在Grid中的布局，对应粗粒度的并行划分。
$B_x, B_y$
块内线程T_x、T_y每个线程块内的线程布局，对应细粒度的并行执行。
$T_x, T_y$
总线程数T_total一次执行可同时调度的全部线程数量。
$T_{\text{total}}$
乘积关系总线程数取决于网格和块两个层级的乘积。
$\times$

6. 空间设计原则

资深设计师拿到户型图，不会把一万种改造方案全部画出来给你挑，而是先问几个关键问题：家里几口人、作息习惯如何、是否经常有客人来。然后结合经验，只给出三五套方向性方案。他们深知：方案太多等于没有方案。空间设计的原则，恰恰是“少而精”的智慧。

调优空间设计同样要遵循“少而精”的原则。空间越大，搜索算法要探索的候选就越多，调优时间随之拉长。但如果空间过小，又可能把最优方案排除在外。因此，设计空间的过程，本质上是“在表达能力和搜索成本之间寻找平衡”。

几条重要的原则包括：第一，提炼关键参数，只把对性能影响显著的维度（如分块大小、拆分因子、线程数）纳入空间，摒弃细枝末节；第二，采用剪枝策略，通过约束条件排除明显不合理的组合，例如拆分因子大于循环长度、块大小超过硬件缓存容量等；第三，利用启发式规则，从硬件特性与算子的结构特征出发，缩小候选范围，比如根据GPU共享内存大小限制分块上限，或者根据访存规律预设若干经验值。

真正的好设计不是“选择更多”，而是“选择更准”。设计师的经验把万种可能收敛为三五个方向，调优空间设计也用剪枝与启发式，把海量参数收敛为一小片高价值区域。这既是设计原则，也是工程智慧。

\displaystyle |S_{\text{pruned}}| = |S_{\text{raw}}| \times (1 - r_{\text{prune}})

剪枝率越高，保留的候选越少、搜索越快，但要小心别把好方案一并剪掉。

原始空间S_raw未加任何约束时所有参数组合的集合。
$S_{\text{raw}}$
剪枝率r_prune因约束条件被排除的候选比例。
$r_{\text{prune}} = 1 - \frac{|S_{\text{pruned}}|}{|S_{\text{raw}}|}$
剪枝后空间S_pruned保留下来真正值得搜索的候选集合。
$S_{\text{pruned}}$

7. 工程实践应用

成熟的设计公司通常有一套标准流程：先量房，再出方案，方案确认后施工，最后验收和售后。每一步都有模板和存档，不会因为换了设计师就一切重来。TVM的自动调优工程，便是这样一条高度标准化的“流水线”。

在TVM中，自动调优的典型代表是AutoTVM和Ansor。AutoTVM通过模板（template）让开发者用调度原语定义一个调优空间，然后使用搜索算法在该空间中寻找最优参数组合。Ansor则进一步自动化——它不需要手写模板，而是通过程序分析自动生成调优空间与调度候选。两者殊途同归，都把“空间定义”作为调优流水线的第一站。

以AutoTVM为例，开发者通常需要针对某个算子定义一个函数模板，在其中使用调度原语写出“带参数的调度”，如 tile_size、split_factor、num_threads 等。TVM框架对这些参数枚举形成调优空间，然后交给搜索算法（如遗传算法、模拟退火、贝叶斯优化）进行探索。每次探索得到的参数组合都会在真实硬件上跑benchmark，将耗时反馈给搜索器。经过若干轮迭代，搜索器收敛到最优参数，最终生成高性能的可执行代码。这套流程已经广泛用于深度学习模型在GPU、CPU、移动端芯片上的部署加速。

标准化的装修流程让每一套房子都值得被认真对待，标准化的自动调优流程让每一个算子都能挖掘出极致性能。从空间定义到搜索评估，这条流水线的每一环，都在为最终交付的“高性能之家”添砖加瓦。

---

\displaystyle \text{Speedup} = \frac{T_{\text{baseline}}}{T_{\text{tuned}}}

加速比是调优收益的度量：调优后耗时越低、加速比越大，说明空间定义和搜索配合得越好。

基线耗时T_baseline未调优或使用默认配置的算子执行时间。
$T_{\text{baseline}}$
调优后耗时T_tuned经过自动调优搜索得到的执行时间。
$T_{\text{tuned}}$
加速比Speedup两者的比值，衡量调优带来的性能提升倍数。
$\frac{T_{\text{baseline}}}{T_{\text{tuned}}}$

AI 应用场景

云上大模型推理加速

阶段：推理优化（Inference Optimization）

解决的问题：大语言模型推理中包含大量自定义算子（如Attention变体、MoE路由），手工编写CUDA核函数工作量大且难以覆盖多种形状。仅靠通用算子库的默认实现，常常让GPU资源利用率停留在低位。精心定义调优空间可以将搜索范围聚焦在硬件高效区域，让编译器自动找到优于手工实现的调度方案。

具体案例：某云厂商在LLM推理服务中使用TVM自动调优，针对FlashAttention的自定义变体算子定义调优空间——将分块大小限制在64~256、线程绑定限制在128~512。调优空间缩小到原始大小的1/5后，搜索在2小时内收敛，最终生成的算子使端到端首Token延迟降低32%，吞吐量提升28%。

自动驾驶芯片算子优化

阶段：模型部署（Deployment）

解决的问题：自动驾驶域控制器中的NPU芯片架构特殊，通用算子库（如cuDNN、oneDNN）往往不覆盖车载芯片。手工为BEV感知模型中的每个算子编写优化代码，需要数月时间。通过定义面向特定硬件的调优空间，自动搜索可以快速找到适配NPU调度特点的高效实现。

具体案例：团队使用TVM为地平线征程5芯片优化BEV空间注意力算子，在调优空间中固定了NPU特有的数据搬移指令时机，并允许分块大小在16~128间搜索。搜索完成后，算子执行时间从4.2ms降至1.8ms，整个模型跑到了30FPS的实时要求。

AI框架训练算子调优

阶段：训练优化（Training Optimization）

解决的问题：大规模分布式训练中，数据预处理、梯度累积等算子在CPU/GPU上执行耗时占比高达30%。这些算子形态固定但性能敏感，手工优化的边际成本太高。利用自动调优可以低成本地为不同硬件平台生成高效实现。

具体案例：某AI平台团队对PyTorch训练中常用的topk、gather算子用TVM做自动调优，通过剪枝将调优空间从1200种组合压缩到96种，搜索不到1小时即获得最优参数，训练吞吐提升15%，CPU利用率下降20%。

Python 演示

python60 行

import itertoolsimport random  def evaluate(params):    """模拟真实硬件上的算子执行耗时（单位：微秒）"""    tile, split, threads = params    tile_penalty = abs(tile - 64) / 64.0    split_penalty = abs(split - 8) / 8.0    thread_penalty = 0.0 if threads in (128, 256) else 1.5    return 120.0 + tile_penalty * 50.0 + split_penalty * 30.0 + thread_penalty * 20.0  def define_space():    """第一步：定义调优空间——每个维度的候选值列表"""    tile_sizes = [16, 32, 64, 128, 256]    split_factors = [2, 4, 8, 16]    thread_counts = [64, 128, 256, 512]    return list(itertools.product(tile_sizes, split_factors, thread_counts))  def prune_space(space):    """第二步：空间剪枝——排除明显不合理的组合"""    pruned = []    for tile, split, threads in space:        if split > tile:            continue        if tile >= 256 and threads <= 64:            continue        if tile <= 16 and threads >= 512:            continue        pruned.append((tile, split, threads))    return pruned  def search_best(space, mode="exhaustive", trials=50):    """第三步：在空间中搜索最优参数组合"""    if mode == "exhaustive":        candidates = space    else:        random.seed(42)        candidates = random.sample(space, min(trials, len(space)))    best_params, best_time = None, float("inf")    for params in candidates:        cost = evaluate(params)        if cost < best_time:            best_time = cost            best_params = params    return best_params, best_time  if __name__ == "__main__":    raw = define_space()    print("原始空间大小:", len(raw))    pruned = prune_space(raw)    print("剪枝后空间大小:", len(pruned))    best, t1 = search_best(pruned, "exhaustive")    print("穷举最优参数:", best, "耗时 %.1f us" % t1)    best_r, t2 = search_best(pruned, "random", trials=30)    print("随机搜索参数:", best_r, "耗时 %.1f us" % t2)

目的：用最简方式演示调优空间从定义、剪枝到搜索的完整流程，帮助你直观理解“空间大小”与“搜索成本”的关系。

return list(itertools.product(tile_sizes, split_factors, thread_counts))用笛卡尔积把所有候选参数组合展开，这正是调优空间是“各维度候选值乘积”的代码体现。
if split > tile: continue剪枝第一刀：拆分因子大于分块大小是不合理组合，直接丢弃。
if tile >= 256 and threads <= 64: continue剪枝第二刀：大分块配太少线程，并行度不足。
cost = evaluate(params)相当于在真实硬件上跑benchmark，把性能表现转为数值信号。
candidates = random.sample(space, min(trials, len(space)))随机采样一部分候选，模拟搜索算法只探索部分空间。

常见误区

误区刚开始接触调优空间，觉得让编译器尝试的方案越多，就越有机会找到最优解，所以把每个维度的取值都放到最大范围。

正解调优空间过大反而会导致搜索效率急剧下降。想象装修设计师面对一万种方案，单纯看方案就要花几个月。空间每增加一个维度或扩大一档取值，候选组合数按乘积增长，搜索算法要在更大的空间里漫游，收敛变慢。真正好的空间是“小而准”，将候选集中在经验上合理的区域，用剪枝策略排除无效组合。

为何常见：直观上“更多选择=更高上限”的直觉很强，忽略了搜索成本是空间大小的函数；同时初学者还没有建立起“空间设计也是优化对象”的认知。

误区认为调优空间定义和搜索算法是同一件事，只要有了搜索算法，空间自然会定义好，不需要单独设计。

正解空间定义和搜索算法是流水线上两个独立环节。空间定义回答“有哪些候选方案”，搜索算法回答“怎么在候选中找最优”。没有好的空间定义，再强的搜索算法也无从发挥；定义得太粗糙，搜索算法再聪明也找不到好方案。好比装修中“允许改哪些结构”和“选哪套方案”是两件完全不同的事。

为何常见：从用户视角看，输入模型后自动调优就“一键完成”了，空间定义被隐藏在了框架内部，因此容易忽视它的存在和复杂度。

误区既然分块是为了提高缓存命中率，那就把块切得越大越好，让一次加载的数据尽量多。

正解分块大小受硬件存储层级的物理限制。共享内存和寄存器容量有限，块太大装不下，反而导致数据溢出到慢速内存，性能暴跌。就像一个纸箱搬不动，你硬往里塞只会让搬运更费力。分块大小应该匹配目标存储层级的容量，这恰恰是调优空间中最重要的参数之一。

为何常见：缓存友好的直觉是对的，但忽略了“局部内存容量”这一硬约束；在小规模场景下大分块确实有效，容易形成路径依赖。

误区为了让GPU满负荷运转，把线程块配置成尽可能多的线程数，觉得线程越多算得越快。

正解线程数受硬件资源约束。每个线程都需要寄存器、局部内存等资源，线程过多会导致每个线程分到的资源不足，甚至产生寄存器溢出，性能反而下降。同时，过多的线程会增加调度和同步开销。就像一个房间塞太多人，每个人都伸不开手脚，工作效率反而更低。

为何常见：并行计算直觉让人认为“更多并行=更快”，忽略了资源是有限的这一基本约束。

面试题

Q1. 调优空间（Tuning Space）在TVM自动调优中的作用是什么？

单选题 · easy

A.存放编译日志的磁盘空间
B.所有合法调度方案的集合← 正确答案
C.加速器上的物理存储区域
D.算子源码的文本存储结构

答案：B。调优空间是所有合法调度方案的集合，对应装修中“允许的改造方案清单”。它不是磁盘或内存区域，也不是源码结构，而是方案层面的抽象空间。

Q2. 下列哪个不是TVM的调度原语？

单选题 · easy

A.循环拆分操作
B.循环融合操作
C.循环重排操作
D.循环复制操作← 正确答案

答案：D。split（拆分）、fuse（融合）、reorder（重排）都是TVM的标准调度原语，而“循环复制”不是独立的调度原语。好比“拆墙、砌墙、改水电”是装修手艺，而“给房间拍照片”不是改造手艺。

Q3. 循环融合（loop fusion）的主要好处是：

单选题 · easy

A.减少循环总迭代次数
B.提高数据局部性减少访存← 正确答案
C.消除一切分支跳转指令
D.减少计算结果的误差

答案：B。循环融合把多个规模相同的循环合并，使同一数据在一次读入后完成多次计算，从而减少访存流量。迭代次数保持不变，也不涉及分支消除或精度变化。这和把厨房和餐厅打通让“端菜路程”更短是同一个逻辑。

Q4. 假设调优空间有三个维度，候选值数量分别为3、4、5，空间总大小为：

单选题 · mid

A.共计12种组合方案
B.共计15种组合方案
C.共计60种组合方案← 正确答案
D.共计120种组合方案

答案：C。空间大小 = 3×4×5 = 60，符合笛卡尔积公式 |S| = ∏|D_i|。相当于三种拆墙方案×四种隔断方案×五种家具布局，总共60种组合。

Q5. 在GPU线程层次结构中，threadIdx.x 用于标识：

单选题 · mid

A.线程网格Grid的索引
B.线程块Block的索引
C.单条线程Thread的索引← 正确答案
D.线程束Warp的索引

答案：C。threadIdx.x 是线程块（Block）内部的线程索引，标识线程在块内的编号。这相当于“房间内部的床位编号”，而 blockIdx.x 则是“楼层号”。

Q6. 下列哪些属于调优空间设计的原则？

多选题 · mid

A.提炼关键参数← 正确答案
B.采用剪枝策略← 正确答案
C.扩大候选范围
D.利用启发式规则← 正确答案

答案：ABD。调优空间设计讲究“少而精”，通过提炼关键参数、剪枝无效组合和启发式规则来聚焦高价值区域。C选项“扩大候选范围”与设计原则相悖，会导致搜索成本失控。

Q7. 关于分块策略（tiling），下列说法正确的是：

单选题 · mid

A.分块越大缓存命中率一定越高
B.分块大小需要匹配硬件缓存容量← 正确答案
C.分块只匹配卷积类算子
D.分块会改变算子计算量

答案：B。分块大小受缓存/共享内存容量限制，太大会溢出到慢速存储，性能反而下降。分块不改变计算总量，只改变访存顺序和局部性，也适用于矩阵乘等多种算子。

Q8. AutoTVM与Ansor的核心区别是：

单选题 · hard

A.AutoTVM支持GPU但Ansor不支持
B.AutoTVM需手写模板定义搜索空间← 正确答案
C.Ansor只能用于精简后的小模型
D.两者使用完全相同的调度原语

答案：B。AutoTVM需要开发者通过模板手工定义调优空间，Ansor则通过程序分析自动生成空间和调度候选，省去了人工设计模板的工作量。两者都支持GPU等硬件，都基于TVM调度原语体系。

Q9. 调优空间定义得过大可能导致哪些问题？

多选题 · hard

A.搜索算法收敛速度下降← 正确答案
B.调优所需时长显著增长← 正确答案
C.最优的方案一定被排除
D.搜索器陷入无效探索区域← 正确答案

答案：ABD。空间过大会让搜索范围过大，收敛变慢、耗时增长，大量计算花在无效候选上。但空间大不会排除最优方案——恰恰相反，空间过小才会排除最优。这是“装修方案太多选不过来”而非“方案里没有好方案”。

Q10. 在AutoTVM中，benchmark反馈的作用是：

单选题 · mid

A.将调优空间导出到日志文件
B.为搜索算法提供性能反馈信号← 正确答案
C.自动修改硬件的时钟工作频率
D.替代开发者自动编写调度代码

答案：B。每次搜索尝试得到的参数组合，都会在真实硬件上运行并测量耗时，这个耗时作为反馈信号指导搜索算法更新方向。就像装修施工后客户反馈“主卧太吵”，设计师据此调整方案。