pm47-m6 · 四层实战优化 · 专题收官

模块：M6 产品手感 ｜ 课节：4 节（语义层：双重蒸馏 / 架构层：KV Cache 的注意事项 / 输出层：管住模型的嘴 / 算力时代的极简主义）

来源：xueai.miyang.cn（小山学堂 · 洛小山《学 AI 产品，从入门到精通》），本页为二次演绎的解读与音频稿件

---

一、本集要解决什么

同样一个功能，别人家的账单是你的五分之一，响应速度还比你快——差在哪？

本集是「Token 降本增效」专题的收官，给出实战四层：

层	管什么	核心收益
语义层	喂进去什么	4000 → 500 Token；压缩 5–20 倍
架构层	怎么复用算过的结果	KV Cache 命中最高省 90%
输出层	让模型说多少话	砍 30% 废话；润色成本差几十倍
收官	一条判断标准	每个 Token 都在为结果贡献价值吗

Token 成本是财务、延迟、质量的三重映射：提示词每多 1000 Token，你不光多付钱，用户还要多等一段首字延迟，模型还更容易抓不住重点。

---

二、能力地图

能力	手段	典型收益	落地难度
动态 Few-Shot	案例存向量库，按问题语义检索 Top-K	4000 → 500 Token，准确率反升	低
文档语义压缩	LLMLingua-2 中间件（BERT 双向注意力识别核心语义）	压缩 5–20 倍，预填充 1s → 50ms	中
前缀稳定	System Prompt / 工具定义 / 人设放最前且不变	KV Cache 命中率 10% → 80%	低
章节缓存	话题转换插分隔符，摘要 + 完整章节分层	命中率 + 连贯性双提升	中
负向约束	明确列出「不要做什么」	Agentic 场景砍 30% 废话	极低
Diff 输出	只输出改动部分或 find/replace 指令	成本差几十倍，体验更好	低
停止序列	物理截断（列表掐「4.」、JSON 掐「}」等）	不计费、不进历史上下文	极低

---

三、原理拆解

3.1 语义层：O(N²) 与中段迷失

• 贵且慢：Transformer 自注意力复杂度是 O(N²)，提示词长度翻倍，计算量翻四倍。提示词越长，Prefill 越久，首字延迟越高。
• 效果可能更差：有效信息被废话淹没产生中段迷失——开头认真看、结尾也留意、中间眼睛扫过去脑子没过去。精心挑选的参考资料落在中段，模型可能根本没认真看。

长上下文窗口提高了上限，没有改变注意力的分布形状。塞得下 ≠ 抓得住。

结论：关键信息放开头或结尾，中间留给「丢了也不心疼」的内容。

3.2 双重蒸馏

重	对象	手段	收益
第一重	Few-Shot 案例	向量检索动态选 Top-K	4000 → 500 Token，省 87.5%
第二重	检索回来的文档	LLMLingua-2 语义压缩	5–20 倍，预填充 1s → 50ms

压缩的隐藏收益：去掉重复的免责声明与垫话后，模型对关键数字的注意力反而更集中，答案更稳。

3.3 架构层：KV Cache 前缀匹配

大模型本质是「Token 推 Token」，只关心前文。前缀相同 = 重复计算 = 可缓存。用廉价存储换昂贵实时计算（空间换时间）。

问「2+4=?」      → 算出 6
问「3+4=?」      → 前缀变了，从头算
问「2+4+1=?」    → 前缀「2+4」没变，从 6 开始算

DeepSeek / Qwen / 智谱均支持，缓存价约为标准价 1/5——挑选 API 的必看项。

3.4 两个隐形大坑

坑一 · 动态切换 tools

只要请求带 tools 参数，服务端就会在 System Prompt 后插入工具说明；没写 System Prompt 时模板还会自动补一个再插。工具状态一变 → 头部前缀变 → 已缓存的几十万 Token 全部失效。

最阴的地方：不报错、账单不立刻爆炸，只是命中率从 80% 掉到 10%，而前缀变化发生在服务端模板里，本地看不到。

对策：System Prompt 保持不变 + 不用 tools 字段；或宁可浪费 Token 也要全量挂载工具定义。

坑二 · 滑动窗口

本质是 FIFO 队列，每滚动一次前缀就变一次，缓存永远命不中。真实案例「伴写」从固定 800 字滚动窗口改为章节缓存：

