应用层 开放阅读

用量制计费

Usage-Based Pricing

概念 ID
usage-based-pricing-2
更新时间
2026-05-29
来源数量
待补

用量制计费

3 秒看懂

用量制计费是将“使用量”作为唯一或主要结算依据的定价模型——客户按实际消耗的计算、存储、网络或业务单元付费,无需预付固定周期或购买固定容量。它是云计算“按需自助”承诺的财务实现层,也是AI大模型商业化的核心引擎,推动着企业IT支出从CAPEX向OPEX的结构性迁移。该模型也可被称为基于使用的定价、按量计费、效用计费、消费定价、即付即用定价、基于消费的定价或后付费计量。在中文语境下,“量”是计费凭证,“制”是制度安排,二者共同构成“用多少付多少”的完整商务机制。

3 分钟产业解释

用量制计费将“资源”抽象为可计量、可定价、可出账的“消费单元”,在每一次资源被实际占用或业务价值被实际交付时触发计费事件。在AI和云计算产业链中,它解决了经典的两难问题:客户若按峰值负载预置资源,则产生大量闲置浪费;若按均值预置,则面临峰值溢出和服务降级。UBP的产业本质,是用实时计量的技术手段将资源供给与业务需求精确对准,使得客户只需为“有效使用”部分付费,而供应商则通过与客户成功深度绑定的收入模型,分享客户业务增长带来的用量红利。

对AI算力而言,训练作业只在GPU被实际分配计算时计费,推理请求仅在token生成完成的瞬间产生费用;对对象存储,费用跟随字节数增长而线性或阶梯式变动;对Serverless函数,则进一步细化到“请求次数”加“执行时长×内存规格”双重维度。UBP抹平了需求波动带来的财务摩擦,使创业公司可以用几十美元启动一个AI实验,大企业则可以跨部门实施按用量分账的精细化成本治理。该模型通常与自动弹性伸缩、计量管道、计费引擎、额度管控和成本可视化工具深度耦合,形成一个从“消费”到“出账”的实时闭环。2023年以来,纯UBP虽然在新兴AI API领域占据主导,但在整个云市场中,混合计费(保底+超额按量)已然成为更普遍的选择——它平衡了客户对支出可预测性的诉求与供应商对收入稳定性的需要。值得注意的是,尽管UBP在某些语境下常被直接等同于订阅模式(subscription),但在严格意义上二者存在本质区别:UBP是基于实际用量的变动计费,订阅通常是固定周期内的固定费用;产业实践中二者可能整合为混合模型。

技术原理

用量制计费的技术本质是一套“采集—传输—聚合—定价—出账—管控”的实时数据管道,其对准确性、低延迟和横向扩展能力的要求,远超传统批处理式计费系统。该管道通常由五大模块构成:

1. 计量采集层

计费的起点是对每一次资源消耗或业务事件的精细化记录。采集点部署在API网关、Hypervisor、存储控制器、容器编排器出口和GPU调度器等关键路径上,以Sidecar进程或内置钩子的形式实时捕获以下维度的元组:(租户ID、资源类型、用量数值、时间戳、地域标签、业务标签)。对AI推理服务而言,计量点通常嵌入Token化引擎输出侧,记录模型ID、有效token数(区分prompt token与completion token)、请求是否成功终止等属性;对训练任务,采集发生在GPU调度器分配物理算力片段的时刻,记录任务ID、GPU型号、占用秒数和节点数量。采集点的设计必须满足两个相互矛盾的要求:极低的开销(不能在热路径上增加可观延迟),以及极高的可信度(记录不能被篡改或丢失)。

2. 流式传输与缓冲层

采集到的原始用量事件以日志或消息的形式流入传输层。产业主流方案是Apache Kafka或Apache Pulsar作为分布式消息总线,承担削峰填谷和持久化缓冲的职责。一条典型的用量事件消息大小约200字节至1千字节,在云超大规模场景下,单个区域的事件写入速率可达每秒数百万条。消息队列不仅隔离了采集端与处理端的速率差异,还通过多分区、多副本机制保证在节点故障或网络分区时事件不丢失。

3. 流式聚合与转化引擎

从消息队列拉取原始事件后,流处理层(常基于Apache Flink、Spark Streaming或云原生托管流计算服务)执行窗口化聚合。关键操作包括:

  • 去重:基于事件唯一标识消除采集端重试产生的冗余。
  • 标准化:将异构资源用量转换为统一计费单位(如毫秒累加为秒,字节累计为GB·月,请求次数汇总为千次)。
  • 维度关联:将用量数值与定价元数据(资源等级、地域系数、时段折扣、承诺用量抵扣优先级)关联,生成“已定价切片”。

