AI 推理引擎四大模式：无服务推理、专用推理、批量推理与智能路由，怎么选？

这是一份面向 AI 推理入门开发者和团队的实用指南，对比 Serverless、Dedicated、Batch 和 Inference Router 四种AI推理服务，帮你从AI开发的第一天起就做出明智的选择。

---

什么是 DigitalOcean 推理引擎？

这篇 DigitalOcean 推理模式对比指南，解释了如何根据延迟、成本和规模需求选择合适的模型服务方式。DigitalOcean 推理引擎 是 DigitalOcean 云平台内的 AI 推理层。它让你可以在一个地方运行大语言模型，从快速实验到生产级应用，服务成千上万的用户——无需管理 GPU 集群、推理服务器或复杂的编排层。

该平台包含四种不同的推理模式，每种都针对不同的发展阶段或工作负载类型设计：

本文将解释每种模式的作用、使用场景以及入门方法，并穿插真实案例。

无服务推理 Serverless Inference

按 token 计费，按模型计费

Serverless Inference 是最快上手AI大模型的方式。调用一个 API 端点，获得响应，然后只为你消耗的输入和输出 token 付费。无需配置 GPU、无需维护基础设施、没有人发送请求时也不会产生闲置成本。

它支持广泛的模型目录，从开源模型（如 DeepSeek、Llama、Qwen、Mistral）到商业模型（Anthropic 的 Claude 和 OpenAI 的 GPT）。当商业模型发布新版本时候，DigitalOcean 支持发布当天24小时内即可使用该模型最新版本（即Day0 支持）。

由于运行在共享基础设施上，负载增加时延迟可能会波动。对于大多数早期应用和实验场景，这通常是可以接受的。当你在规模化时需要更严格的延迟控制，团队通常会迁移到 Dedicated Inference。

最佳适用场景

• 原型验证和概念验证应用
• 不可预测或流量突增的场景
• 低到中等音量的生产工作负载
• 跨多模型的快速迭代
• 内部工具和演示

关键特性

• 零基础设施管理
• 可缩容至零，无闲置 GPU 成本
• 通过单一 API 端点访问大型模型目录
• OpenAI 兼容 API
• 集成 DigitalOcean 账单，无需单独对接供应商账户

快速开始

curl -X POST 'https://inference.do-ai.run/v1/chat/completions' \
  -H "Authorization: Bearer $MODEL_ACCESS_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gpt-oss-120b",
    "messages": [
      {"role": "user", "content": "Summarize this document in 3 bullet points."}
    ]
  }'

真实案例

一个两人的创业团队正在开发一款 AI 写作助手。他们不知道下个月会有多少用户。Serverless Inference 让他们今天就能发货，只为实际使用的部分付费，无需预留可能会闲置的 GPU。当流量增长到可预测的基础水平时，他们可以迁移到 Dedicated Inference 以获得更好的单位经济效益。

专用推理 Dedicated Inference

按 GPU 运行时间计费

Dedicated Inference 为你提供一个私有、单租户的 GPU 端点——一台 DigitalOcean 为你管理的云端专属推理服务器。没有其他人与你共享 GPU。你可以选择 GPU 类型（H100、H200、B300、MI300、MI325 等）、选择模型，获得一个完全属于你的专属 HTTPS 端点。

由于是单租户，不存在可能会干扰你的其他用户。延迟稳定且可预测。你可以配置并发限制、最大序列长度、投机解码和 LoRA 适配器等参数——这些在 Serverless 中是无法调优的。最重要的是，你可以自带微调或自定义模型，而 Serverless Inference 不支持这一点。

根据当前官方文档，Dedicated Inference 部署位于DigitalOcean在 ATL1、NYC2 和 TOR1 区域的数据中心。

定价模式从按 token 计费转变为按 GPU 小时计费。在高稳定流量下，Dedicated 通常比 Serverless 更便宜，因为你不再需要支付按 token 的溢价。在低流量下，你仍需为空闲时间付费。经验法则：如果推理持续且可预测地运行，Dedicated 通常在成本上胜出。

平滑迁移： 你可以在控制台中一键将在 Serverless Inference 上测试过的模型迁移到 Dedicated 端点。API 调用无需任何 schema 变更。

最佳适用场景

• 高容量、稳定的生产流量
• 延迟 SLA 很重要的用户面向应用
• 自定义或微调模型托管（BYOM）
• 需要隔离执行环境的数据隐私要求
• 完全控制 GPU 类型、区域和推理引擎参数

关键特性

• 单租户、私有 GPU 实例
• 无冷启动，始终保持热备
• 支持自带模型（BYOM）用于微调 LLM
• 通过加速器和节点配置控制扩缩容行为
• 独立的 DI 访问令牌（出于安全考虑，有意与通用 DO API 令牌区分）

快速开始

# 使用你的 Dedicated Inference 端点 URL 和 DI 访问令牌
curl -X POST '$DEDICATED_INFERENCE_PUBLIC_ENDPOINT/v1/chat/completions' \
  -H "Authorization: Bearer <your_di_access_token>" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "$MODEL_SLUG",
    "messages": [
      {"role": "user", "content": "Explain quantum entanglement simply."}
    ]
  }'