指标	滑动窗口	章节缓存
KV Cache 命中率	~10%	~80%
逻辑连贯性	差（经常失忆）	好（摘要 + 完整章节）
Token 成本	高（重复计算）	低（缓存复用）

3.5 上下文管理的四个设计决策

问题	设计决策
哪些信息必须恒久保留？	放入 Stable 区，作为缓存前缀
哪些信息可以压缩存档？	用摘要替代原文，控制窗口大小
哪些信息需要按需加载？	按章节 / 话题切分，动态挂载
如何识别可压缩边界？	设计分隔符机制，让 AI 标记话题转换点

3.6 输出层：管住模型的嘴

• 指令层 · 负向约束：「请简洁回答」太抽象；「不要寒暄、不要总结、不要客套，直接输出结果」才有效（英文社区：No preamble, no postscript）。实测 Agentic 场景砍 30% 废话。
• 代码层 · Diff 输出：润色场景让模型只输出改动部分或 find/replace 指令。2000 字重写 ≈ 2000+ Token vs 差异输出 ≈ 30 Token，输出比输入贵好几倍，一进一出差几十倍。
• 工程层 · 停止序列：物理截断，与模型「听不听话」无关。掐掉的部分不计费、不进历史上下文（顺手做了上下文清理）。

---

四、实践提示

提示一 · 把「不变的东西」放最前面

System Prompt、工具定义、产品规则、长期人设 = 缓存本金。用户这一轮的提问与检索文档放后面。顺序看着是工程细节，实际决定月度账单。

提示二 · 管嘴的收益会随轮次放大

废话不仅浪费输出 Token，还会被写进历史上下文，下一轮再被完整读一遍。一轮多说 30 字，十轮就是几百 Token 的输入成本，而且是复利式的。

提示三 · 压缩是质量手段，不只是成本手段

高信噪比 = 高智能。密度越高，注意力越不容易分散，幻觉也越少。快是它的副产品：Token 少了，首字出得快，端到端延迟短。

提示四 · 三条通用红线写进工程规范

红线	阈值	动作
单次输入	< 32k Tokens	预算感知截断（RAG、多图、多轮历史通用）
Agent 轮次	< 10 轮	熔断机制兜底
I/O Ratio	监控 > 50:1	Agent 在空转，先查流程

提示五 · 停止序列的附带价值

被掐掉的内容不进历史上下文，等于顺手做了一次上下文清理。在多轮 Agent 场景里，这比省下的 Token 更值钱。

---

五、审查清单

上线前逐条过：

• 提示词里是否有硬编码的 Few-Shot 案例？是否已改为向量检索动态挂载？
• 检索回来的长文档是否经过了语义压缩再送推理？
• System Prompt / 工具定义是否保持稳定？有没有动态切换 tools 字段？
• 长对话是滑动窗口还是章节缓存？命中率数据是否进了监控？
• 输出约束是否写成明确的负向清单，而不是「请简洁」？
• 润色类功能是否输出 Diff / 替换指令，而非重写整段？
• 列表、JSON、单行答案是否配置了停止序列？
• 单次输入、Agent 轮次、I/O Ratio 三条红线是否有告警？
• 方案评审时是否问过：这里的每一个 Token，都在为最终结果贡献价值吗？

---

六、约束说明

1. 压缩有上限：过度压缩会丢逻辑（LLMLingua 的 5x 与 20x 基准显示精度会随压缩率下降）。压缩率要按任务类型调，不能一刀切。
2. 缓存依赖供应商能力：不同厂商的缓存定价、失效策略、最小命中长度不同，选型时要把「是否支持上下文缓存」列为必看项。
3. 省 Token 不能牺牲质量：本集所有手段的共同点是提高信息密度，而不是减少必要信息。以掉点为代价的省钱是负优化。
4. 停止序列不能替代格式约束：它是兜底开关，不是格式控制的唯一手段，结构化输出仍需校验。
5. 题库内容不入音频：本集涉及的测验类页面仅作集页自测卡渲染，不进音频。

---

七、常见误区

