多模型路由怎么选？2026 年 4 款主流方案对比

随着 AI 应用开始同时接入 GPT、Claude、Qwen、Kimi、GLM 等多个大模型，越来越多团队会遇到同一个问题：到底该让哪个模型处理哪类请求？

一个客服 Agent 可能会用成本更低的小模型回答简单问题，用视觉模型处理图片，在复杂推理任务中切换到能力更强的模型，并在某个 API 出现故障时自动调用备用模型。

真正麻烦的地方在于，如果把这些模型选择、成本控制和 Fallback 逻辑全部硬编码到应用代码里，维护成本很快就会上升。新模型不断发布、Token 价格变化、接口限流、延迟波动，都会让原本简单的模型调用逐渐变成复杂的路由系统。

**多模型路由（Multi-model Routing）**就是为了解决这个问题而出现的。

它把"这次请求应该交给哪个模型"从业务代码中抽离出来，变成一个独立的路由层。你可以按照任务复杂度、模型能力、成本、延迟或可用性定义策略，由路由层负责模型选择、负载均衡、Fallback 和监控。

目前比较典型的多模型路由方案大致可以分为三类：托管式多模型路由、多模型 API 平台、自托管 LLM Gateway，以及云平台原生路由。

本文重点对比 DigitalOcean、OpenRouter、LiteLLM 和 Amazon Bedrock 这 4 种方案。它们代表了四种比较典型的技术路线：托管式智能路由、大模型聚合平台、自托管模型网关，以及大型云平台原生路由。

什么是多模型路由？为什么 AI 应用开始需要它？

多模型路由位于应用和语言模型之间，负责决定每一个进入系统的请求应该交给哪个模型处理。

在构建 LLM 应用时，通常不存在一个模型能够在成本、延迟、推理、编程、视觉和 Tool Calling 等所有维度同时做到最好。

如果应用直接调用一个固定模型，那么无论请求简单还是复杂，都只能使用同一种模型能力和价格。

加入多模型路由层后，流程会变成：

应用 → 多模型路由层 → 选择模型 → 执行请求 → 返回统一响应

路由层先分析 Prompt 或匹配预设规则，再从候选模型中挑选更适合当前任务的模型，把请求发送出去，并以一致格式返回结果。

这个过程通常叫做 Multi-model Routing、LLM Routing 或 Model Routing。

它最大的价值，就是让应用可以灵活使用多个模型，而不是长期绑定某一个模型。

选择 AI 推理架构时，也不能只看支持多少模型。具体可以咨询 DigitalOcean 中国战略合作伙伴卓普云的技术团队，帮助你的团队判断模型、推理服务和路由能力应该如何组合。

智能模型路由和 AI Gateway 有什么区别？

智能模型路由和 AI Gateway 经常被放在一起讨论，一些产品甚至同时提供这两类能力，但两者侧重点并不完全一样：

智能模型路由主要负责模型选择，也就是根据任务类型、成本、延迟和可用性，决定每个请求应该交给哪个模型。
AI Gateway / LLM Gateway则是更广义的控制层，除了路由，还可能提供统一 API、认证、权限管理、限流、可观测性和安全策略。

对比维度	智能模型路由	AI Gateway / LLM Gateway
核心功能	决定每个请求发送到哪个模型	集中管理进入不同模型平台的请求
主要用途	模型选择、请求路由	统一访问、控制、监控和策略执行
判断条件	任务类型、模型能力、成本、延迟、可用性、优先级	平台规则、负载均衡、Rate Limit、预算、安全策略、Fallback
实现方式	可以作为独立路由层存在	通常可以把多模型路由作为其中一项功能

因此，如果只是需要"根据任务自动选模型"，智能模型路由就是核心。

如果还需要管理 API Key、预算、日志、安全和访问控制，那么更接近 AI Gateway 的需求。

这也是为什么 DigitalOcean Inference Router、OpenRouter、LiteLLM 和 Amazon Bedrock 虽然都可以放进"多模型路由"这个大类里，但它们解决问题的方式并不完全一样。

没必要让每一个 Prompt 都支付前沿模型的价格。可以进一步了解推理路由如何把简单请求交给成本更低的模型，把复杂推理任务交给能力更强的模型，从而控制整体推理开销。

多模型路由是怎么工作的？

多模型路由处理一个请求时，基本都会经历这样一条流程：

