假设你家小区门口有一家便利店，老板老陈不需要每天都去城郊总仓取货，因为店里的小货架上已经摆好了住户们最常买的东西。菜场王阿姨每周五都来买两盒鲜奶，老陈周四晚上就把鲜奶从总仓运到冰柜——这样王阿姨进门一伸手就能拿到。这套“就近货架 + 提前备货”的生意经，正是边缘 AI 推理中边缘缓存与预加载要做的事。设备产生的推理请求如果每次都跑到云端，就像顾客每次买东西都跑到城郊总仓，来回几公里，路径长、时延大。边缘缓存把高价值的模型和计算结果留在设备旁边，预加载则根据历史规律提前把“可能要用”的东西搬近一点。本文用老陈的便利店做比喻，逐层拆解缓存基本原理、淘汰策略、模型版本管理、预测性预加载、多模型切换优化，以及命中率监控调优。

岗位关联

掌握边缘缓存与预加载，是边缘 AI 工程师降低推理延迟、节省带宽成本的重要技能，也是从“会调 API”走向“懂边缘体系”的关键一步。

目录
  1. 可视化演示
  2. 缓存基本原理
  3. 缓存淘汰策略
  4. 模型版本管理
  5. 预测性预加载
  6. 多模型切换优化
  7. 命中率监控调优
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

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

缓存基本原理

便利店老板老陈的货架只有几平米，却能让顾客不用跑城郊总仓，这就是缓存最朴素的价值。边缘 AI 推理里的缓存，是把模型文件、中间特征或推理结果，复制一份放到离设备更近的边缘节点上。这里的关键是“复制”而不是“搬走”：云端总仓的数据仍然保留，边缘只保存一份高频使用的副本。

缓存为什么能显著加速？因为网络传输的代价比本地读取高得多。摄像头每帧推理都要向云端下载模型，一遍遍地通过公网传输，就像顾客每天都去城郊总仓买一瓶酱油，时间和油费都浪费在路上了。在边缘节点缓存一份常用模型后，推理请求直接在本地命中，带宽消耗和时延都被大幅压缩。缓存通常放在三个位置：设备本机、边缘网关、区域推理服务器。越靠近设备速度越快，容量越小；越靠近云端容量越大，但延迟也越高。

用数学语言来描述“省了多少钱”，需要看平均延迟：

所以老陈的目标很简单：尽量让顾客进门就能拿到货，而不是经常告诉他“今天没货，我去总仓帮你取”。对边缘 AI 工程师来说，缓存设计的本质，就是把这个公式里的 $h$ 尽量抬高，同时控制 $L_{\text{cache}}$ 不要因为缓存本身过大而变慢。

Lavg=h×Lcache+(1−h)×Lcloud\displaystyle L_{\text{avg}} = h \times L_{\text{cache}} + (1 - h) \times L_{\text{cloud}}
平均延迟由命中率、本地命中延迟和云端回源延迟共同决定。命中率越高，平均延迟越接近本地延迟。
  1. 命中率 $h$表示所有请求中能直接在缓存里找到结果的比例，取值范围是 0 到 1。
    hh
  2. 缓存命中延迟 $L_{\text{cache}}$请求在本地缓存中找到资源所花费的时间，这笔时间很短。
    LcacheL_{\text{cache}}
  3. 未命中率 $1 - h$命中率之外的部分，也就是需要回云端取数据的请求比例。
    1−h1 - h
  4. 云端回源延迟 $L_{\text{cloud}}$请求跨越网络去云端获取资源的时间，通常是本地延迟的几十倍。
    LcloudL_{\text{cloud}}

缓存淘汰策略

货架空间有限，老陈不可能把总仓的所有商品都摆上来。每周盘点时，他都要把滞销品撤下，为新品腾地方。缓存淘汰策略解决的就是“货架满了，谁先下架”的问题。

不同策略对应不同的“老陈”性格。LRU（最近最少使用）像一位只看“最近”的老陈：被顾客翻过的东西往后放，最久没被碰过的摆最前面，下架时从最前面拿走。LFU（最不经常使用）则像一位记着“历史销量”的老陈：总销量最差的商品先撤。FIFO 像“先来后到”的排队，谁先进货谁先下架，完全不管卖得怎么样。TTL 则像保质期：即使商品还在货架上，只要过期了就必须清除，避免把旧数据当成新鲜数据用。

