成本战略与开源定价：Token 卖多少钱才算合理

一句话：推理的单位成本由 GPU 租金或折旧、利用率、电力、带宽、运维和模型效率共同决定；开源是否伤害商业，取决于你是不是成本领先者。低价不是慈善，是用利润换生态和生存概率。

为什么需要

同样叫“每百万 token 一块钱”，两家公司的毛利可能差几十个点。差别不在报价，在成本结构：卡是买的还是租的、利用率是 30% 还是 90%、模型是稠密还是 MoE、输出是长是短、缓存命中多少、折旧按几年算。

只盯 API 单价会做错三个判断：以为自己自建一定便宜，忽略利用率和运维；以为开源等于不赚钱，忽略成本领先者的定价权；以为毛利率高就是暴利，忽略云厂商分成、研发和获客。成本是战略问题，不是财务事后算账。

核心机制

一、单位成本公式

每百万 token 成本 =
  GPU 小时成本 / (每秒 token 数 × 3600 × 利用率) × 1e6
  + 电力 + 带宽 + 运维 + 存储

GPU 小时成本包括租金或折旧：买卡是 capex 按年限摊，租卡是市场价。每秒 token 数取决于模型、batch、序列长度、量化和引擎；利用率是有效占用时间除以总时间。利用率在分母上，意味着它是最敏感的杠杆之一：利用率翻倍，单位 GPU 成本近似减半。

成本项在分子，吞吐和利用率在分母；售价决定毛利，但不改变成本。把这条链路画出来，就能看出低价策略必须落在“利用率高、吞吐高、折旧可控”三者之一，否则只是把亏损卖得更快。

但“每秒 token 数”不能只看峰值。长上下文会让 decode 变慢，小 batch 会让 GPU 空转，MoE 会带来路由和通信开销；真实成本要按业务请求的输入/输出分布加权，而不是用 benchmark 的最优形状。

二、固定成本与边际成本

买卡是固定成本，电费、带宽、运维是半固定，batch 和缓存降低的是边际成本。空闲的 GPU 不是免费：折旧、电和机位照付。所以“自建更便宜”有前提——利用率要足够高。

据 36kr 与 InfoQ 2026 年的测算，自建与 API 的成本平衡点大约在 52% 利用率；头部云厂商的利用率可到 90% 以上，部分创业公司只有 30%–50%。低于平衡点时，把波动流量交给 API 往往更便宜；高于平衡点，自建才有成本优势。这不是绝对数字，但方向很清楚：没有稳定负载，不要轻易买卡。

折旧年限也会改变结论。会计上常见 4 年，也有厂商主张 GPU 可用 7–8 年；同样一张卡，折旧年限翻倍，年化成本近似减半。但会计寿命不等于经济寿命：旧卡可能跑不动新 kernel、租不出去、价格被新一代卡打下来。用长年限做低价，等于把风险推到未来。

三、开源定价的经济学

开源权重意味着客户可以自己部署，价格就有天花板：你卖得太贵，客户会走。所以开源厂商的定价权来自成本领先，而不是来自锁定。成本领先者可以用低价换规模、换生态、换人才；不是成本领先者开源，可能只是把客户送给更会运营的人。

低价还有一个作用：它是可信的承诺。客户会想“它都开源了，应该不会明天涨价”；这能降低采用门槛。但低价也会压缩研发投入，形成“越便宜越没钱迭代”的循环；所以定价要看单位经济模型，不是看对手。

“六倍利润”“十个月回本”这类说法，是特定假设下的定价规则，不是普遍规律。十个月回本意味着一年左右回收投入，年化回报很高；但它通常忽略了利用率爬坡、电力、运维、模型过时和价格战。把它当目标可以，当事实不行。

四、谁拿走利润

据 Barclays 2026 年的分析，模型实验室每 100 美元收入里，大约 35–40 美元流向云厂商；直接 API 的毛利率可超过 80%，Agent 订阅约 70%，转售商则可能亏损。价值正在向“拥有算力且能用满”的一方迁移。

