AI系统中的分布式缓存：加速推理降低延迟

可视化演示

展示分布式缓存在AI系统中的架构设计、特征/Embedding/结果三类缓存对比，以及缓存命中率与延迟优化趋势。

缓存基础：熟食窗口的“快”从哪来

走进食堂，你会发现最热闹的不是后厨，而是那排熟食保温窗口。阿姨提前把宫保鸡丁、糖醋排骨做好，学生来了端走就走，根本不用等着下锅。这个窗口省下的时间，来自一个朴素的观察：一百个学生里，九十个点的都是那几道热门菜。把热门菜提前做好，大多数人就不用等——这个观察，在计算机里叫数据局部性（Data Locality）。

AI系统同样如此。用户请求不是均匀散布的：推荐系统里头部内容贡献了绝大多数流量，大模型服务里翻来覆去是那几句常见问法。如果我们把高频数据——某个热门特征、某条重复的问题、某个常用Embedding——提前存到一块快速存储区，请求到达时先查这块区域，命中就直接返回，未命中才往后端跑。这块快速存储区，就是缓存。

缓存的效果不是玄学，而是可以量化的。把能从缓存直接拿到结果的请求叫做“命中”，把没拿到、必须去后端计算的请求叫做“未命中”。命中数占总请求数的比例就是缓存命中率（Hit Rate），它是评估缓存设计好坏的第一指标，也是所有后续策略优化的出发点。命中率越高，系统中“秒级取餐”的比例就越大。

理解了命中率，就理解了缓存的一切——它本质上是一个概率问题：我们的“备菜”能不能命中“大多数人的需求”。

三类缓存：食堂的三个保温窗口

食堂不会只开一个窗口。有的窗口卖做好的热菜，学生来了直接端；有的窗口卖洗净切好的净菜，厨师拿回去炒一下就行；还有的窗口放标准化酱料包，哪个窗口缺了随时补。三种窗口备货逻辑不同，但目标一致：让学生少等。

AI服务里也有三个对应的“窗口”：

• 特征缓存：存用户画像、物品属性等做模型输入的特征值。同一用户反复请求时，不用每次重新算特征。

• 结果缓存：直接存模型对某个输入的最终输出。相同或相似请求再次出现时，整个推理过程都可以跳过。

• Embedding缓存：存模型把ID映射成的稠密向量。这些向量在推荐、搜索、RAG中被反复使用，重算极其浪费。

选择哪类缓存，取决于“什么东西可以被复用”。特征缓存的复用单位是“实体”——同一个用户或物品的多次请求共用特征；结果缓存的复用单位是“请求”——相同或语义相同的输入，输出可以直接复用；Embedding缓存的复用单位是“实体参与的计算”——向量在多个环节被重复读取。用平均延迟公式可以统一评估三类缓存的价值：命中率提升带来的延迟下降，是否值得那部分内存成本。

三个窗口各有各的菜，但都遵循同一笔账：多备一份菜，少等一个学生，值不值？平均延迟公式就是那本账本。

特征缓存：给每道菜一个正确的牌号

熟食窗口最怕什么？怕菜做出来却没挂牌子，或者牌子挂错。学生看到“鱼香肉丝”的牌子，端走的却是宫保鸡丁，下次就不敢来了。特征缓存也一样，键（Key）就是牌子：牌子挂得稳、挂得唯一，请求才能准确找到要的数据。

特征缓存以 KV 形式存储，键通常由“实体ID + 特征名 + 版本号”组成。比如 user:12345:age_group:v3 表示用户 12345 的年龄分组特征，版本是 v3。设计键的最大原则是“稳定重现”：同一次查询，无论什么时候发起，拼出来的键必须完全一致。用户ID拼错一个空格、特征名大小写不一致，都会导致缓存永远命中不了。

工程上有几个常见的键设计套路：

• 统一格式：实体类型:实体ID:特征名:版本号，冒号分隔，便于排查与统计。

• 对长键做 Hash 压缩，减少内存占用。

