为什么尖峰推理流量会破坏专用GPU算力模型

专用GPU处理突发的LLM推理流量，在胜过按令牌计费之前，需要先达到一个明确、可计算的吞吐量下限——持续每秒1,910个可计费令牌；该下限的推导及其等效利用率百分比将在本文后面展开。本文将这一下限应用于DigitalOcean上的llama3.3-70b-instruct，详细分析了三种具有明确小时分布的流量形态，并涵盖了突发工作负载实际会选择的三种容量模式：计划容量、带无服务器溢出的预留下限，以及纯无服务器。

标准建议是，高流量工作负载应从无服务器升级到专用容量。这一建议对于稳定流量是正确的，但对于突发流量则是不完整的，因为它将流量视为决定性变量，而真正的决定性变量是你是否提前知道GPU会在哪些小时处于忙碌状态。专用GPU只有在你能使其持续保持在下限之上的那些小时里才值得租用，而只有当你知道这些小时是什么时候，你才能恰好租用这些小时。真正不可预测的突发流量无法通过调度来规避；可预测的突发则可以。这一差异决定了专用GPU的账算得通还是算不通，而不是仅由峰谷比或月度令牌量的大小决定。

看清这一点最清晰的方法是保持流量完全相同，只改变你对它的了解。假设一个GPU每天满负荷运行8小时作为高峰，其余时间不工作。全天候持有该GPU，它每月的忙碌时间为33.3%（每天24小时中的8小时），低于本文后面推导出的46.9%交叉点，其每月成本为3,263.10美元，而相同令牌量的等效无服务器账单为2,318.37美元，亏损944.73美元。如果只在真正需要的8小时内租用这块相同的硬件来服务相同的工作负载，这些小时的费用为1,087.70美元，节省1,230.67美元，比等效无服务器成本便宜53.1%。同样的硬件，同样的工作负载，不同的账单。唯一改变的变量是你是否为你不需要的16小时付费，而让你避免为这些时间买单的唯一条件，就是提前知道该购买哪8个小时。

DigitalOcean自己的指南已经指出了这一区别。引自专用推理文档：

当你需要快速开始，而无需管理推理端点背后的任何组件，没有需要托管或优化的自定义模型，或者你的推理流量具有不可预测性或突发性时，请选择无服务器推理而不是专用推理。

本文对这一指导原则进行具体落地，而非提出反对意见：它为你提供了精确的吞吐量下限、该原则适用及需要更细致处理的场景原型，以及一旦你了解自身流量形态后应采用的容量模式。适用范围：本文涵盖 DigitalOcean H200 上以总token数（输入加输出）计费的 llama3.3-70b-instruct FP8。与流量形态无关的自托管决策、量化权衡和批次大小调优在配套成本框架中已有说明，不在本文讨论范围内。

• 自2026年8月1日起，DigitalOcean H200 GPU Droplet 与 H200 专用推理端点的价格均为每小时4.47美元，因此两者现在共享同一个盈亏平衡点：每秒1,910个持续可计费token，占实测4,071.6 tok/s总token上限的46.9%，即可击败定价为每100万token 0.65美元的 DO Serverless Inference。在该日期之前，GPU Droplet 的价格为每小时3.44美元，对应一个更低的36.1%独立阈值；如今两者之间的选择是运营层面的问题，而非财务问题。
• 打破专用GPU成本核算的关键在于可预测性，或者说缺乏可预测性：你无法提前预知GPU在哪些时段会处于繁忙状态。一块GPU处理相同的每日8小时峰值流量，若全天候持有则会亏损（平均利用率33.3%，低于46.9%的交叉点）；若仅在这8小时内租用（计费时间利用率100%）则会稳操胜券。决定成败的是可预测性，而非流量峰值的大小。
• 将峰值与谷值之比固定在10:1，仅改变月度流量，结论依然会发生变化，但费率调整后的利润空间朝着不利于专用GPU的方向发展：在原型1的规模下，serverless现在以27.5%的优势彻底胜出，而非此前近乎五五开的局面。在约3.5倍的流量下，只有单GPU的预留下限仍能击败纯serverless；2GPU下限和按峰值规模配置的纯专用方案现在都输给了serverless。仅凭比率从来无法决定胜负；起决定作用的是峰值首次超过单GPU上限时的流量规模，而在新费率下，必须超过该上限更大的幅度才能实现成本效益。
• 具有不可预测的2小时突发流量的消费类流量形态完全无法使用定时容量，尽管其突发时长足够短，若该负载的定时窗口可行，本来是值得构建的。定时调度要求提前知晓窗口时间；当突发可能出现在任意时段时，专用GPU覆盖它的唯一方式是持续运行，这又将该形态带回了14.8%利用率下限测试失败的境地。
• 定时容量——即仅在一个可预测的工作时间窗口内租用GPU，其余时间将流量路由到serverless——对于接近交叉点的B2B流量形态，相比纯serverless基准可节省37.3%的成本。在计入实际每日配置开销（30分钟的计费创建和销毁时间）后，节省幅度收窄至34.5%，且DigitalOcean从创建之时即开始对GPU Droplet计费，而非从就绪之时起计费。