读取 Prompt → 判断任务或规则 → 筛选模型 → 应用路由策略 → 转发请求 → 必要时 Fallback → 返回响应

其中最关键的问题，是路由层如何判断请求应该交给谁。

基于规则的路由通常根据关键词、模型名称、Header 或预设业务条件判断。例如，Prompt 里出现特定任务标签，就把请求发送给某个模型池。

智能语义路由则会分析 Prompt 的实际含义和意图。即使用户用了不同表达方式，只要背后的任务相同，也可以路由到同一类模型。

完整流程通常包括：

接收请求：应用通过统一 API，把 Prompt、System Instruction、模型参数、Tool 和相关上下文发送给路由层。这样不需要在业务代码里分别集成每一个模型平台。
语义意图或规则分析：路由层可以判断任务类型、所需能力和输出格式，也可以按照模型名、Header、业务标签等规则进行匹配。智能语义路由还可能把 Prompt 转换成 Embedding，再与"编程""客服""信息提取"等预定义任务描述进行匹配。
筛选候选模型：根据请求要求，从模型池里过滤不合适的模型。例如，排除不支持 Tool Calling、结构化输出、视觉输入，或者无法满足上下文窗口要求的模型。
执行路由策略 ：对剩余模型排序。判断条件可能包括任务适配度、质量、Token 价格、响应延迟、负载，以及人工指定的优先顺序。DigitalOcean Inference Router 提供预设路由策略，同时支持进一步配置自定义任务层、模型池和策略。
转发模型请求：把请求发送给当前排名最高、最适合的模型或目标端点。路由层还可以在不同 API 格式之间完成转换，让应用始终调用统一接口。
自动 Fallback：如果首选模型不可用、发生错误或者触发限流，可以自动重试或切换到备用模型，不需要在应用代码中为每个端点分别实现 Failover。
返回结果并记录指标 ：路由层将模型响应返回给应用，同时记录实际模型、Token 使用量、成本、延迟、错误、路由判断和 Fallback 情况，用于监控和后续策略优化。

这也是为什么多模型路由越来越像一项基础设施能力，而不只是简单的模型选择功能。

如果还想进一步降低模型成本，可以参考 LLM 推理优化，了解如何围绕成本、延迟和可用性调整整个推理链路。

为什么 AI 应用需要多模型路由？

多模型路由的核心价值，是让应用能够使用多个模型，而不需要把每一个模型选择都硬编码到业务逻辑中。

它主要可以解决下面几个问题：

降低 LLM 推理成本：简单分类、摘要和提取任务可以交给便宜的小模型，复杂推理再调用前沿模型，从而避免所有请求都按照最高模型价格付费。
降低响应延迟：对于延迟敏感的请求，可以优先使用速度更快的模型；当某个平台负载过高时，也可以暂时绕开。
提高模型与任务的匹配度：编程、摘要、推理、信息提取和视觉等任务，本身就可能适合不同模型。智能语义路由能够根据 Prompt 的含义自动做这种选择，规则路由则可以按照业务预设进行分发。
通过 Fallback 提高可靠性：首选模型限流或不可用时，可以自动切换到备用模型，让单个模型故障不至于直接演变成应用故障。
简化多模型管理：通过统一路由层管理多个模型，比在应用里维护多套独立 API 集成更容易修改策略、测试模型和切换底层模型。

LLM 推理中的各种权衡始终存在。比较合理的方式，是先用自己的生产请求做 Benchmark，再围绕真正需要优化的质量、延迟和成本指标调整模型组合。

多模型路由方案怎么选？重点看这 6 个指标

选择多模型路由方案时，不能只比较谁支持的模型最多。

真正进入生产环境之后，模型覆盖、Fallback、路由开销、成本透明度和可观测性往往同样重要。

可以重点看下面 6 个方面：