实际边缘节点往往不是只用一种策略，而是把多种因素合成一个“淘汰分”。给每个缓存对象打分，分高的优先淘汰：

老陈的货架没有“永远正确”的摆放规则，只有“适应当前小区住户”的规则。换了一批住户，就要调整权重。边缘缓存也一样，淘汰策略必须根据业务请求模式动态调参，而不是写完 LRU 就一劳永逸。

score(k)=w1⋅(t−tlast(k))+w2⋅1f(k)+w3⋅age(k)TTL(k)\displaystyle \text{score}(k) = w_1 \cdot \left(t - t_{\text{last}}(k)\right) + w_2 \cdot \frac{1}{f(k)} + w_3 \cdot \frac{\text{age}(k)}{\text{TTL}(k)}
这是一个加权评分公式：越久没被访问、历史访问次数越少、越接近过期的数据，淘汰分越高，越容易被请出货架。
  1. 最近未使用时长 $t - t_{\text{last}}(k)$当前时间与对象最后一次被访问的时间之差，间隔越长，越该淘汰。
    t−tlast(k)t - t_{\text{last}}(k)
  2. 访问频率倒数 $\frac{1}{f(k)}$对象被访问的总次数 $f(k)$ 越少，倒数越大，说明它越冷门。
    1f(k)\frac{1}{f(k)}
  3. 有效期占比 $\frac{\text{age}(k)}{\text{TTL}(k)}$对象已经过了多大比例的生命周期，越接近 1 越危险。
    age(k)TTL(k)\frac{\text{age}(k)}{\text{TTL}(k)}
  4. 三个权重 $w_1, w_2, w_3$分别控制“最近性”“频次”和“过期风险”在最终决策中的分量。
    w1,w2,w3w_1, w_2, w_3

模型版本管理

同一款薯片换了新包装，老陈不会立刻把旧包装全扔掉——万一新包装不受欢迎，顾客依然要买旧包装。模型版本管理在边缘缓存中做的事，与此非常相似。

云端训练好的模型会不断更新，每次更新都产生一个新版本。边缘缓存如果直接把旧版本覆盖掉，一旦新模型效果变差，线上设备就失去了回退能力。正确做法是：新旧版本在缓存中隔离共存，新版本先在小流量灰度环境中试运行，确认稳定后再把大部分请求切过去；如果新版本异常，则立刻切回旧版本。因此，缓存项不能只叫“车牌识别模型”，而必须带有精确的版本标识。

版本标识通常由模型内容本身生成，而不是简单用“v1、v2”这种顺序号，否则两个不同训练任务可能被误认为是同一版本。常见的做法是对模型权重和配置文件计算哈希：

老陈把新旧包装摆在货架的两个不同位置，每种包装有自己的进货记录，这就是“版本隔离”。边缘节点用哈希指纹区分不同模型文件，再结合灰度发布和快速回滚机制，才能既享受模型迭代的收益，又不承担“一刀切”的风险。

version_id=SHA256(weights∥config)\displaystyle \text{version\_id} = \text{SHA256}\left(\text{weights} \parallel \text{config}\right)
把模型权重和配置文件的字节拼接起来，再做 SHA256 哈希，得到一个几乎不会重复的版本指纹。
  1. 权重参数 $\text{weights}$模型学习到的全部参数，直接决定了模型行为，是版本标识最重要的输入。
    weights\text{weights}
  2. 配置文件 $\text{config}$模型结构、输入输出格式、推理精度等配置，与权重一起参与哈希计算。
    config\text{config}
  3. 拼接符 $\parallel$表示把权重和配置的原始字节按顺序拼在一起，形成统一输入。
    ∥\parallel
  4. SHA256 哈希把拼接后的内容映射成固定长度的数字指纹，内容一改，指纹就完全不同。
    SHA256(⋅)\text{SHA256}(\cdot)

预测性预加载

王阿姨每周五买鲜奶，老陈周四晚上就把鲜奶从总仓运到便利店冰柜。等王阿姨进门时，鲜奶已经在手边了。这不是运气，而是预测性预加载。

在边缘 AI 推理中，设备发出的请求常常有很强的时序规律。一个工位识别完零件类型后，大概率下一步要做缺陷检测；一辆车通过路口后，下一路口可能要重新做人脸识别。边缘节点可以记录这些请求转移规律，训练一张轻量的“下一步可能请求哪个模型”的概率表。当概率超过阈值时，系统提前把目标模型从云端拉到本地缓存。

