AI 时代的技术竞争正在进入一个让很多团队不适应的阶段模型本身越来越强模型之间的能力差距越来越小真正决定 SaaS 产品生死的反而变成了过去不被重视的定价模式。这个判断不是危言耸听。过去十年SaaS 行业的增长逻辑建立在一种非常舒服的成本结构上——软件复制分发几乎没有边际成本按账号、按年订阅的商业模式能够稳定覆盖研发投入。大模型进入产品之后这个结构被打破了每一次请求、每一段上下文、每一次多轮对话背后都有真实的 token 消耗和算力账单。“真正危险的不是模型而是定价模式”这句话的核心含义是如果 SaaS 还在沿用旧的价格体系和成本模型那么 AI 带来的不是利润而是持续失血的成本。这篇文章从成本结构、定价模型、计费工程和架构改造四个角度拆解这个判断在技术上为什么成立以及团队应该怎么应对。1. 为什么说定价模式才是 AI 时代 SaaS 洗牌的胜负手1.1 从“按账号年费”到“按 token 计费”的底层变化传统 SaaS 的商业模式是“卖座位”。一个企业客户买 50 个账号每个账号每年 2000 元不管这个账号实际用了多少功能价格都是固定的。对软件厂商来说这种模式最大的好处是收入可预测最大的隐藏福利是边际成本趋近于零多服务一个用户服务器和带宽成本可以忽略不计。AI 原生 SaaS 或者接入了大模型的 SaaS 完全不是这个逻辑。用户每次发起问答、每次生成摘要、每次让 Agent 执行一个任务都会产生模型调用费用。这个费用由输入 token、输出 token、缓存命中、模型档位等多个因子决定。换句话说SaaS 提供方第一次面对“用户用得越多成本越高”的局面。这带来一个根本性的转变过去定价模式要解决的问题是“客户愿不愿意为软件付钱”现在还要额外回答“客户的使用行为会不会让厂商亏钱”。如果团队还在用“按账号包年”的方式卖 AI 能力而客户大量使用高成本模型那么每多签一个客户亏损反而越大。这就是定价模式成为洗牌胜负手的第一层原因。1.2 模型能力趋同后差异化只能来自商业模式和工程体系2023 年到 2025 年之间各家大模型厂商的基础能力差距在快速缩小。同一个任务多家模型都能完成只是速度、价格、上下文长度和稳定性有差异。这带来一个残酷的结果模型本身很难成为 SaaS 的长期护城河。真正拉开差距的是三件事第一有没有把模型能力封装成客户能理解、能验证的功能场景第二有没有把模型调用成本控制在一个可持续的毛利区间第三有没有一套计费和经营体系能对每个客户、每个功能算清楚成本和收入。也就是说模型解决的是“能不能做”定价和工程体系解决的是“能不能长期做”。当所有竞争对手都能调用同样强的模型时谁的成本结构更健康、谁的定价模式更容易被客户接受谁就能在洗牌期活下来。这也是为什么很多技术团队开始把“成本工程”和“计费系统”当作核心模块而不是后台附属。1.3 IaaS、PaaS、SaaS、DaaS 的边界正在被 AI 重新模糊讨论 AI 时代的 SaaS 定价需要先厘清服务层次。IaaS 提供计算、存储、网络等基础设施PaaS 提供应用运行平台和开发能力SaaS 直接提供面向业务用户的软件服务DaaS 则把数据作为一种可订阅、可调用的服务交付给客户。四者边界本来清晰但 AI 出现后边界开始模糊。如今模型能力既可以作为 IaaS 层的算力资源出租也可以作为 PaaS 层的 API 能力被二次开发还可以直接封装成 SaaS 功能交付给最终用户。同一个模型提供商在不同客户眼里可能属于不同层次于是出现了事实上的 MaaSModel as a Service模式。这种边界模糊带来的直接问题是定价参考系混乱。客户不知道该按算力付费、按 API 调用付费还是按软件功能订阅付费厂商也容易选错计价单位。理解 IaaS、PaaS、SaaS、DaaS 的区别才能判断自己产品当前的护城河到底在哪个层次以及应该向客户出售“能力”“工具”还是“结果”。服务层次核心交付物典型计价方式AI 时代的新变化IaaS计算、存储、网络资源按实例时长、存储量、流量GPU 实例成为稀缺资源算力按卡时计费PaaS开发平台、运行时、API按资源规格、调用量大模型 API 成为新型 PaaS 能力按 token 计费SaaS面向业务的完整软件功能按账号订阅、按功能模块AI 功能常改为按用量、按结果计费DaaS数据产品与服务按数据量、查询次数、订阅向量数据库、知识库检索催生新的数据服务2. AI 改写 SaaS 成本结构算力账单成为第二张损益表2.1 传统 SaaS 边际成本趋近于零AI SaaS 每次调用都有成本传统 SaaS 的损益表上最大的成本项是研发人力和服务器固定成本这些成本与用户数量是弱相关的。业务量增长一倍增加的成本主要是带宽和存储比例很小。所以“低价获客、规模摊薄”的策略行得通。AI SaaS 的损益表上多了一张算力账单。这张账单与用户量、使用频次、提示词长度、模型档位强相关。一个活跃用户一天调用 50 次模型接口与一个低活跃用户一个月调用 10 次成本差距可能达到几十倍。如果产品没有对用户的消耗行为做区分收入端却是一个统一的订阅价那么高消耗用户实际上在持续侵蚀毛利。生产环境必须把算力成本当作第一等公民来治理。团队至少要建立三个基础能力能实时计量每次调用的成本、能把成本归属到具体客户和功能、能在成本异常时自动限流。缺少任何一个算力账单都会变成一颗定时炸弹。2.2 token、请求、会话AI 计费的最小成本单元AI 计费的最小单元是 token。模型厂商通常按“输入 token 单价”和“输出 token 单价”分别计费有些还区分缓存命中价格和未命中价格。输出 token 一般比输入 token 贵因为生成过程占用更多算力。产品层面的计费单元可能与模型层不同。有的产品按“每次问答”向客户收费有的按“每个会话”收费有的按“每个 Agent 任务”收费。这就要求工程系统做一个换算把一个业务动作映射成若干个模型请求再把每个模型请求映射成 token 消耗和费用。更复杂的是多步骤场景。一个 AI Agent 可能在一个任务中调用多次模型还可能调用外部工具、检索向量数据库。此时不能只统计最后一次调用的 token而要把整个工作流的成本都计入一次业务计费单元。否则就会出现“客户只付了一次任务的钱厂商实际承担了五次模型调用成本”的倒挂。2.3 用一个最小测算模型判断产品定价是否安全在给 AI 功能定价之前先做一个成本测算。这里用一个最简化的 Python 示例说明计算方法真实项目需要把 prompt 模板、缓存命中率、模型档位都纳入参数。def estimate_monthly_cost(active_users, queries_per_user_per_day, input_tokens, output_tokens, price_per_million_input, price_per_million_output, cache_hit_rate0.0): days 30 total_calls active_users * queries_per_user_per_day * days cached_input input_tokens * cache_hit_rate uncached_input input_tokens * (1 - cache_hit_rate) # 缓存输入的单价通常更低这里用折扣系数简化 cache_discount 0.5 input_cost ( uncached_input * price_per_million_input cached_input * price_per_million_input * cache_discount ) * total_calls / 1_000_000 output_cost output_tokens * price_per_million_output * total_calls / 1_000_000 return input_cost output_cost, total_calls # 示例参数1000 个活跃用户每人每天 10 次查询每次 2000 输入 token、500 输出 token cost, calls estimate_monthly_cost( active_users1000, queries_per_user_per_day10, input_tokens2000, output_tokens500, price_per_million_input2, price_per_million_output8, cache_hit_rate0.3 ) print(f月度调用次数: {calls:,}) print(f月度模型成本约: {cost:,.2f} 元)这个脚本的价值不是给出一个精确数字而是把定价讨论从“感觉差不多”变成“有据可算”。假设上面测算出来月成本是 3 万元而 1000 个用户按订阅制每月只贡献 2 万元收入那这个定价就是亏钱的。要么提高单价要么降低每次调用的 token 消耗要么引入用量封顶。注意这里的单价只是示例不同模型、不同区域、不同时段的价格差异很大。落地前一定要拿到真实合约价并把缓存命中率、失败重试、流式输出等细节计入成本模型。3. 订阅制、用量制、结果制三种定价模式的演进路径3.1 订阅制适合稳定用量但容易与 AI 成本错位订阅制是传统 SaaS 最成熟的模式优点是现金流稳定、客户决策简单、内部计量系统复杂度低。缺点是它天然假设“所有用户消耗的资源差不多”而这个假设在 AI SaaS 里通常不成立。如果团队坚持订阅制至少要给不同套餐设置不同的用量配额。例如基础版每个月 1000 次 AI 调用专业版每个月 10000 次 AI 调用超过配额后自动降级到基础模型或者按超量部分单独计费。这种做法本质上是把订阅制和用量制组合起来避免少数重度用户拖垮毛利。3.2 用量制把成本显性化但要先解决计量和封顶问题用量制按 token、按请求数、按处理数据量收费。它的好处是收入与成本天然对齐客户用得越多付得越多厂商不用担心被高消耗用户“薅羊毛”。AI 基础设施厂商普遍采用这种模式SaaS 产品也在逐步跟进。用量制的工程门槛比订阅制高很多。团队必须能准确计量每一笔用量能实时或准实时地聚合账单还要给客户提供用量看板和预算告警。更重要的是必须支持额度上限和熔断机制否则客户忘关某个自动化任务一夜之间可能产生天价账单最终导致客户流失。3.3 结果制商业上最性感工程上最难落地结果制是“按最终价值收费”例如按生成的合格线索数、按处理的工单数、按完成的交易额收费。对客户来说这是最合理的方式因为付费与业务价值直接挂钩。对厂商来说这也是毛利风险最大的方式因为“结果”的定义、判定、归因都很复杂而且造成结果的因素不完全是模型能力。结果制要求产品能够稳定地采集结果事件并且能把这个结果事件与某一次具体的 AI 处理过程关联起来。缺少这两个条件结果制就会变成频繁扯皮的来源。比较务实的做法是混合模式基础调用走订阅或用量关键业务成果走结果加成。3.4 三种模式的快速对比定价模式收入可预测性成本对齐程度工程复杂度客户接受度推荐场景订阅制高低低高用量稳定、成本可控的成熟功能用量制中高高中API 服务、AI 生成量大的场景结果制低最高极高高营销、客服、销售等强业务结果场景混合制中高中高中高高大多数 AI SaaS 的过渡方案4. 落地一套 AI 计费系统计量、聚合、限额缺一不可4.1 计量层先能数清楚每一次模型调用计费系统的第一层是计量。计量要解决的问题是每一次模型调用是谁发起的、用了哪个模型、消耗了多少 token、耗时多久、是否成功。没有准确的计量后续的计费、成本归因和限额都是一句空话。在常见项目里计量层通常做成中间件或网关插件在不侵入业务代码的前提下拦截模型请求。下面是一个基于 FastAPI 的简化示例思路是所有模型调用走同一个入口在入口处记录用量事件。import time from fastapi import Request async def usage_middleware(request: Request, call_next): start time.time() response await call_next(request) duration_ms (time.time() - start) * 1000 usage_event { path: request.url.path, user_id: request.headers.get(X-User-Id, anonymous), token_usage: response.headers.get(X-Token-Usage, 0), duration_ms: round(duration_ms, 2), status: response.status_code, ts: int(time.time()), } # 写入队列由异步任务批量落库避免阻塞主流程 enqueue_usage_event(usage_event) return response真实生产环境不建议直接写在中间件里做数据库写入而是把用量事件发到消息队列由消费者批量聚合写入时序数据库或 OLAP 表。计量本身不要阻塞模型响应否则会拖慢业务接口。4.2 聚合层用量数据如何变成账单计量层产生的是原始事件聚合层负责把这些事件变成可计费的用量。聚合维度通常包括客户、产品模块、模型、时间粒度。下面是一个按天聚合的 SQL 示例输出每位客户每天的 token 消耗。SELECT customer_id, date(usage_time) AS usage_day, model_name, sum(input_tokens) AS total_input_tokens, sum(output_tokens) AS total_output_tokens, sum(cached_tokens) AS total_cached_tokens, count(*) AS total_calls FROM model_usage_records WHERE usage_time date(now, -1 day) GROUP BY customer_id, date(usage_time), model_name;聚合完成之后再根据价目表把 token 数换算成金额。这里要注意价目表本身应该是配置化数据存到数据库或配置中心而不是硬编码在代码里。因为模型价格会调整促销折扣也会变化把价目表做成可配置项可以避免频繁发版。4.3 控制层预算、告警和熔断有了计量和聚合还要有控制层。控制层的目标是防止成本失控核心能力是三件事配额限制、预算告警、自动熔断。配额限制可以放在模型网关层对每个客户、每个套餐设置每分钟请求数上限和每日 token 上限。预算告警负责在客户消耗接近套餐额度时通知客户和运营团队。自动熔断则在超限时直接拒绝请求返回明确错误码让调用方感知到额度耗尽。注意熔断策略要温和。直接 429 报错会让客户业务中断更稳妥的做法是“降级到低档模型”例如从大参数模型降级到轻量模型同时提示客户当前套餐额度已用尽。4.4 token 计量的常见误差来源误差来源造成的影响处理建议输入 token 未计入系统提示词计费偏低计量时按最终发送给模型的完整消息计算缓存命中与未命中价格不同成本核算不准从模型响应中读取缓存命中标记并单独统计失败重试造成重复扣量客户计费虚高只在模型返回成功且产生有效输出时计费流式输出与普通输出计费差异统计口径不一致统一按完整响应的 token 数计算多轮对话重复携带历史消息输入 token 被低估在计量链路对最终请求体做一次 token 估算5. AI 时代 SaaS 的技术架构要围绕成本重新设计5.1 模型网关统一接入、路由和降级AI 时代 SaaS 的核心架构组件是模型网关。它负责统一接入多家模型厂商屏蔽底层 API 差异同时承担模型路由、限流、熔断和成本统计。没有模型网关业务代码会散落着对各种厂商 SDK 的直接调用后续换模型、做降级、做成本统计都非常困难。下面是一个简化版本的路由配置表达的是“默认走经济型模型预算或可用性不足时降级到备用模型”的思路。routes: - id: chat-completion primary: economy-chat-model fallback: - stable-chat-model - local-7b-model cost_budget_per_minute: 20 quota: max_tokens_per_day: 1000000 - id: embedding primary: small-embedding-model cache: semantic-cache batch: true这里要特别留意一个真实工程问题embedding 模型和 reranker 模型并不是在所有推理框架里都能直接启动。部分推理框架对生成式对话模型支持得很好但对向量嵌入和排序模型的支持不完整导致部署时启动失败。项目选型前要先用目标推理框架分别验证这三类模型能否正常加载再决定网关的路由策略。5.2 缓存、上下文裁剪和本地模型成本优化的三板斧成本控制的第二层是降低单次调用的 token 消耗和单价主要有三种手段。第一是缓存。对于相似度极高的用户问题可以直接命中语义缓存返回之前的结果完全不调用模型。对于系统提示词、固定知识库片段等重复输入可以利用模型厂商的 prompt 缓存服务降低输入 token 单价。第二是上下文裁剪。很多场景不需要把整个对话历史原样传给模型。可以引入滑动窗口式的上下文管理只保留最近几轮关键消息把更早的消息压缩成摘要。这种方法在长对话场景下能显著减少输入 token。第三是本地模型或小模型。不是所有请求都需要顶级模型。分类、抽取、改写等简单任务完全可以由本地部署的小参数模型完成只有复杂推理和生成任务才路由到云端大模型。模型蒸馏、量化部署也是为了在保持效果基本不变的前提下降低单次推理成本。5.3 成本归因让每个客户、每个功能都能算账成本归因是 AI SaaS 独有的工程要求。传统 SaaS 只需要统计服务器资源占用维度很粗AI SaaS 必须能把每一分钱算到“哪个客户、哪个功能、哪个模型、哪次调用”上。落地成本归因的关键是给用量事件打标签。模型网关在转发请求时要从业务请求头中提取并透传 customer_id、feature_id、session_id 等维度。如果业务方不传这些标签成本就只能被归到“公共池”根本分不清是哪个客户在使用、哪个功能在烧钱。有了准确的成本归因产品团队就能回答三个关键问题这个功能毛利是正还是负、这个客户是不是高消耗顾客、这个模型档位是否值得继续支付溢价。这些数据也是动态调整定价策略的依据。5.4 学习环境与生产环境的成本控制差异环境目标成本策略典型做法学习环境快速跑通功能可以接受手动配置使用免费额度、小模型、本地推理开发环境验证接口和流程设置硬性额度关联个人预算超限自动阻断测试环境回归和压测严格控制并行度使用 mock 或本地模型避免真实验证高并发生产环境保障业务和毛利全链路计量与限流模型网关、预算告警、自动降级、成本日报6. 传统 SaaS 向 AI SaaS 迁移的四个典型坑6.1 坑一用旧订阅价卖新 AI 能力毛利被算力吃光很多团队的路径是先在原有订阅套餐里附赠“AI 助理”功能不额外收费。用户快速增长模型账单也快速增长月底一算毛利被吃光。这个问题的根源是把模型成本当成了普通服务器成本忽略了它与使用强度的强相关性。修正方式是把 AI 功能从基础套餐中拆出来设立独立档位并明确用量配额。哪怕暂时不涨价也要先让客户明白AI 功能不是无限量赠送的。6.2 坑二把模型成本当后台成本没有产品化有些团队把模型费用统一记在“研发成本”里不区分具体产品和客户。这种做法导致产品经理看不到自己负责的功能到底消耗了多少成本也就无法做出“这里应该降级、那里值得用贵模型”的判断。正确的做法是把成本数据产品化给每个产品功能建立成本看板给每个客户建立毛利报表让业务决策建立在真实数据上。成本产品化之后团队才能理性讨论哪些功能应该收钱、哪些客户应该引导降级、哪些模型应该被替换。6.3 坑三用量计费没有上限和告警客户账单爆炸一旦采用用量制必须配备额度管理。真实案例里经常出现客户部署了一个自动化任务循环调用模型接口一晚上消耗了相当于几个月订阅费的 token。客户看到账单的第一反应不是“我用超了”而是“这个系统在坑我钱”。所以用量制上线前必须完成预算告警、额度上限和超限熔断。客户侧还要提供用量看板让客户能在自己后台看到实时消耗。这不只是技术问题也是客户信任问题。6.4 坑四只验证功能可用没有验证成本可用开发阶段验证 AI 功能时往往用几十个 token 的短请求跑通了就算成功。但真实生产场景中用户的提示词可能很长系统提示词不断膨胀RAG 检索来的上下文越来越多一次请求可能消耗几万 token。功能没问题成本却失控了。验证清单里必须增加成本验证项模拟真实长度的输入、统计单次请求的平均 token 消耗、观察缓存命中率、压测高并发时的成本曲线。只有功能和成本都通过验证这个功能才具备上线条件。6.5 排查链路从“客户说太贵”倒推问题问题现象可能原因检查方式处理建议客户反馈账单远超预期自动化任务死循环调用查询用量事件中同一客户的高频调用记录定位异常任务限制单任务并发增加告警单次请求成本异常高系统提示词膨胀或上下文过长抽样查看模型请求日志中的 token 组成裁剪上下文启用 prompt 缓存压缩系统提示词某功能毛利持续为负功能使用了高档模型但定价过低查看成本归因报表中该功能的毛利更换低档模型或调整该功能的价格客户用量突增但收入不变订阅制未设置用量配额对比各客户月度用量分布引入套餐配额和超量计费模型切换后成本上升新模型提示词处理方式不同对比新旧模型的 token 统计按真实业务样本重新测算成本7. 定价与工程落地检查清单7.1 定价模式设计清单明确每个 AI 功能对应的模型调用链梳理单次完整任务的平均 token 消耗。用真实业务样本测算单位客户月成本不要用理想短请求估算。为不同套餐设置明确的用量配额配额要和成本测算对齐。确定超量处理策略降级到低档模型、限流还是按量收费。将价目表做成配置化数据支持促销、折扣和模型价格调整。上线前用目标客户群做价格访谈重点验证客户对“用量计费”的理解程度。7.2 工程落地检查清单模型网关已经接入并承载所有模型调用业务代码不直接依赖厂商 SDK。每次调用都能记录 customer_id、feature_id、model_name、token 明细。计量事件通过异步队列落库不阻塞业务主流程。聚合任务能按天产出客户维度和功能维度的成本报表。配额、预算告警、自动熔断已经在生产环境验证过。缓存命中率、上下文裁剪效果、本地模型降级路径都已压测。学习、开发、测试、生产四类环境有不同的额度策略。上线评审包含“成本可用性验证”不能只看功能效果。7.3 对技术负责人和创业者的建议AI 时代的 SaaS 大洗牌本质上是经营模式的竞争。模型是会被替换的能力是会趋同的但一套能准确计量、合理定价、动态降级、持续控制成本的经营体系会随着时间积累变成真正的壁垒。建议团队从第一天就把定价模式和成本工程当作产品的一部分设计而不是等模型账单吓到管理层之后再补课。对刚起步的团队可以先从混合定价开始基础订阅保证现金流用量计费覆盖超额消耗把结果制留到业务价值可以被稳定度量之后再引入。对已经做 SaaS 多年的团队建议先做一个全功能成本审计把每个 AI 功能的毛利拉出来看一遍再决定哪些功能要涨价、哪些模型要降级、哪些客户要重新谈判。技术问题可以逐步解决定价模式的错误会在每个月底的成本报表里提前兑现。