想象你是一家米其林餐厅的大厨。每研发一道新菜，你都要反复试错：盐放 3 克还是 5 克？大火爆炒 40 秒还是 1 分钟？每次摸索出黄金配方，你都会郑重地写进小本子——菜名、灶台类型、火候、调料配比。三个月后，新来的二厨能照着本子复刻你的招牌菜；换了新厨房，你也能凭经验快速适应新灶台。 AI 编译器里的 AutoTune 就是这样一个「大厨」。它的工作是为每个算子（如矩阵乘法）找到最优调度方案（循环怎么分块、向量化怎么配），这个过程要尝试成百上千种配置。TuningRecords 就是 AutoTune 的菜谱本：记录每次调优发现的好配置与实测性能。而「持久化」与「迁移」——把菜谱妥善保存、带它去新厨房——正是这套机制能否发挥威力的关键。

岗位关联

掌握 TuningRecords 的持久化与复用，意味着你不再让 AI 编译器重复造轮子，而是让每次调优经验沉淀为团队的长期资产——这是 AI 编译器工程师从「会调优」走向「系统化调优」的分水岭。

目录
  1. 可视化演示
  2. 记录格式与结构
  3. 持久化存储策略
  4. 记录读写机制
  5. 跨硬件迁移
  6. 记录复用策略
  7. 增量调优机制
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

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

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

记录格式与结构

菜谱要能用，得写清楚「菜名、灶型、火候、配料」。大厨最忌讳只写「盐少许」——别人没法复现，换了自己也记不清。AutoTune 的菜谱本 TuningRecord 也一样，每条记录必须包含四个铁打的项目，少一项，这条经验就失去了复用价值。

这四个项目不是拍脑袋定的，而是从「复用」这个需求反推出来的。AutoTune 每尝试一种调度配置，就会在目标硬件上跑一次测量，得到一条经验。要让这条经验被另一个环境——另一台机器、另一个调优会话——正确读取并利用，身份、场景、做法、结果四要素缺一不可。

在 TVM / Ansor 这类系统中，一条 TuningRecord 由四个字段构成。WorkloadKey 是算子的身份指纹，由算子类型、输入形状、数据类型等哈希得到，相当于菜谱上的「菜名」；Target 是目标硬件标识，相当于「灶台类型」；Config 是调度配置，描述循环如何分块、向量化因子和展开方式，相当于「火候与步骤」；Perf 是实测性能，通常是运行耗时，相当于「出锅时间」。

记录格式统一之后，菜谱本才可能在任意厨房之间流通。WorkloadKey 对得上，菜名一致；Target 对得上，灶台一致；Config 是做法，Perf 是结果。后面要讲的存储、迁移、复用，全都建立在这个四元组之上——格式是地基，地基不正，楼就歪了。

Record=⟨Workloadkey, Target, Config, Perf⟩\text{Record} = \langle \text{Workload}_{key},\ \text{Target},\ \text{Config},\ \text{Perf} \rangle
一条调优记录就是「在什么灶台上、用什么做法、做哪道菜、花了多长时间」的四元组。
  1. 负载标识WorkloadKey 由算子结构与输入形状唯一确定，是记录查找和匹配的主键。
    Workloadkey=Hash(OpType, Shape, DType)\text{Workload}_{key} = \text{Hash}(\text{OpType},\ \text{Shape},\ \text{DType})
  2. 目标硬件Target 记录该配置在哪个硬件上测得，迁移时必须核对。
    Target∈{CPU, GPU, NPU, …}\text{Target} \in \{ \text{CPU},\ \text{GPU},\ \text{NPU},\ \ldots \}
  3. 调度配置Config 是循环变换参数的集合，决定代码生成的具体形态。
    Config=(tile, vectorize, unroll, …)\text{Config} = ( \text{tile},\ \text{vectorize},\ \text{unroll},\ \ldots )
  4. 性能数据Perf 是测量得到的运行时间，越小代表调度越优。
    Perf=min{ t1,t2,…,tk }\text{Perf} = \text{min}\{\, t_1, t_2, \ldots, t_k \,\}

持久化存储策略