有第三方按 38 美元/GPU 小时、155 万亿 token/日 反推，得出某模型服务约 82% 的毛利率。这是在一套公开假设下的测算，不是审计后的利润；它说明低价不一定亏，但前提是利用率、模型效率和规模同时成立。换个利用率或折旧年限，结论就会变。

实战场景

场景：推理服务只按 GPU 租金定价，$0.55/百万 token 卖出 -21.7% 毛利

现象：一家推理服务商用本章最小上手的同一组参数（GPU 租金 2 美元/小时、单卡 2000 tok/s、70% 利用率）算出 $0.397/百万 token，加价到 $0.55 报价、按模板是 27.8% 毛利；上线三个月财务口径毛利率 -21.7%（经验值，需校准），单月现金净流出约 40 万元人民币（经验值，需校准），售价一次没动过。

排查路径：

排除对象	判定证据	结论
计量与计价	网关 token 计数与账单逐日核对偏差小于 1%，重试与失败请求都已计入分子	排除：计量与重复计费都不是原因
利用率与冗余	监控里有效占用确为 70%，但容量按 1.25 倍冗余采购，可售分母只有 56%	确认：分母口径错，70% 是占用不是可售
电费与人力	机房电费单折 $0.114/GPU 小时、出口与日志 $0.05、存储 $0.02；1 名 SRE 覆盖 16 卡、月薪 $6000，折 $0.514/GPU 小时	确认：公式右侧四个加项一个都没进报价
对症做法：按公式把每个加项按 GPU 小时折算，再用可售利用率代回分母，重算单位成本与毛利。

tps, util = 2000, 0.70 / 1.25                 # 70% 占用 ÷ 1.25 冗余 = 56% 可售
per_m = lambda x: x / (tps * 3600 * util) * 1e6
opex = {"GPU 租金": 2.0, "电力+制冷": 0.114, "带宽+日志": 0.05,
        "运维人力": 6000 / (16 * 730), "存储": 0.02}
for k, v in opex.items(): print(f"{k:8s} ${per_m(v):.3f}/M")
full = per_m(sum(opex.values()))
print(f"全成本 ${full:.3f}/M 现金 ${per_m(2.114):.3f}/M 毛利率 {1 - full / 0.55:.1%}")

本章公式只有四个加项和两个分母，最小上手只代了 GPU 租金一项：把电力、带宽、运维、存储折成 GPU 小时后分子从 2.0 涨到 2.698（+35%），再叠加冗余吃掉的分母，单位成本从 0.397 到 0.669，0.55 落在现金成本 0.524 与全成本之间。本章要求按现金成本、全成本、目标毛利三档设底线，这一单只越过了第一档。 复盘要点：判据是报价前把公式的每个加项逐一代入，并把利用率从“有请求的时间占比”换成“可售容量 × 有效占用”。红线：价格低于全成本必须写明补贴期限与退出条件，没有期限的低价等于把亏损固化。早发现的指标是每月用账单反算的单位成本除以报价，连续两个月毛利低于 5% 就触发复核，而不是等季报。

场景：32 卡自建集群按 70% 利用率定价，实际只有 30%，保本价 0.98 高于售价 0.55

现象：一家公司按 70% 利用率把 32 卡自建集群摊到 2 美元/GPU 小时，报价 $0.55/百万 token、按 27% 毛利立项；实际利用率 30%（P95 峰值需求只有采购容量的 34%，经验值，需校准），单位 GPU 成本按本章同一算式从 0.397 变成 0.926，毛利率 -68%（经验值，需校准）。销售仍按“每卖一单都是正贡献”继续打折，因为边际成本确实只有 $0.076/百万 token。

排查路径：

排除对象	判定证据	结论
定价公式	代入 70% 得 0.397、代入 30% 得 0.926，两者都与财务反算一致	排除：公式没写错，错的是利用率假设
利用率口径	有效占用按“有并发请求的时间占比”统计为 30%，P95 需求只到采购容量 34%，其中 31% 的 token 是夜间可延迟批处理	确认：分母是“为峰值买的卡”，不是负载
成本可逆性	租金与机房合同 36 个月、按 4 年折旧，电费不随利用率下降	排除：短期降本无空间，只剩提利用率或改价
对症做法：用固定成本除以月售 token 反推保本价，再决定 30% 那部分负载该不该留在自建。

