传统网站其实早就有 Cache。

比如用户访问一篇文章。

第一次：

用户
↓
服务器
↓
PostgreSQL
↓
找到文章
↓
返回

如果这篇文章非常热门，每秒有几千个人访问，服务器就没必要每次重新查 PostgreSQL。

于是：

用户
↓
Redis
↓
直接返回文章

这就是传统 Cache。

它解决的问题主要是：

数据库查询速度和服务器压力。

但到了 AI 时代，同样的 Cache 思想 suddenly 变得更值钱了。

因为一次数据库查询可能只是：

几十毫秒

而一次 LLM 请求可能意味着：

几秒等待
+
几千 Token
+
一次模型 API 费用
+
GPU 推理计算

所以以前 Cache Hit 可能只是：

少查了一次数据库。

现在一次 AI Cache Hit 可能意味着：

整次 LLM 推理都不用发生。

这两者的经济价值完全不是一个量级。

因此我越来越愿意把 Redis 理解成 AI 系统里的：

计算复用层。

它并没有让模型算得更快。

它做的是更聪明的一件事情：

如果以前已经算过了，那能不能干脆不要再算？

比如用户第一次问：

什么是 RAG？

系统正常调用 LLM：

用户问题
↓
Redis
↓
没有缓存
↓
LLM
↓
生成答案
↓
写入 Redis
↓
返回

Redis 里可能记录：

Key:
"什么是RAG？"

Value:
"RAG，即 Retrieval-Augmented Generation……"

第二个用户再次问：

什么是 RAG？

系统先看 Redis。

发现：

Cache Hit

于是：

用户
↓
Redis
↓
直接返回

LLM 根本不用出现。

结果原本：

3 秒
+
Token 成本

可能变成：

几十毫秒
+
几乎没有新的模型 Token 成本

这就是最基础的：

Response Cache。

从原理上看，它和传统互联网缓存没有本质区别。

真正让 AI Cache 开始变得有意思的是下一步。

普通 Cache 有一个明显的问题。

用户第一次问：

什么是 RAG？

Redis 记住了。

但是第二个人问：

RAG 是干什么的？

第三个人问：

能不能解释一下检索增强生成？

第四个人问：

为什么 LLM 要用 RAG？

从字符串来看：

四个问题完全不同。

传统 Key-Value Cache 很可能认为：

Cache Miss
Cache Miss
Cache Miss

于是模型重新算三遍。

但我们作为人一眼就知道：

这些问题高度相关。

这就是 AI 时代 Cache 最有意思的变化：

Cache 不再一定要求文字相同，而是可以判断“意思是不是相近”。

这就是：

Semantic Cache

语义缓存。

核心其实又回到了我们之前聊过的：

Embedding。

假设第一个问题：

什么是 RAG？

先转成向量：

然后把：

问题
Embedding
模型答案
模型版本
时间
其他Metadata

一起存进 Redis。

下一次用户问：

RAG 技术到底是干什么的？

也转换成：

然后计算两者语义距离。

如果：

比如：

系统就可以认为：

这两个问题足够相似。

于是不用再次调用 LLM。

直接把之前的答案拿回来。

整个过程变成：

新问题
↓
Embedding
↓
Redis Vector Search
↓
有没有语义相似的问题？
↓
有
↓
Cache Hit
↓
直接返回历史答案

Redis 官方现在就提供了这种 Semantic Cache 能力：它可以把 Prompt、Embedding、模型回答和 Metadata 一起保存，并通过向量相似度判断一个新 Prompt 是否可以复用已有答案。

这意味着：

AI Cache 第一次从“相同字符串复用”，变成了“相同含义复用”。

这是一个非常重要的变化。

这里就终于能理解：

为什么不是随便找一个地方存答案，而是经常出现 Redis。

因为一个好的 AI Cache 同时要求几件事情。

首先：

非常快。

如果你查 Cache 本身就需要两三秒，那还不如直接问模型。

Redis 本来就以低延迟访问见长。

其次：

支持 TTL。

AI 答案并不是永远有效。

例如：

英国现在的首相是谁？

这种答案不能缓存一年。