预加载不是越早越多越好，而是要算一笔账。它会占用带宽和缓存空间，如果预取的东西最终没被使用，就是白白浪费。只有“预测收益”大于“预取成本”时才值得做：

老陈不会把总仓所有商品都搬来，只会预判“最可能被买走的那几样”。边缘预加载同样讲究精准：在带宽空闲时段、低峰期执行预热，同时为关键业务预留带宽预算，才能让预加载成为“雪中送炭”，而不是“火上浇油”。

Prefetch(k)  ⟺  Pr⁡(k∣context)>θ\displaystyle \text{Prefetch}(k) \iff \Pr(k \mid \text{context}) > \theta
当已知当前上下文时，模型 k 被请求的概率超过阈值 θ，系统才执行预加载。
  1. 模型 $k$ 被请求的概率 $\Pr(k \mid \text{context})$在给定当前设备状态、时间、业务阶段等上下文条件下，模型 k 出现的条件概率。
    Pr⁡(k∣context)\Pr(k \mid \text{context})
  2. 上下文 $\text{context}$包括设备位置、时间、上一轮推理结果、业务线类型等信号。
    context\text{context}
  3. 预加载条件 $\text{Prefetch}(k)$当条件概率高于阈值时，执行预取动作。
    Prefetch(k)\text{Prefetch}(k)
  4. 阈值 $\theta$由带宽预算和缓存空间共同决定，阈值越高，预取越保守。
    θ\theta

多模型切换优化

一个路口往往同时运行车牌识别、车型分类、违章检测等多个模型，就像便利店同时服务小区、写字楼和学校三拨客人。如果每个客群都独占一个货架，空间很快就不够用；如果大家抢同一个货架，高峰期又容易互相踢掉对方的必需品。

多模型切换优化的核心，是把“每个模型一个独立缓存区”改为“一个共享缓存池”。共享池按请求热度动态分配空间：热点模型常驻，冷门模型只在被预测到即将使用前临时入驻。切换模型时，系统优先淘汰“最久未用且业务优先级最低”的模型，而不是简单清空整个缓存。这样即使模型 A 被模型 B 替换，A 的高频依赖数据也可能被保留一小部分。

切换后的整体效果，用加权命中率来衡量。每个模型的重要性不一样，不能把不同模型的命中率直接求平均，而应按请求占比加权：

老陈的货架虽然没有固定隔间，但他心里有数：鲜奶天天卖、蜂蜜偶尔卖，位置自然动态调整。边缘缓存在多模型场景下越灵活，切换时就越少出现“刚换了模型，老模型的热数据就被浪费”的尴尬。

Heff=∑i=1nwi⋅hi∑i=1nwi\displaystyle H_{\text{eff}} = \frac{\sum_{i=1}^{n} w_i \cdot h_i}{\sum_{i=1}^{n} w_i}
加权有效命中率等于每个模型命中率乘以其权重后的总和，除以总权重。
  1. 模型权重 $w_i$表示模型 i 在总业务中的请求占比或优先级，权重越大，它的命中率越重要。
    wiw_i
  2. 单模型命中率 $h_i$模型 i 在缓存中的本地命中比例。
    hih_i
  3. 加权分子 $\sum_{i=1}^{n} w_i \cdot h_i$把每个模型的命中率按权重累加，得到总体命中质量。
    ∑i=1nwi⋅hi\sum_{i=1}^{n} w_i \cdot h_i
  4. 总权重 $\sum_{i=1}^{n} w_i$所有权重之和，用于归一化，避免模型数量影响结果。
    ∑i=1nwi\sum_{i=1}^{n} w_i

命中率监控调优

老陈每天打烊后都会看销售日报：哪些商品压货、哪些商品经常断货，下一周该多进什么。边缘缓存同样需要一套监控和调优闭环，不能只靠上线时拍脑袋设置容量和策略。

最重要的指标是命中率，也就是请求在本地找到资源的比例。命中率不是越高越好，还要结合空间利用率一起看。假设货架被一大堆没人买的超大尺寸商品塞满，空间利用率很高，但命中率很低，说明该淘汰的商品没被淘汰；如果命中率很高，空间利用率却很低，说明货架太大或缓存对象太小，还有压缩成本的空间。边缘节点通常还需要记录淘汰次数、预加载误判率、单模型命中率等日志，当指标异常时触发告警。

