Redis 8 敲锣打鼓的回归, 为什么?
digoal约 5 分钟Redis 8 敲锣打鼓的回归, 为什么?
Redis 8敲锣打鼓的, 又是重新开源, 又是支持多重开源协议, 重新支持云厂商友好的AGPLv3开源协议. 这是怎么了?
Starting with Redis 8, Redis Open Source is moving to a tri-licensing model with all new Redis code
contributions governed by the updated Redis Software Grant and Contributor License Agreement.
After this release, contributions are subject to your choice of:
(a) the Redis Source Available License v2 (RSALv2);
or (b) the Server Side Public License v1 (SSPLv1);
or (c) the GNU Affero General Public License v3 (AGPLv3).
Redis Open Source 7.2 and prior releases remain subject.
和前面几期结合起来看, 说白了大家的判断都一样.
《德说-第333期, Databricks花10亿美元买开源Neon数据库, 值得吗?》 《德说-第331期, ty的竞争对手是谁?》
1、一切都将被AI化, AI 智能体会遍地开花的爆发, 数量巨多, 有哪些?
C端, 平均每个人拥有超过1个智能体, 这就是几十亿.
B端, 政府、制造业、金融、游戏、教育等各个领域, 每个领域的企业/机构都需要大量智能体.
2、AI 智能体的本质是什么? 大脑 + 记忆(包括会话记录、私有知识库、配置等) + 工具及连接(通过工具调用连接、使用物理世界的其他产品和其他AI agent)
我在这一期谈过, 详见: 《德说-第325期, AI Agent的本质是什么? 如何快速搭建属于自己的agent》
我们重点关注“记忆(包括会话记录、私有知识库、配置等)”, 这个实际上就是数据库. 而且记忆不仅仅有向量、还有标准的结构化数据、非结构化数据等等.
以下几篇文章说明了即使是召回, 为了获得更好的召回率, 也不仅仅需要向量类型和向量索引. 更何况是有其他类别字段的过滤条件时.
《为什么用了RAG, 我的AI还是笨得跟猪一样! RAG效果评测与优化》 《维基百科(wikipedia) RAG 优化 | PolarDB + AI》 《召回精度提升插件: pg_tokenizer + VectorChord-BM25 reranking》
3、云和数据库都是基础设施, 大多数应用都会部署在云上, 大多数人会使用云数据库 (广义的, 包括任何用管控搭建的数据库服务)
4、大脑分为理性脑(推理) + 感性脑(低复杂度任务), LLM也一样. 但是推理用到的transformer架构需要从前N个token去计算下面token的概率, 所以运算量较大, 这里就诞生了kvcache加速推理的应用架构.
显然, redis 看重的是kvcache这块.
再不回来就没它啥事了, 各大云厂商自己在搞kvcache产品.
任何新赛道都是资本推动的，AI就是，对于个人来讲当然是增持并长期持有云厂商的股票！这可是千载难逢的发财机会。
KV Cache在LLM中的作用
以下来自Qwen3.
在大语言模型（LLM, Large Language Models）中，KV Cache（Key-Value Cache） 是一种用于 加速推理过程 的关键技术，尤其是在处理自回归生成任务（如文本生成、对话等）时非常关键。
🧠 什么是 KV Cache？
KV Cache 是 Transformer 模型在解码过程中缓存 Key 和 Value 向量的机制，目的是避免在每一步重复计算注意力权重，从而显著提高推理速度。
🔁 背景：Transformer 的自注意力机制
在 Transformer 架构中，每个 token 的输出依赖于所有之前 token 的 Key 和 Value 向量。这意味着：
在生成第 个 token 时，需要重新计算前 个 token 的 Key 和 Value。 如果每次都从头开始计算，时间复杂度会是 ，效率极低。
🚀 KV Cache 的作用
✅ 核心功能：
缓存已生成 token 的 Key 和 Value 向量 避免重复计算注意力矩阵中的历史信息
💡 原理图示（简化版）：
[Input] → Embedding → Q, K, V → Attention(Q, K, V) → Output
第一次输入一个 prompt 或初始 token，计算出 Q、K、V。 在后续生成 token 时，只计算当前 token 的 Q，而复用之前的 K 和 V（来自 KV Cache）。 这样可以将每次注意力计算的时间复杂度从 降低到 。
📊 KV Cache 的性能优势
⚠️ 注意：KV Cache 本身也需要占用内存，尤其是长文本或高维向量时，但其带来的推理加速效果通常远大于内存开销。
🧩 实现方式（以 HuggingFace Transformers 为例）
以下是一个简单的伪代码片段，展示 KV Cache 如何被使用：
# 初始调用，不带 cache
outputs = model(input_ids)
past_key_values = outputs.past_key_values
# 后续生成步骤，使用 cache
for i in range(num_steps):
outputs = model(
input_ids=next_token_id,
past_key_values=past_key_values
)
past_key_values = outputs.past_key_values # 更新 cache
past_key_values就是 KV Cache。每次调用模型时传入这个参数，模型就知道哪些 Key/Value 已经算过，可以直接复用。
🧰 支持 KV Cache 的主流框架和模型
| HuggingFace Transformers | ||
| PyTorch / TensorFlow | ||
| vLLM / TensorRT-LLM | ||
| Llama.cpp | ||
| DeepSpeed |
🚨 注意事项
| 内存占用 | |
| 上下文长度限制 | |
| 并行生成 | |
| 流式生成（Streaming） |
🧠 应用场景
| 对话系统 | |
| AI 写作助手 | |
| 语音转文字后端 | |
| API 接口服务 |
✅ 总结一句话
KV Cache 是 LLM 推理加速的关键技术之一，通过缓存历史的 Key 和 Value 向量，大幅减少重复计算，使生成过程更高效、更流畅。
如果你希望我提供具体的 KV Cache 实现代码（如 PyTorch 或 HuggingFace），或者想了解如何在 vLLM 中使用它，欢迎继续提问 😊