7.3 四条降本路线正面对比：缓存、蒸馏、截断、语义压缩

7.3 四条降本路线正面对比：缓存、蒸馏、截断、语义压缩

本节摘要：把缓存、蒸馏、截断、语义压缩四张牌摊开前，先记住一个事实——它们都在修改第 6 章成本模型里的同一个目标（单位 token 的有效单价），但各自动的是账单的不同部分。本节用同一套成本框架把这四条路线摆到前期投入、单位成本降幅、质量风险、见效周期、适用前提五个维度上正面对决，再给出"缓存加压缩"的叠加收益测算，最后为客服问答、长文档分析、Agent 循环三类业务各推荐一种组合。

缓存只是回收预付算力的一种手段，它不是唯一的牌，也不总是最优的牌。当账单压顶，工程师手里其实有四张不同的牌可打：缓存把重复算力收回来、蒸馏把单价底座结构性拉低、截断直接砍掉冗余输入、语义压缩在保留信息的前提下缩短输入。这一节不站队，只把它们放到同一张成本框架里比武。

四条路线各自动了账单的哪一笔

先厘清四条路线在成本模型里的位置，后面的大表才有锚点。

缓存（前缀缓存与语义缓存）省的是"重复计算"：同样的前缀或相似的问题只算一次，输出分布完全不变，所以它几乎零质量风险，代价是只能吃掉"重复或相似"那部分，对完全独有、一次性的长输入无能为力。

蒸馏把大模型能力迁到小模型，改的是"单价"本身——小模型每 token 的推理成本天然低于大模型，这是结构性的、对所有请求一视同仁的下降。代价是前期要训练、要调校，且质量有下行风险，不是所有任务都能无损迁到小模型。

截断最朴素：直接砍上下文长度或历史窗口，零工程门槛，输入短了 Prefill 和 KV 都跟着降。代价是信息损失，砍掉的内容如果后续被用到，质量立刻掉。它赌的是"被砍的通常不重要"。

语义压缩是用 LLMLingua 一类工具或对话摘要、检索式记忆，在保留语义的前提下把 token 数压下来。它不像截断那样硬删，而是重写或筛选，尽量做到"短了但没丢关键信息"。代价是压缩本身有算力开销和质量风险，且对输入结构有要求。

五维同台比武

把四条路线放到五个维度上对比，结论一眼可见：没有哪条全胜，只有"在特定前提下谁更值"。

四个维度里最该盯的是"质量风险"和"适用前提"两列：缓存质量风险极低但有"重复占比"前提，蒸馏降得最狠却要扛质量与训练成本，截断即时但最容易伤质量，语义压缩居中但依赖输入结构。选路线本质上是在"降幅、风险、前提"三者的约束下找交叉点。

实务里最常犯的错，是把四条路线当成单选题去比"哪个降幅最大"。降幅最大的蒸馏往往质量风险也最高、见效最慢，单独看它赢了，放进真实业务却可能答不准或半年才上线。正确的比较姿势是按风险排序、再按前提过滤：先把零风险且有前提满足的路线用上，剩下的降幅空间才交给有风险的那几张。换句话说，路线之间不是竞争关系，而是"能用的先用、不敢用的看前提"的排队关系。这也能解释为什么多数团队的最终方案是缓存打底、压缩补刀、蒸馏收尾，而不是孤注一掷押某一张牌。

组合不是加法而是乘法

四条路线不是互斥的，叠加时收益接近乘法而非简单相加——因为它们各自削减的是账单的不同部分，互不抵消。

下面这段可运行代码算一个典型叠加：平台前缀缓存先省掉稳定前缀，语义压缩再对剩余易变输入做 token 级压缩，两者作用在不同部分，合计降幅远大于单用任一种。

# 叠加收益测算：平台前缀缓存 + 语义压缩，作用在不同部分
base_cost = 1000.0        # 原始月度推理成本（元）
cache_save = 0.30         # 前缀缓存省 30%（作用在稳定前缀部分）
compress_save = 0.25      # 语义压缩再省剩余输入 token 的 25%

after_cache = base_cost * (1 - cache_save)
after_both = after_cache * (1 - compress_save)

print(f"仅缓存：{after_cache:.0f} 元")
print(f"缓存+压缩：{after_both:.0f} 元，合计省 {(1 - after_both / base_cost) * 100:.0f}%")
# 输出：仅缓存：700 元；缓存+压缩：525 元，合计省 48%
​