本文中的每一项比较最终都归结为一个问题：给定一小时的GPU时间，平均每秒能否产出超过1,910个可计费令牌？低于这条线时，DigitalOcean Serverless Inference处理这些令牌更便宜；高于这条线时，专用GPU更便宜，且价差会随着利用率每增加一个百分点而扩大。

方法论：为什么使用可计费令牌总量

DigitalOcean对Serverless Inference上的llama3.3-70b-instruct统一定价为每100万令牌0.65美元，输入和输出价格对称。由于账单两侧的定价相同，可计费令牌总量（输入加输出）是用于比较Serverless支出与专用GPU吞吐量的有效通用单位，本文中的每个数字，在每次比较的两侧，计数的都是同一件事。这是本文做出的唯一方法论决策，在此仅作一次说明。

这一基础很重要，因为实测吞吐量锚点来自以1,024输入/1,024输出令牌比率运行的基准测试，而非必然代表您实际流量的比率。在该比率下，总令牌吞吐量为4,071.6 tok/s（2,036 tok/s输出加上大致相同的输入，在单个H200上运行llama3.3-70b-instruct FP8与vLLM 0.24.0测得的）。如果您自行运行该基准测试，在应用本文中的下限公式时，请使用Total token throughput (tok/s)行而不是Output token throughput (tok/s)行，因为下限是按每个可计费令牌来表述的。不同的输入：输出比率会改变预填充与解码之间的平衡，而不会简单地将该总数减半或翻倍。如果您的生产比率与1:1偏差较大，请先使用成本框架方法论部分中的测试工具对您自己的配置进行基准测试，再做判断，而不是只凭表面数值轻信1,910 tok/s的下限。

下限恒等式

此推导独立于吞吐量测量，仅取决于GPU的每小时费率和Serverless的每令牌费率：

floor_tokens_per_second = gpu_hourly_rate / (serverless_rate_per_token * 3600)

floor = 4.47 / ((0.65 / 1_000_000) * 3600)
print(f"{floor:,.0f} billable tokens per second")

Output
1,910 billable tokens per second

DigitalOcean H200 GPU Droplet 必须在计费周期内平均每秒维持 1,910 个可计费 token，才能使其每个 token 的成本低于 DO Serverless。低于该阈值时，每一秒额外的空闲容量都按全额 $4.47/小时 计费，且不产生任何 token 收益。

将下限转换为利用率百分比

将下限除以 GPU 实测的 token 总上限，即可得到百分比：

total_tps = 4071.6  # measured total (input + output) throughput, single H200
gpu_hourly = 4.47    # H200 GPU Droplet, effective August 1, 2026; also the current Dedicated Inference rate
serverless_rate = 0.65 / 1_000_000

floor = gpu_hourly / (serverless_rate * 3600)

print(f"H200 crossover (GPU Droplet and Dedicated Inference): {floor / total_tps:.1%}")

Output
H200 crossover (GPU Droplet and Dedicated Inference): 46.9%

