7.4 选型决策树与术语速查

7.4 选型决策树与术语速查

本节摘要：前面三节把能用的手段和它们的代价都摊开了，但真到拍板时，问题不是"哪个最好"，而是"从账单上哪个数字先动手"。本节给出一条完整的选型决策路径——从"重复 token 占比"这一个可查的数字出发，沿分支走到具体方案，每个岔路口都给判断依据和量化阈值；后半部分是一份覆盖全册的术语速查表，按显存层、平台层、应用层、成本与度量四层分组，方便离开教程后随时回查。

决策最怕拍脑袋。把第 6 章的成本框架和前三节的手段收成一张树，好处是每个节点都有可量化的判断依据——你不用懂全部原理，只要会看账单上的几个数字，就能顺着分支走到该用的方案。

决策从哪一个数字开始

整棵树的入口只有一个数字：账单里"重复 token 占全部 token 的比例"。它直接决定缓存这条零质量风险的路线有没有足够大的肉可吃。这个比例怎么来——把一个月的用量日志按请求拆解，统计被同一前缀覆盖、或被语义去重命中的 token 量，除以总数即可。拿到这个数，下面的分支才有意义。

阈值先给一版经验值，后面每个节点再细化：重复占比低于百分之十，缓存基本不值得专门做，优先考虑截断或压缩；百分之十到四十，缓存有收益但有限，配合压缩更划算；高于四十，缓存是主角，再按前缀稳定性决定用哪一层缓存。

沿着分支走到具体方案

从根节点出发，每一跳的判断依据和阈值如下。

第一跳看"重复占比是否高且前缀稳定"。若占比高（大于四十）且前缀固定（系统提示词、知识库注入基本不变），走平台级 Prompt 缓存——这是零工程门槛、零质量风险的第一选择，命中率九成以上时月度账单常能砍掉两三成。若占比高但问法多变、前缀早早分叉（典型如客服里同一意思百种问法），平台缓存命中率低，应改走应用层语义缓存，用向量相似度拦住"答案相同"的那一大块。

第二跳看"是否自建推理服务"。如果流量跑在自己部署的 vLLM 或同类框架上，无论前缀稳不稳，都应开启框架层前缀缓存（RadixAttention 一类），这是服务端白送的复用，不依赖任何平台特性。自建场景下这一跳优先级甚至高于语义缓存，因为框架层命中是确定性的、无质量风险。

第三跳看"上下文是否过长"。当单请求输入动辄数万 token、且大量是冗余或可凝练内容时，缓存帮不上（每次文档不同），应走截断或语义压缩。截断即时但伤质量，语义压缩慢热但保信息，按质量容忍度二选一或叠加。这一跳和前面不冲突——长文档场景往往是"截断加压缩"双管齐下。

第四跳看"是否预算充足且长期高频"。如果业务会长期跑、调用量巨大，前面几招省的是"重复部分"，蒸馏省的是"单价底座"——它是结构性、对所有请求一视同仁的下降。蒸馏前期要训练和评测，不是立竿见影，但只要任务可迁小模型，长期看它才是把账单打穿地板的那张牌。它通常作为叠加项，放在缓存和压缩之后。

图 7-4：LLM 降本选型决策树图

三类典型起点的走法

把树浓缩成三种最常遇到的起点，方便对号入座。

起点一是"账单重复占比过半、系统提示词固定"——直接平台缓存，命中率起来后账单立降，这是最舒服的情况。起点二是"上下文巨长、单次为主、重复占比低"——缓存几乎无效，全力做截断加语义压缩，必要时上小模型蒸馏。起点三是"自己部署推理服务、流量混杂"——先开框架层前缀缓存（白送的确定性命中），再按前缀稳定性补平台或语义缓存。三种起点互不排斥，真实业务往往是组合。

走一遍：客服问答业务的决策实例

用完整五段把决策树落到真实业务，验证它能不能独立导航。

背景：某电商客服接入大模型，月度推理费 5 万元。系统提示词固定约 1500 token，用户问题高度重复但问法各异（"怎么退款""退款流程""钱什么时候退"算同一意图不同表述）。团队不自建服务，走云厂商 API。初步统计重复 token 占比约五成。

