在多大的 token 用量下，自托管才比 API 便宜？

这取决于利用率，所以没有单一数字。大致来说，在 GPU 得到充分利用时，每月数百万 token 就可能胜过高价 API；但要胜过廉价的预算型 API，则需要每月数千万到数亿 token。一个常见的经验阈值是每天持续数百万 token——低于这个水平，通常还是 API 更划算。

每月运行一台 H100 要花多少钱？

在专业 GPU 云上，按需 H100 大约每小时 $1.50–3.00（超大规模云服务商更贵），因此一台 7×24 小时运行的专用实例每月约为 $1,000–5,000，具体取决于服务商档位。这笔固定成本需要你的 token 用量来填满，自托管才物有所值。

为什么 GPU 利用率对自托管的经济性至关重要？

因为无论 GPU 是忙碌还是闲置，成本都是一样的。充分利用时，每百万 token 的成本可以降到一美元以下；在低负载（比如 10%）时，实际每 token 成本大约上涨十倍，往往使自托管比高价 API 还贵。闲置的 GPU 是纯粹的浪费——利用率是最大的单一变量。

自托管比预算型 API（如托管的小型模型）更便宜吗？

通常只有在用量非常高时才如此。预算型 API 定价很激进，因此靠自托管超越它们，通常需要在良好利用率下每月数千万到数亿 token。相比之下，与高价 API 的交叉点会来得早得多。请与你实际会用的那个具体 API 比较，而不是某个通用费率。

量化能把自托管成本降低多少？

相当可观。FP8 在几乎不损失质量的情况下将吞吐量提升约一倍，INT4 可提升约两倍，同时把模型压缩到能装进更小、更便宜的 GPU。对于大型模型，这可以把每百万 token 的成本砍掉一半甚至更多——量化是自托管中杠杆效应最高的成本手段之一。

自托管 LLM 有哪些隐藏成本？

运维。除 GPU 账单外，你还要为 MLOps 工程（六位数年薪）、模型更新周期（每次数周工作量），以及推理服务器、驱动管理、自动扩缩容和监控买单。这些通常是原始硬件成本的数倍，也正是大多数粗糙的盈亏平衡测算所遗漏的部分。

我能把自托管和 API 结合起来以优化成本吗？

能——混合方案通常是最明智的做法。把高且稳定的用量放在本地或自有推理上运行，把中等用量、可预测的工作负载放在专用端点上，把突发型或低用量流量（以及任何需要前沿质量的内容）放在按 token 付费的 API 上。按经济性路由，既能拿到自托管的节省，又不必为突发工作中的闲置 GPU 付费。

← Resources

By Jordan Malik — Staff Engineer, Inference · 2026-06-02 · GUIDE

自托管 LLM 何时真的比 API 更便宜

只有当 token 用量超过某个完全取决于 GPU 利用率的阈值时，自托管 LLM 才会比 API 更便宜——并不存在单一的盈亏平衡数字。本指南讲清真实的计算逻辑、批处理与量化为何起决定作用、隐藏的运维成本，以及为什么混合方案通常才是正确答案。

不存在单一的盈亏平衡数字

对于「自托管何时更便宜？」这个问题，诚实的答案是一个由利用率决定的区间，而不是某个数字——这正是已发布的估算结果相差数个数量级的原因。它们各自假设了不同的 GPU 价格、利用率，以及不同的对比 API。

有用的大致规律是：在 GPU 得到充分利用的前提下，自托管以相对适中的持续用量（每月数百万 token）就能胜过高价 API；但要胜过廉价的预算型 API，则需要多得多的用量（每月数千万到数亿 token）。一个粗略的中间参考点是每天持续数百万 token。低于这个水平，API 几乎总是更划算。

GPU 的成本计算

自托管意味着租用或购买 GPU，而这笔固定成本正需要你的 token 用量来「填满」。在专业 GPU 云上，按需 H100 大约每小时 $1.50–3.00（超大规模云服务商更贵），因此一台 7×24 小时运行的专用 H100，每月费用约为 $1,000–5,000，具体取决于服务商档位。

这笔月度固定费用无论你用不用都要支付——这正是每百万 token 成本只有在高利用率下才便宜的原因。充分利用时，中型模型的每百万 token 成本可以降到远低于一美元；而在 10% 负载下，实际每 token 成本大约上涨十倍，足以让自托管比高价 API 还贵。闲置的 GPU 是在成本之争中输得最快的方式。

决定因素是批处理与量化

有两个杠杆对盈亏平衡点的影响超过其他任何因素。持续批处理（借助现代推理服务器）是其中的经济引擎：在同一块 GPU 上同时处理多个请求，可以大幅压低每 token 成本——从一次处理一个请求转为大批量处理，吞吐量就能提升数个数量级。流量忽高忽低、并发低的场景无法填满批次，运行效率比峰值差数倍，这正是突发型工作负载不适合自托管的原因。

[量化](/articles/llm-quantization-explained-gguf)是另一个杠杆：FP8 在几乎不损失质量的情况下将吞吐量提升约一倍，INT4 可提升约两倍，同时把模型压缩到能装进更小、更便宜的 GPU。批处理与量化结合起来，可以把每 token 成本拉动数倍。

