LLM Token 优化实战：省钱的 6 种方法

LLM Token 优化实战省钱的 6 种方法Redis 官方博客的一篇文章讲的不是 Redis 自身而是 LLM token 优化的几种通用策略。从 Prefill/Decode 的原理出发串联了语义缓存、上下文剪枝、推测解码等做法。一个基础概念Prefill 和 Decode要理解 token 优化得先知道 LLM 推理的两个阶段。Prefill预填充模型读取你的整个 prompt。这个阶段是并行计算的——prompt 里所有的 token 同时互相做 attentionGPU 一次性算完。耗时主要取决于 prompt 长度和 GPU 算力通常用首 token 延迟TTFT来衡量。Decode解码模型逐个生成输出 token。每个新 token 依赖之前所有的 token所以必须串行——等前一个生成完才能生成下一个。这个阶段通常是内存带宽瓶颈意味着限制速度的不是 GPU 算得多快而是 GPU 能把模型参数搬得多快。每个生成 token 都要把几十 GB 的模型权重从显存加载一遍做一小点计算产出单个 token。推论你每省掉一个输入 token就省了一次 Prefill 中的并行计算每省掉一个输出 token就省了一次 Decode 中的串行步骤。后者的延迟收益通常更明显。6 种优化方法1. 语义缓存Semantic CachingRAG 场景下用户问的问题经常高度重复。传统缓存只缓存精确匹配的结果——Redis 是什么和 Redis 是啥会被当成两个不同的请求。语义缓存的做法是把用户 query 向量化用向量相似度匹配。如果某个历史 query 的语义相似度超过阈值比如 0.95直接用缓存的回答不走 LLM。用户 query → 向量化 → 向量搜索Redis ├─ 命中返回缓存的回答零 token 消耗 └─ 未命中走 LLM → 缓存新结果实测效果在客服、FAQ、文档问答这类场景下查询重复率经常在 40-60% 之间语义缓存可以直接抹掉这部分 token 开销。Redis 在中间扮演的是向量存储角色——内存数据库亚毫秒级搜索。收益中高取决于查询重复率零质量损失2. 上下文剪枝Context Pruning长上下文场景下你的 prompt 里塞了大量内容——系统指令、RAG 检索结果、对话历史。模型不一定需要全部内容才能给出正确答案。做法是用一个轻量级模型或统计算法评估输入 token 的价值去掉低价值部分。三个粒度Token 级用小模型逐 token 打分扔掉得分低的。最精确但增加了额外推理开销。句子级评估每个句子的相关性删掉不相关的段落。开销适中效果不错。文档级在 RAG 阶段就做——检索时只取最相关的前 K 个 chunk而不是把所有检索结果都塞进去。收益中高长上下文场景下可以省 30-60% 输入 token质量可能反而提升减少噪音3. 推测解码Speculative Decoding前面说了 Decode 阶段是串行的速度受限于内存带宽。推测解码换个思路用一个更快的小模型当草稿大模型做审校。流程小模型draft model快速生成一批候选 token比如 5 个大模型并行验证这些 token——一次性计算所有候选 token 的 acceptance probability接受通过的 token拒绝的回退重来好处是原来需要串行 5 步的 Decode现在只需要串行 1 步小模型起草 并行 1 步大模型验证。在大模型推理时内存带宽是瓶颈——既然一次推理已经把模型权重加载到显存了一次性处理 5 个 token 和 1 个 token 的时间差不多。实际效果在合适的 draft model 搭配下Decode 速度可以提升 2-3 倍回答质量完全一致因为验证机制保证了最终输出和原模型一致。注意推测解码需要自己部署模型不能用 API对自建推理服务的团队更适用。收益高Decode 速度 2-3x零质量损失4. KV Cache 优化含 LMCache这是 Prefill 阶段的优化。LLM 在 Prefill 阶段计算 attention 时会产生 Key-Value pairs 的缓存。同一个 session 内的多次推理前面的 KV cache 可以复用。问题在于 KV cache 增长很快——一次长对话的 KV cache 可能占用几 GB 显存。LMCache 的做法是把 KV cache 从 GPU 显存卸载到 CPU 内存甚至 SSD需要时再按需加载。Redis 作为 LMCache 的存储后端看中的是它的高性能和持久化能力。收益中显存压力大的场景零质量损失5. Prompt 压缩结构化精简最简单直接的一种。把冗长的 prompt 改写成更紧凑的形式。比如你是一个经验丰富的软件工程师擅长 Python、JavaScript、Go 等多种编程语言 对后端架构设计有深入理解曾参与过多个大型分布式系统的设计与开发。改为角色软件工程师 专长Python/JS/Go、后端架构、分布式系统语义相同token 数量减少 60-70%。系统指令、few-shot 示例都可以做类似的压缩。收益低中取决于原始 prompt 的冗余程度质量基本不变6. 智能路由 模型选择不是所有 query 都需要最强的模型。用户问 “Redis 的 SET 命令怎么用”一个 7B 模型就能回答不需要 GPT-5.6。做法加一层路由判断。先评估 query 的复杂度分配给合适的模型。简单 query → 便宜的小模型复杂 query → 贵的大模型。通常结合语义缓存一起用——路由器先判断能不能走缓存再判断该走哪个模型。收益高混合模型策略可以省 40-70% 总推理成本部分 query 质量略降但要可控把这些方法叠起来用不是选一个而是能叠多少叠多少。一个生产级的推理管道大概长这样用户 query → 智能路由 → 语义缓存命中直接返回零 cost → 语义缓存未命中 → 上下文剪枝精简输入 → 走 LLM 推理自建时开推测解码 KV cache 优化 → 缓存结果每一层解决的 token 浪费类型不同方法解决什么问题省的是输入还是输出语义缓存相同问题的重复计算全部上下文剪枝无效上下文浪费输入为主推测解码Decode 速度瓶颈输出KV cache重复 attention 计算输入间接Prompt 压缩prompt 冗余输入智能路由过度使用大模型全部选择性地写在最后这篇文章其实说明了一件事LLM token 优化的核心不是省而是不浪费。缓存省的是重复计算剪枝省的是无效上下文路由省的是过度使用——这些都是浪费在不同形式的体现。Redis 在这篇文章里被提及为多项技术的存储后端——语义缓存的向量存储、LMCache 的 KV cache 后端。但文章本身的通用性大于它的产品推广意图即使你不用 Redis里面的策略思路也值得借鉴。不过有一个明显的警告虽然官方说上下文窗口越来越大2026 年已经到 1M tokens但上下文窗口不等于有效上下文。模型在大窗口下的大海捞针能力虽然在提升但实际场景中prompt 越长模型的 attention 越分散回答质量往往下降。这和 token 优化无关是 transformer 架构的固有问题。所以最简单的结论是能不送的 token就不送。Sources:LLM Token Optimization: Cut Costs Latency in 2026 - RedisPrefill vs Decode: LLM Inference Phases Explained - RedisContext Pruning: Cut LLM Tokens Without Losing Quality - RedisSpeculative decoding: how it works when to use it - RedisBoost LLM inference with LMCache and RedisLLM Inference Optimization Guide - MorphLContext Window Overflow in 2026 - Redis