在2026年8月1日之前，专用推理端点（$4.47/小时，包含托管服务栈）需要一个比原始GPU Droplet（$3.44/小时）更高的持续利用率下限，因为其$1.03/小时的管理溢价必须在相同的每token比较中赚回。自2026年8月1日起，GPU Droplet的费率上调至与专用推理相同的$4.47/小时（DigitalOcean，“即将到来的GPU定价更新”，发布于2026年7月21日），因此两个产品现在共享相同的46.9%交叉点，以及单个GPU每月$3,263.10的相同成本。现在两者之间的选择是运营层面的而非财务层面的：选择GPU Droplet自行管理服务栈，或者选择专用推理让DigitalOcean管理它，因为两者之间不再有任何成本溢价。除非另有说明，本文后续的每个原型和容量模式都将利用率与46.9%进行核对。

参考常量

本文中的每个数字都追溯到此表。舍入约定：全文使用4,071.6 tok/s和每月730小时，以便各表在分币级别上保持一致。定价反映了自2026年8月1日起生效的H200 GPU Droplet费率，该费率当时与现有专用推理费率趋同。

人们很容易把峰谷比当作驱动无服务器与专用决策的唯一数字：3:1的形态看起来对专用很安全，20:1的形态看起来显然不适合。但这种直觉经不起流量的考验。将比率固定在10:1，只改变每月的规模，正确的架构也会随之改变。

下一节中的B2B工作时段形态在8小时内以85%的利用率运行，在16小时内以8.5%的利用率运行，正好是10:1的峰谷比，其规模恰好使得一块GPU即可覆盖整个峰值。在该规模下，按8月1日后的GPU费率计算，纯专用方案（3,263.10美元）比纯无服务器方案（2,364.74美元）贵27.5%，这是无服务器方案的干脆利落的胜利，而不是几乎不分胜负。现在考虑一个同样具有10:1比率的工作负载（峰值12,215计费tok/s持续8小时，谷值1,221 tok/s持续16小时），将其规模扩大到峰值超过一块GPU的4,071.6 tok/s上限。在这一规模下，预留一块GPU并将溢出流量路由到无服务器的方案每月花费7,899.84美元，而纯无服务器方案为8,346.13美元，节省5.3%；相对于按峰值规模配置的纯专用方案9,789.30美元，则节省19.3%。相同的比率，更大的体量，胜出的架构仍然与原型1规模下的情况不同，但胜出模式的 margin 比费率调整之前更薄了，而且无论是2-GPU下限还是按峰值规模配置的纯专用方案都不再能胜过无服务器。比率本身并不能告诉你哪一方会胜出；起决定作用的是体量，具体来说，是体量是否将峰值需求推过了单块GPU的上限。

尖峰流量本身也并不意味着专用容量就不经济。可预测的尖峰可以通过调度来应对：仅为需要的时段预留GPU，与全天候运行相比，账单大约减少一半（在下面的容量模式一节中有详细计算）。真正打破这种计算的是不知道应该预留哪些时段。不可预测的尖峰——可以在任何时刻出现且没有任何预先信号——根本无法通过调度来应对，因为调度需要在窗口开启之前就知道它。让专用GPU覆盖真正不可预测的突发流量的唯一方式是持续运行并等待它到来，这迫使GPU回到了它试图避免的24小时平均利用率测试上。

这就是本文的核心论点：一块专用GPU只有在你能保持每秒超过1,910个计费token的时段才值得租用，而且你只能精确租用那些时段——并且只有当你事先知道这些时段何时到来时，你才能精确租用这些时段。流量按照你能指明的日程表出现尖峰，就是一个有调度解决方案的调度问题。没有预警就出现尖峰的流量则不是，无论尖峰相对于谷值有多大或多小。

下面的利用率是单块H200总token容量（4,071.6计费tok/s）的占比，按24小时进行时间加权。每种原型都有明确的逐小时形态，而不仅仅是平均值，因此你可以自行复现这些数字。流量形态是说明性的构造示例，选择它们是为了从两侧逼近交叉点，而不是来自任何实测数据集。它们是展示下限测试在一系列形态中如何表现的算例，而非你自己工作负载的先例。在采用这里的任何结论之前，请先分析你自己的逐小时分布。

