AI 产品经理 LLM API 定价建议模板下载：包含 Token 定价模型
一句话总结
LLM API 的定价核心从来不是计算成本加成，而是对用户心理账户的精准切割与价值捕获。大多数产品负责人错误地认为定价是财务模型的后端输出，实际上它是产品战略的前端武器，直接决定了你的 API 是被当作 commodity（大宗商品）随意替换，还是被当作 strategic partner（战略伙伴）深度绑定。正确的判断是：不要试图覆盖所有成本，而是要设计一个让高用量客户感到“占便宜”、让低用量客户感到“安全”的结构，哪怕这意味着在初期牺牲部分毛利。那些在 debrief 会议上拿着精美 Excel 表格展示“盈亏平衡点”的 PM，往往第一个被否决；
而那些能讲清楚“为什么这个价格阶梯能锁住未来三年的企业预算”的 PM，才能拿到 offer。定价不是数学题，是博弈论，你的模板里如果只包含 token 成本核算，那它就是个废品。真正的模板必须包含竞争锚点、迁移成本计算以及客户 LTV（生命周期价值）的敏感性分析。如果你在面试中被问到如何给一个新的 LLM API 定价，回答“参考竞品打八折”的人直接出局，回答“重构客户的成本结构，让他们无法离开”的人才能进入下一轮。
适合谁看
这篇文章只写给那些正在负责 B2B 开发者工具、AI 基础设施或企业级 SaaS 的产品负责人，特别是那些即将面临定价策略审查或需要重构现有收费模型的人。如果你还在认为定价只是填个数字然后交给销售去谈，那么你不适合看这篇，因为你还没意识到自己正在把公司的命脉交给运气。适合看这篇文章的人，是那些在 hiring committee 讨论中被质疑“缺乏商业敏感度”，或者在跨部门会议中被 CFO 挑战“为什么我们的 ARPU（每用户平均收入）上不去”的资深 PM。这也适合那些准备面试硅谷顶级 AI 公司（如 Anthropic, Cohere, 或云厂商的 AI 部门）的候选人，因为这里的逻辑是面试官真正想听到的“判词”，而不是教科书上的废话。对于那些刚入行、连 token 是什么都搞不清楚的初级产品经理，这篇文章过于残酷且直接，建议先去补齐基础认知再来。
这里没有温情的鼓励，只有冷冰冰的决策逻辑：要么你学会用定价杠杆撬动增长，要么你就永远只能做个功能经理，等着别人告诉你该收多少钱。在硅谷，一个不懂定价策略的 AI PM，其薪资上限通常被锁死在 base $130K，总包不超过 $180K；而精通此道的 PM，base 起步就是 $180K，RSU 加上 bonus，总包轻松突破 $450K 甚至更高。这不是危言耸听，这是我们在做 leveling calibration 时的真实共识。
为什么传统的成本加成定价在 LLM 时代是死路一条
在传统的 SaaS 时代，我们习惯用成本加成法，算出服务器成本、人力摊销，然后加上 30% 的毛利作为售价。这套逻辑在 LLM API 定价上是致命的毒药。LLM 的边际成本结构极其特殊，推理成本随着并发量和上下文长度呈非线性波动，且硬件折旧速度极快。如果你基于今天的 GPU 成本定价，明天新一代芯片出来，你的价格就失去了竞争力，或者你的毛利被瞬间吞噬。我见过一个典型的失败案例：某初创公司在 debrief 会议上自豪地展示他们的定价模型，精细计算了每张 H100 的折旧和电费，得出结论每百万 token 成本是$2.5，所以售价定为$3.5。Hiring Manager 当场反问：“如果竞争对手用更高效的量化模型把成本降到$1.5，你是不是要跟着降到$2？你的护城河在哪里？”全场 silêncio。那个 PM 被淘汰了，不是因为他算得不对，而是因为他算错了对象。定价不是关于你的成本，而是关于客户的支付意愿和替代成本。不是“我能赚多少”，而是“客户愿意为了不迁移而多付多少”。在 LLM 领域，客户购买的不是 token，而是“确定性”和“集成深度”。如果你的模型能减少他们 20% 的幻觉率，或者能无缝嵌入他们现有的 RAG 架构，他们愿意支付溢价。
正确的做法是参考客户的业务价值。比如，一个法律科技公司的客户，使用你的 API 生成合同草稿，每生成一份合同能帮他们节省$500 的人力成本。那么，哪怕你的 token 成本只有$0.1，你也可以定价到$50，因为这是价值定价，不是成本定价。那些还在纠结 GPU 电费的 PM，本质上是在用工业时代的思维做信息时代的事。你需要构建的模板，第一页不应该是成本表，而应该是客户场景的价值映射图。你要问自己：如果我的服务明天停机，客户会损失多少钱？那个数字，才是你定价的天花板。很多 PM 在面试中被问到定价策略时，习惯性地去谈“薄利多销”，这在 API 业务中是大忌。API 业务的核心是粘性，一旦客户把你的接口写进核心代码库，迁移成本极高。这时候，低价不仅不能带来增长，反而会让客户怀疑你的可持续性和服务质量。高价配合高 SLA（服务等级协议），才是 B2B 的正确打法。记住，在硅谷的 AI 圈子里，没有人尊重“便宜”的 API，大家只尊重“稳定且昂贵”的基础设施。
> 📖 延伸阅读：PM核心技能在Amazon的应用实践：从PRD到发布
如何设计让大客户无法逃离的阶梯式 Token 定价结构
设计阶梯式定价不仅仅是为了量大从优，更是为了制造“锁定效应”和“预算消耗”。大多数错误的模板只是简单地把价格随用量递减，比如前 100 万 token 一个价，100 万到 1000 万一个价。这种设计太线性，太容易被预测和规避。真正的顶级定价策略，是利用阶梯制造“断崖”和“诱惑”。不是“用量越多单价越低”，而是“跨过这个阈值，你的单位经济模型会发生质变”。举个具体的 insider 场景：在一次关于企业级 API 定价的 cross-functional review 中，一位资深 PM 提出了一个反直觉的方案。她建议在第一阶梯设置一个相对较高的价格，甚至略高于市场均价，但在第二阶梯设置一个极具诱惑力的“跳板价”，这个价格低到让客户觉得“只要我再多用 20%，我的平均成本就能减半”。这迫使客户主动去优化他们的 Prompt，增加调用量，甚至把原本在其他模型上的流量切过来，只为了跨过那个阈值。这就叫“诱导性扩容”。一旦客户为了享受低价而增加了用量，他们的架构就会围绕你的高用量场景进行优化，迁移成本随之飙升。这就是心理学中的“沉没成本”与“损失厌恶”的组合拳。错误的定价是平滑的曲线，正确的定价是精心设计的陷阱。在你的模板中，必须包含对“阈值效应”的模拟计算。你要算出客户在哪个用量点会产生“不跨过去就亏了”的心理。
此外，阶梯定价还要考虑“承诺用量”（Committed Use）。对于年框合同，不要只给折扣，要给“资源预留权”。告诉大客户：“如果你承诺每年消耗 5000 万美元的 token，我不仅给你打折，我还保证在算力紧张时优先给你供货。”在 2023 年底的算力荒中，这一条比任何价格折扣都值钱。很多 PM 在谈判时只会说“我可以给你打七折”，这是低级销售的话术。高级 PM 会说“我可以给你锁定未来 18 个月的算力配额，价格随行就市，但你的优先级高于一切”。这才是大客户 CTO 想听的。在面试中，如果你能提出“动态阶梯 + 资源预留”的组合拳，面试官会立刻意识到你懂 B2B 的深层逻辑。不要只盯着 token 的数量，要盯着客户的预算周期。企业的预算通常是按年批复的，你的定价阶梯如果能帮助客户在 Q4 把当年的预算“花光”以获得明年的预算基数，那你就赢了。这不是作弊，这是顺应组织行为学。很多 PM 设计的模板里只有“单价”，没有“预算消耗策略”，这就是为什么他们只能做执行者，做不了决策者。你的模板必须包含一个模块，专门模拟不同阶梯对客户财务部门的影响，证明你的定价能帮助他们更合理地规划 IT 支出。
面试实战：如何在白板前推导出一套完整的定价模型
在硅谷的大厂面试中，尤其是 L6 及以上的产品负责人岗位，面试官一定会扔给你一个白板，说：“我们要发布一个新的多模态模型 API，请设计定价策略。”这时候，90% 的候选人会立刻开始画坐标轴，写公式，算成本。这是大错特错。前 5 分钟，你不应该写任何一个数字。你应该先问问题，界定边界。不是“怎么定价”，而是“我们要服务于谁，以及我们要达成什么战略目标”。我亲眼见过一个候选人在 hiring committee 的 debrief 中拿到 full strong hire，就是因为他前 10 分钟一直在挑战面试官的预设。他问：“这个模型是针对开发者实验用的，还是针对生产环境的？我们的目标是抢占市场份额，还是追求短期盈利？我们的竞品是开源模型还是闭源巨头？”当他把这些战略问题抛出来后，面试官的眼神变了。因为他展示了 PM 最核心的能力：在模糊中寻找方向。接下来，他并没有直接给出一个价格，而是构建了一个“定价框架”。他首先定义了三个客户分层：Hobbyist（业余开发者）、Startup（初创公司）、Enterprise（大型企业）。针对 Hobbyist，他建议采用 Free Tier + Pay As You Go，目的是最大化生态传播，这里不是要赚钱，而是要赚“注意力”和"GitHub Star"。针对 Startup，他设计了阶梯定价，重点在于降低早期的尝试门槛，同时设置自动升级机制。
针对 Enterprise，他完全抛弃了 Token 计价的单一模式，提出了"Base Fee + Usage"的混合模式，甚至引入了“按效果付费”的试点概念。在白板推导过程中，他特意提到了一个细节：如何处理突发流量带来的账单休克（Bill Shock）。他建议在模板中加入“预算预警”和“硬封顶”功能，这看似是功能设计，实则是定价策略的一部分，因为它消除了企业客户的采购顾虑。这个细节直接击中了 Enterprise 销售的痛点。相比之下，另一个候选人虽然算出了精确到小数点后三位的成本结构，但因为忽略了客户心理和采购流程，被判定为“缺乏商业直觉”。在面试中，具体的数字不重要，重要的是你推导数字的逻辑链条。你必须展示出你对“价格弹性”的理解。你可以说：“如果我们将价格提高 10%，预计会流失 5% 的价格敏感型用户，但剩下的 95% 用户贡献的毛利会增加，因为他们的需求是刚性的。”这种基于假设的推演，比拍脑袋定个$0.002/1k tokens 要有说服力得多。你的准备清单里，必须包含这种“白板推演”的刻意练习。不要只背答案，要练逻辑。在硅谷，PM 的薪资差距往往就体现在这种结构化思维上。一个能清晰拆解定价逻辑的 L6 PM，base 可以给到$210K，RSU 每年$150K，bonus 20%；而一个只会执行定价表的 L5 PM，总包可能连$300K 都勉强。这不是学历的差距，是思维维度的差距。
> 📖 延伸阅读：2026年应届生SWE面试Amazon SDE1行为问题应对策略
准备清单
- 重构你的定价思维模型：彻底抛弃“成本 + 利润”的线性思维，转而建立“客户价值 + 迁移成本 + 竞争锚点”的三维定价框架。在下次产品评审前，强制自己用这三个维度重新审视当前的定价表，找出至少一个可以被优化的杠杆点。
- 收集并拆解竞品定价页的隐藏逻辑：不要只看表面的价格数字，去注册竞品账号，模拟不同用量的场景，看他们的账单是如何生成的。特别注意他们的“隐藏费用”（如并发限制、上下文窗口额外收费、数据保留费用），这些往往是利润的真正来源。
- 系统性拆解面试结构（PM 面试手册里有完整的 AI 商业化实战复盘可以参考）：重点练习如何在 45 分钟内从战略定位推导到具体价格数字，确保每一个数字背后都有明确的假设支撑，而不是凭空捏造。
- 建立内部利益相关者地图：定价不仅仅是 PM 的事，提前与销售 VP、CFO、法律顾问进行非正式沟通，了解他们在定价上的红线和诉求。销售想要好卖的低价，财务想要高毛利，法律想要合规，你的方案必须是这三者的最大公约数。
- 设计“账单休克”防御机制：在你的产品文档中，明确写出当客户用量异常激增时的处理流程。是自动切断？还是发送警告？或者是临时提额？这不仅是产品功能，更是定价策略的信任基石。
- 准备三套不同战略目标的定价预案：一套用于“市场掠夺”（低价高频），一套用于“利润最大化”（高价精选），一套用于“生态锁定”（混合模式）。在面试或汇报时，根据对方的战略意图灵活切换，展示你的战略弹性。
- 量化“不定价”的成本：计算如果维持现状或定价错误，公司在未来 12 个月会损失多少潜在收入或市场份额。用具体的 Dollar Amount 来支撑你的变革提案，而不是用模糊的“用户体验更好”。
常见错误
错误案例一：陷入“精确成本核算”的陷阱
BAD 版本：PM 在会议上花费 20 分钟展示 Excel 表格，详细列出 GPU 租赁费、带宽成本、运维人力，最后得出“每百万 token 成本$1.8，建议售价$2.5"的结论。当被问及“如果竞争对手售价$1.5 怎么办”时，哑口无言，只能建议削减功能。
GOOD 版本：PM 直接跳过成本表，指出“我们的模型在医疗垂直领域的准确率比竞品高 15%，这意味着客户可以减少 30% 的人工复核成本。因此，我们的定价策略应锚定在‘节省的人力成本’上，建议起步价设为$5.0，并配套提供 SLA 保障。即使竞品低价，他们也无法提供同等的合规性和准确性，客户不会为了省几块钱而冒医疗事故的风险。”
解析：前者是会计思维，后者是产品战略思维。定价是价值的货币化表现，不是成本的转嫁。
错误案例二：设计“平滑无感”的阶梯价格
BAD 版本：定价表显示，0-100 万 token 单价$X，100 万 -200 万单价$0.9X，200 万 -300 万单价$0.85X。价格曲线平滑下降，客户感觉不到任何激励，也没有动力去冲刺更高的用量层级。
GOOD 版本：设计“断崖式”激励。0-100 万单价$X，一旦超过 100 万，超出部分单价直接降至$0.6X，并且回溯适用（或提供大额返点）。同时在界面上显眼地展示“再使用 5 万 token，您的平均成本将降低 20%"。
解析：平滑的降价是理所当然的，没有驱动力。只有制造“不跨过去就亏了”的心理落差，才能驱动客户主动扩容，从而增加粘性。
错误案例三：忽视企业采购流程的“纯用量”定价
BAD 版本：只提供 Pay As You Go 模式，没有任何年度承诺或预留实例选项。当大客户 CFO 询问“明年预算如何锁定”或“是否有价格保护”时，PM 回答“我们随市场调整，目前是最优价”。导致大客户因无法做长期预算规划而放弃签约。
GOOD 版本：提供"Committed Use Discount (CUD)"方案。客户承诺年消耗$1M，即可锁定当前价格 18 个月，并享有算力优先调度权。同时在合同中注明，若实际用量不足承诺量的 80%，需补足差额，若超过则享受更低阶梯价。
解析：B2B 交易的核心是确定性和预算可控。纯用量模式适合开发者，不适合企业。不懂企业采购心理的 PM，永远拿不下大单。
FAQ
Q1: 在 LLM API 定价中，应该按 Token 收费还是按请求次数（Request）收费？
这是一个经典的战略选择题，没有标准答案，只有适合场景的答案。如果你的模型主要用于短文本生成、分类或情感分析，且每次输入的 Token 数相对固定且较少，按 Request 收费更简单透明，客户易于理解预算。但如果你的模型主打长上下文（Long Context），比如处理整本书或长视频转录，按 Request 收费会导致严重的套利行为（客户会把大量内容塞进一个请求），此时必须按 Token 收费以覆盖成本。更高级的策略是混合模式：基础调用费 + 超长上下文附加费。
在面试中，不要二选一，要展示你对“成本结构”和“客户行为”的双重理解。例如，你可以说：“对于标准版模型，我们按 Request 收费以简化决策；对于 Pro 版长文本模型，我们按 Token 收费以体现资源消耗的差异。”关键在于，你的选择必须能防止客户滥用资源，同时让客户觉得公平。
Q2: 如何应对开源模型免费或极低价的竞争压力？
这是每个闭源模型 PM 都会被问到的问题。错误的回答是“我们也降价”或“我们功能更多”。正确的判断是：开源模型卖的是“模型权重”，你卖的是“确定性服务”。企业客户不敢在生产环境直接用开源模型，因为他们担心合规、数据隐私、SLA 无法保障以及运维成本高昂。你的定价策略应该包含这些隐性价值的显性化。比如，你的价格里包含了数据隔离、GDPR 合规认证、99.99% 的可用性承诺以及专属的技术支持。
在定价页上，不要只列价格，要列“风险对比表”。告诉客户：用开源模型看似免费，但一旦出事，法律成本是百万美元级的；用我们的 API，虽然每百万 token 多付$2，但你买的是保险。在硅谷的 Enterprise Sales 中，没人会因为便宜而选择不可靠的基础设施。你的高价，恰恰是你可靠的证明。
Q3: 新产品的定价应该在发布前定死，还是发布后快速迭代？
绝对不要在发布前定死。LLM 市场变化太快，今天的成本结构明天可能就变了。正确的做法是设计一个“可配置的定价引擎”。在后台，价格参数应该是动态可调的，无需重新发版。发布初期，可以采用"Beta 定价”，明确告知客户价格可能会在 3 个月后根据实际成本和反馈进行调整，并给予早期用户“终身锁定价”的优惠作为补偿。
这种策略既保留了调整的灵活性，又利用了“早鸟优惠”刺激早期采用。在面试中，如果你说“我们会根据数据每两周调整一次价格”，这会显得你很专业。因为这意味着你建立了“构建 - 衡量 - 学习”的闭环，而不是拍脑袋定个价格然后祈祷市场接受。定价是一个持续的产品优化过程，不是一次性的营销活动。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。