操作：按树走——第一步重复占比五成、且前缀（系统提示词）稳定，先上平台级 Prompt 缓存吃掉固定前缀，预期省掉那 1500 token 的稳定部分。第二步判断问法多变、前缀早早分叉，平台缓存对"问题主体"命中率低，叠加应用层语义缓存，用向量相似度拦截"同一意图不同问法"的重复回答。蒸馏暂不评，因为客服答案准确性要求高，迁小模型风险先不扛。

结果：平台缓存上线后稳定前缀部分月度省约 25%；语义缓存把"问法不同但答案相同"的重复请求再拦下约 30%，两者叠加月度费用从 5 万降到约 2.8 万（降约 44%）。用户侧无感知——两套缓存都不改输出分布，答案质量和以前一致。

解读：这个 case 正好是决策树"高占比加稳定前缀"与"问法多变"两个分支同时命中的典型，所以它吃到了两层缓存的叠加收益，且零质量风险。关键判断是"前缀稳"和"问法多变"分属不同部分——前者靠平台缓存、后者靠语义缓存，两者互补而非打架。若只做平台缓存，会漏掉问法多变那块；若只做语义缓存，会浪费稳定前缀那块零风险的便宜。

变式：若这家公司把客服迁到自建 vLLM 集群，应在平台缓存前先开框架层前缀缓存（确定性命中白送），再保留语义缓存；若后续发现七成问题都能由小模型答对，可追加蒸馏把单价底座再降，月度费用有望压到 1.5 万以下。决策树每多走一层，收益就多叠一层，前提是每层的前提都满足。

全册术语速查表

离开教程后遇到陌生名词，按下面四层回查即可。每个术语一行定义。

显存层（第 2 章）

• KV Cache：自回归解码时为每个已生成 token 缓存的注意力键值，避免后续步重复计算。
• PagedAttention：vLLM 将 KV 显存分页管理的机制，提升显存利用率与跨请求复用效率。
• RadixAttention：SGLang 用基数树组织并复用跨请求 KV 的机制，自动命中公共前缀。
• 显存复用：把已算出的 KV 留在显存供后续请求命中的总称，是缓存的物理基础。
• 前缀缓存（框架层）：推理框架按请求前缀复用 KV 的能力，典型如 vLLM 的自动前缀缓存。

平台层（第 3 章）

• 平台 Prompt 缓存：云厂商提供的跨请求前缀复用与计费产品，命中即按折扣计费。
• cache_control：在提示词中显式标记缓存断点的控制字段，告诉平台从哪开始算共享前缀。
• TTL：缓存存活时长，到期未被复用则失效并需重建，直接影响命中率与成本。
• 命中率：命中缓存的请求或 token 占比，衡量复用程度的核心指标。
• 缓存污染：错误内容进入缓存后被反复返回的现象，会成倍放大错误答案。

应用层（第 4 章）

• 语义缓存：用向量相似度判断"这个问题以前答过没有"，命中时连模型都不用调。
• 嵌入缓存：缓存文本的向量化结果，避免对相同内容重复编码，端侧性价比极高。
• 前缀投毒：攻击者抢先种入污染前缀以操纵共享缓存命中结果的攻击手法。
• 侧信道探测：通过命中时延差异反推他人上下文是否存在的间接泄漏手法。

成本与度量（第 6 章及本章）

• 有效单价：扣除缓存等复用收益后，实际每 token 的成本，是比标价更真实的口径。
• TCO：总拥有成本，含显存占用、算力、失效重建、运维等全口径费用。
• 蒸馏：将大模型能力迁移到小模型，结构性降低每 token 单价的训练型手段。
• 语义压缩：在保留信息前提下缩短输入 token 数的方法族，如 LLMLingua 类工具。
• LLMLingua：一类对提示词做 token 级语义压缩的开源工具，典型代表语义压缩路线。

这张表不是死记清单，而是决策树的词汇表——前面每一跳的判断依据，落到术语上就是"命中率""有效单价""TCO"这些可查可算的量。全册七章走到这里，复用经济学的闭环已经合上：算力预付、缓存回收，而收不收、在哪收、收不动时换哪张牌，现在都在你手里。