原型1：B2B工作时间段

avg_util = (85 * 8 + 8.5 * 16) / 24
print(f"{avg_util:.1f}%")

Output
34.0%

这种形状的峰值速率为每日8小时3,461个可计费tok/s（占4,072 tok/s上限的85%），轻松低于单块GPU的上限，因此单个H200即可覆盖每小时的负载而不溢出。该形状34.0%的平均利用率比8月1日之后46.9%的交叉点低12.9个百分点，而serverless与专用容量之间27.5%的差距是明显的serverless优势，而非随机波动：按当前的GPU费率，这种仅限工作时段使用的形状已不再接近阈值。对于这种工作时段模式，真正的解决方案仍然是调度容量，这将在下一节中详细讨论，它比两种纯选项高出37.3%。

模式二：消费者病毒式传播高峰

avg_util = (2 * 0.90 + 22 * 0.08) / 24
print(f"{avg_util:.4f}")

Output
0.1483

在14.8%的平均利用率下，这种形态在无服务器上的成本比专用服务器便宜68.4%，是三种原型中差距最大的。仅凭这一差距，人们可能会建议像原型1围绕其8小时窗口调度那样，围绕这2小时的突发进行调度。但在这里无法做到这一点，原因正是本文的核心观点：预留容量在这里无济于事。只为繁忙时段租用GPU需要知道哪些时段是繁忙的。当突发可能发生在任何时间时，专用GPU覆盖它的唯一方法是持续运行，这又回到了这种形态未能通过的地板测试。

2小时的突发足够短，在这种负载下安排一个调度窗口通常值得构建，就像原型1的8小时窗口一样。区别完全在于原型1的窗口有已知的开始和结束时间，而这里没有。

原型3：稳定的API后端（对照）

avg_util = 75.0
monthly_tokens = avg_util / 100 * 10_700_164_800
serverless_cost = monthly_tokens * 0.65 / 1_000_000
print(f"{monthly_tokens/1e6:,.0f}M tokens -> ${serverless_cost:,.2f} serverless vs $3,263.10 dedicated")

Output
8,025M tokens -> $5,216.33 serverless vs $3,263.10 dedicated

这是诚实的锚点。在75%的平稳利用率下，远高于46.9%的交叉点，专用方案以37.4%的优势胜出，尽管这一差距相比费率调整之前已经收窄：更昂贵的GPU小时成本会侵蚀专用方案的优势，即使在利用率较高时也是如此。这种原型支持一个结论：专用基础设施是适配这种负载形态的正确工具。它并不支持对专用基础设施的更广泛指控；本文没有任何内容反对将专用GPU用于稳定、高吞吐量的工作负载，它只是主张那些无法保证持续最低使用量的流量，不应以专用方案为基准来规划容量。

一旦你了解了工作负载的形态，可供选择的架构有三种，而不是两种。

定时容量：应用于原型1

原型1的营业时间窗口是可预测的，因此这正是定时容量所针对的负载形态：仅在8小时的峰值窗口内租用GPU，其余16小时路由到无服务器。

与两种纯方案中较便宜的一种（全部无服务器）相比，定时容量节省了37.3%的成本。该数字假设计费的配置时间为零，但这并不现实：DigitalOcean从GPU Droplet创建之时起就开始计费，而不是从它完成启动并准备就绪之时。公布配置时间敏感性是为了让节省数字保持真实可信。

gpu_hourly = 4.47
serverless_rate = 0.65 / 1_000_000
total_tps = 4071.6
days_month = 730 / 24

gpu_cost = gpu_hourly * 8 * days_month
trough_tokens = 0.085 * total_tps * 3600 * 16 * days_month
trough_cost = trough_tokens * serverless_rate
scheduled_base = gpu_cost + trough_cost

for extra_min in (0, 10, 20, 30):
    extra_cost = gpu_hourly * (extra_min / 60) * days_month
    total = scheduled_base + extra_cost
    saving = (2364.74 - total) / 2364.74 * 100
    print(f"{extra_min:>2} min provisioning: ${total:,.2f}/mo, {saving:.1f}% saving vs. all-serverless")

