1. 预算到底是被谁吃掉的先拆解那张让人肉疼的账单1.1 一个“小流量但高消耗”的问答应用翻车现场我最近在跟进一个知识库问答应用核心场景并不复杂用户选一份文档然后让大模型基于文档内容回答问题。日活几百人很多页面还是静态展示理论上API调用量应该很有限。结果月底对账的时候账单数字比团队预估的高出好几倍。A同学截图发到群里以后我第一反应不是“模型太贵”而是直接去翻调用链路的日志。翻完就清楚了问题根本不在“回答一个问题多少钱”而在一次用户请求的背后模型被悄悄调用了好几轮。这类翻车现场在团队里非常常见。为了让答案更准确我们先调用一次小模型判断用户意图再把整篇长文档拼进上下文让大模型生成答案之后又觉得原文太长再让模型输出一版摘要。一个问答请求背后可能藏着三四次模型调用每次调用都完整计费。更隐蔽的是这些中间调用经常没有日志埋点月底看到账单时已经无法回溯每一笔花了多少。所以要控制大模型成本第一步永远不是“换便宜模型”而是先把全链路的调用关系画出来弄清楚每一笔钱到底产生在哪一个环节。1.2 成本基本公式以及三个最容易漏掉的隐藏入口不管用哪一家大模型API计费的基本逻辑都是按Token走而且输入和输出Token的单价往往不一样。大致可以归纳成这么一条公式单次请求成本约等于输入Token数乘输入单价再加上输出Token数乘输出单价。输出Token通常比输入更贵因为生成内容比读取已有内容消耗更多算力。所以很多优化动作只盯着输入词数却忽略了输出长度同样可能成为第一大头。除了目标函数本身还有三个隐藏入口特别容易漏掉。第一个是系统提示词过长。有些产品把几十条规则、背景说明、few-shot示例一股脑塞进系统提示词每次请求都带着这一大坨。只要请求量级一上来光固定输入就会把账单撑大一大截。第二个是日志回灌和调试链。开发调试时反复调用会计费生产环境把每次完整响应写进日志后续又拿日志去喂模型做摘要或质检相当于同一段内容买了两次单。第三个是重试机制。网络抖动、上游超时都会触发自动重试如果上一次请求已经在服务端生成了部分内容这笔费用一样要算重试一次可能就是双倍成本。1.3 模型档位价差最大的浪费往往来自“一锅端”很多产品团队的习惯是所有请求都统一走旗舰级模型图省心。但真实项目的流量分布不是均匀的固定话术回复、简单标签抽取、格式转换这类任务让一线轻量模型来做完全是杀鸡用牛刀价格却可能是旗舰模型的五分之一甚至更低。只有真正涉及复杂推理、长文分析、多轮纠错的请求才值得把最贵的算力用上去。我按项目经验大概分过一档任务类型典型场景建议模型档位理由简单重复问候语、固定FAQ、关键词回复轻量模型规则或模板可覆盖调用频繁但成本极低中等理解标签抽取、意图识别、单文档摘要中型模型能力够用价格适中质量稳定复杂推理多文档比对、长链条推理、代码排错旗舰模型效果优先必须严格控制请求频次这张表看起来朴素但大多数项目真正可优化的空间就在分级上。简单问题不要占用贵模型复杂问题也不要硬塞给便宜模型否则账单和效果会一起崩。2. 提示词瘦身和输出控制趁Token还没进账先把钱省下来2.1 提示词不是越长越好而是“够用就好”不少人调提示词有个误区总觉得写得多、写全面效果才会稳。实际上提示词里的大部分修饰语对模型来说属于冗余噪声不仅提高输入Token成本还可能削弱真正的指令。我在问答应用里做过一轮系统提示词瘦身把原来一大段固定文本拆成参数化模板只有和当前问题相关的知识片段才会在请求时动态拼进去。具体操作可以按三步走。第一步把所有恒定不变的指令抽到公共模板里能放进版本配置的就不套在用户上下文中第二步把文档内容先做切块和索引只选择与用户问题最相关的几块拼进上下文而不是把整份文档都拖进来第三步few-shot示例只保留最必要的两三条示例越多每次请求额外支付的固定成本就越高。这轮调整做完我们线上平均输入Token直接降了约四成而效果几乎没有变化。2.2 输出Token才是更容易失控的那一半输入Token再大至少在请求发出前还能估算和控制输出Token是模型现场生成的谁也猜不准它会写多少。尤其是提示词里写“请详细说明”“请补充更多建议”这类话模型会很听话地输出长篇大论账单立刻失控。我们后来查线上统计发现平均输出Token居高不下根源就是产品引导语鼓励用户问长问题同时提示词又要求模型“多角度、多维度分析”。控制输出可以用几招组合在API参数里设置合理的最大输出上限别让模型无限发挥提示词里明确写“直接给结论不要解释过程”如果是基于文档找答案就要求“只引用原文不添油加醋”。这些调整都很基础生效却极快。但这里有个坑要提醒最大输出上限如果设得太小答案会被截断用户看到的是一段残句反馈变差后又会逼着你切到更贵的模型去补效果两边都在花钱。所以这个参数要结合真实长尾问题反复试找一个既不会截断关键答案、又能压住废话的临界值。2.3 结构化输出让模型从“写作文”变成“填表单”把输出限定成JSON或者其他固定字段格式不只是方便程序解析更是一笔成本账。结构化输出从机制上压缩了寒暄、过渡句和补充说明的空间回复长度天然减小。比如在知识库问答里我们不再要求模型输出大段文字而是固定输出“结论、依据、置信度”三个字段前端拿到数据以后直接渲染。同一批问题做过对比自由发挥版本平均输出接近四百个Token结构化版本平均只有一百八十个左右输出费用差不多省了一半。结构化的关键不是简简单单在提示词里写一句“请返回JSON”而是要配合严格的解析和校验。模型偶尔会返回不合规范的格式程序解析失败后又去请求一次一来一回就是重复计费。要么在提示词里给一个最小可用示例要么用约束解码能力把输出格式固定住别让纠错成本转嫁到下游。3. 模型分级路由让简单问题不再占用旗舰模型3.1 路由设计的两条路线规则优先模型打分兜底模型路由是整个成本优化里见效最快的一环。理念非常直白根据请求难度把流量分到不同档位模型上能便宜解决的就不请专家。但落地时有个经典难点——怎么判断一个问题到底难不难完全靠规则会漏掉大量边界情况完全靠模型打分则意味着每个请求都要额外调一次分类模型分类成本又抵消一部分收益。我建议用“规则优先模型打分兜底”的两级方案。第一级是规则分类器判断请求里是否包含特定专业术语、是否出现“对比”“总结全文”“写出推理过程”这类强指令只要命中就直接分流到对应档位。第二级是轻量分类模型兜底规则分不出来的请求交给一个小模型打难度分分数低的走便宜档位分数高的才升级到旗舰。这样绝大多数请求在第一级就完成了分流真正需要额外调用分类模型的占比很小回归算力成本几乎可以忽略。3.2 一份可以直接抄的路由配置样例下面这份配置不是唯一答案但结构非常有代表性。它先定义优先级规则再定义兜底分类的阈值然后按顺序匹配请求包含“产品名/价格/保修”等明确业务关键词且文本长度较小直接走轻量模型请求包含“对比”“总结全文”“给推理过程”“对比优缺点”等高频复杂指令直接走旗舰模型其余请求交给轻量分类模型难度评分高于阈值才升级低于阈值一律走轻量模型这里有两个细节非常关键。第一个是路由层本身也要做缓存和熔断不然分类模型一旦出故障在线请求全部阻塞只能干等。第二个是路由规则会随着产品功能迭代而失效最好每两周复查一次分类准确率看看哪些简单问题被误判去了旗舰哪些复杂问题被漏判去了轻量。我见过不少团队上线路由后就再也不管结果业务改了话术、换了领域旧规则悄悄把高难度请求送进便宜模型用户投诉一堆再回头改已经很被动。3.3 路由上线后的实际收益效果没降费用直降路由在问答应用里上线后我们统计了分流比例大约只有27%的请求最终走到了旗舰模型其余全部落在轻量或中型模型上。整体API费用下降了一半还多线上质量抽查评分基本持平。业务场景本来就是典型二八分布少部分复杂问题需要强推理大部分请求靠轻量模型足够。路由把资源按需分配是在不牺牲体验的前提下把成本结构彻底换了一遍。这里要把账算清楚不能只看平均单价。路由的价值还在于它让后续优化有了入口当你想继续降本时只需要盯住“哪些旗舰请求被过度服务”这件事继续拆解那一部分请求的共性就能往下压当你觉得效果不够时也能精准定位哪些请求被错送去了便宜模型。整个优化循环由此变得可控。4. 缓存与批处理重复问题和离线任务不该每次都重新花钱4.1 用缓存挡掉重复请求从精确命中到语义命中知识库问答有一个明显特征用户的高频问题高度重复问法略有变化但答案指向的是同一条文档内容。如果每个问题都真金白银地调用大模型那等于你在同一份答案上反复买单。缓存是这里性价比最高的方案没有之一。第一层是精确缓存把归一化后的用户问题组合上参数做键命中了就返回历史结果。这一层只能挡住完全相同的请求命中率通常不高但实现成本几乎为零。第二层是语义缓存把用户问题向量化再和历史问题算相似度超过阈值就复用当时的答案。这一层能把“保修期是多久”和“多久保修”这类同义不同形的请求也挡在外面。需要注意缓存必须有合理时效知识库内容一旦更新以前生成的答案就不能继续复用否则用户在同一套问题下得到的永远可能是过期信息。我们当时给缓存加了版本号文档库更新时整库失效简单粗暴但非常有效。4.2 离线批处理把批量任务放进队列而不是同步逐个调用很多团队会忽略任务形态对成本的影响。产品里那些报告生成、批量润色、定时总结等功能最忌讳的就是用一个同步循环去逐个调API。串行太慢高并发又容易触发限流限流一出现就是重试重试账单往往比主流程贵得多。离线任务天然不要求秒级返回就不该按在线请求的方式去烧钱。正确处理是统一进入消息队列用固定并发数消费同时优先利用厂商提供的批量接口。不少平台对这类非实时任务有价格折扣允许更长的处理时间把耗时体现在产品文案里用户看到的只是“任务生成中”。我们后来把定时日报生成改成队列加批量接口单次任务成本基本砍半而且再没有出现过限流重试的隐性支出。4.3 超时、重试与并发三个参数直接影响你的账单性能优化时常会调整超时和重试参数但很多人没意识到这个动作本身可能变成成本黑洞。上游响应稍慢客户端立刻超时触发重试但上一次调用其实已经在服务端产生费用结果是用两倍甚至三倍成本换一个“响应及时”的假象。我的建议是区分读场景和写场景。读场景可以适当放宽超时、减少重试次数把用户的等待感交给流式输出和过渡动画去缓解写场景则务必做幂等设计重试之前先确认上一次请求到底有没有成功。并发数对成本的影响更加直接。并发太高限流概率上升重试增多账单涨并发太低任务排队积压体验崩。一个实用做法是设置“并发水位线”从低并发慢慢往上压观察失败率和账单增幅找到稳定临界点以后固定运行。不要全凭感觉拍一个大并发数很多隐性成本都是这么“拍”出来的。5. 响应速度和成本本来就是同一件事性能优化别只会调大并发5.1 流式输出首字节延迟下降用户感知完全不同大模型调用天然慢动辄几秒甚至十几秒。大多数团队遇到“慢”的第一反应是升级模型、加并发、上服务器但却忽略了慢的本质可能来自“总响应时间”和“首字节时间”的错位。开启流式输出以后模型边生成边返回用户几乎在几百毫秒内就能看到第一个字等待焦虑大幅缓解。这项功能不一定直接省钱但它能避免你为了解决“慢”而花更大代价去升级模型或加机器。很多时候产品不是真慢而是把全部内容攒完才吐出来。5.2 上下文精简变快和变省是同一件事请求慢的一个核心原因是上下文太长。输入Token增加模型要读取的内容变多计算耗时和费用同步上涨。所以我做性能优化的第一件事往往不是改服务框架而是去看线上平均输入Token。如果发现每个请求都带着一整本手册的全文那不管换什么模型都很难快得起来。处理办法和提示词瘦身一脉相承静态上下文压到最小文档按相关性动态切片真正相关的片段才进入请求。对话轮数多的时候还要做历史压缩。问答应用很容易积累几十轮对话如果每轮都把完整历史拼进去上下文会越滚越大。我们的做法是当轮数超过阈值时先把此前多轮对话做一个摘要再带着摘要继续往下既保住了上下文连贯性也把单次请求的延迟和成本一起降下来。滑动窗口加摘要的组合在所有长会话场景里几乎都适用。5.3 限制和降级与其让所有请求都慢不如保关键请求更快并发一高所有请求都在排队等待整体体验反而下降。我倾向于在网关层做一些优先级划分核心问答请求优先占用配额聊天、润色、灵感生成这类辅助功能可以排队甚至降级到更便宜的模型。这个思路和机房里的带宽保障相似总资源就那么多关键业务保住了非关键业务先缓冲一下产品体验整体反而更稳。这里要特别强调限流不能只看每秒请求数更要关注Token消耗速率。不同请求消耗的Token差异极大按请求数限流很容易漏掉那些“吞Token大户”。把每分钟累计Token数和每分钟调用次数放在一起看往往能发现几个平时根本注意不到的异常场景修复之后成本回落非常明显。6. 自建模型还是继续调API这笔账必须按流量算清6.1 两种模式的成本结构完全不同流量起来以后很多团队会动心“自己部署开源模型省掉API费”。这个想法本身合理却经常低估自建的隐性成本。API是按调用量计费用多少花多少团队请求少时它不会追着你收钱自建则是先付固定成本服务器、加速卡、带宽、存储、运维人力都要按月摊不管有没有请求这笔钱都得出。两者的分水岭在于月请求量和平均单次成本。可以粗略这么算假设每月请求量是M一次请求用API的平均成本是C自建方案每个月折算的固定摊销加运维成本是F。只有当M乘以C明显大于F时自建才有账可算。流量还没起来就强行自建只会背上沉重的运维包袱。判断公式虽然简单但团队常犯的错误是只拿单次调用成本去做对比完全不看固定成本摊销。6.2 硬件和量化方案不是越强越好而是匹配最重要如果决定自建开源权重模型参数量、量化精度和硬件规格必须一起考虑。一个中等规模的开源权重模型通过4bit量化以后在单卡或双卡级别的图形加速卡上也能跑出可用效果适合问答、抽取、改写这类中间任务。但量化会带来一定效果损失复杂推理场景未必合适显存不足时模型频繁搬运数据延迟可能比调API还要高。所以自建前必须先做负载测试不能只在测试环境里跑一条SQL就下结论。最容易忽略的还有吞吐测试。不能只看“跑通”要看在目标并发下的每秒处理量。很多团队租了昂贵机器业务峰值只有几十路并发机器空闲率极高固定成本却月月扣。这种情况退回API反而更划算把省下来的运维精力投到产品迭代上性价比要高得多。6.3 混合部署让钱花在最需要的地方我最后的选择往往不是“API或自建”二选一而是混合部署。简单、高频、格式固定的请求尽量走自建轻量模型数据敏感、不能出内网的场景更是如此复杂、低频、需要最新知识的请求继续走在线API。路由层根据流量特征把请求分流到两边既享受自建的边际成本优势又保留在线API的强能力。混合部署确实多一套运行环境多一套监控和故障处理所以更适合让非核心场景先小范围试点稳定后再逐步扩大不要一上来就把核心链路全切过去。最后再补几句心里话这个系列做到1.11我自己最大的感触是大模型成本控制本质上就是一个资源分配问题不是单纯“省吃俭用”而是把有限预算投到产出最高的地方。对我个人来说最有用的工具不是某个神奇的优化器而是一张带着Token计量、请求量、缓存命中率、档位分布的成本看板。数据齐了以后所有优化动作都有了反馈哪里在烧钱、哪里该加钱一眼就能看到。如果让我重新做一遍知识库问答应用我一定会先把计量埋点做完再上线而不是等到月末账单出来以后拍大腿。这个习惯看起来不起眼却能为后续每一轮优化省下一半时间。最后再提一个小建议把输出Token上限当成正式配置项来评审别让它在代码里随便躺着一个默认值。这一条在很多项目里比大多数人想象的要更值钱。