cards, hours, tps = 32, 730, 2000
fixed = cards * hours * 2.114                # 租金 + 电力，不随利用率变化
for u in (0.30, 0.52, 0.70):
    tokens = cards * tps * 3600 * hours * u  # 月售 token 与利用率线性相关
    print(f"util={u:.0%} 月售 {tokens/1e9:.1f} B 保本 ${fixed/tokens*1e6:.2f}/M")
# 30%：50.5 B、$0.98/M；52%：$0.56/M；70%：$0.42/M

本章公式里利用率在分母且是乘数，30% 与 70% 让单位 GPU 成本从 0.397 变 0.926，正好是利用率之比的 2.3 倍；而固定成本（租金加电）不随利用率下降而减少，所以保本价反比于利用率，利用率算错一倍，保本价就错一倍。本章的 52% 平衡点是判据：30% 的负载原本该把波动部分交给 API。 复盘要点：判据是固定成本的摊销分母只能是“可售容量 × 实际利用率”，用计划利用率定价等于用假设定价。红线：利用率低于 52% 平衡点时，新增长期容量合同一律不签，峰值走弹性 API。早发现的指标是每周的“实际 tok/s ÷ 采购容量”，连续两周低于定价假设的 0.7 倍就重算保本价。

场景：开源 32B 只对标 API 单价自建，8 卡集群单位成本反而贵 40%

现象：一个团队用开源 32B 替代 $1.20/百万 token 的闭源 API，按 4 卡、60% 利用率估出 $0.46/百万 token，判定便宜 62%（经验值，需校准）；采购时按 P95 峰值买了 8 卡（峰值是均值的 3.2 倍），三个月后财务口径 $1.68/百万 token，比 API 贵 40%。日均有效利用率只有 25%，冷启动 4 分钟让 12% 请求超时重试，另摊 0.5 个 SRE。

排查路径：

排除对象	判定证据	结论
引擎与硬件	同模型单卡 2000 tok/s 与社区基线一致，峰值时段 GPU 利用率 85%、无降频	排除：不是引擎效率问题
容量口径	日均 4051 tok/s ÷（8 卡 × 2000 tok/s）= 25.3%，定价假设是 60%	确认：分母是“为峰值买的卡”，冗余 2 倍
冷启动与人力	网关 12% 请求带 retry 且集中在峰值扩容窗口（70 GB 权重从对象存储拉加引擎预热约 4 分钟）；月度工单折算 0.5 SRE 等于 $0.51/GPU 小时	确认：有效吞吐再乘 0.88，且人力整项漏算
对症做法：把自建停在能跑满的容量上，峰值溢出交给按量计费的 API，再算混合单位成本。

avg_tps, per_gpu, api = 4051, 2000, 1.20          # api 为 $/百万 token
for cards in (8, 4):
    util = avg_tps / (cards * per_gpu)            # 有效利用率，不是峰值占比
    gpu = 2.0 / (per_gpu * 3600 * util) * 1e6
    print(f"{cards} 卡 util={util:.1%} GPU 成本 ${gpu:.2f}/M")
# 8 卡 util=25.3% $1.10，加电力/0.5 人力/重试 0.88 折 = $1.68，已高于 API 的 1.20
# 4 卡 util=50.6%（≈本章 52% 平衡点）$0.55，溢出 12% 的 token 走 API，混合 $0.63

本章公式的分母是“每秒 token 数 × 利用率”，自建的利用率由“为峰值买的卡”决定，而不是平均负载：8 卡的 25.3% 把 GPU 项推到 1.10，再加电力、0.5 人力和重试的 0.88 折，正好反超 API 的 1.20。把自建停在 4 卡、50.6% 逼近 52% 平衡点，溢出 12% 的峰值 token 按 1.20 买，混合成本 0.63。 复盘要点：判据是自建与 API 对比的分母为“采购容量 × 有效利用率”，按 P95 采购就必须把冗余倍数写进单位成本，不能只写引擎吞吐。红线：冷启动超过 1 分钟的服务禁止缩容到 0，扩容触发线要提前一个冷启动窗口。早发现的指标是每周的“实际 tok/s ÷ 采购容量”和网关 retry 率，后者超过 5% 就说明容量或预热已经不够。

