同一周内，Moonshot 的 Kimi K3 与阿里巴巴的 Qwen 3.8 相继发布，并被描述为追平 Anthropic 的 Fable 5；两者还计划开放模型权重。Wojciech Gryc 的分析没有继续比较榜单分数，而是把焦点转向财务问题：当能力差距缩小时，闭源模型高出约三倍的价格，究竟在为什么买单？
摘要没有给出完整的训练成本、推理单价和使用量明细，因此不能仅凭“三倍”推导 Anthropic 的利润率。不过，这个问题提供了一套很实用的评估框架：不要只比每百万 token 的标价，要比较完成同一业务任务的总成本。
三倍单价不等于三倍总成本
闭源 API 的账单通常比较直观：输入 token、输出 token，再加缓存、工具调用或批处理等费用。开源权重看起来没有 API 单价，但运行它需要 GPU、推理框架、运维人员和容量冗余。
可以把月度成本写成两组公式：
闭源 API 月成本 = 输入 token 成本 + 输出 token 成本 + 附加服务成本
自托管月成本 = GPU 租金 + CPU/内存/存储 + 网络成本
+ 运维与工程成本 + 空闲容量成本
真正应该比较的则是：
每个成功任务的成本 = 月度总成本 / 成功完成的任务数
这里的“成功”很重要。如果价格较低的模型需要重试、生成更长的答案，或者必须增加一次校验调用，它的有效成本可能显著上升。反过来，如果开源模型经过量化和批处理后能持续吃满 GPU，那么零权重许可费会逐渐转化为真实的单位成本优势。
Anthropic 的溢价可能覆盖什么
在能力接近的前提下，闭源服务的溢价不能只靠模型分数解释。企业实际购买的还可能包括托管推理、弹性容量、稳定接口、监控、安全控制以及故障责任边界。这些能力是否值得三倍价格，取决于使用场景，而不是一张统一榜单。
低流量或波动明显的业务往往更适合 API。团队不用提前租 GPU，也不必为夜间空闲容量付费。高流量、请求形态稳定的业务则更容易摊薄自托管的固定成本，尤其是在模型能够量化、批量推理，并且团队已经具备 GPU 平台能力时。
训练成本也不能直接决定客户应付的价格。厂商需要回收训练和研发投入，但客户最终关心的是替代方案：完成同一个客服回复、代码修改或研究任务，需要花多少钱、等待多久，并承担多大风险。Kimi K3 和 Qwen 3.8 开放权重的意义，正是给采购方增加了可部署、可优化和可议价的选项。
用自己的流量跑一遍成本模型
下面是一个可直接运行的 Python 估算器。示例数字只是演示假设，不代表摘要中任何厂商的真实价格。运行前应替换 API 单价、GPU 租金、吞吐量和任务成功率。
from dataclasses import dataclass
@dataclass
class Workload:
requests_per_month: int
input_tokens_per_request: int
output_tokens_per_request: int
@dataclass
class ApiPlan:
input_usd_per_million: float
output_usd_per_million: float
success_rate: float
@dataclass
class SelfHostedPlan:
gpu_count: int
gpu_usd_per_hour: float
hours_per_month: int
platform_usd_per_month: float
success_rate: float
def api_cost(workload: Workload, plan: ApiPlan) -> tuple[float, float]:
input_tokens = workload.requests_per_month * workload.input_tokens_per_request
output_tokens = workload.requests_per_month * workload.output_tokens_per_request
monthly = (
input_tokens / 1_000_000 * plan.input_usd_per_million
+ output_tokens / 1_000_000 * plan.output_usd_per_million
)
successful_tasks = workload.requests_per_month * plan.success_rate
return monthly, monthly / successful_tasks
def self_hosted_cost(workload: Workload, plan: SelfHostedPlan) -> tuple[float, float]:
monthly = (
plan.gpu_count * plan.gpu_usd_per_hour * plan.hours_per_month
+ plan.platform_usd_per_month
)
successful_tasks = workload.requests_per_month * plan.success_rate
return monthly, monthly / successful_tasks
workload = Workload(
requests_per_month=2_000_000,
input_tokens_per_request=1_500,
output_tokens_per_request=500,
)
api = ApiPlan(
input_usd_per_million=3.0,
output_usd_per_million=15.0,
success_rate=0.94,
)
self_hosted = SelfHostedPlan(
gpu_count=8,
gpu_usd_per_hour=4.0,
hours_per_month=730,
platform_usd_per_month=8_000,
success_rate=0.90,
)
for name, result in {
"闭源 API": api_cost(workload, api),
"开源自托管": self_hosted_cost(workload, self_hosted),
}.items():
monthly, per_success = result
print(f"{name}: 月成本=${monthly:,.2f}, 每个成功任务=${per_success:.4f}")
执行命令：
python3 cost_model.py
这个脚本故意保持简单。用于正式决策时，还应加入峰值容量、缓存命中率、批处理收益、量化后的质量变化、失败重试、数据传输和工程师人力。对于智能体工作流，还要统计一个任务触发的平均模型调用次数，而不是只计算用户请求数。
采购前做一次受控对照
比价时可以从生产流量中抽取一批脱敏任务，让 Fable 5、Kimi K3 和 Qwen 3.8 执行相同输入，并记录质量、延迟、token 数量与失败率。评审标准应在测试前确定，避免看到结果后再修改“成功”的定义。
一份可执行的检查清单包括：
- 用业务任务成功率替代单一基准分数。
- 同时测量平均延迟和 P95、P99 尾延迟。
- 把重试、审核模型和工具调用计入总 token。
- 给自托管方案加入空闲 GPU 和运维人力成本。
- 检查开放权重对应的许可证、商业使用和再分发限制。
- 评估数据驻留、供应商锁定、升级节奏与故障响应责任。
“三倍”是值得追问的价格信号，却不是采购结论。闭源 API 卖的是模型能力与托管服务的组合，开放权重卖的是控制权和优化空间。只有把两者换算成每个成功任务的成本，再叠加延迟、合规与运维风险，才能看出 Anthropic 的溢价是合理保险，还是会被开源模型迅速压缩的利润空间。