近两年AI 圈出现了一个非常分裂的现象一边是模型厂商反复强调推理成本大幅下降另一边是企业财务表上的 AI 相关支出不降反升。很多团队把这种矛盾简单解释为“厂商玩价格游戏”但其实两者都是真的单次调用的边际成本确实在降企业的总账单也确实在涨。这里的关键是把“边际成本”和“总成本”分开看。边际成本是指多服务一个请求、多生成一个 token 多花的钱总成本则等于单价乘以用量再加上基础设施、工程人力、重试损耗等一大堆外围开销。单价下降只作用于第一个变量而另外几个变量正被技术趋势和团队使用习惯同时放大。这篇文章不讨论“企业该不该上 AI”这种立场问题而是把账单问题当作一个纯工程问题来拆解为什么边际成本下降没有带来总账下降钱到底花在了哪里如何通过成本基线、缓存、模型路由、配额护栏等工程手段把总账真正控制住。读完你会得到一份可以照着做的成本治理路径而不是一句“要节约成本”的空话。1. 矛盾拆解边际成本下降与账单上涨为什么同时发生1.1 推理侧的成本下降是真实的技术红利在模型服务这一侧单 token 的计算成本近几年确实在大幅下降。推动因素主要有几个推理引擎优化连续批处理、PagedAttention、算子融合等技术让 GPU 利用率显著提高KV Cache 复用多轮对话时不再重复计算历史部分的 Key-Value省掉大量算力投机解码用小模型先生成草稿大模型并行验证加速的同时摊薄单位成本模型量化与稀疏化把权重从 FP16 压到 INT8 甚至更低显存占用和计算量一起下降架构演进MoE 架构让每次推理只激活一部分参数单 token 的算力消耗明显低于同规模的稠密模型。这些优化是实打实的工程进步。用同一笔算力预算现在能服务的 token 数量比一两年前多得多。所以“边际成本下降”不是营销话术它是推理系统整体效率提升的结果。1.2 企业总账的公式里不只有单价问题在于企业账单从来不是“单价 × 固定用量”这么简单的算术。一个更接近真实情况的总成本结构是这样的总成本 模型调用单价 × Token 用量 基础设施成本向量库、存储、缓存、网络 工程人力成本Prompt 调优、联调、排障 稳定性损耗重试、超时、降级、容灾模型厂商能优化的是第一项里的“单价”但企业实际支付的是整个公式。只要后面几项涨得足够快即使单价降了一半总账照样翻倍。1.3 一个更直观的类比想象一家超市的牛奶降价 50%目的是让你买得更多。你确实买了三倍的牛奶总花费反而比原来多了 50%更麻烦的是你为了存放这些牛奶又买了一个更大的冰箱冰箱还需要多耗电。冰箱和电费就是企业账单里的基础设施成本与稳定性损耗。所以边际成本下降与企业总账单上涨并不矛盾。它们是一件事的两个侧面技术红利降低了单个 token 的代价工程复杂度却放大了 token 的消耗总量。把这两个数字放在一个报表里看才能真正理解企业的 AI 支出。这一节的小结论是不要在“单价降没降”上争论应该去算“总账涨在哪、为什么涨、能不能通过工程手段压住”。2. 企业 AI 账单的真实构成Token 单价只是冰山一角很多团队复盘 AI 支出时只盯着模型厂商的账单看。实际上企业为 AI 付出的钱分散在六个层面其中至少有一半不会直接出现在“模型调用费用”那一行。成本类别典型来源为什么难控制模型调用文本生成、分类、抽取、向量化、重排调用量弹性大需求一多就膨胀检索与存储向量库、对象存储、切片缓存、中间件数据规模线性增长不调用也在付钱微调与训练领域微调、模型蒸馏、评估集构建一次性投入高复用率不稳定评估与测试LLM-as-judge、回归集跑测、效果对比开发期不起眼上线后频繁触发工程与人力Prompt 调优、接口联调、监控、排障隐性成本几乎不进入成本核算稳定性开销重试、超时重算、降级、容灾、人审兜底故障越多花费越高且很难提前预估2.1 模型调用账单上最明显的一项这是最直观的一层每次调用都要按输入 token 和输出 token 付费。但它远不止“大模型聊天”这一种形态。一个成熟业务里文本分类、命名实体识别、意图识别、向量化、重排序都会产生独立调用。这些调用单价不高但数量巨大累积起来常常超过主线的大模型调用。2.2 检索与存储沉默的固定支出只要上了 RAG就需要向量库、文档切片、索引更新、对象存储。这部分费用按数据规模和存储时长计算即使没有任何用户提问账单也在持续产生。很多团队在方案设计时只算了模型调用费没算向量库的部署和存储成本等到月度账单出来才发现多了一大块。2.3 微调与训练一次性但昂贵领域微调需要准备数据集、购买算力、训练多个版本还要做效果对比和回滚预案。它不像 API 调用那样按量计费而是一笔集中支出。如果团队为了“跟上版本”反复微调这笔钱会快速累积。2.4 评估与测试最容易被低估的环节现代 AI 工程的评估普遍采用“LLM-as-judge”即让另一个模型来给生成结果打分。听起来很轻巧但一次完整回归可能要跑几百条测试用例每条用例又是多次模型调用。如果每天跑多轮回归评估环节的 token 消耗甚至可能超过正式业务调用。2.5 工程人力与稳定性损耗账单外的大头Prompt 调优、接口联调、效果排查、日志监控这些都是人的时间很少被财务归入“AI 支出”但它们是真实成本。更隐蔽的是稳定性损耗一次超时导致的重试一次并发高峰触发的降级一次生成中途失败导致的算力浪费都会带来额外的模型调用。这一节的小结论是只盯模型调用费就像只看了水电费账单里的电费忽略了水费、燃气费和管理费。成本治理的第一步是先把账单拆到足够细的粒度。3. 用量弹性越便宜调用越多总消耗越大3.1 价格下降会刺激更多需求经济学里有一个概念叫“需求价格弹性”价格下降时需求量通常会上升。AI 调用完美符合这个规律甚至弹性比大多数商品更大因为 AI 能力可以被嵌入到无限多的功能点里。在单价较高的阶段团队会本能控制调用量只有核心业务才敢用大模型其他场景一律用规则或小模型。随着单价下降这种克制开始松动原来只给客服做智能回复现在连邮件草稿、会议纪要、代码注释、SQL 生成都想交给模型原来只对长文档做总结现在短消息也要先“润色一遍”原来分类任务用正则硬扛现在直接调用模型分类理由很简单“反正也不贵”。于是单价下降 50%调用量却可能翻三倍。单价降的那点钱远远跟不上用量增长的速度。3.2 Agent 让 Token 消耗变成“乘法”而不是“加法”如果说普通 API 调用是“一次请求一次账单”那么 Agent 类应用就是“一次业务请求N 次模型调用”的叠加而且这个 N 还在不断增加。一个典型的 Multi-Agent 协作流程一个任务先交给规划 Agent 拆解拆成 3 个子任务分别交给不同的执行 Agent每个执行 Agent 又要与环境交互、调用工具、读取上下文最后汇总 Agent 还要把多份结果整合成最终答案。如果每个环节都需要 5 轮交互那么一次业务请求最终触发的模型调用次数不是 1 次也不是 3 次而是几十次。下面这段代码演示了不同调用模式下的成本差异# estimate_cost.py # 演示用估算不同调用模式下的一次任务成本 # 单价以参数传入避免写死具体厂商价格实际以官方定价为准 def estimate_task_cost( num_calls: int, input_tokens_per_call: int, output_tokens_per_call: int, price_per_million_input: float, price_per_million_output: float, ) - dict: total_input num_calls * input_tokens_per_call total_output num_calls * output_tokens_per_call input_cost total_input / 1_000_000 * price_per_million_input output_cost total_output / 1_000_000 * price_per_million_output return { num_calls: num_calls, total_input: total_input, total_output: total_output, input_cost: round(input_cost, 4), output_cost: round(output_cost, 4), total_cost: round(input_cost output_cost, 4), } # 假设每次调用输入 2000 token、输出 500 token # 价格为演示取值实际请以模型厂商最新定价为准 scenarios { 单次问答: estimate_task_cost(1, 2000, 500, 5, 15), 5轮多轮对话: estimate_task_cost(5, 2000, 500, 5, 15), 3个Agent各5轮: estimate_task_cost(15, 2000, 500, 5, 15), } for name, result in scenarios.items(): print(f{name}: 调用 {result[num_calls]} 次总费用 {result[total_cost]} 元)运行结果可以很直观看出来从单次问答到 3 个 Agent 协作调用次数从 1 变成 15总费用也同步放大 15 倍。而且这里还没有计算 Agent 之间互相传递上下文带来的额外 token。3.3 用量弹性带来的经营问题用量弹性本身不是坏事它说明 AI 真的在产生价值。坏的是没有配套的成本治理需求放量之后成本归因、预算上限、用量监控都没有跟上导致账单上涨但没人能说清楚哪笔钱花在了哪个功能上。这一节的小结论是单价下降刺激用量上升用量上升又催生更复杂的调用架构。要控制总账不能只看单价必须同时管理“调用次数”和“单次调用规模”。4. 架构放大效应RAG、长上下文与多 Agent 的“成本倍率”4.1 RAG一次问答背后是一整条调用链很多团队对 RAG 的成本预期是“一次问答 一次大模型调用”但真实链路要长得多用户提问后先调用嵌入模型把问题向量化拿问题向量去向量库检索取回 Top-K 相关文档切片可能还要调用重排模型对候选切片做更精细的排序把排序后的切片拼进 Prompt再调用大模型生成答案如果答案质量不达标还可能有“二次检索”或“改写问题再检索”的循环。每一步都有成本嵌入模型是独立调用向量库检索消耗计算资源重排模型又是一次模型调用。最终生成阶段因为要带上下文输入 token 数可能从几百涨到几千甚至上万。一次“看起来很简单”的 RAG 问答实际成本往往是单次生成的好几倍。4.2 长上下文单次调用的金额被悄悄拉高上下文越长单次调用的 token 消耗越大。假设一个模型按 token 计费一个 2,000 token 的 Prompt输入费用是一个固定值一个 32,000 token 的 Prompt输入费用是前者的 16 倍。即使长上下文模型的单价更便宜只要比例低于长度放大比例总费用依然是上涨的。再加上长 Prompt 还会增加首 token 延迟延迟一高超时重试的概率也上升重试又是额外账单。在多轮对话里这是一个特别容易失控的场景。如果系统不做历史裁剪每一轮都把完整会话历史塞进 Prompt对话轮次越多单次调用的 token 数越大呈近似二次增长。用户聊到第 50 轮时一次请求的消耗可能比第 1 轮高出几十倍。4.3 多 Agent上下文被反复复制和传播Multi-Agent 系统的成本倍率更高因为编排器要把对话历史、任务状态、工具返回结果分发给多个 Agent。这意味着同一段上下文会被复制多份分别计费。Agent 数量越多、协作轮次越多上下文膨胀得越快。方案单请求相对调用量说明单次生成约 1x一次 Prompt 对应一次 CompletionRAG 问答约 2-5x向量化、检索、重排、生成各有消耗多 Agent 协作约 10-50x多角色 × 多轮 × 上下文同步消耗成倍放大长对话不裁剪随轮次增长上下文越长单次调用金额越高这个表格不是精确测量结果而是经验量级。它想说明的是架构设计决定了“一个业务请求最终会换算成多少次模型调用、多少 token”。这个换算倍率是比单价更关键的成本变量。4.4 为什么优化倍率比谈降价更重要模型厂商降价是在“单价”上做文章而架构优化是在“倍率”上做文章。单价降 30%如果倍率从 1x 涨到 3x总成本还是涨了 2 倍多。反过来如果能把倍率从 3x 压回 1.5x即使单价完全不变总账也能明显下降。这一节的小结论是谈成本之前先画一张调用链路图把一次业务请求经过的所有模型调用、所有 token 消耗都列出来。倍率清楚之后优化对象也就清楚了。5. 从 POC 到生产账单在验收后飙升的三个工程原因5.1 POC 阶段的成本数字天然偏低很多人对 AI 成本的判断来自 POC 阶段的经验跑一个演示 Demo调几十次接口感觉“很便宜”。但 POC 和生产的运行条件完全不同POC 只有一条调用链路生产会有多条业务线同时接入POC 只有少量测试样本生产面对真实流量和并发POC 没有重试、超时、权限校验生产全都要有POC 没有日志、监控、告警生产这些本身就是开销。所以一个在 POC 阶段每天花几十元的应用上线后每天花几千元是非常正常的。这不是厂商“坐地起价”而是运行负载和工程保障完全不同。5.2 重试机制账单的隐形放大器生产中为了稳定性几乎都会配置超时重试。但重试对 AI 账单的放大效果经常被低估。下面这段代码演示了成功率与重试对调用次数的影响# retry_cost.py # 演示重试机制如何放大模型调用次数 def expected_calls(success_rate: float, max_attempts: int) - float: 计算一次请求平均会触发多少次模型调用。 假设每次调用独立且失败后立即重试最多尝试 max_attempts 次。 total 0.0 p_fail 1 - success_rate for attempt in range(1, max_attempts 1): # 执行到第 attempt 次的概率 前 attempt-1 次全部失败 prob p_fail ** (attempt - 1) total prob return total success_rate 0.8 max_attempts 3 print(f单次成功率 {success_rate}最多尝试 {max_attempts} 次) print(f平均每次请求实际触发 {expected_calls(success_rate, max_attempts):.2f} 次模型调用)如果模型接口在高峰期成功率只有 60%配置 3 次重试后平均每次请求会触发约 1.56 次调用比理想情况多了 56%。而很多生产事故里重试风暴会把原本一次就能成功的请求也拖入重试循环让调用量瞬间翻倍。更隐蔽的是模型的生成是流式的。一个生成到一半就超时的请求已经消耗的输入 token 和部分输出 token 同样会被计费。用户端已经放弃服务端的钱已经花了。5.3 人审兜底最容易漏算的“隐性成本”为了提高可靠性很多企业加了“人在环”环节AI 先生成草稿再由人工确认或修改。这个设计没问题但成本核算经常漏掉人工时间。更尴尬的是如果 AI 输出质量不稳定人工修改的时间可能比从头自己做还长这时“AI 降本”就是一句空话。正确做法是给每个 AI 功能同时记录“模型成本”和“人工介入成本”把两者放在同一张评估表里。如果某个功能的人工兜底成本高于手工直接完成那这个 AI 环节的价值就非常可疑。这一节的小结论是POC 验证的是效果不验证成本。生产环境的并发、重试和人工兜底才是账单暴涨的关键放大器必须在设计阶段就纳入成本模型。6. 成本治理第一步建立成本基线与可观测性6.1 为什么先建基线任何成本优化前提都是“可度量”。如果一个团队说不清每天消耗了多少 token、每个功能花了多少钱、哪个模型是支出大头那么所有优化动作都是拍脑袋。建基线的目标很简单让每一笔 Token 消耗都能归因到一个业务功能。只有做到这一点才能回答“这个月为什么涨了”“哪个功能最烧钱”“降模型后省了多少钱”这些关键问题。6.2 记录每一笔调用的关键维度在实际工程里建议在模型调用的统一入口处做一层包装把关键信息全部记录下来# cost_tracker.py # 一个极简的调用成本采集包装器用于建立成本基线 import time import json from dataclasses import dataclass, asdict dataclass class UsageRecord: timestamp: float feature_id: str # 业务功能标识如 customer_service model: str # 模型名称如 gpt-4o-mini input_tokens: int output_tokens: int latency_ms: int http_status: int def compute_cost(record: UsageRecord, price_input: float, price_output: float) - float: return (record.input_tokens / 1e6) * price_input (record.output_tokens / 1e6) * price_output def track_llm_call(feature_id: str, model: str, llm_func, *args, **kwargs): start time.time() response llm_func(*args, **kwargs) elapsed_ms int((time.time() - start) * 1000) usage response.get(usage, {}) record UsageRecord( timestamptime.time(), feature_idfeature_id, modelmodel, input_tokensusage.get(input_tokens, 0), output_tokensusage.get(output_tokens, 0), latency_mselapsed_ms, http_statusresponse.get(status, 200), ) # 实际项目中应写入日志管道或监控平台而不是打印 print(json.dumps(asdict(record), ensure_asciiFalse)) return response这个包装器要解决的核心问题是每一次调用是从哪个功能发起的、用了哪个模型、烧了多少 token、耗了多长时间。这些数据就是成本基线的原始素材。6.3 汇总、分析与告警有了逐笔记录后面的事情就好做了按 feature_id 汇总知道每个功能每天烧多少钱按 model 汇总知道哪个模型是支出大头按小时维度聚合发现流量高峰和成本高峰是否同步设置预算告警比如“某功能当日成本超过预设阈值”时自动通知。业界已经有专门做 LLM 可观测性的开源项目也会提供 token 消耗、成本估算、调用链追踪这类能力。团队可以先用手写日志跑通流程再逐步接入平台化工具。关键是不管用什么工具每个调用必须带 feature_id这是成本归因的生命线。这一节的小结论是没有成本基线的优化都是拍脑袋。先让每一个业务功能都能回答“我今天烧了多少 token、多少钱”再谈优化。7. 成本治理实战缓存、模型路由、压缩与配额护栏7.1 缓存复用成本治理的第一杠杆在 AI 调用里缓存是最直接、风险最低的优化手段可以分为两层精确缓存请求完全相同直接返回历史结果语义缓存请求语义相近通过向量相似度判断后返回缓存答案。知识库问答、FAQ、产品介绍这类重复率高的场景非常适合做缓存。下面是一个语义缓存的简化示例# semantic_cache.py # 语义缓存通过向量相似度判断“相似问题是否命中缓存” # 实际项目中embed_func 通常是对应的向量化模型接口 class SemanticCache: def __init__(self, embed_func, similarity_func, threshold0.92): self.embed_func embed_func # 输入字符串 - 向量 self.similarity_func similarity_func # 计算余弦相似度 self.threshold threshold self.items [] def get(self, query: str): query_vec self.embed_func(query) for cached in self.items: if self.similarity_func(query_vec, cached[vector]) self.threshold: return cached[answer] return None def set(self, query: str, answer: str): self.items.append({ query: query, answer: answer, vector: self.embed_func(query), }) # 使用示例 # cache SemanticCache(embed, cosine_similarity, threshold0.92) # answer cache.get(如何修改密码) # if answer is None: # answer call_llm(如何修改密码) # cache.set(如何修改密码, answer) # print(answer)使用语义缓存时要注意三点一是阈值要调合适太高命中率低太低会返回错误答案二是对时效性敏感的内容要设置过期时间比如活动规则不能缓存旧版本三是生成类任务“写一封邮件”不适合语义缓存检索问答类任务才适合。7.2 模型路由不要所有请求都上旗舰模型很多团队的习惯是“所有请求都走最强模型”理由是省事。但大多数业务请求并不需要旗舰模型的全部能力。文本分类、关键词抽取、情感判断这类任务小模型完全够用代码生成、多步推理、长文档理解才需要旗舰模型。通过一个简单的路由规则即可把成本大幅降下来# router.yaml # 模型路由规则示例字段含义以实际网关实现为准 routes: - name: simple_tasks priority: 1 match: [文本分类, 命名实体, 关键词抽取, 情感判断] model: cheap_fast_model max_tokens: 512 - name: complex_tasks priority: 2 match: [代码生成, 多步推理, 长文档总结] model: flagship_model max_tokens: 4096 default: fallback_model路由可以由规则触发关键词、正则、任务类型也可以由一个小的分类模型先判断任务难度再决定走哪个模型。更高级的做法是动态路由先让小模型尝试如果置信度低再升级到旗舰模型。7.3 上下文压缩与用量控制除了缓存和路由还要管理单次调用的 token 规模多轮对话必须裁剪历史只保留最近几轮和早期关键信息长对话可以做“历史摘要”把旧轮次压缩成一段摘要再带进后续对话RAG 场景要控制检索片片的数量和质量不要“多检索”堆上下文系统 Prompt 定期清理去掉冗余背景信息。做上下文压缩时最关键的是建立“质量回归集”每次修改压缩策略都要跑一批典型用例确认效果没有明显回退。省 token 不能以牺牲核心功能质量为代价。7.4 配额护栏给成本装上刹车工程化的最后一道防线是配额和告警每个功能设置单日预算上限超过后自动降级到小模型或停止调用每个团队设置月度配额避免某个业务线滥用共享资源对异常调用设置熔断比如某个 Key 突然产生超量请求时自动拦截所有阈值要落在监控系统里而不是写在文档里。配额不是“限制业务”而是“防止事故”。真正的 AI 成本事故几乎都是没有护栏导致的账单一夜飙升。这一节的小结论是优化是一个分层动作能缓存先缓存能路由就路由不能压缩就控量最后才是考虑整体降模型。每一层都要有对应的监控指标。8. 成本排查企业 AI 账单异常的常见误区和定位方法8.1 常见误区对照表常见误区表象真实原因正确做法所有请求都上最强模型效果满意但单价很高没有区分难度分级建立分级模型路由只关注模型单价单价降了总账还是涨用量与架构倍率被忽略同时监控用量和倍率不做缓存直接上线相同问题重复计费缺少缓存层精确缓存 语义缓存POC 成功就全量放量上线后账单飙升并发、重试、多团队接入先压测再逐步放量用更便宜的模型解决一切效果下降人工兜底成本上升成本不只有模型单价综合评估全链路成本没有成本日志无法定位是哪笔调用花了钱缺少可观测性建立按业务线的成本追踪8.2 异常账单的定位顺序当“模型没变、功能没变、账单却突然上涨”时建议按下面顺序排查查流量是不是某个业务线的请求量突然上升比如营销活动、爬虫或脚本误调用查重试是不是上游某段时间不稳定导致大量超时重试查上下文是不是某个长文档功能把 Prompt 越撑越长单次调用金额上涨查缓存缓存是否失效或语义缓存的阈值被调低导致命中率下降查 Key共享 API Key 是否有其他团队误用或存在泄露风险。这里要特别提醒如果排查后发现是因为业务量正常增长导致成本上升这不叫事故而是预算规划问题。成本治理的目标不是让账单不涨而是让上涨可解释、可预判、可控制。9. 最佳实践与工程建议把成本治理变成持续动作9.1 先小范围试点带上成本指标再放量不要一上来就全量接入 AI。选择一两个核心场景先跑通效果同时记录成本基线。只有当“效果指标”和“成本指标”都清晰之后再考虑扩大范围。这个顺序能避免很多控制不住账单的团队掉进同一个坑。9.2 分级模型与可回退策略建议默认设计成“小模型先行、大模型兜底、规则模型回退”三层结构。简单任务直接由小模型处理复杂任务升级到大模型极端情况可以直接切回规则和模板。这样既能控制成本又能在模型服务异常时保住最基本的可用性。9.3 缓存层是成本治理的第一优先在所有优化手段里缓存是投入产出比最高的一个。先做精确缓存再做语义缓存优先覆盖重复率高的知识库问答和客服场景。缓存命中率要作为核心监控指标目标不是越高越好而是要在“成本”和“新鲜度”之间找到业务可接受的平衡点。9.4 异步化与批处理对不要求实时响应的任务比如日报生成、批量摘要、离线分类尽量走异步和批量处理。批量接口通常比实时调用更便宜还能把算力峰谷填平降低基础设施成本。9.5 每个功能都必须有成本归因所有模型调用统一走带 feature_id 的封装入口。从第一天起就做好成本归因后面才能回答“哪个功能最烧钱”“哪个模型应该替换”“预算应该加到哪个业务线”。临时性的代码绕过统一入口都会在成本报表上留下盲区。9.6 成本治理不是一次性项目模型价格会变、业务量会变、架构会变所以成本治理要持续运营。建议每个迭代周期做一次“AI 成本复盘”对比上个周期的 token 消耗、缓存命中率、路由占比和单功能成本把变化量讲清楚。成本负责人不是某个人而是每个接入 AI 的团队都要承担的职责。9.7 不要把省钱做成单纯的模型降级最后一条要特别强调成本优化的目标是让每一笔 Token 花费可解释、可归因、可控制而不是把模型降级到不可用。如果为了省钱让小模型处理超出能力范围的任务导致效果下降、人工兜底成本上升那反而是总成本上涨。衡量优化是否成功的标准只有一个在效果指标不下降或者可接受下降的前提下总拥有成本是否下降。把“成本”和“效果”放在同一张评估表里永远比单独看任何一边更接近真相。如果你所在的团队正在为 AI 账单发愁建议先从“成本基线”开始做起把每个功能的调用量、token 数、模型占比拉出来你会很快发现真正吃钱的可能不是你以为的那个环节。下一轮再评估降本方案时请把倍数思维带进去。真正优秀的 AI 工程不是把每一个请求都压到最低价而是让每一笔付出都能对应到明确的业务价值。这也是企业 AI 成本治理的最终标准。