所以可以规定：

TTL = 10分钟

或者：

TTL = 1小时

时间到了自动失效。

再次：

可以存 Metadata。

比如：

Prompt
Embedding
Response
Model
Model Version
User Locale
Tenant
Safety Flag
Created Time

Redis 官方的 Semantic Cache 设计就允许 Prompt、Embedding、Response 和相关 Metadata 一起保存。

最关键的是：

Redis 现在可以直接进行 Vector Search。

也就是说，它不仅能够问：

有没有完全相同的 Key？

还能够问：

有没有一个意思非常接近的 Prompt？

Redis Search 支持对 Embedding 做 KNN 和向量范围搜索，这正是 Semantic Cache 能成立的重要基础。

于是 Redis 从：

Key-Value Cache

自然延伸成：

Semantic Cache。

这又是 AI 时代才特别值得注意的一点。

Semantic Cache 虽然避免了 LLM 调用，但前面还有一步：

文本
↓
Embedding Model
↓
向量

Embedding 本身也是计算。

如果某段文本以前已经生成过 Embedding，就没必要重复计算。

于是又可以：

文本
↓
Redis
↓
有没有 Embedding？

有：

直接使用

没有：

Embedding Model
↓
生成
↓
写入 Redis

所以 AI 系统实际上可以一层一层减少重复计算：

Prompt
↓
Embedding Cache
↓
Semantic Cache
↓
RAG Cache
↓
LLM

RedisVL 官方现在也明确提供了 Embeddings Cache，用于避免重复的 Embedding 调用。

所以 Redis 在这里越来越不像一个简单的：

“存答案的小数据库。”

而更像一个：

AI 计算结果的复用中心。

再看 RAG。

一次标准 RAG 流程可能是：

用户问题
↓
Embedding
↓
Vector Search
↓
找到 Chunk
↓
组成 Context
↓
LLM
↓
答案

这里其实每一步都可能产生重复计算。

例如很多用户都在问：

公司退款政策是什么？

系统可能不断：

生成 Query Embedding；

重新 Vector Search；

重新取相同 Chunk；

重新构造 Context；

最后再调用 LLM。

如果业务允许，其中一部分完全可以被缓存。

因此 Redis 可以参与：

Embedding Cache
Retrieval Cache
Context Cache
Response Cache
Semantic Cache

甚至 Redis 本身也已经能够承担 Vector Search，因此它还可以直接作为某些 RAG 系统的向量检索层。Redis 官方现在明确把 Vector Search、RAG 和 Semantic Caching 都放在 AI 应用能力里。

于是一个 AI 系统可能变成：

用户问题
   ↓
Redis Semantic Cache
   ↓
命中？
├── Yes → 直接回答
│
└── No
     ↓
  Embedding
     ↓
  Redis Vector Search
     ↓
    RAG
     ↓
    LLM
     ↓
  写回 Redis Cache

Redis 在这里同时承担了：

检索 + Cache + 临时状态。

这和 Router 的关系其实也非常直接。

假设 Router 收到：

把下面这句话翻译成英文。

Router 判断：

简单任务 → 小模型

下一次又出现非常类似的任务。

Router 未必需要：

重新分类；

重新计算路由；

重新调用模型。

Redis 可以保存：

Prompt → Route

甚至利用 Embedding 做：

Semantic Routing

意思相似的任务：

翻译任务
↓
直接进入 Translation Route

RedisVL 现在甚至直接提供 SemanticRouter 这一类能力，用向量相似性帮助把语义相近的请求送往对应处理路径。

除此之外，Router 还有大量实时信息适合放 Redis：

session_123 → Claude

model_A_latency → 820ms

model_A_failures → 2

user_123_request_count → 47

于是 Redis 既可以帮助：

Cache

也可以帮助：

Session Stickiness

Rate Limit

Failover

模型状态

路由状态

这也是为什么 Redis 很容易出现在 AI Gateway 和 Router 架构里。

这是理解 AI Cache 时最容易犯的错误。

AI 领域里所有叫 Cache 的东西，并不都属于 Redis。

至少要分清下面几种。

