多数团队过早转向专用推理

预留容量方案感觉像是从共享推理的自然升级。它们提供可预测的性能、更少的共享舰队限制、稳定的模型版本以及私有权重支持。这些优势都是真实的。错误在于认为更高的流量意味着专用推理更便宜。

每月处理数亿 token 的工作负载仍可能低效地使用专用 GPU。工作负载可能会经历瞬间爆发且很快消失的请求。每日流量可能剧烈波动。GPU 可能在顺序代理步骤之间空闲等待。月度总量掩盖了这些空闲时段。

我们应该提出的问题不是：

“我们每月会处理多少 token？”

它是：

“在可接受的服务水平下，我们完成有用推理工作的付费 GPU 时间所占的百分比是多少？”

一个 无服务器推理 端点是一个托管的 API，应用程序使用它来提交推理请求，而无需预置 GPU 实例。

提供方负责：

• GPU 舰队
• 已加载且受支持的模型
• 请求路由
• 请求批处理（兼容请求）
• 共享容量的扩缩
• 推理软件更新
• 平台级安全与监控
• 替换失效的基础设施

无服务器使用通常按每百万输入和输出 token 计费。一些平台会单独收取 嵌入向量、缓存的 token、图像生成、音频或推理 token 的费用。无服务器并不意味着没有服务器。仍然有服务器和 GPU。关键区别在于客户不会预留或控制这些资源。

这种抽象将利用率风险转移给提供方。当您的应用没有流量时，通常不会对空闲 GPU 产生费用。

因此，无服务器推理不仅仅是一个原型产品。随着时间的推移但间歇性的大规模工作负载仍可将无服务器视为更佳的生产选择。较大组织内的虚拟助手、文档处理应用、批处理报告流程以及已建立的 SaaS 应用中的新功能都是符合此描述的工作负载示例。

DigitalOcean 无服务器推理 让您可以在其托管的 模型目录 中运行受支持的模型。与 Together AI 和 Fireworks AI 的无服务器产品类似，您需要牺牲一些模型和基础设施的灵活性，以换取按需付费的托管共享基础设施访问权限。限制在于模型支持。无服务器目录是一种托管基础设施。您不能在那里托管任意模型。如果应用需要私有检查点、修改后的分词器、不受支持的架构、自定义 CUDA 内核或特殊量化，共享服务可能不支持。

什么是专用推理端点？

专用端点在为特定客户或部署保留的 GPU 资源上托管模型运行。其他客户不会向该保留部署发送请求。

托管的专用端点不应被误认为是完全自托管的推理。使用托管端点时，提供方可能仍会管理集群、网络、存储、容器运行时、推理引擎、监控以及重启失败的节点。客户可以获得基础设施隔离和更大的配置控制权，而无需承担所有运营层的责任。

DigitalOcean 的专用推理，例如，管理模型存储、vLLM 推理、入口网络、自动伸缩基础设施、路由、并行性以及更多多节点推理逻辑。客户选择他们的 GPU 资源和副本数量，而平台则抽象掉大部分部署栈。

当自定义权重使专用推理变得值得时

在甚至考虑延迟或成本之前，您可以将模型和部署需求与 DigitalOcean 支持进行核对。通过 “自定义模型”，我们可以指许多事项：

1. 应用于现有基础模型的提示或系统指令。
2. 提供商训练的微调
3. 一个 LoRA 或另一种参数高效的适配器
4. 一个完整的微调检查点

在第一种情况下，您可能不需要自定义部署。您可以创建一个接受您的提示、系统指令、工具定义和应用端逻辑的 DigitalOcean Serverless Inference 端点，使用来自 DigitalOcean Model Catalog 的任何受支持模型。

其他情况可能需要 DigitalOcean Dedicated Inference。DigitalOcean 的 Bring Your Own Model，或 BYOM，功能允许您导入托管在 Hugging Face 或 DigitalOcean Spaces 存储桶中的受支持私有或微调模型。目前，BYOM 模型只能通过 Dedicated Inference 部署，而不能通过 Serverless Inference 部署。