菜谱写完不能随手丢在灶台上。大厨的厨房有专门的收纳柜，分类分册，防潮防火。AutoTune 跑一次调优可能产生成千上万条记录，如果只存在内存里，进程一退出就全没了。持久化就是把菜谱本收进柜子——让经验在断电、重启、换机器之后依然存在。

持久化有两个硬指标：第一是不丢，数据要落到磁盘这类非易失介质上；第二是可找，下次调优启动时能快速按 WorkloadKey 和 Target 索引到历史记录。只存不查，等于把菜谱锁进保险柜却把钥匙弄丢了。

实际系统里常见三种形态。JSON/日志文件最直观，一条记录一行，方便调试和人工检查；KV 数据库适合大规模记录，按键查询效率高；带版本管理的记录库则允许同一条目被新记录平滑覆盖。为了避免无限膨胀，还需要去重与淘汰：同一种算子的同一目标硬件只保留一份最优记录，超过容量上限按时间戳或收益淘汰旧条目。

收纳柜分层分区，菜谱才能随手可取。文件型存储像纸质菜谱，简单但翻找慢；数据库像电子检索系统，索引快但需要维护。一条经验如果存了却找不到，等于没有存；如果存了太多废配方，又会拖慢找到真经的速度。持久化的艺术，就是在「存得下」和「找得快」之间找到平衡。

Memstore=∑i=1NdedupSize(ri),Ndedup≪Nraw\text{Mem}_{\text{store}} = \sum_{i=1}^{N_{\text{dedup}}} \text{Size}(r_i), \quad N_{\text{dedup}} \ll N_{\text{raw}}
存储开销等于「去重后」每条记录大小的总和；去重让记录数量远小于原始条数。
  1. 唯一记录集合r_i 是去重后第 i 条唯一的调优记录，重复测量只保留最优。
    ri=dedup(Records)[i]r_i = \text{dedup}(\text{Records})[i]
  2. 单条大小Size 表示序列化后的字节数，由 Config 复杂度和字段数量决定。
    Size(ri)=∣JSON(ri)∣\text{Size}(r_i) = |\text{JSON}(r_i)|
  3. 总容量求和累加所有去重后记录，得到存储总开销。
    Mem=∑iSize(ri)\text{Mem} = \sum_{i} \text{Size}(r_i)
  4. 去重收益N_dedup 远小于 N_raw，因为同 workload 的大量中间尝试会被覆盖。
    Ndedup≪NrawN_{\text{dedup}} \ll N_{\text{raw}}

记录读写机制

大厨每天开工第一件事是「翻菜谱」，收工前要「补配方」。AutoTune 的调优循环也遵循同样的节奏：会话开始时加载历史记录，让搜索从经验出发；每次测量发现更优配置，立刻写回记录库，供后续使用。

读的快慢决定了「启动成本」。假如记录库里有 10 万条历史记录，每次调优启动都要全量扫一遍，还没开始搜索就已经等了半天。写的快慢则决定了「收敛效率」——如果新发现的好配置不能及时落盘，一次崩溃就会丢掉几小时的调优成果。

实际机制分为四层。加载与解析：从文件或数据库逐条读取并重建内存对象，复杂度是线性的 O(N)，N 为记录条数；写入与序列化：新增记录先在内存更新，再异步落盘，避免阻塞搜索主循环；缓存加速：高频访问的 WorkloadKey 放入哈希表，使单条查询达到 O(1)；并发与一致性：多进程同时写文件时必须加锁或采用原子写入，防止记录互相覆盖。

翻得顺手、记不漏字，菜谱本才真正好用。加载慢就像大厨翻一本五千页的厚册子，手都酸了还没翻到要做的菜；缓存层则像把最常做的几道菜贴在灶台边，一抬眼就能看到。而并发写入的锁机制，则确保了多个副厨同时记笔记时，不会你写我擦、把菜谱弄成一团乱麻。