窗口粒度直接影响计费延迟与系统吞吐的权衡。产业实践中,秒级聚合用于实时配额管控和预算熔断,分钟级聚合用于近线出账,小时级聚合用于日账单生成和对账。

4. 定价引擎与账单生成

定价引擎是UBP系统中最富商业复杂性的模块。它维护着一张高维定价矩阵,维度包括但不限于:资源类型、规格、地域、时段、累积用量阶梯、承诺用量方案、免费配额、市场折扣等。对于每个聚合后的用量切片,引擎在内存中展开矩阵,实时计算费用,并处理复杂的抵扣逻辑——例如先抵扣客户已购买的承诺用量包,再对超出部分应用阶梯价,最后减去节省计划或预留实例的权益。定价规则通常以领域特定语言或规则引擎实现,确保业务人员可以调整费率而无需改动核心管道。账单行项目生成后,写入下游OLAP数据库(如Snowflake、ClickHouse或自研分布式账务存储),并通过API或Portal向客户披露。SaaS场景下,该模块还需与Stripe、Orb等第三方计费平台对接,输出符合财务合规要求的发票。

5. 额度管控与限流闭环

计量数据并非单向地流向账单系统,它同时反灌至配额管理模块,形成实时管控闭环。当客户设置的每日预算上限或并发请求上限将被触达时,管控模块通过令牌桶或分布式信号量机制,在网关或调用链路的入口处拦截超量请求,并向调用方返回“预算耗尽”或“速率受限”的响应状态码。这一机制在AI API服务中尤为关键,因为它既保护客户免受意外账单冲击,也保护供应商的底层算力池不被单一租户占满。

可靠性设计要点

计量管道的可靠性直接影响收入确认和客户信任,因此系统通常采用至少一次送达语义,并辅以定期的离线物理对账(由独立的审计管道重放底层基础设施日志,与主计量管道的结果交叉校验)。产业经验表明,丢单率需控制在0.01%以下,计费延迟需在T+0至T+1内完成,且系统应具备跨可用区容灾能力——这意味着计量管道的每层都须有热备或双活设计。

下图以抽象代码块形式概括了数据流向(不构成实际部署架构):

+-----------------+     +-------------------+     +--------------------+
|  计量采集层      |---->|  流式传输与缓冲    |---->|  流式聚合与转化     |
| (网关/SDK/Sidecar)|     | (Kafka/Pulsar)     |     | (Flink/Spark,窗口化)|
+-----------------+     +-------------------+     +--------------------+
         |                         |                          |
         v                         v                          v
  限流决策点                 用量就地缓存              定价引擎 & 账单生成
  (令牌桶/信号量)                                   (规则矩阵,阶梯,折扣)
                                                               |
                                                               v
                                                   企业ERP / 支付网关

关键参数

评估用量制计费系统和商业模式时,以下量化参数构成核心分析框架:

参数定义典型目标/行业观察计量口径与备注
计量准确率已记录计费事件数 / 实际应计费事件数≥99.99%(公有云厂商公开SLA级别)含丢失率和对账差异率,通常通过离线审计管道验证
计费延迟从用量发生到账单可查询的时间间隔T+0(实时)至T+1(次日),产业中间值约4-8小时实时管道需在秒级完成聚合,但客户可见账单常以小时为粒度
超额用量占比超出客户承诺用量的部分占总用量的百分比混合计费模式下通常为15%-40%(行业访谈口径,无全量公开基准)该值越高,说明客户对弹性的依赖越强,UBP地位越不可替代
用量留存率当期使用过服务的客户在下一期继续使用的比例头部AI API厂商公开资料较少,可参考SaaS月活留存中位数约90%比财务留存更前置:用量留存下降预告未来收入减速
单位经济模型-毛利(收入 – 流转的第三方资源成本)/ 收入对于AI推理API,公开资料未见系统性毛利率基准,需个案分析关键驱动变量:推理GPU成本摊销至每1k token的水平 vs. API定价
客单价演变单客户月度/年度经常性收入初期因从小用量起步而偏低,随客户渗透加深而逐季上升监控“客户启动后第N月ARPU”队列曲线,成长型公司N=12时通常为N=1时的2-5倍(公开资料常见定性描述)
单位成本递减率每单位用量处理成本随规模扩张而下降的速度受硬件代际(如H100 vs A100)和软件优化双重驱动,间隔一代GPU,推理吞吐可提升2-5倍若UBP定价降幅小于成本降幅,毛利率扩张;若定价降幅大于成本降幅,则“以价换量”
信用风险敞口已产生用量但尚未收回的应收账款与月收入之比后付费模式天然存在敞口,公开资料未见统一基准需监控坏账率和平均回款天数,与预付费模式形成对照

注:上表中定量数值除非特别标注来源,均来自行业公开信息聚合与典型实践,不构成对任何具体公司指标的预测或披露。

