Q74 · 控制大模型应用成本，你会优先从哪些层面下手？

一个耳机售后助手每天回答大量“订单 A123 到哪了”“这款耳机可以退吗”之类的问题。账单上涨时，团队最容易想到“换便宜模型”。但如果“查物流”本来可以由订单接口直接返回，却先调用模型分类、再让 Agent 连续查三次订单、最后把整份政策和几十轮聊天记录塞给模型，即使换了模型，浪费仍在。先看清一笔任务的钱花在哪一步，再消除多余调用，最后才细调每次调用的价格。

OpenAI 当前的成本优化指南也把减少请求数、减少 Token、选择合适模型列为主要方向；时延优化指南还提醒“有些步骤不必默认调用大模型”。本文用虚构计价单位解释计算，不引用任何厂商的现行报价；真实价格、缓存计费和批量政策可能变化，实施时应以所用服务的官方价格页与实际账单为准。

术语与符号

术语或符号	零基础解释	售后助手里的对应物
任务 / 请求	用户要完成的一件事；一次任务可能包含多次模型、检索和工具调用	回答 A123 能否按政策退款
调用	向模型或外部服务发出一次请求	让模型生成售后答复
Token	模型计量文本的单位，不等于一个汉字；不同模型切分方式不同	问题、政策片段、历史消息及回复所占的计量单位
输入 / 输出 Token	送入模型的内容 / 模型生成的内容	订单事实和政策 / 回给顾客的话
上下文	一次模型调用能看到的输入材料	系统指令、当前问题、必要历史、检索证据
RAG	先检索相关资料，再让模型据此回答	从政策库取当前退款条款
模型路由	按任务难度选择模型或非模型流程	简单问候走模板，复杂政策冲突交给更强模型
缓存	重用先前计算或结果；需区分缓存对象与有效期	重用相同提示词前缀，或重用仍有效的公开 FAQ 答案
批处理	把允许晚些完成的任务异步提交、之后取结果	夜间给大量工单做分类
并发	多个互不依赖的步骤同时进行，主要影响等待时间	同时查订单和政策版本
命中率	可复用缓存的请求比例	100 次模型调用中有多少次重用了前缀
端到端时延	用户提出任务到收到结果的总耗时	A123 提问后等多久得到答复
成功任务	达成业务目标且符合安全规则的任务	条件答对、有来源、没有错退
I / O	一次模型调用的输入 / 输出 Token 数量	例中 I=6000、O=600
p_in / p_out	每千个输入 / 输出 Token 的假设计价单位	例中分别为 1 单位和 4 单位
C_task	完成一笔任务所花的总成本	模型、检索、工具、重试成本之和
N	同一统计期内处理的任务数	例中 1 万笔售后问题

先拆一笔账，避免“降价了但账单没降”

图展示的是决策顺序：先按任务拆账，再操作主要成本项，最后复测质量。图中的三个拨杆并非都要同时调到最小；减少 Token 可能删掉关键政策，换模型可能降低复杂案例准确率。检索和工具也可能收费，图右边的质量门要结合下文的时延、安全与人工接管一起检查。

以“订单 A123 已拆封，问能否自动退款”为贯穿例子。假设应用需查订单、检索当前政策、生成答复；当前政策的教学规则是“签收后 7 天内且未拆封才可自动退款；已拆封且有故障可以申请质检，结果待定”。A123 于 2026 年 9 月 20 日签收，已拆封，评测日为 9 月 25 日。正确答复是“不能直接自动退款，可申请质检，退款结果待定”，不能省掉“已拆封”这个条件。

先给每次任务一个关联编号，把所有模型调用、检索、工具、重试和缓存状态串起来。至少记录任务类型、是否成功、模型及版本、输入/输出 Token、缓存读写或命中、检索次数、工具次数、外部服务费用、总时延和失败原因。账单的基本关系是：