最小上手

假设 GPU 租金 2 美元/小时、每秒输出 2000 token、售价 1 美元/百万 token，只改变利用率，看成本与毛利怎么变。

gpu_hour = 2.0
tokens_per_sec = 2000
price_per_m = 1.0

for util in (0.3, 0.5, 0.9):
    cost = gpu_hour / (tokens_per_sec * 3600 * util) * 1e6
    margin = 1 - cost / price_per_m
    print(f"util={util:.0%} cost=${cost:.3f}/M margin={margin:.1%}")

输出：

util=30% cost=$0.926/M margin=7.4%
util=50% cost=$0.556/M margin=44.4%
util=90% cost=$0.309/M margin=69.1%

售价没变、模型没变、卡没变，只把利用率从 30% 提到 90%，毛利率从 7.4% 涨到 69.1%。这就是为什么容量规划是定价决策：买多了，折旧压死；买少了，峰值接不住。真实成本还要加电力、带宽和运维，但这个模型足以判断“低价能不能活”。

生产动作

• 按成功任务算成本：不是每百万 token，而是每次成功回答/每次工具调用；失败、重试、超长上下文和缓存未命中都进分子。
• 分模型、分场景核算：输入/输出比例、上下文长度、batch、缓存命中率不同，单位成本可能差几倍；不要用一个平均数定价。
• 监控利用率：按 GPU、模型、租户看有效占用；低于平衡点的自建容量，优先考虑弹性 API 或共享。
• 把缓存和批处理算进模型：前缀缓存、连续批处理、量化都会改变每秒 token 数；定价前用真实流量压测。
• 折旧假设写清楚：4 年还是 8 年、残值多少、何时淘汰；财务口径和容量口径要能对上。
• 开源前先算三笔账：成本曲线是否领先、 license 是否允许商用、支持与托管服务能不能收费；不要只算“省了销售成本”。
• 设价格底线：按现金成本、全成本、目标毛利三档设底线；价格战可以打，但要知道打到哪一层会失血。
• 合同留弹性：预留实例、按量、承诺用量各有风险；把电力、带宽和涨价条款写进模型。

边界

• 会计利润不等于现金流。折旧年限、资本化、预付款都会改变报表；看单位经济模型，不要只看毛利率。
• 利用率假设最容易失真。峰值流量、冷启动、故障切换都会拉低平均利用率；用 P95 负载规划，不要用平均。
• GPU 会过时。今天能跑满的卡，明天可能因为新模型、新精度或新互联而贬值；长折旧是在赌技术稳定。
• 开源不等于免费。托管、支持、合规、SLA 都要成本；客户自建也要付出人力和运维。
• 低价有边界。低于现金成本的价格不可持续；靠融资补贴的定价，会在融资环境变化时反噬。
• 需求弹性不保证。降价不一定带来足够增量；如果容量有限，低价只会让排队更长。
• 第三方测算不是审计。82% 毛利、52% 平衡点、35–40% 云分成都有假设；引用时要带口径，不要当普适常数。

讲清楚

Token 成本的分母是“每秒 token 数 × 利用率”，分子是 GPU 小时成本；利用率翻倍，单位成本近似减半。买卡还是租卡，取决于负载是否稳定、利用率能否过平衡点。

开源是一种定价承诺：客户可以自己部署，价格有天花板。成本领先者开源能换规模和生态，非成本领先者开源可能只是让出客户。低价能不能持续，看单位经济模型，不看口号。

判断 AI 生意，别只看 API 单价和毛利率；看每成功任务成本、利用率、折旧年限和云厂商分成。十个月回本、六倍利润、82% 毛利都是特定假设下的结果，换个利用率就可能不成立。

参考：36kr 利用率测算；InfoQ 推理成本；Barclays 云分成分析；38 美元/GPU 小时与 82% 毛利测算；GPU 折旧年限的公开讨论

适用：推理服务定价、自建/API 选择与开源商业化评估 | 初稿 2026-10