技术路线

用量制计费在技术和商业模式上的演进,形成了三条典型路线,其分野体现为计费粒度粗细、定价信号与业务价值的耦合深度、以及技术实现复杂度的递进:

路线一:资源级计量(资源即计费单元)

这是云计费的基础形态,将物理或虚拟化资源(vCPU·秒、GB·秒、网络流出字节数、存储GB·月)作为计费原子。该路线的优势在于直观——计量对象与基础设施资源一一对应,客户易于理解“花钱买了什么”;供应商也只需在Hypervisor或调度器出口挂载计量钩子,技术成熟、实现风险低。但其劣势也日渐凸显:资源消耗与业务价值之间的映射松散,客户买的是“算力马力”而非“业务成果”。在GPU租赁场景下,资源级计费表现为“每GPU·秒”,但客户真正关心的是“每完成一次高质量生成”的效率和成本。

路线二:事件级计量(请求或执行为计费单元)

Serverless计算(如AWS Lambda)和API经济(如短信、邮件发送服务)推进了这一路线。计费粒度从“占用多少资源时长”转向“发生了多少次有效请求”,并将资源消耗隐性包含在每次执行或每千次调用的定价中。事件级计量更靠近业务逻辑,减少了客户对底层资源维度的认知负担,但对供应商的计量精度和资源隔离能力提出了更高要求——供应商必须在同一物理节点上精确区分不同租户请求的资源占用比例,并将其合理归因。AI领域的“每API调用”或“每生成张数”基本属于此路线。

路线三:价值级计量(业务语义为计费单元)

这是UBP的前沿演进方向,将计费锚点从“用了多少资源”切换为“创造了多少可度量的业务价值”。AI大模型的“每1k token”计费即是当前最接近此路线的实践——token是语言的信息密度单位,与最终输出的业务效用强相关。更进一步,部分Image/Video生成平台开始尝试按“生成并下载的有效图片/视频数”计费,而非按底层GPU秒数计费,从而将质量失败成本(生成模糊或不符合要求的图像)从客户转移至供应商,强化了供应商优化模型和推理效率的激励。价值级计量要求计量引擎能理解业务语义(如解析token数、审核输出内容、校验质量门槛),技术复杂度远超前两条路线,但其定价透明度与业务对齐度也最高。

混合模式:路线间的桥梁

现实中,多数服务并不完全固守单一路线,而是将上述路线组合进混合定价模型。常见模式为“保底月费(预留一定量的资源或事件) + 超额按量(事件级或价值级)+ 阶梯费率”,或者“低量级免费 + 中量级按事件计费 + 高量级协商价值分成”。这种混合设计试图同时俘获客户对支出稳定性的偏好、供应商对增长弹性的追求,以及小微企业客户的零门槛启动需求。

量化对比

维度资源级计量事件级计量价值级计量
计费单元示例vCPU·秒、GB·秒、TB·月每百万次请求、每次函数执行每1k token、每生成并确认的有效图片
与业务价值对齐度
客户认知门槛需理解资源术语中等通常直观
供应商实现复杂度较低高(需多租户精确归因)极高(需语义解析与质量判断)
典型采用场景传统IaaS、裸金属租赁微服务/Serverless/基础API大模型推理、创意生成平台
收入波动性中高

上游

用量制计费的上游由一系列使“量”能被精准、实时、安全地采集、传输和处理的基础设施技术与服务构成。

1. 计量采集 Agent / SDK

这是计费数据链路的“神经末梢”。在网关层面,典型实现如基于Envoy或NGINX的自定义过滤器,在请求转发的同时捕获并异步上报用量事件;在应用SDK层面,供应商常提供集成OpenTelemetry标准的轻量客户端,自动记录API调用、token消耗等业务计量维度。对私有化部署或混合云场景,采集Agent还需具备离线缓冲和签名能力,确保在断网或时钟偏移时,计量数据的完整性和可信度不降级。采集仪的防篡改设计(如基于硬件可信根或客户端哈希链)是高级别SLA场景的必要增强。

2. 流处理引擎与消息中间件

这是计费数据链路的“循环系统”。Apache Kafka的事实标准地位,使其成为用量事件消息总线的首选;部分对延迟极度敏感的GPU云服务商,则采用共享内存或RDMA方案在节点内跨进程传递计量信号,再批量投递至远端队列。Apache Flink凭借其精确一次语义和窗口化聚合能力,占据流处理的主导地位,而依托Spark Streaming的批微批混合架构在部分传统企业架构中仍有余留。这些引擎需在高峰期消化每分钟数十亿条事件的吞吐压力,并预留足够的空余容量应对突发尖刺。

3. 计费引擎产品与平台