部署模式与基础设施范围：先确定你需要的是托管式智能 Router、自托管 LLM Gateway，还是云平台内部的原生路由。DigitalOcean 和 Amazon Bedrock 更接近平台原生托管能力，OpenRouter 是独立的多模型平台，而 LiteLLM 需要自行部署和维护。
模型覆盖范围 ：确认是否支持业务真正需要的模型，例如 OpenAI、Anthropic、Qwen、Kimi、GLM、DeepSeek 等，以及能否使用自己的 API Key。DigitalOcean 可以通过一个模型访问密钥调用其模型目录，同时支持自带 OpenAI 和 Anthropic API Key。
路由策略与 Fallback 能力：确认系统是按照成本、速度、任务语义、固定规则还是人工优先级进行选择，以及模型故障之后怎么切换。
延迟和可靠性：任何路由层都会多经过一层处理，因此最好用真实流量测试额外路由开销，而不是只看厂商 Benchmark。
成本透明度：确认路由层本身是否额外收费、模型费用如何计算，以及是否能对不同任务、模型和项目做清晰的成本归因。
可观测性与治理 ：生产环境最好能够看到路由日志、模型选择、Token 用量、延迟和错误。DigitalOcean 还支持带权限范围的模型访问密钥以及 Droplet 云服务器（VPC）限制，用于凭证隔离和私有网络访问。

如果应用里存在大量重复上下文，还可以进一步了解 KV Cache如何减少解码过程中的重复 Attention 计算，在不更换模型的情况下进一步降低每 Token 成本、提升吞吐量。

2026 年 4 款主流多模型路由方案对比

本文中的价格和功能信息基于截至 2026 年 8 月公开文档，不同地区和工作负载下可能有所变化。所有价格，包括免费额度，都受相关条款约束。最新价格与可用情况请以各平台官方文档为准。

*文中"更适合的场景"属于根据公开第三方评论和社区用户体验做出的判断，不代表经过独立验证的事实、完整数据或最终产品评价。

这 4 款产品正好代表了目前几种比较典型的多模型路由路线：DigitalOcean 把智能路由直接集成到推理平台；OpenRouter 更强调通过统一 API 聚合大量模型和底层推理平台；LiteLLM 让团队自己部署和掌控 LLM Gateway；Amazon Bedrock 则把智能 Prompt 路由集成在 AWS 自己的 AI 平台内部。

方案	更适合的场景	核心功能	类型
DigitalOcean Inference Router	希望少运维，同时按任务、成本和速度调用多个模型的 AI 团队	任务感知路由、可配置策略、自动 Fallback、统一推理平台	托管式智能路由
OpenRouter	希望通过一个 API 快速访问大量模型	多模型目录、Auto Router、Provider Routing、Fallback	多模型平台 / Router
LiteLLM	希望自己掌控模型 Gateway 和多平台 API 的团队	OpenAI 兼容 Gateway、负载均衡、Retry、Fallback、成本管理	自托管 LLM Gateway
Amazon Bedrock	已经深度使用 AWS Bedrock 的企业	Prompt 感知模型选择、AWS 原生集成、质量与成本优化	云平台原生智能路由

托管式多模型路由

托管式多模型路由通过统一端点提供跨模型选择能力。

它们可以根据任务类型、成本、延迟或可用性选择模型，并在首选模型失败时自动执行 Fallback。

对于希望直接获得生产级多模型路由能力，又不想自己搭建 Gateway 的团队，这类方案比较直接。

DigitalOcean 推理路由器：托管式多模型智能路由

DigitalOcean 推理路由器是 DigitalOcean 推理引擎中的托管式路由层。

它的核心思路是通过 Task、Model Pool 和 Selection Policy，把不同类型的请求分发到不同模型。

相比单纯按照模型名或者固定权重转发请求，它可以结合任务描述判断请求属于哪类任务，再在对应模型池中按照成本、速度或者人工优先级选择模型。

这意味着，一个应用不需要把所有请求都交给同一个大模型。例如简单分类、摘要可以优先使用成本更低的模型，而复杂编程或推理任务再交给能力更强的模型。

由于 Router 和 DigitalOcean 上的模型、数据库、存储都处在同一个平台内，可以减少跨云数据出站，以及额外维护多套平台关系所带来的管理成本。

已有推理请求只需要把模型名称替换成 Router 名称，就可以接入路由能力，应用层改动较小。

DigitalOcean 核心功能：

提供适用于软件工程、写作等场景的预设策略，也支持自定义路由。通过自定义 Router，可以定义任务描述、候选模型池，以及优先最快、最低成本或者人工排序模型的策略。
支持 Fallback，同时可以在 DigitalOcean 的模型 Playground 中，通过实时分析面板比较 Router 和单个模型在自己数据集上的表现。
可以访问 70+ 模型。同时支持通过 BYOM 把 DigitalOcean Spaces 中的自定义模型，或者需要权限访问的 Hugging Face 模型导入模型目录。