一个综合性的缓存价值指标，可以把“命中率”和“空间”统一起来：

老陈通过销售日报不断调整进货清单，边缘缓存也通过指标监控形成调优闭环：先采集命中率、空间利用率、淘汰次数等数据，再定位瓶颈，调整淘汰策略或预加载概率阈值，最后上线新参数并继续观察。缓存不是一次性搭建完就结束的静态系统，而是一个需要持续经营的“便利店”。

value=h×R×SavgCoccupied\displaystyle \text{value} = \frac{h \times R \times S_{\text{avg}}}{C_{\text{occupied}}}
缓存价值等于命中率、请求总数和平均节省延迟的乘积，除以当前占用的存储空间，衡量的是“单位空间换来的延迟收益”。
  1. 命中率 $h$请求在本地命中的比例。
    hh
  2. 总请求数 $R$统计周期内到达该边缘节点的推理请求总数。
    RR
  3. 平均节省延迟 $S_{\text{avg}}$每一次命中平均比回源节省的毫秒数。
    SavgS_{\text{avg}}
  4. 占用空间 $C_{\text{occupied}}$缓存当前实际占用的存储或内存大小。
    CoccupiedC_{\text{occupied}}

AI 应用场景

工业视觉质检：工位模型预加载

阶段：边缘推理加速阶段

解决的问题：一条生产线有多个工位，每个工位需要不同的缺陷检测模型。传统做法让每个工位都从云端拉取模型，换产线时模型加载等待时间长。AI 缓存可以根据排产计划提前把下一工位要用的模型预热到边缘节点，切换产线时几乎无缝衔接。

具体案例：某手机外壳工厂有 6 个质检工位，分别检测划痕、色差、螺钉缺失等。边缘服务器缓存当前工位模型，同时根据 PLC 信号预加载下一工位模型，模型切换耗时从 8 秒降到 200 毫秒。

车联网路侧单元：地图与模型协同缓存

阶段：端云协同推理阶段

解决的问题：路侧单元（RSU）需要在车辆经过时快速识别车牌、车型和危险行为。若每个模型都从云端下载，车辆经过的几十毫秒窗口根本来不及。使用边缘缓存把高频模型长期驻留，再结合车辆位置预测预加载下一路口的高精地图切片，可以显著降低端到端延迟。

具体案例：某智慧路口部署 RSU，缓存 3 个核心识别模型，并依据红绿灯周期预加载“行人意图预测”模型，高峰时段平均识别延迟从 180ms 降至 85ms。

智能摄像头：分时段模型调度

阶段：模型部署与运维阶段

解决的问题：小区摄像头白天以车牌识别和车辆违停检测为主，夜间以人形检测和周界告警为主。传统方案一次性加载全部模型，内存爆满且命中率低。边缘缓存结合时段预测，将当前时段模型常驻、下一时段模型提前预热，并按命中率监控动态调整模型驻留名单。

具体案例：某智慧园区 32 路摄像头共用一台边缘网关，启用分时段预加载后，模型平均加载时间降低 65%，周界告警响应速度提升一倍。

Python 演示

python49 行
from collections import OrderedDict class EdgeCache:    def __init__(self, capacity):        self.capacity = capacity        self.store = OrderedDict()        self.hit_count = 0        self.miss_count = 0     def get(self, key):        if key in self.store:            item = self.store.pop(key)            self.store[key] = item            self.hit_count += 1            return item        self.miss_count += 1        return None     def put(self, key, value):        if key in self.store:            del self.store[key]        elif len(self.store) >= self.capacity:            old_key, _ = self.store.popitem(last=False)        self.store[key] = value     def prefetch(self, keys, loader):        for key in keys:            if key not in self.store:                print("prefetch", key)                self.put(key, loader(key))     def hit_rate(self):        total = self.hit_count + self.miss_count        return self.hit_count / total if total else 0.0 def remote_load(model_name):    return {"model": model_name, "version": 1} def main():    cache = EdgeCache(3)    requests = ["a", "b", "a", "c", "b", "d", "a", "b", "c"]    for req in requests:        if cache.get(req) is None:            cache.put(req, remote_load(req))    cache.prefetch(["c", "d"], remote_load)    print("hit_rate", round(cache.hit_rate(), 2)) if __name__ == "__main__":    main()
目的：用 OrderedDict 实现一个带 LRU 淘汰和预测性预加载的边缘缓存，并统计请求命中率。
  1. self.store = OrderedDict()有序字典用来记录键的访问顺序，实现 LRU 的核心数据结构。
  2. item = self.store.pop(key)先从字典中取出并删除键，再重新插入，模拟“最近被访问过”的刷新动作。
  3. old_key, _ = self.store.popitem(last=False)缓存满时从字典头部弹出最久未使用的键。
  4. cache.get(req) is None请求未命中时，调用云端加载函数把模型放进缓存。
  5. cache.prefetch(["c", "d"], remote_load)根据预测逻辑，提前把接下来可能用到的模型写入缓存。