专门为UBP模式设计的计费引擎封装了定价规则、折扣矩阵、汇率转换、税务适配和发票格式化等复杂逻辑。典型产品如AWS Marketplace Metering Service、Azure Commerce Platform,以及独立计费基础设施商Stripe Billing、Orb、Metronome等。这些平台通常提供低代码规则编辑器,允许业务人员在不涉及底层管道改动的情况下创建或修改定价方案、阶梯层级和免费配额。对AI服务商而言,能否支持“按token”、“每GPU·秒”、“每完成图片”等多维混合定价,是选型计费引擎的关键衡量点。

4. 配额管理与限流中间件

与计费管道紧耦合的限流组件负责在用量接近客户设定阈值或信用额度时实施管控。技术方案常采用Redis或自研分布式计数器的滑动窗口限流算法,并在API网关侧注入决策逻辑。Sentinel、Envoy的限流过滤器等开源组件也被广泛二次开发后集成进计费闭环。

5. 监控与可观测性平台

计量管道本身需要被严密监控。Datadog、Grafana Cloud等可观测性平台在“监控计费系统健康度”这一利基上扮演关键角色,追踪计量丢失率、管道背压、聚合窗口延迟等核心健康指标,并在异常时触发告警。FinOps工具(如CloudHealth、Vantage、Apptio)提供更上层的成本可视化与异常用量检测能力,虽处于UBP的消费端,但其底层需要接入上述监控数据源。

下游

用量制计费的下游生态涵盖直接使用该模型向最终客户交付服务的企业,以及围绕用量数据衍生出的成本管理、咨询和财务治理服务。

1. AI应用与服务商

这是当前UBP增长最迅猛的下游分支。OpenAI的GPT系列API、Anthropic的Claude API、Google的Vertex AI和AI Studio、微软Azure OpenAI Service、国内大模型厂商的MaaS平台,均以“每1k/1M token”为定价默认。这些公司的收入涨跌与开发者和企业客户的调用量直接联动,构成“用量增长→显示产品价值→吸引更多用例→用量再增长”的正反馈循环。此外,Hugging Face的推理端点、Replicate等AI模型托管平台亦按GPU实例运行时长或单次推理调用计费。需要注意,尽管token计费在AI推理领域极为常见,部分AI训练和微调服务仍以资源预留制为主导。

2. SaaS公司嵌入AI功能

大量成熟的SaaS企业在原有订阅费基础上,以UBP形式单独销售AI附加功能。例如,Notion AI对工作区成员按AI功能使用额度计费;Canva对AI生成功能和背景移除工具设定月度免费额度,超额按次或按包计费;Zendesk、Salesforce等CRM/客服平台在其Einstein GPT等智能功能中引入基于用量的附加收费。这一模式使SaaS公司得以将AI推理的高边际成本直接转嫁或部分转嫁至使用方,同时保持基础订阅费的稳定现金流。

3. 传统企业IT转型消费者

金融、制造、零售等传统行业的IT部门正将越来越多的批处理作业、数据管道、灾备环境迁移至Serverless或按量计费的容器平台上,以替换过去常年预留但利用率低下的私有化集群。对于这些部门,UBP的直接收益是将IT支出与业务季节性和项目型工作负载对齐,将大量沉默成本转化为随业务弹性变化的可变成本。但挑战同样显著:成本治理能力滞后,容易出现“账单冲击”,催生企业对FinOps人才和工具的迫切需求。

4. FinOps与成本优化工具商

UBP的普及使“管理云账单”成为一项专门的工程学科。CloudHealth(VMware)、Spot by NetApp、Vantage、Apptio Cloudability等工具,通过持续拉取多云账单和用量报告,实施异常检测、资源规格建议、闲置资源识别、承诺用量规划等分析,帮助客户在不牺牲业务弹性的前提下将按量账单压缩15%-35%(该区间为多家工具商公开案例口径,非严格统计)。这些工具商的业务增长,事实上与UBP在企业渗透率的提升高度正相关。

5. 系统集成商与咨询公司

UBP的落地常伴随组织财务流程变革,系统集成商和云咨询公司因此在计费系统搭建、标签策略设计、成本分账模型建立等环节提供专业服务。德勤、埃森哲等均有云财务管理专项实践,帮助大型企业从“中心化IT预算”过渡到“业务部门按用付费”的运营模型。

受益公司

用量制计费模式的渗透与深化,在不同环节使以下典型类别的公司受益(注意:受益逻辑基于产业趋势公开分析,非投资建议或业绩预测):