最后两项尤其要分开。

例如模型收到：

System Prompt
+
10000 Token 文档
+
用户问题

下一次用户继续对话时：

前面的 10000 Token 可能完全没变。

某些 LLM Provider 会把这部分已经计算过的 Prompt 前缀缓存起来。

下一次不用从头计算。

这叫：

Prompt Caching。

它通常发生在：

模型推理服务内部。

也就是说：

你的应用
↓
OpenAI / Anthropic / 其他 Provider
↓
Provider 内部 Prompt Cache
↓
模型

而 Redis Semantic Cache 通常发生在：

用户
↓
你的 Redis
↓
如果命中甚至根本不调用模型

区别非常大。

Prompt Cache 是：

这个模型还是要回答，只是少算一部分。

Redis Response/Semantic Cache 是：

这个答案以前已经有了，模型这一次甚至可以完全不运行。

KV Cache 更底层。

Transformer 在生成 Token 时，会计算 Attention 中的：

Key 和 Value。

前面的 Token 已经算过以后，没必要每生成一个新 Token 都重新算一遍。

于是把之前的：

保存下来。

这就是：

KV Cache。

它通常在：

GPU 显存 / 推理基础设施

这一层。

所以千万不要理解成：

Transformer
↓
把 KV 存 Redis

正常情况下不是这么回事。

因此可以把 AI Cache 分成三个完全不同的层级：

应用层
Redis Semantic / Response Cache
        ↓

模型服务层
Prompt Cache
        ↓

模型推理层
KV Cache

虽然三个东西都叫 Cache，

但缓存的根本不是同一种计算。

如果只说：

Redis 是一个很快的内存数据库。

当然没错。

如果再说：

Redis 经常被拿来做 Cache。

也没错。

但到了 AI 系统里，这两个定义都没有真正解释它为什么重要。

LLM 最大的一个现实特点就是：

每次生成都是一次计算。

而计算意味着：

时间。

Token。

GPU。

钱。

所以一个成熟 AI 系统很重要的一项能力就是：

尽量判断哪些计算其实根本不应该重新发生。

Redis 正好处在这里。

第一次：

问题
↓
Embedding
↓
RAG
↓
Router
↓
LLM
↓
答案

整个系统认真计算一次。

第二次：

意思相似的问题
↓
Redis
↓
发现以前已经处理过
↓
复用

于是原本复杂的一条 AI Pipeline：

Embedding
+
Retrieval
+
Routing
+
LLM Inference

可能被一次 Cache Hit 直接跳过。

这就是为什么 AI 越昂贵，

Cache 的价值反而越高。

而 AI 请求越多，

Redis 这样的共享高速数据层也就越有价值。

所以，如果让我现在重新定义 Redis，我不会再只说：

Redis 是一个内存数据库。

也不会简单说：

Redis 就是 Cache。

我更愿意说：

Redis 是一个高速共享数据层，而在 AI 系统里，它最重要的价值之一，是充当应用层的计算复用层。

它把已经付过成本得到的东西：

LLM Response

Embedding

Retrieval Result

Session State

Router Decision

Tool Result

暂时保存下来。

当类似请求再次出现时，系统首先问的不是：

“应该调用哪个模型？”

而是：

“这件事情以前是不是已经算过了？”

只有答案是：

没有。

才继续往下计算。

所以一个越来越成熟的 AI 系统，其实不应该是：

所有请求
↓
LLM

而应该越来越像：

                 用户请求
                    ↓
              Redis Cache
               ↙        ↘
          Cache Hit    Cache Miss
              ↓            ↓
          直接复用      RAG / Router
                           ↓
                          LLM
                           ↓
                     写回 Redis

模型当然仍然是整个系统最聪明的部分。

但 Redis 做了一件完全不同、却非常重要的事情：

尽可能不让这份昂贵的聪明被重复浪费。

如果 GPU 负责提供 AI 的计算能力，

那么从 AI Application 的角度看，

Redis 很像站在模型前面的一层：

计算复用层。

它不负责让模型更聪明。

它负责让整个 AI 系统：

更快、更便宜，也更高效。