• 特征版本号写进键里，模型升级后自动改用新键，天然做到新老缓存隔离，不用手动清空。

牌子挂对了，学生才能准确地把菜端走；键设计对了，特征缓存才能真正发挥“按需取用”的威力。

结果缓存：识别“同一个问题”的智慧

食堂阿姨是半个语言学家。学生说“宫保鸡丁盖饭”和“宫保鸡丁饭，不要辣”，她能判断出这是同一道菜，配方早就准备好，直接盛饭就行。结果缓存的难点也在这里：如何识别“字面不同、语义相同”的请求。

朴素的缓存拿原始文本做等值匹配，只有完全相同的字符串才能命中。但真实用户的问题千变万化：“报销流程是什么”“怎么报销”“报销步骤有哪些”——同一个意图，三种说法。于是需要用语义哈希（Semantic Hashing）：把文本编码成向量，再比较向量间的相似度。

典型流程：

1. 用轻量编码器把请求文本转成向量。

2. 用余弦相似度与缓存池中的已有向量比对。

3. 相似度超过阈值（如 0.95）判定为重复请求，直接返回缓存中的历史回答。

4. 同时缓存“无答案”之类的空结果，防止无效请求反复穿透到模型，浪费算力。

阿姨听的是“话里的需求”，不是“字面上的句子”。结果缓存的价值，就在于理解深层语义，把同一道菜的千万种说法归到同一个牌号下。

Embedding缓存：预制菜仓库的生意经

食堂有个后仓，整箱整箱地堆着标准化净菜包：每包 500 克，按固定配方封装，厨师拆开就能下锅。虽然占地方，但随取随用，省下的备菜时间非常可观。Embedding 缓存就是 AI 系统里的那个后仓。

Embedding 是模型把离散的 ID（用户ID、商品ID、文本块ID）映射成的稠密向量，常听到的 128 维、768 维就是指它。推荐系统里每个用户和商品都有向量，RAG 里每个知识块也有向量。这些向量在每次请求中都要被读取参与计算，如果每次都重新生成，成本极高；缓存下来，等于把“现做”变成“拆包”。

Embedding 缓存的特殊之处在于数据量大、访问模式固定，设计上有几个关键点：

• 内存采用连续行存储，保证批量读取时的空间局部性。

• 常用 int8 量化压缩，省内存带宽，精度损失可接受。

• 配合 ANN（近似最近邻）只检索需要的向量子集，避免全量扫描。

• 服务启动时把头部实体的向量批量预热，避免冷启动穿透。

预制菜仓库虽贵，但拆包即炒的快感让食堂阿姨们趋之若鹜。Embedding 缓存的内存成本，换回的是计算和延迟的双重节省。

一致性：菜谱改了，旧菜怎么办

后厨突然推出新配方：宫保鸡丁改版了，减油减辣。但熟食窗口还摆着旧配方做的菜。阿姨心里清楚：卖，学生吃到的就是过期口味；不卖，这几个窗口就浪费了。缓存一致性，就是讨论“旧菜该怎么处理”的学问。

问题出在缓存里的数据和数据源（数据库/模型）不同步了。两类经典策略：

• 写穿透（Write Through）：数据变更时同步更新数据库和缓存，保证强一致；代价是每次写操作都要两处落盘，写放大明显。

• 失效广播（Cache Aside）：数据变更时通知各缓存节点删除对应键，下次请求再重新计算回填；实现简单，读多写少场景效率高。

工业界主流的做法是“过期时间兜底 + 版本号校验”。缓存数据附带一个版本号，读取时拿它和数据源的当前版本比较：如果缓存版本不落后，直接用；落后了，判定失效并重新计算。分布式场景下，通过消息队列把失效事件广播给所有缓存节点，达到最终一致——几毫秒内旧版本被清出，用户几乎无感知。

广播一响，各窗口同步撤旧菜、再上新菜。版本号让每一盘菜都清楚自己是哪个时代的产物，这就是最终一致的优雅之处。

热点调优：爆款菜让队伍排到门口