超大规模云厂商 – AWS、微软Azure、谷歌云。UBP是这三家IaaS/PaaS层的基础商业模式之一,随着企业将更多通用工作负载迁移至云,以及AI/ML、大数据分析等用云量大的新型负载爆发,其按量收入池不断扩大。Azure通过OpenAI API独占托管权,将模型推理用量直接转化为云计算消费;AWS的Bedrock、SageMaker和GCP的Vertex AI则分别在各自生态中吸引模型训练和推理用量。各云厂商2023年财报及电话会均提及“AI相关用量”对云收入增速的拉动(具体数字因公司而异,且未来增量存在不确定性)。

独立AI API与模型即服务公司 – OpenAI、Anthropic、Cohere、以及部分国内对标厂商。这些公司不拥有底层大规模基础设施,但凭借模型能力和开发者生态建立品牌,UBP几乎是其唯一可行的商业化路径。它们的收入直接与开发者社区的调用量挂钩,因而在定价策略上极为审慎,频繁调整token价格、引入细粒度模型等级(如GPT-4o与GPT-4o-mini)、或推出阶梯批量折扣。公开信息显示,OpenAI已公开宣布其API收入在2023-2024年高速增长,但精确数字需查阅其官方披露。

垂直SaaS厂商 – Adobe、Salesforce、ServiceNow。这类公司的核心商业模式仍是订阅制,但AI功能的叠加打开了新的按量收入空间。Adobe Firefly生成点数、Salesforce Einstein GPT的用量附加费、ServiceNow的智能自动化运行次数等,均属于“订阅+UBP”的混合模型先行实例。由于这些公司的基数庞大,即使附加AI功能的每用户平均收入(ARPU)提升幅度乍看不大,其绝对增量收入规模仍可观。

专用GPU云与新算力供应商 – CoreWeave、Lambda Labs等。面对AI训练和推理对GPU的爆炸性需求,这些公司以比超大规模云厂商更灵活的按秒/按小时GPU实例计费模式切入市场,在特定高性能配置和响应速度上形成差异化。2023-2024年,此类公司的融资与估值扩张迅速,反映市场对GPU算力供需错配的定价。其收入模型天然是UBP,规模的扩大直接受益于AI应用层的繁荣。

计费基础设施与成本管理公司 – Stripe、Orb、Metronome(计量计费中间件);CloudHealth、Vantage、Apptio(FinOps成本管理)。它们处于UBP的“工具层”,为SaaS和AI公司提供从计量到出账的完整组件,或为企业客户提供多云的统一账单治理。UBP渗透率越提升,对这些工具的需求越刚性。

需要明确的是,上述公司的“受益”程度高度依赖其执行能力、技术演进速度、竞争格局变化以及宏观需求波动,且不同公司的财务披露口径差异较大,不宜直接横向对比。公开资料未见的细节,此处不臆造。

市场规模

(数据口径说明:以下引用年份均指数据所对应的公开年份,非预测期。因实时检索受限,部分基准数据来自行业共识与权威机构过往报告,遇不确定性则标记“公开资料未见”。)

云基础设施市场总量与UBP权重

Gartner数据显示,2023年全球公有云最终用户支出约为5918亿美元(来源:Gartner,2024年1月发布),涵盖IaaS、PaaS、SaaS等。其中,IaaS和PaaS层以用量制计费为主导付费模式,SaaS层传统上以订阅制为主、但UBP混合模式占比持续提升。Synergy Research Group的数据显示,2023年Q4全球云基础设施服务收入(IaaS+PaaS+托管私有云)约740亿美元(年化近3000亿美元),几乎全部支持以某种形式的按量计费。由于云厂商未统一披露“纯UBP收入”与“预留实例/长期合同收入”的比例,精确的UBP分额属公开资料未见;但行业共识为,按量计费是云基础设施服务不可或缺的基本商业元素,混合模式中超额按量部分在总用量中的占比较为可观。

AI API与模型推理市场

大模型API推理市场是UBP增长的集中体现。多个行业报告与分析师估计,2023年全球生成式AI市场(含模型API、中间件、应用)在400-600亿美元区间(来源口径存在差异,此处综合Gartner、IDC、Bloomberg Intelligence等机构预测的中间值),其中模型推理API是增速最高的子领域之一,且几乎全部采用UBP。公开信息显示,OpenAI在2024年年中对外交流时透露其API年化收入已达到数十亿美元量级(具体数字请查阅OpenAI官方或权威财经信源);Anthropic、Cohere等独立厂商的收入规模相对较小但增长较快。需要强调的是,这一市场仍在极早期,年度排名和份额波动剧烈,精确市场份额数据具有时效性,建议读者以最新财报和权威分析报告为准。

UBP中间件与FinOps市场

根据公开资料,云成本管理及FinOps工具市场在2023年约在10-20亿美元级别(综合IDC、Gartner相关细分市场估算),并预期随企业多云环境的深化而持续扩大。UBP计费基础设施(如Stripe Billing、Orb、Metronome等所在细分)的市场规模难以精确切分,因为它们通常嵌套在更大范围的“支付与计费基础设施”统计中,且大量交易额经支付通道流转,公开细分市场规模数据有限。