Output
 0 min provisioning: $1,481.82/mo, 37.3% saving vs. all-serverless
10 min provisioning: $1,504.48/mo, 36.4% saving vs. all-serverless
20 min provisioning: $1,527.14/mo, 35.4% saving vs. all-serverless
30 min provisioning: $1,549.80/mo, 34.5% saving vs. all-serverless

该表并未计入预定时长容量架构在实际运营中的全部成本：每天需要构建和维护的创建-销毁自动化任务、每个时段开始时的冷端点、针对脚本中途失败后仍持续计费的孤立资源的拆除验证，以及时段开启时无法保证您所在区域有可用GPU容量的风险。以34.5%至37.3%的利润率来看，这些运营开销是值得承担的。

预留底量加无服务器溢出

只有当峰值需求超过单个GPU的容量上限时，这种模式才会与纯专用模式产生区别。原型1的峰值是3,461计费tok/s，而容量上限为4,072 tok/s，因此一块GPU就能覆盖所有时段，永远不会发生溢出，该模式也就退化为纯专用模式，成本为3,263.10美元。只有当峰值确实超过容量上限时，这种模式才会成为一个独立的选项。

更大的工作负载：峰值12,215计费tok/s持续8小时，谷值1,221计费tok/s持续16小时，每月计费token数为12.84B，峰值与谷值之比同为10:1，与原型1相同，但整体规模约为其3.5倍。

一块预留GPU胜出，其原因就是这个模式的核心决策规则。只要有需求，预留GPU就会以其满容量上限运行，绝不会为了制造溢出而被限制在容量上限之下，因此问题从来不是整个工作负载的平均情况如何。问题在于这块特定GPU自身的平均利用率是否超过46.9%的交叉线：

• 第一块预留GPU在整个8小时峰值期间以4,071.6 tok/s的容量上限运行，并且仍然在夜间独自扛起整个1,221 tok/s的谷值流量，因为谷值从未超过一块GPU能够处理的范围。它整个月的平均利用率为53.3%，高于46.9%的交叉线，因此它配得上自己的费率。
• 第二块预留GPU只会在8小时峰值期间运行，因为第一块GPU已经独自消化了全部谷值流量。这样最多只有33.3%的负载率，低于交叉线，因此即使整个工作负载大到看起来明显适合专用容量方案，第二块GPU仍然会亏钱。

这是对速率变更之前的边际 GPU 规则更清晰的说明。在之前的 $3.44/小时费率下，按峰值规模配置的纯专用方案（$7,533.60）甚至 2-GPU 下限方案（$7,340.77）都优于纯无服务器方案（$8,346.13）；这些选项之间的差异只是程度问题。在当前的 $4.47/小时费率下，只有 1-GPU 下限方案仍然胜出：纯专用现在花费 $9,789.30，2-GPU 下限方案花费 $8,844.57，两者都高于纯无服务器方案。边际利用率数据本身不变，GPU #1 仍然以 53.3% 的占空比运行，GPU #2 仍然以 33.3% 的占空比运行，因为这些取决于流量形态而非价格；但跨越临界点的缓冲已经缩小：GPU #1 的利用率目前超出临界点 6.4 个百分点，低于变更前的 17.2 个百分点。在越过下限的 GPU 之上再增加 GPU，现在比之前更可能输给无服务器方案。

不要把波谷水平本身当作需求。波谷本身并不需要维持 1,910 tok/s；预留 GPU 会优先填充，并占用它可用的最繁忙时段，因此重要的是边际 GPU 在整个月内的自身平均利用率，而不是波谷本身是否超过下限。

纯无服务器

只要另外两个条件都不成立，纯无服务器就会胜出，也就是说窗口无法被调度，并且没有任何单个 GPU 的边际利用率能超出临界点。原型 2 是一个干净的例子：它的突发短且不可预测，因此无法被调度；而且它从未产生足够的持续负载，哪怕一个预留 GPU 也无法使利用率超过 46.9%，因此预留下限方案也无济于事。对于这种形态，纯无服务器是正确的答案，而不仅仅是退路。