真实案例

一家 AI 原生 SaaS 公司有 15,000 名日活用户使用他们的代码补全产品。请求全天候稳定且可预测。按 token 计费在这种量级下很快就会变得昂贵。通过 Dedicated Inference，他们配置 H100，托管基于专有代码库训练的微调代码模型，并按小时费率支付。他们还配置了与流量曲线紧密匹配的并发限制——这在 Serverless Inference 中是不可能的。

批量推理 Batch Inference

成本显著低于实时推理

Batch Inference 适用于你有大量工作要做、但没有任何任务需要立即完成的情况。你不需要一个一个发送请求并等待每个响应，而是将所有内容打包成 JSONL 文件，作为单一任务提交，然后在完成后回来取结果，通常在 24 小时内。

权衡很简单：你放弃实时响应，换取更低的 token 成本。批处理流量运行在离峰 GPU 容量上，与实时推理隔离，不会影响你的在线应用。系统也具有容错能力。临时错误会自动重试，单个请求失败不会导致整个任务失败，如果任务中途被取消，所有已完成的请求都会被保存并计费。

当前模型支持： Batch Inference 适用于 OpenAI 和 Anthropic 的纯文本模型。开源模型、DO 托管模型、多模态和图像生成工作负载暂不支持。

最佳适用场景

• 大规模文档分类
• 隔夜数据富化管道
• 针对大型测试集运行模型评估套件
• 构建 RAG 知识库 索引
• 对大型文本语料库进行情感分析或实体提取

关键特性

• 每个任务文件最多 50,000 个请求
• 每个任务文件最大 200 MB
• 对 429 和 5xx 错误自动重试（最多 2 次指数退避重试）
• 通过轮询监控任务状态或配置 Webhook
• 支持续接任务以恢复部分完成的工作

三步工作流程

# 步骤 1: 请求预签名上传 URL 并上传你的 JSONL 文件
curl -X POST 'https://inference.do-ai.run/v1/batches/files' \
  -H "Authorization: Bearer $MODEL_ACCESS_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"file_name": "my_prompts.jsonl"}'

# 步骤 2: 创建批处理任务
curl -X POST 'https://inference.do-ai.run/v1/batches' \
  -H "Authorization: Bearer $MODEL_ACCESS_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "file_id": "<file_id>",
    "completion_window": "24h",
    "parameters": {
      "temperature": 0.2,
      "max_tokens": 1024
    }
  }'

# 步骤 3: 轮询完成状态并下载结果
curl 'https://inference.do-ai.run/v1/batches/<batch_id>' \
  -H "Authorization: Bearer $MODEL_ACCESS_KEY"

真实案例

一家法律科技公司需要对 200,000 个合同条款按风险类别分类。用前沿模型实时处理既昂贵又缓慢。他们将所有 200,000 条 prompt 准备成 JSONL 文件，在下班前提交批处理任务，第二天早上以实时成本的一小部分取回完全处理好的结果。如果有少量请求在夜间失败，他们只对剩余记录运行续接任务。

推理路由 Inference Router

你只需为所选模型的实际推理使用量付费

Inference Router 位于你的模型前方，自动根据任务类型、当前延迟和成本决定每个传入请求应由哪个模型处理。路由不再将每个请求都发送到最昂贵的前沿模型，而是将复杂度与能力匹配。

它构建在 Plano 之上——一个开源的 AI 原生代理。当请求到达时，一个轻量级路由模型在大约 200ms 内解析 prompt 的意图，然后使用持续刷新的实时成本和延迟数据对候选模型进行排名。一个简单的 FAQ 问题会被路由到快速、便宜的模型。一个复杂的多步推理任务会被路由到前沿模型。你只为每个任务实际需要的部分付费。

你可以从预设路由开始（常见工作流包括：软件工程、写作、一般问答、知识库、文档智能），也可以用纯语言描述定义你自己的任务类别，无需编写代码。实时仪表板显示选中了哪些模型以及频率，让你对路由决策有完全的透明度。

模型亲和性： 你可以使用 X-Model-Affinity 头发送会话标识符，将后续请求固定到同一路由模型，以获得更一致的 Agent 行为。

最佳适用场景

• 处理多样化、混合复杂度任务类型的应用
• 在不牺牲响应质量的情况下降低推理成本
• 希望自动选择模型但不想自己构建路由逻辑的团队
• 简单和复杂 prompt 混合的高容量应用

关键特性

• 每个请求约 200ms 路由开销
• 常见工作流的预设路由配置
• 使用纯自然语言定义自定义任务
• 实时成本和延迟指标仪表板
• 路由到 Serverless 和 Dedicated Inference 端点
• 使用模型访问密钥，与 Serverless Inference 相同
• Inference Router 目前处于公开预览阶段

快速开始

# 只需在模型名称前加上 "router:" 和你的路由器名称
curl -X POST 'https://inference.do-ai.run/v1/chat/completions' \
  -H "Authorization: Bearer $MODEL_ACCESS_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "router:my-custom-router",
    "messages": [
      {"role": "user", "content": "How do I reset my password?"}
    ]
  }'