单次模型费用 = (I / 1000) × p_in + (O / 1000) × p_out
C_task = 本任务所有模型调用费用 + 检索与工具费用 + 重试等额外费用
每成功任务成本 = 统计期总成本 / 同期成功任务数

公式里的 I、O 是模型实际计量结果，p_in、p_out 是所选计价方式下的单位价格；缓存命中、不同输入种类、推理 Token、工具计费等具体口径应按供应商账单拆分，不能套一个公式估所有产品。每成功任务成本比“每次调用费用”更接近业务目标：把一次大调用拆成三次小调用可能看似每次便宜，却让整笔任务更贵；省掉必要的检索也可能让回答错误、重试和人工处理增加。OpenAI 成本优化指南

用纯假设数字算一次：若 A123 任务只做一次模型调用，I=6000、O=600，假设计价是输入 1 单位/千 Token、输出 4 单位/千 Token，那么模型部分为 6000/1000×1 + 600/1000×4 = 8.4 单位。若 1 万笔任务输入结构相同、无缓存与重试，模型部分为 8.4×10000=84000 单位，尚未包含检索、工具、存储和人工成本。这组数字只用于算术示范，既非真实币种，也不是当前任何模型的价格。

如果通过证据筛选把输入从 6000 降到 3000 Token，输出仍为 600，且质量不下降，那么模型部分变成 3000/1000×1 + 600/1000×4 = 5.4 单位/任务；同样 1 万笔为 54000 单位，模型费用在这组假设下减少约 35.7%。如果答案遗漏了质检途径而需要人工补救，账面上的 3 单位节省就不能直接算净收益；还要计入返工、投诉和业务损失。

第一层：先判断这一步需不需要模型

最先排查无效调用和重复调用，往往比微调提示词更直接。A123 若只问“物流到哪”，页面已有用户认证与订单号，应用可由受控订单接口取状态，再用固定模板显示；无需让大模型先识别显而易见的按钮意图，也无需让它复述物流状态。对于需要解释复杂退款条款的自由提问，再考虑检索加模型。判断标准不是“这类问题简单”四个字，而是能否由确定性规则、受控数据和固定格式可靠完成，并在边界输入上验证。

接着看每笔任务是否重复做了同一件事：Agent 查完 A123 订单后又查两次相同参数；政策结果已足够却继续搜索；模型连续调用三次，只为先改写问题、再判是否需要检索、再写答案。可用明确的停止条件、工具结果缓存和流程合并减少调用。不过合并步骤也可能让错误难定位，需在回归集核对。OpenAI 的时延优化指南提出减少请求、在合适时合并步骤，并明确建议不要默认用 LLM 处理所有步骤。

正常例子：用户点击“查物流”按钮，权限验证后直接查 A123 的物流接口，模型调用从一次变为零，答复仍准确。失败边界：把“耳机有杂音，按现行政策怎么处理”也硬套物流模板，虽然零模型费用，却答非所问。对“能否自动退款”这类涉及政策与订单条件的问题，至少要确保版本正确、关键条件齐全；降低成本不能绕过授权和退款判断。

第二层：按任务难度选模型，算上升级与重试

模型路由可以把高频、低风险、可清楚验收的任务交给成本较低的模型，把复杂政策冲突、长文档归纳或高风险决策交给能力更强的模型或人工。这里的“高/低”都是在自己的测试集上测出的能力与费用，不能凭模型名称或单价判断。比如常见 FAQ 的意图归类可尝试较省的模型；A123 已拆封且政策与人工流程相交，仍须在复杂样本上验证输出是否正确。模型选型还会随版本和定价变化，需以当前官方模型目录及价格页核对，而非写死某个型号与价格。

低价模型若 20% 的任务需要再交给强模型，整单成本不是“低价模型一次”而是“低价模型一次 + 升级那部分的强模型调用 + 增加的时延”。如果先让小模型判“是否复杂”，这个判断本身也要计费和评测。可先对各任务类型用固定样本测通过率、费用与时延，设升级条件：缺必要证据、格式校验失败、政策冲突、输出不确定或触及高风险动作时升级。不要让模型自报一个未校准的“我有 95% 把握”就自动批准退款。OpenAI 成本优化指南

