先这样答
成本优化讲顺序感很重要：先做不花钱的，再做花小钱省大钱的，最后才动架构。
第一层：省 token。这是性价比最高的一层。上下文瘦身：提示词里冗长的说明、few-shot 例子、塞进去却没用的检索内容，都是按 token 计费的固定开销，逐项审计砍掉一半很常见。输出限制：回答长度、列表条数、格式化输出，输出 token 通常比输入贵，控制输出就是直接省钱。工具结果别全量进上下文，摘要进。
第二层：缓存。命中就是全额省钱。请求级缓存：完全相同的查询直接返回缓存结果（FAQ 类场景命中率可观）。语义缓存：问题换个说法但意思一样也能命中，用向量相似度匹配历史问答，命中阈值要设保守，答错的缓存比不缓存更糟。前缀缓存：很多模型厂商对相同前缀（长的系统提示词）有折扣计价，把稳定内容放前、动态内容放后，白捡的折扣。
第三层：模型路由。不是每个请求都需要旗舰模型：意图分类、格式转换、简单改写用小模型，复杂推理才升级大模型。实现可以从规则起步（按任务类型定档），再演进到模型自己路由（先过一个小模型判断难度）。粗略的量级判断：路由得当能砍掉一半以上的模型成本，因为多数请求其实很轻。
第四层：架构手段。批处理接口（不赶时间的离线任务用 batch 价，通常是半价以下）；自托管小模型处理超大调用量场景（要算 GPU 成本盈亏点）；以及谈判：量大了找厂商谈阶梯价，这最朴素但经常有效。
落地的度量基础：先埋成本指标：每次调用的 token 数按「输入/输出/模型档位」拆开记录，按天看曲线。没有成本归因，优化就只能凭感觉。
面试官会怎么追问
- 语义缓存的风险怎么控？ 相似不等于可复用：「退款政策」和「退款到账了没」向量很近但答案无关。阈值调高、命中时带出原问题供用户确认、高危场景（交易、法务）直接禁用语义缓存。
- 怎么判断该自托管了？ 算月调用量对应的 API 账单和 GPU 推理成本（含运维人力）的交叉点，一般要到相当大的稳定量级才划算，小规模自托管多数是亏的。
- 成本和延迟冲突吗？ 常常一致：省 token、上缓存、换小模型同时降低延迟和成本，所以优化时两个指标一起看，很少真正二选一。
回答的坑
- 一上来就说「换便宜模型」。跳过省 token 和缓存直接换模型，质量损失立现，顺序错了。
- 没有度量意识。成本优化前先有成本归因，这个习惯面试官很看重。
同系列的题
—— 本题完 ——