# 路由器决定哪个模型回答，不是你

真实案例

一家开发者工具公司有一个 AI 助手，处理代码生成、文档编写和简单 FAQ 回答——三种复杂度截然不同的任务。没有路由器，每个请求都以高价打到前沿模型。有了 Inference Router，他们用纯语言定义任务类别。复杂的编码问题发送到强编码模型。FAQ 查询发送到小型、快速的开源模型。他们的月推理账单下降，而应用代码无需任何更改。

四种模式横向对比

如何选择使用哪种模式？

通过这些问题快速找到答案。

你需要立即得到结果，还是可以等几小时？ 如果可以等 → Batch Inference。这是批量工作最便宜的选择。

你是在原型设计、实验，还是早期开发？ 从 → Serverless Inference 开始。零配置、按需付费、访问所有模型。

你有高且可预测的生产流量和严格的延迟要求？ 升级到 → Dedicated Inference。私有 GPU 资源和稳定负载下更可预测的延迟。

你需要托管微调或自定义模型？ 唯一选择 → Dedicated Inference。BYOM 仅在此支持。

你发送的是简单和复杂请求的混合，希望自动降低成本？ 叠加 → Inference Router。智能路由在不更改应用代码的情况下降低成本。

典型演进路径

大多数团队遵循一条自然路径：

1. 从 Serverless Inference 开始 以验证想法。零承诺，按学习进度付费。
2. 随着流量增长且变得可预测，迁移到 Dedicated Inference。更好的单位经济效益和更严格的延迟控制。
3. 添加 Inference Router 以降低不断增长的模型组合成本。
4. 引入 Batch Inference 用于离线数据作业，如评估、富化管道和大规模分类。

你不必按顺序遵循这条路径。许多团队同时运行多种模式。一家公司可能用 Serverless 做聊天机器人，用 Dedicated 做微调的内部模型，用 Batch 做夜间数据管道，用 Router 协调一切。

指标和盈亏平衡清单

使用此清单决定是留在当前模式还是切换。

• 延迟目标： 如果你的 p95 延迟目标严格且未达标情况在增加，先测试 Dedicated Inference。
• 流量形态： 如果日流量不可预测或突发，保持 Serverless 作为默认入口。
• 每成功请求成本： 比较当前和预测流量下 Serverless token 支出与按小时 GPU 支出的对比。
• TTFT 和吞吐量： 如果首 token 时间和每秒 token 数未达到产品预期，基准测试 Dedicated 和 Router 策略。
• 工作负载类型： 将离线工作流转移到 Batch 以降低成本，为用户面向请求保留实时容量。

快速入门链接

四种推理模式现已在 DigitalOcean 控制面板中全部可用。

• 推理引擎控制台： cloud.digitalocean.com/model-studio
• 完整文档： docs.digitalocean.com/products/inference
• Serverless 快速入门： 使用 Serverless Inference
• Dedicated 快速入门： 使用 Dedicated Inference
• Batch 快速入门： 使用 Batch Inference
• Router 快速入门： 使用 Inference Router
• 定价详情： 推理定价
• API 参考： DigitalOcean AI Inference API

常见问题

1. DigitalOcean 上的 Serverless 和 Dedicated 推理有什么区别？

Serverless Inference 按请求计费、按 token 使用量计费，最适合可变流量和快速迭代。Dedicated Inference 运行在隔离 GPU 上按小时计费，更适合稳定的高容量工作负载、更严格的延迟控制和自定义模型托管。

2. 我什么时候应该从 Serverless 推理迁移到 Dedicated 推理？

当你的流量基础稳定、p95 延迟未达标反复出现，或月 token 支出持续高于预期按小时 GPU 成本时，进行迁移。使用类生产 prompt 的简短基准测试通常足以找到盈亏平衡点。

3. Batch 推理比实时推理便宜吗？

对于非交互式工作负载，通常是的。Batch Inference 异步运行，符合条件的 OpenAI 和 Anthropic 文本工作负载享受最高 50% 的折扣。如果任务被取消或过期，已完成的工作会被保留。

4. Inference Router 如何选择模型，支持 fallback 吗？

Inference Router 根据任务定义评估传入请求，并应用成本效率或速度优化等策略。如果所选模型不可用或被限流，fallback 模型可以自动接管。Router 目前处于公开预览阶段。

5. 我可以在一个架构中同时运行多种推理模式吗？

可以。许多团队使用混合模式：Serverless 处理突发流量、Dedicated 处理基线生产流量、Router 处理混合 prompt 复杂度、Batch 处理评估、富化和大规模分类等离线管道。

结语

选择正确的推理模式不是一劳永逸的决定，而是将每种工作负载匹配到正确运营模式的过程。从简单开始，衡量重要指标，随着产品和流量成熟，逐步演进到混合架构。

相关链接

• DigitalOcean 推理引擎官方文档
• Serverless Inference 产品页
• Dedicated Inference 技术深度解析
• 推理时代：DigitalOcean AI 原生云内部解读