误区	为什么错	正确做法
上下文窗口够大就不用挑素材	塞得下 ≠ 抓得住，注意力分布形状没变	关键信息放首尾，中段放可丢弃内容
为了省 Token 动态挂载工具	前缀一变，缓存全打穿，反而更贵	全量挂载或不用 tools 字段
用滑动窗口处理超长历史	FIFO 每滚动一次前缀就变，命中率趋零	Stable 前缀 + 摘要存档 + 章节挂载
写「请简洁回答」	「简洁」对模型太抽象	列清「不要做什么」
润色让模型重写整段	输出比输入贵，成本差几十倍	输出 Diff 或 find/replace 指令
靠提示词控制输出条数	模型听不听是玄学	停止序列做物理截断

---

八、落地节奏（建议四个迭代）

• 第一迭代 · 量测：把 TTFT、单次输入 Token 数、缓存命中率、I/O Ratio 四项接入监控，先摸清现状基线与浪费分布。
• 第二迭代 · 语义层：Few-Shot 改为向量动态检索；RAG 链路插入压缩中间件，按任务类型调压缩率。
• 第三迭代 · 架构层：重排提示词结构，稳定 System Prompt 与工具定义；长对话由滑动窗口改为章节缓存。
• 第四迭代 · 输出层：全量改写输出约束为负向清单；润色类功能改 Diff；为列表/JSON/单行答案配置停止序列。
• 长期运营：三条红线进告警，方案评审固定加问「这个 Token 是否为结果贡献价值」。

---

九、判断清单（可直接进评审会）

1. 这个提示词里，有没有一个 Token 是可以干掉而不影响结果的？
2. Few-Shot 是硬编码还是动态检索？命中率是 P50 还是 P99 的水平？
3. 我们的 System Prompt 上一次改动是什么时候？改动时有没有评估缓存损失？
4. 长对话用的是什么策略？命中率有没有进监控？
5. 这个功能的输出约束写成了什么？是「请简洁」还是一张负向清单？
6. 有没有让模型在重写它自己刚写过的东西？
7. 停止序列配了吗？列表、结构化输出、防自问自答各配了几个？
8. 输入/输出比是多少？超过 50:1 时我们的第一反应是加预算还是查流程？

---

十、要点速记

• 提示词翻倍 = 计算量翻四倍，O(N²) 是长上下文又贵又慢的物理根源
• 中段迷失：关键信息放开头或结尾，中间留给丢了不心疼的内容
• Few-Shot 别硬编码，存向量库动态检索：省 87.5% 还更准
• 长文档先压缩再推理：高密度 Prompt 换高质量 Attention
• 前缀不变缓存命中，最高省 90%；选 API 必看「是否支持上下文缓存」
• 别动态切换 tools，别用滑动窗口
• 负向约束要具体；润色输出 Diff；停止序列是物理开关
• 省 Token = 提高信息密度 = 高信噪比 = 高智能

---

十之二、给 PM 的一句话

这一集所有手段都不需要换模型、也不需要改产品形态，改的全是工程细节和提示词写法——但叠加起来能到几倍。降本不是砍功能，是把算力从噪音里赎回来。 下次评审听到「先加预算把效果做出来」时，你可以先问一句：现在的每一个 Token，都在为最终结果贡献价值吗？

十一、出处与延伸

本专题整理自作者团队内部分享《AI Token 降本增效策略分享》。延伸方向：

• 上下文腐烂研究（Chroma, Context Rot）；压缩基准见 LLMLingua
• 缓存工程：Manus「Mask, Don't Remove」把命中率从 20% 提到 95%；SGLang RadixAttention
• 输出控制：各家 API 的 stop 字段（OpenAI 兼容接口最多 4 个序列）
• 经济性：RAG 的 Re-Ranking 成本可达向量检索的 5000 倍；Agent 任务输入 Token 占比可达 95%

---

十二、本集与前后课程的接缝

• 往前接：BPE 解释了中文的 Token 税；报价表给出 T0/T1/T2 梯队与缓存价；跳档陷阱、Agent 账单解释了为什么输入会平方级膨胀。
• 往后接：进阶实战篇章的 RAG、Agent 与上下文工程章节，会把本集四层优化落到具体架构里。
• 横向看：本集四条红线（32k / 10 轮 / 50:1）可以直接变成工程规范与告警阈值，是整条降本链路里最容易固化的一层。

来源：xueai.miyang.cn（小山学堂 · 洛小山《学 AI 产品，从入门到精通》）

本页为二次演绎的解读与音频稿件，配套音频见本集 MP3。