常见误区

误区既然缓存能减少延迟，那把边缘节点的存储堆到最大，把云端所有模型都缓存下来，命中率自然就高了。

正解缓存容量不是越大越好。首先，边缘节点存储容量有限且成本不低；其次，缓存对象数量增多后，查找和维护的开销也会上升；最后，大的缓存可能把大量低频大模型塞进来，挤占高频小模型的空间。正确的做法是像老陈只租一个小货架，用淘汰策略和命中率监控决定该进什么货。

为何常见：人们容易把性能问题简单归因于“容量不够”，忽略了缓存的核心是“把有限空间花在最值得保留的数据上”。

误区网上都说 LRU 最经典，那我直接所有项目都用 LRU，总不会有错。

正解LRU 适合访问模式有较强局部性的场景，比如反复请求同一批模型。但如果数据是“一次性读取”或“强时效性”的，LRU 可能把刚读过的过期数据留在缓存里。LFU 适合高频重复但低频数据绝不重复的场景，TTL 则适合时效性敏感的数据。真实系统往往要结合多种策略。

为何常见：很多初学者只学过 LRU，遇到淘汰问题就会条件反射地套用，很少分析请求模式的差异。

误区既然预加载能提速，那就系统启动时把所有模型都拉到边缘，反正早晚会用。

正解预加载会占用带宽、存储和云端的下载能力。如果预测不准，预加载的模型不仅占着货架，还挤掉真正要用的热点模型。只有条件概率超过阈值且收益大于成本时才值得做，并要为关键业务保留可用带宽。

为何常见：这是一种“防御性心理”，总担心万一用到某个模型，于是把所有可能都塞进缓存，却没意识到预加载本身也有代价。

误区云端模型更新后，直接把边缘缓存里的旧模型删掉，换上新的不就行了？

正解如果新模型在真实边缘设备上运行效果不佳，甚至出现崩溃，直接覆盖会让系统失去兜底能力。正确的做法是版本隔离、灰度发布和快速回滚，让新旧版本在缓存中共存一段时间，确认新版本稳定后再切换流量。

为何常见：默认新版本一定比旧版本好，忽略了边缘环境复杂、模型可能过拟合等风险。

误区调优边缘缓存的目标就是拼命把命中率刷到接近 100%，这样系统一定最快。

正解命中率只是中间指标，最终目标是降低延迟并节省带宽。为了把命中率从 95% 抬到 99%，可能需要缓存一大堆低频大模型，空间利用率下降，甚至拖慢缓存查找速度。应该在存储、带宽和业务优先级的约束下，用“单位空间换来的延迟收益”来评估缓存价值。

为何常见：单一指标导向很容易让人忘记业务目标，以为指标好看就等于系统高效。

面试题

Q1. 边缘缓存的主要作用是什么？

单选题 · easy

  • A.替代云端进行模型训练
  • B.减少推理链路上的重复传输← 正确答案
  • C.增大神经网络的参数量
  • D.强制所有请求都走云端

答案：B。边缘缓存把常用模型和结果放在设备附近，避免每次都跨网络回源，从而减少重复传输。训练仍然在云端或专用设备完成，缓存不替代训练，也不会增加参数量，更不会强制请求走云端。

Q2. LRU 淘汰策略主要依据什么？

单选题 · easy

  • A.数据被插入时间的先后
  • B.数据被访问的总次数最少
  • C.数据最近访问时间最远← 正确答案
  • D.数据文件大小排名靠前