无服务器上的冷启动与突发延迟

成本并不是唯一的维度。无服务器用突发延迟换取弹性，而这种权衡正是专用容量可以提出的正当反驳。一个已经预热的预留 GPU，在突发尖峰时服务第一个请求的延迟与第十万个请求相同。无服务器端点则未必如此。

“冷启动”这个短语背后隐藏着两种不同的效应，它们需要分别测量，因为原因不同、缓解措施也不同：

• 空闲冷启动。 在安静期之后的第一个请求的首个 token 生成时间，此时权重可能需要暂存，容量可能需要调度。这是大多数人所说的冷启动，通过在意留白窗口后发单个请求来测量。
• 并发下的排队等待。 当突发流量到达的速度超过服务池接纳速度时，请求会等待被调度到批次中，而不是在到达时立即被服务。连续批处理使整体上高效，但单个请求的首个 token 时间反映的是它在队列中的位置，而不是模型的加载时间。其标志非常明显：多个请求在同一个墙钟时刻收到第一个 token，因此测得的时间到首个 token 会随着发送时间的上升而下降。

将两者混为一谈会产生误导数字。在空闲窗口后立即发出 32 个并发请求的测试，会同时测到两者，并把总数归因于冷启动。

在您自己的账户上分别测量它们：

• 低并发下的稳态首个 token 时间，作为基线。

报告百分位数而非平均值，并在任何突发数据旁边注明攀升形状，因为没有攀升过程的数字是不可复现的。在与端点相同的区域运行客户端。远程客户端会将其往返时间添加到每次测量中，并且对基线的抬高幅度大于对突发流量的影响，这会压缩你试图观察的比率。

本文不发布单一的突发延迟数值，因为该数字特定于账户层级、区域、模型和一天中的时段。上述协议才能使你自己的测量结果站得住脚。

本文的最低成本公式和实测吞吐量基准来自成本框架文章，该文章推导了专用GPU推理的通用有效每令牌成本公式。本文将该公式专门应用于流量可预测性，而非抽象层面的利用率。

该框架文章将其交叉点表述为72.2%，而本文现在表述为46.9%。截至本文撰写时，这一差距有两个独立原因，而非一个，仅重新定价无法弥合这一差距。第一个原因是令牌基数：框架文章基于输出令牌推导成本，使用基准测试的2,036 tok/s输出吞吐量，而本文基于可计费令牌推导成本，使用同一基准测试的4,071.6 tok/s总吞吐量，因为DigitalOcean Serverless对llama3.3-70b-instruct的输入和输出均计费。在基准测试1:1的输入输出比下，总吞吐量是输出吞吐量的两倍，因此按可计费令牌表示的阈值所对应的利用率，仅为按输出令牌表示的同一阈值的利用率的一半，这本身就解释了二倍的差异。第二个原因是定价日期：本文使用自2026年8月1日起生效的H200 GPU Droplet费率$4.47/小时，依据的是DigitalOcean的费率变更（DigitalOcean，“即将推出的GPU定价更新”，发布于2026年7月21日）；框架文章中已发布的72.2%数字早于该变更，截至本文撰写时尚未重新定价，因此仍反映之前的$3.44/小时费率。如果框架文章重新定价至$4.47/小时而不修正其令牌基数，其交叉点将上升至约93.8%（与本文前面专用推理数字背后的输出令牌基数数学相同），这将扩大而非弥合两篇文章之间的差距。在框架文章更新之前，请将其72.2%的数字视为在两个层面均已过时，并基于你自己当前的费率和自己的令牌基数重新计算交叉点，而不是试图调和两个已发布数字之间的差异。

一篇相关的DigitalOcean教程Serverless与专用及自托管LLM推理成本对比（2026年7月10日发布）在MI300X上对Qwen3-32B进行了评测，报告了22%至48%的占空比盈亏平衡。这与本文的46.9%交叉点不是同一个阈值，该交叉点现在同时适用于GPU Droplet和专用推理，两者不能直接比较：模型不同、GPU不同、每小时费率不同，而且那篇文章在抽象层面衡量占空比，而本文衡量的是流量可预测性是否能让您达到某个占空比。DigitalOcean 2026年8月1日的定价更新同时涵盖AMD和NVIDIA GPU Droplet，因此那篇文章定价所依据的MI300X费率也在该日期发生变化；出于与本文对自身与上述框架文章比较所提示的相同原因，在将其视为当前数据之前，请确认其22-48%的数字是否已重新定价。