DigitalOcean 的推理服务按照 Token 计费，不同模型价格不同。目前支持 Kimi K3、GLM 5.2、Claude Fable5、GPT-5.6 等不同模型，不需要分别维护多套 SDK、鉴权和调用逻辑，只需要在同一个推理接口中切换模型即可。具体最新价格可咨询卓普云。

Hippocratic AI 在该平台运行对安全要求较高的医疗 Agent，并使用 DigitalOcean 推理路由。根据公布的数据，在超过 2,000 万次患者交互中，其生产吞吐量提升一倍，同时 P99 延迟降低 40%。

OpenRouter：一个 API 访问数百个模型

OpenRouter 是一个托管式多模型 API 平台和路由服务，通过单一 OpenAI 兼容 API 提供对大量模型的访问。

它和 DigitalOcean Inference Router 的侧重点并不完全相同。

OpenRouter 最大的优势之一，是可以通过一个统一 Endpoint 访问大量不同模型，并在同一个模型背后的不同推理平台之间做 Provider Routing。

它可以在多个底层平台之间路由同一个模型，并在某个端点不可用时自动切换到其他端点；同时也提供 Auto Router，根据请求情况自动选择模型。

因此，OpenRouter 实际上同时解决了两个问题：

"我要调用哪个模型？"

以及：

"这个模型应该由哪个底层推理平台来提供？"

不过，上游平台出现故障、Rate Limit 或 Endpoint 变化时，仍然可能影响请求。同时，由于不同底层平台支持的 API 参数并不完全相同，不同 Endpoint 上的功能表现可能存在差异。

另外，Prompt 最终会发送到路由层选中的底层平台，而不同平台拥有各自的数据保留和模型训练政策，这也是生产环境需要额外考虑的一项因素。

OpenRouter 核心功能：

通过统一 API 访问大量模型，可以按照 Prompt 价格、Context Length 和延迟筛选模型。
支持 Auto Router，根据 Prompt 和模型能力自动选择模型。
支持 Provider Routing，在提供同一个模型的不同底层平台之间选择。
支持 Model Fallback、BYOK 和平台筛选。

如果团队的主要目标是快速测试大量模型，或者不想分别维护多个模型 API，OpenRouter 的门槛比较低。

但如果应用、数据库、向量数据库等基础设施都部署在另一家云平台，生产环境还需要考虑模型调用过程中的网络链路、跨平台数据传输，以及多套平台账号和费用管理。

自托管 LLM Gateway

托管式 Router 的优势是部署简单，而另一条路线是自己掌控整个多模型 Gateway。

这种方式控制权更高，但同时也意味着团队需要自己负责部署、扩缩容、监控、升级和高可用。

LiteLLM：适合自托管 LLM Gateway 和多模型路由

LiteLLM 是一个开源 AI Gateway 和 Router，可以在外部模型平台、云 Endpoint 和自托管模型之间路由请求。

它在模型栈前面增加一个 OpenAI 兼容 API，让应用在切换底层模型和平台时不用修改原有调用方式。

例如，业务代码可以始终面对 LiteLLM：

复制代码

应用
 ↓
LiteLLM
 ↓
 ├── OpenAI
 ├── Anthropic
 ├── Amazon Bedrock
 ├── Azure OpenAI
 └── 自托管模型

LiteLLM 可以部署在自己的云环境、Kubernetes 集群、本地数据中心，甚至 Air-gapped 环境中。

需要注意的是，LiteLLM 本身默认并不提供底层模型推理能力。

也就是说，它解决的是"怎么统一管理和调度这些模型 API"，但真正的大模型推理仍然由 OpenAI、Anthropic、Bedrock、自托管 GPU 等底层 Endpoint 完成。

因此，你仍然需要自己维护不同模型平台的账号、API Key 和费用。

它提供的路由控制能力很丰富，但 Gateway 的部署、配置和运行都由团队自己负责，因此也会增加一定运维成本。

LiteLLM 核心功能：

OpenAI Compatible API；
多模型和多平台接入；
Load Balancing；
Retry、Cooldown 和 Fallback；
Virtual Key 和支出追踪；
支持自托管。

