如何估算大模型功能的成本，并在不明显降质的前提下降本？

面试时怎么答

成本估算的口径应是“完成一个成功任务花多少钱”，而不是请求单价。把输入输出 Token、检索、工具、重试、缓存、GPU 空闲和人工接管画成成本树，再按无效上下文、缓存、模型路由的顺序找优化点；每项降本都要守住质量、安全和重试率。

可以这样答：

LLM 成本不能只用请求数乘单价，而要算完成一个业务任务的总成本。拆成输入输出 Token、向量检索、工具调用、失败重试、缓存、GPU 闲置和人工接管。降本可以先去无效上下文、做前缀缓存，再按任务难度路由模型，但要防止小模型导致更多重试。实际应看的是每成功任务成本，同时看任务胜率、平均 Token、重试率、缓存命中率、P95 延迟和人工接管率，确认省下的不是表面账。

核心回答

先按真实流量拆账，而不是只看模型标价。托管 API 的可变成本通常可写成：未缓存输入 token、缓存输入 token、输出 token、工具或检索调用分别乘以对应单价，再加重试、失败请求和离线评测消耗；自建服务还要计入 GPU 空闲、冗余、存储、网络和运维。用请求量与输入/输出长度的 p50、p95 估算常态和峰值，并按租户、功能、模型版本归因。

降本顺序通常是：删除无效上下文，限制无界输出和 Agent 步数，复用稳定前缀，给重复读取做缓存，让简单任务路由到经过评测的小模型，最后再考虑量化或批处理。每一步都要在固定评测集和线上业务指标上验证，不能只比较 token 数。

展开说明

需要特别检查几个容易漏算的放大器：

• 长度长尾：平均值会掩盖少量超长上下文，成本预算应同时看分位数和上限。
• 输出与循环：max_tokens 是上限而非必然消费量，但宽松上限、工具循环和自动重试会放大尾部开销。
• 缓存条件：前缀缓存通常要求相同内容保持相同顺序，因此稳定的系统说明与共享示例应放前面，用户变量放后面。
• 成本与质量耦合：盲目截断上下文或更换小模型可能降低任务成功率，导致人工接管和重试成本上升。

成本指标最好落到“每个成功任务成本”，而不只是“每次请求成本”。

工程实践

为每次调用记录模型快照、输入/输出/缓存 token、重试次数、路由原因、任务结果和租户成本中心，但对原始文本做最小化采集与脱敏。上线优化时采用同流量回放或小比例灰度，比较质量、p95 延迟、缓存命中率和每成功任务成本；给日预算、单任务 token 和最大步骤设置硬上限及告警。

常见追问

1. 为什么按请求数估算 LLM 成本往往不准？ 请求的输入输出长度、模型路由、工具次数和重试概率差异很大；同样一千次请求可能对应完全不同的成功任务数。
2. Prompt Caching 与业务层响应缓存有什么区别？ Prompt Caching 复用前缀计算，仍会生成后续结果；响应缓存直接复用答案，对语义、权限和时效一致性要求更高。
3. 如何判断换成小模型是真降本，而不是把成本转移给重试和人工？ 按端到端成功任务计算成本，并同时纳入升级大模型、重试、人工接管和质量损失，而非比较单次 Token 单价。

一句话复习

先按真实 token 与任务成功率建立成本账本，再通过减上下文、控循环、缓存和路由逐层优化。

参考资料

• 面试题来源：AI Engineering Interview Questions 的生产成本题
• 官方依据：OpenAI Prompt Caching 指南、OpenAI Token 计数指南