关于将溢出流量从预留GPU路由到serverless的机制（如上述预留下限模式中所使用的），请参阅如何使用推理路由器。

本文将输入和输出token视为单一计费单位，因为DigitalOcean对llama3.3-70b-instruct的定价相同。这种对称性并不普遍。对于对输出收取额外费用的模型，成本基础会分裂，您工作负载的输入:输出比例将独立于其流量形状开始产生影响，这一点在Llama 3.3 70B输出token定价的隐藏成本中有所讨论。

对于突发性LLM流量，Serverless和专用哪个更便宜？

这取决于突发流量是否可预测，而不是取决于其规模大小。对于llama3.3-70b-instruct，专用GPU需要在其计费的小时内平均维持每秒1,910个可计费token，即单个H200上限的46.9%，才能以每100万token $0.65的价格击败DO Serverless Inference。如果您能恰好将GPU调度到流量超过该下限的时段，那么专用GPU在这些时段更便宜。如果繁忙时段无法提前预测，持续运行GPU来捕捉这些时段通常无法通过下限测试，此时serverless更便宜。

多大的持续吞吐量才能证明专用GPU的合理性？

对于运行llama3.3-70b-instruct FP8的DigitalOcean H200 GPU Droplet，在计费周期内持续平均每秒1,910个可计费token，是与DO Serverless Inference的盈亏平衡点。这占实测4,071.6 tok/s总token上限的46.9%，按GPU Droplet费率$4.47/小时（自2026年8月1日起生效）计算。H200 Dedicated Inference端点共享相同的$4.47/小时费率，因此也共享相同的46.9%阈值；在费率变更之前，GPU Droplet以$3.44/小时运行，阈值较低为36.1%，而Dedicated Inference为其托管服务溢价设置了单独的更高下限。

专用GPU能否缩容到零？

不能。DigitalOcean从创建之时起对GPU Droplet和Dedicated Inference端点计费，无论资源是在积极处理流量、空闲还是已关机，计费都会持续。关闭GPU电源不会停止计费。

混合设置是否总是省钱？

不能。只有在预留GPU自身的平均利用率在整个月内超过46.9%的交叉点时，带有serverless溢出的预留下限才省钱。一个在高峰期需要多GPU的工作负载并不能自动证明所有这些GPU都是必要的：在本文较大的工作负载示例中，第一个GPU达到53.3%的利用率，以$7,899.84的成本相对于纯serverless的$8,346.13赚回了其费率，而第二个GPU仅有33.3%的负载率则不能，将其加入后总成本升至$8,844.57，超过了纯serverless。在当前费率下，即使是按峰值规模配置的纯专用方案（$9,789.30）也输给serverless，所以这条规则比以往更严格：应逐GPU应用，而不是按工作负载平均值应用，并且不要因为一个GPU超过了下限，就认为增加更多容量是白拿的钱。

如何计算我自己流量的交叉点？

使用您自己的GPU每小时费率和提供商的每token费率计算下限恒等式：floor_tokens_per_second = gpu_hourly_rate / (serverless_rate_per_token * 3600)。将该结果除以您GPU实测的饱和总token吞吐量，得到百分比。请使用成本框架的方法论部分中的基准测试工具来测量您自己的饱和吞吐量，而不是复用本文中的4,071.6 tok/s数字，该数字特定于单个H200上llama3.3-70b-instruct FP8在1,024:1,024输入:输出比率下的情况。

什么是DigitalOcean无服务器推理速率限制？

两个不同的页面描述了两种不同的限制，两者都很重要。推理API参考规定每个OAuth令牌的固定限制为每小时5,000次请求和每分钟250次请求。推理限制页面则记录了随账户层级扩展的分层请求/分钟和令牌/分钟配额，从第1级的120 RPM和50万到75万TPM，直到第5级的4,500 RPM和350万到7000万TPM。在根据任一数字估算突发流量之前，请在控制面板的“资源限制”页面检查您的账户层级。