注意代码里两次乘法是作用在"剩余部分"上，所以合计不是 30% 加 25% 等于 55%，而是 1 减 0.7 乘 0.75 等于 48%——这就是乘法效应的来历。如果再叠一层蒸馏把单价底座再降两成，最终账单可能只有原来的四成。叠加的顺序建议是：先用缓存吃掉零风险的稳定部分，再用压缩缩短易变长尾，最后对高频场景叠蒸馏，风险一层层加、收益一层层叠。

三类业务的推荐组合

落到具体业务，三类典型场景的推荐组合各有侧重。

客服问答：问题高度重复、系统提示词固定、答案分布稳定。首选平台级前缀缓存吃掉固定前缀，叠加应用层语义缓存拦截"问法不同但答案相同"的那一大块，两者都是极低质量风险。蒸馏可选项——若问答任务简单，迁到小模型能再压单价，但需先评测质量。截断一般不用，因为客服上下文短。

长文档分析：输入长、冗余多、单次为主。首选截断（砍掉无关章节）配合语义压缩（LLMLingua 类凝练），把超长输入压进模型窗口；前缀缓存收益有限（每次文档不同），但若同一文档被多人反复分析，框架层前缀缓存仍有价值。蒸馏收益低（分析任务常需大模型能力），一般不优先。

Agent 循环：多步推理、上下文随时间膨胀、重复模式多。首选框架层前缀缓存（多轮命中历史 KV），叠加对话历史摘要式语义压缩（把早期步骤压成摘要，避免上下文无限增长），截断作为兜底（超出窗口强制摘要）。蒸馏视任务而定。Agent 场景里"压缩加缓存"几乎是必选项，否则上下文膨胀会让单轮成本随步数线性起飞。

把三类组合放在一起看，会发现它们其实是由同一组前提推导出来的：客服问答赢在"重复占比高"，所以缓存打头；长文档分析输在"重复占比低、输入长"，所以压缩打头；Agent 循环痛在"上下文随时间膨胀"，所以缓存加压缩兜底。前提不同，主牌就不同，但决策逻辑完全一致——先量前提，再排路线。这也反过来提醒：抄别人的组合方案没意义，因为你家业务的重复占比和输入结构大概率和案例不一样，照着前提推一遍才可靠。

实例：长文档分析从截断切到"缓存加压缩"

完整走一遍背景、操作、结果、解读、变式。

背景：一家投研团队用大模型做研报摘要，每份研报约 3 万 token，单次分析为主，原方案是硬截断到模型 8K 窗口、丢掉的章节靠用户二次追问补。月度推理成本 2 万元，但摘要完整度差，用户投诉"关键信息被截没了"。

操作：保留截断作为第一道（先按章节相关性砍到 1.5 万 token 的精读区），再接入语义压缩组件，把精读区里可凝练的论述压到 8K 以内、保留关键数据；同时因为同一批研报会被团队多人反复调阅，开启框架层前缀缓存，让"研报正文前缀"在团队内跨请求复用。蒸馏不采用——摘要质量依赖大模型理解力，迁小模型会掉准确度。

结果：截断加压缩让单份研报稳定进 8K 窗口、不再丢关键信息，用户投诉降为零；前缀缓存在团队复用下吃掉约三成重复 Prefill。月度成本从 2 万降到约 1.1 万（降约 45%），且摘要完整度反而上升——因为压缩是"凝练"而非"硬删"，丢的是套话不是数据。

解读：这个 case 的转折在于，原来单用截断是把"冗余"和"关键信息"一起砍了，质量换成本；改成"截断粗筛加语义压缩精修"，成本照样降、质量还更好。它说明四路线里截断和语义压缩看似都在"缩短输入"，机制却不同——一个盲删、一个有损凝练，选错手段质量代价天差地别。前缀缓存在这里只是锦上添花（团队复用前提才成立），主角仍是压缩。

变式：若这家团队后来改成"每人独立分析不同研报、零重叠"，前缀缓存的复用前提消失，应撤掉缓存、只保留截断加压缩；若分析任务标准化到可以迁小模型，再叠一层蒸馏把 1.1 万进一步压到 7 千。组合永远跟着"重复占比、输入结构、质量容忍度"三个前提起舞，没有固定配方。

图 7-3：四条路线的四维对比矩阵图

下一节把这张比武表收成一张可操作的决策树——从账单上"重复 token 占比"这一个数字出发，沿分支走到具体方案，每个岔路口都给判断依据和量化阈值。