Tload=O(N),Tlookup=O(1)T_{\text{load}} = O(N), \quad T_{\text{lookup}} = O(1)
加载整库是线性扫描，而查询单条记录因缓存的存在可以做到常数时间。
  1. 加载代价每条记录都要解析一次，总耗时随记录数线性增长。
    Tload=∑i=1Ntparse(ri)=O(N)T_{\text{load}} = \sum_{i=1}^{N} t_{\text{parse}}(r_i) = O(N)
  2. 缓存索引WorkloadKey 作为哈希表键，直接映射到记录对象。
    cache[k]→r,k=WorkloadKey\text{cache}[k] \to r, \quad k = \text{WorkloadKey}
  3. 常数查询哈希表平均查找时间不随数据规模增长。
    Tlookup=O(1)T_{\text{lookup}} = O(1)
  4. 原子写入采用「写临时文件 + 重命名」避免半截记录。
    write(ftmp)⇒rename(ftmp, ffinal)\text{write}(f_{\text{tmp}}) \Rightarrow \text{rename}(f_{\text{tmp}},\ f_{\text{final}})

跨硬件迁移

大厨家的煤气灶开大火 3 分钟能烧开锅，新厨房的电磁炉可能要 5 分钟。菜还是那道菜，厨房却不是那个厨房。AutoTune 也面临同样的窘境：在 A100 上花了三天调出的矩阵乘法最优调度，放到 4090 或者 CPU 上，还能不能打？

跨硬件迁移要回答的核心问题是：一条在硬件 A 上产生的 TuningRecord，拿到硬件 B 上还算不算数？答案不是简单的「能」或「不能」，而是取决于两者差异有多大。就像菜谱上写着「大火 40 秒」，换了个火力输出完全不同的灶台，照抄就可能糊锅。

迁移过程分三步。硬件差异分析：比较算力、内存带宽、缓存规模、寄存器数量等架构特征；工作负载匹配：确认 WorkloadKey 完全一致——菜名对不上，后面全是空谈；性能预估：用核心数与主频的比值做一个粗糙折算，估算记录迁移到新硬件后的大致性能。策略上分三种：差异小直接复用；差异中等作为初始点做小范围重搜；差异巨大则放弃记录，从零调优。

好菜谱不会让你盲目照搬，而是提醒你「换灶先试火」。跨硬件迁移的精髓在于：经验值得带走，但必须带着判断力。Warmup 几次测量验证预估是否准确，如果偏差太大就果断放弃，这比抱着旧记录死磕更有价值。

T^new=Told×Coresnew×ClocknewCoresold×Clockold\hat{T}_{\text{new}} = T_{\text{old}} \times \frac{\text{Cores}_{\text{new}} \times \text{Clock}_{\text{new}}}{\text{Cores}_{\text{old}} \times \text{Clock}_{\text{old}}}
新硬件上的预估耗时 ≈ 旧耗时 × 新旧硬件算力之比，算力越强预估时间越短。
  1. 旧环境性能T_old 是记录中存留的实测耗时，代表源硬件上的真实表现。
    Told=Record.PerfT_{\text{old}} = \text{Record.Perf}
  2. 算力粗比Cores × Clock 代表理论峰值算力，是迁移预估的一阶近似。
    Coresnew×ClocknewCoresold×Clockold\frac{\text{Cores}_{\text{new}} \times \text{Clock}_{\text{new}}}{\text{Cores}_{\text{old}} \times \text{Clock}_{\text{old}}}
  3. 线性折算将旧耗时按算力比例放大或缩小，得到新硬件的预估值。
    T^new=Told×α\hat{T}_{\text{new}} = T_{\text{old}} \times \alpha
  4. 二阶修正真实性能还会受带宽、缓存命中率影响，需在估算后做验证。
    Tactual=T^new⋅β, β∈[0.5, 1.5]T_{\text{actual}} = \hat{T}_{\text{new}} \cdot \beta,\ \beta \in [0.5,\ 1.5]

记录复用策略

新厨房里的第一道菜，大厨必然从老菜谱起步，而不是从零发明调味。这就是复用的直觉：站在经验上往前走，永远比从原点出发更快。AutoTune 的搜索过程也一样，与其在巨大的搜索空间里随机碰运气，不如让历史记录先给你指个方向。

复用不是无脑读取，而是一套「精选先用」的策略。就像大厨带了一箱子菜谱，到了新厨房要先翻目录，挑出最适合今天食材和灶台的那几页，而不是把整箱倒在地上慢慢看。

