如果你最近关注大模型应用的定价会发现一个很有意思的交叉现象用户侧价格标到 1 元平台再补贴 5.6 元看起来几乎等于免费使用但真实算力账单完全不是这个量级。一次带长文档、多轮工具调用或者批量生成的复杂任务成本会从“几毛钱”跳到“几百块”极端情况下单任务跑到“几千块”也不奇怪。这个现象值得每个做 AI 产品、接大模型 API、或者自己跑推理服务的人认真拆一遍。低价引流是市场策略成本黑洞是技术账。策略可以短期补贴账本必须长期算清。很多团队并不是业务不行而是月底看到云账单才发现卖 1 元一单的产品实际变动成本高到离谱。这篇文章不是产品测评也不拉踩任何厂商。我会把“用户花 1 元、平台补贴 5.6 元、成本却是几千元”这件事拆成四个部分成本从哪里来、哪些业务最容易爆量、开发者怎么用工程手段控本、什么时候该自部署、什么时候该用 API。看完之后至少你能在下一版产品里做出一套自己的成本监控和预算告警。1. 大模型应用“成本黑洞”到底是什么所谓成本黑洞指的是用户支付价格和平台补贴收入远低于提供这段 AI 服务的真实成本。这里的真实成本不只是“一次接口调用”的账单还包括 GPU 算力消耗、上下文存储、结果返回、人工兜底、客服审核、合规处理等一整套链路。把“1 元 5.6 元补贴”和“几千元成本”放到一起其实是在对比两个完全不同的记账口径。1 元是用户侧价格5.6 元是平台补贴两者加起来是平台为这个用户付出的市场成本。而几千元往往不是单次对话它是一个复杂任务流程、一个用户在一段时间内的累计调用、一次批量生成任务甚至是异常流量造成的全部算力开销。很多团队在做定价时只看“单次对话”不看“任务总成本”这是最容易被账单教育的地方。为什么传统软件不会出现这种黑洞因为传统软件的边际成本趋近于零服务器和带宽成本相对稳定。生成式 AI 则不同每一次生成都消耗真实算力token 越多、步骤越多、单次生成要求越高边际成本就越明显。如果产品还按“软件订阅”的思路定价比如一个会员月卡 30 元随便用那在重度用户面前就是直接亏钱。成本黑洞的本质是产品用了传统互联网的“免费引流 补贴留存”打法去承接一个边际成本不为零的生成式服务。补上的那一刻账由技术团队兜底。所以解决成本黑洞不能只靠财务调表必须靠架构、模型路由、请求控制、缓存、限流这些工程手段。2. 一次大模型调用成本是这么算出来的要控制成本第一步是把成本算出来。大模型 API 最常见的计费单位是 token输入和输出通常分开计价。一次请求的基本成本模型可以写成总成本 输入token数 × 输入单价 输出token数 × 输出单价输入 token 是用户发给模型的内容包括系统提示词、历史对话、上下文文档输出 token 是模型生成的回答。大部分平台输出 token 单价比输入高因为模型生成阶段是逐 token 解码无法并行对显存带宽和算力要求更高。除了 token 单价真实成本还受并发、批处理、模型参数规模、推理框架影响。同样处理 100 万 token在一张大卡上做连续批处理和在多张小卡上单条跑成本差很多。所以你对外的 API 价格是一个值你的真实算力成本是另一个值两者之间就是优化空间。下面这段 Python 脚本可以帮你做一个快速成本估算。里面的单价只是演示参数不是真实报价你需要按自己接入的服务商控制台填实时价格def estimate_cost(input_tokens, output_tokens, input_price_per_million, output_price_per_million): cost (input_tokens / 1_000_000) * input_price_per_million \ (output_tokens / 1_000_000) * output_price_per_million return cost cases { 短问答: (2000, 500), 长文档总结: (200_000, 5000), Agent多轮执行: (1_000_000, 30_000), } # 演示参数输入按 1 元/百万token输出按 10 元/百万token for name, (in_tokens, out_tokens) in cases.items(): cost estimate_cost(in_tokens, out_tokens, 1.0, 10.0) print(f{name}: {cost:.4f} 元)这里有一个容易被忽略的问题中文 token 数不是按字数等价换算的。同一段文字在不同模型的分词器里可能对应不同数量 token所以监控时以 API 返回的 usage 字段为准不要自己用“字数除以 2”这种粗暴估算。另外一次真实业务请求往往还会连带其它成本内容安全审核、向量化、检索、日志存储、带宽、回调函数、人工复核。这些不会出现在大模型账单里却同样计入业务成本。做成本控制时必须按“一个任务从进入系统到最终返回”的全链路来核算。3. 哪些业务容易把账单拉到“几千元”3.1 长上下文多轮对话很多聊天机器人会不断把历史消息一起发给模型。对话轮数越多输入 token 越大。如果一次会话反复上传长文档每一轮都是几万到几十万 token 的输入成本会随轮数线性上涨。3.2 Agent 工具调用与多智能体这类业务最吓人。一个 Agent 可能要做规划、调用搜索、读网页、执行代码、再看结果继续回复。每一步都是一次完整模型调用而且每步的上下文还可能继续累积。一个复杂任务跑出十几轮模型调用很正常账直接翻好几倍。3.3 图片、视频、3D 生成Diffusion 模型要做多次去噪迭代一次生成消耗的算力远超普通文本对话。分辨率、步数、帧数、批量生成数量都会直接影响账单。这类任务在高峰期的 GPU 占用率极高也是最容易出现“单个任务几千元”的场景。3.4 批量任务与自动化脚本批量翻译、批量内容总结、批量图文生成只要任务量起来成本就是线性放大。如果业务方把批量任务丢在白天和用户请求抢资源还会进一步推高基础设施成本。3.5 Key 泄露或恶意刷量这是成本黑洞的极端情况。API Key 一旦被泄露会被脚本在短时间内大量调用。有监控的团队可能几小时就能发现没有监控的团队往往等到月底账单才反应过来已经形成一笔不小损失。3.6 人工兜底成本AI 服务出错后用户投诉、客服介入、专家复核、退款赔付这些环节虽然不直接体现在 GPU 账单里但会让“单用户成本”进一步扩大。用户付 1 元平台补贴 5.6 元再叠加一次人工投诉综合成本很容易翻数倍。判断一个业务会不会出现成本黑洞可以看三个信号单次任务调用模型次数多不多、上下文是否不断累积、生成内容是否属于高算力类型。三个信号占得越多账单越危险。4. 为什么价格比成本低还要卖从纯粹财务角度看卖一单亏一单是不可持续的。但大模型应用现在还处于市场教育期平台想解决的问题不是“每一单赚钱”而是“让用户先开始用”。低价和补贴是在降低尝试门槛。用户对生成式 AI 的能力边界还不熟悉如果第一次体验就要付几十块很多人会直接流失。定价 1 元平台再补 5.6 元用户实际感知成本几乎为零这是典型的获客逻辑。另一个原因是竞争。各家大模型服务商都在用低价策略抢调用量因为真实用户调用数据对模型迭代、评测、厂商生态建设都有价值。你主动降价至少能换来一批愿意跑量、反馈问题的开发者和用户。这里的风险在于如果真实成本是几千元而补贴只能覆盖几块钱那这种模式必须依赖两种情况之一才能长期运行一是模型和算力成本快速下降二是用户后续产生高价值付费。如果两者都没有发生补贴就只是给流量打工。真正健康的策略应该是把成本结构优化到“不补贴也能跑”的程度再决定要不要用补贴抢速度。5. 先把成本“按请求”监控起来不管要不要继续补贴第一步是记账。建议从每次 API 调用开始把结构化的成本日志记录下来至少要包含请求 ID、用户 ID、模型名、输入 token、输出 token、总耗时、任务类型、日志时间。下面这个例子用 OpenAI 风格的 SDK 做了一个简化封装目的是展示如何从响应的 usage 字段里拿到 token 数并写入日志。不同服务商的字段命名可能有差异但思路是一样的import json import time import uuid def call_model_with_cost_log(client, messages, user_id, model): start time.time() resp client.chat.completions.create(modelmodel, messagesmessages) usage resp.usage log { request_id: str(uuid.uuid4()), user_id: user_id, model: model, prompt_tokens: usage.prompt_tokens, completion_tokens: usage.completion_tokens, total_tokens: usage.total_tokens, latency_ms: int((time.time() - start) * 1000), created_at: int(time.time()), } with open(usage.log, a, encodingutf-8) as f: f.write(json.dumps(log, ensure_asciiFalse) \n) return resp, log有了日志之后每天或每小时做一次聚合按用户、模型、任务类型统计累计 token 和估算成本。成本聚合的关键是给每个模型维护一份实时单价不要写死在业务代码里最好放到配置中心或环境变量。统计口径越早统一越好。建议直接给每次调用加一个估算成本字段而不是等月底再算。下面这个配置结构可以作为一个初始模板实际字段根据你自己的系统设计调整# cost_config.yaml models: small_model: input_per_million: 1.0 output_per_million: 5.0 large_model: input_per_million: 5.0 output_per_million: 20.0 alert: user_daily_limit_cny: 50 task_total_limit_cny: 500 notify_channel: webhook告警规则要覆盖几个维度单个用户日成本超限、单个 API Key 小时调用次数突增、某个任务类型单日成本超限、批量任务并发失败率升高。监控的意义不是让财务好看而是把“成本失控”从月底发现提前到当天发现。6. 工程化堵漏模型路由、缓存、限流、上下文裁剪记账解决的是“知道钱花在哪”工程化堵漏解决的是“让钱花得少”。这一套组合拳做下来通常能在不牺牲太多效果的前提下明显降低单位成本。6.1 模型路由不要让所有流量都打最强模型。简单分类任务、格式化任务、常规问答用小模型或高效模型就能完成复杂推理、长文档分析、代码生成再路由到大模型。路由规则可以基于问题长度、意图分类、历史召回质量也可以用一个小模型做“预分类”。模型路由的最大价值是让大模型只处理那部分真正需要它的请求。调用量大的产品模型路由带来的成本降幅通常比单纯砍请求更可观。6.2 语义缓存很多用户问题本质是重复的特别是客服、FAQ、文档问答场景。如果每次都交给大模型重新生成等于把同样的钱付很多遍。可以先用 Embedding 把用户问题向量化再和已有回答做相似度检索超过阈值就直接返回缓存结果。缓存的粒度可以是一整段回答也可以是检索后的上下文片段。对高重复率业务语义缓存能显著降低输入 token 总量同时让响应速度更快。6.3 上下文裁剪长对话成本膨胀的核心原因是历史消息过多。解决方式三种截断最老的消息、对历史消息做摘要、把不相关的上下文从 prompt 中移除。摘要方案适合 Agent 类任务截断方案适合客服场景但都要做效果回归避免上下文信息丢失导致回答质量下降。6.4 限流与用户额度给每个用户设置日调用次数、单次最大 token 数、每日估算成本上限。超过阈值后可以降级到小模型、排队处理或者直接提示用户等待明天。对免费用户、付费用户、企业用户分别设置等级。下面是一个简单的用户预算控制伪代码class UserBudget: def __init__(self, daily_limit_cny: float): self.daily_limit_cny daily_limit_cny self.usage {} def check_and_account(self, user_id: str, estimated_cost: float): spent self.usage.get(user_id, 0) if spent estimated_cost self.daily_limit_cny: raise BudgetExceeded(fuser {user_id} exceed daily budget) self.usage[user_id] spent estimated_cost return True这套措施同样适用于 Key 管理。每个业务线、每个环境、每个第三方应用都使用独立 Key方便单独限额和追踪。一旦发现 Key 被刷可以立刻吊销而不会影响其它业务。7. 自部署还是调用 API算清楚再选很多团队问过一个同样的问题自部署大模型是不是更便宜答案取决于你的流量规模、团队运维能力和数据敏感度。自部署的主要成本集中在 GPU 采购或租赁、电力、机房、带宽、模型存储、以及一大块容易忽略的运维人力。API 调用的主要成本集中在 token 单价以及上游平台可能发生的限流和价格调整。两者没有绝对的谁更便宜只有谁更适合当前阶段。维度自部署大模型调用现有 API启动成本高需要 GPU 资源和机房低注册即可调用单位成本高并发下可能更低取决于平台定价运维成本高需要监控、更新、调优低可定制性高可以改推理参数和量化低按平台规则走上线速度慢快数据控制可控适合私有数据取决于合规要求适用场景中高并发、数据敏感快速验证、低并发、弹性流量如果产品处于早期流量不稳定先调用 API 做验证是更合理的选择。等到单模型并发需求稳定、且成本占比明显升高时再考虑自部署。自部署不是用来“省掉 API 单价”的万能方案而是要在固定成本和可变成本之间找平衡点。自部署场景下最基本的资源观察命令是watch -n 1 nvidia-smi重点看显存占用、GPU 利用率、温度、功耗。推理服务启动后如果 GPU 利用率长期很低说明请求不足或批处理没生效如果显存逼近上限要考虑量化、换更小模型、或调整批次大小。另一个判断点是数据安全。涉及私有数据、用户隐私数据时自部署确实更容易控制数据流向但你仍然需要自己处理日志脱敏、模型加固、权限管理。调用 API 则要对平台的数据使用条款做审核确保符合自己的合规要求。8. 推理侧还能省什么当成本已经从“业务调用层”优化到一定程度下一步就是把视角转向推理侧。这里同样有很多工程手段8.1 量化把模型从 FP16 降到 INT8 或 INT4显存占用降低单位 token 需要搬运的数据量也降低。对很多场景来说量化后的质量损失可以接受尤其适合对话和分类任务。8.2 蒸馏用大模型生成高质量训练数据蒸馏出一个小模型。小模型参数量更低推理更快成本也低。适合那些任务边界清晰、不需要顶尖能力的场景。8.3 KV Cache 优化长上下文推理时KV Cache 会占用大量显存。优化手段包括 PagedAttention、前缀缓存等。多轮对话中如果前面几轮内容不变可以复用 KV Cache避免重复计算。8.4 Prefill 与 Decode 分离部署Prefill 阶段是计算密集型Decode 阶段是显存带宽密集型。两者混合部署容易互相挤占资源。把它们拆开部署到不同规格的机器上可以提升整体吞吐和资源利用率。8.5 连续批处理传统 batch 要等最慢的请求结束单位时间利用率不稳定。连续批处理按请求粒度动态调度哪些请求准备好了就送哪些进 GPU能明显提升吞吐。对高并发应用很有价值。8.6 投机解码用小模型先生成一批候选 token再用大模型一次性验证。如果候选通过率高整体生成速度会提升单位时间内能产出更多 token间接降低成本。8.7 降级策略高峰期可以把图片分辨率降低、视频帧数减少、Agent 最大执行轮数收紧。这类降级不会完全杜绝成本但能避免“所有请求都按最高规格跑”造成的满载风险。9. 常见“成本失控”问题排查即使做了前面几步业务上线后还是会遇到各种成本异常。关键在于能不能快速定位。下面是一张可以直接对照的排查表问题现象可能原因排查方法解决方案成本在深夜暴涨批量任务或恶意脚本在夜间执行按小时统计成本曲线定位起始时间给批量任务设置时间窗口加预算告警单个用户成本异常高Key 泄露、自动化刷量查该用户调用次数和 token 分布封禁用户、吊销 Key、加单用户限额长对话越用越贵上下文无限增长对比每轮 prompt_tokens 变化做历史摘要、上下文裁剪、对话轮数上限调用量正常但账单偏高实际使用了更高价模型检查模型路由日志调整路由规则简单任务降级到小模型响应速度变慢GPU 显存不足、批处理未生效用 nvidia-smi 看 GPU 利用率调小批次、开启连续批处理、量化模型批量任务中断导致重复计费任务失败后没有做幂等控制查看任务日志和请求 ID增加重试幂等失败任务记录断点排查成本问题最怕只看总额不看明细。所以前面强调的“按请求记录日志”会在这种时候发挥真正作用。没有日志排查只能是猜有日志你至少能回答三个问题哪个用户、哪个任务、哪个模型花了最多钱。10. 给产品与商业化团队的建议技术侧的优化只能降低单位成本产品侧的定价策略则决定成本能不能被商业模型消化。两者必须配合。第一建立单位经济模型。每个用户一个月平均调用多少次每次调用成本多少付费转化率多少客单价多少。这个公式越早搭越好不要等到补贴期结束才开始算。第二补贴要设门槛。完全无门槛的免费流量会吸引大量只薅羊毛、不产生长期价值的用户。可以把补贴集中在首次体验、学生认证、企业试用这些更有转化潜力的场景。第三分级定价。免费版限制模型规格和调用次数付费版解锁更强模型企业版支持更高并发和私有化部署。高成本能力比如视频生成、长文档推理、Agent 高频调用单独按量计费或放入高套餐。第四高成本功能要和主产品隔离。如果主产品是文本对话就不要让每一个用户都能随意生成高清视频。单独设置入口、单独计价避免少数重度用户拖垮整体毛利率。第五所有折扣和免费额度都要和成本监控打通。运营发券前先评估这批券预计会带来多少 token 消耗再决定券的面值和适用范围。产品团队还要关注退款和客诉成本。AI 服务出错频率不低如果回答质量差导致大量用户投诉人力成本会直接影响单用户成本。适当的提示词调优、模型路由、结果审核机制其实也是成本控制的一部分。11. 回到那一块钱“用户花一块钱巨头补贴五块六也盖不住几千块成本黑洞”这句话看起来夸张但它准确反映了大模型商业化的一个本质矛盾市场侧用低价换用户技术侧必须用工程手段把成本降下来否则补贴只能让亏损扩大。对于正在做 AI 应用的团队比讨论“能不能烧钱”更重要的事情是先做好三件事。一是给每个请求打上成本字段先让成本可见二是给用户、模型、任务类型设置预算上限避免单个异常流量拖垮整月账单三是建立每周成本账单回顾持续优化模型路由和上下文策略。等这三件事做完你再来决定要不要学巨头发补贴。用户花一块钱确实很爽但你的账单必须能活下来。对于大多数中小团队最稳的打法是在补贴之外把真实成本压到自己能接受的定价区间再用模型选型和推理优化建立长期竞争力。