LiteLLM 更适合已经有平台工程或者 DevOps 能力，希望完全掌控模型流量入口的团队。

相比直接使用托管式 Router，这种方案最大的优势是控制权；最大的代价则是 Gateway 本身也成为了一套需要维护的生产基础设施。

云平台原生多模型路由

另外一类方案，是大型云平台直接把模型路由集成进自己的 AI 服务。

这类产品的特点是：

路由能力和云平台本身的模型、IAM、网络、监控和账单体系深度集成。

优势是对于已经重度使用这家云平台的企业来说，集成非常自然。

缺点则是模型范围和路由能力往往受限于该云平台自己的 AI 生态。

Amazon Bedrock：AWS 原生智能 Prompt 路由

Amazon Bedrock Intelligent Prompt Routing 是 AWS 在 Bedrock 中提供的智能模型选择能力。

它可以分析请求，并从候选模型中选择更适合当前 Prompt 的模型，以平衡质量和成本。

从思路上看，它与 DigitalOcean Inference Router 都属于"把模型选择交给平台"的方案。

但两者的模型选择范围并不完全一样。

Amazon Bedrock 的一个比较明显的边界是：路由主要发生在 Bedrock 支持的特定模型系列内部，而不是在任意不同模型生态之间自由选择。

因此，它更加适合这种情况：

团队已经确定使用 AWS Bedrock，并希望进一步降低同一模型系列中的推理成本。

而不是：

先接入大量不同模型，再根据不同任务自由构建模型池。

Amazon Bedrock 核心功能：

AWS 原生；
托管式路由；
Prompt 感知模型选择；
在质量和成本之间做自动权衡；
和 Bedrock 基础设施深度集成。

如果整个 AI Stack 已经运行在 AWS Bedrock 中，这种方式可以减少自己开发模型选择逻辑的工作。

但如果企业还希望大量使用 Bedrock 之外的模型或推理平台，就仍然可能需要额外的 Gateway 或路由层。

DigitalOcean、OpenRouter、LiteLLM 和 Amazon Bedrock 怎么选？

把这四种方案放在一起之后，差异其实非常清楚。

它们最大的区别不是"谁支持的模型最多"，而是：

你希望多模型路由这一层由谁来负责。

你的需求	更值得关注的方案
希望托管式使用多模型，并根据任务、成本或速度自动选择	DigitalOcean Inference Router
希望用一个 API 快速访问和测试大量模型	OpenRouter
希望完全自建、自主管理模型 Gateway	LiteLLM
AI 基础设施已经深度绑定 AWS	Amazon Bedrock
不想自己维护 Gateway、数据库和高可用	DigitalOcean / OpenRouter / Bedrock
需要跨多家外部模型平台统一管理	OpenRouter / LiteLLM
希望模型路由和推理基础设施放在同一平台	DigitalOcean / Bedrock

如果希望少运维，同时需要比较自由的多模型选择：

可以重点看 DigitalOcean Inference Router 和 OpenRouter。

但两者的逻辑有所不同。

DigitalOcean 更接近"推理平台 + Router"：模型、推理和路由在同一个平台内。

OpenRouter 更接近"模型聚合 + Router"：通过统一 API 把多个模型和底层推理平台聚合起来。

如果团队已经有成熟的基础设施能力，希望完全掌控 Gateway：

LiteLLM 更合适。

它允许自己决定模型平台、Fallback、负载均衡和访问策略，但相应的 Gateway 基础设施也需要自己维护。

如果已经深度使用 AWS：

Amazon Bedrock 的价值会明显提高。

因为这时 IAM、网络、模型、监控和账单原本就在 AWS 体系内，直接使用 Bedrock Prompt Routing 的集成成本最低。

如果需要在 Kimi、Qwen、GLM、Claude、GPT 等多个模型之间切换：

则需要重点关注模型目录本身的覆盖范围。

这种场景下，能够通过统一平台直接调用多个模型，并进一步做 Task Routing 的方案会更加方便。

多模型路由 FAQ

多模型路由和负载均衡是一回事吗？

不是。

负载均衡通常解决的是：

同一个模型或服务有多个 Endpoint，请求应该发到哪个实例？

而多模型路由解决的是：

这个请求本身应该使用哪个模型？

两者可以同时存在。