关键趋势

  • 企业采用UBP的速度在AI时代明显快于十年前云原生初期,反映出市场对灵活消费模型的接纳度提升。
  • 混合计费预计在中长期仍是主流,纯UBP在中小企业的吸引力和大型企业的风险管控需求之间形成拉锯。
  • 国内市场方面,公开研究报告(如艾瑞、易观)显示,中国云计算市场2023年约4000-5000亿元人民币,但AI大模型API和公有云按量付费的份额分布与海外存在结构性差异(受混合云、私有化部署偏好的影响),详细数据因各机构口径差异较大,建议直接查阅相关报告。

玩家对比

(注:以下对比基于公开产品信息与行业认知,不作完整排名,仅呈现差异化特征。市场份额数据具时效性,请以最新财报和第三方审计报告为准。)

定价单位与最小粒度对比

服务商/产品典型计费单元最小计费粒度特色设定
OpenAI API每1k/1M token(区分prompt与completion)每次调用(token数舍入至1k或1M的分数)多模型阶梯价,2024年频繁降价和引入更便宜的模型等级
Anthropic API每1M token类似OpenAI强调安全性和可控性的模型定位,定价策略跟随但保持溢价区域
Azure OpenAI Service同OpenAI模型token计费,叠加Azure云资源消耗token层面同上,注意区分部署付费模式与Azure生态绑定的身份管理、网络、合规能力为差异卖点
AWS Bedrock按模型推理请求次数及每1k token计费,或按使用时长视模型而定多模型托管,同一API调用多供应商模型
Google Vertex AI / AI Studio按推理调用、token、或训练节点·时视具体服务与Google生态深度集成,Gemini模型定价具竞争力
CoreWeave GPU云每GPU·时/秒按秒聚焦H100/H200等高端GPU,合同灵活性高于超大规模云
Stripe Billing / Orb作为计费引擎,按交易或坐席计费不直接面向最终AI用量使其他SaaS/AI公司快速落地UBP的中间件

差异化维度分析

  • 与生态绑定深度:Azure OpenAI凭借与微软365、GitHub Copilot、企业身份管理的集成,形成系统锁定优势;AWS Bedrock则在已使用AWS的客户中自然渗透。
  • 模型多样性与单一模型策略:AWS Bedrock和Vertex AI扮演“模型聚合器”角色,强调客户可在同一平台上切换不同供应商的模型;OpenAI和Anthropic则以自有前沿模型为唯一核心,品牌认知鲜明。
  • 计费透明度与复杂度:OpenAI和Anthropic的token计费模式最具可解释性;超大规模云厂商的AI推理账单常与网络、存储、数据传出等费用交织,需借助FinOps工具才能清晰归因。
  • 中国市场参与者:阿里巴巴、百度、字节、华为云均推出各自的大模型API,普遍采用token或调用次数计费,且价格竞争激烈。国内企业的另一特征是对私有化部署的需求更高,部分厂商提供“买断式”或“资源预留式”大模型交付方案,不完全依赖公有云UBP。已公开发布的token价格为公开信息,但各厂商之间的精确市场份额排名和营收数据,建议查阅IDC中国市场报告或公司财报。

风险

用量制计费在释放弹性和降低门槛的同时,也为供应商和客户双方引入了值得关注的风险类别:

1. 收入波动与经济周期敏感度

供应商的UBP收入天然随客户业务量波动:若客户缩减广告投放、减少用户活跃度或下线应用,API调用量和GPU消耗量立即下降,供应商收入同向变动。在2022-2023年全球科技行业预算收紧周期中,多家云厂商的用量增速一度放缓,部分已公开的增速下滑为公开披露信息。对于以UBP为主要收入来源的初创公司,宏观经济下行阶段的收入韧性弱于以多年合同为基石的订阅制公司。

2. 价格战与同质化竞争

在AI API赛道,模型能力固然是核心壁垒,但当多个供应商在基准测试上的性能差距收窄时,定价便成为差异化竞争武器。2023-2024年,OpenAI、Google、以及国内大模型厂商接连下调token单价或推出低配低价模型,使行业面临定价纪律被破坏的风险。如果UBP单价下降的速度持续快于单位成本下降的速度,供应商的单位经济模型将恶化,出现“量增利不增”的局面。

3. 计量错误与信任危机

