大型语言模型（LLM）产品可能承担显著的可变成本，并依赖第三方平台。这些因素是否会削弱业务，取决于实际使用分布、定价、支持负载、用户留存率和客户价值。
本文说明如何构建可审计的单位经济模型，并测试可能形成竞争壁垒的因素。本文不报告行业调查，也不预测哪些公司能够存续。
FinOps Foundation 将 单位经济 定义为将技术成本与业务价值指标联系起来。将其作为可比的运营框架，然后由财务部门定义该产品的实际单位、成本分配和利润处理方式。
LLM 产品有何不同
LLM 驱动产品与传统 SaaS 有几个不同之处：
使用可能会产生显著的边际成本。 模型调用、工具使用、检索、存储、审查和支持成本可能随着使用量的增加而上升。第一次调用和第一万次调用的边际成本不一定相同，因为缓存、批量处理、折扣、路由和容量利用率会改变这一成本；应从追踪记录和发票中计算出分布情况。
利润率取决于完整的服务成本分布。 不要引用没有来源依据的行业区间。应与财务审核人员一起定义毛利率和贡献毛利率，然后从公司的账簿和使用记录中计算出这两个指标。
基础模型的访问权限可能是共享的。 单独的公共模型可能容易被竞争对手获取，但实施质量、合同、数据权利、分发、运营和客户信任仍可能存在差异。
基础模型会变化。 版本、弃用、价格、配额和条款可能按照供应商的时间表进行调整。请记录每个依赖项、通知路径、回退方案、迁移测试和商业触发条件。
功能可能被复制。 测试实现质量、已获授权的数据、分发方式、合同、集成、运营或信任是否创造了可观的客户价值；不要假设某个提示、调优或工作流程是独特或易于复现的。
客户期望和供应商功能会变化。 按照既定的时间表重新测试客户支付意愿和竞争替代方案。
竞争重叠。 模型、云服务、SaaS 和专业供应商可能会增加相邻功能。请维护一份更新的竞争对手地图，并测试客户替代方案，而不是根据公司规模或合作伙伴关系推断压力。
应把这些因素视为需要纳入商业模型的风险，而不是适用于所有大语言模型产品的既定事实。
成本结构
从账簿和追踪信息构建产品的成本结构。首先从成本池开始，然后由财务部门根据活动基础、合同、容量承诺和决策时间范围对成本行为进行分类；同一成本在某一决策中可能是固定的，在另一决策中可能是可变或阶梯固定的。
潜在的计费或用量敏感型资源池：
- 推理（LLM API 或托管）。
- 嵌入（用于 RAG）。
- 向量数据库或存储。
- 其他随使用量扩展的基础设施。
潜在的周期性、承诺容量或阶梯固定型资源池：
- 薪资和支持人员配置，取决于招聘和服务用量决策。
- 办公室和运营承诺。
- 软件许可，可能为固定费用、按座位数、分级或基于使用量。
- 托管服务的基础成本或预留容量，包括阶梯式变化。
- 市场营销和销售，区分承诺支出与佣金或活动驱动成本。
按账户计算贡献值，公式为：确认收入减去商定的可变成本和可归属成本。应包括模型/工具使用、检索和存储、人工审核、支付费用、支持、退款或账户抵扣，以及财务分类为可变或可归属的任何其他成本。
应建模分布情况，而非假设一个平均值。至少应按账户和用量百分位计算服务成本，然后对当前供应商的价格、重试、更长上下文、模型回退、支持工单和滥用情况进行压力测试。在每次决策周期前，重新检查供应商官方页面上的价格信息。
定价模式
定价需明确处理用量敏感成本、客户价值和计费操作。候选模型包括：
按用户计费。 定价可预测，但使用量的波动可能导致交叉补贴或亏损用户群体。
按席位收费并设置用量上限。 每个席位每月包含 N 次操作、调用或 token。用量较高的用户支付超额费用或达到上限。
纯用量计费。 按调用次数、令牌数、操作次数或其他单位计费。这可能使收入与某一成本驱动因素对齐，但无法保证利润的可预测性；支持、重试、折扣、最低承诺和价值可能因客户账户而异。
分级计费。 套餐可以区分能力、服务、限制或支持。验证分级是否易于理解、合同上可行且经济上具有区分度。
混合计费。 每用户基准加上用量额度或超额费用。这可能在可预测性和成本对齐之间取得平衡，但只有用户群体经济性和客户调研才能确认这一点。
结果导向计费。 按定义的结果付费。这可以将价格与价值挂钩，但会引发归因、质量、争议、欺诈、时机和会计问题；本文没有市场数据集证明其采用趋势。
每种模式都有取舍。“正确”的模式取决于：
- 你与客户对可预测性的需求。
- 使用量的差异程度。
- 利润率结构。
- 竞争格局。
在没有市场证据的情况下，不要断言某种定价模式是主导的最优方案。通过客户调研、法律审查、计费可行性分析和用户群体经济性分析来测试候选定价方案。
单位经济问题
一个实用的思考框架是：你按什么单位收费，这个单位的成本是多少？
对于聊天助手，候选单位可能包括一次对话、已解决的任务、席位或使用配额。请衡量与该单位相关的模型/工具成本、人工审核和支持成本、失败/重试成本以及由此产生的收入。
该练习包括：测算每单位成本、测试收入和套餐方案，以及在使用分布范围内评估经财务批准的利润率目标。
高使用量账户可能成本更高，但也可能带来更高的留存、扩展或创造更多价值。在更改限制之前，按用户群体分析其贡献和留存情况。
保护利润率
以下策略可以保护利润率：
1. 按功能划分模型档位
基础版提供运行成本低的功能。昂贵功能（推理模型、长上下文、大量输出）放到高级版。
按功能和路径衡量成本。如果某项高级功能的服务成本或客户价值显著更高，请测试是否可以设置独立的配额或层级，并且该方案是否易于理解且具有商业可行性。
2. 成本优化（参见成本优化推理）
缓存、路由和输出控制是候选方案。请使用链接文章中基于追踪的方法；在未进行测量之前，不要预设节省百分比的预算。
3. 用量透明
向用户展示其用量，借此间接引导他们优化自己的使用行为。
使用可见性可以帮助客户理解限制和费用，但也可能造成混淆或抑制使用。应通过测试来评估用户的理解程度、可访问性、行为、支持负载和转化率，而不是假设用户会自行限制使用或升级。
4. 智能缓存
针对用户或组织的缓存机制在新鲜度、隐私、授权、失效验证和命中率测试支持的情况下，可以减少重复工作。请测量净成本和用户结果；切勿在不同作用域之间共享个性化缓存条目。
5. 托管/自托管混合
自托管或自带云（BYO-cloud）方案会改变基础设施的运营和付费方。它们还可能增加支持、安全、发布和兼容性成本；应对整份合同进行建模。
6. 高价值场景按成果收费
某些工作流程具有可衡量的结果。结果定价会改变归因、争议、欺诈、时间安排和收入确认等问题；因此，合格的财务和法律审查是必不可少的。
护城河问题
更难的问题是：什么能让你的产品具备可防御性？
需针对客户行为进行验证的假设列表：
可能的防御性来源
依法掌控的数据。 经批准的数据权利、数据质量和反馈可能有助于改进产品。测试这些因素是否会影响结果或用户切换行为；切勿通过限制客户或隐藏导出/删除权利来束缚客户。
获客渠道。 已有的目标细分市场触达能力可能降低获客阻力。应测量转化率和留存率，而非假设覆盖面能创造防御性优势。
信任。 测量安全证据、行业领域审查、可靠性、支持服务和负责任的事件处理是否影响获取、续约或扩展。受监管行业的标签并不能建立信任。
集成。 集成可能会减少用户摩擦并创造运营价值。在不设计不公平锁定机制的前提下进行测量，并保留导出和卸载功能。
工作流专业化。 领域特定的实现可能优于通用替代方案，但只有任务结果、采用情况、评审证据和切换研究才能证明其优势。
网络效应。 明确其他参与者如何通过某种机制增加价值，获取必要的数据权利，并测量该效应。社区或共享数据集并不自动构成网络效应。
品牌与切换证据。 使用赢单/丢单分析、续约行为、迁移工作量、客户控制的导出和信任度测量。不要臆测采购决策者的职业前途，也不应将客户难以离开视为目标。
垂直整合。 拥有模型、推理或数据管道可能会提高控制力或经济效益，但也可能增加资本和运营负担。请衡量所声称的优势。
伪护城河
特定的提示或工作流程。 应将可复制性和客户构建能力视为研究问题，而非假设。
特定的公开模型选择。 单独的访问权限很少具有排他性，尽管合同、地区、调优、服务和运营仍可能存在差异。
巧妙的用户界面。 用户界面本身并不能证明防御性；虚构的复制时间线也是如此。
迭代速度。 它可能创造暂时的优势，但持久性需要来自客户价值、留存率、运营或其他强化机制的证据。
仅靠营销或品牌。 品牌可能重要，但其防御性必须通过获取、留存、信任或定价的证据来证明。
较弱的假设更容易被复制或可能迅速失效。在没有引用数据集的情况下，不要将其与死亡率联系起来。
战略模式
可能提升可防御性的模式：
模式1：工作流 + AI，而不是“AI工具”
不要构建“做X的AI”，而要构建一个将AI纳入更大系统的工作流。
例如：不是“用于法律合同的AI摘要工具”，而是“内置AI的合同管理平台”。
测试周围的工作流程是否能提升激活率、留存率、付费意愿或转换行为。更大的功能集并不自动形成护城河。
模式2：客户数据飞轮
每位客户的使用都会产生数据，改善其体验（也可能改善其他人的体验）。切换意味着失去累积的个性化。
示例假设：使用已批准的账户上下文和确认的偏好的人工智能销售助手，可能减少重复设置。测试其可移植性、客户控制能力以及该优势是否持续。
仅在拥有明确权利、客户控制、隔离、纠正、删除以及可衡量的改进循环的情况下进行构建。在缺乏这些控制措施的情况下积累数据是一种负债，而非飞轮效应。
模式3：深耕垂直领域
选择一个垂直领域并深入构建，如医疗、法律、金融、房地产。
垂直领域的知识可能提升工作流程的契合度。但它也会提高领域审查、责任、数据和合规要求。需将优势与通用型和专业型竞争对手进行对比衡量。
模式4：嵌入现有工作流
将功能嵌入到用户已经使用的已批准系统中，是减少上下文切换的一种候选方案；但这并不总是比采用独立的产品边界更优。
嵌入可以减少工作流程中的摩擦，并增加集成依赖性。应测量使用率和留存率，并确保公平的数据导出和退出流程。
模式5：AI 原生运营
有些企业从头到尾都采用 AI 原生运营。它们不是向客户销售 AI 本身，而是使用 AI 提供服务，例如 AI 辅导、按成果交付的 AI 客服服务，或商品化的 AI 内容。
产品可能是服务成果，而人工智能则作为运营组件存在。应将质量、成本、可靠性和客户偏好与替代交付模式进行比较。
模式 6：多个相互强化的假设
多个优势可能相互强化。应通过证据建立每一条联系，而不是提前将组合标记为成功。
用证据记录代替虚构的案例研究
不要编造匿名的初创公司或财务结果。对于每次定价实验，应保留包含以下内容的决策记录：
- 假设和客户群体，
- 价格、用量配额、超量费用、取消和退款条款，
- 样本量和实验日期，
- 激活率、使用分布、转化率、留存率、扩展率、支持情况和流失率，
- 经财务部门批准的服务成本分布和贡献定义，
- 定性客户调研和已知的选择偏差，
- 法律、税务、计费和消费者保护审查，
- 决策、置信度、负责人和下次审查日期。
为评估可防御性，应记录续约行为、价值实现时间、集成深度、已批准的数据权利、切换访谈、销售周期影响以及相对竞争对手赢单/丢单的原因等证据。一个看似合理的解释并不能证明护城河的存在。
哪些地方会出问题
用于测试的示例性风险场景：
失败1：利润率压缩。 利润率一开始表现良好，随后受到竞争与价格压力挤压。现在收入增长了，利润却没有增长。
失败案例2：供应商替代。 基础模型或平台提供商推出足够具有竞争力的功能，导致可衡量的差异化下降。
失败案例3：高使用量群体的经济性。 某些账户不成比例地推高了成本。在决定是否以及如何调整条款之前，应测试定价、限制、工作流程设计、模型路由、支持和价值。
失败4：质量退化。 基础模型更新改变了行为，调优过的提示失效，客户信任下降，恢复缓慢。
失败 5：客户替代。 一个成本更低的平台或竞争对手足以满足工作流程，导致用户留存率下降。
失败 6：未管理的替代风险。 平台或竞争对手提供了足以替代本产品的方案，但团队没有注明日期的竞争对手评估、客户证据或迁移计划。
失败7：扩张时没有利润纪律。 用增长资金换增长，忽视利润率。最终资金耗尽，也没有盈利路径。
失败8：基础依赖风险。 提供商提高API价格、弃用服务或发生停机。你的业务被无法控制的因素打断。
需要验证的定价假设
按操作计费并设上限。 测试该操作是否明确、可审计、有价值、不易被滥用，并且与成本和客户预期一致。
客户自备 API 密钥。 这可以将服务提供商的费用转移至客户，但不会消除支持、安全、集成、故障或会计方面的责任。请核实提供商条款和租户隔离措施。
协商定价。 测试预期的使用量、服务、支持、风险分配和折扣是否在不利使用情况下仍能产生经批准的贡献毛利。
免费试用或层级。 测量激活率、转化率、滥用情况、支持需求、基础设施成本、留存率和内部替代（蚕食效应）。免费使用并不保证会转化为付费使用。
合同期限。 与财务和法律审核人员一起建模计费方式、收入确认、折扣、最低使用量、服务义务、取消政策、收款流程、续约以及预测误差。
定价决策框架
步骤：
-
建模你的成本分布。 为每个账户和有意义的使用百分位（包括失败和支持）提供服务的成本是多少？
-
选择计费单位。 你对什么收费？席位、操作、成果还是 token？
-
测试价格方案。 按照客户细分，测量客户支付意愿、转化率、留存率、价值证据、成本和竞争替代方案。
-
测试产品包装。 仅使用客户能够理解且系统可以执行并准确计费的层级和限制。
-
设置限制。 重度用户的用量达到什么程度后会开始侵蚀利润率？执行上限或收取超额费用。
-
规划变更。 基础模型的价格和功能可能会上升、下降或发生变化。定义供应商变更如何触发价格和产品审查。
-
按既定节奏进行衡量。 在将客户终身价值、贡献毛利、流失率和扩张率用于决策之前，应由财务部门明确定义这些指标。
如何研究市场主张
避免使用诸如“只做模型薄封装的产品会失败”、“垂直产品繁荣”或“平台主导”等宽泛陈述，除非有明确的数据集定义了所涉及的人群、时间段和结果。产品的证据应基于以下内容：
- 带有日期的当前竞争对手能力及价格信息，
- 客户的得失访谈记录，
- 各用户群体的留存率和扩张率，
- 供应商的产品路线图及弃用监控，
- 客户调研中观察到的切换和集成成本，
- 引用的行业数据集，其方法论适用于该主张。
在每次评审中，将战略假设与实测市场发现区分开来。
应该优化什么
对于创始人，优先级如下：
-
构建真正完成工作的产品。 不是“用于 X 的 AI”，而是客户重视的可衡量成果。
-
有意识地测试防御性假设。 客户价值、合法数据优势、垂直深度、分销渠道、集成能力以及工作流程嵌入性都需要证据支持。
-
验证单位经济模型。 在实际用户群体和预测范围内对已批准的利润率定义和价格方案进行压力测试。
-
管理基础依赖关系。 多样化和可移植性会带来成本；从影响和经过验证的可行性角度选择回退和迁移控制方案。
-
积累支持规模化运营的证据。 可观测性、评估、安全性、质量、事件处理和恢复机制使可靠性及成本主张可审计。
-
建立持久的关系。 信任、可靠的集成、价值和负责任的客户退出流程至关重要。不要将客户锁定视为目标。
上游供应商格局变化迅速，因此需明确审查日期和退出计划。
构建时就考虑护城河
推出大型语言模型（LLM）产品需要明确的可变成本和依赖关系管理。其利润率或竞争态势究竟优于还是劣于其他 SaaS 类别，都必须通过可比数据加以验证。
可防御性的可能来源包括合法的数据优势、垂直深度、获客渠道、集成度、信任度和工作流程契合度。将每项视为可验证的假设。
经济分析需要严谨。应识别并归集可变成本和可避免成本，测试缓存、路由和产品包装变更对质量与政策的影响，并通过经过审查的产品和商业决策处理高成本用户群体，而不是套用通用的上限规则。
本工作表的输出是一个可审计的定价和可防御性决策，包含明确列出的假设、证据、负责人和审查日期。在生产使用或外部财务声明之前，合格的财务和法律审查人员必须批准定义和客户条款。