隐藏成本：运维

GPU 账单并不是全部开销。运维成本通常是原始硬件成本的数倍：一名 MLOps 工程师的年薪高达六位数，而每一轮模型更新——重新量化、测试、重新部署——都是数周的工作量。「免费」的开放权重模型，在你算上推理服务器、驱动与 CUDA 管理、自动扩缩容和监控之后，每年可能隐藏着数十万美元的工程成本。

这正是让粗糙的自托管测算翻车的那一项开销。规格表上的每 token 成本假设 GPU 会自己运转；而现实中得有人让它持续运转，而那个人并不是免费的。

API 明显胜出的情形（以及成本之外的因素）

对于用量低或波动大、流量不可预测、团队没有内部 MLOps 能力，以及需要你自己无法运行的前沿质量模型的情形，API 是正确的选择。据一项估算，对于绝大多数使用场景，API 都是更好的选择——而且 API 价格在持续下降，这会随着时间推移不断推高自托管的盈亏平衡点。

有两个因素完全在成本计算之外：延迟和隐私。无论 token 经济性如何，在数据驻留、受监管的工作负载，以及可预测的区域内延迟方面，自托管都更有优势——参见我们的[本地部署指南](/articles/on-premise-ai-for-enterprise)。即便纯粹的成本计算并不支持，这些因素也足以证明自托管的合理性。

用 osFoundry 按经济性路由

务实的答案是混合方案：按经济性而非意识形态来路由。高且稳定的用量应放在本地或自有推理上，靠填满 GPU 批次把每 token 成本压下来。中等用量、可预测的工作负载适合专用 GPU 端点——无需拥有硬件、也不必承担完整的运维成本倍数，就能获得对利用率友好的吞吐量。突发型、低用量或不可预测的流量，以及任何需要前沿质量的内容，则留在按 token 付费的 BYOK API 上。

osFoundry 会自动处理真正能撬动盈亏平衡点的杠杆——量化、批处理和分层路由——并让同一份工作负载在本地、专用端点或通过 BYOK API 运行。于是你能在自托管胜出的地方拿到节省，而无需自己管理 CUDA、自动扩缩容或占空比计算。（我们的 [BYOK 成本拆解](/articles/byok-vs-managed-ai-cost-breakdown)涵盖了等式中的 API 一侧。）

Frequently asked questions

在多大的 token 用量下，自托管才比 API 便宜？: 这取决于利用率，所以没有单一数字。大致来说，在 GPU 得到充分利用时，每月数百万 token 就可能胜过高价 API；但要胜过廉价的预算型 API，则需要每月数千万到数亿 token。一个常见的经验阈值是每天持续数百万 token——低于这个水平，通常还是 API 更划算。
每月运行一台 H100 要花多少钱？: 在专业 GPU 云上，按需 H100 大约每小时 $1.50–3.00（超大规模云服务商更贵），因此一台 7×24 小时运行的专用实例每月约为 $1,000–5,000，具体取决于服务商档位。这笔固定成本需要你的 token 用量来填满，自托管才物有所值。
为什么 GPU 利用率对自托管的经济性至关重要？: 因为无论 GPU 是忙碌还是闲置，成本都是一样的。充分利用时，每百万 token 的成本可以降到一美元以下；在低负载（比如 10%）时，实际每 token 成本大约上涨十倍，往往使自托管比高价 API 还贵。闲置的 GPU 是纯粹的浪费——利用率是最大的单一变量。
自托管比预算型 API（如托管的小型模型）更便宜吗？: 通常只有在用量非常高时才如此。预算型 API 定价很激进，因此靠自托管超越它们，通常需要在良好利用率下每月数千万到数亿 token。相比之下，与高价 API 的交叉点会来得早得多。请与你实际会用的那个具体 API 比较，而不是某个通用费率。
量化能把自托管成本降低多少？: 相当可观。FP8 在几乎不损失质量的情况下将吞吐量提升约一倍，INT4 可提升约两倍，同时把模型压缩到能装进更小、更便宜的 GPU。对于大型模型，这可以把每百万 token 的成本砍掉一半甚至更多——量化是自托管中杠杆效应最高的成本手段之一。
自托管 LLM 有哪些隐藏成本？: 运维。除 GPU 账单外，你还要为 MLOps 工程（六位数年薪）、模型更新周期（每次数周工作量），以及推理服务器、驱动管理、自动扩缩容和监控买单。这些通常是原始硬件成本的数倍，也正是大多数粗糙的盈亏平衡测算所遗漏的部分。
我能把自托管和 API 结合起来以优化成本吗？: 能——混合方案通常是最明智的做法。把高且稳定的用量放在本地或自有推理上运行，把中等用量、可预测的工作负载放在专用端点上，把突发型或低用量流量（以及任何需要前沿质量的内容）放在按 token 付费的 API 上。按经济性路由，既能拿到自托管的节省，又不必为突发工作中的闲置 GPU 付费。