几乎每一个把大模型接进生产环境的团队都会在某个节点被同一个问题卡住这个功能到底该怎么收费讨论 Agent、多模态、AI 编程的人很多但真正把“AI 怎么定价”这件事讲透的内容很少。等到产品上线、账单出来的时候团队才发现Token 成本不是线性增长的用户用量是两极分化的按次计费可能卖一单亏一单包月又可能被重度用户直接薅穿。我的判断很直接AI pricing 并没有坏坏的是我们还在用旧软件的定价框架来套 AI 服务。这篇文章不打算讨论“价格战”也不替某家厂商算账。我想解决的问题是一个做 AI 应用的团队如何从成本拆解、价值锚定、模式设计到系统落地走完一套可执行的定价方案。包括用最小的 Python 工具把成本算清楚用配置驱动定价规则以及上线之后怎么验证和迭代。1. AI 定价不是玄学而是一条工程链路1.1 为什么最近大家都在讨论 AI 定价大模型 API 的计价方式打破了传统软件的定价直觉。传统软件卖的是“能力”价格颗粒度是席位、版本、LicenseAI 服务卖的是“每次推理消耗的资源”价格颗粒度是 Token、请求次数、任务完成度。这两种模式完全不同但很多团队在做商业化时第一反应还是翻开 SaaS 的定价手册抄一个“基础版 / 专业版 / 企业版”出来。结果往往是按 Token 计费用户看不懂账单每一行都觉得被扣了冤枉钱按席位收费发现同一版本下轻度用户用量极低重度用户成本远超客单价按结果计费又很难定义“结果”到底怎么量化遇到恶意 or 复杂场景容易被钻空子。这不是定价没做好而是定价之前的问题没有解决成本结构没有拆清楚价值锚点没有定明白。1.2 三个典型误区第一个误区把 Token 当带宽来卖。带宽的成本相对固定卖多少都有底线Token 成本却会随着上下文、缓存命中率、模型选型剧烈波动。按量计费如果只看消耗不看价值单位毛利的波动会非常大。第二个误区照搬 SaaS 订阅制。SaaS 的边际交付成本几乎为零所以包月包年很容易核算AI 服务每多一次调用就多一次推理成本。订阅制不是不能用而是必须先做容量规划和成本上限控制否则一个高频用户就能吃掉几十个普通用户的毛利。第三个误区所有场景用同一个计价维度。智能客服、内容生成、Agent 任务、代码辅助它们的成本结构和价值密度完全不同。把四种场景塞进同一张价目表要么用户价值感被稀释要么成本被隐藏。所以前面提到的判断在这里就成立了AI 定价不是财务部门单独能拍板的事它需要模型选型、缓存策略、用量计量、账单系统一起参与本质是一条成本工程加价值工程的链路。2. 先把成本拆明白AI 服务的“三张账单”在讨论客户愿意付多少钱之前先回答另一个问题一次请求到底花了多少钱很多团队只盯着大模型 API 的 Token 单价忽略了 AI 服务的完整成本链条。我把它们拆成三张账单。2.1 算力层账单如果使用自建 GPU 集群这张账单包括服务器采购、机房电费、运维人力、模型部署和弹性扩缩容成本。即使按 API 调用这部分成本也隐藏在服务商的报价里。它的特点是固定成本高、变动成本低。对平台型团队来说算力利用率直接决定单位成本对这个问题的重视程度决定了最终毛利。2.2 模型调用层账单这是最明显的成本但包含不少细节输入 Token、输出 Token 通常是分开计价输出 Token 一般更贵上下文越长单次调用的 Token 消耗越大缓存命中率低时相同逻辑可能反复计算Agent 场景下一个任务可能触发多次模型调用成本是叠加的。从工程角度看这里的优化空间最大。上下文缓存、模型路由、批量推理、结果复用都能直接降低单位成本。2.3 产品层账单最后别忘了 AI 应用自身的基础设施成本向量数据库、对象存储、检索服务、第三方 API、人工审核甚至账单系统本身的存储和计算。这一层容易被忽略因为它不直接体现在模型调用里。但如果产品每天处理几十万次请求这些成本会可靠地出现在月底账单上。使用模式成本特点典型场景对定价的影响实时对话短输入、短输出次数多智能助手、客服适合按请求次数或套餐计量批量处理长输入、长输出次数可控文档总结、数据处理适合按任务或按 Token 计量Agent 多轮调用多次模型调用成本不可预测自动化任务、深度分析必须按任务结果封装计价高频嵌入单次成本低调用量大搜索、推荐、向量化定价要细到单次请求以下3. 主流的四种 AI 定价模式对比成本拆完之后再来看模式选择。市面上常见的是四种按 Token、订阅制、按结果计费和混合模式。3.1 按 Token 计费这是大模型 API 服务商的标准做法也是争议最大的一种。优点成本透明用户用多少付多少对服务商来说单位经济模型最清晰。缺点用户感知不到 Token 的实际价值。普通用户不知道 2000 Token 是什么概念只觉得账单复杂。适用场景API 开放平台、开发者工具、内部系统成本分摊。3.2 订阅制席位制/套餐制从 SaaS 时代延续过来的模式按用户或按团队收费。优点用户心理负担小预算可控产品方现金流稳定。缺点必须提前做容量规划。如果订阅套餐没有用量上限高用量用户会无限拉高推理成本。适用场景面向普通用户的产品工具用户群体对 AI 用量差异不大。3.3 按结果计费不是按“用了多少资源”收费而是按“完成了什么任务”收费。比如翻译一篇文档收 2 元生成一张合规海报收 5 元一个 Agent 自动完成客户分类收 100 元。优点价值感强客户容易理解产品方收益上限高。缺点结果定义复杂如果结果指标定义不完整容易被异常输入绕过或恶意刷量。适用场景任务型产品有清晰可验收的业务结果。3.4 混合模式目前实际落地最好的一种方式基础订阅保证收入稳定超量后按用量或按任务加收费用。典型设计是“免费试用额度 付费套餐 超额按量”。这样轻度用户永远不用付费重度用户贡献的额外收入也能覆盖额外成本。四种模式对比如下模式价值感知成本风险用户理解成本推荐场景按 Token 计费低低高API 平台、开发者工具订阅制高高低用量均衡的工具型产品按结果计费很高中中任务型产品、Agent混合模式中高中中大多数 B 端和 C 端 AI 产品这里补充一个常见概念很多平台避开了 Token 一词改用 Credits点数。本质是把 Token 消耗折算成平台积分好处有两个一是降低用户对底层计量的困惑二是 Credits 的换算规则平台可控当模型成本下降时可以直接调高单位 Credit 的购买力不必频繁修改前台价格。4. 一套可复用的 AI 定价框架模式选完之后怎么把价格数字定出来这里给出一套相对通用的三变量框架。4.1 三个关键变量第一成本单位。先明确一次计费的基本单位是什么一次请求、一个任务、还是一个月活跃用户这个单位要尽量和成本对齐也要和用户价值对齐。第二价值锚点。客户用这个功能替代了什么省了多少人工带来多少增量收入减少多少错误率价值锚点决定了价格上限。第三弹性边界。最低价不能低于单位成本最高价不能超过客户能感知到的价值。在这条区间内再根据竞争环境、品牌定位、获客成本来调整。4.2 一个案例AI 客服定价假设你在做一个 AI 客服产品客户是一家月营收 100 万元的电商公司。成本侧一次 AI 客服会话平均消耗 2500 Token其中输入 1800、输出 700。按演示价格估算单次会话成本约 0.03 美元左右实际请填写你的模型价格。价值侧客户每月收到 1 万次客服咨询如果 AI 能处理其中 70%相当于替代约 7000 次人工响应。按每次人工响应成本 10 元计算月价值约为 7 万元。定价区间成本下限是 10000 次会话 × 0.03 美元 300 美元价值上限是 7 万元人民币中的一部分比如收取增量价值的 15% 作为服务费约 1500 美元。那么一个合理的月费锚点可以落在 500 到 1500 美元之间。低于 300 美元是亏本高于 1500 美元会挑战客户的心理阈值。这个例子说明AI 定价不是拍脑袋而是先用成本框住下限再用业务价值框住上限。4.3 从定价到定价规则确定单一价格之后还要把它扩展成一组规则。通常做法是免费层让用户低门槛体验但用量限制要能覆盖成本付费层为大多数用户提供足够用量企业层包含更高配额、私有化部署、更长的上下文或定制模型服务。每一层之间要有明确的分界避免出现“免费用户把 AI 当生产环境用”的情况。5. 用 Python 搭建定价测算工具前四章是方法论这一章给出可直接运行的代码。以下三个脚本不依赖第三方库Python 3.10 及以上版本即可运行。5.1 环境准备python --version mkdir ai-pricing-tool cd ai-pricing-tool只需要 Python 标准库。模型单价请填写服务商最新报价下面的价格仅为演示占位。5.2 代码一单次请求 Token 成本计算新建文件token_cost.py# 文件路径ai-pricing-tool/token_cost.py 单次请求 Token 成本估算。 价格仅为演示请填入模型服务商最新报价。 def calculate_request_cost( input_tokens: int, output_tokens: int, input_price_per_million: float, output_price_per_million: float, cache_hit_tokens: int 0, cache_read_price_per_million: float | None None, ) - dict: 计算一次模型请求的成本。 :param input_tokens: 输入 token 总数含缓存命中与未命中 :param output_tokens: 输出 token 数 :param input_price_per_million: 每百万输入 token 价格美元 :param output_price_per_million: 每百万输出 token 价格美元 :param cache_hit_tokens: 命中缓存的输入 token 数 :param cache_read_price_per_million: 缓存命中时的每百万 token 价格 if cache_read_price_per_million is None: # 假设缓存读取价格约为输入价格的 10%请按服务商实际价格调整 cache_read_price_per_million input_price_per_million * 0.1 cache_miss_tokens max(input_tokens - cache_hit_tokens, 0) cache_hit_cost (cache_hit_tokens / 1_000_000) * cache_read_price_per_million cache_miss_cost (cache_miss_tokens / 1_000_000) * input_price_per_million output_cost (output_tokens / 1_000_000) * output_price_per_million total_cost cache_hit_cost cache_miss_cost output_cost return { cache_hit_cost_usd: round(cache_hit_cost, 6), cache_miss_cost_usd: round(cache_miss_cost, 6), output_cost_usd: round(output_cost, 6), total_cost_usd: round(total_cost, 6), } if __name__ __main__: result calculate_request_cost( input_tokens1800, output_tokens700, input_price_per_million3.0, output_price_per_million15.0, cache_hit_tokens1200, ) print(result)运行命令python token_cost.py预期输出{cache_hit_cost_usd: 0.00036, cache_miss_cost_usd: 0.0018, output_cost_usd: 0.0105, total_cost_usd: 0.01266}这段代码帮你把“一次请求花了多少钱”从经验判断变成可重复计算。注意缓存命中率对成本的直观影响如果 1200 个输入 Token 全部按原价计算成本会明显上升。5.3 代码二定价区间估算新建文件pricing_range.py# 文件路径ai-pricing-tool/pricing_range.py 从单位成本倒推最低价从业务价值估算上限。 def estimate_min_price(cost_per_request_usd: float, target_margin: float) - float: 根据单位成本和目标毛利率计算最低售价美元/次。 if target_margin 0 or target_margin 1: raise ValueError(target_margin 必须在 (0, 1) 区间) return cost_per_request_usd / (1 - target_margin) def estimate_max_price( customer_monthly_revenue: float, efficiency_gain_pct: float, service_fee_pct: float 0.1, ) - float: 从客户业务价值估算月度价格上限。 :param customer_monthly_revenue: 客户月度营收或月度成本基数 :param efficiency_gain_pct: AI 带来的效率提升比例例如 0.2 表示提升 20% :param service_fee_pct: 产品方从增量价值中抽取的比例 value_created customer_monthly_revenue * efficiency_gain_pct return value_created * service_fee_pct def build_pricing_band( cost_per_request_usd: float, target_margin: float, monthly_requests: int, customer_monthly_revenue: float, efficiency_gain_pct: float, service_fee_pct: float 0.1, ) - dict: min_price estimate_min_price(cost_per_request_usd, target_margin) max_price estimate_max_price( customer_monthly_revenue, efficiency_gain_pct, service_fee_pct, ) min_price_monthly min_price * monthly_requests band { min_price_per_request_usd: round(min_price, 6), min_price_monthly_usd: round(min_price_monthly, 2), max_price_monthly_usd: round(max_price, 2), } if min_price_monthly max_price: band[warning] 成本下限高于价值上限需要降低推理成本或调整目标毛利 return band if __name__ __main__: band build_pricing_band( cost_per_request_usd0.01266, target_margin0.6, monthly_requests10000, customer_monthly_revenue100000, efficiency_gain_pct0.7, service_fee_pct0.15, ) print(band)运行命令python pricing_range.py预期输出{min_price_per_request_usd: 0.03165, min_price_monthly_usd: 316.5, max_price_monthly_usd: 10500.0}价格上下限算出来之后可以用来判断一个商业方案的可行性。如果成本下限已经超过价值上限说明当前单位成本或目标毛利需要调整而不是继续硬定一个价格。5.4 代码三月度账单模拟先创建pricing_config.json{ pricing_model: hybrid, currency: USD, plans: [ { name: free, monthly_fee: 0, included_requests: 100, extra_request_price: 0.01 }, { name: pro, monthly_fee: 49, included_requests: 5000, extra_request_price: 0.008 }, { name: enterprise, monthly_fee: 499, included_requests: 100000, extra_request_price: 0.005 } ], cost_control: { cache_enabled: true, model_routing: true, daily_budget_usd: 500 } }再创建simulate_monthly_bill.py# 文件路径ai-pricing-tool/simulate_monthly_bill.py import json def simulate_monthly_bill( request_log_by_user: dict, config_path: str, plan_name: str pro, ) - dict: 根据用户请求量和定价配置模拟月度账单。 :param request_log_by_user: {用户名: 月请求数} :param config_path: pricing_config.json 路径 :param plan_name: 套餐名称 with open(config_path, r, encodingutf-8) as f: config json.load(f) plan next(p for p in config[plans] if p[name] plan_name) results {} for user, total_requests in request_log_by_user.items(): included plan[included_requests] extra max(total_requests - included, 0) extra_cost extra * plan[extra_request_price] total plan[monthly_fee] extra_cost results[user] { plan: plan_name, total_requests: total_requests, included_requests: included, extra_requests: extra, monthly_fee: plan[monthly_fee], extra_cost: round(extra_cost, 2), total_bill: round(total, 2), } return results if __name__ __main__: demo_log { user_001: 3200, user_002: 6200, user_003: 15000, } bills simulate_monthly_bill(demo_log, pricing_config.json, pro) for user, bill in bills.items(): print(user, bill)运行命令python simulate_monthly_bill.py预期输出类似user_001 {plan: pro, total_requests: 3200, included_requests: 5000, extra_requests: 0, monthly_fee: 49, extra_cost: 0.0, total_bill: 49.0} user_002 {plan: pro, total_requests: 6200, included_requests: 5000, extra_requests: 1200, monthly_fee: 49, extra_cost: 9.6, total_bill: 58.6} user_003 {plan: pro, total_requests: 15000, included_requests: 5000, extra_requests: 10000, monthly_fee: 49, extra_cost: 80.0, total_bill: 129.0}这个脚本最大的价值是验证套餐设计是否合理。如果一个套餐里 80% 用户的用量都在 included 范围内说明套餐阈值可能偏高需要下调或调整超额价格。6. 定价上线之后的验证与迭代定价不是一次性的商务决定而是一个需要持续观察和调整的系统行为。6.1 三个核心运营指标第一是单位毛利每个请求或每个任务的真实成本与真实收入之差。低于预期时说明定价未覆盖成本或推理成本失控。第二是成本收入占比模型调用成本加基础设施成本占订阅收入的比例。一般建议保持在可接受范围如果超过阈值需要优化成本或调整价格。第三是付费转化率与留存率免费用户转付费的比率以及付费用户次月续费率。这两个指标反映价格是否落在用户价值感知区间内。6.2 灰度发布与回滚定价改动上线时不要直接全量切。建议按用户群体灰度新用户先适用新价格老用户保留旧价格一定周期按地域或行业分组验证每个价格版本预留回滚开关。价格配置的管理方式和代码版本一样需要可回滚、可追溯。这要求定价规则不能只存在运营人员的表格里而应该作为可配置的代码或配置文件进入版本库。6.3 用量日志需要记录哪些字段成本模型是否准确取决于用量日志的完整度。建议在请求日志中记录以下字段字段说明user_id用户标识request_id请求唯一标识model_name实际使用的模型名称input_tokens输入 Token 数output_tokens输出 Token 数cache_hit_tokens命中的缓存 Token 数latency_ms请求耗时task_type任务类型例如 chat、summarize、agentcost_estimate服务端估算成本created_at请求时间这些字段同时服务于成本核算、漏洞排查和功能调优是定价工程化的基础数据。7. 常见问题与排查思路问题现象可能原因排查方式解决方案单位毛利为负模型单价上涨缓存命中率低查看每日成本日志和缓存命中率启用输入缓存、批量推理、换用更低成本模型用户抱怨账单复杂Token 计费维度太多分析用户反馈和使用分布改为按任务或套餐计费封装 Credits订阅用户用量两极分化不同用户对 AI 需求量差异大按分位数统计用量增加超额计费层分层定价按结果计费被刷量结果指标定义不完整审查漏斗指标和异常使用特征使用组合指标加入人工抽查和风控新价格上线后申诉量激增价格调整未做迁移缓冲查看申诉数据和灰度配置保留老用户旧价周期逐步切换成本账单和预估偏差大缓存/重试/上下文拼接处理不一致对比日志中的 cost_estimate 与模型账单统一成本计算口径定期对账需要强调的是定价相关的问题大多不是“某一天爆出来的”而是长期积累的。建议把成本日志、用量统计和财务对账做成日常巡检项不要等月底才发现异常。8. 最佳实践把定价工程化8.1 成本日志先行动手做 AI 应用的第一天就记录每个请求的模型、Token、耗时和估算成本。不要等商业化阶段再补历史数据是定价决策最重要的依据。8.2 缓存与模型路由优先在调价格之前先把推理成本降下来。上下文缓存、模型路由、小模型兜底能有效降低单位成本。这些工程手段会让定价模型有更大的回旋空间。8.3 价格配置要进入版本库定价规则不要只写在运营表格里建议写成 JSON 或 YAML 配置纳入 Git 管理。每次调价都走代码评审和发布流程配合监控指标一起观察。8.4 安全与合规边界涉及价格、配额、账单的系统权限必须做好隔离。建议遵循最小权限原则定价配置和用量明细只有授权人员可修改和查看。任何批量调价操作先在生产环境之外的小流量用户上验证再逐步放开。8.5 定期做成本和价格对账模型服务商的价格半年内可能多次调整产品团队应该定期检查单次请求成本是否还在预期区间。当成本显著下降时可以适当让利给用户这也是提升竞争力的方式。9. 总结AI 定价没坏坏在旧框架回到文章开头的判断。AI 定价之所以让很多人觉得“复杂”“算不清”“怎么定都亏”并不是这个领域本身无解而是我们习惯性地套用了传统软件的定价思路。传统软件卖的是资产AI 服务卖的是持续发生的智能与算力消耗。资产可以按版本打包卖消耗品必须按成本、用量和价值三重维度来设计价格。只要把成本拆到请求级把价值锚定在业务结果上再通过工程手段把定价规则变成可配置、可监控、可回滚的系统定价这件事完全可以做得清楚明白。如果你正在做 AI 应用商业化下一步可以先做三件事把请求日志里的成本字段补齐写一个上面这样的成本计算脚本然后拿出一张纸写下你的客户用这个功能到底省了多少钱。这三件事做完你的定价方案大概率已经比市面上大多数“拍脑袋”方案靠谱了。