无服务器 vs. 专用 vs. 自托管 LLM 推理：自托管何时真正更便宜

• 在 GPU 利用率达到 22-48% 之前，无服务器推理比自托管 GPU Droplet 更便宜。
• 专用推理比自托管 GPU Droplet 贵 30%，使其盈亏平衡点上升到约 29% 的利用率。
• 默认使用无服务器推理；一旦 GPU 确实能保持忙碌，就迁移到 GPU Droplet。
• 不要猜测你的推理账单，要仔细测量。
• 为了“省钱”而购买或预留 GPU 却让其近空闲运行，比无服务器方案贵 2-4 倍，还要承受运维负担。

这里的每个数字都来自我们在 DigitalOcean 上的实际运行，使用 Qwen3-32B，涵盖两种真实工作负载形态：聊天形态（1000 token 输入 / 500 token 输出）和 RAG 形态（2000 token 输入 / 200 token 输出）。延迟通过公网从单一客户端测量；最大吞吐量数据则是在机器本身上测量，以免网络限制它们。

先说两个坦诚的注意事项。第一：自托管分支在 192 GB 的 MI300X 上以完整 bf16 精度运行，而托管分支则运行它们自己的构建，很可能是 FP8。因此精度并不匹配，这是本次对比的一个真实局限，而非刻意设计的选择。这个局限对自托管不利，而非有利，因为如果自托管也使用匹配的 FP8，成本很可能还会更低。第二：最高并发层级下的数字（峰值吞吐量、约 40 秒的尾延迟）来自单次运行，而非平均值。请将那些尾部数据视为近似值，而不是可以依赖的可靠测量结果。

所有原始数据和脚本都已发布，你可以自行重新运行。文中引用的价格为本次实验运行时的价格。在做出购买决定之前，请查看 DigitalOcean 的最新价格，因为价格可能会变化。

无服务器（DigitalOcean 无服务器推理）。你调用 API，按 token 付费。提供商负责 GPU、扩缩容等所有事情。你无需管理任何东西。

专用（DigitalOcean 专用推理）。你租下一整块 GPU 的容量，以托管端点的形式为你保持预热。你可以获得隔离性；提供商仍然负责运行这台机器。

自托管（DigitalOcean GPU Droplets）。你租用一块裸 GPU，自己运行模型服务器（更进一步，你可以直接购买硬件）。拥有最大的控制权，也承担所有责任。

从四个方面来评判这三种方式：成本、延迟、扩展能力，以及它们给你带来的运维工作量。

我们固定了模型（Qwen3-32B）和两种真实工作负载：一种生成大量文本的聊天形态，以及一种塞入大文档以生成简短有据回答的检索形态。相同的提示词、相同的流式客户端、相同的指标。唯一变化的是部署模式。

• 分支 A：DigitalOcean 无服务器推理
• 分支 B：DigitalOcean 专用推理（托管专用端点）
• 分支 C：在 DigitalOcean GPU Droplet 上自托管，租用裸 GPU 并自行搭建 vLLM，既使用现成镜像也完全手工搭建。

第一个差异在第一位用户到来之前就已经显现：你需要多长时间才能开始服务，以及计费从什么时候开始。

无服务器在几分钟内就上线了。获取一个 API 密钥，粘贴到你的应用中，你就能上线了，而且只在 token 流动时才付费。

对于单个请求，独占一块GPU显然更快。通过公共互联网以同样的方式测量，我们自托管的MI300X GPU Droplet上单个流大约跑到每秒50个token，首个token约0.6秒。共享资源池的无服务器推理，每个流会慢一些，大约每秒22个token，首个token接近1.5秒。由你控制的GPU在首个token上要快约2.5倍。

但这只是在负载较轻的情况下。将同一GPU推得更狠，吞吐量会上升，而延迟则会崩溃。

在32个并行请求时，体验仍然不错，端到端大约15秒。当并发请求超过100时，端到端时间突破30秒，然后到40秒，慢尾部变得极其糟糕。完全去掉网络，在机器本身测量，首个token的延迟会降到几十毫秒，但那是机器的原始上限，而不是用户实际感受到的。

一台MI300X在192个并发请求时峰值约为每秒2,389个token，但此时的端到端延迟会突破40秒。推到256个并发时，它会过度饱和：吞吐量实际上会下降。

记住这一点，因为它改变了自托管真正有回报的场景。

这是大家真正想要的数字，而且很容易搞错，所以我们按每个回答来计算，而不是按原始token。这里一个典型的聊天回答是输入1,000个token，输出500个。在无服务器推理上，这大约花费$0.0005，并且不会随着GPU的繁忙程度而改变。

租用的GPU则相反。无论是否工作，你按小时付费，因此每个回答的价格完全取决于利用率。这里有两件事经常被混淆：

• 占空比：GPU在一天中实际工作的比例。这决定了你的成本。
• 并发：你同时运行多少请求。这是用延迟换取吞吐量的旋钮。

让GPU在高并发下满负荷运行，一台MI300X每秒几乎能处理5个回答，每个约$0.0001，大约是无服务器的五分之一。但满负荷意味着40秒的响应。

