作者注：从推理服务的成本结构出发，解释 Token 服务为什么容易亏损，并给出一套评估模型 API 服务商的可执行清单。
Token 已经被拿进直播间售卖，可“硅基流动”这类推理服务商的财务表现仍然不乐观。另一则新闻里，一家公司嫌 Claude 太贵，改用 GLM，用 56 张 B200 支撑 2000 名工程师，AI 成本下降约 90%。两件事放在一起看，Token 服务的成本结构有它自己的规律。本文将从 推理服务的成本结构 出发，说明 Token 服务为什么会亏，再落到开发者真正关心的问题：怎样评估一家模型 API 服务商是否靠谱。
这不是又一篇行业八卦解读。文中的拆解都围绕技术变量展开，包括 GPU 折旧、利用率、Prefill 与 Decode 的成本差、KV Cache、缓存命中率和补贴策略。读完后你可以把它直接用在选型评估里。
核心价值：读完本文，你会理解 Token 价格背后的成本构成，并掌握一套 6 维度的服务商评估方法。你还会知道怎样用真实调用数据核对计费是否透明。
Token 服务为什么会亏：推理成本结构核心要点
先给出结论。推理服务的成本大部分是固定成本，收入却按 Token 量计费，两者之间靠“利用率”连接。利用率上不去，或者价格被竞争压到边际成本附近，账面就会亏损。
| 成本要素 | 说明 | 对 Token 单价的影响 |
|---|---|---|
| GPU 资本开支与折旧 | 高端 GPU 采购或长租费用，按年限摊销 | 固定成本，利用率越低，单 Token 分摊越高 |
| 机房、电力、网络 | 托管、散热、带宽、跨区容灾 | 半固定成本，规模化后才能摊薄 |
| GPU 利用率 | 实际在跑推理的时间占比与批处理饱和度 | 盈亏的核心杠杆，峰谷差直接吃掉利润 |
| Prefill / Decode 结构 | 输入并行处理，输出逐 Token 生成 | 输出 Token 更贵，长输出场景压力大 |
| 长上下文与 KV Cache | 显存被缓存占用，降低并发容量 | 长上下文请求会挤占可服务的用户数 |
| 补贴与获客 | 免费额度、低价引流、渠道分成 | 短期拉量，长期拉低毛利 |
Token 服务成本结构重点详解
固定成本与按量收入的错配是第一个原因。一台满配 GPU 服务器不论有没有请求，折旧、电费和机房费用都在发生。用户却只按实际消耗的 Token 付费。白天高峰需要预留足够算力保证延迟，夜间低谷这些算力就闲着，空闲时段的成本最终都要摊到高峰时段卖出的 Token 上。如果定价只参考“满载时的理论成本”，实际运营几乎一定亏。
价格竞争把单价压向边际成本是第二个原因。开源模型权重人人可用，多家推理服务商部署的是同一个模型，差异化空间很小，价格自然成为主要竞争手段。把 Token 放进直播间促销，说明这类商品已经接近“标准化大宗品”。这种情况下，服务商很难靠溢价覆盖固定成本，只能拼规模和调度效率。
推理服务成本拆解：Token 单价是如何被算出来的
理解 Token 服务为什么会亏，需要把一次推理请求拆成两个阶段来看。不同阶段消耗的资源不同，计费口径也就不同。这正是很多服务商把输入、输出、缓存分开定价的原因。
Prefill 与 Decode：为什么输出 Token 更贵
一次请求先进入 Prefill 阶段。模型并行处理全部输入 Token，计算密集但效率高，GPU 算力能被充分利用。随后进入 Decode 阶段，模型每次只生成一个 Token，并且要反复读取之前的 KV Cache。这个阶段更受显存带宽限制，GPU 的算力难以吃满。
所以同样数量的 Token，输出的单位成本通常明显高于输入。主流服务商的定价也普遍是输出单价高于输入单价。如果业务以长输出为主，比如代码生成、长文写作或 Agent 多轮推理，成本会集中在输出侧。评估服务商时，要优先看输出单价和输出吞吐。
KV Cache 与长上下文：看不见的显存税
长上下文请求的代价不止“输入多”。KV Cache 会随上下文长度增长而占用更多显存，一张卡能同时服务的请求数随之下降。也就是说，一个超长上下文用户可能挤占好几个普通用户的并发位置。这部分成本不一定完整体现在单价里，服务商只能通过分档定价、限流或上下文长度限制来平衡。
缓存命中：既是降本手段，也是定价陷阱
提示词缓存（Prompt Caching）可以让重复的前缀不再重新计算，命中部分按更低的缓存读取价计费。对 Agent、RAG 这种系统提示长且重复的业务，缓存命中率会显著影响最终账单。需要注意，不同服务商对缓存写入、缓存读取、缓存有效期的计费口径不一致，有的还需要显式开启。评估时一定要确认返回的 usage 字段里是否包含缓存相关的 Token 统计。
| 计费口径 | 资源消耗特点 | 评估时要确认的点 |
|---|---|---|
| 输入 Token | Prefill 并行计算，效率较高 | 是否按上下文长度分档计价 |
| 输出 Token | Decode 逐个生成，受显存带宽限制 | 输出单价、输出吞吐（Token/s） |
| 缓存写入 | 首次写入缓存，部分平台单独计费 | 写入是否加价、有效期多长 |
| 缓存读取 | 命中前缀，跳过重复计算 | 命中部分折扣、usage 是否透出 |
| 推理思考 Token | 推理模型的内部思考过程 | 是否计入输出、能否限制预算 |
💰 价格口径说明：上表只说明计费维度，不涉及具体价格。本文涉及模型的输入单价、输出单价、缓存读写价格，请以 API易 价格页
https://docs.apiyi.com/models的实际数据为准。不同模型、不同分组的计费口径可能不同，下单前请逐项核对。
自建推理 vs 调用 API：Token 成本账怎么算
“56 张 B200 支撑 2000 名工程师、成本降低约 90%”这个案例能成立，有几个前提。这家公司的负载来自内部工程师，请求量大且相对稳定。工作时间集中，可预测性强。模型换成了开源可自部署的 GLM。这三点让固定成本能被充分摊薄，正好避开了公有推理服务商最头疼的利用率问题。
反过来说，这个案例并不意味着所有团队都应该自建。如果请求量小、波动大，或者需要频繁切换多个闭源模型，自建 GPU 集群的闲置成本会很快超过 API 账单。公有推理服务商的价值，正是用大量客户的负载互相“削峰填谷”，换取更高的整体利用率。
| 方案 | 成本结构 | 适用场景 | 主要风险 |
|---|---|---|---|
| 自建 GPU 集群 | 高固定成本，低边际成本 | 用量大、负载稳定、模型固定的大团队 | 闲置浪费、运维人力、硬件迭代贬值 |
| 单一模型官方 API | 纯按量付费 | 强依赖某个闭源模型的业务 | 价格单一、切换成本高、区域可用性受限 |
| 多模型 API 聚合平台 | 按量付费，统一接口 | 需要对比、切换、混合使用多个模型 | 需核实计费透明度与稳定性 |
| 混合架构 | 高频任务自建，长尾任务走 API | 业务规模中大、模型分层明确 | 架构复杂度上升 |
自建方案对标分析：自建在单位成本下限上有优势，但前提是利用率足够高，而且团队有能力处理部署、量化、扩缩容和故障恢复。相比之下，API 方案的单位成本更可预测，更适合负载波动大、需要多模型并行验证的团队。
聚合平台对标分析：官方 API 在模型首发速度上有优势，但多数情况下一个账号只覆盖一家的模型。多模型聚合平台的好处是一套接口对接多个模型，便于做 A/B 对比和成本分层。像 API易 apiyi.com 这类平台同时兼容 OpenAI 与 Anthropic 接口格式，现有代码改动很小就能切换模型。
如何评估模型 API 服务商：6 维度快速上手清单
理解成本结构以后，就能反推出一个判断：长期低于成本的价格不可持续。服务商要么在某个环节“省”，要么靠补贴撑一段时间。评估服务商时，不能只盯着标价，下面 6 个维度要一起看。
| 维度 | 核心问题 | 验证方法 |
|---|---|---|
| 1. 价格透明度 | 输入、输出、缓存是否分别公示 | 对照价格页，逐项记录口径 |
| 2. 计费一致性 | 实际扣费是否与 usage 一致 |
小批量调用后核对账单明细 |
| 3. 模型真实性 | 是否存在降级、混用或过度量化 | 固定测试集对比输出质量 |
| 4. 性能稳定性 | 首字延迟、吞吐、错误率如何 | 高峰与低谷各测一轮 |
| 5. 接口兼容性 | 是否兼容 OpenAI / Anthropic 格式 | 用现有 SDK 只换 base_url 测试 |
| 6. 可持续性 | 价格是否明显低于合理成本区间 | 结合成本结构判断补贴风险 |
第一步：用兼容接口接入并做最小调用
不写代码也能把测试流程讲清楚。如果你的项目已经在用 OpenAI SDK，通常只需要改两个配置项：把 api_key 换成服务商提供的密钥，把 base_url 换成服务商的接口地址。以 API易 为例，OpenAI 兼容格式的 base_url 为 https://api.apiyi.com/v1，对话请求走 /v1/chat/completions 路径，model 字段填写目标模型名称即可。
如果项目基于 Anthropic SDK，比如使用 Claude 系列模型或 Claude Code 类工具，同样可以替换接口地址，走 /v1/messages 路径的 Anthropic 原生格式。具体地址和模型名称以 API易 文档 https://docs.apiyi.com 为准。做最小调用时建议同时开启 stream 流式输出，方便后面测量首字延迟。
第二步：核对计费口径与 usage 字段
每次调用的响应里，OpenAI 格式会返回 usage.prompt_tokens、usage.completion_tokens，部分模型还会给出缓存命中的 cached_tokens。Anthropic 格式对应的是 input_tokens、output_tokens 以及缓存读写字段。你可以用一个简单公式估算单次成本：输入 Token 数乘以输入单价，加上输出 Token 数乘以输出单价，再加上缓存读写 Token 数乘以对应的缓存单价。
把估算值和平台账单明细对比，偏差应当可解释。如果长期出现“账单比 usage 推算的多”，或者缓存命中从不体现在计费上，就要警惕了。估算时用到的单价，请以 API易 价格页 https://docs.apiyi.com/models 公示的数据为准。
第三步：测性能、测质量、测高峰
性能测试建议记录三个指标：首字延迟（TTFT）、输出吞吐（每秒 Token 数）、错误率（超时、429 限流、5xx）。工作日高峰和夜间低谷各测一轮，波动越小说明服务商的容量规划越充足。质量测试用一组固定提示词，覆盖代码、推理、长文本，和官方渠道或其他平台的输出交叉对比，有助于发现模型被降级或替换。
| 测试项 | 关键参数 / 字段 | 合格参考 |
|---|---|---|
| 首字延迟 | 开启 stream，记录首个 chunk 时间 |
高峰与低谷差异不过大 |
| 输出吞吐 | completion_tokens ÷ 生成耗时 |
与同模型其他渠道相近 |
| 计费核对 | usage 各字段 × 价格页单价 |
与账单明细偏差可解释 |
| 缓存命中 | cached_tokens 或缓存读取字段 |
长前缀重复请求有命中 |
| 稳定性 | 429 / 5xx / 超时次数 | 错误率低且有重试说明 |
🚀 快速开始：如果想在同一套接口下对比多个模型的成本与表现，可以先通过 API易 apiyi.com 注册并获取测试额度。平台提供本文涉及的主流模型 API 调用，兼容 OpenAI 与 Anthropic 接口格式，把
base_url换成https://api.apiyi.com/v1即可开始验证。各模型价格以https://docs.apiyi.com/models为准。
常见问题 FAQ
Q1：Token 服务为什么会亏损？
推理服务以 GPU 折旧、机房电力等固定成本为主，收入却按 Token 量计费。高峰需要预留算力，低谷算力闲置，利用率难以长期维持高位。再加上开源模型同质化带来的价格战和免费额度补贴，售价容易被压到成本以下。
Q2：为什么输出 Token 普遍比输入 Token 贵？
输入在 Prefill 阶段并行计算，GPU 利用效率高。输出在 Decode 阶段逐个生成，需要反复读取 KV Cache，主要受显存带宽限制，单位成本更高。因此长输出业务要重点关注输出单价和吞吐。
Q3：自建 GPU 一定比调用 API 便宜吗？
不一定。“56 张 B200 支撑 2000 名工程师”这类案例，依赖的是大规模、稳定、可预测的内部负载。用量小或波动大的团队自建后闲置严重，单位成本反而更高。建议先用 API 跑出真实用量曲线，再评估盈亏平衡点。
Q4：价格特别低的 API 服务商可以用吗？
可以测，但要多做验证。明显低于合理成本区间的价格，通常意味着补贴、限流、模型降级或稳定性折扣中的某一种。按本文的 6 维度清单做质量和计费核对，比单看标价更可靠。
Q5：如何低成本对比多个模型的 API 表现？
推荐使用兼容主流接口格式的多模型平台做统一测试：
1. 在 API易 apiyi.com 注册账号并获取 API Key
2. 按文档 `https://docs.apiyi.com` 配置 OpenAI 或 Anthropic 兼容接口
3. 用固定测试集轮流切换 `model` 字段，记录延迟、质量与 `usage`
同一套代码就能完成横向对比，切换成本很低。
Q6：缓存价格怎么查？不同平台口径一样吗？
不一样。有的平台对缓存写入单独计费，有的只对读取打折，有效期和开启方式也不同。在 API易 上调用时，缓存读写价格以价格页 `https://docs.apiyi.com/models` 的实际数据为准，并结合返回的 `usage` 缓存字段核对扣费。
Q7：评估服务商时最容易被忽略的指标是什么？
计费一致性和高峰稳定性。很多团队只在低峰时段做一次测试就上线，结果高峰期频繁遇到 429 或超时。也有不少团队从不核对 `usage` 和账单的对应关系。这两项都应纳入上线前的固定检查。
Token 服务成本与 API 服务商评估 Key Takeaways
- 亏损根源：固定成本高、按量收入、利用率波动，三者错配导致 Token 服务易亏
- 输出更贵：Decode 受显存带宽限制，长输出业务要盯紧输出单价与吞吐
- 长上下文有隐性成本：KV Cache 挤占显存，降低并发，服务商只能用分档与限流平衡
- 自建有门槛：只有大规模稳定负载才能摊薄 GPU 固定成本，小团队优先用 API
- 评估看六维：价格透明、计费一致、模型真实、性能稳定、接口兼容、可持续
- 上手方式：通过 API易 兼容 OpenAI / Anthropic 格式快速实测，价格以
docs.apiyi.com/models为准
总结：从成本结构看懂 Token 服务，选对模型 API 服务商
Token 服务为什么会亏，归根结底是推理服务的成本结构决定的：
- 成本端：GPU 折旧、机房电力是固定成本，利用率是盈亏杠杆，输出 Token 与长上下文进一步推高成本
- 收入端：开源模型同质化让价格战难以避免，补贴拉量却压低毛利
- 选型端：低价不等于划算，要用价格透明、计费一致、模型真实、性能稳定、接口兼容、可持续这 6 个维度综合判断
对开发者来说，与其猜测哪家服务商能撑多久，不如用真实调用数据说话。先用小流量跑通计费核对和质量对比，再决定主力模型和备用渠道。
推荐通过 API易 apiyi.com 快速验证效果。平台提供本文涉及模型的 API 调用，兼容 OpenAI 与 Anthropic 接口格式，接入文档见 https://docs.apiyi.com。所有模型的输入、输出与缓存价格，以价格页 https://docs.apiyi.com/models 的实际数据为准。
📚 参考资料
- 36氪 – Token都卖进李佳琦直播间了，“硅基流动”们为何还在亏损？：推理服务商盈利困境报道
- 链接：
36kr.com/p/4055385238017664 -
说明： 了解 Token 商品化与推理服务商亏损的行业背景
-
36氪 – 有人每月烧掉1万美元，嫌Claude太贵，这家公司改用GLM：企业自建推理降本案例
- 链接：
36kr.com/p/4055383551038595 -
说明： 56 张 B200 支撑 2000 名工程师的自建推理案例，可用于理解自建与 API 的成本边界
-
API易 文档中心：接口接入与模型价格
- 链接：
docs.apiyi.com - 说明： 查看 OpenAI / Anthropic 兼容接入方式，模型价格以
docs.apiyi.com/models为准
作者: APIYI 技术团队
技术交流: 关于模型选型与 Token 成本评估的问题，欢迎通过 API易 官网 apiyi.com 联系我们，更多接入资料可访问 docs.apiyi.com 文档中心