答案：C。LRU 全称 Least Recently Used，优先淘汰“最近最久没有使用”的数据。插入时间先后是 FIFO，访问次数最少是 LFU，文件大小通常不是 LRU 的决策依据。

Q3. TTL 在边缘缓存中表示什么？

单选题 · easy

  • A.数据允许在缓存里的存活时间← 正确答案
  • B.网络请求连接的超时时间
  • C.模型单次推理的时间上限
  • D.定时清理缓存的时间间隔

答案：A。TTL（Time To Live）表示缓存数据只能在有效期内被使用，避免过期数据被当作新鲜结果。它不等于网络超时、推理耗时或清理周期。

Q4. 模型版本管理为什么需要版本隔离？

单选题 · mid

  • A.防止新旧参数互相覆盖引发线上异常← 正确答案
  • B.减少模型文件占用的磁盘空间
  • C.提升模型推理时的每秒帧数
  • D.扩大模型支持的图像输入格式

答案：A。版本隔离的核心是让新旧模型在缓存中互不干扰，新模型灰度验证失败时可以回滚旧模型。它不会减少磁盘空间，也不会直接提升推理帧率或输入格式兼容性。

Q5. 预测性预加载能够生效的前提是什么？

单选题 · mid

  • A.请求模式可预测且收益大于成本← 正确答案
  • B.模型权重必须小于十兆字节
  • C.边缘节点必须支持五G网络
  • D.云端必须关闭本地缓存功能

答案：A。预加载的本质是用历史规律预测未来请求，因此请求必须有模式；同时预取消耗带宽和存储，必须保证收益大于成本。模型大小、网络制式、云端是否缓存都不是必要条件。

Q6. 多模型切换时，以下哪些缓存优化手段是合理的？

多选题 · mid

  • A.统一共享缓存池灵活分配空间← 正确答案
  • B.每个模型固定平均分得独立区
  • C.热点常驻冷门动态按需预热← 正确答案
  • D.每次切换前清空缓存防冲突

答案：AC。共享缓存池能让高频模型获得更多空间，热点模型常驻、冷门模型动态预热也是高效做法。固定平均分配浪费空间，每次切换前清空缓存会让命中率暴跌，因此 B 和 D 不正确。

Q7. 缓存命中率的正确计算方式是？

单选题 · mid

  • A.命中次数除以总请求次数← 正确答案
  • B.未命中次数乘以总请求次数
  • C.缓存容量除以模型文件大小
  • D.命中次数乘以缓存容量

答案：A。命中率 = 命中次数 ÷（命中次数 + 未命中次数）= 命中次数 ÷ 总请求次数，用来衡量请求在本地被满足的比例。

Q8. 缓存空间利用率高但命中率低，最可能的原因是什么？

单选题 · hard

  • A.缓存里堆了大量低频大模型← 正确答案
  • B.缓存容量设置过小导致抖动
  • C.请求频率峰值极高导致排队
  • D.预加载只在空闲时段执行

答案：A。空间被大量低频大模型占满，说明资源用在了错误对象上，命中率自然低。容量过小会导致空间利用率低而不是高；请求排队和预加载时段与命中率低的关系较弱。

Q9. 关于边缘缓存中的模型版本管理，正确做法包括哪些？

多选题 · hard

  • A.新旧版本并行缓存灰度切流← 正确答案
  • B.异常时快速回滚到旧版本← 正确答案
  • C.删除旧版本直接覆盖新版本
  • D.哈希指纹作为版本标识← 正确答案

答案：ABD。新旧版本并行、灰度切流、异常回滚和哈希指纹标识都是标准做法。直接覆盖旧版本会失去回滚能力，因此 C 错误。

Q10. 关于边缘缓存调优闭环，下列说法正确的是？

多选题 · extreme

  • A.监控命中率空间利用率淘汰次数← 正确答案
  • B.命中率低先分析请求再调策略← 正确答案
  • C.命中率高就不需要检查空间率
  • D.调优结果反哺预加载模型训练← 正确答案

答案：ABD。调优闭环需要监控多维指标，命中率低时要分析请求模式并调整策略，调优后的数据还能用于优化预加载模型。即使命中率很高，也必须关注空间利用率，否则可能为虚高的命中率支付过多存储成本，因此 C 不正确。