所以有两个盈亏平衡点，而不是一个：

• 如果让GPU饱和（接受约40秒的响应），只需约22%的占空比就能做到盈亏平衡。
• 如果保持快速响应（端到端约15秒，c32工作点），盈亏平衡点则接近48%的占空比。

反直觉的是，饱和运行在较低利用率时就能实现盈亏平衡，而不是保持快速响应，因为更高的并发能从每个工作小时中榨出更多token。

无论哪种方式，信息都是一样的：一旦单个GPU稳定繁忙（一天中大约四分之一到一半的时间），它在价格上就胜过无服务器。远高于这个水平，价格要便宜好几倍。而保持繁忙不等于把它推向极限；只要GPU不空闲，你可以停留在快速响应的工作点，仍然在价格上胜出。

Dedicated Inference和自托管GPU Droplet运行完全相同的芯片，因此性能相同。Dedicated Inference每小时成本仅高出约30%，这将其盈亏平衡点从大约22%的占空比提高到约29%。这仍然是一个很低的门槛，但溢价纯粹是为了不必自己管理服务器。

至于直接购买硬件：诚实地建模（资本分摊到三年，加上电费），自有加速器仍然更便宜，一旦让它保持忙碌，成本只是serverless的一小部分。但有两个重要的星号。首先，你实际上无法购买单个MI300X；它们以八GPU服务器形式出货，所以这是一个说明性模型，不是你可以放在显卡上的真实价格。其次，只有当你持续多年保持该负载、前期有资金，并且（这部分没人计算成本）有人随时待命维护时，它才划算。对几乎每家初创公司来说，那个人的成本太高了。

这一切背后有一个定价说明：上面的自托管数据使用的是按需费率。长期承诺的预留GPU Droplet运行成本更低（12个月MI300X合约期约每GPU小时$1.49，而按需为$1.99），这再次降低了每个盈亏平衡点。只有当你能够承诺该期限时才有帮助，因此它恰恰奖励了自托管已经胜出的稳定基础负载场景。

做出购买决定前，请务必通过DigitalOcean当前费率确认价格，因为它们可能会变化。

默认使用Serverless Inference。在找到产品市场契合之前，流量尖峰且不可预测，它既是最便宜的选择，也是最省事的选择。空闲时基本不花钱，而且它会自动为你弹性扩容。

当你需要serverless无法提供的东西时，迁移到Dedicated Inference或自托管GPU Droplet：紧密可预测的延迟；隔离性和有保证的容量；或者必须留在你自己边界内的数据。注意这是一个控制权决策，而不是省钱决策。

一旦你拥有稳定、可预测的基础负载，让一块GPU全天候至少有四分之一到一半的繁忙程度，就去追求成本交叉点。那时它才真正比serverless便宜。先租后买：租用速度相同，成本低约30%，而且无需资本支出。

在所有内容前面放一个轻量网关，这样以后将热路径迁移到专用时，只是配置更改，而不是重写。

为了“省钱”购买或预留GPU，却让它接近空闲地运行。在大多数早期GPU实际看到的5-10%利用率下，这比serverless贵2-4倍，还要加上运维负担。

忘记预热和空闲账单。Dedicated Inference在我们获得任何服务之前就收取了25分钟的费用。一个孤儿GPU在我们以为已经关闭后仍在计费：端点从API中消失了，但其背后的MI300X droplet仍保持活跃并持续产生费用，直到我们手动删除它。

错误测量吞吐量。我们的第一次测试从笔记本电脑通过互联网运行，将GPU的真实吞吐量低估了约3倍。瓶颈是客户端和广域网，而不是GPU。我们不得不在droplet本身上重新运行负载生成器（localhost）来找到真正的上限。

在错误的基础上比较成本。 这一点很容易陷入。Serverless 提供给你的价格表会将输入和输出 token 分开计费，而租用的 GPU 只提供按小时计费，完全没有 token 核算，因此你必须自己算出每个 token 的成本。早期我们只根据输出 token 来计算，然后与同时收取输入和输出费用的 Serverless 价格进行比较。由于分母不匹配，导致 GPU 的每小时全部成本被加载到它实际处理的一部分 token 上，使自托管看起来比实际更昂贵。后来我们改为计算每个选项下完整答案的端到端价格（所有输入加输出 token），让两边统计的内容一致，从而修复了这个问题。

每次的修正方法都一样：诚实地对齐数字。如果你要做基准测试，就要从贴近实际环境开始进行饱和测试，并比较每个答案的成本，而不是每个原始输出 token 的成本。

在选择部署模型之前，先优化你的模型选择和利用率。默认使用 DigitalOcean Serverless Inference，一旦 GPU Droplet 真正保持繁忙，再迁移过去。不要猜测你的推理费用，要仔细测量。

如果你想在深入数字之前了解选择推理模式的更广泛概念框架，DigitalOcean 的推理模式比较指南从高层次涵盖了 serverless、专属、批处理和推理路由器。若要更深入地了解影响这一切的吞吐量/延迟/成本权衡，LLM 推理三难困境值得一读。