DigitalOcean 会检查导入模型的架构、许可证、配置、分词器文件、格式和依赖项，以确认它们是否兼容。

下面，我们对 DigitalOcean、Together AI、Fireworks AI 和 Modal 在自定义模型推理方面的支持进行比较。这包括它们的模型部署方式、托管服务能力、模型限制以及在使用专用 GPU 容量时的冷启动权衡。

DigitalOcean 通过 Dedicated Inference 提供了一条从目录模型到受支持私有权重的托管路径。部署后，私有模型即可运营访问且自动具备经济性。客户需要保持足够高效的 GPU 利用率，以证明保留容量的合理性。

基于假设的示例

下面的示例仅作说明；它不是经过测量的基准。提供商的价格已根据公开的提供商文档在2026年8月25日确认，且可能会变化。截至撰写本文时，DigitalOcean 对一个NVIDIA H100 的专用推理收费为每 GPU 小时 4.41 美元。

将一个 H100 在 30 天的月份中持续运行会产生大约的基础设施成本：1×$4.41×720=$3,175.20。假设该端点在实际饱和状态下每分钟可以生产 100 个成功完成的任务，工作负载与基准测试规模相匹配。该端点的理论月处理能力为 100×60×720 = 4,320,000 个任务。

如果实际利用率为 8%，则该部署预计可完成 4,320,000 × 0.08 = 345,600 个任务。假设存储和网络成本可忽略不计，则其专用推理成本因此为：345,600 ÷ $3,175.20 = 每成功任务 $0.00919。

在 70% 利用率下，同一端点可完成 3,024,000 个成功任务，使基础设施成本降至每成功任务 $0.00105。GPU 价格未变。由于固定成本被分摊到远更多的成功工作中，有用的经济效益提升了约 8.75 倍。

这就是为什么仅根据 GPU 小时费率比较提供商是不够的。DigitalOcean 列出的 H100 价格为每小时 4.41 美元，而Together AI 将其单个 H100 副本的价格列为每小时 5.49 美元。Fireworks 按 GPU 秒计费对需求部署进行计费，并提供不同的部署形态。由于计费粒度导致的价格差异显然很重要；然而，利用率可以掩盖单价的微小差异。使用率低的 $4.41/小时 GPU 每个结果的成本可能高于使用率高的 $5.49/小时 GPU——甚至高于任一平台的无服务器推理。

因此正确的比较不是“tokens 与 GPU 小时”，而是在应用实际能够维持的利用率下，无服务器每成功任务的成本与专用每成功任务的成本。

使用利用率比较经济性

无服务器和专用端点采用不同的计费单位，因此直接比较它们的标价可能会产生误导。无服务器推理通常按 token 消耗计费，而专用推理则按分配的 GPU 时间计费。

无服务器推理成本

下面的公式根据 token 利用率和额外服务成本估算月度无服务器推理费用：

专用推理成本

月度专用推理成本可以通过下面的公式估算，其中变量包括分配的 GPU、运行时间、存储和网络费用。

此函数揭示了核心差异。无服务器定价通常随处理的 token 数量而变化。专用定价则随预配的运行时间而变化——即使端点未收到足够的流量以饱和底层硬件。

衡量每成功任务的成本

如果仅计算 token 或 GPU 小时，上述盈亏平衡计算就毫无意义。成本较低的端点可能会更频繁地失败，导致额外重试，或延迟过高。此时，我们可以使用更具可操作性的指标，如每成功完成任务的成本：

该指标考虑了模型推理、工具调用、检索和重试。因此，它衡量的是生成有用结果的成本，而不仅仅是发起请求的成本。

它还能防止两种常见的会计错误。第一种是仅凭生成 token 来宣称无服务器很便宜，却忽略了付费搜索、检索、重排和重试。第二种是通过理论最大吞吐量而非实际成功吞吐量来除法得出专用推理很便宜的结论。