最可靠的来源是您自己的账户，而不是任何页面。每个无服务器推理响应都带有 x-ratelimit-limit-requests、x-ratelimit-limit-tokens-per-minute 和 x-ratelimit-limit-tokens-per-day 标头，每个标头都有对应的 remaining 和 reset 值。在估算突发流量之前，请从这些标头中读取您的实际配额；如果它们与文档不一致，请以它们为准。

本文介绍了在DigitalOcean H200上运行llama3.3-70b-instruct的一个决定性数字：GPU Droplet需要每秒1,910个持续计费令牌（为其测量上限的46.9%），才能在每100万令牌0.65美元的价格下击败DO无服务器推理。文章将该下限应用于三种流量原型（工作时间、病毒式尖峰和稳态）以及三种容量模式（计划容量、带无服务器溢出的预留下限、纯无服务器），并通过8小时每日峰值示例表明，同一GPU处理相同工作负载时，全天候持有会亏损，而仅在需要的小时内租用则能果断获胜。在所有案例中，决定结果的关键从来不是尖峰的规模，而是你是否提前知道GPU会在哪些小时处于繁忙状态。

对于估算您自己的流量，有两件事需要遵循。在单独相信峰值与谷值比率之前，请先检查流量是否低于单个GPU的上限：保持10:1的比率不变并扩大流量，仍然会改变正确的架构选择；但按照当前GPU费率，较大工作负载的两种多GPU选项——按峰值规模配置的纯专用方案和2-GPU预留下限方案——现在都输给了纯无服务器方案；只有单GPU预留下限方案仍然获胜，但利润率比费率变化前更薄。此外，先按可预测性排序，再按规模排序：一个可预测的工作时间尖峰和一个不可预测的病毒式尖峰，规模相近，却会落在决策的两端——一个可以通过计划调度节省37.3%的成本，另一个则完全无法调度，因为调度需要在窗口开启之前就知道它。

你还可以参考我们 生产环境中的推理 系列中的以下教程来入门：

1. 你的 LLM 账单为什么是预期的 3 倍
2. 如何为推理用例选择正确的 LLM 模型
3. 实践中的提示缓存：从 7% 到 74% 的命中率
4. 多提供商 LLM 路由不是问题，而是你的架构

• 专用 GPU 上不同流量特征下的 Token 经济学 — 推导出了每 Token 有效成本公式和基准测试工具，本文的 1,910 tok/s 基线正是建立于此之上。
• DigitalOcean 推理模式对比（针对你的每种用例） — 比较了无服务器、专用、批处理和推理路由器模式，以便你可以在进行基线计算之前将托管选择与流量特征相匹配。
• 无服务器 vs. 专用 vs. 自托管 LLM 推理：自托管何时真正更便宜 — 测量了不同模型和 GPU 上的工作周期盈亏平衡点，可作为与本文 46.9% 交叉点的交叉验证。
• 规模化时的专用推理与无服务器推理 — 涵盖了当可预测的基线证明在容量增长时从无服务器迁移到专用容量是合理的情况。
• 使用推理路由器进行多模型 API 成本治理 — 展示了如何跨模型层级路由溢出流量，这是本文预留基线模式中的无服务器侧。
• 无服务器推理中重要的指标 — 解释了在根据无服务器速率限制或 SLA 确定突发负载规模之前，应测量哪些延迟、吞吐量和成本指标。
• 为什么同一模型上的无服务器推理一致性会变化 — 对空闲冷启动和队列等待行为进行了基准测试，上文“突发延迟”部分建议你自行测量这些行为。
• Llama 3.3 70B 输出 Token 定价的隐藏成本 — 介绍了当输入:输出定价不对称会改变基线计算，使其超出本文使用的总 Token 计费基础的情况。
• LLM 推理中的连续批处理与静态批处理 — 解释了连续批处理如何影响饱和吞吐量，1,910 tok/s 基线正是以该饱和吞吐量为上限的百分比。