期末考试前，糖醋排骨突然成为全食堂的爆款。问题是：所有的糖醋排骨都放在同一个保温台，几百个学生全挤那一个窗口，其他人只能干着急。这个“一个窗口承载全校食欲”的场景，就是分布式缓存里的热点问题。

分布式缓存把数据分散在很多节点上，一个 key 正常情况下只落在某一个节点。当某个 key 成为热点——爆款商品的 Embedding、热门新闻的特征——大量请求会同时打向同一个节点，造成节点过载、延迟飙升，而其他节点却闲着。这就是“热点倾斜”。

应对热点有三板斧：

1. 热点识别：统计 key 的访问频率和增速，提前发现可能爆发的热点。

2. 本地缓存：在应用进程内加一层小型缓存，把热点请求直接挡在进程内，不再经过分布式缓存节点。

3. 副本扩容：把热点 key 复制出多个副本分布到不同节点，把流量摊开。

最后是监控与调优指标：命中率、平均延迟、p99 延迟、节点 CPU、淘汰量、热点 Top-K。容量规划遵循“内存换时间”原则，一般给总数据量的 20%-40% 分配缓存内存，优先覆盖头部热数据。

爆款菜多开几个窗口、每个窗口备一份，队伍自然就消化了。热点处理的核心不是把菜做多，而是让“窗口”变多。

AI 应用场景

Python 演示

import timefrom collections import OrderedDict  class TTLCache:    """带过期时间和LRU淘汰的缓存，模拟AI推理结果缓存。"""     def __init__(self, capacity=1024, ttl=60):        self.capacity = capacity        self.ttl = ttl        self._cache = OrderedDict()  # key -> (value, expire_at)        self._hit_count = 0        self._miss_count = 0     def get(self, key):        # 读取缓存：命中则刷新LRU顺序，未命中返回None        now = time.time()        if key not in self._cache:            self._miss_count += 1            return None        value, expire_at = self._cache[key]        if now > expire_at:            # 过期：删除并视为未命中            del self._cache[key]            self._miss_count += 1            return None        # LRU: 先删除再插入，让它在有序字典中排到末尾        del self._cache[key]        self._cache[key] = (value, expire_at)        self._hit_count += 1        return value     def set(self, key, value):        # 写入缓存：容量满时淘汰最久未用的项        now = time.time()        if key in self._cache:            del self._cache[key]        self._cache[key] = (value, now + self.ttl)        if len(self._cache) > self.capacity:            self._cache.popitem(last=False)     @property    def hit_rate(self):        total = self._hit_count + self._miss_count        return self._hit_count / total if total else 0.0  def slow_predict(user_id, query):    # 模拟耗时的AI推理，比如大模型生成回答    time.sleep(0.5)    return f"回答[{user_id}]: {query} 的推理结果"  def main():    cache = TTLCache(capacity=3, ttl=5)    requests = [        ("u1", "什么是缓存"),        ("u2", "机器学习"),        ("u1", "什么是缓存"),        ("u3", "深度学习"),        ("u1", "什么是缓存"),    ]    for uid, q in requests:        key = f"{uid}:{q}"        result = cache.get(key)        if result is None:            result = slow_predict(uid, q)            cache.set(key, result)            print(f"[未命中] {key} -> {result}")        else:            print(f"[命中] {key} -> {result[:12]}...")    print(f"命中率: {cache.hit_rate:.1%}")  if __name__ == "__main__":    main()

1. from collections import OrderedDictLRU 需要有序字典记录键的访问先后顺序。
2. self._cache = OrderedDict()缓存主体，既能做 LRU 淘汰，又能配合时间戳做 TTL 过期检查。
3. if now > expire_at:判断持久层里这个灵魂拷问：这盘“预制菜”还新不新鲜？
4. self._cache.popitem(last=False)容量满时弹出最久未用的键，对应食堂撤掉最没人吃的菜。
5. slow_predict()模拟耗时 0.5 秒的 AI 推理，对应“后厨现炒”。
6. cache.set(key, result)计算完写回缓存，下一次同样的请求就能直接命中。

常见误区

面试题