考察点
这道题考的是从"算法工程师"到"业务负责人"的视角切换：LLM 应用的成本 = 单价 × token 数 × 调用量，每个因子都有对应的工程杠杆。面试官想看你有没有量化的成本意识（知道钱花在哪、能算出各手段的收益量级），以及缓存、路由、级联这些手段的适用条件和坑。追问常落在缓存命中率怎么提、路由的质量风险怎么控。
参考答案
先拆成本结构
控制成本的第一步是知道钱花在哪。一次 RAG 问答的 token 账单：输入（system prompt + 检索 chunk + 历史 + 用户问题）通常占大头，输入几千 token 输出几百很常见——很多应用 80% 以上的成本在输入侧，所以优化 prompt 比优化输出值钱。拆完账，杠杆就清楚了：减少 token 数、用更便宜的模型、干脆不调用。
缓存：不调用是最便宜的调用
- 精确缓存：对相同请求直接返回历史结果。FAQ、客服场景命中率可观，实现就是 key-value，没什么技术含量但收益直接。
- 语义缓存：用户问法不同但语义相同的命中。做法是把 query 向量化（如 bge-m3），查向量库里相似度超阈值的历史问题，命中即返回缓存答案。GPTCache 是开源代表。语义缓存的命门是阈值校准：阈值低了答非所问（"怎么退款"命中"怎么退货"可能没关系），高了命中率上不去。要按业务灰度调，并对命中结果做来源标注和兜底。
- Prompt 级缓存： Anthropic 和 OpenAI 都提供 prompt caching，长 system prompt/文档前缀的重复部分按折扣价计费，本质是服务端帮你做 prefix KV 复用。长固定前缀的应用（文档问答、agent）接入后输入成本可降一个量级，几乎是白捡。
- 缓存什么也要设计：RAG 里检索结果可以缓存（同一文档库下 query 向量复用）、中间结果可以缓存（摘要、改写），不只有最终答案。
模型路由：让便宜的模型接能接的活
不是所有请求都值得用旗舰模型。路由的做法：前置一个轻量分类器（可以是微调的小模型，甚至规则 + embedding 相似度），按请求难度/类型分流——简单问答、格式转换、分类打标走小模型（7B 级或 Haiku 级），复杂推理、多步规划才上大模型。RouteLLM 这类工作证明用少量路由训练数据就能在质量损失几个点内把成本砍半以上。
工程上要处理三件事：路由模型本身要够便宜够快（否则省的钱被路由开销吃掉）；路由错误要有兜底（小模型置信度低时升级到大模型，即下面说的级联）；路由边界随业务演化要持续评估，别上线一次就不管。
级联（Cascade）：先小后大，不行再升
路由是"事前判断"，级联是"事后兜底"：先让小模型作答，用置信度信号（logits 熵、自评打分、或一个校验器）判断答案质量，不达标再调大模型重做。大部分请求在小模型就终结了，成本结构从"全部按大模型计价"变成"小模型价格 + 升级率 × 大模型价格"。客服场景升级率做到 20-30%，成本能砍 60% 以上。风险是错误答案的质量判断本身很难——自评置信度和真实质量相关性有限，校验器要用业务标注数据校准。
其他该提一嘴的杠杆
- Prompt 瘦身：检索 top-k 收敛、历史消息滚动摘要、删掉万年不变的客套指令；输入 token 是成本的乘数。
- 输出控制：max_tokens 收紧、prompt 里要求简洁，输出单价通常是输入的 3-5 倍（以主流 API 定价论）。
- 批处理 API：离线任务（打标、清洗）走 OpenAI Batch API 这类通道，半价换 24 小时内返回。
- 自建 vs API 的账：调用量到一定规模后，开源模型 + vLLM 自建可能更便宜，但要算全 GPU 成本、运维人力和可用性成本，不是简单比 token 单价。
- 监控：按业务线/功能点分摊 token 用量，成本异常要能定位到是哪个功能在烧钱——没有成本看板，一切优化都是盲打。
可能的追问
- 语义缓存最大的风险是什么？ 错误命中：语义相近但答案不同的问题被串答。应对：阈值保守起步 + 灰度放量、对答案附带条件信息（时间、用户身份）的场景禁用缓存、建立 badcase 回流机制。
- 路由分类器用什么特征？ 离线先用大模型给历史请求打难度标签，再训练小分类器；特征可以是 query embedding、长度、意图标签。关键指标不是分类准确率，而是"端到端质量损失 vs 成本下降"的帕累托曲线。
- 级联里怎么判断小模型答案不行？ 便宜信号：输出 logprob 的均值/熵；贵一点：让小模型自评或规则校验（格式、关键字段）；最稳：训练一个判别器。生产上多信号融合，阈值按业务标注调。