UBP的核心是“用多少就计多少”,若计量系统出错(多计费、漏计费、计量丢失)或账单结构晦涩难懂,将迅速侵蚀客户信任。2021年曾有个别云厂商因复杂的账单结构引发客户激烈反弹的案例(属于行业公开讨论),提示即使在技术高度成熟的环境下,“计费信任”仍属需持续投入的高优先级事务。AI token计费因其单位抽象、数量庞大,计量标准(如不同模型对token定义的一致性)和第三方审计机制的缺失,构成潜在争议点。

4. 替代性定价模型的竞争

尽管UBP在AI领域占据主导,但并非没有替代选项。开源模型的性能追赶、企业内部的私有化微调部署,以及“买断式”企业许可(on-premise license)在数据敏感行业中的顽固存在,均限制了纯UBP的渗透天花板。此外,部分平台型公司开始实验“结果导向定价”(如按生成的合格图像张数收费),虽然仍属于广义UBP范畴,但更激进的价值绑定风险也更高。

5. 客户成本治理失能与“账单冲击”

UBP的自由度是一柄双刃剑:缺乏FinOps实践或监控告警的客户,容易因配置错误、代码bug、或DDoS攻击导致用量异常飙升,在下一期收到天文数字账单。此类“账单冲击”事件在云计算历史上屡见不鲜,AI领域因大模型推理的高算力成本而放大潜在危害。头部云厂商已有预算警报、自动熔断等功能,但客户主动配置的比例仍有提升空间。

6. 监管与交易对手风险

UBP的后付费属性使供应商承担客户信用风险;在金融服务等受严格监管行业中,UBP可能还需应对“第三方集中度风险”的合规审查。此外,以token为单位的AI计费若被某些司法管辖区视为“数据流量”或“电信服务”,可能触发新的监管框架,目前公开资料未见系统性立法,但值得持续监测。

误读纠偏

误读1:“UBP对供应商是低利润模式”

纠正:UBP的单位毛利在完全不同的业务场景间差异悬殊,不能一概而论。对于有显著规模效应和硬件迭代红利的AI推理服务,若供应商能持续将单位成本降幅大于定价降幅,毛利率实际可随时间扩大;而对于缺乏技术护城河的同质化资源转售,UBP的确可能沦为微利生意。关键在于供应商是否掌握成本结构的持续优化能力,而非计费模型本身。

误读2:“把订阅改成按量就是UBP”

纠正:UBP不是简单地将功能清单拆散按次销售。真正的UBP产品需要投入计量管道的可靠性(丢单率容忍度极低)、定价梯度的精细设计(平衡鼓励用量与控制风险)、以及为客户提供可行的成本治理工具。如果仅仅改变计价单位,而忽略上述系统性的能力建设,可能引发更强烈的“计费焦虑”,反噬客户关系和收入增长。

误读3:“大客户不会喜欢用量制计费”

纠正:虽然大型企业在采购谈判中往往倾向于承诺用量折扣或定制合同以获得稳定支出,但并不意味着他们排斥UBP。事实上,大型客户常常将“承诺用量”与“超额按量”组合使用——通过承诺量锁定折扣,再通过按量部分吸收业务弹性;且大客户内部不同业务部门间的用量分账(showback/chargeback)必须依赖精细化的计量数据。UBP提供的用量透明性,本身即为大型组织的IT财务治理所需。

误读4:“UBP会暴露所有技术缺陷,因此供应商不敢做”

纠正:UBP确实要求服务具有更高的弹性和可计量性,但它同时也创造了正向激励:如果服务频繁宕机或响应缓慢,客户用量自然下降,供应商收入受损,因此供应商有更直接的商业动机去维护服务质量和持续优化性能。这与订阅制下“客户已预付、服务差可能导致续约率下降”的延迟反馈形成对比——UBP的反馈循环更快,但未必是单向的惩罚。

误读5:“客户采用UBP的产品一定更省钱”

纠正:UBP为客户提供了“按需付费”的机制,但“更省钱”不是自动保证。客户如果缺乏有效的用量监控、预算控制和架构优化,实际支出可能会超出传统预留模式。是否能省钱,取决于客户的运维治理成熟度、应用负载特征,以及能否充分利用弹性扩缩容来释放闲置成本。对于稳定基线负载,完全采用按量付费有时反而不如预留实例经济。

最新事件