分母应包含通过应用验收标准的任务。超时、无效的工具调用、模式违规或任务级评估器的错误都会消耗资源，但未产生成功结果。

两个模型每月可能各处理 3000 万个 token，但所需的部署方式可能完全不同。

应用 A 可能全天分散处理少量请求，负载相对恒定，模型保持持续活跃。应用 B 在大多数时间可能几乎空闲，但在每天的两次报告作业中会处理数百万个 token。虽然两者的月总流量可能相近，但应用 A 能够在预留容量上获得不错的利用率；而应用 B 则需在突发之间为空闲的 GPU 付费，除非它能够将部署停止或缩放至零。

为了了解您的流量形态，请测量：

• 每秒和每分钟的请求数
• 峰值并发数
• 中位数和最大并发数
• 输入和输出 token 的分布
• 零流量时间的百分比
• 每小时和每日流量模式
• 突发持续时间
• 排队时间
• 重试频率

仅凭每月的 token 量不足以选择端点。工作负载的时机、集中度和可预测性决定了无服务器或专用推理哪种更具经济性。

平均需求低且出现短暂峰值的工作负载可能不适合持续供给的专用容量。即使月总 token 量较低，只要具有可预测的基线，也可能是极佳的匹配。

Scale-to-zero 并不会消除这种权衡，只是把它转移到了其他地方。像 DigitalOcean 专用推理 这样的云服务提供商可以将所需的 GPU 节点数量降至零。像 Together AI 这样的定价模型允许部署要么缩放到零，要么在副本不再运行时停止计费。像 Fireworks 这样的框架允许最小副本数为零，但会警告冷启动时间取决于模型大小。Modal 默认将函数缩放到零，但会提醒用户 初始化大型引擎可能需要几分钟。

一个经济考量是：在空闲窗口期间节省的费用是否值得恢复备用容量所带来的延迟或可用性惩罚。交互式服务通常需要维持一个温备的最小副本。离线管道通常可以处理冷启动，并且还应考虑 DigitalOcean 批量推理。这可能比持续保持温备的端点或同步无服务器请求更合适。

专用端点有时会被宣传为“更快”，但“更快”过于笼统，无法支持生产决策。应查看完整的延迟分布，而不仅仅是单一平均值。

至少应测量：

• 首个 token 延迟
• token 之间延迟
• 每秒输出 token 数
• 端到端请求延迟
• 中位数延迟
• P95 和 P99 延迟
• 排队时间
• 超时率
• 冷启动频率

专用容量并不应仅因为中位延迟略低而购买。更大的好处通常是能够控制较慢的请求。预留空间和显式并发限制应能最小化排队，并帮助 P95 或 P99 延迟 保持可预测。

假设你有一个无服务器端点，其中位延迟为 1.2 秒，但 P99 为 12 秒。如果你正在构建交互式代理，该端点可能提供的用户体验不如一个中位延迟为 1.5 秒、P99 为 3 秒的专用端点。专用端点在典型请求上仅略慢，但在最慢的 1% 请求中要可预测得多。

这种效果在代理型应用中会被放大，因为单个用户任务可能需要数十次顺序模型调用。如果某些调用出现排队或容量相关的延迟，整个工作流的延迟可能变得不可预测。

基于这些原因，专用部署使团队能够预留性能空间并控制最大并发。因此，专用实例适用于以下场景：

• 语音助手
• 交互式编码工具
• 实时推荐系统
• 多步骤 AI 代理
• 具有合同延迟目标的面向客户的应用
• 缓慢响应会导致用户流失或收入损失的工作负载

如果你正在进行离线摘要、索引、评估或文档分类，可预测的尾部延迟可能不如无服务器推理的弹性和按使用付费定价重要。

提供商在基本经济方面的共识超过了其产品语言所暗示的。

