一个典型的 AI 原生开发团队会遇到这样的问题产品已经接入了大模型能力用户提问、多轮对话、内容生成都跑通了团队最初只关注“答案准不准”没有把模型调用成本当作第一优先级。上线一段时间后账单开始超预算而且很难定位问题。看 API 账单只能知道总额涨了但到底是因为用户量增长、Prompt 变长、重试太多还是某个功能模块的上下文策略设计不合理账单本身给不出答案。这种状态在 AI 原生开发项目中非常普遍。AI 原生开发不是“在传统应用里接一个 AI 接口”而是从产品设计、数据流、异常处理到评测方式都以大模型推理为核心来组织应用架构。推理成为业务主路径之后推理成本就从一个“后台账单”变成了必须纳入架构决策、代码评审和日常监控的技术指标。这篇文章围绕 AI 原生开发中的推理成本洞察按工程落地的顺序拆解成本到底从哪里产生如何在应用层度量成本如何通过 Prompt、缓存、模型路由和降级策略控制成本以及当成本异常飙升时如何通过日志和指标快速定位。最后给出一套可在学习环境和生产环境分别落地的成本治理清单。1. AI 原生开发的核心是“推理成为主路径”1.1 传统应用和 AI 原生应用的差异在哪里传统 Web 应用和后端服务的核心特征是确定性。请求进来后代码按已知逻辑执行输入输出可以精确预测数据库查询、第三方接口调用、任务调度都在可控范围内。虽然也要关心性能、并发和资源成本但单位请求的成本基本稳定扩容策略也相对成熟。AI 原生应用不同。大模型推理结果是非确定性的业务逻辑不再是一段完全可控的代码而是“给定上下文模型生成内容”。一个应用是否属于 AI 原生关键不在于“接没接大模型接口”而在于大模型是否承担了核心业务决策。例如一个客服工单系统如果大模型只是做关键词辅助分类这是传统应用接入 AI 能力如果系统把用户问题理解、知识检索、答案生成、追问处理、结果校验全部交给大模型链路完成这就是 AI 原生的形态。两种模式的区别会直接影响成本结构维度传统应用AI 原生应用业务逻辑代码确定输入输出可预测模型推理生成结果非确定每次请求成本相对稳定取决于 CPU、内存、接口调用波动大取决于 Token 数量、模型等级、上下文长度调试方式断点、日志、堆栈定位需要评测集、Prompt 版本、输出校验、人工抽检缓存策略按参数、用户、数据版本设计缓存键需要考虑语义缓存和 KV 缓存扩容约束主要看服务和数据库资源还要看模型推理延迟、并发额度、Token 消耗预算异常处理重试通常能解决问题重试可能造成重复计费需要更谨慎AI 原生开发中最容易犯的一个错误是把大模型当普通接口调用忽略“单次请求成本不可预知”这个本质。要对成本做控制必须先理解这个差异。1.2 推理成本的三个特点不确定、会累积、非线性推理成本不是传统意义上的 API 计费金额这么简单它有三个工程上必须重视的特点。第一个特点是不确定性。模型输入 Token 数量和输出 Token 数量在请求发出前难以精确预测。即使是同一个 Prompt 模板不同用户输入的长度不同不同批次的模型回复长度也可能差异很大。非流式调用可能返回完整结果后再计费流式调用则需要处理增量输出。这种不确定性意味着成本策略不能只写一条“估算一下”的口径必须在每次请求返回后记录真实 Token 消耗。第二个特点是累积性。多轮对话会把历史消息不断追加到上下文里。每一轮用户提问模型都要重新处理前面的历史内容。Round 1 消耗 1000 TokenRound 5 可能因为历史累积消耗 4000 TokenRound 10 可能更高。Agent 类应用更明显一次用户目标可能需要模型多次推理、多次调用工具、多次生成中间结果每一步都会累积消耗。第三个特点是非线性。这里的非线性指的是成本增长往往比业务量增长更快。用户量增长 20%如果 Prompt 没优化、上下文没裁剪、缓存没生效模型调用量可能增长 40% 甚至更多。多轮对话、工具调用、重试和上下文膨胀组合在一起成本曲线会比用户曲线陡峭得多。1.3 为什么成本必须是架构决策的一部分一些团队把成本控制放在上线后等到账单异常再去查。这时候能做的优化已经受限可能只能降级功能或砍掉部分场景。更合理的做法是把成本当作和延迟、准确性并列的约束条件在架构设计阶段就确定成本边界。具体来说AI 原生开发的架构设计至少要考虑三个问题一个业务动作最多允许多少次模型调用一次调用允许输入多少 Token每天或每月单个功能模块的成本预算是多少。这三个问题决定了 Prompt 模板设计、上下文管理策略、模型选择和缓存方案。没有这些约束后面所有优化都只能靠临场补救。2. 推理成本不是一张账单而是一条成本链路2.1 拆解一次 AI 原生请求的完整计费路径只按“模型调用一次收费一次”理解成本会漏掉很多真实支出。一次 AI 原生请求通常不是一个单次调用而是一条由多个环节组成的链路。用一个典型的 RAG 问答场景举例。用户提问后系统需要先对问题做向量化检索召回若干知识片段再把用户问题、知识片段、系统 Prompt 拼接到一起发送给大模型。模型返回答案后系统还可能做一次答案有效性校验如果答案不符合要求会自动重新组织 Prompt 并再次调用模型。这个过程中会产生成本的地方包括用户问题向量化如果向量化服务也按 Token 计费这会产生前置成本。知识片段召回为了提升答案质量系统可能把多个候选片段都放进上下文导致输入 Token 明显变长。模型主调用按输入输出 Token 计费。答案校验调用一次业务动作实际发生两次或多次模型调用。超时或限流重试每次重试都会再次计费。下面用一个简化的流程代码展示这种链路def handle_user_question(user_question: str, user_id: str): # 1. 向量化用户问题 query_vector embedding_model.encode(user_question) # 2. 检索知识片段 retrieved_chunks vector_db.search(query_vector, top_k5) # 3. 构造上下文知识片段全部拼入 prompt context \n\n.join([chunk.text for chunk in retrieved_chunks]) prompt build_prompt(user_question, context) # 4. 主模型调用 answer llm_agent.chat(prompt) # 5. 答案合理性校验 if not validate_answer(answer): # 这里会再次调用模型产生第二次成本 answer llm_agent.chat(build_corrective_prompt(prompt, answer)) return answer这段代码在功能上没问题但从成本角度看第 5 步是隐藏的成本放大器。一次失败校验意味着一次业务请求消耗了两次甚至更多次模型调用而且第二次调用的输入还附带第一次的答案Token 消耗更大。实际项目中这样的链路必须在每一步都记录调用次数和 Token 消耗。2.2 主要成本项拆解表AI 原生应用中推理成本可以进一步拆成以下成本项成本项来源典型放大原因输入 Token系统 Prompt、用户问题、历史消息、检索片段、工具描述上下文不裁剪历史消息无限增长输出 Token模型生成的答案、中间推理过程未限制 max_tokens模型输出过长缓存命中缓存降低重复计算未命中则重复支付缓存键设计不合理命中率过低重试超时、限流、输出校验失败业务侧无上限重试多次调用同一模型多轮对话历史消息每次重复进入上下文只追加不摘要越聊越长工具调用Agent 多轮决策、多次工具调用步数无上限每个工具调用都要模型再推理RAG 检索知识片段拼接导致输入变长召回数量固定且过多无关片段占据 Token批量与异步大批量任务未做聚合逐条调用单条请求重复系统提示词浪费输入预算这张表的作用不是让人把每个成本项都背下来而是提供一个基础映射任何一次成本发生变化都能对应到某个具体环节。比如某日账单上升如果平均输出 Token 没变但平均输入 Token 明显上升优先怀疑 Prompt 模板变更或历史消息累积如果请求量没变但调用次数上升优先怀疑重试逻辑或 Agent 步数。2.3 度量口径不要只盯着账单金额API 账单是供应商维度的汇总数据粒度通常是“日”“小时”甚至“总消耗”按模型维度统计 Token 数量。这个数据只能回答“花了多少钱”不能回答“哪个功能模块花了钱”“哪个 Prompt 版本花了更多”“哪类用户请求成本最高”。要在应用中建立自己的成本度量口径。核心原则是每次模型调用都必须记录可以用于成本归因的最小字段。通常包括请求 ID、业务功能、模型名称、输入 Token、输出 Token、缓存命中状态、重试次数、调用耗时和任务结果状态。有了这些字段后成本分析才能从总额拆到模块、从模块拆到 Prompt 版本、从版本拆到具体用户场景。这才是 AI 原生开发里“成本洞察”的工程含义。3. 先建立成本可观测性再谈优化3.1 在模型调用层统一封装AI 原生项目的代码里尽量不在业务代码中直接拼接大模型 Client而是统一封装一个模型调用入口。统一封装的目的有三个统一记录 Token 消耗统一处理超时、重试和流式结束统一维护模型路由和缓存逻辑。下面是一个最小封装示例用于说明记录成本的思路# llm_wrapper.py import time import json import uuid class LLMResult: def __init__(self, text, prompt_tokens, completion_tokens, model, cache_hit, latency_ms): self.text text self.prompt_tokens prompt_tokens self.completion_tokens completion_tokens self.total_tokens prompt_tokens completion_tokens self.model model self.cache_hit cache_hit self.latency_ms latency_ms class LLMWrapper: def __init__(self, client, cost_center): self.client client self.cost_center cost_center def chat(self, messages, feature, modeldefault, max_tokens1024, retry_count2): request_id uuid.uuid4().hex start time.time() attempt 0 while attempt retry_count: try: response self.client.chat.completions.create( modelmodel, messagesmessages, max_tokensmax_tokens, ) latency_ms int((time.time() - start) * 1000) usage response.usage result LLMResult( textresponse.choices[0].message.content, prompt_tokensusage.prompt_tokens, completion_tokensusage.completion_tokens, modelmodel, cache_hitFalse, latency_mslatency_ms, ) # 统一记录成本日志 self.cost_center.record( request_idrequest_id, featurefeature, modelmodel, prompt_tokensusage.prompt_tokens, completion_tokensusage.completion_tokens, cache_hitFalse, latency_mslatency_ms, retry_countattempt, ) return result except Exception: attempt 1 if attempt retry_count: raise return None这段代码的关键点在于所有业务代码都通过LLMWrapper.chat发起调用成本记录与业务逻辑解耦。实际项目中这个封装还可以扩展出模型路由、语义缓存、降级开关等功能。不要在业务代码里直接使用底层 SDK Client否则成本统计会漏掉一部分调用排查时也很难定位。3.2 记录结构化成本日志记录成本日志时推荐使用结构化格式例如 JSON方便后续写入日志系统、Elasticsearch 或 ClickHouse 做分析。一条成本日志的最小结构如下{ request_id: 7f3a9c0e2b1d4f6a8c5d1e2f3a4b5c6d, user_id: u_10086, feature: customer_service_qa, prompt_version: prompt_v20240601, model: default, prompt_tokens: 1850, completion_tokens: 320, total_tokens: 2170, cache_hit: false, latency_ms: 1450, retry_count: 0, success: true, estimated_cost: 0.0023 }estimated_cost字段可以由程序根据 Token 数量和模型单价计算。这里有一个工程细节不要把单价硬编码在业务代码里建议维护一张模型单价表避免因为模型价格调整导致历史成本估算全部失真。3.3 看板和告警让成本变化可感知成本日志记录之后还需要聚合指标和告警。常用指标包括总成本按天、小时聚合功能模块成本 Top N平均 Prompt Token 数平均 Completion Token 数缓存命中率模型调用次数与请求数比值重试率告警规则建议包含几类告警类型触发条件建议动作日成本环比增长同比增长超过 20%检查流量、Prompt 版本、路由配置单模块成本突增某功能模块成本占比超过阈值分析该模块平均 Token 与调用次数缓存命中率下降命中率下降超过 10%检查缓存键设计、数据更新、并发重试率上升重试率超过 5%检查模型限流、超时设置、下游依赖平均输入 Token 上升环比增长 30%检查历史消息裁剪、RAG 召回数量生产环境的成本日志建议与业务日志分离存储。业务日志通常关注用户行为和异常成本日志则是一个独立的可聚合数据源。两者通过request_id关联遇到用户反馈或故障时可以同时查看业务链路和成本链路。注意成本可观测性不是上线后才补的工作。模型调用封装、结构化日志、看板和告警最好在项目初始化阶段就建立因为这些基础设施一旦缺失后续优化会失去判断依据。4. 推理成本优化的常用手段4.1 Prompt 工程层面的成本控制Prompt 是 AI 原生应用中最容易优化也最容易失控的部分。每一段系统提示词、每一条历史消息、每一个知识片段都会转化为输入 Token直接影响成本。具体的成本控制手段包括精简系统提示词删除冗余说明只保留模型完成任务必要的行为约束。比如“你是一个乐于助人的 AI 助手”这类的装饰性内容可以去掉因为对任务结果影响很小却会占用每次请求的 Token。限制输出长度为每个模型调用设置max_tokens避免模型生成过长的内容。尤其要关注流式输出场景有些模型在没有明确长度约束时会把一段话扩展成很长的解释。历史消息裁剪多轮对话不能无限追加历史消息。超过一定轮数或一定 Token 阈值后保留最近的几条消息并把更早的内容做摘要用一句摘要代替完整历史。固定 Prompt 版本每次修改 Prompt 都要记录版本号方便成本分析时对照版本变化。def build_messages(user_input, history, system_prompt, max_history_tokens1200): messages [{role: system, content: system_prompt}] # 估算历史消息 token 长度超过阈值时只保留最近的消息 estimated_history_tokens sum(len(h[content]) for h in history) if estimated_history_tokens max_history_tokens: # 保留最近 4 条消息其余丢弃或摘要 history history[-4:] # 更早内容可以用 summary 替代而不是直接丢弃 summary summarize_early_history(history[:-4]) messages.append({role: system, content: f更早的对话摘要{summary}}) messages.extend(history) messages.append({role: user, content: user_input}) return messages这是一个很常见的工程处理方式在消息进入模型前先做一次 Token 估算和裁剪。实际项目中可以使用 Tokenizer 做精确计数而不只是按字符长度估算。4.2 缓存策略语义缓存和 KV 缓存缓存是 AI 原生应用中收益最大也最容易做错的一环。第二种是 KV 缓存。KV 缓存在模型侧或推理框架内部维护对于相同前缀的请求可以复用计算中间结果降低同一次服务调用中的部分计算成本。开发侧主要关注推理服务的配置和命中率例如在多轮对话中保持相同会话上下文让前缀一致从而提升 KV 缓存命中率。对于应用开发团队语义缓存是自主可控的优化方式。核心思路用户问题经过向量化后与历史问题做相似度匹配如果相似度超过阈值直接返回缓存答案不调用大模型。class SemanticCache: def __init__(self, vector_db, threshold0.92): self.vector_db vector_db self.threshold threshold def get(self, user_question): question_vector embedding_model.encode(user_question) result self.vector_db.search(question_vector, top_k1) if result and result[0].score self.threshold: return result[0].answer return None def set(self, user_question, answer): question_vector embedding_model.encode(user_question) self.vector_db.upsert(vectorquestion_vector, answeranswer)语义缓存适合用户问题重复率较高的场景比如企业内部的常见问题咨询、售后客服、产品使用帮助。如果用户问题几乎不重复缓存命中率会很低投入语义缓存的收益有限。缓存键设计是这里最容易踩的坑如果直接用完整文本做精确匹配个别字眼不同就无法命中如果语义向量相似度阈值过低又可能返回错误的答案。建议上线时先用阈值 0.90 到 0.95 区间做小流量测试观察答案准确率和缓存命中率的平衡。4.3 模型路由让请求匹配合适的模型不同业务场景对模型能力的要求不同。复杂推理、代码生成、长文档理解需要较强的模型简单问答、意图识别、格式转换可能用轻量模型就足够。模型路由的思路是在调用模型前判断请求的难度和业务优先级再决定使用哪个模型。一个简单实现是根据业务功能决定def route_model(feature, user_input_length, has_tool_callFalse): # 简单功能或短输入走轻量模型 if feature intent_classification and user_input_length 100 and not has_tool_call: return fast-model # 需要工具调用或长上下文时走主力模型 if has_tool_call or user_input_length 3000: return strong-model # 其他情况走默认模型 return balanced-model这只是最直观的路由策略。生产环境中路由条件可以根据实际效果动态调整先标记请求类别观察不同模型的回答质量、延迟和成本再调整路由规则。需要注意的是不要把路由逻辑做得过于复杂否则排查问题时又多了一层不确定因素。路由决策本身也要记录日志方便后续判断“某类请求被错误路由到昂贵模型”的情况。4.4 降级、批量与异步在流量高峰期AI 原生系统要有明确的降级策略。例如关闭 Agent 工具调用退化为普通问答关闭 RAG 检索只使用模型自身知识关闭长上下文优化只处理最近几轮消息。降级策略的代价是效果下降但对保证服务可用性和控制成本很重要。非实时场景不要走同步逐个调用。例如日报整理、批量内容审核、数据分析任务可以设计成异步队列批量调用模型减少系统提示词和上下文的重复构造。批量处理可以降低请求数量但对单个请求的 Token 消耗没有直接帮助最终效果取决于任务类型。流式输出场景要特别注意结束信号。客户端如果因为流式响应没有正确结束而发起重试每次重试都会重新计费。建议在流式输出中明确设置结束标记并做好响应校验。注意成本优化的前提是效果不劣化。任何减 Token、降级、换模型的措施都要在评测集上验证效果。不要在没有任何评测的情况下直接为了省钱把主模型切换成轻量模型。5. 推理成本异常飙升怎么排查5.1 先确认口径再查链路排查成本异常时第一件事不是找代码而是确认“成本上升”的口径来自哪里。是 API 账单总额上升还是自建看板聚合出的数字上升还是某个报表的估算金额上升三者口径不同结论可能完全不一样。确认口径后按以下顺序排查请求量是否变化。日活、请求量、并发量上升成本上升可能只是业务增长。平均调用次数是否变化。每个用户请求对应的模型调用次数是否增加重点怀疑 Agent 步数或重试逻辑。平均 Token 是否变化。分别看输入 Token 和输出 Token输入 Token 上升重点看 Prompt 版本、上下文策略、RAG 召回数量输出 Token 上升重点看 max_tokens 限制。缓存命中率是否变化。语义缓存或 KV 缓存命中率下降可能导致大量重复请求直接打到模型。模型路由是否变化。是否存在请求被错误路由到更贵模型的情况。是否引入新的重试机制。超时时间和重试次数的调整可能让成本成倍增加。5.2 用日志链路定位具体功能定位到具体功能模块需要依赖第 3 章建立的成本日志。排查的基本方法是按feature、prompt_version、model三个维度做分组聚合。假设成本日志存储在 ClickHouse 或 Elasticsearch可按类似 SQL 逻辑查询SELECT feature, model, count() AS call_count, sum(prompt_tokens) AS total_prompt_tokens, sum(completion_tokens) AS total_completion_tokens, avg(cache_hit) AS cache_hit_rate FROM llm_cost_log WHERE date 2025-05-20 GROUP BY feature, model ORDER BY total_prompt_tokens total_completion_tokens DESC LIMIT 20;结果如果显示某个 feature 的成本占比异常高再继续看该 feature 下的单次请求调用次数分布和 Token 分布。例如某个客服问答功能单次请求的平均模型调用次数从 1.2 涨到了 3.5那就能直接联想到 Agent 工具调用或答案校验逻辑引入了额外模型调用。5.3 常见成本问题与处理方案以下几个问题在 AI 原生项目中很常见。这里用表格列出典型现象、原因和处理方向问题现象常见原因处理建议成本上涨但请求量没涨Prompt 模板改动导致输入 Token 变长对比 prompt 版本改动回滚或裁剪用户多轮对话越用越贵历史消息无限累积对历史做摘要只保留最近几轮大量重试产生重复计费模型超时未合理处理或流式结束信号缺失设置合理超时重试次数上限设为 1 到 2 次使用流式结束标记做校验缓存命中率很低缓存键设计不合理或用户问题几乎不重复检查相似度阈值换用语义缓存或干脆取消缓存单模块成本异常高但没有新功能Agent 工具调用步数增加限制最大步数设置工具调用白名单对中间结果做校验请求被路由到昂贵模型路由规则过于粗糙或默认走强模型增加路由日志按业务功能细化规则默认改为平衡模型这个表格可以作为团队排查成本异常的 Starter 清单。实际排查中如果以上各项都正常再检查是否有批处理任务意外重跑、是否有客户端重复请求、是否有测试流量混入生产环境。5.4 三个容易忽视的隐藏成本点第一输出式流媒体中断导致的残次请求。用户如果中途断线服务端可能仍把已验证的完成请求算作真实消费。客户端离开页面后AI 会话管理仍保存上下文下次进入会继续累积历史。第二上下文无关的固定提示词重复计费。在一些批量任务中系统提示词完全相同却为每条记录分别拼入并支付输入 Token。批量处理时应该把固定提示词部分从每次调用中尽量抽离能不能拼一个长 Prompt 让模型一次性处理多条记录取决于任务类型。第三模型升级带来的隐性成本变化。模型 A 的输出会把“合理答案”扩展成长文模型 B 可能更简洁但有时模型 B 的输入 Token 对长上下文的计费系数更高。升级模型后如果没做成本对比可能发现质量下降的同时成本反而更高。6. 成本视角下的 AI 原生架构决策6.1 RAG 和微调的成本差在哪在 AI 原生项目中团队经常需要在“RAG 检索增强”和“模型微调”之间做选择。从推理成本角度看两者差别明显。RAG 的成本主要集中在每次请求的输入 Token 上。系统需要把知识切片拼入上下文召回片段越多输入越长。RAG 的优势在于不需要模型训练知识更新可以走索引更新新增知识条目的成本较低。劣势是每个请求都要承担额外的 Token 成本尤其当知识库片段较长时成本会被放大。微调的成本主要集中在模型训练、部署和持续维护上。一次微调需要准备训练数据、调整参数、评估效果并承担训练计算资源。推理时微调模型的输入中不需要加入大量知识内容单次请求的 Token 消耗通常比 RAG 场景更低但部署环境、模型版本和评估成本长期存在。这不是一个简单的“谁更便宜”的判断题而是要看数据更新频率和单次请求上下文长度。知识大量且频繁更新时RAG 更适合知识相对固定、对延迟和单次成本敏感时微调或混合方案可能更合适。工程上常见的做法是先用 RAG 快速验证效果确认某些固定知识确实需要模型额外学习时再考虑微调。6.2 Agent 步数必须设置边界Agent 类应用是成本失控的高危区。原因是 Agent 的每次工具调用都可能触发一次模型推理而模型又可能根据工具结果再次调用工具形成多轮循环。一次简单业务请求在 Agent 架构下可能变成 5 到 10 次模型调用。控制 Agent 成本的关键指标是“平均一次用户请求对应的模型调用次数”。这个指标应当被监控并且设置上限。当某类请求的平均调用次数超过阈值不应该继续放量而应该先优化 Agent 的工具描述、限制工具调用白名单、减少无效推理或者设置明确的最大步数。MAX_AGENT_STEPS 4 def run_agent(user_question): steps 0 while steps MAX_AGENT_STEPS: steps 1 action llm_agent.decide_next_action(user_question) if action.type finish: return action.result result execute_tool(action) llm_agent.add_observation(result) return 达到最大步数改为降级回答在这里MAX_AGENT_STEPS是一个架构级约束。它不是为了限制用户而是防止不可控的推理循环让成本无限扩大。允许的最大步数不是越大越好要根据业务需要和成本预算共同决定。6.3 模型选型要绑定预算阈值每个功能模块都应有“单次完成该业务动作的成本上限”。例如客服问答功能一次完整问答的 Token 成本预算为 0.01 元到 0.05 元如果某个解决方案估算后超出预算就需要调整 Prompt、缓存策略或模型等级。模型选型不是选最聪明的模型而是选在预算内能满足准确率的模型。团队应该维护一张“模型能力与成本对照表”记录每个模型在内部评测集上的通过率、平均 Token 数和调用延迟。模型版本升级前先在评测集上运行一次对比效果和成本而不是只看准确率提升了多少。7. 推理成本治理清单学习环境与生产环境7.1 学习环境如何快速跑通成本度量对于学习和 Demo 项目成本治理不需要一开始就做完整系统但至少要把“记录 Token”这个习惯建立起来。最小做法是在代码中统一封装模型调用入口。每次调用后打印或记录 prompt_tokens 和 completion_tokens。为不同 Prompt 方案保留简易的 Token 对比记录。设置一个固定的消耗上限避免开发测试时失控。学习环境下可以不用做真实账单和告警系统但核心原则是每次模型调用都要有迹可循。很多生产环境的成本问题早期在开发阶段就已经因为“数据没记”而被忽略。7.2 生产环境上线前检查清单生产环境上线的成本治理建议至少覆盖以下内容模型调用是否统一走封装层是否存在绕过封装的直接 Client 调用。每次调用是否记录 request_id、feature、model、token 数、耗时、重试次数。是否设置了 max_tokens 和合理的超时时间。重试次数是否有上限是否考虑重复计费风险。是否设计了缓存策略缓存命中率基线是否确定。Prompt 模板是否有版本号改动是否可回溯。每个功能模块是否有成本预算和告警阈值。除主链路外额外模型调用校验、摘要、二次生成是否有成本日志。是否建立了成本看板是否有人每天或每周检查。7.3 运行中的监控指标上线后持续关注以下指标这些指标反映的是成本健康度而不是单一的总金额指标健康信号风险信号日成本总量随业务量平稳变化无明显业务增长但总额翻倍平均请求模型调用次数接近 1Agent 场景接近预期步数持续上升且没有版本变更说明平均输入 Token稳定或有小幅优化持续上涨Prompt 版本反复膨胀缓存命中率语义缓存命中率高于预期命中率从 50% 跌到 10%重试率低于 3%超过 5%功能模块成本占比与业务量占比一致单模块成本突然超过 60%模型路由命中率预期模型占比符合设计大量请求被路由到最高价模型7.4 迭代后复盘清单每次 Prompt 变更、模型升级、Agent 逻辑调整或缓存策略变化都应该做一次成本复盘变更前后同一个评测集上的效果指标是否上升、持平或下降。变更前后平均每个业务动作的成本变化比例。变更引入的额外调用链是否被记录是否有新重试风险。缓存收益是否达到上线的判断阈值。是否需要对上一次设定的预算阈值做调整。把成本复盘纳入迭代流程团队才会逐渐形成成本意识。这里最值得提醒的一点是成本治理不是一次性的“省钱运动”。在 AI 原生开发里推理成本是应用形态的一部分。持续记录、持续观察、持续优化才能保证业务在扩大规模时成本不会先于收益失控。 AI原生开发中的推理成本洞察与治理实践
一个典型的 AI 原生开发团队会遇到这样的问题产品已经接入了大模型能力用户提问、多轮对话、内容生成都跑通了团队最初只关注“答案准不准”没有把模型调用成本当作第一优先级。上线一段时间后账单开始超预算而且很难定位问题。看 API 账单只能知道总额涨了但到底是因为用户量增长、Prompt 变长、重试太多还是某个功能模块的上下文策略设计不合理账单本身给不出答案。这种状态在 AI 原生开发项目中非常普遍。AI 原生开发不是“在传统应用里接一个 AI 接口”而是从产品设计、数据流、异常处理到评测方式都以大模型推理为核心来组织应用架构。推理成为业务主路径之后推理成本就从一个“后台账单”变成了必须纳入架构决策、代码评审和日常监控的技术指标。这篇文章围绕 AI 原生开发中的推理成本洞察按工程落地的顺序拆解成本到底从哪里产生如何在应用层度量成本如何通过 Prompt、缓存、模型路由和降级策略控制成本以及当成本异常飙升时如何通过日志和指标快速定位。最后给出一套可在学习环境和生产环境分别落地的成本治理清单。1. AI 原生开发的核心是“推理成为主路径”1.1 传统应用和 AI 原生应用的差异在哪里传统 Web 应用和后端服务的核心特征是确定性。请求进来后代码按已知逻辑执行输入输出可以精确预测数据库查询、第三方接口调用、任务调度都在可控范围内。虽然也要关心性能、并发和资源成本但单位请求的成本基本稳定扩容策略也相对成熟。AI 原生应用不同。大模型推理结果是非确定性的业务逻辑不再是一段完全可控的代码而是“给定上下文模型生成内容”。一个应用是否属于 AI 原生关键不在于“接没接大模型接口”而在于大模型是否承担了核心业务决策。例如一个客服工单系统如果大模型只是做关键词辅助分类这是传统应用接入 AI 能力如果系统把用户问题理解、知识检索、答案生成、追问处理、结果校验全部交给大模型链路完成这就是 AI 原生的形态。两种模式的区别会直接影响成本结构维度传统应用AI 原生应用业务逻辑代码确定输入输出可预测模型推理生成结果非确定每次请求成本相对稳定取决于 CPU、内存、接口调用波动大取决于 Token 数量、模型等级、上下文长度调试方式断点、日志、堆栈定位需要评测集、Prompt 版本、输出校验、人工抽检缓存策略按参数、用户、数据版本设计缓存键需要考虑语义缓存和 KV 缓存扩容约束主要看服务和数据库资源还要看模型推理延迟、并发额度、Token 消耗预算异常处理重试通常能解决问题重试可能造成重复计费需要更谨慎AI 原生开发中最容易犯的一个错误是把大模型当普通接口调用忽略“单次请求成本不可预知”这个本质。要对成本做控制必须先理解这个差异。1.2 推理成本的三个特点不确定、会累积、非线性推理成本不是传统意义上的 API 计费金额这么简单它有三个工程上必须重视的特点。第一个特点是不确定性。模型输入 Token 数量和输出 Token 数量在请求发出前难以精确预测。即使是同一个 Prompt 模板不同用户输入的长度不同不同批次的模型回复长度也可能差异很大。非流式调用可能返回完整结果后再计费流式调用则需要处理增量输出。这种不确定性意味着成本策略不能只写一条“估算一下”的口径必须在每次请求返回后记录真实 Token 消耗。第二个特点是累积性。多轮对话会把历史消息不断追加到上下文里。每一轮用户提问模型都要重新处理前面的历史内容。Round 1 消耗 1000 TokenRound 5 可能因为历史累积消耗 4000 TokenRound 10 可能更高。Agent 类应用更明显一次用户目标可能需要模型多次推理、多次调用工具、多次生成中间结果每一步都会累积消耗。第三个特点是非线性。这里的非线性指的是成本增长往往比业务量增长更快。用户量增长 20%如果 Prompt 没优化、上下文没裁剪、缓存没生效模型调用量可能增长 40% 甚至更多。多轮对话、工具调用、重试和上下文膨胀组合在一起成本曲线会比用户曲线陡峭得多。1.3 为什么成本必须是架构决策的一部分一些团队把成本控制放在上线后等到账单异常再去查。这时候能做的优化已经受限可能只能降级功能或砍掉部分场景。更合理的做法是把成本当作和延迟、准确性并列的约束条件在架构设计阶段就确定成本边界。具体来说AI 原生开发的架构设计至少要考虑三个问题一个业务动作最多允许多少次模型调用一次调用允许输入多少 Token每天或每月单个功能模块的成本预算是多少。这三个问题决定了 Prompt 模板设计、上下文管理策略、模型选择和缓存方案。没有这些约束后面所有优化都只能靠临场补救。2. 推理成本不是一张账单而是一条成本链路2.1 拆解一次 AI 原生请求的完整计费路径只按“模型调用一次收费一次”理解成本会漏掉很多真实支出。一次 AI 原生请求通常不是一个单次调用而是一条由多个环节组成的链路。用一个典型的 RAG 问答场景举例。用户提问后系统需要先对问题做向量化检索召回若干知识片段再把用户问题、知识片段、系统 Prompt 拼接到一起发送给大模型。模型返回答案后系统还可能做一次答案有效性校验如果答案不符合要求会自动重新组织 Prompt 并再次调用模型。这个过程中会产生成本的地方包括用户问题向量化如果向量化服务也按 Token 计费这会产生前置成本。知识片段召回为了提升答案质量系统可能把多个候选片段都放进上下文导致输入 Token 明显变长。模型主调用按输入输出 Token 计费。答案校验调用一次业务动作实际发生两次或多次模型调用。超时或限流重试每次重试都会再次计费。下面用一个简化的流程代码展示这种链路def handle_user_question(user_question: str, user_id: str): # 1. 向量化用户问题 query_vector embedding_model.encode(user_question) # 2. 检索知识片段 retrieved_chunks vector_db.search(query_vector, top_k5) # 3. 构造上下文知识片段全部拼入 prompt context \n\n.join([chunk.text for chunk in retrieved_chunks]) prompt build_prompt(user_question, context) # 4. 主模型调用 answer llm_agent.chat(prompt) # 5. 答案合理性校验 if not validate_answer(answer): # 这里会再次调用模型产生第二次成本 answer llm_agent.chat(build_corrective_prompt(prompt, answer)) return answer这段代码在功能上没问题但从成本角度看第 5 步是隐藏的成本放大器。一次失败校验意味着一次业务请求消耗了两次甚至更多次模型调用而且第二次调用的输入还附带第一次的答案Token 消耗更大。实际项目中这样的链路必须在每一步都记录调用次数和 Token 消耗。2.2 主要成本项拆解表AI 原生应用中推理成本可以进一步拆成以下成本项成本项来源典型放大原因输入 Token系统 Prompt、用户问题、历史消息、检索片段、工具描述上下文不裁剪历史消息无限增长输出 Token模型生成的答案、中间推理过程未限制 max_tokens模型输出过长缓存命中缓存降低重复计算未命中则重复支付缓存键设计不合理命中率过低重试超时、限流、输出校验失败业务侧无上限重试多次调用同一模型多轮对话历史消息每次重复进入上下文只追加不摘要越聊越长工具调用Agent 多轮决策、多次工具调用步数无上限每个工具调用都要模型再推理RAG 检索知识片段拼接导致输入变长召回数量固定且过多无关片段占据 Token批量与异步大批量任务未做聚合逐条调用单条请求重复系统提示词浪费输入预算这张表的作用不是让人把每个成本项都背下来而是提供一个基础映射任何一次成本发生变化都能对应到某个具体环节。比如某日账单上升如果平均输出 Token 没变但平均输入 Token 明显上升优先怀疑 Prompt 模板变更或历史消息累积如果请求量没变但调用次数上升优先怀疑重试逻辑或 Agent 步数。2.3 度量口径不要只盯着账单金额API 账单是供应商维度的汇总数据粒度通常是“日”“小时”甚至“总消耗”按模型维度统计 Token 数量。这个数据只能回答“花了多少钱”不能回答“哪个功能模块花了钱”“哪个 Prompt 版本花了更多”“哪类用户请求成本最高”。要在应用中建立自己的成本度量口径。核心原则是每次模型调用都必须记录可以用于成本归因的最小字段。通常包括请求 ID、业务功能、模型名称、输入 Token、输出 Token、缓存命中状态、重试次数、调用耗时和任务结果状态。有了这些字段后成本分析才能从总额拆到模块、从模块拆到 Prompt 版本、从版本拆到具体用户场景。这才是 AI 原生开发里“成本洞察”的工程含义。3. 先建立成本可观测性再谈优化3.1 在模型调用层统一封装AI 原生项目的代码里尽量不在业务代码中直接拼接大模型 Client而是统一封装一个模型调用入口。统一封装的目的有三个统一记录 Token 消耗统一处理超时、重试和流式结束统一维护模型路由和缓存逻辑。下面是一个最小封装示例用于说明记录成本的思路# llm_wrapper.py import time import json import uuid class LLMResult: def __init__(self, text, prompt_tokens, completion_tokens, model, cache_hit, latency_ms): self.text text self.prompt_tokens prompt_tokens self.completion_tokens completion_tokens self.total_tokens prompt_tokens completion_tokens self.model model self.cache_hit cache_hit self.latency_ms latency_ms class LLMWrapper: def __init__(self, client, cost_center): self.client client self.cost_center cost_center def chat(self, messages, feature, modeldefault, max_tokens1024, retry_count2): request_id uuid.uuid4().hex start time.time() attempt 0 while attempt retry_count: try: response self.client.chat.completions.create( modelmodel, messagesmessages, max_tokensmax_tokens, ) latency_ms int((time.time() - start) * 1000) usage response.usage result LLMResult( textresponse.choices[0].message.content, prompt_tokensusage.prompt_tokens, completion_tokensusage.completion_tokens, modelmodel, cache_hitFalse, latency_mslatency_ms, ) # 统一记录成本日志 self.cost_center.record( request_idrequest_id, featurefeature, modelmodel, prompt_tokensusage.prompt_tokens, completion_tokensusage.completion_tokens, cache_hitFalse, latency_mslatency_ms, retry_countattempt, ) return result except Exception: attempt 1 if attempt retry_count: raise return None这段代码的关键点在于所有业务代码都通过LLMWrapper.chat发起调用成本记录与业务逻辑解耦。实际项目中这个封装还可以扩展出模型路由、语义缓存、降级开关等功能。不要在业务代码里直接使用底层 SDK Client否则成本统计会漏掉一部分调用排查时也很难定位。3.2 记录结构化成本日志记录成本日志时推荐使用结构化格式例如 JSON方便后续写入日志系统、Elasticsearch 或 ClickHouse 做分析。一条成本日志的最小结构如下{ request_id: 7f3a9c0e2b1d4f6a8c5d1e2f3a4b5c6d, user_id: u_10086, feature: customer_service_qa, prompt_version: prompt_v20240601, model: default, prompt_tokens: 1850, completion_tokens: 320, total_tokens: 2170, cache_hit: false, latency_ms: 1450, retry_count: 0, success: true, estimated_cost: 0.0023 }estimated_cost字段可以由程序根据 Token 数量和模型单价计算。这里有一个工程细节不要把单价硬编码在业务代码里建议维护一张模型单价表避免因为模型价格调整导致历史成本估算全部失真。3.3 看板和告警让成本变化可感知成本日志记录之后还需要聚合指标和告警。常用指标包括总成本按天、小时聚合功能模块成本 Top N平均 Prompt Token 数平均 Completion Token 数缓存命中率模型调用次数与请求数比值重试率告警规则建议包含几类告警类型触发条件建议动作日成本环比增长同比增长超过 20%检查流量、Prompt 版本、路由配置单模块成本突增某功能模块成本占比超过阈值分析该模块平均 Token 与调用次数缓存命中率下降命中率下降超过 10%检查缓存键设计、数据更新、并发重试率上升重试率超过 5%检查模型限流、超时设置、下游依赖平均输入 Token 上升环比增长 30%检查历史消息裁剪、RAG 召回数量生产环境的成本日志建议与业务日志分离存储。业务日志通常关注用户行为和异常成本日志则是一个独立的可聚合数据源。两者通过request_id关联遇到用户反馈或故障时可以同时查看业务链路和成本链路。注意成本可观测性不是上线后才补的工作。模型调用封装、结构化日志、看板和告警最好在项目初始化阶段就建立因为这些基础设施一旦缺失后续优化会失去判断依据。4. 推理成本优化的常用手段4.1 Prompt 工程层面的成本控制Prompt 是 AI 原生应用中最容易优化也最容易失控的部分。每一段系统提示词、每一条历史消息、每一个知识片段都会转化为输入 Token直接影响成本。具体的成本控制手段包括精简系统提示词删除冗余说明只保留模型完成任务必要的行为约束。比如“你是一个乐于助人的 AI 助手”这类的装饰性内容可以去掉因为对任务结果影响很小却会占用每次请求的 Token。限制输出长度为每个模型调用设置max_tokens避免模型生成过长的内容。尤其要关注流式输出场景有些模型在没有明确长度约束时会把一段话扩展成很长的解释。历史消息裁剪多轮对话不能无限追加历史消息。超过一定轮数或一定 Token 阈值后保留最近的几条消息并把更早的内容做摘要用一句摘要代替完整历史。固定 Prompt 版本每次修改 Prompt 都要记录版本号方便成本分析时对照版本变化。def build_messages(user_input, history, system_prompt, max_history_tokens1200): messages [{role: system, content: system_prompt}] # 估算历史消息 token 长度超过阈值时只保留最近的消息 estimated_history_tokens sum(len(h[content]) for h in history) if estimated_history_tokens max_history_tokens: # 保留最近 4 条消息其余丢弃或摘要 history history[-4:] # 更早内容可以用 summary 替代而不是直接丢弃 summary summarize_early_history(history[:-4]) messages.append({role: system, content: f更早的对话摘要{summary}}) messages.extend(history) messages.append({role: user, content: user_input}) return messages这是一个很常见的工程处理方式在消息进入模型前先做一次 Token 估算和裁剪。实际项目中可以使用 Tokenizer 做精确计数而不只是按字符长度估算。4.2 缓存策略语义缓存和 KV 缓存缓存是 AI 原生应用中收益最大也最容易做错的一环。第二种是 KV 缓存。KV 缓存在模型侧或推理框架内部维护对于相同前缀的请求可以复用计算中间结果降低同一次服务调用中的部分计算成本。开发侧主要关注推理服务的配置和命中率例如在多轮对话中保持相同会话上下文让前缀一致从而提升 KV 缓存命中率。对于应用开发团队语义缓存是自主可控的优化方式。核心思路用户问题经过向量化后与历史问题做相似度匹配如果相似度超过阈值直接返回缓存答案不调用大模型。class SemanticCache: def __init__(self, vector_db, threshold0.92): self.vector_db vector_db self.threshold threshold def get(self, user_question): question_vector embedding_model.encode(user_question) result self.vector_db.search(question_vector, top_k1) if result and result[0].score self.threshold: return result[0].answer return None def set(self, user_question, answer): question_vector embedding_model.encode(user_question) self.vector_db.upsert(vectorquestion_vector, answeranswer)语义缓存适合用户问题重复率较高的场景比如企业内部的常见问题咨询、售后客服、产品使用帮助。如果用户问题几乎不重复缓存命中率会很低投入语义缓存的收益有限。缓存键设计是这里最容易踩的坑如果直接用完整文本做精确匹配个别字眼不同就无法命中如果语义向量相似度阈值过低又可能返回错误的答案。建议上线时先用阈值 0.90 到 0.95 区间做小流量测试观察答案准确率和缓存命中率的平衡。4.3 模型路由让请求匹配合适的模型不同业务场景对模型能力的要求不同。复杂推理、代码生成、长文档理解需要较强的模型简单问答、意图识别、格式转换可能用轻量模型就足够。模型路由的思路是在调用模型前判断请求的难度和业务优先级再决定使用哪个模型。一个简单实现是根据业务功能决定def route_model(feature, user_input_length, has_tool_callFalse): # 简单功能或短输入走轻量模型 if feature intent_classification and user_input_length 100 and not has_tool_call: return fast-model # 需要工具调用或长上下文时走主力模型 if has_tool_call or user_input_length 3000: return strong-model # 其他情况走默认模型 return balanced-model这只是最直观的路由策略。生产环境中路由条件可以根据实际效果动态调整先标记请求类别观察不同模型的回答质量、延迟和成本再调整路由规则。需要注意的是不要把路由逻辑做得过于复杂否则排查问题时又多了一层不确定因素。路由决策本身也要记录日志方便后续判断“某类请求被错误路由到昂贵模型”的情况。4.4 降级、批量与异步在流量高峰期AI 原生系统要有明确的降级策略。例如关闭 Agent 工具调用退化为普通问答关闭 RAG 检索只使用模型自身知识关闭长上下文优化只处理最近几轮消息。降级策略的代价是效果下降但对保证服务可用性和控制成本很重要。非实时场景不要走同步逐个调用。例如日报整理、批量内容审核、数据分析任务可以设计成异步队列批量调用模型减少系统提示词和上下文的重复构造。批量处理可以降低请求数量但对单个请求的 Token 消耗没有直接帮助最终效果取决于任务类型。流式输出场景要特别注意结束信号。客户端如果因为流式响应没有正确结束而发起重试每次重试都会重新计费。建议在流式输出中明确设置结束标记并做好响应校验。注意成本优化的前提是效果不劣化。任何减 Token、降级、换模型的措施都要在评测集上验证效果。不要在没有任何评测的情况下直接为了省钱把主模型切换成轻量模型。5. 推理成本异常飙升怎么排查5.1 先确认口径再查链路排查成本异常时第一件事不是找代码而是确认“成本上升”的口径来自哪里。是 API 账单总额上升还是自建看板聚合出的数字上升还是某个报表的估算金额上升三者口径不同结论可能完全不一样。确认口径后按以下顺序排查请求量是否变化。日活、请求量、并发量上升成本上升可能只是业务增长。平均调用次数是否变化。每个用户请求对应的模型调用次数是否增加重点怀疑 Agent 步数或重试逻辑。平均 Token 是否变化。分别看输入 Token 和输出 Token输入 Token 上升重点看 Prompt 版本、上下文策略、RAG 召回数量输出 Token 上升重点看 max_tokens 限制。缓存命中率是否变化。语义缓存或 KV 缓存命中率下降可能导致大量重复请求直接打到模型。模型路由是否变化。是否存在请求被错误路由到更贵模型的情况。是否引入新的重试机制。超时时间和重试次数的调整可能让成本成倍增加。5.2 用日志链路定位具体功能定位到具体功能模块需要依赖第 3 章建立的成本日志。排查的基本方法是按feature、prompt_version、model三个维度做分组聚合。假设成本日志存储在 ClickHouse 或 Elasticsearch可按类似 SQL 逻辑查询SELECT feature, model, count() AS call_count, sum(prompt_tokens) AS total_prompt_tokens, sum(completion_tokens) AS total_completion_tokens, avg(cache_hit) AS cache_hit_rate FROM llm_cost_log WHERE date 2025-05-20 GROUP BY feature, model ORDER BY total_prompt_tokens total_completion_tokens DESC LIMIT 20;结果如果显示某个 feature 的成本占比异常高再继续看该 feature 下的单次请求调用次数分布和 Token 分布。例如某个客服问答功能单次请求的平均模型调用次数从 1.2 涨到了 3.5那就能直接联想到 Agent 工具调用或答案校验逻辑引入了额外模型调用。5.3 常见成本问题与处理方案以下几个问题在 AI 原生项目中很常见。这里用表格列出典型现象、原因和处理方向问题现象常见原因处理建议成本上涨但请求量没涨Prompt 模板改动导致输入 Token 变长对比 prompt 版本改动回滚或裁剪用户多轮对话越用越贵历史消息无限累积对历史做摘要只保留最近几轮大量重试产生重复计费模型超时未合理处理或流式结束信号缺失设置合理超时重试次数上限设为 1 到 2 次使用流式结束标记做校验缓存命中率很低缓存键设计不合理或用户问题几乎不重复检查相似度阈值换用语义缓存或干脆取消缓存单模块成本异常高但没有新功能Agent 工具调用步数增加限制最大步数设置工具调用白名单对中间结果做校验请求被路由到昂贵模型路由规则过于粗糙或默认走强模型增加路由日志按业务功能细化规则默认改为平衡模型这个表格可以作为团队排查成本异常的 Starter 清单。实际排查中如果以上各项都正常再检查是否有批处理任务意外重跑、是否有客户端重复请求、是否有测试流量混入生产环境。5.4 三个容易忽视的隐藏成本点第一输出式流媒体中断导致的残次请求。用户如果中途断线服务端可能仍把已验证的完成请求算作真实消费。客户端离开页面后AI 会话管理仍保存上下文下次进入会继续累积历史。第二上下文无关的固定提示词重复计费。在一些批量任务中系统提示词完全相同却为每条记录分别拼入并支付输入 Token。批量处理时应该把固定提示词部分从每次调用中尽量抽离能不能拼一个长 Prompt 让模型一次性处理多条记录取决于任务类型。第三模型升级带来的隐性成本变化。模型 A 的输出会把“合理答案”扩展成长文模型 B 可能更简洁但有时模型 B 的输入 Token 对长上下文的计费系数更高。升级模型后如果没做成本对比可能发现质量下降的同时成本反而更高。6. 成本视角下的 AI 原生架构决策6.1 RAG 和微调的成本差在哪在 AI 原生项目中团队经常需要在“RAG 检索增强”和“模型微调”之间做选择。从推理成本角度看两者差别明显。RAG 的成本主要集中在每次请求的输入 Token 上。系统需要把知识切片拼入上下文召回片段越多输入越长。RAG 的优势在于不需要模型训练知识更新可以走索引更新新增知识条目的成本较低。劣势是每个请求都要承担额外的 Token 成本尤其当知识库片段较长时成本会被放大。微调的成本主要集中在模型训练、部署和持续维护上。一次微调需要准备训练数据、调整参数、评估效果并承担训练计算资源。推理时微调模型的输入中不需要加入大量知识内容单次请求的 Token 消耗通常比 RAG 场景更低但部署环境、模型版本和评估成本长期存在。这不是一个简单的“谁更便宜”的判断题而是要看数据更新频率和单次请求上下文长度。知识大量且频繁更新时RAG 更适合知识相对固定、对延迟和单次成本敏感时微调或混合方案可能更合适。工程上常见的做法是先用 RAG 快速验证效果确认某些固定知识确实需要模型额外学习时再考虑微调。6.2 Agent 步数必须设置边界Agent 类应用是成本失控的高危区。原因是 Agent 的每次工具调用都可能触发一次模型推理而模型又可能根据工具结果再次调用工具形成多轮循环。一次简单业务请求在 Agent 架构下可能变成 5 到 10 次模型调用。控制 Agent 成本的关键指标是“平均一次用户请求对应的模型调用次数”。这个指标应当被监控并且设置上限。当某类请求的平均调用次数超过阈值不应该继续放量而应该先优化 Agent 的工具描述、限制工具调用白名单、减少无效推理或者设置明确的最大步数。MAX_AGENT_STEPS 4 def run_agent(user_question): steps 0 while steps MAX_AGENT_STEPS: steps 1 action llm_agent.decide_next_action(user_question) if action.type finish: return action.result result execute_tool(action) llm_agent.add_observation(result) return 达到最大步数改为降级回答在这里MAX_AGENT_STEPS是一个架构级约束。它不是为了限制用户而是防止不可控的推理循环让成本无限扩大。允许的最大步数不是越大越好要根据业务需要和成本预算共同决定。6.3 模型选型要绑定预算阈值每个功能模块都应有“单次完成该业务动作的成本上限”。例如客服问答功能一次完整问答的 Token 成本预算为 0.01 元到 0.05 元如果某个解决方案估算后超出预算就需要调整 Prompt、缓存策略或模型等级。模型选型不是选最聪明的模型而是选在预算内能满足准确率的模型。团队应该维护一张“模型能力与成本对照表”记录每个模型在内部评测集上的通过率、平均 Token 数和调用延迟。模型版本升级前先在评测集上运行一次对比效果和成本而不是只看准确率提升了多少。7. 推理成本治理清单学习环境与生产环境7.1 学习环境如何快速跑通成本度量对于学习和 Demo 项目成本治理不需要一开始就做完整系统但至少要把“记录 Token”这个习惯建立起来。最小做法是在代码中统一封装模型调用入口。每次调用后打印或记录 prompt_tokens 和 completion_tokens。为不同 Prompt 方案保留简易的 Token 对比记录。设置一个固定的消耗上限避免开发测试时失控。学习环境下可以不用做真实账单和告警系统但核心原则是每次模型调用都要有迹可循。很多生产环境的成本问题早期在开发阶段就已经因为“数据没记”而被忽略。7.2 生产环境上线前检查清单生产环境上线的成本治理建议至少覆盖以下内容模型调用是否统一走封装层是否存在绕过封装的直接 Client 调用。每次调用是否记录 request_id、feature、model、token 数、耗时、重试次数。是否设置了 max_tokens 和合理的超时时间。重试次数是否有上限是否考虑重复计费风险。是否设计了缓存策略缓存命中率基线是否确定。Prompt 模板是否有版本号改动是否可回溯。每个功能模块是否有成本预算和告警阈值。除主链路外额外模型调用校验、摘要、二次生成是否有成本日志。是否建立了成本看板是否有人每天或每周检查。7.3 运行中的监控指标上线后持续关注以下指标这些指标反映的是成本健康度而不是单一的总金额指标健康信号风险信号日成本总量随业务量平稳变化无明显业务增长但总额翻倍平均请求模型调用次数接近 1Agent 场景接近预期步数持续上升且没有版本变更说明平均输入 Token稳定或有小幅优化持续上涨Prompt 版本反复膨胀缓存命中率语义缓存命中率高于预期命中率从 50% 跌到 10%重试率低于 3%超过 5%功能模块成本占比与业务量占比一致单模块成本突然超过 60%模型路由命中率预期模型占比符合设计大量请求被路由到最高价模型7.4 迭代后复盘清单每次 Prompt 变更、模型升级、Agent 逻辑调整或缓存策略变化都应该做一次成本复盘变更前后同一个评测集上的效果指标是否上升、持平或下降。变更前后平均每个业务动作的成本变化比例。变更引入的额外调用链是否被记录是否有新重试风险。缓存收益是否达到上线的判断阈值。是否需要对上一次设定的预算阈值做调整。把成本复盘纳入迭代流程团队才会逐渐形成成本意识。这里最值得提醒的一点是成本治理不是一次性的“省钱运动”。在 AI 原生开发里推理成本是应用形态的一部分。持续记录、持续观察、持续优化才能保证业务在扩大规模时成本不会先于收益失控。