(截至2024年中;事件基于公开新闻报道与公司官方公告整理,排名不分先后,不构成趋势预测)

  • OpenAI连续降价与模型分级:2023-2024年,OpenAI多次下调GPT-3.5与GPT-4o系列API的token单价(具体降幅与时间节点详见OpenAI官方博客),并推出更轻量、更便宜的GPT-4o-mini模型。这一系列动作被业界解读为利用规模效应和成本优势,扩大开发者生态并抬高竞争对手的准入门槛。
  • Anthropic发布Claude 3系列(2024年3月):Anthropic推出其新一代模型Claude 3 Opus、Sonnet、Haiku,分别对应不同性能与定价层级,进一步强化token计费的梯度体系。
  • 微软Azure OpenAI Service 商用加速:Azure OpenAI在2023-2024年间持续扩大区域可用性和模型阵容,并将OpenAI的API与Azure现有的企业合同和承诺消费协议整合,使大型客户可以统一管理订阅和用量账单。
  • Google Gemini API 全面上线(2024年):Google将Gemini模型系列接入Vertex AI及AI Studio,推出免费配额、按token计费以及与Google Cloud账户合并出账的完整商业链路。
  • Meta开源模型对商业UBP的间接影响:Meta持续发布开源的Llama系列模型(2023-2024年),尽管Meta自身不提供托管API,但大量第三方推理平台基于Llama提供商用UBP服务,加剧了长尾API供应商之间的价格竞争。
  • 国内大模型价格战(2024年上半年):阿里巴巴、百度、字节跳动等国内云厂商和大模型创业公司相继大幅下调模型推理API的token价格,甚至出现免费策略,反映出国内AI API市场从技术竞争快速转入规模与定价竞争阶段(来源:多家财经与科技媒体报道,具体价格请查阅各厂商公告)。
  • FinOps成为企业IT管理刚需:多家行业峰会和调查显示,云成本优化已从“可选实践”上升为组织最高IT优先级之一,FinOps Foundation的成员数与认证人数持续增长。

跟踪指标

对于希望持续监测用量制计费产业动态的读者,建议跟踪以下维度的公开数据和信号:

  1. 云厂商用量增速:在AWS、Azure、GCP的季度财报电话会议中,管理层通常会披露“计入承诺用量后的按量收入增速”或“剩余履约义务中与用量相关的比例”,用以判断UBP业务的健康度。关注其增速相对于合同收入增速的差值。

  2. AI API定价变动:OpenAI、Anthropic、Google的官方定价页面是重要的前置指标。频繁或大幅的降价,可能释放规模效应显现、竞争加剧、或新模型代际即将上线的信号。

  3. 单位经济指标:对于已上市的云和SaaS公司,关注毛利变动、单位成本趋势,以及电话会中对“优化率”(客户降低用量的努力)的描述。

  4. 用量集中度:在可获得数据的条件下,关注前5大或前10大客户贡献的收入占比变化。UBP原生公司的集中度若快速上升,可能隐含收入波动风险加大。

  5. 客户队列ARPU曲线:依时间跟踪“签约后第N月ARPU”的队列数据,判断客户是否在持续扩大用量。如果新近队列的成长斜率明显低于历史同类队列,需关注市场饱和或竞争替代的可能性。

  6. 监管与标准动态:跟踪ISO、全国信标委等是否有关于云计费、AI服务计量准确性的标准立项或征求意见稿;关注主要司法管辖区是否对“token计费”归属数据服务、电信服务或内容服务进行界定。这对于判断UBP中长期的合规成本至关重要。

  7. 开源计量计费项目活跃度:例如OpenMeter、KubeCost等项目的Star数、贡献者增长和厂商采用公告,可视为产业对“可观察的计量基础设施”兴趣的晴雨表。

信源

本文参考的信息来源包括:

  • 云厂商官方文档与财报:AWS计费文档、Azure定价与计费说明、GCP Cost Management文档;AWS/微软/谷歌季度财报及电话会实录(2023-2024年)。
  • AI公司官方定价页与博客:OpenAI Platform文档与定价页;Anthropic官方发布;Google AI Studio与Vertex AI定价页;Azure OpenAI Service文档。
  • 行业报告:Gartner公有云预测与云战略报告(2023-2024年);IDC全球云与AI市场追踪报告;Synergy Research Group云基础设施市场季度数据。
  • 风险投资与产业分析:Bessemer Venture Partners《State of the Cloud》年度报告(含UBP公司专章);a16z关于AI经济模型与用量制计价的博客系列;FinOps Foundation年度状态报告。
  • 技术社区与开源项目:OpenTelemetry计量规范;Apache Flink、Kafka在计费系统的实践案例;OpenMeter、KubeCost项目文档。
  • 财经与科技媒体:The Information、The Verge、TechCrunch关于AI API定价变动的报道;国内科技媒体关于大模型市场动态的新闻(2024年)。

读者请注意,所有定量数据均需核对原始来源的最新版本,市场排名和份额数据具有时效性。本文仅作为产业概念梳理与信息聚合,不作为任何形式的投资或商业决策依据。

source: 公开披露与公开资料整理 本页仅用于产业链学习、信息检索和研究辅助;不构成投资建议,不预测涨跌,不提供买卖、仓位或目标价建议。
完整概念页 复盘 13 节结构 公司投研页 沿产业链找到受益公司 投资课 把概念转成可跟踪模型