第三层：给上下文和输出设预算

输入 Token 常来自系统指令、工具定义、历史消息、检索片段和用户当前问题。逐项量化后再缩减：只保留回答 A123 所需的现行政策条款和订单条件；检索结果先去重、按版本与权限过滤、再筛掉无关段；长对话保留最近相关轮次与经核实的关键事实，而不是把前几十轮原文全部重发。输出也要按业务需要限制长度，售后答复可简洁说清结论、原因与下一步，无需每次生成长篇政策复述。OpenAI 时延优化指南

不能按字符数或“取前 500 字”粗暴截断。假设条款写“7 天内且未拆封”，截断把“且未拆封”去掉，会让 A123 被错判可自动退款。优化要以保留关键条件和来源为前提，做缺条件、旧政策、资料冲突等回归样本。若更短的输入让答案正确率下降或人工接管上升，账面 Token 节省就要重新计算。不同模型的 Token 切分和上下文上限不同，应该读取实际用量而不是用中文汉字数估账。OpenAI Token 计数文档

第四层：分清提示词缓存、结果缓存与资料缓存

提示词缓存重用模型对相同输入前缀的处理：如果多个售后请求共享固定指令、工具定义和常用资料，把稳定部分放前面、每位用户的订单信息放后面，可能提高重用率。它通常仍需处理新问题并生成新答案，不等于直接返回上次的答复。是否命中、读写如何计费、有效期与最低可缓存长度都依模型和供应商机制而定，需要看实际使用量，不要为凑缓存长度盲目塞字。OpenAI Prompt caching 文档

结果缓存则是应用保存最终答案或中间结果。例如“通用的耳机保修说明”在政策未变时可重用；但“A123 当前物流”随时间变化、含用户隐私，必须按用户与订单隔离，并设合理有效期，不能把甲的订单答案返给乙。资料缓存可以暂存当前版本政策或只读工具结果，减少重复检索与外部接口调用；更新政策时要失效旧版本。三种缓存各省不同的计算，命中率和节省额也要分别记录。对 A123 的退款资格，哪怕政策文字相同，仍须重新核实订单事实与权限。

第五层：检查 RAG、工具和 Agent 的隐形成本

RAG 不只花一次模型费。知识库入库需要切分、向量化与存储，在线查询可能用检索、重排、模型生成和引用校验；不同服务可能按存储、调用或用量计费。无需检索的固定业务数据应直接查受控接口；需要政策依据的回答才取最少但足够的片段。Top-k 的 k 是“取前几个检索结果”，不是越小越好：A123 至少要保留自动退款条件和质检途径，减成一段可能省 Token 却漏答案。适当做版本过滤、去重和重排，能少送无关材料，但自身也可能增加调用费用与时延，须比较整单结果。

Agent 的工具循环同样能放大成本：一次失败的订单查询可能触发多次模型重新规划、重复搜索与重试。给工具设置超时、重试上限、重复参数检测、停止条件和人工接管；失败时保留已取得的事实，不要无上限地“再试一次”。对有副作用的工具，不能为了省一次核验就跳过权限或幂等检查。记录每成功任务的平均/分位模型调用数与工具调用数，比只看单次模型 Token 更能发现这种浪费。

第六层：批处理降单位费用，并发主要缩短等待

“批量”和“并发”经常被混为一谈。批处理适合不需要即时答复的后台任务，例如夜间给历史工单分类、给政策库重建向量、运行回归评测；将任务异步提交后稍后取结果。以 OpenAI 当前 Batch API 文档为例，它描述了异步任务、单独的处理窗口和与同步接口不同的价格安排；具体折扣和时限会变，采用前核对当前文档与 SLA。用户在线问“A123 能退吗”通常等不起离线批任务，不能为单价更低牺牲交互体验。