具体环节有四步。筛选与排序：从记录库中挑出 WorkloadKey 相同、Target 匹配的记录，按 Perf 升序取 Top-K；初始配置生成：把这 K 条最优配置注入搜索起点，让调优器从高起点出发；代价模型辅助：历史性能作为先验参与打分，帮助代价模型更早识别有潜力的配置；搜索空间裁剪：将搜索空间中与已验证次优配置相似度过高的区域直接排除，省下算力探索未知区域。

复用不是抄答案，而是用旧笔记给你画了一张新地图。地图帮你避开已知的坑，但不会替你走完路。AutoTune 拿到历史记录后依然要搜索，只是搜索的起点更高、范围更小、判断更准——这正是调优记录最值钱的地方。

S′={ c∈S∣Sim(c, crec)≥θ }\mathcal{S}' = \{\, c \in \mathcal{S} \mid \text{Sim}(c,\ c_{\text{rec}}) \geq \theta \,\}
裁剪后的搜索空间只保留与历史记录相似度不低于阈值 θ 的配置，跳过明显低效的区域。
  1. 原始空间S 是所有合法调度配置组成的全集，规模可能达到亿级。
    S={c1,c2,…,cM}\mathcal{S} = \{ c_1, c_2, \ldots, c_M \}
  2. 相似度函数Sim 衡量候选配置与历史记录配置的结构相似程度。
    Sim(c, crec)=1−∥c−crec∥Dmax⁡\text{Sim}(c,\ c_{\text{rec}}) = 1 - \frac{\| c - c_{\text{rec}} \|}{D_{\max}}
  3. 阈值过滤只保留相似度高于 θ 的配置，形成裁剪子集。
    S′⊆S,∣S′∣≪∣S∣\mathcal{S}' \subseteq \mathcal{S},\quad |\mathcal{S}'| \ll |\mathcal{S}|
  4. 搜索加速搜索空间变小，同等算力下可以尝试更多有希望的配置。
    ∣S∣∣S′∣≈加速比\frac{|\mathcal{S}|}{|\mathcal{S}'|} \approx \text{加速比}

增量调优机制

菜谱是活的：第一版过咸，第二版减盐，第三版加醋，越改越合客人胃口。TuningRecord 也有自己的「版本迭代」。大厨不会因为第一版不满意就撕掉整本菜谱，而是在原有基础上不断修订。AutoTune 的增量调优，正是这种「小步快跑、不断修订」的哲学。

增量调优的设计目标很明确：每次调优都在上次的基础上前进一小步，而不是每次都把地球重新发明一遍。生产环境中的模型和硬件频繁更新，如果每次更新都从零搜索，成本将不可承受。

机制由四条规则驱动。新记录合并：每次调优会话结束后，把新发现的好配置合并入库；多轮迭代优化：下一轮会话从当前最优配置出发做局部探索，而不是全局重搜；最优记录更新：一旦找到耗时更短的配置，立刻替换记录库中的旧最优；收敛加速：随着轮次增加，搜索范围自动收缩，收敛速度越来越快。

最终大厨的经验越积越厚，菜越做越稳——这就是调优记录沉淀的价值。增量调优让 AutoTune 在长期运行中越来越「懂」当前环境的脾气，每多跑一轮，搜索就更有针对性。记录库不再是一堆静态数据，而是一个不断进化的活系统，陪着编译器一起成长。

Pbest(t+1)=min⁡{ p∣p∈Pbest(t)∪Pnew }P_{\text{best}}^{(t+1)} = \min \{\, p \mid p \in P_{\text{best}}^{(t)} \cup P_{\text{new}} \,\}
下一轮的最优集合，等于上一轮最优点和新发现点取最小值的结果——经验只增不减。
  1. 当前最优P_best^{(t)} 是第 t 轮结束时已知的最优配置集合。
    Pbest(t)={p1∗,p2∗,…}P_{\text{best}}^{(t)} = \{ p_1^*, p_2^*, \ldots \}
  2. 新候选点P_new 是本轮搜索新产生的配置点。
    Pnew={p∣Perf(p)<Perfcur}P_{\text{new}} = \{ p \mid \text{Perf}(p) < \text{Perf}_{\text{cur}} \}
  3. 集合合并将新旧候选取并集，保留全部可能的最佳点。
    Pbest(t)∪PnewP_{\text{best}}^{(t)} \cup P_{\text{new}}
  4. 取最小值min 表示从合并集中挑选耗时最短的配置，作为下一轮的起点。
    Pbest(t+1)=min⁡(⋅)P_{\text{best}}^{(t+1)} = \min(\cdot)

AI 应用场景

云服务商的多硬件部署

阶段：部署优化

解决的问题：传统方式下，每上一个新模型、换一批 GPU 实例，都要从零开始算子调优，消耗大量 GPU 机时。AutoTune 的 TuningRecords 让历史经验可在同一系列硬件间复用，就像大厨的菜谱本跟着他去了新厨房。

具体案例：某推理服务商在 A100 上完成了 ResNet-50 全部算子的调优，积累了 3000 条记录。当客户新增一批 T4 实例时，平台直接加载 A100 的调优记录作为初始配置，仅花费原来 20% 的调优时间就达到了同等推理性能。

CI/CD 流水线的持续集成调优

阶段：持续集成与自动化测试

解决的问题：代码频繁更新导致每次 CI 构建都要重跑调优，耗时过长。通过增量调优，把每次构建产生的新记录合并回记录库，下一次构建自动站在上次的肩膀上。

具体案例：一家 AI 芯片公司把 AutoTune 接入 CI 流水线，每次提交代码后自动触发算子调优，并把更优的记录写回版本仓库。三个月后，调优时间从平均 40 分钟降到 12 分钟，收敛速度显著提升。

边缘设备的快速适配

阶段：端侧部署

解决的问题：手机 NPU、嵌入式芯片型号繁杂，逐个调优成本极高。利用跨硬件迁移策略，把云端调优记录迁移到边缘设备，配合少量本地搜索即可完成适配。

具体案例：某智能摄像头厂商在云端 GPU 上调优好的目标检测模型算子，通过迁移预估筛选出可用记录，再在端侧 NPU 上做 50 轮小范围搜索，将原本需要 3 小时的调优压缩到 20 分钟。

Python 演示

python126 行
import jsonimport random  class Workload:    def __init__(self, op_type, shape, dtype="float32"):        self.op_type = op_type        self.shape = shape        self.dtype = dtype     def key(self):        return "{}:{}-{}".format(self.op_type, self.shape, self.dtype)  class TuningRecord:    def __init__(self, workload_key, target, config, time_ms):        self.workload_key = workload_key        self.target = target        self.config = config        self.time_ms = time_ms     def to_dict(self):        return {            "workload_key": self.workload_key,            "target": self.target,            "config": self.config,            "time_ms": self.time_ms,        }  class TuningRecordStore:    def __init__(self, path=None):        self.path = path        self.records = []        self._cache = {}        if path:            self.load(path)     def load(self, path):        try:            with open(path, "r") as f:                data = json.load(f)        except FileNotFoundError:            data = []        self.records = [            TuningRecord(d["workload_key"], d["target"], d["config"], d["time_ms"])            for d in data        ]        for r in self.records:            self._cache[self._cache_key(r.workload_key, r.target)] = r     def save(self, path=None):        path = path or self.path        with open(path, "w") as f:            json.dump([r.to_dict() for r in self.records], f, indent=2)     def _cache_key(self, wk, target):        return "{}@{}".format(wk, target)     def add_record(self, record):        key = self._cache_key(record.workload_key, record.target)        if key in self._cache:            if self._cache[key].time_ms <= record.time_ms:                return False        self._cache[key] = record        self.records.append(record)        return True     def lookup(self, workload_key, target):        return self._cache.get(self._cache_key(workload_key, target))     def filter_records(self, op_type=None, target=None, top_k=5):        matched = []        for r in self.records:            if target and r.target != target:                continue            if op_type and not r.workload_key.startswith(op_type):                continue            matched.append(r)        matched.sort(key=lambda r: r.time_ms)        return matched[:top_k]  def simulate_measure(config, workload, target):    base = workload.shape[0] * workload.shape[1] / 2000.0    perf = base + config["tile"] * 0.05 + (0.3 if config["unroll"] > 4 else 1.0)    if target == "cuda":        perf *= 0.3    elif target == "cpu":        perf *= 1.2    return round(perf + random.uniform(0, 0.2), 3)  def run_tuning(store, workload, target, n_trials=30):    best = None    for _ in range(n_trials):        config = {            "tile": random.choice([4, 8, 16, 32]),            "unroll": random.choice([1, 2, 4, 8]),        }        time_ms = simulate_measure(config, workload, target)        rec = TuningRecord(workload.key(), target, config, time_ms)        if best is None or time_ms < best.time_ms:            best = rec        store.add_record(rec)    return best  def main():    store = TuningRecordStore("records.json")    w1 = Workload("matmul", [512, 512])    store.add_record(TuningRecord(w1.key(), "cuda", {"tile": 16, "unroll": 4}, 12.5))    print("initial store size:", len(store.records))    old = store.lookup(w1.key(), "cuda")    print("lookup cuda record:", old.time_ms, "ms")    best_cpu = run_tuning(store, w1, "cpu", n_trials=30)    print("best cpu time:", best_cpu.time_ms, "ms")    store.save()    loaded = TuningRecordStore("records.json")    print("reload size:", len(loaded.records))    reused = loaded.filter_records(op_type="matmul", target="cpu", top_k=3)    print("reuse candidates:", [r.time_ms for r in reused])  if __name__ == "__main__":    main()
目的：模拟一个极简的 TuningRecord 持久化与复用系统，展示记录写入、加载、跨硬件查找和复用候选筛选的完整流程。
  1. class TuningRecord定义菜谱的「四元组」：负载标识、目标硬件、调度配置、实测耗时。
  2. store.add_record(rec)新配方入库前先查缓存，旧记录更优则拒绝写入，实现去重。
  3. store.lookup(w1.key(), "cuda")通过哈希缓存 O(1) 查出 GPU 上的历史最优记录。
  4. run_tuning(store, w1, "cpu", n_trials=30)在 CPU 上重新调优，同时把每次测量结果增量写入记录库。
  5. loaded.filter_records(op_type="matmul", target="cpu", top_k=3)模拟迁移复用：按算子类型和目标硬件筛选 Top-3 记录作为初始配置候选。
  6. store.save()将内存中的全部记录序列化为 JSON 文件，实现断电不丢。

常见误区

误区在 A100 上调优好的 TuningRecords，直接复制到 4090 上就能用，反正都是 NVIDIA 显卡，架构差不多。

正解硬件差异（SM 数量、显存带宽、寄存器文件大小）会直接改变最优调度。就像煤气灶和电磁炉虽然都叫「灶」，火候曲线完全不同。正确做法是先匹配 WorkloadKey，再用性能模型预估，最后决定直接复用还是作为初始点重新搜索。

为何常见：大家习惯把同一厂商的 GPU 当作等价设备，忽视了架构代际差异和硬件配置差异对调度效果的深远影响。

误区调优产生的每条记录都应该永久保存，方便以后参考，反正磁盘便宜。

正解记录膨胀会拖垮加载和查询效率。就像菜谱本被 5000 张废配方塞满，真到用时翻半天也找不到有用信息。正确做法是定期去重、只保留每条目的最优记录，并设置容量上限，超限后按时间戳或收益淘汰。

为何常见：只看到「多存一份没坏处」，忽视了记录数量与检索效率之间的权衡——存的成本低，找的成本却很高。

误区加载了 TuningRecords 后，AutoTune 应该直接采用历史配置，不需要再跑搜索，这样最快。

正解记录是「起点」不是「终点」。硬件差异、算子上下文变化都可能让历史最优失效。增量调优的价值恰恰在于：记录给了好的先验，仍需少量搜索来验证或超越。直接照搬就像拿三个月前的菜谱在完全不同的灶台上盲做，翻车风险极高。

为何常见：把「经验」和「事实」混为一谈——经验需要在新环境中验证，而不是无条件信任。

面试题

Q1. AutoTune 的 TuningRecord 中，负责唯一识别算子「身份」的字段是？

单选题 · easy

  • A.负载标识← 正确答案
  • B.硬件型号
  • C.调度配置
  • D.运行耗时

答案：A。负载标识（WorkloadKey）由算子类型与输入形状唯一生成，相当于菜谱的「菜名」。硬件型号、调度配置、运行耗时都只是记录的其他属性，不能唯一区分不同算子。

Q2. TuningRecords 持久化时，最常用的文本文件格式是？

单选题 · easy

  • A.JSON 文本← 正确答案
  • B.WAV 音频
  • C.PNG 图片
  • D.AVI 视频

答案：A。JSON 轻量、可读、易于结构化存储，适合保存调优记录；WAV、PNG、AVI 分别是音频、图像和视频的多媒体格式，无法表达调度配置和性能数据。

Q3. 跨硬件迁移调优记录时，第一步应该做什么？

单选题 · mid

  • A.直接复用全部记录
  • B.匹配工作负载← 正确答案
  • C.删除历史记录
  • D.重装编译工具

答案：B。必须先确认 WorkloadKey 完全一致——菜名对不上，后面全是空谈。直接复用跳过了验证步骤，就像换灶台却不试火，很容易翻车；删除记录和重装工具更是南辕北辙。

Q4. 增量调优中「最优记录更新」的正确含义是？

单选题 · mid

  • A.删掉所有旧记录
  • B.更好配置替换旧记录← 正确答案
  • C.保持第一次记录
  • D.随机挑选一条记录

答案：B。增量调优的核心是「旧的不去、新的更好才替换」：当新配置的实测耗时短于旧记录时，才更新最优记录。删除全部记录会丢失历史经验，保持第一次记录则无法进步。

Q5. 记录复用可以为新一轮调优带来哪些帮助？

多选题 · mid

  • A.提供初始配置← 正确答案
  • B.辅助代价模型← 正确答案
  • C.消除测量误差
  • D.裁剪搜索空间← 正确答案

答案：ABD。历史记录可注入搜索起点、充当代价模型先验、裁剪低效搜索区域。但无论多少记录都无法消除真实测量的随机误差，测量误差只能靠重复测量来降低。

Q6. 内存缓存层在记录读写中主要作用是？

单选题 · easy

  • A.加速记录查找← 正确答案
  • B.加快磁盘写入
  • C.增大搜索空间
  • D.降低编译温度

答案：A。缓存将常用记录放入哈希表，使单条查询达到 O(1)，就像把常用菜谱贴在灶台边。它不改变磁盘写入速度、不参与搜索空间调整，更与「编译温度」无关。

Q7. 对调优记录做去重处理，主要是为了防止？

单选题 · mid

  • A.存储空间膨胀← 正确答案
  • B.模型精度下降
  • C.编译错误增多
  • D.网络带宽不足

答案：A。同一条目的重复测量会产生大量近似记录，不去重会导致存储膨胀、加载变慢。去重不改变模型精度、不产生编译错误，也与网络带宽没有直接关系。

Q8. 迁移性能预估时，最常用的硬件参照量是？

单选题 · hard

  • A.算力核心指标← 正确答案
  • B.源代码行数
  • C.变量命名长度
  • D.注释数量占比

答案：A。核心数与主频乘积近似理论算力，是迁移预估的一阶参照。源代码行数、变量命名、注释占比都与硬件性能无关，无法用于估算迁移后的运行时间。

Q9. 搜索空间裁剪时，可以依据哪些信息？

多选题 · hard

  • A.历史最优相似度← 正确答案
  • B.记录性能排序← 正确答案
  • C.随机均匀猜测
  • D.目标硬件特征← 正确答案

答案：ABD。裁剪依赖「历史最优相似度」排除次优区域、用「记录性能排序」聚焦高潜力配置、参考「目标硬件特征」判断哪些配置适用。随机猜测没有信息量，不能作为裁剪依据。

Q10. 多进程并发写入调优记录时，正确的做法是？

多选题 · extreme

  • A.使用文件锁保护← 正确答案
  • B.原子性方式写入← 正确答案
  • C.无控制直接写
  • D.忽略记录丢失

答案：AB。并发写入必须用文件锁或原子写（写临时文件再重命名）保证记录一致性，否则多个进程互相覆盖会产生半截记录。无控制直接写和忽略记录丢失都会导致菜谱被撕烂，是不可接受的工程实践。