DigitalOcean 不应声称自己独自发现了从无服务器到专用的进展。Together 和 Fireworks 在其文档中提出了类似的高利用率论点。DigitalOcean 可信的差异化在于其支持的 Model Catalog、BYOM 工作流、GPU 选择、托管的 vLLM 堆栈以及更广泛的云环境的组合，以便将推理部署在靠近应用服务和数据的位置。

仅在所需模型无法在无服务器目录中运行、观察到的利用率使每个成功任务的成本低于无服务器价格，或可预测的容量能够证明保留实例的空闲成本合理时，才转向专用推理。团队可以通过以下路径将该规则付诸实施：

1. 在需求和模型需求仍然不确定时，先从无服务器模型开始。
2. 测量任务成功率、令牌分布、并发度、P95/P99 延迟、重试次数以及零流量间隔。
3. 只有在证明提示、检索、工具架构或模型选择无法达到所需质量水平时，才进行微调。
4. 将候选自定义模型与最小的已配置专用端点进行基准测试。
5. 根据观察到的成功吞吐量计算成本，而非供应商宣传的最大理论吞吐量。
6. 将受控比例的生产流量发送到专用端点。
7. 仅在队列长度、尾部延迟和持续利用率表明需要时，才增加副本数。
8. 在适用的情况下，保留无服务器或批量推理用于溢出、实验、罕见任务或异步工作。

混合路由器可以将 可预测的基线流量发送到保留容量，同时将不规则的溢出流量发送到可互换的无服务器模型。这可能在不需要预配足够 GPU 以满足每天仅几分钟的理论峰值使用的情况下提供尾部延迟保护。最大的挑战是行为的一致性。不同的模型可能会生成不同的结构化响应、工具调用、安全决策或响应质量。后备路径本身也必须使用与主部署相同的生产套件进行测试。

团队应停止将专用推理视为成熟度的象征。保留 GPU 并不会使 AI 系统达到生产就绪水平。衡量这些 GPU 是否能产生可靠且有用的工作才是关键。他们还应停止使用以下捷径：

• 在未建模吞吐量的情况下，将无服务器令牌价格与专用 GPU 小时进行比较
• 在不理解流量集中度的情况下，分析每月令牌总量
• 使用理论吞吐量而非实际吞吐量来计算专用成本
• 忽略失败的任务和付费重试
• 仅基于中位延迟声称延迟优势
• 认为 scale-to-zero 能逃避冷启动后果
• 认为 BYOM 意味着支持任意架构或自定义内核

这些错误系统地倾向于过度配置。它们让专用推理在电子表格上看起来更便宜，而在生产环境中却更昂贵。

无服务器与专用的决策并不是一个所有因素权重相等的平衡清单。对于大多数团队，无服务器应保持为默认选择，直至有证据推翻它。

当应用需要受支持的私有权重、测量的需求使 GPU 高效利用，或可预测的 P99 延迟和预留容量足以证明闲置成本的合理性时，专用推理才具有吸引力。仅凭高月度 token 量本身并不能证明这些条件中的任何一个。

DigitalOcean 提供了一条合理的迁移路径：先从 Serverless Inference 中提供的模型开始，在受支持的自定义权重需要特定定制时，转向 BYOM 和 Dedicated Inference。您还可以根据观察到的需求扩展 GPU 节点，并对符合条件的异步工作负载使用 Batch Inference。Together AI、Fireworks AI 和 Modal 提供了不同的实现，大体上属于同一种权衡。因此，选择提供商时也应考虑模型兼容性、冷启动行为、服务控制、区域部署以及每个成功任务的成本等因素。

关键指标不是广告中的每 token 价格或每 GPU‑小时价格，而是在您的应用实际所需的延迟和可靠性下产生成功结果的成本。直到团队能够证明预留容量在此基础上具有优势之前，转向专用推理并不是优化，而是赌注——赌注未来的利用率终有一天能够证明今天的闲置 GPU 是合理的。

• DigitalOcean 无服务器推理概览
• DigitalOcean 支持的模型
• PagedAttention 和 vLLM 论文
• Hu等人，“LoRA：大型语言模型的低秩适配”