并发是把相互独立的步骤同时做，例如在权限前置条件已满足的前提下并行查订单详情与现行政策，可能缩短端到端等待，但通常不会自动减少模型 Token 或工具调用次数。并发还可能增加峰值负载、限流和失败重试。若一项操作依赖另一项结果，就应保持顺序：没核实用户有权查看 A123，不能并发启动读取该订单的敏感接口。对并发优化要同时测等待时间、总调用量和错误率；对批处理要核对业务允许的完成时间。OpenAI 时延优化指南

每改一层，都用同一组任务做质量回归

成本优化应有基线：按“查物流”“咨询退款”“故障售后”等任务类型统计请求量、成功率、每成功任务成本、p50/p95 端到端时延与人工接管率。p50 表示半数任务不慢于该值，p95 用来观察慢尾；高风险任务还要看错退、越权查询、错误政策引用等独立的硬门槛。不能只用总账单：流量减少也会让账单下降，却没有提高效率。

改动后用同一批含正常与失败案例的样本对照旧版本，固定政策快照和业务规则，并记录模型、提示词、知识库和工具版本。至少重测 A123 已拆封、未拆封但超期、政策版本冲突、检索缺关键句、订单工具超时、用户无权查看等案例。若候选方案把 A123 误判可退款，哪怕平均成本低一半，也不能上线；若质量通过，再小流量灰度，观察真实成功任务成本、慢请求、升级到强模型比例和投诉。失败样本补入回归集。对成本报告可并列展示“质量、每成功任务成本、p95 时延、安全事故数”，不要把它们揉成一个无法解释的分数。OpenAI Agent 评估文档

实际优先级可按账单数据决定：

看到的最大浪费	优先试的改动	必须防住的反效果
简单查询也调用模型	受控按钮、规则或业务接口直出	把复杂问题错当简单问题
同一任务调用次数过多	合并相邻步骤、停止重复工具循环	合并后错误难定位、必要步骤被跳过
输入 Token 被无关历史和检索片段占满	过滤、去重、压缩、保留关键条件	截掉“且未拆封”等限制
简单任务全走高成本模型	在验证过的范围内模型路由	升级/重试增多，整体成本反升
大量固定前缀重复处理	测提示词缓存命中与读写成本	为缓存增加无用内容或混入用户私密数据
后台任务占用在线调用	对可延迟任务用批处理	把在线售后请求排进慢队列

面试时怎样回答

我会先把一笔成功任务的完整账单拆出来：模型输入输出 Token、调用次数、缓存命中、检索、工具、重试和人工接管，再按任务类型找最大成本项。通常先消除不必要的模型调用和重复工具循环，再在测试集上做模型路由、上下文筛选、输出长度控制与缓存。RAG 要保留足够的现行证据；批处理用于允许延迟的后台任务，并发主要用于缩短独立步骤的等待。每项改动都比较成功任务成本、正确率、越权或错退、p95 时延和人工接管，质量门槛不过就回退，而不是只看 Token 单价。

若追问“换最便宜模型不就行了”，可以用 A123 解释：便宜模型若漏掉“已拆封”，后续错退、重试与人工返工可能使整笔任务更贵，且违反业务规则。若追问“把所有请求并发会不会省钱”，应说明并发主要减少等待，通常不减少调用量；相互依赖的权限检查和敏感查询更不能乱序。

资料依据

• OpenAI：Cost optimization——减少请求、Token 与选型的基本方向。
• OpenAI：Latency optimization——少调用、并行和不用模型的适用条件。
• OpenAI：Prompt caching——相同前缀复用、命中与缓存成本的机制。
• OpenAI：Batch API——可延迟任务的异步批处理。
• OpenAI：Model catalog与Pricing——实施时核对当前可用模型与价格；本文未使用其具体报价。

继续阅读：Token 和上下文窗口意味着什么？、应用上线后看哪些指标？、如何做 Prompt 版本管理与回归？。