例如，Router 先决定使用 Claude，之后再在三个 Claude Endpoint 中通过 Load Balancing 选择一个实例。

智能模型路由一定比规则路由好吗？

不一定。

如果业务任务非常固定，例如：

复制代码

/code → Coding Model
/summary → Cheap Model
/vision → Vision Model

规则路由反而简单、稳定、可预测。

智能语义路由更适合请求类型复杂、用户输入自然、难以提前穷举规则的场景。

DigitalOcean 和 OpenRouter 最大区别是什么？

两者都可以通过统一 API 使用多个模型，但产品定位不同。

OpenRouter 更强调聚合大量模型以及多个底层推理平台。

DigitalOcean Inference Router 则属于 DigitalOcean 推理引擎的一部分，除了模型 API，本身还把 Task Routing、模型池、Fallback、无服务器推理、批量推理和专属推理整合在同一个平台内。

因此，如果主要需求是"大量模型统一入口"，OpenRouter 很有吸引力；如果希望把 Router 和生产推理基础设施结合起来，则可以重点比较 DigitalOcean。

LiteLLM 和托管式 Router 最大区别是什么？

最核心的区别是运维责任。

LiteLLM 给团队更多控制权，但 Gateway 本身需要自己部署和维护。

托管式 Router 则把这部分工作交给平台。

所以最终应该比较的不只是软件价格，还包括：

服务器 + 数据库 + Redis + 高可用 + 监控 + 升级 + 工程师时间。

Amazon Bedrock 适合跨模型路由吗？

它支持智能 Prompt Routing，但路由范围存在一定限制。

如果已经在 Bedrock 模型生态内，它非常自然。

如果希望在多个不同平台、不同模型生态之间自由路由，则需要进一步评估是否还需要一个额外的多模型 Gateway。

多模型路由真的可以降低推理费用吗？

可以，但前提是你的请求本身存在明显的复杂度差异。

如果 80% 的请求只是分类、摘要和信息提取，却全部使用最贵的前沿模型，那么路由带来的成本优化空间会非常明显。

反过来，如果所有请求都必须调用同一个最强模型，增加 Router 并不会凭空降低成本。

真正应该 Benchmark 的是：

任务类型 × 模型质量 × Token 价格 × 延迟

而不是单独比较模型价格。

用 DigitalOcean 构建多模型 AI 路由

很多基于 LLM 构建应用的团队，最初都会让所有请求调用同一个模型。

结果是，一些简单的分类、提取和摘要任务，也要按照前沿模型价格付费。

随着业务增长，又会逐渐出现另一类问题：

一个模型不够用了。

团队开始接入 Claude、GPT、Qwen、Kimi、GLM、DeepSeek......

如果继续把所有模型判断写进业务代码，最终很容易出现越来越多这样的逻辑：

复制代码

if task == A:
    model = X
elif task == B:
    model = Y
elif X unavailable:
    model = Z

DigitalOcean Inference Router 提供了一种更直接的方式：把这些模型选择逻辑放进专门的路由层，根据请求对应的任务，从已经配置好的模型池中选择模型，再根据团队优先级综合考虑成本、延迟等因素。

由于它和无服务器推理、批量推理、专属推理运行在同一个平台，多模型路由可以直接成为整个推理架构的一部分，而不是之后再增加一个独立 Gateway。

根据任务选择模型，而不是固定一个默认模型：可以使用预设任务，也可以通过自然语言描述和模型池创建自己的任务。
自定义优化目标：可以优先成本、速度，也可以按照人工配置的模型优先级进行选择。
只改一个模型名称即可接入：把现有 OpenAI 兼容请求中的模型名称替换成 Router 名称。之后模型组合变化时，只需要修改路由策略，不需要反复调整业务代码。
自动 Fallback：如果模型触发限流或者不可用，Router 可以继续按照顺序尝试备用模型，避免一次模型故障直接变成请求失败。
统一管理多个模型：可以在同一平台访问多个开放模型、商业模型和多模态模型，同时统一处理账单和管理。

对于不想自己搭建和维护 LLM Gateway，同时又需要在多个模型之间根据任务、成本和速度动态选择的团队来说，这种方式可以把多模型路由从一段越来越复杂的业务代码，变成一项独立的推理基础设施能力。

如果需要更多建议，并进一步了解DigitalOcean 的产品，可直接咨询卓普云（aidroplet.com）。