ACE Studio 是一款面向制作人、作曲家和专业词曲作者打造的 AI 原生音乐工作站。公司提供前沿工具，包括人声合成和由 AI 驱动的乐器，用于简化创作流程。正如 CTO 兼联合创始人 Sean Zhao 所说：“ACE Studio 是面向制作人和作曲家的下一代音乐创作工具。”

该平台最初主要服务于使用 AI 进行歌声生成（AI Singing Voice Generation）的专业用户，随后扩展至旋律生成与分层（layering）等功能，使不同水平的用户都能在无需深厚专业背景的情况下创作音乐。当 ACE Studio 在延迟、成本以及超大规模云平台（hyperscalers）复杂配置方面遇到挑战时，他们选择了 DigitalOcean 和 AMD 来满足 GPU 与推理需求，从而实现了更低成本、更少卡顿，以及更优质的用户体验。

## ACE Studio 面对的问题：高延迟与高昂成本

随着用户规模增长和模型不断演进，ACE Studio 在训练与推理两方面都面临基础设施挑战。他们发现，主流云厂商（如 AWS 和 Google Cloud）的 GPU 不仅价格高昂，而且常常供不应求，限制了扩展能力。同时，本地低成本数据中心在可靠性方面表现不佳。

CTO 兼联合创始人 Sean Zhao 表示：“有时我们需要扩容，但超大规模云厂商已经没有可用 GPU。本地低成本数据中心的可靠性和稳定性又很脆弱。我们希望找到像 DigitalOcean 这样的服务商，在可用性和规模化可靠性之间取得平衡。”

这些基础设施问题直接导致了高延迟，这对于依赖 MIDI 和歌词进行创作的用户来说是不可接受的。用户曾经历超过 2 秒的延迟——对于需要频繁进行细微调整的专业制作人和音乐爱好者而言，这是一个致命问题。

此外，超大规模云平台的高成本与资源限制，也使 ACE Studio 难以高频进行模型训练，成为团队保持竞争力的瓶颈。

## 解决方案：DigitalOcean + AMD 高性能基础设施

为了解决这些问题，ACE Studio 迁移至由 AMD Instinct™ MI325X GPU 驱动的 [DigitalOcean GPU Droplets](https://www.aidroplet.com/product/gpu/)。

对于 ACE Studio 来说，这一转变显著提升了整体 GPU 性能和运维体验。Sean Zhao 表示：“DigitalOcean 易于使用，界面简洁，我的开发团队非常喜欢。相比之下，传统超大规模云平台对他们来说简直是一场噩梦。”

这种易用性直接降低了模型部署与管理的运维成本。同时，在经历了本地低成本数据中心的不稳定之后，DigitalOcean 提供的高可靠性也成为关键优势，确保其高速创作工具能够持续稳定运行。

结合 DigitalOcean 的简化管理与 AMD 高性能 GPU，ACE Studio 的开发效率显著提升——原本需要半个月的训练周期缩短至不到一周。正如 Zhao 所说：“我们可以非常快地看到结果，并迅速迭代。这对于我们在市场中持续领先、满足用户需求至关重要。”

## 延迟优化策略

ACE Studio 的专业用户对延迟极为敏感，尤其是在处理 MIDI 旋律和歌词时，需要接近实时的反馈。

为此，他们采取了两项关键优化措施：

- 在欧洲、北美和东亚部署推理节点，降低网络延迟
- 构建面向全球用户的分布式推理架构
    

同时，这一切是在优于其他方案的性价比下实现的，使其在成本与性能之间取得最佳平衡。

## 基于DigitalOcean GPU Droplet的优化成果

通过上述优化，ACE Studio 在训练与推理层面均取得显著提升：

- 基础设施成本效率提升约 5%
- 推理延迟从 2500ms 降至 1500ms（降低 40%）
- 模型训练周期从约 2 周缩短至 1 周以内，迭代速度翻倍
- 更高的性价比，使同一预算下可进行更多实验
- GPU 资源交付更快，运维开销显著降低
- 基础设施稳定性提升，消除以往宕机风险
    

## 展望：降低创作门槛，释放创造力

随着稳定且高性价比的基础设施落地，ACE Studio 已准备好迎接 AI 技术带来的用户增长浪潮。Zhao 强调，这项技术的目标是增强创作者能力，而不是取代他们——真正的灵感始终源于人类。

未来，ACE Studio 将继续深化与 DigitalOcean 和 AMD 的合作，支持更大规模的音乐生成模型。同时，其技术路线图中的重点之一，是构建高性能分布式文件系统，以应对音频模型训练所需的海量数据，从而保持在 AI 音乐领域的领先地位。

> “获取大显存且高性价比的 GPU，使我们能够构建更大、更复杂的模型。DigitalOcean 与 AMD 提供的基础设施，是我们实现路线图的关键，让我们能够更快迭代，并为创作者带来更多能力。”—— ACE Studio CTO & 联合创始人 Sean Zhao

目前，DigitalOcean除了提供AMD MI350X、MI325X、MI300X，还提供NVIDIA B300、H200、H100、RTX 6000 Ada、L40S等型号的[GPU Droplet 云服务器](https://www.aidroplet.com/product/gpu/)，并提供无需认证、无网络连接障碍的 [Serverless Inference 服务](https://www.aidroplet.com/product/serverless-inference/)，可轻松直接调用 Claude、GPT等模型API。如需了解详情与价格折扣，可直接联系 [卓普云AI Droplet（aidroplet.com）](https://www.aidroplet.com/)。

large_images-14.png

medium_images-14.png

small_images-14.png

thumbnail_images-14.png

images-14.png

基于 DigitalOcean 与 AMD GPU，ACE Studio 将推理延迟降低40%、训练周期缩短一半，实现更高效稳定的音乐生成体验。

DigitalOcean 助力 ACE Studio：推理延迟降40%，训练效率翻倍

Bright Data 是一家行业领先的 Web 数据平台，帮助全球企业以快速、规模化的方式采集、索引并结构化公开的互联网数据。Bright Data 团队致力于让数据更易获取，帮助人们高效获取所需信息，从而支持关键的战略和运营决策。无论是《财富》500 强企业、学术机构，还是中小型公司，都依赖 Bright Data 以高效、可靠且灵活的方式获取关键的公开网络数据，用于研究、监测和分析，从而做出更优决策。

Bright Data 成立于 2014 年，旨在解决日益增长的 Web 数据需求。互联网或许是全球最大的数据库，但其数据高度割裂。例如，在一个地区可访问的数据，在另一个地区可能无法获取。为了解决这一问题，Bright Data 推出了住宅 IP 网络，使相关的数据采集请求能够被识别为来自真实用户的访问——这一在当时具有开创性的方式，使各类企业能够在全球范围内访问任意公开的 Web 数据。公司在成立之初便选择与 DigitalOcean 合作，并一直将其作为云基础设施的重要组成部分。如今，随着业务快速增长，Bright Data 已升级至 DigitalOcean Kubernetes。

## 借助 DigitalOcean 实现高带宽稳定性与可靠性

Bright Data 采用多云架构，能够结合不同云服务提供商的优势，为业务提供更高的灵活性。DigitalOcean 对开源与透明性的坚持，使企业可以根据自身需求自由配置基础设施，同时也让 DigitalOcean 成为一个可靠的长期合作伙伴。对于 Bright Data 来说，这意味着他们可以借助 DigitalOcean 可扩展、稳定的 Droplets 实例以及低成本带宽，来维护代理服务器，并通过简洁的 API 快速扩展规模。

Bright Data 使用 [DigitalOcean Droplets 云服务器](https://www.aidroplet.com/product/cloudcpu/)部署其 Web 数据采集平台，对公开互联网进行爬取，收集并整理信息。相比其他云服务商，Droplets 在稳定性与带宽能力上具备更优性价比，使 Bright Data 能够提升数据处理规模，并随着客户增长持续扩展。同时，借助 DigitalOcean API，Droplets 的快速部署也让扩展变得更加轻松。

“我们很快发现，DigitalOcean 在 Droplets 稳定性、带宽以及数据中心网络方面的表现是最好的，非常稳定。这一点至关重要，也正是这种稳定性帮助我们不断提升业务规模。”——Nir Borenshtein，Bright Data COO

到 2016 年，Bright Data 已拥有 1000 万住宅 IP，到 2018 年增长至 3500 万。到 2019 年，公司团队从 2014 年的 8 人扩展至 120 人，并推出多款新产品。近几年，Bright Data 实现了指数级增长，目前服务超过 15,000 家客户，团队规模超过 450 人，分布在 17 个国家，并在美国设立了主要办公地点。2021 年，公司年收入突破 1 亿美元，并完成了 3 起收购，而 DigitalOcean 一直伴随其发展。

Bright Data 每天通过 DigitalOcean 服务器处理数百 TB 的数据。到 2022 年初，公司在 DigitalOcean 上运行近 6000 个 Droplets，由一个小型团队维护整个云网络。DigitalOcean 的高可靠性帮助 Bright Data 实现每年超过 12,000 次产品发布，平均每天发布 60–80 个新版本，不断优化其 Web 数据平台。

此外，公司还建立了完善的合规部门，并制定了行业领先的流程与规范，以确保数据质量和可靠性达到最高标准。

“DigitalOcean 提供的技术非常强大，让我们能够高效运作。其 API 和快速部署能力，以及良好的扩展性，对我们来说极具价值，我们一直在持续使用这些能力。”——Nir Borenshtein，Bright Data COO

## 迁移至 DigitalOcean Kubernetes

作为一支注重效率与创新的团队，Bright Data 始终在寻找最优解决方案。其业务负载具有明显的周期性：工作时间内使用率较高，而在非工作时间及周末则较低。由于负载波动较大，Droplets 的平均利用率仅约为 60%，存在资源浪费问题。因此，他们需要一种能够根据需求自动扩展的方案，以避免为高峰流量预留大量闲置资源。为此，团队决定迁移至 [DigitalOcean Kubernetes](https://www.aidroplet.com/product/kubernetes/)。

“我们的负载是动态变化的，周末较低，工作日较高。虽然我们可以通过 DigitalOcean API 创建 Droplets 并部署系统，但从整体来看，这不如 Kubernetes 强大。我们希望尽快解决资源利用率不足的问题，而唯一可行的方案就是 DigitalOcean Kubernetes。”——Nir Borenshtein，Bright Data COO

![Bright Data architecture.png](https://blog.aidroplet.com/uploads/Bright_Data_architecture_b6553f146c.png)
Bright Data 将其核心产品之一——数据平台进行了容器化改造，并迁移至 Kubernetes（这一过程通常被称为 lift-and-shift）。团队在大约三周内完成了最小可行产品（MVP），并很快投入生产使用。随后，他们将服务器迁移至 Kubernetes，并通过 Terraform 实现自动化资源配置，同时改造了容器构建流程，并开发了自有的 CI/CD 工具。

“Kubernetes 运行更快、效果更好，而且我们无需重新设计系统。它让我们能够专注于开发，同时实现高效扩展。借助 DigitalOcean Kubernetes，我们可以更快增长，并通过充分利用 Droplets 来降低成本。”——Nir Borenshtein，Bright Data COO

## 持续增长以满足客户需求

快速增长也带来了新的挑战。COO Nir Borenshtein 表示，在公司发展过程中，他们逐渐认识到最重要的两大资产是“人才”和“技术”。从最初的 8 人团队发展到如今的 450 人，需要管理层不断优化制度与流程，同时持续吸引并留住顶尖人才。他认为，要在行业中保持领先地位，必须持续投入创意与创新。目前，公司已提交超过 2200 项专利申请，并仍在快速发展中。

“我们的增长不是偶然的，而是因为市场对 Web 数据的需求真实存在。随着业务扩张，我们面临的客户交付压力也在增加。需求越大，对速度和创新的要求也越高。我们的目标是为所有客户按时提供高质量、可靠的数据，并持续打造能够解决数据挑战的技术。”——Nir Borenshtein，Bright Data COO

Bright Data 目前仍是行业的领先者，并将继续保持这一地位。其对卓越的追求贯穿业务的各个方面，而与 DigitalOcean 的合作，也让他们能够将精力集中在最关键的领域。

large_images (15).png

medium_images (15).png

small_images (15).png

thumbnail_images (15).png

xsmall_images (15).png

images (15).png

依托 DigitalOcean 的高带宽与稳定云基础设施，Bright Data 实现全球数据采集能力提升与业务规模化增长，持续优化平台性能与效率

DigitalOcean 助力 Bright Data 构建高稳定数据平台

过去一年，AI 几乎进入了每一家公司的讨论清单。 但在卓普云，我们发生的变化并不是“多用了一些工具”，而是： 一整套业务执行逻辑，开始由 AI 协同运行。

这不是在写 Prompt，而是一个持续运转的执行闭环：

- **在前端与内容侧：**


我们的官网和博客不再依赖传统的开发排期。页面结构由 AI 驱动生成，前端组件自动上线。

在传统流程中，一个页面上线意味着多个角色之间的协作与排期，需要经历：

> 文案 → 设计 → 前端开发 → 测试 → 发布，往往需要数天甚至数周时间。

而现在，从一个业务想法到上线，我们只需要在系统中完成一次定义，整个过程可以在数小时内完成。

这种能力并非天生，我们用了很长时间去反复调整这条链路，才让它稳定下来。

  
![1280X1280.PNG](https://blog.aidroplet.com/uploads/1280_X1280_a10159694b.PNG)

上图即为当前线上运行的官网页面，由 AI 完成设计与开发，并持续迭代。

- **在增长与获客侧：** 系统在后台持续分析用户行为。它会识别潜在客户、完成画像（Profile）打分，并生成对应的话术与内容。这不是群发邮件，而是在同时进行成千上万场“一对一”的自动化沟通。
- **在销售与支撑侧：** 每一位销售都拥有一个 AI 技术助理。从技术方案初稿到话术建议，再到报价生成，系统可以即时响应。销售不再需要排队等待技术支持，决策逻辑被固化在了系统内部。
- **在运维与稳定性侧：** 异常由系统自动识别，并通过企业微信触发处理流程。当出现问题时，我们不再需要登录控制台或 SSH 服务器，而是在对话中直接触发构建、刷新与恢复。


在这套体系中，业务人员不再只是提出需求。

没有工程背景的增长负责人，通过 AI 完成了自己的第一条 Pull Request。如今，这套由非技术团队驱动的系统已稳定运行超过一年，支撑着数万客户的日常业务。目前，我们正将这套能力向更复杂的 SMB（中小企业）销售场景持续演进。

欢迎访问：www.aidroplet.com，查看这个稳定运行的案例。

直到这一刻，我们才意识到：我们不仅仅是在“使用 AI”。 我们是在用 AI 运行公司本身。


我们把这种形态，称为：**AI Native Company**



## 一、我们做的，是让“执行层消失”

一家公司，本质上就四件事：Build / Operate / Sell / Grow。

在传统公司，“需求”与“上线”之间，隔着一条沉重的组织链路：市场提需求 → 技术排期 → 多轮沟通 → 最终上线。 而在卓普云，这个过程没有“人”。

这套系统起初由 1 位业务定义者搭建原型，目前由极少数非技术成员驱动运行。这几位成员原本从事内容、增长与销售工作，并没有传统分工中的开发角色。这 3 人的市场团队，不再是系统的操作者，而是业务系统的定义者（System Architects）。 这不是简单的效率优化，而是执行层的消失。

很多人会说：“这本质上还是需要极强的架构能力。” 我们完全同意。但这恰恰说明：技术门槛没有消失，而是发生了迁移。

- **过去：** 技术 = 会不会写代码（How to code）
- **现在：** 技术 = 能不能设计系统（What to build）


代码正在贬值，系统编排（Orchestration）能力正在成为新的通识能力。这 3 位成员不再操作系统，他们在定义业务的目标函数。AI 负责寻找最优解，人负责定义“什么是对的结果”。

## 二、重写 Execution Layer：Infra by Engineers, Execution by AI

我们把公司架构拆解为两层：

1. **基础设施层 (Infra Layer)：** 包括 GPU、Serverless 架构与底层平台。由专业工程团队负责，这是系统确定性的前提。

2. **执行层 (Execution Layer)：** 包括官网、内容、运维、销售支持与增长引擎。由 AI 驱动，由非技术团队定义。

例如下图所示，这是在企业微信中的龙虾（OpenClaw）。龙虾由这个小团队里的人配置，每当网站有新的页面，就可以在企业微信中发出增量部署指令，通过指挥龙虾来完成，整个过程0代码。

![20260401-161946.jpeg](https://blog.aidroplet.com/uploads/20260401_161946_0b9a73fa02.jpeg)


我们不迷信 AI 能自动解决一切，而是重新定义了协作方式：

- 可标准化任务 → AI 执行
- 高价值决策 → 人负责


当前阶段：

- 市场与基础销售流程，已由 AI 主导执行
- 客户识别、初步沟通与方案生成，系统可自动完成


但在复杂交易环节，例如大客户落单、定制化方案与关键决策，仍然由人来完成。

在这些场景中，AI 不再是执行者，而是：

- 提供技术建议
- 生成话术与方案草稿
- 辅助判断与决策


人仍然做最终判断，但不再从零开始。

下一步，我们正在探索：

让 AI 从“执行层”进一步向“决策支持层”延伸

特别是在 SMB 销售场景中，让更多决策可以被系统承接。

## 三、这不是工具组合，而是自动流转的“执行链”

很多人把 AI 理解为一组孤岛式的工具。但在 AI Native Company，这是一条自动流转的执行链 。

从用户进入页面，到画像识别、意向判断、方案生成，再到自动化触达。整个过程在系统内部毫秒级闭环。这不是在用工具，而是在管理一个“自动增长”的生命体。



## 四、关于“不确定性”：我们如何处理 AI 出错

这是一个最常见的问题：**AI 会不会出错？**

答案是：**会。**

我们并不假设模型是可靠的，而是从一开始，就把“出错”当作系统的一部分来处理。在实际运行中，我们做了几件很简单但关键的事情：

- AI 的输出不会直接执行，而是作为“建议”进入流程
- 关键动作（例如对外沟通、报价）会有明确的触发条件
- 系统会记录每一步行为，并用于后续修正


换句话说：我们不是在追求“AI 不出错”，而是在设计：

> **即使出错，系统也不会失控**

在这个过程中：

- AI 负责生成
- 系统负责约束
- 人负责最终判断


我们改变的不是“正确率”， 而是“出错的代价”。



## 五、我们在做什么：卖“执行层的入口”

卓普云是一家提供 AI 基础设施的公司。我们当前提供的核心能力是：

- GPU 租赁
- Serverless Inference（无服务器推理服务）

这是我们业务的“产品形态”。但在过去一年的实践中，我们发现，算力本身，并不能直接转化为业务结果。

真正的难点在于：如何把模型能力，变成可执行的业务系统。

也正因为如此，我们在内部持续用 AI 运行公司本身：

- 官网与内容
- 运维
- 增长
- 销售支持


这套系统，已经在真实业务中稳定运行，并服务数万客户。在这个基础上，我们开始重新理解“基础设施”的意义：

> 我们提供的，不只是算力资源， 而是让 AI 能够真正参与业务执行的基础环境。

所以更准确地说：我们提供的是 GPU 与推理能力。但我们验证的是：**AI 可以成为公司运行的一部分**。

  

**关于卓普云**

卓普云是 DigitalOcean 在中国的独家战略合作伙伴，负责相关产品在中国市场的落地与服务支持。

我们所提供的 GPU 与推理服务，基于 DigitalOcean 的全球基础设施，并由本地团队提供对接、迁移与技术支持。

卓普云 AI Droplet 由 Access Technology Venture 组建。作为 DigitalOcean 的控股股东，Access Technology Venture 长期投资于科技企业（包括知乎、声网、PingCAP 等）。

这意味着：

我们不仅在内部实践 AI Native 的运行方式，也在基础设施层，为客户提供稳定、可持续的能力支撑。

## 六、关于“人”的位置

我们不是在让组织变冷酷，而是在让组织变敏捷。当 3 个人可以调度一个服务数万客户的增长系统时：

他们不再是执行的耗材，而是业务的定义者。但这并不意味着，这套系统“谁都可以使用”。

恰恰相反：

对人的要求变得更高了。

在这个体系中，人需要具备的是：

- 能理解业务本身
- 能把业务拆解为清晰的流程（workflow）
- 能判断 AI 与人的边界在哪里

不再是“会不会操作工具”，而是：

> 能不能定义系统应该如何运行

AI 是否会替代人，一直在被讨论。但在我们的实践中，更明显的变化是：AI 在演进，人的能力也在演进。两者之间的边界，并不是固定的。

它是在真实业务中，被不断试探和重新划分的。我们不是在减少人，我们是在改变“人应该做什么”


## 最后

  

AI 已经不算是一个新事物了。很多讨论还停留在：

- 哪个工具更好
- 哪些案例是真是假


但在我们这里，这些问题已经不再重要。我们用了一年的时间，把一套系统跑起来。踩过很多坑，也反复推翻过不少做法。现在回头看：

AI 是否能参与真实业务执行，其实不是一个需要讨论的问题。它是可以被做出来的。

更重要的是：

> 不是先想清楚一切，再开始。而是在运行中，慢慢把事情做清楚

如果有什么经验的话，那就是：

**先动起来，比讨论更重要。**

  

**AI 协同声明**

本文内容源于卓普云真实系统运行，由人定义目标，AI 辅助文字生成与润色。

large_zach-m-pd9jBKNLyj4-unsplash.jpg

medium_zach-m-pd9jBKNLyj4-unsplash.jpg

small_zach-m-pd9jBKNLyj4-unsplash.jpg

thumbnail_zach-m-pd9jBKNLyj4-unsplash.jpg

xlarge_zach-m-pd9jBKNLyj4-unsplash.jpg

xsmall_zach-m-pd9jBKNLyj4-unsplash.jpg

zach-m-pd9jBKNLyj4-unsplash.jpg

AI在演进，人与公司也在随之进化。

当所有人都在讨论 AI 工具时，我们已经用 AI 跑通了一家公司


人工智能的格局已经从静态模型演变为动态的、长时间运行的智能体。在 DigitalOcean，我们致力于为开发者提供一个专为智能体打造的 AI 推理云平台——让他们无需承担传统基础设施的运维负担和复杂成本。

今天，在 NVIDIA GTC 2026 上，DigitalOcean 宣布与 NVIDIA 合作大规模扩展推理能力。我们正在超越基础架构，构建一个专为 AI 构建者和下一代自主智能体提供支持的 AI 工厂（AI Factory）。

## AI 智能体的成熟平台

DigitalOcean 正在迅速成为智能体工作流的主导平台和AI企业的首选部署平台。当开源智能体 OpenClaw（前身为 Clawdbot）风靡全球时，DigitalOcean敏锐地察觉到了市场对一键部署（或者说无感知部署）的需求。

- 不到 36 小时，DigitalOcean就将生产级的[一键部署OpenClaw功能](https://marketplace.digitalocean.com/apps/openclaw)上线到了DigitalOcean Marketplace（生态插件市场）
- 结果证明了我们的影响力：OpenClaw 在 DigitalOcean 上实现了 43,000+ 部署量，目前有超过 11,000 个 OpenClaw 部署在实际场景中运行
- DigitalOcean的开发者们不仅仅是在部署模型，他们还在利用DigitalOcean的生态系统，从备份、快照到 Gradient AI 无服务器推理等相关服务，以支持他们的智能体工作负载

DigitalOcean 和 NVIDIA 还合作开发了开源工具集 [NVIDIA NemoClaw](https://www.nvidia.com/en-us/ai/nemoclaw/#referrer=vanity)，只需一条命令就能更安全地运行 OpenClaw 常驻助手。NVIDIA OpenShell 运行时提供了一个安全环境来运行自主智能体和开源模型，然后无缝部署到 DigitalOcean。

## AI 工厂：深度融合云基础设施与推理服务

为什么 DigitalOcean 在这个 AI 市场中处于独特的领先地位？我们正大力投入，将云基础服务与 AI 推理能力深度集成，打造一个支持各类推理场景的卓越平台。

不同于传统超大规模云（如AWS、GCP）的碎片化与复杂性，我们的AI工厂为构建者提供了直达生产、易于扩展的简化路径。除了尖端GPU，你还能无缝整合以下完整的DigitalOcean产品套件，为生产业务保驾护航：

- [Kubernetes 托管服务（DOKS）](https://www.aidroplet.com/product/kubernetes/)用于编排
- [VPC](https://www.aidroplet.com/product/cloudcpu/) 和云防火墙提供无妥协的安全性
- [负载均衡器](https://www.aidroplet.com/product/loadbalancer/)轻松扩展流量
- 高性能 NAS 存储加速推理和微调
- [OpenSearch](https://www.aidroplet.com/product/opensearch/) 等托管数据库处理对智能体记忆和检索至关重要的海量向量数据集

## 专为 AI 构建的基础设施：Richmond 数据中心

为支撑这个 AI 工厂，我们启用了全新的 **Richmond 数据中心**——DigitalOcean 专为 AI 打造的 latest 设施。

- 该数据中心配备最先进的 [NVIDIA HGX B300 GPU 服务器](https://www.aidroplet.com/product/b300/)
- 400 Gbps 无损 RDMA 网络架构，满足复杂智能体工作流和大规模模型部署所需的高吞吐数据传输
- 与计算、网络、存储及推理中心等核心云服务无缝集成

## 基于DigitalOcean的build.nvidia.com

通过与 NVIDIA 的深度合作，我们正在将世界上最先进的开源模型直接集成到 NVIDIA 原生技术栈中——而这些模型实际运行在 DigitalOcean 的高性能基础设施上。

具体来说：

- **直接在 [build.nvidia.com](https://build.nvidia.com/) 调用无服务器端点**：用户现在可以在 [build.nvidia.com](https://build.nvidia.com/) 上直接使用 [DigitalOcean 的无服务器推理能力](https://www.aidroplet.com/product/serverless-inference/)，运行 GLM-5、Kimi-K2.5、Minimax-M2.5 等顶尖开源模型，无需跳转，无需重新配置。
- **Blackwell 带来的性能跃升**：这些最先进的模型跑在 DigitalOcean 由 NVIDIA Blackwell GPU 驱动的无服务器推理平台上，相比 HGX H200 性能提升约 4 倍（基于内部测试数据）。
- **Dynamo 1.0 加持，成本再降**：我们已经采用 NVIDIA Dynamo 1.0 来优化生产级推理。在 DigitalOcean Kubernetes 上运行 Dynamo 的客户不仅获得了显著的性能提升，在 Hopper GPU 上的推理成本也降低了高达 3 倍。


通过 [build.nvidia.com](https://build.nvidia.com/) 与 DigitalOcean 的深度集成，AI 开发者现在可以：在 NVIDIA 的 API 目录里试用高性能模型做原型设计 → 然后一键无缝部署到 DigitalOcean GPU Droplets 进入生产环境。整个流程无需重构技术栈，基础设施层面的摩擦被彻底消除。

我们邀请你今天就上手试试，开始交付下一代 AI 应用。

## 扩展开源模型目录

同时，DigitalOcean 宣布，NVIDIA 的 [Nemotron 3 Nano 模型](https://cloud.digitalocean.com/gen-ai/dedicated-inference/new?i=e0fda3)现已上线 DigitalOcean 推理云平台。

- 该模型为深度推理工作流带来了卓越效率
- 利用稀疏混合专家（MoE）架构，每个 Token 仅激活 32 亿参数
- 这种效率支持高达 100 万 Token 的上下文窗口，为复杂的长时间任务解锁高级智能体推理

欢迎参加在旧金山举办的 [DigitalOcean Deploy](https://www.digitalocean.com/deploy)，与创新者一起探讨现实世界推理的挑战、使用 AI 智能体进行构建，以及定义智能体时代的未来。

同时，也欢迎中国区的企业与开发者关注[卓普云AI Droplet](https://www.aidroplet.com/)，今年 DigitalOcean 还将发布一系列面向 AI 与机器学习的 GPU 算力产品、AI 推理产品等服务，并通过卓普云AI Droplet 为大家提供专业的技术服务。

large_images (16).png

medium_images (16).png

small_images (16).png

thumbnail_images (16).png

xsmall_images (16).png

images (16).png

DigitalOcean 与 NVIDIA 联合发布 AI 工厂：NVIDIA 使用 DO 基础设施搭建 build.nvidia.com，开发者可无缝完成从模型原型到生产部署。

DigitalOcean 亮相 NVIDIA GTC 2026：为智能体时代打造 AI 工厂

让一个模型同时处理 10 个推理请求是棘手的，但还算简单；让它在全天候面对 2,000 名工程师使用长上下文的代码助手时保持稳定、不产生失控成本，这才是团队容易卡住的地方。一个能工作的端点只是起点。团队需要识别支持硬件、连接正确的组件——服务、扩缩容、可观测性和成本护栏——这样部署才能在真实、持续负载下支撑预期的 SLA 和 SLO。

DigitalOcean 已在 [DigitalOcean AI Platform](https://www.digitalocean.com/products/gradient/platform) 上提供 [无服务推理Serverless Inference](https://docs.digitalocean.com/products/gradient-ai-platform/how-to/use-serverless-inference/)：一条快速接入 OpenAI、Anthropic、Meta、Deepseek 或其他提供商模型的路径，最小配置、按 token 定价。这种产品适合很多使用场景。然而，当你需要跑自己的模型权重、要在专用 GPU 上获得可预测的性能，并且从经济角度看，持续的大量 token 生成远比按 token 突发计费更划算时，就需要另一种方式了。

[专用推理Dedicated Inference](https://docs.digitalocean.com/products/gradient-ai-platform/how-to/use-dedicated-inference-platform/)——我们在 DigitalOcean AI Platform 上的托管 LLM 托管服务——填补了这一空白。

专用推理Dedicated Inference 在[专用 GPU ](https://www.aidroplet.com/product/gpu/)上部署并运维一套带有明确倾向的推理栈，底层采用 Kubernetes 原生编排。你通过已经在 DigitalOcean 生态中使用的控制平面和 API 进行交互；数据平面则暴露公网和私有网端点，让 VPC 内外的应用都能安全调用你的模型。

这项服务的设计初衷，是将一个庞大的组合空间——GPU 型号、运行时、路由器、自动扩缩策略——收敛为引导式的默认配置，让团队比自建栈更快达成生产就绪的里程碑，同时保留模型服务中真正重要的那几个可调旋钮：副本数、扩缩行为，以及在推进产品路线图时需要用到的高级优化能力。

## 我们管什么，你管什么

每项托管产品都会在平台负责和客户负责的事项之间划一条线。专用推理的目标，是把 Day 2 运维——集群生命周期集成、流量入口、核心推理服务与路由组件，以及它们之间的衔接——放在平台侧，而把模型选择、容量规划以及针对具体工作负载的调优留给你。

通常由平台管理：

- 底层编排体系的供应与生命周期，遵循产品设计（例如托管 Kubernetes 集成以及 GPU 资源池协调）。
- 核心推理引擎与编排集成，包含规模化下真正关键的模式：智能路由、自动扩缩钩子，以及面向生产环境的服务路径。
- 端点的创建、健康检查与弹性伸缩工作流，以及让端点持续符合声明式配置所需要的运维自动化。


由你掌握：

- 选择适合你 SLO 和预算的模型（含支持的自带模型路径）、GPU 规格以及副本数。
- 配置扩缩行为，并随着时间推移，逐步启用与你的延迟、吞吐和成本目标相匹配的高级服务选项。

- 通过稳定的 HTTP API 接入应用，API 与主流 LLM 客户端栈保持一致。



## 专用推理Dedicated Inference 是什么？

专用推理构建于业界标准组件之上，让客户能够受益于社区推动的持续改进：

- [vLLM](https://docs.vllm.ai/en/latest/) 是一个功能强大且被广泛采用的推理引擎，适用于在现代 GPU 上运行大语言模型。
- [LLM-d](https://llm-d.ai/) 是一套面向 [Kubernetes](https://www.aidroplet.com/product/kubernetes/) 的分布式推理模式技术栈——精确的前缀缓存感知路由、有别于传统 HTTP 服务的扩缩考量，并留有随着工作负载需求而向更高级拓扑发展的空间。

这一组合反映了一种深思熟虑的选择：在客户当前所处的位置与之相遇（兼容 OpenAI 的 API、DigitalOcean 上熟悉的 GPU 产品），同时与路由、副本和横向扩展推理的生态演进方向保持一致。


## 高层架构

系统设计将控制平面（端点如何创建、更新、列出及删除）与数据平面（聊天/补全请求流量如何抵达你的模型）进行了分离。这与管理请求相呼应：管理请求走的是一条为区域部署和持久化生命周期工作而构建的路径；推理请求则走的是 GPU 前面一条直接且低延迟的路径。

### 控制平面：中心入口，区域执行

这里所说的“控制平面”是指什么？在这种划分中，控制平面就是处理管理流量的那一整套东西：针对专用推理端点的管理 RPC，以及将你声明的意图转化为实际运行的 DI 基础设施所依赖的持久化记录。它与数据平面是分离的，数据平面是端点健康后推理请求（聊天/补全风格）所经过的“热路径”。

![image1.png](https://blog.aidroplet.com/uploads/image1_8ce35f24e2.png)

**中心 API 层**：源自 DigitalOcean Cloud UI、自动化工作流或公共 API 的请求，首先会被路由经过一个中心化的 API 层。这一层维护着按区域划分的端点归属映射关系，并将每个请求透明地转发至对应的区域后端。这一设计遵循多区域扇出模型，通过稳定的标识符来定位区域端点。

**区域专用推理服务**：每个区域运行一个控制平面服务，负责其范围内实例的完整生命周期管理。这包括持久化期望状态、根据观察到的状态进行调和、推进生命周期状态（例如 创建中 → 活跃），以及将供应或变更底层基础设施的工作流排入队列。在此语境中，生命周期指的是那台状态机，它管理者从被请求到正在运行再到可达的状态转换。一个实例代表了整个托管推理部署——既包含其控制平面记录，也包含相关联的后备资源。

独立的 Worker 式组件负责执行那些需要重试、退避和幂等性的集成操作——调用 Kubernetes API、观察对象状态，并将生命周期更新发布回核心服务。这类似于我们熟知的 Kubernetes Operator 协调器模式：观察期望状态、采取行动、不断重复直至现实与意图一致。典型场景：临时性 API 错误或缓慢的节点启动不会卡住面向用户的 API；系统会持续尝试，并展现一个清晰的状态，而非一个只应用了一半的状态。

**DigitalOcean Kubernetes 与容量**：平台首先帮助确保目标 VPC 内拥有足够的 DigitalOcean Kubernetes 容量，挂接所需的 GPU 及配套 CPU 节点容量，铺开托管推理栈（网关与模型工作负载），并为公网和私有端点创建区域网络负载均衡器。

### 数据平面：VPC 原生流量，经网关路由的请求

![image2.png](https://blog.aidroplet.com/uploads/image2_b3779e4e40.png)

**客户合约与端点连接**：一旦端点处于活跃状态，客户端便发送兼容 OpenAI 的 API 请求（例如，到 /v1/chat/completions 风格路由的 HTTPS 请求）。你的公网端点 FQDN 解析到一个外部区域网络负载均衡器（L4）；你的私有端点则解析到一个内部区域网络负载均衡器，因此同一个推理栈既可从公网访问，也可停留在你的私有 VPC 网络上。在这两种情况下，流量都是符合 OpenAI 格式的 JSON，承载着模型 ID、消息及生成参数。

**集群放置与 VPC 隔离**：在 VPC 内部，工作负载运行在 DOKS 上。每个 VPC 一个集群可以承载多个专用推理部署，每个部署通过一个 Kubernetes 命名空间隔离。所期望的网关与模型接线通过 Custom Resources（CRD——自定义资源定义）来表达：是以声明式对象的方式 kubectl apply（或由平台代为 apply），而非使用命令式脚本。

**推理网关与 Kubernetes Gateway API**：经过 NLB 后，流量到达推理网关，该网关基于上游 Kubernetes Gateway API 实现——这是描述 HTTP/TLS 路由进入集群的社区标准。

**Gateway API 推理扩展（推理感知路由）**：在网关之下，Gateway API Inference Extension 教会路由如何识别推理信号：队列深度、副本健康度以及 KV 缓存亲和性（优先选择一个已经存有可复用提示前缀的键/值张量的副本，以避免从头重新计算）。KV 缓存是先前 token 注意力状态的保存；推理感知路由特意不是简单的轮询，因为“最廉价”的副本往往是那个已经缓存了你前缀的副本。

**端点选择器**：在 CPU 节点上，端点选择器是与推理扩展通信，并为每个请求选出应由哪个 GPU 副本接收的组件。

**模型服务与推理池**：在 GPU 节点上，模型服务——在配置中由推理池提供支撑——运行着你的模型副本（能够服务于相同模型 ID 的不同 Pod/进程）。每个副本向上报告负载、KV 及缓存元数据，使端点选择器的选择在滚动更新、崩溃及自动扩缩事件中始终保持准确。副本是同一模型服务器的水平扩展拷贝；池则是为路由和容量而对这些副本的分组。

## 谁适合使用专用推理？

专用推理面向的是那些已经清楚自己需要 GPU，但又不想成为一支全职推理平台团队的构建者：

- 在裸金属 GPU Droplet 或 Kubernetes 上自托管，并希望将编排、基线优化以及重复性的基础设施工作卸载出去，同时保持对应用 API 级别自主权的团队。
- 已从无服务器推理毕业，需要硬件层面的控制或自带模型，但又不想放弃托管运营的团队。
- 推理需求持续稳定，对可预测的 GPU 小时经济性和性能隔离的看重程度超过纯粹突发弹性的组织。

推理已不再是一个新奇层；它已是核心应用栈的一部分。这一转变拔高了可靠性、性能及成本可预测性的门槛。专用推理是为那些需要生产级、专用 GPU 推理，且需要一条从模型选择到稳定端点的托管路径的团队而建——这样，你们的工程周期就可以花在产品与提示上，而非重新发明一遍服务平台。

large_images (17).png

medium_images (17).png

small_images (17).png

thumbnail_images (17).png

xsmall_images (17).png

images (17).png

当 Serverless infernece 不够用了，如何在专用 GPU 上托管 LLM、兼顾性能可预测与成本可控？

既要 LLM 推理性能可预测，又要成本可控？专用推理了解一下

AI 是在循环中运行的。智能体会思考，然后行动，接着再次思考。单个用户任务就可能跨越数十万个 token，调用五六个工具，访问知识库，编写代码，执行代码，并持久化状态，这一切都发生在返回答案之前。我们现有的云并非为此而生。超大规模的云厂商（例如 AWS、GCP）提供数百种为昨日应用而构建的服务，却把集成工作留给了你。而那些只提供推理服务的新型平台则搭建在别人的算力之上，并加价出售给你。GPU 租赁商（常被称为“新型云”）给你的是芯片，而不是一个完整的系统。

本周，在 DigitalOcean 主办的 [Deploy 2026](https://www.digitalocean.com/deploy) 大会上，我们推出了 DigitalOcean AI 原生云，一个专为推理和智能体时代打造的平台，它将从芯片到智能体的五层能力整合在一个开放的栈中。

我们在周二交付了十五款产品。以下是详细介绍。

## DigitalOcean AI 原生云的五层技术栈

我们的 AI 原生云由五层构成，每一层都对应着我们所观察到的客户正在努力解决的真实工作负载模式。

![Paddy Blog Image 2.png](https://blog.aidroplet.com/uploads/Paddy_Blog_Image_2_9b86b993e5.png)
  

它们既能独立发挥价值，也能完美集成：


- **托管****智能体****：** 智能体的生产运行时，提供沙箱、持久状态和通用数据平面
- **数据与学习：** 托管数据库、向量存储、知识库和反馈闭环
- **推理引擎：** 每个开放和前沿模型共用一个端点，在内核层面进行优化
- **核心云：** 为 AI 调优过的计算、网络和存储原语
- **基础设施：** DigitalOcean 自有的芯片与设施，与业界顶尖伙伴共同设计

开源在任何一层都不是附加项，而是基石：PostgreSQL、MySQL、MongoDB、Valkey、OpenSearch、Kafka、Weaviate、vLLM、SGLang、OpenCode、LangGraph、CrewAI。彻底的开源。你带上自己的模型权重、框架和工具。我们提供运行时。


让我们从底层开始，逐层介绍。


## 一、基础设施：掌握芯片，掌握经济


DigitalOcean 的全球布局现已覆盖 **19 个数据中心** 和 200 多个网络接入点，未来还将在 **堪萨斯城和孟菲斯** 上线更多资源。其中还包括我们首批**液冷机柜**，专为下一代高密度 GPU 工作负载而建。


DigitalOcean 的 **[里士满数据中心](https://blog.aidroplet.com/news/building-ai-factory-for-agentic-era-nvidia-gtc/)** **现已正式上线**，提供 **[NVIDIA HGX™ B300](https://www.aidroplet.com/product/b300/)** 和 **AMD** **Instinct™ MI350X** GPU 服务器，与整个集群中已在运行的 H100、H200、MI300/MI325 芯片并存。我们与 NVIDIA 和 AMD 在内核层面进行共同设计。我们不是转租算力，而是自己拥有硬件。所以你在 DigitalOcean 这儿用得越多，单次推理的成本就越实惠，而不会像在其他平台那样，用得越多越贵。

## 二、核心云：每个智能体之下的基础


每天都有数十万客户在 DigitalOcean 的核心云上运行：Droplets、Kubernetes (DOKS)、VPC 网络以及对象/块/网络文件存储。我们已将这些产品服务扩展以适应 AI 工作负载，包括无阻塞的 RDMA 网络结构、支持 RDMA 的 NFS，以及开箱即用的 VPC 原生推理。


在 Deploy 大会上，DigitalOcean 发布了Burstable CPU 和MicroVM Droplet，目前处于预览阶段。这些是基于 Firecracker 的实例，启动时间约 200 毫秒，非常适合智能体沙箱和轻量级、突发型工作负载。智能体需要 GPU 来思考，也需要 CPU 来执行。这两者 DigitalOcean 都有，而且现在它们的规格是真正按照智能体的实际行为来设计的。如果需要申请在预览阶段体验，可直接联系[卓普云（aidroplet.com）](https://www.aidroplet.com/)。

## 三、推理引擎：所有模型，一个端点


这是DigitalOcean彻底重建的一层。DigitalOcean与合作伙伴 Hippocratic AI 共同开发了它，其成果是当今市场上性能最高的推理引擎之一：在独立机构 Artificial Analysis 按 token 吞吐量进行的基准测试中，实现了[对 Qwen 3.5 和 DeepSeek V3.2 的最快推理](https://blog.aidroplet.com/tutorials/how-we-built-fastest-deepseek-minimax-qwen-on-blackwell-ultra)速度，这个推理速度超过了其他云平台。


以下是新功能：


- **推理路由器**（公共预览版）：一个偏好感知的控制平面，为每个请求选择最佳模型，在无需代码更改的情况下平衡成本、延迟和质量
- **专用推理**（正式版）：为生产工作负载提供预留容量，实现可预测的性能和经济效益
- **自带模型 (BYOM)**（正式版）：一项让你在我们的服务栈上托管自定义微调模型，并继承内核级优化的服务
- **多模态模型支持**（正式版）：在单一 API 上支持文本、图像、音频和视频
- **批量推理**（正式版）：专为异步工作负载（文档处理、评估运行、合成数据生成）而建，价格约为高峰无服务器定价的 50%
- **内容安全护栏**（正式版）：集成在推理层的策略控制
- **支持多模态的无服务器推理**（正式版）：单一 API，可缩容至零，仅按消耗的 token 付费
- **评估**（公共预览版）：依据黄金数据集或内置裁判模型进行自动化评分，让你可以在不盲目飞行的前提下切换模型
 
推理路由器是一个偏好感知的控制平面，为每个请求选择最佳模型，在无需触碰应用代码的情况下平衡成本、延迟和质量。与静态路由规则不同，它运行在一个专门构建的小语言模型上，能在 200 毫秒内解析意图，并根据实时的成本和延迟数据对候选模型进行排序，从而确保无论是凌晨 2 点还是下午 2 点，最合适的模型都能胜出。大多数 AI 构建者起初只使用单个前沿模型。一旦实现产品-市场契合 (PMF)，账单便会随用量线性增长，单位经济性迅速恶化。我们合作过的大多数成功 AI 公司都在生产环境中运行三个或更多的大模型。走在AI行业前沿的公司甚至运行二十个以上的模型。推理路由器让这一切成为可能，且无需重写代码。

以 [Celiums.AI](http://celiums.ai/) 为例，在通过推理路由器处理的 2920 万个 token 中，他们 83% 的流量现在流向了开源模型，而此前这个数字是零。


> “我们的 AI 伦理引擎是用开源 AI 构建的，所以将其运行在闭源模型上感觉非常违和。DigitalOcean 的推理路由器闭合了这个循环：我们将前沿闭源模型替换为开放的替代模型，单 token 成本降低了 61%，同时将 P95 延迟保持在 400 毫秒以下。同样的 API，零代码更改。路由器为每个请求找到最优模型。我们只管构建。”
> 
> **—— Mario Gutiérrez**，Unity Financial Network 首席技术官，[Celiums.AI](http://celiums.ai/) 创始人



我们还为模型目录新增了超过 25 个新模型，包括：


- **NVIDIA Nemotron 3 Nano Omni**
- **DeepSeek V3.2**
- **Llama 3.3 70B**
- **Qwen 3.5**
- **MiniMax-M2.5**

## 四、数据与学习：AI 就绪的数据，无需重建


有状态的智能体需要上下文、记忆，以及从生产环境中学习的能力。数据与学习层建立在成千上万客户已经信赖的托管服务之上，并针对 AI 系统的实际运行方式进行了扩展。


新功能包括：


- **知识库**（正式版）：托管检索，提供有依据、带引用的答案；默认情况下，每个知识库都作为一个 MCP 工具暴露
- **学习与反馈循环**（正式版）：捕获生产信号并将其引导回模型改进流程，无需单独的数据管道
- **托管 Weaviate**（私有预览版）：开源向量存储，全托管
- **PostgreSQL** **高级版** 和 **MySQL** **高级版**（公共预览版）：容量可达 50 TiB，数分钟内完成 1 TiB 的扩缩，基于代理的秒级故障转移，以及超过 100 项可观测性指标


事务性数据库依然是 AI 的基础。我们使其达到了智能体时代的生产级水准。


## 五、托管智能体：一个生产运行时，而非单体


这是全栈最新的一层，也是我们花最长时间倾听的一层。我们观察到客户在 [App Platform（应用托管平台）](https://www.aidroplet.com/product/app-platform/)上将智能体作为容器部署了成千上万个。我们也看到，当智能体的循环、工具调用、状态、可观测性和代码执行都缠绕在一个单体中时，他们就会碰壁。


于是我们问了一个简单的问题：什么能帮你们真正跑得更快？答案就是托管智能体：五个原语（_Primitives_），将“管道”与智能体的业务逻辑分离开来。


新功能包括：


- **托管智能体**（正式版）：生产运行时
- **开放式框架 (Open Harness)**（正式版）：可带入你自己的智能体框架，包括 OpenCode、LangGraph、CrewAI 或任何其他框架
- **托管沙箱**（正式版）：兼容 E2B，基于 Firecracker，亚秒级冷启动，安全执行模型生成的代码
- **持久状态管理**（正式版）：框架可以信赖的检查点和内存原语
- **Plano**（正式版）：我们的智能体编排框架和数据平面，以 Apache 2.0 协议发布
- **Launchpad**（正式版）：点击几下即可从原型到部署智能体
- **模型上下文协议 (MCP)**（正式版）：在整个平台上扩展支持
- **ToolBox**（即将推出）：超过 3000 个工具连接器，让你的智能体能够在你业务实际运行的系统上执行操作


## 全栈的复合效应


这个技术栈中的任何单独一层都能独立发挥作用。而将它们整合在一起运行的理由在于，优化效果会复合叠加。

当你的AI 智能体、AI 推理、数据和计算位于同一个 VPC、运行在同一块芯片上、出在同一张账单下时，你就消除了一般因缝合三家供应商和三份账单而产生的出口流量费、成本叠加以及集成成本。

我们见证过像 [Workato](https://blog.aidroplet.com/news/workato-nvidia-technical-deep-dive-agentic-inference-cloud/) 这样的客户，以降低 67% 的成本运行一万亿次自动化任务。[Character.AI](https://blog.aidroplet.com/news/DigitalOcean-AMD-GPUs-Delivers-2X-Performance-for-Character/) 每天处理超过十亿次查询，推理吞吐量提升 2 倍。LawVo 通过转用我们的服务，零代码更改即降低了 42% 的推理成本。Hippocratic AI 正为超过 2000 万次患者互动提供支持，延迟降低了 40%。这些都不是演示，而是规模化运行的生产工作负载。

## 从这里开始，在这里扩展


如果你是一名 AI 构建者，无论你是在写第一行代码，还是正加速跨越产品-市场契合点，这个栈都为你而建。你无需在超大规模云厂商的队列中排在前沿实验室后面苦等。你无需将一家新型云、一个推理包装器和一个向量数据库厂商强行拼接起来。你无需在开放性、经济效益或开发者体验上做出妥协。


欢迎来到 AI 原生云。一起构建吧。如需了解更多，或申请测试，可直接联系[卓普云](https://www.aidroplet.com/)。

images.svg

智能体爆发，传统云失效，AI原生云成为新基础设施

AI 正在变成智能体，传统云不够用了：DigitalOcean 的新解法

人工智能行业存在一个复合型的瓶颈，而这个瓶颈并非模型本身，而是推理。

过去仅仅是一次模型调用，如今已演变成一个持续交互的系统。现在的应用程序会编排多个模型，检索并合成数据，执行工具，并在生产环境中重复这一循环。这些不再是“无状态请求”，而是更像基础设施而非软件特性的动态系统。

**以下四个变化正在重新定义基础设施必须具备的能力：**

- 推理已取代训练成为重心
- 推理模型正成为默认选择
- 自主智能体正在大规模运行
- 开源模型正以极低的成本达到与闭源模型相当的质量

大多数技术栈从未为此而设计。超大规模云服务商提供了数百种服务，但依然需要将它们拼接在一起。推理提供商则坐落在别人的算力之上，额外增加了一层利润空间。GPU 供应商提供芯片，但不提供系统。

**推理已悄然成为现代技术栈中最昂贵、却又最无人真正掌控的一层**。每一项新能力都被叠加在一个碎片化的基础之上，而其底层的复杂性则在不断累积。

**最终，你遇到的问题不再是模型问题，而是技术栈的问题。**

今天，在 Deploy 2026 大会上，DigitalOcean 发布了[ DigitalOcean 的 AI 原生云](https://www.digitalocean.com/)，这是一个面向生产级AI工作负载的全栈系统。

DigitalOcean 的 AI 原生云建立在 DigitalOcean 的核心云服务之上，涵盖计算、存储、网络和托管服务，并针对AI系统在实际生产中的运行方式，扩展了专门设计的能力。

目标很简单：精简技术栈，让构建者能够专注于构建，而不是把各种系统拼凑在一起。

在这里，开源不是附加功能，而是基础。DigitalOcean 去除了不必要的抽象层，消除了供应商之间的利润叠加，让开发者可以直接访问构建和扩展AI系统所需的原语。

这并非空谈。像 [Workato](https://blog.aidroplet.com/news/workato-nvidia-technical-deep-dive-agentic-inference-cloud/) 这样的客户在 DigitalOcean 上运行了**数万亿次自动化任务**，成本降低了67%。[Character.ai](https://blog.aidroplet.com/news/DigitalOcean-AMD-GPUs-Delivers-2X-Performance-for-Character/) 部署于DigitalOcean 云平台上，**每天处理超过 10 亿次查询**，推理吞吐量提高了2倍。Hippocratic AI 医疗平台支持超过 2000 万次患者交互，延迟降低了40%。这三个客户案例表明 DigitalOcean AI 原生云已在生产环境中稳定运行。

## 面向现代AI系统的五层技术栈

AI应用程序不是单一系统，而是由多个相互作用的层组成，这些层必须持续协同工作。

DigitalOcean AI 原生云将这五层整合为一个统一的系统，包括 托管式Agents、数据与分析、推理引擎、核心云服务、基础设施。（如下图所示）

![Paddy Blog Image 2.png](https://blog.aidroplet.com/uploads/Paddy_Blog_Image_2_9b86b993e5.png)

## DigitalOcean AI原生云的新增能力

这些并非概念上的层次，而是实际运行的系统。DigitalOcean 正在扩展产品服务，提供涵盖推理、数据和存储的生产级能力，使其能够大规模运行。

**Inference Router（推理路由器，公测版）**  

一个具备策略感知能力的控制平面，可根据**成本、延迟、质量与数据合规性**动态路由请求。  
团队无需硬编码模型逻辑，只需定义意图，系统即可在不同模型提供商和部署方式之间自动优化执行路径。

例如，LawVo 运行着 130+ AI 智能体，每周处理超过 5 亿 Token，在无需修改代码的情况下，将推理成本降低了 42%。

**专用推理与 Bring Your Own Model**

支持在专用 GPU 基础设施上运行自定义或微调模型，全面掌控性能、扩展和配置。

开发者可以从 Hugging Face 或自有环境部署模型，通过预调优的推理栈和托管编排，实现高吞吐运行，而无需承担 Kubernetes 的复杂性。

**扩展模型与服务**  

通过统一系统运行和评估文本、图像、音频和视频模型。

模型库持续更新，包含 25+ 新模型，并支持“Day 0”首发接入，例如 NVIDIA Nemotron 3 Nano Omni（在 DigitalOcean 首发）。该高效开源多模态模型整合视觉、语音、语言与工具调用能力，并通过 NVIDIA TensorRT-LLM 在内核层优化。

内置评估工具可在上线前对质量、成本和延迟进行基准测试。

**PostgreSQL和MySQL高级版（公测）**  

托管式PostgreSQL和MySQL高级版提供超大规模云服务商级别的可靠性和扩展能力，与标准版并行提供。

**托管式 Weaviate（预览版）**  

提供可用于生产环境的**向量数据库基础设施**，无需运维负担，并与 Serverless Inference 原生集成，具备可预测定价。

**Knowledge Bases（知识库）**  

一个完全托管的 RAG 服务，处理数据摄取、分块、嵌入、检索和重排序，并为智能体框架提供 MCP 支持。让你的团队只需几天就能从原型走向生产。

**旨在简化，同时不限制灵活性**

优势并不在于任何一个单独的层，而在于它们如何协同工作。

当智能体、推理和数据运行在同一个系统上时，性能和成本方面的优化会自动相互叠加。技术栈变得能够自我强化，而不是碎片化。

与此同时，灵活性得以保留。开放的 API 和与现有工具的兼容性，使得采用新模型、集成外部系统以及根据需要演进架构变得容易。

**展望未来**

从本地部署到云计算的转变催生了 AWS。从云到 SaaS 的转变催生了 Salesforce。而从云原生到 AI 原生和智能体原生应用的转变，将催生下一家伟大的基础设施公司。DigitalOcean 志在于此。

五层技术栈。一个平台。层层开放。今天就让我们与开发者一起构建吧。

medium_luke-jones-tBvF46kmwBw-unsplash.jpeg

small_luke-jones-tBvF46kmwBw-unsplash.jpeg

thumbnail_luke-jones-tBvF46kmwBw-unsplash.jpeg

xsmall_luke-jones-tBvF46kmwBw-unsplash.jpeg

luke-jones-tBvF46kmwBw-unsplash.jpeg

DigitalOcean 推出 AI 原生云，整合推理、数据与模型，简化技术栈，降低成本与复杂度，助力 AI 应用快速规模化落地。

DigitalOcean 打造 AI 原生云，帮助 AI 应用大幅降低成本与运维复杂度

DigitalOcean 正在全力构建全球领先的**Agent 推理云**。我们的使命很清晰：为 AI 原生企业提供一个坚实底座，让它们能在生产环境中大规模运行推理任务。今天，我们正式宣布收购 AI Agent 基础设施领域的领先公司 [Katanemo Labs, Inc.](https://www.katanemo.com/)。

通过这次整合，我们将平台能力进一步下沉到Agent系统最关键的运行层。Katanemo Labs 的技术与 DigitalOcean 一贯坚持的理念——运维简单、成本可控、性能可扩展——高度契合。同时，我们非常高兴地欢迎 Katanemo Labs 联合创始人兼首席执行官 Salman Paracha 加入 DigitalOcean，担任 AI 业务高级副总裁。他和他的团队在模型研究及开源基础设施开发方面积累深厚，将极大加速我们为开发者打造“可用于生产环境的Agent推理云”这一目标的实现。

## 跨越生产落地鸿沟

2025 年，AI 的重心已经从实验探索转向了生产应用。随着行业逐步走向真实场景部署，最棘手的挑战也不再是模型获取和准确率，而是如何在大规模环境下运行稳定、安全且可观测的系统。

- 根据我们发布的 [Currents](https://www.digitalocean.com/currents/february-2026) 研究报告，**61% 的开发者**认为，缩小原型与生产之间的差距是他们当前最大的难题。
- [麦肯锡研究](https://www.mckinsey.com/~/media/mckinsey/business%2520functions/quantumblack/our%2520insights/seizing%2520the%2520agentic%2520ai%2520advantage/seizing-the-agentic-ai-advantage.pdf) 显示，成功走出试点阶段的 AI 用例占比不足 **10%**。

- 同一份研究还指出，**可观测性** 是实现大规模、智能化AI Agent生态系统安全运行的关键能力。


通过将 Katanemo Labs 纳入 DigitalOcean，我们正在直面这一“生产落地鸿沟”。我们将提供 AI 领域的核心基础组件——例如编排、工作流执行和安全机制——让多Agent系统变得可靠、可观测，并能快速转化为稳定、可用的业务资产。

## 数据平面与可观测性创新，加速AI Agent技术栈演进

本次收购的核心，是一项与框架无关的专有数据平面技术，它源自 Plano 开源项目。

Plano 相当于Agent系统的“NoOps”层，负责屏蔽底层复杂性，让工程团队可以专注于构建AI Agent的核心逻辑。生产级别的执行全部自动完成，从而为开发者提供他们最需要的可预测性和性能，帮助他们放心地扩展规模。

此外，[Katanemo Labs 在AI Agent可观测性方面的研究](https://arxiv.org/abs/2604.00356)及其基于信号的创新成果，也让我们倍感振奋。

这套基于信号的方法，可以提前洞察AI Agent在生产环境中的行为。通过将生产环境中的追踪数据转化为可操作的行为洞察，我们为团队提供了一种高效手段：识别有价值的信息交互、定位故障原因，并在部署后持续优化 AI Agent表现。

## AI 原生企业的统一平台

Katanemo Labs 的小型行动模型（例如 Arch-Agent 系列），以其在实际应用中的灵活性和高性能，很好地补充了其数据平面软件。通过整合这些模型，我们确保 AI 团队不必忍受碎片化 AI 技术栈带来的复杂性和“成本堆叠”。此次收购让我们的客户能够轻松获得为 AI Agent量身打造的基础组件，从而缩短上线时间，降低运维成本。

DigitalOcean收购Katanemo Labs，解决AI从原型到生产的落地难题。

DigitalOcean 收购 Katanemo Labs：迎接 Agent 时代，重塑基础设施

别再让简单问题消耗昂贵算力，用推理路由为每次请求找到最合适的模型。

AI 成本太高怎么办？用推理路由自动分配 Claude、Qwen、DeepSeek

large_images.png

medium_images.png

small_images.png

thumbnail_images.png

xsmall_images.png

images.png

用 DigitalOcean 无服务器推理与推理路由，为 Hermes Agent 搭建单一端点、多模型智能调度，降本增效。

如何在无服务器推理上运行 Hermes Agent？



> “你用了什么大模型，用了多少大模型并不重要。你的基础设施才是核心。”

在AI产品圈，我们似乎陷入了一种“模型焦虑”：今天 GPT 更新了，明天Claude 推理更强了，后天某个开源模型在榜单上屠榜了。产品经理忙着追新Prompt，开发者连夜切API。但如果我们换个视角，把时间轴拉长到产品全生命周期，会发现一个反直觉的真相：**当模型逐渐标准化、商品化，真正决定AI应用能否存活、能否盈利、能否规模化扩张的，根本不是模型本身，而是你底层的AI基础设施（AI Infrastructure）。**

本文将从AI产品经理与开发者的实战视角，拆解一条从“第1天”到“第1000天”的基建演进之路。从中你会发现，AI产品能否走得远，模型并不是关键。

## 先搞懂这 4 类AI推理服务

在深入架构演进前，先用最直白的方式统一 4 个高频术语。理解它们，能帮你避开早期的选型大坑。

### 1、无服务器推理（Serverless Inference）

**「用完即走，按量付费」**。 你不需要管理任何服务器，只需调用 API 发送请求，平台自动分配资源并**按实际消耗的 Token 计费**。 
**适合**：产品冷启动、流量波动大、快速试错场景。 
**注意**：高并发时单价较高，且延迟可能受共享资源影响。

### 2、专用推理（Dedicated Inference）

**「包下一台专属服务器，性能独享」**。 你独占一组 GPU 资源，**按运行时长（如每小时）付费**，无论是否有请求，费用固定。 
**适合**：流量稳定且高并发、对延迟敏感、需要部署自定义模型的企业场景。 
**注意**：流量低谷时资源闲置会产生浪费，需做好容量预估。

### 3、智能路由 / 推理路由（Inference Router）

**「AI 请求的交通指挥中心」**。 它不直接运行模型，而是根据**成本、速度、任务难度**，自动把每个请求分发给最合适的模型（例如：简单文本处理问题走便宜小模型，复杂推理问题走高端大模型）。 
**核心价值**：在不牺牲体验的前提下，通过「好钢用在刀刃上」的策略，通常可降低 30%~80% 的推理成本。

### 4、推理引擎（Inference Engine）

**「真正干活的底层执行器」**。 它是运行在服务器上的软件栈（如 vLLM、TGI），负责把模型高效地「跑起来」，直接决定**首字延迟、吞吐量和显存利用率**。 
**开发者视角**：通常无需直接操作，但在追求极致性能或自托管时，引擎选型可能带来 2~5 倍的效率差异。



## 第一阶段（Day 1）：唯快不破，用“无服务器”架构抢占先机

在产品冷启动阶段，核心目标只有一个：**验证PMF（产品市场契合度），抢占市场先机。** 此时，过度设计基础设施是致命的。

### 1. 天下武功，唯快不破
Day 1 的架构哲学是 **Serverless Inference（无服务器推理）**，也就是使用那些可以直接调用的模型推理服务。你不需要管理GPU集群，不需要考虑显存分配，更不用写复杂的并发控制代码。通过单一API端点，即可即时调用70+顶级模型。对于开发者而言，这意味着你可以把90%的精力放在业务逻辑和用户体验上，而不是底层运维。

### 2. 三天升级基础模型能力
很多团队以为“接入大模型”就是调个对话接口。但在无服务器推理服务下，基础模型的升级可以按“步骤”模块化完成：
* **步骤1：统一入口**——通过单一端点聚合多模型，灵活切换，避免供应商锁定。
* **步骤2：网络搜索增强**——仅需3行代码，即可为模型赋予实时联网查询能力，解决大模型“幻觉”与“信息滞后”痛点。
* **步骤3：MCP工具链接入**——无缝对接Model Context Protocol，让AI直接执行真实账户操作（如查订单、改配置、发邮件），从“聊天机器人”进化为“智能体（Agent）”。

**建议：** 第1天不要追求“完美架构”。用Serverless Inference快速跑通MVP，验证用户是否愿意为你的AI价值买单。速度，就是早期的护城河。



## 第二阶段（Day 50）：流量引爆点，当“按Token计费”撞上成本墙

产品上线后，流量开始自然增长或投放起量。恭喜你，产品跑通了。但别急着开香槟，**规模化引爆点（Scaling Tipping Point）** 往往也是成本失控的起点。

### 1. 无服务器 vs 专用推理：计费模式的十字路口
当请求量飙升，纯Serverless架构的“按Token计费”模式开始显现弊端：
* **无服务器推理**：按Token计费、即时访问、共享端点。适合低并发、波动大的场景。
* **专用推理**：按小时计费、独享GPU实例、成本可预测。适合高并发、稳定负载的场景。

视频中的临界点图表揭示了一个关键规律：**开源中等参数模型（如12B）转向专用GPU的成本临界点，远低于昂贵的尖端前沿模型。** 这意味着，当你大量使用高性价比开源模型处理常规任务时，自建/租赁专属GPU实例反而更省钱。

### 2. 智能推理路由器：AI时代的“交通指挥中心”
面对日益复杂、多样化的工作负载，盲目调用最强模型既不经济也不高效。这时，**智能推理路由必须登场。

它是一个动态调度系统，能根据**成本、速度、任务优先级**的平衡，将每个AI请求自动分配给最理想的模型。例如：

| 任务类型 | 优先级策略 | 被选模型 | 逻辑 |
|:---|:---|:---|:---|
| 密码重置 | 成本效益 | OSS 12B | 简单规则任务，无需昂贵算力 |
| 代码Bug修复 | 最佳平衡 | DeepSeek 32B | 需较强逻辑推理，兼顾成本与质量 |
| 会议总结 | 速度优先 | Gemma 4 | 对延迟敏感，快速吞吐即可 |

通过路由调度，团队可实现高达 **80% 的推理成本优化**。AI基建不再是“后台支撑”，而是直接参与利润表的“财务引擎”。


## 第三阶段（Day 500）：企业级规模，云原生架构的长期博弈

当产品进入成熟期，面临海量企业级请求、SLA保障要求、数据合规与多租户隔离时，基础设施的复杂度呈指数级上升。此时的架构关键词是：**混合部署、弹性兜底、云原生。**

### 1. 基础设施的演进路径
* **Day 1**：无服务器推理（Token计费，极速启动）
* **Day 50**：无服务器推理 + 智能推理路由器（成本与性能动态平衡）
* **Day 500**：专用GPU + 无服务器兜底 + 智能路由器全局调度

在Day 500阶段，成熟的AI平台会采用**混合基础设施**：核心高优任务跑在专用GPU集群上保障低延迟与高吞吐；流量洪峰或长尾请求自动溢出（Fallback）到Serverless端点；智能路由器作为“大脑”，实时计算最优路径。

### 2. 从“烧钱买模型”到“基建省出利润”
早期团队把钱花在“买更好的模型”上，而成熟团队把钱花在“构建更聪明的调度系统”上。云原生架构的优势在于：资源池化、弹性伸缩、自动化运维。它让AI应用能够像水电一样按需取用，同时保持企业级的稳定性与安全性。



## 你在第1天随便选择的平台，到了第1000天还适合你吗？

这是一个所有AI产品负责人和架构师都必须直面的灵魂拷问。

很多产品在Day 1为了图快，随便接了一个API平台或用了个简陋的封装库。但当用户量突破十万、请求量达到千万级、成本压力倒逼财务红线时，才发现早期架构根本无法平滑演进，只能推倒重来，付出巨大的技术债代价。

给AI开发者的最后建议：
1. **产品初期**：拥抱Serverless，快字当头，验证价值。
2. **增长中期**：尽早引入路由层，建立成本模型，让每一分钱花在刀刃上。
3. **规模后期**：拥抱云原生与混合架构，把基础设施当作产品核心功能来设计。

AI的下半场，拼的不是谁的模型参数更大，而是谁的**基础设施更聪明、更弹性、更懂商业逻辑**。别卷模型了，选择正确的云基础设施才是节省成本、提升AI推理性能的关键。


你用了多少大模型并不重要。你的基础设施才是核心。

AI 推理产品省钱指南：如何通过基建优化降低 80% 推理成本？


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

---

## 什么是 DigitalOcean 推理引擎？

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

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

| 模式 | 一句话总结 |
|------|-----------|
| **Serverless Inference** | 发请求、按 token 付费、重复调用 |
| **Dedicated Inference** | 创建一个完全由你控制的私有 GPU 端点 |
| **Batch Inference** | 将数千条 prompt 作为单一夜间任务批量处理 |
| **Inference Router** | 自动将每个请求路由到成本和速度最优的模型 |

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



## 无服务推理 Serverless Inference

### 按 token 计费，按模型计费

[Serverless Inference](https://www.aidroplet.com/product/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 写作助手](https://www.digitalocean.com/resources/articles/ai-writing-tools)。他们不知道下个月会有多少用户。Serverless Inference 让他们今天就能发货，只为实际使用的部分付费，无需预留可能会闲置的 GPU。当流量增长到可预测的基础水平时，他们可以迁移到 Dedicated Inference 以获得更好的单位经济效益。



## 专用推理 Dedicated Inference

### 按 GPU 运行时间计费

[Dedicated Inference](https://www.digitalocean.com/blog/dedicated-inference-technical-deep-dive) 为你提供一个私有、单租户的 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）](https://www.digitalocean.com/blog/powering-the-inference-era)用于微调 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](https://docs.digitalocean.com/products/inference/how-to/use-batch-inference/) 适用于你有大量工作要做、但没有任何任务需要立即完成的情况。你不需要一个一个发送请求并等待每个响应，而是将所有内容打包成 JSONL 文件，作为单一任务提交，然后在完成后回来取结果，通常在 24 小时内。

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

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

### 最佳适用场景

- 大规模文档分类
- 隔夜数据富化管道
- 针对大型测试集运行模型评估套件
- 构建 [RAG 知识库](https://www.digitalocean.com/resources/articles/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](https://docs.digitalocean.com/products/inference/how-to/use-inference-router/) 位于你的模型前方，自动根据任务类型、当前延迟和成本决定每个传入请求应由哪个模型处理。路由不再将每个请求都发送到最昂贵的前沿模型，而是将复杂度与能力匹配。

它构建在 [Plano](https://github.com/katanemo/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 查询发送到小型、快速的开源模型。他们的月推理账单下降，而应用代码无需任何更改。



## 四种模式横向对比

|  | Serverless | Dedicated | Batch | Router |
|--|-----------|-----------|-------|--------|
| **响应类型** | 实时 | 实时 | 异步（最长 24h） | 实时 |
| **定价模式** | 按 token | 按 GPU 小时 | 折扣 token | 底层使用量 |
| **基础设施配置** | 无需配置 | 选择 GPU 和模型 | 无需配置 | 配置任务 |
| **自定义/微调模型** | 不支持 | 支持（BYOM） | 不支持 | 通过 Dedicated 端点支持 |
| **延迟特征** | 共享基础设施上可变 | 隔离 GPU 上更可预测 | 不适用 | 取决于所选目标模型 |
| **可缩容至零（无闲置成本）** | 是 | 否（按小时计费） | 是 | 是 |
| **最佳成本场景** | 低或可变流量 | 高稳定状态 | 任何高容量离线工作 | 混合任务类型 |
| **OpenAI 兼容 API** | 是 | 是 | 是 | 是 |
| **认证令牌** | 模型访问密钥（或 PAT） | Dedicated 端点访问令牌 | 模型访问密钥 | 模型访问密钥（或 PAT） |
| **开源模型支持** | 是 | 是 | 仅 OpenAI 和 Anthropic | 是 |



## 如何选择使用哪种模式？

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

**你需要立即得到结果，还是可以等几小时？**
如果可以等 → **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](https://cloud.digitalocean.com/model-studio)
- **完整文档：** [docs.digitalocean.com/products/inference](https://docs.digitalocean.com/products/inference/)
- **Serverless 快速入门：** [使用 Serverless Inference](https://docs.digitalocean.com/products/inference/how-to/use-serverless-inference/)
- **Dedicated 快速入门：** [使用 Dedicated Inference](https://docs.digitalocean.com/products/inference/how-to/use-dedicated-inference/)
- **Batch 快速入门：** [使用 Batch Inference](https://docs.digitalocean.com/products/inference/how-to/use-batch-inference/)
- **Router 快速入门：** [使用 Inference Router](https://docs.digitalocean.com/products/inference/how-to/use-inference-router/)
- **定价详情：** [推理定价](https://docs.digitalocean.com/products/inference/details/pricing/)
- **API 参考：** [DigitalOcean AI Inference API](https://docs.digitalocean.com/products/inference/reference/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 推理引擎官方文档](https://docs.digitalocean.com/products/inference/)
- [Serverless Inference 产品页](https://www.digitalocean.com/products/inference-engine)
- [Dedicated Inference 技术深度解析](https://www.digitalocean.com/blog/dedicated-inference-technical-deep-dive)
- [推理时代：DigitalOcean AI 原生云内部解读](https://blog.aidroplet.com/product-updates/powering-the-inference-era/)


large_images (2).jpeg

medium_images (2).jpeg

small_images (2).jpeg

thumbnail_images (2).jpeg

xsmall_images (2).jpeg

images (2).jpeg

对比 Serverless、Dedicated、Batch 和 Inference Router 四种AI推理服务，帮你从AI开发的第一天起就做出明智的选择。

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

介绍DigitalOcean VPC网络故障排查runbook，含诊断工具与自动化函数。



DigitalOcean VPC 网络故障排查 Runbook 实战指南

AI 基础设施的版图已经告别了过去那种“租台机器装驱动”的单一模式。现在的开发者面临的是一个完全分裂的市场，每一层都在试图定义 AI 开发的最优路径。

目前的市场主要由三股力量驱动：以 **AWS** 为代表的传统云巨头，它们大而全，但往往带着厚重的历史包袱；以 **Together AI** 为代表的新兴 AI 聚合平台，它们主张“基础设施不可见”，让开发者只看 API；以及以 **DigitalOcean** 为代表的[ AI 原生云](https://blog.aidroplet.com/product-updates/powering-the-inference-era/)，它们正试图在原始算力与极致聚合之间，为开发者找到一个既能全栈托管又能深度控制的“第三空间”。

举个例子，在 Together AI 这样的平台上，你不再需要关心 GPU 是怎么联网的，直接调用一个 API 就能得到结果。这对于验证想法和快速原型开发来说简直是福音。然而，当你的应用从简单的对话框演变成一个包含检索流水线（RAG）、持久化记忆和复杂代理（Agents）的系统时，这种“过度隐藏”的弊端就会显现：你发现自己很难优化跨组件的延迟，也没法触达底层的网络配置。

这时，开发者往往会陷入两难：是去 AWS 忍受复杂的 IAM 权限和繁杂的配置，还是寻找一个既懂 AI 又不失灵活性的原生环境？

### 核心观察：AI 基础设施的三大阵营

1. **传统云（如 AWS）：功能森林里的重型武器**
    
    它们拥有最深的产品护城河，从 S3 到 SageMaker 样样都有。但问题在于，这些工具并非为“AI 优先”设计的，而是作为原有生态的插件。在这些平台上，你可能需要花费 40% 的精力去对付与 AI 业务无关的云资源管理。
    
2. **新 AI 平台（如 Together AI）：极致的“拿来主义”**
    
    它们把 GPU 算力封装成了类似水电的公共服务。你不需要理解 H100 的架构，只需要知道并发量和 Token 价格。这种模式极大降低了准入门槛，但它也设定了一个隐形的天花板：当你的业务需要精细化的模型微调或复杂的私有网络部署时，平台提供的“黑盒”可能会限制你的发挥。
    
3. **AI 原生云（如 DigitalOcean）：回归控制权的全栈进化**
    
    DigitalOcean 现在的定位非常明确——**Powering the Inference Era**（驱动推理时代）。它不再仅仅提供一个存放代码的“水滴”虚拟机，而是将 GPU 计算、向量数据库、智能体编排以及低延迟网络整合成了一个原生闭环。它保留了传统云的控制力（你可以拥有 root 权限），又具备了 AI 平台才有的开箱即用感。
    



### 为什么“状态管理”决定了你的架构选择？

在 AI 开发中，有一个分水岭：**无状态（Stateless）** vs **有状态（Stateful）**。

- **无状态**就像自动售货机：你投币（输入 Prompt），它掉出饮料（输出结果），任务结束，两不相欠。Together AI 这种推理 API 完美契合这一场景。
- **有状态**则像和老友聊天：他记得你上次说过的烦恼，能翻看你们的聊天记录。在生产环境下，一个 RAG 系统或 AI 助手必须处理大量的“状态”——向量搜索的上下文、用户的对话历史、正在运行的任务流。


**新兴 AI 平台**通常针对无状态任务做了极致优化，它们处理单次推理飞快。但如果你要构建复杂的有状态应用，你往往得在平台外拼凑各种外部数据库，导致系统像个“补丁架”。

**AI 原生云（DigitalOcean）** 的逻辑则不同。它默认你的系统是有状态的。通过将带有 `pgvector` 的托管数据库（存储记忆）、[GPU Droplets ](https://www.aidroplet.com/product/gpu/)和私有网络（VPC）放在同一个物理边界内，它消除了跨平台调用的延迟。这种“同地域部署”不仅是为了快，更是为了让系统在扩展时依然可控。



### 深入对比：三个平台的实战表现

| **维度**     | **Together AI (新兴 AI 平台)** | **AWS (传统云)**    | **DigitalOcean (AI 原生云)**    |
| ---------- | -------------------------- | ---------------- | ---------------------------- |
| **GPU 访问** | 完全抽象，只看 API 或端点            | 极致复杂，需申请配额和处理实例  | 直接、灵活，提供持久化的 GPU VM          |
| **冷启动**    | 无冷启动（Serverless 模式）        | 视服务而定（通常较慢）      | 零冷启动（机器始终在线）                 |
| **数据整合**   | 需对接外部向量库                   | 功能极多但配置极其繁琐      | 原生集成知识库、向量存储与 GPU            |
| **成本模式**   | 按 Token 计费，用多少付多少          | 复杂的按需+预留+流量费     | 简单透明，Droplet 固定小时费率，也支持中长期合约 |
| **开发者体验**  | **极简**：几行代码即可调用            | **沉重**：需要专门的运维知识 | **平衡**：专注 AI 逻辑，无需管底座        |
| **最适合人群**  | 想快速上线、不想管机器的团队             | 对合规和复杂生态有极高要求的巨头 | **构建全栈 AI 应用、追求性能一致性的团队**    |



### 给开发者的建议：基础设施不是一次性决策

一年前，开发者习惯于先在本地跑通，再扔到云端。但现在，基础设施的选择正直接影响产品的边界。

如果你正在做一个简单的文本生成小工具，**Together AI** 的 API 是最明智的选择，它能让你在 5 分钟内起步。但当你的业务规模逐渐变大，使用的模型数量越来越多，你会发现这类平台的成本会越来越高，维护也将越来越复杂。

但如果你正在构建一个面向企业、需要处理海量私有文档、且对响应速度有极致要求的 **AI 助手**，那么 **DigitalOcean** 这样的 AI 原生云会更有后劲。它让你不必在“过度抽象”带来的限制和“传统云”带来的繁琐之间二选一，而是提供了一个专门为 AI 推理时代优化的底座。

**最后的话：**

最好的 AI 系统，不一定是用最贵的 GPU 堆出来的。而是那些能够深刻理解业务中的“状态”分布，并在控制权与便利性之间找到平衡点的团队，才能在推理时代跑得更稳。

传统云架构已无法满足AI业务的发展需求；新兴的AI聚合平台又存在基础设施方面的不足；AI原生云正成为越来越多AI团队的选择。

如何选择 AI 基础设施：传统云 (AWS) vs. AI 聚合聚合 (Together AI) vs. AI 原生云 (DigitalOcean)

在今天举办的 Deploy 大会上，DigitalOcean 正式宣布 DeepSeek V3.2、MiniMax-M2.5 和 Qwen 3.5 397B 在 DigitalOcean Serverless Inference （AI推理云平台）上全面可用。DigitalOcean 推理云上的DeepSeek V3.2 和 Qwen 3.5 397B ，在参与[Artificial Analysis 测试](https://artificialanalysis.ai/) 的所有云中实现了 **第一名 的输出速度**。具体到 DeepSeek V3.2，这意味着在 10,000 个输入 token 的情况下，输出速度达到 230 token/秒，首 token 时间（TTFT）低于 1 秒。

这篇文章将讲述DigitalOcean是如何做到这一点的：GPU 层面的工作、服务栈的调优，以及在此过程中做出的具体技术取舍。

## 为什么快速推理很重要

AI 开发的重心已经从模型训练根本性地转向了推理效率。这一转变是由智能体工作负载、Copilot 以及实时系统（这些构成了下一代 AI 应用的核心）的普及所驱动的。对于这些应用而言，速度不再仅仅是一个性能指标，它是决定一个产品是引人入胜还是被用户弃用的关键区别因素。具体来说，低延迟推理对于无缝的终端用户体验至关重要。对于对话式智能体、语音界面等高度交互的应用，任何超过 1 秒 TTFT 的延迟都会让用户感到卡顿。

快速推理的重要性因现代 AI 工作流的复杂性而进一步放大。例如，一个智能体任务往往涉及数十次顺序模型调用，即使每次调用微小的每输出 token 时间（TPOT）延迟，累积起来也会变成用户可见的几秒钟延迟。快速推理还能为企业提供可靠的性能和更低的成本。在此领域的优化（例如 DigitalOcean 推理引擎所提供的）使企业能够获得卓越的 token 经济性、持续的高吞吐量和可预测的低延迟，这对于以可靠且经济的方式扩展其 AI 原生应用至关重要。

## 在 Artificial Analysis 速度基准测试中领先

DigitalOcean今天发布的基准测试结果反映了这一点。在 10K 输入 token 的 DeepSeek V3.2 上，DigitalOcean实现了：

- **输出速度**：230 token/秒（AWS Bedrock 为 59 token/秒，DigitalOcean是其 3.9 倍）
- **TTFT**：0.96 秒（在测试的 12 家提供商中，仅 Google Vertex 比DigitalOcean更快）
- **延迟与输出速度之间的均衡性能**：在 Artificial Analysis 的延迟 vs. 输出速度象限图中，DigitalOcean 是仅有的三家位列最优象限的提供商之一。

![AA blog DeepSeek V3.2 non-reasoning.png](https://blog.aidroplet.com/uploads/AA_blog_Deep_Seek_V3_2_non_reasoning_e9cb1748ad.png)
*图 1：DeepSeek V3.2 非推理版，各提供商输出速度对比。来源：[Artificial Analysis](https://artificialanalysis.ai/models/deepseek-v3-2/providers#output-speed)，2026 年 4 月。*

![AA blog graph2 final.png](https://blog.aidroplet.com/uploads/AA_blog_graph2_final_f272a54386.png)
*图 2：DeepSeek V3.2 推理版，各提供商输出速度对比。来源：[Artificial Analysis](https://artificialanalysis.ai/models/deepseek-v3-2-reasoning/providers#output-speed)，2026 年 4 月。*

![AA blog latency vs output deepseek v3.2.png](https://blog.aidroplet.com/uploads/AA_blog_latency_vs_output_deepseek_v3_2_e5b60c06d6.png)
*图 3：DeepSeek V3.2 推理版，延迟 vs. 输出速度象限图。来源：[Artificial Analysis](https://artificialanalysis.ai/models/deepseek-v3-2-reasoning/providers#latency-vs-output-speed)，2026 年 4 月。*

MiniMax-M2.5 和 Qwen3.5 397B 的性能数据类似：

![AA blog MiniMax-M2.5.png](https://blog.aidroplet.com/uploads/AA_blog_Mini_Max_M2_5_c6d98aac84.png)
*图 4：MiniMax-M2.5，各提供商输出速度对比。来源：[Artificial Analysis](https://artificialanalysis.ai/models/minimax-m2-5/providers#output-speed)，2026 年 4 月。*

![AA blog MiniMax-M2.5 quadrant.png](https://blog.aidroplet.com/uploads/AA_blog_Mini_Max_M2_5_quadrant_95eb3272fd.png)
*图 5：MiniMax-M2.5，各提供商延迟 vs. 输出速度对比。来源：[Artificial Analysis](https://artificialanalysis.ai/models/minimax-m2-5/providers#latency-vs-output-speed)，2026 年 4 月。*

![AA Qwen3.5 397B reasoning.png](https://blog.aidroplet.com/uploads/AA_Qwen3_5_397_B_reasoning_4df45350a6.png)
*图 6：Qwen 3.5 397B，各提供商输出速度对比。来源：[Artificial Analysis](https://artificialanalysis.ai/models/qwen3-5-397b-a17b/providers#output-speed)，2026 年 4 月。*

![AA Qwen3.5 397B reasoning quadrant.png](https://blog.aidroplet.com/uploads/AA_Qwen3_5_397_B_reasoning_quadrant_d5f52bdef4.png)
*图 7：Qwen 3.5 397B，各提供商延迟 vs. 输出速度对比。来源：[Artificial Analysis](https://artificialanalysis.ai/models/qwen3-5-397b-a17b/providers#latency-vs-output-speed)，2026 年 4 月。*

## 数字背后的工程

要达到这一性能水平，仅靠最前沿的 GPU 是不够的。在最新一代硬件上使用标准配置，往往无法在 Artificial Analysis 排行榜上登顶。为了取得这些成果，DigitalOcean对技术栈的每一层进行了协同设计和优化：精选高端 GPU、在虚拟化 NVIDIA Blackwell Ultra GPU 上最大化 CUDA 效率、实现推测解码，以及在速度与准确性之间取得最佳平衡的位置应用量化技术。

### 硬件：NVIDIA Blackwell Ultra 的强大性能

DigitalOcean性能突破的基础是 **NVIDIA HGX™ B300 GPU**。Blackwell Ultra 架构实现了巨大的飞跃，拥有 288GB HBM3e 容量（比 B200 增加 50%），以及 1.5 倍的 NVFP4 计算能力。这一硬件基础对于处理 DeepSeek 和 Qwen 的大规模吞吐需求至关重要。尽管在虚拟化环境中的早期部署导致性能下降了 25%，但DigitalOcean与 NVIDIA 的直接合作解决了这些问题，完全释放了 Blackwell 芯片的潜力。

### 模型量化：NVFP4 的高效性

DigitalOcean使用了模型的 NVFP4 量化版本，这是一种专门的 4 位浮点格式，可显著减少内存占用（相比 FP8 约减少 1.8 倍）并提高推理吞吐量。这些优势由 NVIDIA Blackwell Ultra 架构独家提供，该架构具有 1.5 倍的专用 NVFP4 计算能力，从而在几乎不影响模型精度的前提下实现巨大的性能提升。有关 NVFP4 精度与原始 FP8 模型权重的对比，请参阅 DeepSeek V3.2 的[模型评估](https://huggingface.co/nvidia/DeepSeek-V3.2-NVFP4#evaluation)。

然而，纯粹的芯片和量化只是故事的一半。要将这种硬件能力转化为世界级的推理速度，DigitalOcean必须实现高度定制化的软件栈。

### 推理引擎：vLLM 的性能优化

DigitalOcean通过一系列技术对开源 vLLM 服务框架进行了优化：

- **张量并行**：DigitalOcean使用了张量并行技术，将大型模型层分布到多个 GPU 上，这是运行超出单个 GPU 内存容量的模型所必需的技术，需要高速 GPU 互连。根据模型大小，DigitalOcean使用 TP4 或 TP8 配置，在 4 个或 8 个 GPU 上运行推理。
- **内核融合**：这项关键优化将多个运算融合到单个 GPU 内核中，从而最大限度地减少单个内核启动的开销，并减少 CPU 间隙。通过在芯片上执行这些合并后的运算，内核融合显著减少了较慢的片外内存访问，从而实现更快的处理速度。
- **可编程依赖启动（Programmatic Dependent Launch）**：DigitalOcean使用[可编程依赖启动](https://docs.nvidia.com/cuda/cuda-programming-guide/04-special-topics/programmatic-dependent-launch.html)技术，尽可能重叠内核，从而隐藏内核启动开销并减轻短运行内核的尾部效应。这使得低批量、低并发、高交互性工作负载的性能提升了约 10%。
- **推测解码与多 token 预测（MTP）**：DigitalOcean利用最新的模型特性，如 DeepSeek 的多 token 预测，来加速 token 生成，从而改善每输出 token 时间。MTP 被用作推测解码优化的一部分，以提高生成速度。该技术使用一个较小的草稿模型（MTP 头或 EAGLE 头）来预测 token 序列，然后由较大的目标模型在单次前向传播中进行验证，从而在保持主模型输出高质量的同时显著提高吞吐量。对于 MiniMax-M2.5，DigitalOcean使用 TorchSpec 训练了一个 EAGLE3 草稿模型——这是一个 torch 原生的在线推测解码训练框架，它同时运行 FSDP 训练和基于 vLLM 的目标推理，通过从 MiniMax-M2.5 重新生成的响应和实时的 vLLM 生成的隐藏状态中学习，来匹配基础模型的确切 token 分布。在部署时，DigitalOcean的实验表明，减少草稿模型的张量并行度可以最小化 GPU 间通信开销，从而提升性能。对于 MiniMax-M2.5，通过在配置中设置 `"draft_tensor_parallel_size": 1`，每输出 token 时间（TPOT）改善了 23%。

内核融合和草稿模型训练是与 [Inferact](https://inferact.ai/) 密切合作完成的。Inferact 是领先推理服务引擎 vLLM 的原创团队，他们的专业知识对于针对特定 GPU 和模型版本优化这些复杂工作负载起到了关键作用。

## 真实世界的性能

这些技术已经在为客户提供大规模推理服务的生产环境中运行。Workato 使用智能体 AI 扩展其生产自动化，处理超过 1 万亿次自动化工作负载，它运行在 DigitalOcean 的推理平台上，实现了 77% 更快的首 token 时间、79% 更低的端到端延迟以及 67% 更低的推理成本。

“在 DigitalOcean 之前，DigitalOcean没有针对多节点服务的专用解决方案，这拖慢了DigitalOcean的 AI 进展。DigitalOcean 让DigitalOcean快速启动并运行起来，通过在性能优化方面的紧密合作，帮助DigitalOcean加速推理性能，整体进展提高了两到三倍。”——Oscar Wu，Workato 人工智能研究科学家与技术负责人

## 前进之路：扩展智能

DigitalOcean对性能的承诺不止于此。DigitalOcean正在扩展优化模型的目录，以满足不断变化的客户需求。当DigitalOcean迈向推理的下一个前沿时，DigitalOcean正在构建支持多节点服务的基础设施，具备解耦配置和 Wide Expert Parallelism 能力，以处理全球最苛刻的智能体工作负载。通过硬件与软件的协同设计，DigitalOcean将持续为 AI 原生构建者提供规模化所需的性能。

立即在 [DigitalOcean Serverless Inference](https://www.aidroplet.com/product/serverless-inference/) 上试用 DeepSeek V3.2、MiniMax-M2.5 或 Qwen 3.5 397B吧！

除了开源大模型，DigitalOcean Serverless Inference 还提供 Claude Opus 4.7、GPT 5.4、GPT Image 2等多种商用大模型，新注册用户可直接联系[卓普云（aidroplet.com）](https://www.aidroplet.com/)申请使用权限。


在 DigitalOcean 推理云上，DeepSeek V3.2 等模型实现接近4倍提速，输出速度达230 token/s，解析其背后的工程优化与架构设计。

比AWS还快！DeepSeek 推理接近 4 倍提速，这家 AI 推理云是怎么做到的？

之前的文章 [只需一个 API！教你用Continue/Kilo插件在VS Code里丝滑切换Qwen3与Opus 4.6](https://blog.aidroplet.com/tutorials/vscode-continue-kilo-gradient-claude/) 介绍了如何使用 DigitalOcean 的 Serverless Inference 服务配置 VS Code 插件使用 Opus4.6 或者 OpenAI 系列模型，但是由于默认的API格式为 Open AI 格式，Opus4.6 无法使用 Anthropic 官方的 Claude Code 和 Claude Code 的 VS 插件。为提供更好的兼容性，DigitalOcean （简称：DO）现提供 Anthropic Messages API 格式，可以配合以上两款著名的AI开发IDE，提供接近原生的 Anthropic Claude Code 开发体验，同时避免了科学上网、被封号的风险。

注意：Claude模型、OpenAI模型暂时只为指定客户开放，因此如需测试或使用该模型请联系[卓普云（aidroplet.com）](https://www.aidroplet.com/)解除账号限制。其他模型注册后可正常使用。

## 相对于其他Token聚合平台的优势

DigitalOceean 作为海外上市的云平台，已经为全球开发者与企业服务14年，现在拥有60万注册用户。DigitalOcean Gradient Serverless Inference 与其他 Token 聚合平台相比，优势在于：

- 与 Anthropic 官方合作，提供真实算力，不打折；
- 无需通过 Anthropic 认证，注册DigitalOcean账号即可使用 Claude；
- 网络直连，无需担心网络连接障碍；
- 支持包括 Claude系列、GPT、Fal ai、DeepSeek、Qwen、Kimi等多种大模型；
- 只需在云后台更改配置，即可更换不同模型，无需重新生成或替换 API；
- 支持支付宝、信用卡、Paypal等多种支付渠道，安全合规；
- 配置简单，无技术门槛，几分钟即可完成配置。

## 1. 权限开通


由于 DO 账号默认不开通 Serverless Inference 访问 OpenAI 和 Anthropic 的商业模型的权限，需要向[卓普云](https://www.aidroplet.com/)申请人工审核后才可以使用。所以请联系卓普云，确认开通 Claude 模型访问和 Anthpropic Messages API 权限。（如果是使用 DO 云平台上的其他模型，则无需申请，可直接使用）

## 2. 准备好Serverless Inference服务的Model/API Key


进入 DigitalOcean 云平台的 Agent Platform，并在 Serverless Inference 服务里创建模型访问的 API Key（即图中的 Access Key），通过这一个 API Key 可以访问Severless Inference 服务支持的所有开源和商业大模型，例如开源的 Kimi K2.5、Mini-max M2.5、智谱 GLM5、英伟达 Nemotron 3 Super 120b，以及 Qwen3 模型。

![c1.PNG](https://blog.aidroplet.com/uploads/c1_680a2d96fa.PNG)

## 3. 简单测试Claude模型的访问是否正常


把API Key存储环境变量 MODEL_ACCESS_KEY, sk-xxxx

```Plain
#session级别临时生效
export MODEL_ACCESS_KEY=sk-xxxx  

#永久生效
#编辑~/.zshrc
#在底部添加 
export MODEL_ACCESS_KEY=sk-xxxx
#保存, 并执行
. ~/.zshrc
#验证是否生效
env
```

Serverless页面上，创建 Model/API Key 的右边有访问大模型的 API 格式，选择自己熟悉的编程语言，简单期间可以用curl直接访问。 本例子里使用Anthropic Messages API格式测试，仅针对Claude系列模型

```JSON
curl -s -X POST "https://inference.do-ai.run/provider/anthropic/v1/messages" \
-H "X-API-Key: $MODEL_ACCESS_KEY" \
-H "Content-Type: application/json" \
-H "anthropic-version: 2023-06-01" \
-d '{
    "model": "claude-opus-4-7",
    "max_tokens": 200,
    "messages": [{"role": "user", "content": "Say hello"}],
    "tools": [
      {
        "name": "get_weather",
        "description": "Get the weather for a location",
        "input_schema": {
          "type": "object",
          "properties": {
            "location": {"type": "string", "description": "City name"}
          },
          "required": ["location"]
        }
      }
    ],
    "tool_choice": {"type": "any"}
  }'
```

Anthropic Messages API Base URL: https://inference.do-ai.run/provider/anthropic/v1/messages

Model/API Key: MODEL_ACCESS_KEY保存在环境变量里

模型ID: claude-opus-4-7

模型ID请参考Anthropic官方文档：https://platform.claude.com/docs/zh-CN/about-claude/models/overview

![c2.png](https://blog.aidroplet.com/uploads/c2_ab5c8ffc14.png)

如返回正常回答，则代表开通成功，否则请根据报错提示检查API是否正确或者DO的权限是否完全开通。

预期结果：

![c3.png](https://blog.aidroplet.com/uploads/c3_1784b1a4a7.png)

如出现报错Provider relay is disabled, 请联系[卓普云（aidroplet.com）](https://www.aidroplet.com/)确认权限问题。

![c4.png](https://blog.aidroplet.com/uploads/c4_c2f7a1408d.png)


如使用OpenAI格式访问模型，则使用以下API访问格式

```C++
curl https://inference.do-ai.run/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $MODEL_ACCESS_KEY" \
-d '{
  "model": "anthropic-claude-opus-4.7",
  "messages": [
    {
      "role": "user",
      "content": "Tell me some fun facts about octopuses"
    }
  ],
  "max_tokens": 100
}'
```

注意，OpenAI格式的base URL和Anthropic Messages API 是不同的。

Base URL：https://inference.do-ai.run/v1/chat/completions

模型ID也采用DO自定义名称，以DO的模型ID命名。模型ID和最大Token可以参考以下链接： https://docs.digitalocean.com/products/gradient-ai-platform/details/models/

模型ID：anthropic-claude-opus-4.7

![c5.PNG](https://blog.aidroplet.com/uploads/c5_3157db419f.PNG)

预期结果

![c6.png](https://blog.aidroplet.com/uploads/c6_53a32fa896.png)

## 4. 安装配置Claude Code

### 安装Claude code


使用官网提供的多种方式安装Claude Code：https://code.claude.com/docs/en/overview#homebrew

```Plain
brew install --cask claude-code
```

  

### 配置第三方Claude Code使用DO模型


只需要更改环境变量就可以让Claude Code的字符界面使用DO转发的Claude系列模型。

以下环境变量需要导出，永久保存请加入对应的操作系统的用户profile文件，本例子为MacOS的~/.zshrc 。

```Plain
export ANTHROPIC_BASE_URL="https://inference.do-ai.run/provider/anthropic"
#请修改ANTHROPIC_API_KEY为自己的Model/API Key
export ANTHROPIC_API_KEY="sk-do-..."
export CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1
```

  

### 启动Claude Code


如以前登录过Claude Code或者第一次配置，CC可能会去Anthropic验证，可能需要科学上网，以后BASE_URL改过来后就不需要科学上网了。

如以前用Anthropic或者AWS账号登录过可以用/logout启动。

```Plain
claude /logout
```

![c7.png](https://blog.aidroplet.com/uploads/c7_1c1dcf5c5c.png)

退出登录后，重新后执行 claude。

确认所用的API Key正确后选择1。

![c8.png](https://blog.aidroplet.com/uploads/c8_1cc9b45bae.png)

之后正常启动，可以开始工作, 通过/model切换模型

![c9.png](https://blog.aidroplet.com/uploads/c9_7ea132baaf.png)

  

## 安装配置Claude Code的VS Code扩展


由于VSCode广泛的使用和最好的开发生态环境，Claude Code在VScode中也有官方插件。在我们之前发布的文章里介绍的是Continue.dev或者OpenCode的第三方插件，提供最好的兼容性，可以使用任意模型。而Claude Code官方插件提供了最为完整的的Claude Code用户体验，可以根据个人喜好选择。

### 安装Claude code

先安装VScode的扩展，在扩展Extension 安装里搜索Claude Code，并点击安装。

![c10.png](https://blog.aidroplet.com/uploads/c10_5644863bc7.png)
  

### 打开Claude Code Extension的设置

选择Vscode的设置，并勾选Disable Login Prompt

![c11.png](https://blog.aidroplet.com/uploads/c11_a90314ca41.png)

之后用settings.json文件配置环境变量Environment Variables，点击打开

![c12.png](https://blog.aidroplet.com/uploads/c12_2d0c46bc70.png)

把以下配置复制到"claudeCode.environmentVariables": [] 里面

```JSON
  {
      "name": "ANTHROPIC_API_KEY",
      "value": "sk-do-xxx" // 第三方API Key
    },
    {
      "name": "ANTHROPIC_BASE_URL",
      "value": "https://inference.do-ai.run/provider/anthropic" // 第三方Base URL
    },
    {
      "name": "ANTHROPIC_DEFAULT_SONNET_MODEL",
      "value": "claude-sonnet-4-6" // 目标模型名
    },
    {
      "name": "CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS",
      "value": "1" // 1 = 关闭实验Beta
    }
```

最终如下

![c13.png](https://blog.aidroplet.com/uploads/c13_fc44955fe3.png)

测试一下：

![c14.png](https://blog.aidroplet.com/uploads/c14_48ede75f41.png)

请注意，有时候碰到配置修改不能立刻生效的情况，请尝试修改配置后彻底的关闭Vscode。也出现过配置修改了，但是过了一会才生效的情况，应该是vscode或者插件自身的问题。

large_images (20).png

medium_images (20).png

small_images (20).png

thumbnail_images (20).png

xsmall_images (20).png

images (20).png

VS Code + Claude Code 官方插件 + DO 国内直连，免翻墙不封号，直接使用Claude Opus 4.7。

Claude Code 官方插件 +VS Code ，稳定接入的配置指南

在 GTC 2026 大会上，NVIDIA 发布了 [NemoClaw](https://nvidianews.nvidia.com/news/nvidia-announces-nemoclaw)。这是一个开源技术栈，可以让你轻松又安全地运行 [OpenClaw](https://openclaw.com/) 自主代理。OpenClaw 是一个开源的代理平台，黄仁勋把它称为“个人 AI 的操作系统”。我们在之前的教程里介绍过[如何在DigitalOcean Droplet 云服务器上运行 OpenClaw](https://blog.aidroplet.com/tutorials/Clawdbot-quickstart-guide/)。而 NemoClaw 走了另一条路：它通过 NVIDIA 的云，给 OpenClaw 加上了沙箱、安全策略和推理路由。

> NemoClaw 现在还只是 alpha 版本，所以有些地方还不够完善。界面可能会变，功能可能不完整，也可能出问题。但如果你好奇想试试，或者只是想看看 NVIDIA 对代理的设想长什么样，那这篇教程可以帮你在 10 分钟之内，在 [DigitalOcean Droplet ](https://www.aidroplet.com/product/cloudcpu/)上把它跑起来。
> 
> 另外简单介绍一下，DigitalOcean 是 2012 年成立的海外云平台，现已上市，目前服务于全球60+万企业用户，并且是 NVIDIA、AMD 等企业的重要合作伙伴，可提供包括NVIDIA B300、H200，AMD MI350X、MI325X等旗舰级 GPU 云服务器/裸金属服务器。更多详情可咨询卓普云（aidroplet.com）。

## 前提条件

开始之前，你需要准备：

- 一个 DigitalOcean 账号（如果没有，可以[在这里注册](https://cloud.digitalocean.com/registrations/new)，如果遇到问题，可咨询[卓普云](https://www.aidroplet.com/)）
- 一个 NVIDIA 账号，用来在 [build.nvidia.com](https://build.nvidia.com/settings/api-keys) 生成 API Key

## 第 1 步 - 从 Marketplace 创建 Droplet

前往 DigitalOcean Marketplace 上的 [NemoClaw 1-Click Droplet](https://marketplace.digitalocean.com/apps/nemoclaw-alpha) 页面，点击 **Create NemoClaw Droplet**。

配置 Droplet 的时候，选择 **CPU-Optimized** 套餐，并选用 **Premium Intel**。你需要 **32 GB 内存 + 16 个 CPU** 的那个选项。因为 NemoClaw 要运行 Docker 容器、一个 Kubernetes 集群（k3s）以及 OpenShell 网关，所以需要足够的资源。

![config.png](https://blog.aidroplet.com/uploads/config_99ab88d7bd.png)

选一个离你近的数据中心区域，添加你的 SSH 密钥，然后点击 **Create Droplet**。

> **注意：** 我们跑 Demo 而配置的这台 Droplet 的费用是 $336/月，所以实验完之后一定记得销毁。如果忘了，费用会很快累积起来。

## 第 2 步 - 通过 SSH 连接 Droplet

Droplet 就绪后，用 SSH 连上去：

```
ssh root@your_server_ip
```

你会看到常见的 Ubuntu 登录提示，然后 NemoClaw 的引导向导会自动启动。它会执行一系列预检：检查 Docker 是否在运行、安装 OpenShell CLI、启动网关。每一步完成后，你会看到一个个对勾闪过。

![onboarding-preflight-checks.png](https://blog.aidroplet.com/uploads/onboarding_preflight_checks_ec613c5df3.png)

## 第 3 步 - 跟着引导向导完成配置

引导向导会问你几个问题。下面是对每个提示的操作说明：

### 沙箱名称

第一个提示是让你输入沙箱名称。直接按 **Enter** 接受默认值（`my-assistant`）。然后向导会创建沙箱、构建容器镜像，并推送到网关。这一步需要几分钟，你会看到大约 20 个步骤在构建和上传。

### NVIDIA API Key

沙箱准备好之后，向导会询问你的 NVIDIA API Key。在这个设置里，推理会通过 NVIDIA 云路由，使用的模型是 `nvidia/nemotron-3-super-120b-a12b`，所以需要 Key 来做认证。

获取 Key 的方法：前往 [build.nvidia.com/settings/api-keys](https://build.nvidia.com/settings/api-keys)，登录，点击 **Generate API Key**。给它起个名字，选择过期时间，然后点击 **Generate Key**。

![nvidia-generate-api-key.png](https://blog.aidroplet.com/uploads/nvidia_generate_api_key_c4a0dc58bd.png)

复制这个 Key（它以 `nvapi-` 开头），粘贴到终端提示符中，然后按 Enter。

![onboarding-api-key-prompt.png](https://blog.aidroplet.com/uploads/onboarding_api_key_prompt_34bdf77692.png)

向导会把 Key 保存到 `~/.nemoclaw/credentials.json`，并设置好推理提供方。你会看到它确认模型并创建推理路由。

### 策略预设

推理设置完成后，NemoClaw 会在沙箱内配置 OpenClaw，然后询问策略预设。你会看到一个可用的预设列表，包括 Discord、Docker Hub、Hugging Face、Jira、npm、PyPI、Slack 等。这些预设用来控制代理允许访问哪些外部服务。

![onboarding-policy-presets.png](https://blog.aidroplet.com/uploads/onboarding_policy_presets_ef68f619e5.png)

在底部，向导会问：

```
Apply suggested presets (pypi, npm)? [Y/n/list]:
```

输入 **`n`** 然后按 Enter。这些预设会授予沙箱对包注册中心的网络访问权限，但在基础设置中你并不需要它们。以后如果代理需要安装包，你随时可以再添加。

引导完成后，你会看到一个清晰的摘要，包含沙箱的详细信息以及后续需要用到的命令：

![onboarding-complete.png](https://blog.aidroplet.com/uploads/onboarding_complete_96ee1cb9d4.png)

```
Sandbox    my-assistant (Landlock + seccomp + netns)
Model      nvidia/nemotron-3-super-120b-a12b (NVIDIA Cloud API)
NIM        not running

Run:       nemoclaw my-assistant connect
Status:    nemoclaw my-assistant status
Logs:      nemoclaw my-assistant logs --follow
```

## 第 4 步 - 连接 NemoClaw

现在到了最有趣的部分。连接你的沙箱：

```
nemoclaw my-assistant connect
```

这会把你带进沙箱环境内的一个 shell。在这里，启动 OpenClaw 的 TUI（终端用户界面）：

```
openclaw tui
```

这样就完成了。你会看到 OpenClaw 的聊天界面出现。代理会跟你打招呼并自我介绍，随时可以开始聊天。

![openclaw-tui.png](https://blog.aidroplet.com/uploads/openclaw_tui_9520f29310.png)

输入一条消息，按 Enter。你现在正在与你自己的 Droplet 上、一个安全的沙箱环境中运行的 AI 代理对话。

## 新的 SSH 会话后如何重新连接

如果你关闭了终端，之后再次 SSH 连回 Droplet，你会发现 `nemoclaw` 和相关命令不可用。这是因为引导脚本是通过 nvm 在一个单独的 shell 中安装的所有东西，新的会话不会继承。

运行下面这条命令可以永久解决这个问题。它会将 nvm 添加到你的 `.bashrc` 中，这样每次登录时都会自动加载：

```
echo 'export NVM_DIR="$HOME/.nvm"' >> ~/.bashrc && echo '[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"' >> ~/.bashrc && echo '[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"' >> ~/.bashrc && source ~/.bashrc
```

然后像之前一样重新连接沙箱并启动 TUI：

```
nemoclaw my-assistant connect
```

```
openclaw tui
```
![reconnecting-to-sandbox-like-before.png](https://blog.aidroplet.com/uploads/reconnecting_to_sandbox_like_before_4b9c9a6706.png)

一切都会从你上次离开的地方继续。你的沙箱和代理都还在运行。

## 下一步做什么

默认情况下，沙箱的网络访问是受限的，所以代理默认无法访问外部服务。要解锁更多能力——比如连接 Slack、GitHub，或者从 PyPI 拉取包——你需要配置策略预设。可以查阅 [NemoClaw 文档](https://docs.nvidia.com/nemoclaw/latest/)，了解所有可用的集成方式以及如何设置。

NemoClaw 目前还非常早期，所以有些地方可能还比较粗糙。但如果你想感受一下“始终在线”的代理未来会走向何方，这倒是一个不错的起点。

small_0_bInE0mjf_zoaE4Db.webp

thumbnail_0_bInE0mjf_zoaE4Db.webp

xsmall_0_bInE0mjf_zoaE4Db.webp

0_bInE0mjf_zoaE4Db.webp

10分钟在DigitalOcean Droplet上部署NemoClaw，安全运行OpenClaw。

快速体验 NVIDIA NemoClaw：10 分钟上手指南

large_gpu-fleet-1.png

medium_gpu-fleet-1.png

small_gpu-fleet-1.png

thumbnail_gpu-fleet-1.png

xsmall_gpu-fleet-1.png

gpu-fleet-1.png

实战演示如何打造 AI 运维 Agent，利用 DCGM 指标实现 GPU 自动审计与降本，开启 Agentic Ops 新范式。

拒绝 GPU 集群资源浪费：教你打造自动化降本的 AI 运维 Agent

AI 现已深度融入现代软件开发。各行各业的团队都在借助 AI 解决产品和流程问题。然而，构建生产级系统仍然复杂。部署 AI 最难的部分，往往不在模型本身，而在模型之外的一切。

更关键的是：**不同技术栈之间的成本差异，往往并不体现在 GPU 或模型调用价格上。**

在很多实际场景中，两种方案的基础设施和模型支出可能大致相当。但一旦将跨云架构带来的工程复杂性与人力投入计算在内，总体拥有成本（TCO）会迅速拉开差距。

当存储、计算、编排、网络、认证和推理分属不同系统、各自采用不同运维模式时，这种复杂性就会演变为“胶水代码”问题。工作流跨越的“接缝”越多，开发者就越难专注于构建产品逻辑，而不得不把时间花在“把系统拼起来”。

**本文要回答的核心问题不是“哪家更便宜”，而是：为什么看起来成本相近的两种 AI 架构，最终总成本会完全不同？**



## 真正的问题是碎片化

来看一下当今 AI 部署的现状。AI 应用远不止依赖推理。真实的工作流涉及对象存储、计算、提示词转换、模型端点、持久化以及监控，每个环节都需要专门的运维知识。

而这些组件通常无法原生连接——这恰恰是当前的现状：产品、资源和服务各自为政，往往只能通过 API 相互连接。

结果是，开发者不得不花费大量时间建立和维护这些连接。填补不同云之间的鸿沟，需要大量人工操作。这种割裂系统在扩展、安全和调试方面都更加困难。

更重要的是，**这些看似只是“工程复杂度”的问题，最终都会转化为成本——要么是更长的开发周期，要么是更多的人力投入。**


![Screenshot 2026-04-01 at 9.58.47 AM.png](https://blog.aidroplet.com/uploads/Screenshot_2026_04_01_at_9_58_47_AM_733cf39845.png)
考虑这样一种组合：像 Baseten 或 Fireworks.AI 这样的新型云平台，搭配 AWS 这样的超大规模云厂商。在这种架构下，前者托管模型，而超大规模云厂商负责编排周边的应用或工作流。例如，一个处理用户上传文档并用大语言模型进行摘要的应用。开发者通常需要：

>通过 API 密钥管理认证，而非使用共享的云身份原语。在 AWS 中，文件上传可通过 S3 事件触发 Lambda 函数。在这个例子里，Lambda 会下载文件，将其内容转换为 JSON 格式的提示词，然后使用 API 密钥通过 HTTP 请求发送到新型云平台的模型端点。模型返回响应，Lambda 解析响应并将其写回 S3 或数据库。
>
>如果模型已缩容到零，请求可能会遇到额外延迟；而在处理大批量任务时，开发者必须自行实现批处理、重试和错误处理。新型云平台并不原生管理这一整套流程，开发者需要负责协调 AWS 各服务与外部推理层之间的每一个步骤。

这些工作并不产生业务价值，但必须存在。

本质上，这些“连接工作”，就是成本的开始。这种复杂性也直接推高了成本。


## 这对开发者意味着什么

这种运维上的复杂性，在规模扩大后会被放大。

首先，扩展变得更难。每增加一个服务集成点，就增加一个潜在故障点，同时也增加一段需要长期维护的代码。

换句话说：**每一个“接缝”，不仅是系统风险点，也是一个持续消耗人力的成本点。**

其次，网络问题更加棘手。模型通过公共 API 暴露，使其更像外部 SaaS，而非原生基础设施，带来安全、延迟和流量问题。

最后，数据管道缺乏集成。开发者必须自行搬运数据，并保证这些连接稳定运行。这进一步增加了工程负担。

在实践中，这会导致成本结构变得碎片化：  
不同供应商、不同计费模型，使得成本难以预测、难以优化。

最终，团队不得不投入专门人力来维持系统运行。

## 胶水代码的隐性成本

一个典型的 AI 管道可能需要 5 到 10 个集成点，每个点都会引入延迟、故障风险和工程开销。在小规模时，这些问题尚可接受；但在规模扩大后，团队往往需要专职工程师来维护这些连接。这就是胶水代码的隐性成本变得无法回避的地方：**在很多 AI 系统中，基础设施成本是可见的，但真正持续增长的，是工程人力成本。**

一旦达到一定规模，推理服务最终需要从无服务器迁移到专用供应商。随着规模扩大，无服务器推理的效率可能会下降，因为你用简单性换来了对成本、性能和容量的控制力下降。它在低流量或不可预测流量场景下表现良好，但在高流量下，冷启动、并发限制、延迟波动以及按请求计费可能使其比专用基础设施更昂贵、更不可预测。专用供应商提供预留容量、更稳定的性能以及更大的 GPU 利用率优化空间——当推理成为产品核心且始终在线的功能时，这一点就至关重要。真正的专用服务通常集中在超大规模云平台上，这往往意味着开发者需要投入更多时间去学习、配置和管理它们的基础设施。这种额外的运维复杂性会显著增加开发者的负担，尤其是与最初让无服务器模式具有吸引力的简单性相比。

多云 AI 系统需要专门的专业知识来管理故障、重试、网络问题以及不同服务间的不一致行为。建立并留住能够运维这些系统的团队既昂贵又困难。在许多情况下，维护系统的成本甚至超过了运行系统的成本。

## 理想的 AI 云应该做什么

理想的 [AI 推理云](https://www.aidroplet.com/product/serverless-inference/)，不应只是托管模型，而应统一整个技术栈：

- 计算
- 存储
- 网络
- 推理
- 持久化

认证、权限、部署和日志应保持一致，工作流应成为平台能力，而不是开发者的负担。

垂直集成的价值，不在于“功能更多”，而在于：

**减少开发者需要亲自连接的部分。**

## 用 DigitalOcean 重新定义问题

为了更具体地理解这种差异，我们用同一个 AI 应用架构，对比两种实现方式：
- 方案 A：新型云 + 超大规模云（如 Baseten + AWS）
- 方案 B：一体化平台（DigitalOcean）

DigitalOcean 的AI推理云提供了一种切实可行的替代方案，它减少了开发者需要管理的“整合衔接”的数量。DigitalOcean 不依赖新型云平台（如上文提到的Baseten 或 Fireworks.AI ）做推理、超大规模云厂商（AWS或GCP）做其他所有事情，而是将计算、存储和 AI 推理更紧密地整合在一个统一的平台模型之下。

在 DigitalOcean 上，相同架构可以用更少组件实现：

- 文件存储在 [Spaces对象存储](https://www.aidroplet.com/product/spaces/)
- 调用 [Function（云函数）](https://www.aidroplet.com/product/functions/) 处理数据
- 调用 [Gradient AI 推理端点](https://blog.aidroplet.com/tutorials/serverless-inference-gradient/)（支持Opus、Sonnet、Qwen、DeepSeek等）
- 结果写入数据库或存储

整个流程在同一平台内完成。

![Screenshot 2026-03-30 at 10.49.45 AM.png](https://blog.aidroplet.com/uploads/Screenshot_2026_03_30_at_10_49_45_AM_b1f8c4fc5e.png)


更少的集成点意味着更少的故障风险、更低的延迟、更清晰的成本可见性和更低的运维开销。最重要的是，再小的 AI 创业团队也可以构建和扩展 AI 应用，而无需投入工程师去维护胶水代码。

这种优势不仅仅是便利，更是一种杠杆。DigitalOcean 让开发者能够专注于构建智能应用，而不是维护“胶水代码”。

## 构建成本分析演示环境

为了验证上述架构，我们构建了一个演示项目(https://github.com/Jameshskelton/demo_do)，并将其完全部署在 DigitalOcean 云平台上。目标是比较在集成平台（如 DigitalOcean）上大规模运行此应用的成本，与在碎片化技术栈（超大规模云厂商做基础设施 + 新型云做推理）上的成本。

在此次更新的分析中，我们采用更公平的模型比较：假设 DigitalOcean 上使用 `openai-gpt-oss-120b`，而推理供应商（如 Baseten）搭配超大规模云厂商也使用同一模型。其他工作流假设保持一致：

| 假设项 | 取值 |
|---|---|
| 每文档输入 token 数 | 10,000 |
| 每文档输出 token 数 | 500 |
| 每文档预处理耗时 | 约 2 秒（1 GB） |
| 每文档存储数据量 | 约 210 KB |
| 保留周期 | 30 天 |
| 所用模型 | gpt-oss-120b |


如果只看基础设施和模型调用成本，两种方案的差距其实非常有限。在所有规模区间内，差异基本维持在约 6% 左右。这意味着：单纯从“算力和模型价格”来看，两种方案几乎可以认为是持平的。但是，真正的经济差异体现在人力上。

**成本分析（未计入人力开销）**

| 月处理量 | DigitalOcean 方案 | Baseten + AWS 方案 | 模型 API 成本差异 | 差异百分比 |
|---|---|---|---|---|
| 100 万份摘要/月 | ~$1,391 | ~$1,306 | ~$85 | ~6% |
| 1000 万份/月 | ~$13,910 | ~$13,060 | ~$850 | ~6% |
| 5000 万份/月 | ~$69,550 | ~$65,300 | ~$4,250 | ~6% |
| 1 亿份/月 | ~$139,100 | ~$130,600 | ~$8,500 | ~6% |

举一个简单的例子：如果一家公司需要至少雇佣一名[初级软件工程师（月薪约 7000 美元）](https://www.indeed.com/career/junior-software-engineer/salaries)来构建和维护创新的云平台+超大规模云厂商架构所需的集成工作，那么即使月处理量低于 5000 万份摘要，这笔人力成本也会轻易抹掉表面上的基础设施节省。而且随着系统变得复杂，这种负担会迅速放大。一个由**四名**初级工程师和**一名**月薪高出约 4000 美元的高级工程师组成的团队，其**基础设施运维人力成本可能接近推理成本本身的一半**。到那时，成本故事就不再只关乎 GPU 或 API 定价，而是你的平台为了系统运行需要消耗多少维护成本。

一个跨越新型云平台和超大规模云厂商的多供应商技术栈会引入真实的胶水代码问题：更多的连接代码、更多的集成点、更多的认证边界、更多的可观测面，以及跨供应商的更多故障模式。在企业级规模下，构建、维护、监控和演进这些“胶水工程”所需的工程努力本身就会成为一个真正的成本中心。相比之下，在像 DigitalOcean 这样单一集成平台上运行相同的业务，可以显著降低这些成本。存储、函数、托管数据库、应用托管和模型访问都位于同一环境内，这实质上降低了运维复杂性，从而降低了系统的长期人力成本。

因此，DigitalOcean 在原始使用量定价上具有巨大优势。而是：真正的差别是在人力成本上。当你需要额外 1–5 名工程师去维护跨云架构时，节省下来的基础设施成本会被迅速吞噬。这也是为什么：在账面价格相近的情况下，整体拥有成本却会出现显著差距，DigitalOcean 的集成平台在总体拥有成本上明显更便宜。

## 结论

现在的 AI 行业，模型访问变得更轻而易举，但围绕模型构建 AI 产品仍然非常关键。下一波 AI 平台的差异化重点将不是仅仅扩大模型目录或增加更多配置选项，而是谁能保证业务不断增长的同时，却投入了更少的工程维护成本，投入了更少的精力。

如果你希望更进一步了解DigitalOcean Gradient AI 推理云，欢迎咨询 卓普云（aidroplet.com）。

DigitalOcean目前可提供包括：
- GPU云服务器，如B300、H200、H100
- Gradient AI 无服务推理，支持GPT、Claude等模型调用
- NFS 网络文件存储
- Kubernetes 托管等。

AI成本不在算力，在跨云胶水代码与人力开销

AI 开发的最大成本，不是 GPU，而是“胶水代码”

在规模化环境下保持云基础设施安全是一项挑战。基础设施漂移、服务暴露、身份权限的滥用都会产生风险。团队并不总是有时间和专业知识在所有环境中保持一致的安全态势。

为了帮助团队在生产环境中可靠运营，并对潜在安全问题保持清晰可见，我们今天推出 DigitalOcean 云安全态势管理（Cloud Security Posture Management，CSPM）。CSPM 在仪表板内提供一体化的基础设施可视化能力。帮助你快速识别风险、优先处理关键问题，并通过引导式指导高效修复问题——全程无需依赖第三方工具或专职安全团队。

CSPM 持续评估 DigitalOcean 资源，包括 Droplets 和 Databases，可识别配置错误和态势风险。无论你是在运行传统应用还是规模化 AI 推理工作负载，CSPM 都能帮你保持可见性、降低运营风险、保持生产系统安全。现在每个 DigitalOcean 客户都可以获得无限免费扫描。升级计划可以获得高级规则、自动化指导、API 集成。随着环境增长解锁更多功能。



## 解决常见安全挑战

管理基础设施的团队经常在安全可见性方面苦苦挣扎，尤其是在复杂架构中。常见挑战包括：

- Droplets 和 Database 服务的可见性不足
- 警报过载，优先级不清晰
- 修复摩擦大，指令复杂或需要外部工具

CSPM 帮助解决这些挑战。通过原生、无代理的体验确定发现优先级、引导修复、直接集成到 DigitalOcean 仪表板和 API。帮助团队减少中断，保持可预测性能。



## 云安全态势管理功能

CSPM 将简洁性和强大能力结合。帮助团队管理安全而不拖慢运营。其无代理、集成的方法提供即时可见性、可操作洞察、引导修复。帮助随着环境增长降低风险。功能包括：

- **无代理、零配置扫描**：开箱即用，即刻启动扫描，无需部署代理或调整工作负载。
- **按优先级排列的发现**：配置错误按严重程度分组，帮助团队首先关注高影响风险。
- **引导式修复**：提供分步操作指引，并附带直达配置页面的链接，让修复更快速、更安全。
- **统一可见性**：在单一仪表板中查看 CSPM 发现和其他安全信号。
- **免费版到高级版路径**：所有用户均可享受免费基线扫描；付费后可解锁工作负载规则、高级优先级排序、API 访问及自动化能力。

除了这些功能，我们还推出 **安全顾问（Security Advisor）**，这是 CSPM 下一项新的 AI 能力。它为体验带来智能层。汇总发现、突出最高影响风险。帮你快速从洞察到行动。



## 几分钟内扫描、优先级排序、修复

开始使用 CSPM 很简单。无需外部工具：

1.**运行扫描**：直接从仪表板中的安全控制台启动扫描。

2.**审查按优先级排列的发现**：配置错误按严重程度和服务分组。行动清晰。

3.**快速修复问题**：评估并应用引导式建议。重新扫描确认改进。付费层级通过安全顾问添加额外的 AI 辅助、策略保障修复。

每个 DigitalOcean 客户即日起均可开启无限次免费扫描。随着业务环境扩展，您可随时升级以解锁高级规则、自动化指导及 API 集成等进阶能力。

DigitalOcean 推出 CSPM：免费扫描，快速识别修复云安全风险。


DigitalOcean 云安全态势管理功能正式上线

推理是大多数 AI 项目证明价值的地方。也是真实约束显现的地方。模型部署后，开发者要处理不可预测的流量、规模化延迟要求。

对技术决策者来说，对话已经从"怎么训练模型"变成"怎么在生产环境高效运行模型"。这个转变已经带来摩擦。根据 [DigitalOcean 2026 年趋势报告](https://www.digitalocean.com/currents/february-2026)显示，49% 的受访者认为推理成本是关键挑战。

对大多数不需要从零训练模型的团队来说，重点是搞定推理：快、省、可扩展。怎么有效集成 AI 模型、生成 API、管理推理成本？

推理即服务（Inference-as-a-Service）让这件事变得简单。团队可以把预训练 AI 模型——从 Llama、DeepSeek 到 Whisper、Stable Diffusion——集成到应用中。不需要大量基础设施配置，也不必操心模型后的扩展管理。

## 核心要点

- 推理即服务（Inference-as-a-Service）是一种云服务模式。帮你管理 AI 推理基础设施，托管预训练 AI 模型。集成 AI 数据到应用，只需要创建一个 AI 端点来促进通信。

- 通过托管平台使用推理即服务（Inference-as-a-Service）的好处：部署更快、可扩展、基础设施优化、模型访问更简单、成本更低。

- 评估推理即服务（Inference-as-a-Service）提供商时，看 GPU 加速可用性、全球数据中心分布、模型兼容性、流量扩展和管理功能、成本透明度。

- 团队用推理服务支持各种场景：聊天机器人、AI 智能体、欺诈检测、内容生成、计算机视觉。

## 什么是推理即服务？

推理即服务是一种云服务模式。让你通过 API 运行 AI 模型，不用手动管理硬件。

流程是这样的：把预训练模型添加到推理服务器。服务器会创建一个安全 API 端点。连接你的应用，接收新输入时集成模型数据。

提供云推理服务的包括 DigitalOcean、AWS、Microsoft Azure、Google Cloud Platform、CoreWeave、IBM Cloud。

 

## 推理即服务 vs 自托管 AI 推理

托管推理平台和自托管 AI 推理有什么区别？

用推理即服务，你为使用的计算资源付费。提供商维护所有基础设施、保证在线、运行工作负载。提供 GPU、驱动、API 创建、最新 AI 模型，随时可集成。但你对推理部署可能没有那么多细粒度定制。这会影响硬件可用性、性能、数据存储限制、安全。

自托管 AI 推理需要你购买所有必需硬件。通过云提供商或数据中心完成。需要手动长期维护。你要负责安全更新、服务器维护和补丁、GPU 资源、API、[vLLM](https://www.digitalocean.com/community/conceptual-articles/vllm-kubernetes-model-loading-caching-strategies)、事件管理系统。还要维护自己的兼容 AI 模型数据库。

但这意味着不用依赖第三方满足特定技术、延迟或合规要求。如果团队有基础设施专业知识能长期管理和维护技术栈，这是个优势。

> 如果想找推理即服务提供商，DigitalOcean 让连接平台和你需要的硬件变得简单。
>
>[DigitalOcean Gradient AI 平台](https://www.aidroplet.com/product/serverless-inference/)支持规模化无服务器推理。可以用模型访问密钥直接从代码调用 OpenAI、Anthropic、Meta 的模型。不需要任何基础设施配置。还让 AI 智能体开发更直观。有预置工具做智能体洞察、评估、端点。有了这些能力，可以用 Gradient 平台部署智能体。不需要配置任何基础设施。平台推理自动扩展，满足流量需求。
>
硬件这边，可以配置 [Gradient GPU Droplets](https://www.aidroplet.com/product/gpu/)。专为在几分钟内运行 AI/ML 工作负载设计。可以从 NVIDIA 和 AMD 选择 GPU 选项。获得运行应用所需的内存和带宽。包括自动扩展和透明定价。

## 推理即服务的好处

把支持推理的所有基础设施交给云厂商管理是选择的首要原因。但不是唯一好处。推理即服务给组织带来多种好处：

**部署更快**

推理即服务支持更精简的 AI 模型集成。通过 API 实现。用命令行界面设置 API 调用，把 AI 模型数据集成到应用。不用手动在应用和数据之间写连接代码。

**可扩展**

基础设施自动扩展。由云提供商管理。随着推理工作负载需求变化而调整。帮助应用无论流量带宽、延迟、数据托管需求如何都能在线。

**基础设施优化**

推理即服务提供商建了数据中心和基础设施。专门支持 AI 和推理工作负载。经常提供多种配置选项，包括 GPU、TPU、裸金属服务器。这意味着不仅能设置适合需求的配置，还能让供应商长期维护和升级，帮助应用平稳运行。

**模型可访问性**

通过推理服务提供商的托管基础设施，你不需要上传最新 AI 模型版本。除非有想用的自定义版本。大多数云提供商目标是集成领先提供商的最新版本。准备好模型部署到应用。

**初期成本节省**

用云提供商跑推理基础设施，避免专用硬件的高额前期成本。比如 GPU 或高性能计算服务器。只需要为消耗的计算时间付费。尤其如果是 DigitalOcean，还可能帮你优化计算设置和成本。例如，基于DigitalOcean Gradient AI 平台，Workato 的 AI 推理服务[总体成本降低了 67%](https://blog.aidroplet.com/news/workato-nvidia-technical-deep-dive-agentic-inference-cloud/)。

AI 应用依赖两个截然不同的阶段。对基础设施的要求非常不同。我们的 AI 推理 vs 训练文章分解了：模型训练用大数据集和密集 GPU 计算构建和更新模型。推理在生产环境持续运行，为真实用户生成预测或响应。推理往往成为 AI 系统最高的长期成本和性能考量。

## 推理即服务怎么工作

用推理即服务，运行 AI 应用变得精简。减少托管、数据集成、基础设施优化的工作量。具体流程是这样的。以 AI 聊天机器人为例：

### 1. 模型打包和部署

API 需要 AI 模型来提取数据并集成到应用。把为特定任务训练的模型，用机器学习格式（如 PyTorch）上传到专用推理服务器。团队在这里取预训练模型（如云托管的 GPT 5.4、Claude Opus 4.6、Gemini 3.1），发送到托管推理平台。也可能遇到自托管模型如 Qwen 3.5 或 MiniMax-M2.7。

### 2. API 端点创建

服务生成一个 API 端点（如 REST 或 gRPC）。在应用和模型之间运行通信。模型部署到 GPU 服务器后自动完成。聊天机器人现在有 API 端点来集成新数据。

### 3. 输入数据提交

这一步是推理模型端点接收新数据。通过用户交互或客户端应用。当客户通过网页浏览器或手机应用向公司聊天机器人提交问题时。比如"法国的首都是哪里？"请求添加后，应用把提示发送到 API 端点：

```json
POST /v1/chat/completions

{

  "model": "support-assistant-v1",

  "messages": [

    {"role": "user", "content": "What is the capital of France?"}

  ]

}
```

### 4. 预处理

推理服务器把数据转换成 AI 模型可读的格式。服务器会 Token 化文本、调整图像大小、为端点添加会话上下文（语气、答案长度）。把用户查询转换成：["What", "is", "the", "capital", "of", "France", "?"]

### 5. 推理执行

服务器然后执行前向传递。用预训练权重生成答案。对聊天机器人，输出 Token 是："The capital of France is Paris." 因为 GPT 模型根据上下文信息预测序列中的下一个 Token。

### 6. 后处理和输出

答案返回用户前，必须转换成用户友好的输出，发送到客户端。包括把 Token 变成可读文本、应用安全过滤器、把答案格式化成 JSON。

```json
{

"response": "The capital of France is Paris."

}
```

所有步骤完成后，后端工作流发送结果。聊天机器人 UI 然后显示："The capital of France is Paris."

### 7. 自动扩展和优化

交互发生时，推理即服务平台自动管理 GPU 实例来处理流量。有助于降低总体延迟，改善性能。

运行大规模 AI 推理需要硬件、软件、模型架构的仔细调优。这篇技术深度文章探讨了 DigitalOcean、AMD、Character.ai 如何在 AMD Instinct GPU 上优化大型 Qwen3-235B 模型。在保持生产工作负载严格延迟目标的同时，将推理吞吐量提高了一倍。

## 评估推理即服务提供商的考虑因素

市场上有许多提供商可以集成或部署让推理可管理的设置。评估推理即服务厂商时有五个主要因素要考虑：

**GPU 加速可用性**

访问正确的 GPU 硬件会影响推理速度、吞吐量、整体应用响应。技术团队应评估可用架构（如 NVIDIA H100、H200、B200、AMD Instinct）。还要看资源是专用（单租户）还是共享。以衡量可能达到的性能类型。

**全球分布和数据中心位置**

为聊天机器人、AI 智能体、推荐系统提供动力的推理工作负载通常需要低延迟响应来提供良好用户体验。在多个市场有全球分布式区域的提供商，优化网络可以减少数据往返时间，支持实时 AI 应用。

**模型兼容性和框架支持**

推理平台应与工程团队已在使用的框架和模型格式集成。支持 PyTorch、TensorFlow、Hugging Face 等工具，以及容器化部署，可以简化模型从开发到生产的迁移。

**扩展和流量管理**

生产 AI 系统经常遇到不可预测的流量峰值。会给 GPU 基础设施带来压力。AI 推理平台应包括自动扩展、请求批处理、负载均衡功能。在高需求时期帮助支持性能。

**成本透明度和计费模式**

推理工作负载随模型使用增长可能产生高运营成本。透明定价模式——如按 GPU 小时、按请求计费、或价格封顶消费层级——帮助团队预测支出，更有效地优化工作负载。

**更广泛的云产品组合**

推理服务有大型工具库和兼容产品组合。随着推理需求增长，集成新能力和功能变得更容易。除了推理即服务，检查组织完整产品组合看有什么支持。包括虚拟机、GPU 计算、托管数据库、托管 Kubernetes 产品、应用开发和托管平台、网络服务。

成本是运行推理的主要考量。看看下面的视频，了解用 DigitalOcean 做托管推理怎么在保持性能的同时控制成本。

## 推理即服务的使用场景

如果好奇什么时候想用推理即服务，这里有六个例子。技术旨在支持各行业：零售、内容、金融、医疗：

**AI 聊天机器人和对话助手**

推理服务为实时对话 AI 系统提供动力。用于客户支持、内部知识助手、开发者工具。平台处理模型执行和扩展，让团队无需管理 GPU 基础设施就能部署大语言模型。Google 2025 年 12 月推出的 Live API 用 Gemini 2.5 Flash 架构通过有状态 WebSocket 会话提供推理。主要客户包括 Shopify 和 SightCall。用于 AI 助手。

**AI 智能体和自动化工作流**

现代 AI 智能体依赖频繁的模型调用来推理、规划行动、与 API 或内部系统交互。推理即服务平台让支持这些持续工作负载更容易。提供可扩展端点，能以可预测延迟处理数千请求。Navan 和 Box 等公司用 OpenAI 的 Responses API 和 Agents SDK 构建和编排智能体。通过 Responses API 调用，开发者可以访问多个模型轮次和工具。

**内容生成和创意 AI 工具**

生成文本、图像、视频或音频的应用通常依赖高吞吐量推理管道。托管推理平台让开发者部署模型更容易。用于营销文案生成、图像合成、自动视频字幕等任务。不需要构建自定义 GPU 集群。Adobe 提供 Firefly 扩散模型的集成 API 和无代码生产。被 Accenture、PepsiCo、Gatorade 等品牌使用。

**推荐和个性化系统**

许多数字平台用机器学习模型提供个性化产品推荐、搜索结果、内容动态。推理服务让这些模型能实时运行。平台能动态响应用户行为和上下文。典型例子是 Netflix。把自研 Netflix Foundation Model 集成到个性化应用中。

**欺诈检测和风险分析**

金融服务和电商平台经常依赖 ML 模型分析交易、毫秒级检测可疑活动。推理即服务基础设施让这些模型能处理大量事件。同时保持实时决策所需的低延迟。2025 年 11 月，Vonage 推出欺诈预防网络 API。检测 SIM 卡交换和支持静默认证。减少一次性 SMS 验证码的需求。

**计算机视觉和媒体分析**

视频审核、医学影像分析、工业质量检测等应用依赖计算机视觉模型分析视觉数据。推理平台让跨大数据集或流视频管道部署和扩展这些模型更容易。NVIDIA 开发了计算机视觉设置。集成 VLM、LLM、NeMo Retriever 微服务、RAG。帮助 Pegatron 在制造车间使用视频搜索和标签摘要。

## 常见问题

**什么是推理即服务？**

推理即服务是一种云服务模式。让你通过 API 运行 AI 模型，不用手动管理硬件。这意味着开发者可以在不配置硬件的情况下集成 AI 模型和数据到应用。


**推理即服务有什么好处？**

好处包括部署更快、可扩展、基础设施优化、更简单的模型访问、成本节省。用推理即服务提供商让把 AI 能力集成到应用更容易。


**推理需要 GPU 吗？**

需要。AI 推理工作负载需要 GPU 来支持模型和应用使用的大量数据。在 DigitalOcean 上，可以通过 Gradient AI GPU Droplets 访问 GPU。这些是预加载驱动、CUDA、深度学习框架的按需虚拟机。可以几分钟内从启动到实时推理。当前选项包括 NVIDIA H100 和 H200 GPU、AMD Instinct MI300X 和 MI325X GPU。可选单 GPU 或 8-GPU 配置。按秒计费。需要专用单租户硬件的团队，DigitalOcean 还提供裸金属 GPU。


**怎么在不管理服务器的情况下规模化运行 AI 推理？**

可以用推理即服务提供商。不需要管理服务器就能规模化运行 AI 推理。这些提供商处理 AI 模型集成、服务器可用性、资源扩展。提供商例子包括 DigitalOcean、AWS、Microsoft Azure、Google Cloud Platform、CoreWeave、IBM Cloud。

## 在 DigitalOcean 智能推理云上部署

DigitalOcean 花了十多年为开发者构建云基础设施。从虚拟机、托管 Kubernetes 到对象存储、托管数据库、应用托管。DigitalOcean 智能推理云把同样的简洁延伸到 AI 工作负载。给团队工具来训练、运行推理、规模化部署智能体。没有运维负担。提供多条路径让 AI 工作负载进入生产：

**Gradient AI 平台**：构建和部署 AI 智能体，不需要管理任何基础设施

- 通过单一 API 密钥访问 OpenAI、Anthropic、Meta 模型的无服务器推理
- 内置知识库、评估、可追溯性工具
- 在完整开发生命周期中版本化、测试、监控智能体
- 按使用量定价。账单简洁，无隐藏成本

**GPU Droplets**：按需 GPU 虚拟机，起价 $0.76/GPU/小时

- NVIDIA HGX H100、H200、RTX 6000 Ada Generation、RTX 4000 Ada Generation、L40S。以及 AMD Instinct MI300X
- 一分钟内从零到 GPU。预装深度学习框架
- 按需实例比超大规模云节省高达 75%
- 按秒计费，支持托管 Kubernetes

**裸金属 GPU**：专用单租户 GPU 服务器。用于大规模训练和高性能推理

- NVIDIA HGX H100、H200。AMD Instinct MI300X。每服务器 8 GPU
- 根级硬件控制。无嘈杂邻居
- 高达 400 Gbps 私有 VPC 带宽和 3.2 Tbps GPU 互联
- 在纽约和阿姆斯特丹可用。

**专业技术支持**：帮助中国企业快速迁移、部署多云方案

[DigitalOcean 中国区战略合作伙伴卓普云（aidroplet.com）](https://www.aidroplet.com/)负责 DigitalOcean 产品在中国的销售，为 DigitalOcean 中国的客户提供本土技术支持服务。

large_WX20250721-151435@2x.png

medium_WX20250721-151435@2x.png

small_WX20250721-151435@2x.png

thumbnail_WX20250721-151435@2x.png

xlarge_WX20250721-151435@2x.png

xsmall_WX20250721-151435@2x.png

WX20250721-151435@2x.png

无需自建和管理AI基础设施，即可通过API快速、可扩展且低成本地将预训练模型集成到应用中

什么是推理即服务（Inference-as-a-Service）？

很多开发者为了追求极致的代码理解力，会订阅多个大模型，但往往面临“订阅费昂贵”和“模型切换麻烦”的痛点。其实，对于追求高效率的开发者来说，DigitalOcean 推理云平台的 Gradient Serverless Inference 提供了一个非常便捷的方法：它提供了一套标准化的 API 接口，让你能以一个 API、按量计费的方式，在编辑器里直接调用 Opus 4.6、Qwen3 等多个顶级大模型。

你不需要为每个模型单独支付月费。通过 **Continue.dev** 或 **Kilo Code** 插件，你可以把 Gradient 当成一个强大的算力后台——复杂的架构设计交给 Opus或Sonnet，日常的逻辑实现交给 Qwen。

今天我就带大家打通这条路径，把 VS Code 真正变成一个“全模型集成”的开发大本营。

## 操作步骤


**首先准备好Gradient Serverless Inference服务的Model Key**。

首先注册 DigitalOcean 推理云平台账号。进入后台之后点击侧边栏的 Gradient AI 平台按钮，选择下图中的“Serverless Inference”，然后创建 Access Key。如果希望通过API的方式来创建，可阅读[卓普云官网博客的教程](https://blog.aidroplet.com/tutorials/serverless-inference-gradient/)。

![vs1.PNG](https://blog.aidroplet.com/uploads/vs1_ebb26db341.PNG)
  

### Continue插件配置


在VScode里扩展里搜索并安装Continue插件, 点击安装

![vs2.PNG](https://blog.aidroplet.com/uploads/vs2_3c8dc50388.PNG)

  

![vs3.PNG](https://blog.aidroplet.com/uploads/vs3_72194e96e4.PNG)

  

**配置Continue插件**

在左侧边栏找到Continue插件，选中后点击右上角的设置

![vs4.PNG](https://blog.aidroplet.com/uploads/vs4_044ae78a61.PNG)

点击设置里的Config，并点击Local Config的设置，打开配置文件

![vs5.png](https://blog.aidroplet.com/uploads/vs5_3a117dca32.png)

配置文件如下：

```YAML
name: DO Gradient
version: 1.0.0
schema: v1

models:
  - name: Main Chat Model
    provider: openai
    model: alibaba-qwen3-32b
    apiBase: https://inference.do-ai.run/v1
    apiKey: ${{ secrets.MODEL_ACCESS_KEY }}
    roles:
      - chat
      - edit
      - apply
```

可以先使用Qwen3-32b调试访问正常后，再切换为Anthropic Claude Opus 4.6，改为：

```YAML
name: DO Gradient
version: 1.0.0
schema: v1

models:
  - name: Main Chat Model
    provider: openai
    model: anthropic-claude-opus-4.6
    apiBase: https://inference.do-ai.run/v1
    apiKey: ${{ secrets.MODEL_ACCESS_KEY }}
    roles:
      - chat
      - edit
      - apply
```

可根据需要选择Gradient Serveless Inference上的其他模型，无需更换API Key，本例子中API Key保存在环境变量的MODEL_ACCESS_KEY 变量中，把系统环境变量的值设置成API Key即可。

本例子中未配置自动补全的模型，可以使用VS Code的copilot实现自动补全，免费且响应更快。Claude Opus 4.6更适合代码的Plan和Agent场景，无需在代码补全浪费Token。 Continue插件支持在不同角色下使用不同的模型，实现更加灵活和安全的配置。涉及隐私和机密的数据可以使用本地模型

  

测试用Claude Opus 4.6帮助生成一个数据迁移脚本：
![16c4f0a5-1506-4652-a91e-a0f74342fd6f.png](https://blog.aidroplet.com/uploads/16c4f0a5_1506_4652_a91e_a0f74342fd6f_7749f1d972.png)

  

### Kilo Code插件配置


搜索并安装Kilo插件

![vs7.png](https://blog.aidroplet.com/uploads/vs7_15c944a911.png)

安装完成后，在左边边栏点击Kilo插件图标，开始配置

![vs8.png](https://blog.aidroplet.com/uploads/vs8_523094892e.png)

按如上所示配置以下信息：

API 提供商：OpenAI Compatible

OpenAI基础URL: https://inference.do-ai.run/v1

API密钥：DO平台Model Access Key

模型：anthropic-claude-opus-4.6

最大输出Token：128000

默认的最大输入Token值为-1，会报错，需要改成平台支持的最大Output Tokens

![vs9.png](https://blog.aidroplet.com/uploads/vs9_59e0b3bfe8.png)
  

模型ID和最大Token可以参考以下信息： https://docs.digitalocean.com/products/gradient-ai-platform/details/models/

![vs10.png](https://blog.aidroplet.com/uploads/vs10_47576ef8c6.png)

配置成功后，可以开始使用Kilo Code

![vs11.png](https://blog.aidroplet.com/uploads/vs11_03935b0f9f.png)

## FAQ：使用中的常见疑难杂症

**Q：Gradient 的计费逻辑是怎样的？真的划算吗？** 
**A：** 它的计费方式是标准的 **Pay-as-you-go（按量计费）**，价格与大模型官方（如 Anthropic）对齐。这对于不经常进行高强度重构、但偶尔需要大模型处理复杂逻辑的开发者非常友好。你不再需要每月死磕 20 刀的固定订阅，用多少扣多少，透明且可控。

**Q：既然价格和官方一样，为什么不直接买官方订阅？** 
**A：** 最大的优势是“多模集合”。在 Gradient 一个平台上，你可以通过同一个 API Key（Access Key）调用不同厂商的模型（Anthropic, Llama, Qwen 等）。配合 Continue 插件的配置，你可以在一个界面里灵活切换，省去了管理多个平台账号和 API 密钥的麻烦。

**Q：这个方案会影响 VS Code 的响应速度吗？** 
**A：** 体验上几乎无感知。Gradient 的 Serverless 推理延迟非常低。

**Q：如果配置大模型的时候遇到报错怎么办？**
通常来讲，可以在注册DigitalOcean中后先调用Qwen模型来进行测试，再测试其他大模型。如果遇到调用失败，可以直接联系卓普云（aidroplet.com）的技术支持。


## 总结：构建你的 AI 混合工作流

通过将 DigitalOcean Gradient 推理云服务接入 VS Code，我们实际上构建了一套“混合算力”工作流：

1. **轻量任务本地化**：简单的代码提示交给 Copilot 或本地模型。
2. **重型任务云端化**：涉及跨文件逻辑、架构设计、数据迁移脚本时，直接调用 Gradient 上的 opus 4.6。
3. **统一化管理**：所有的 API 调用、模型切换和账单支付都集中在 DO 平台，不再需要到处找 Key。


这种“Serverless AI”的配置方式，代表了未来开发者工作流的趋势——**不为闲置的订阅买单，只为产生的价值付费。** 赶紧去配置你的专属开发助手吧！

large_images (11).png

medium_images (11).png

small_images (11).png

thumbnail_images (11).png

xsmall_images (11).png

images (11).png

拒绝昂贵订阅！一个 API 让 VS Code 集成 Qwen 与 Opus 多模型，按量计费更自由。

只需一个 API！教你用Continue/Kilo插件在VS Code里丝滑切换Qwen3与Opus 4.6

随着团队规模扩大和无服务器工作负载的增长，安全管理变得与代码管理同等重要。DigitalOcean 的目标是在您的每个发展阶段都提供支持。我们持续迭代安全架构，正是实现这一目标的方式之一。

过去，[DigitalOcean Functions（云函数）](https://www.aidroplet.com/product/functions/) 在同一个 namespace（命名空间）内采用共享凭证模型，凭证在Functions的「设置」标签页中进行配置。

![Access Keys REST API.png](https://blog.aidroplet.com/uploads/Access_Keys_REST_API_c7c88d6b5c.png)

图：同一命名空间的所有用户共享相同的凭证

这种模式虽然上手简单，但对不断壮大的团队来说存在挑战：当团队成员离职或转岗时，共享凭证仍然有效。为了确保命名空间安全，管理员必须手动撤销并重新生成密钥，这会干扰其他所有使用该共享密钥的开发者和生产工作负载。

今天，DigitalOcean 宣布了一个重大升级：**用户专属命名空间访问密钥**（user-specific namespace access keys）。

这一更新将访问控制从命名空间级别下沉到用户身份级别，确保权限授予给具体用户，而不再依赖共享密钥。

## 用户专属访问密钥如何增强安全性

向用户专属密钥的转变解决了团队的几个关键场景：

- **自动化访问管理**：当团队成员从 DigitalOcean 团队中移除时，平台会自动撤销其专属访问密钥。无需手动轮换密钥，也不会对剩余团队成员造成任何干扰。

- **每个命名空间支持多个密钥**：用户可以为同一命名空间创建多个访问密钥，便于手动轮换和管理不同环境的密钥。

- **简化责任追溯**：由于操作现在与独特的用户专属密钥关联，您可以更好地了解资源管理情况并进行审计。

- **支持过期时间**：为了进一步缩小攻击面，访问密钥可以「选择性地」设置过期时间（TTL）。过期后，该密钥将无法通过任何操作的认证。

## 教程：通过 API 管理 Functions 访问密钥

DigitalOcean Functions API 已更新，支持以编程方式管理访问密钥。您现在可以直接通过 API 创建、列出、更新和删除访问密钥，从而实现无服务器命名空间的更好自动化和安全管理。

以下是与新端点交互的指南。本教程使用 Bash 脚本完成。

### 前置条件

- 需要您的 Functions **命名空间 ID**（在 API 路径中显示为 `fn-xxxxxxx`）。
- 必须拥有有效的 DigitalOcean API Token（令牌） `($DIGITALOCEAN_TOKEN)`，并具有 `function:admin` 权限。

#### 1. 创建命名空间访问密钥

要生成新的访问密钥，向密钥端点发送 `POST` 请求。

**重要提示**：访问密钥的密钥部分仅在创建后立即返回一次。您必须复制并安全存储，之后将无法再次获取。

**请求：**

```
curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
  -d '{"name": "my-function-access-key", "expiration": "12h"}' \
  "https://api.digitalocean.com/v2/functions/namespaces/fn-xxxxxxx/keys"
```

**响应要点：**

- 返回完整的密钥详情，包括 `secret`。
- 包含 `created_at` 和 `expires_at` 等元数据。

#### 2. 列出访问密钥

要查看特定命名空间的所有现有密钥，使用 `GET` 端点。这有助于审计当前的访问凭证。

**请求：**

```
curl -X GET \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
  "https://api.digitalocean.com/v2/functions/namespaces/fn-xxxxxxx/keys"
```

**响应要点：**

- 返回 `access_keys` 对象列表。
- 包含找到的密钥总数 `count`。

#### 3. 更新访问密钥

如果需要重命名密钥（例如，为了轮换用途但暂时不删除），可以向特定密钥 ID 发送 `PUT` 请求。

**请求：**

```
curl -X PUT \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
  -d '{"name": "updated-key-name"}' \
  "https://api.digitalocean.com/v2/functions/namespaces/fn-xxxxxxx/keys/dof_v1_yyyyyyyy"
```

**响应要点：**

- 返回更新后的访问密钥对象，包含新的 `name`。
- **不会**返回密钥。

#### 4. 删除访问密钥

要撤销访问权限，可以使用 `DELETE` 方法永久删除密钥。

**请求：**

```
curl -X DELETE \
  -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
  "https://api.digitalocean.com/v2/functions/namespaces/fn-xxxxxxx/keys/dof_v1_yyyyyyyy"
```

**响应要点：**

- 成功删除将返回 `204 No Content` 状态码。

## 教程：通过 doctl 管理访问密钥

您可以通过云控制面板或命令行管理这些访问密钥。下面，我们将介绍使用 [doctl（DigitalOcean command line interfece）](https://docs.digitalocean.com/reference/doctl/) 的workflow。

### 前置条件

要跟随本教程并迁移到新密钥系统，您需要：

- **已安装 doctl**：确保已安装并配置最新版本的 DigitalOcean CLI `(doctl)`。
- **权限**：必须具有 `function:admin` 权限才能创建或管理命名空间访问密钥。

#### 1. 创建新访问密钥

您可以为每个命名空间创建多个访问密钥，将本地开发、CI/CD 流水线和生产应用的凭证分开。

要在当前连接的命名空间中创建密钥，使用以下命令：

```
doctl serverless key create --name my-dev-key --expiration 7d
```

输出将显示您的新密钥。

```
ID                                      Name           Secret
dof_v1_a1b2c3d4e5f67890                 my-dev-key     /1x2y3z4a5b6c7d8e9f0g1h2i3j4k5l6m
```

**注意**：新访问密钥遵循特定格式，前缀为 `dof_v1_`。

#### 2. 连接您的唯一身份

生成密钥后，需要使用这个新身份将 `doctl` 连接到您的命名空间。这取代了无需显式密钥即可连接的已弃用方法。

运行以下命令将 CLI 链接到您的命名空间：

```
doctl serverless connect <your-namespace> --access-key "<access-key-id>:<secret-key>"
```

连接后，您的个人凭证将安全存储在本地配置中。所有后续命令（如 `deploy`、`invoke` 和 `list`）将自动使用您的唯一密钥进行认证。

#### 3. 删除访问密钥

如果密钥不再需要（例如，需要轮换 CI/CD 令牌），可以将其删除。这将撤销其访问权限，而不会影响您的其他密钥或团队成员。

```
doctl serverless key delete <access-key-id>
```

**注意**：此操作是永久性的，将立即阻止使用该凭证进行认证。

### 用户专属访问密钥的迁移和过渡时间表

我们目前处于**双支持阶段**。这意味着：

- **宽限期**：在有限时间内，旧版共享凭证和新版用户专属密钥将并行工作。您可以在[DigitalOcean英文文档中](https://docs.digitalocean.com/products/functions/how-to/manage-namespace-access/#migrate-from-legacy-shared-credentials)找到有关迁移截止日期的更多信息。

- **需要采取行动**：为确保持续访问，每个用户最终必须迁移到自己的个人访问密钥。如果通过 doctl 交互，需要重新运行 doctl serverless connect 命令。此外，如果您在系统中的任何地方硬编码了旧密钥/令牌，需要将它们替换为您或团队中任何其他用户账户下创建的访问密钥。

- **无需修改代码**：这是平台级别的认证更新。您无需修改实际的函数代码。

我们建议管理员/所有者立即开始为团队中的所有用户跟踪此过渡，以防止旧方法[停用](https://docs.digitalocean.com/products/functions/#13-march-2026)后出现访问问题。

## DigitalOcean Functions 更安全的未来

向用户专属访问密钥的转变是 DigitalOcean Functions 安全性和可管理性的重要进步。通过将访问权限与个人身份关联，我们实现了自动访问撤销、更好的可审计性，以及更安全的无服务器应用环境。

DigitalOcean Functions 推出用户专属访问密钥，替代共享凭证，提升安全性并简化团队权限管理。

使用用户专属访问密钥增强 DigitalOcean Functions 云函数的安全性

OpenClaw 迅速成为构建个人 AI 助手的热门开源框架，可以连接 Slack、微信、飞书等消息平台。随着更多开发者从本地实验转向常驻助手，挑战从构建智能体转变为长期可靠地运营——通常还要跨多个智能体处理不同的工作流。

一旦助手持续运行、处理真实流量并协调工具或 API，新问题会迅速出现：

- 如何让它持续运行而无需不断管理服务器？
- 如何在不重新架构的情况下从一个助手扩展到多个智能体？
- 如何应用可默认信任的安全和访问控制？
- 如何增长使用量而不把运维变成第二份工作？
- 如何在保持成本可见性和可预测性的同时扩展智能体？

DigitalOcean现在已推出 OpenClaw on [App Platform（应用托管服务）](https://www.aidroplet.com/product/app-platform/) 方案来解决这些问题。它专为这个阶段设计——帮助团队从概念验证过渡到持续的生产运营，具有弹性扩展、安全默认配置和更简单的日常运营。

此外，App Platform 上的 OpenClaw 为常驻 AI 系统的成本完全可预测。与那些随使用量增长，可能意外飙升的可变按请求付费服务不同，App Platform 使用清晰的基于实例的定价。团队可以清楚地了解添加智能体或增加容量时成本如何变化。


## 更简单的运维，同时不失控制力

在 DigitalOcean App Platform 的环境中，OpenClaw 用户依然掌控关键部分：智能体行为、模型选择和渠道配置。同时，无需管理底层基础设施。

在 DigitalOcean App Platform 上使用 OpenClaw：

- **智能体配置、底层 LLM 和消息渠道**都以代码形式定义，可作为配置项管理。
- **App Platform 负责容器运行时、网络和可观测性**，无需手动管理服务器或编排系统。
- **智能体更新基于 Git 驱动**，团队可以通过 “git push” 升级 OpenClaw 镜像，实现零停机更新。

开发者可以专注于优化智能体本身，而不必处理复杂的基础设施问题。

## 从单一智能体到多智能体的弹性扩展

随着使用增长，OpenClaw 在 DigitalOcean App Platform 上可以轻松扩展，无需重新架构：

- **可以声明式定义多个智能体**（例如销售、客服、个人助理或家庭助手），全部集中在一个 App Platform 配置中。
- **单个智能体可以按需扩容或升级实例类型**，无需停机。
- **同一套运行模式适用于从单个助手到多智能体集群**，避免系统扩展时频繁调整架构。

这使 App Platform 非常适合从单一场景逐步演进为多智能体系统的 OpenClaw 部署。

## 可预测成本的扩展方式

随着 OpenClaw 部署规模扩大，扩展不应带来成本不确定性。DigitalOcean App Platform 上的 OpenClaw 让团队在扩容的同时保持清晰的成本预期。

智能体通过调整已知实例规格进行扩展，而不是依赖不透明的按请求计费。这让多智能体系统更容易做预算规划。当使用模式稳定后，可以对单个智能体进行精细化调整或缩容，避免为空闲资源付费。

团队可以从一个助手扩展到多个专业智能体，同时保持运维简单和成本可控。

## 默认安全强化的私人 AI 助手

智能体需要保持私有、隔离，并具备状态能力。即使在重启、更新或扩展时也是如此。

DigitalOcean App Platform 上的 OpenClaw 默认满足这些要求：

### 默认私有

- 以后台 worker 运行，没有公共 URL
- 不暴露任何公网入站端口
- 访问仅限于：私有 Tailscale 网络（用于 Web UI），或 DigitalOcean CLI（用于无头操作）

### 强化且可替换的运行环境

- 运行在可替换的容器中，而非长期运行的虚拟机
- 每次部署都从干净、已知状态开始
- 减少配置漂移，降低手动加固和打补丁的需求

### 无需持久服务器的状态持久化

- 配置、会话和智能体记忆可通过用户配置，实时备份到 DigitalOcean Spaces（可选，需额外费用）
- 即使容器是临时的，智能体在重启和更新后仍可保留状态

### 天然隔离设计

- 基于容器和私有网络实现隔离
- 限制配置错误或故障的影响范围
- 随着系统扩展，降低误暴露风险

## 部署模式

App Platform 上的 OpenClaw 支持两种常见的生产部署方式，满足不同团队在进入常驻运行后对访问和运维的需求。

### 使用 Tailscale（支持 Web UI）

如果需要通过 Web 界面配置或监控 OpenClaw，部署会同时运行 Tailscale 服务。你的 OpenClaw 实例会获得一个私有地址（例如 openclaw.your-tailnet.ts.net），且无法从公网访问。

### 无头模式（仅网关）

如果只需要消息网关，不需要 Web UI，可以选择无头部署。容器作为 worker 运行，没有入站端口，默认私有。可以通过 DigitalOcean CLI 查看日志和执行命令：

`doctl apps console <app-id> openclaw`

两种模式都支持通过 DigitalOcean Spaces（用户自行配置）进行状态同步。


## 开始使用

OpenClaw 现已支持在 DigitalOcean App Platform 上运行。你可以通过以下方式部署：

- 使用 GitHub 模板仓库中的 Deploy-to-DigitalOcean 按钮
- 通过 App Platform 控制台
- 或使用 [doctl](https://docs.digitalocean.com/reference/doctl/reference/) 从你的 Git 仓库部署

如果需要详细步骤，可以参考 OpenClaw 官方教程。对于更复杂的使用场景，可能需要额外配置，但 App Platform 已提供一个快速且安全的生产环境起点。


## 不确定该选择哪种 OpenClaw 部署方式？

### 一键部署 OpenClaw 到 Droplet 服务器

适合实验、学习 OpenClaw，或需要完整虚拟机控制和手动管理基础设施的场景。

### 在 App Platform 上运行 OpenClaw

适合希望实现弹性扩展、简化运维、并保持成本可预测的团队。尤其适用于从单一智能体扩展到多智能体的场景。

以上两种方案基于相同的 OpenClaw 架构。区别在于，随着系统规模扩大，你会承担的运维工作量不同。

---
 相关阅读：
 
 - [Moltbot/Clawdbot是什么？如何在云服务器部署 Moltbot/Clawdbot？](https://blog.aidroplet.com/tutorials/Clawdbot-quickstart-guide/)
 - [不用海外卡、不怕封号，OpenClaw 稳定跑 Claude / GPT 的最简单方法](https://blog.aidroplet.com/tutorials/openclaw-use-claude-or-GPT/)
 - [教程：让OpenClaw一次接入Claude、Qwen、DeepSeek 多个模型](https://blog.aidroplet.com/tutorials/openclaw-multiple-model/)
 - [使用 DigitalOcean 实现 Claude Code “低配订阅 + 外部 Token”](https://blog.aidroplet.com/tutorials/claude-code-gradient-connect/)

large_images (19).png

medium_images (19).png

small_images (19).png

thumbnail_images (19).png

xsmall_images (19).png

images (19).png

当 AI 助手开始“常驻运行”，真正的难题才刚刚出现——你准备好了吗？

OpenClaw 多智能体部署：弹性扩展、零运维 

本文将介绍，如何在本地安装的Openclaw中，使用DigitalOcean GradientAI 的Key配置大模型。可用的大模型包括：Claude opus、Claude Sonnet、gtp-oss、Kimi、DeepSeek、Qwen、MiniMax，以及 NVIDIA Dynamo 1.0等数十种大模型。本文中介绍的API 接入方法，对云端部署的Openclaw同样适用。


## 必要条件

1.确认已经安装好Openclaw（本地或云端皆适用）

2.注册Digitalocean账号，[创建Gradient Access Key](https://blog.aidroplet.com/tutorials/serverless-inference-gradient/)。方法见卓普云官网博客。

## 开始配置

1.打开终端，输入 openclaw configure , 激活Openclaw的配置

2.使用键盘方向键，选择 model

![1280X1280.PNG](https://blog.aidroplet.com/uploads/1280_X1280_0256964eb2.PNG)

3.Model /auth provider 选择 Custom Provider

![1280X1280 (1).PNG](https://blog.aidroplet.com/uploads/1280_X1280_1_d57e91c29e.PNG)

4.配置按照下图填写


API Base URL：https://inference.do-ai.run/v1

Paste API key now ： 把你的DigitalOcean Gradietn Serverless Inference Access Key 粘贴在这里。

![3.PNG](https://blog.aidroplet.com/uploads/3_3f1463c9fb.PNG)

5.完整配置如图
 
![4.PNG](https://blog.aidroplet.com/uploads/4_cc21506e78.PNG)

这里填写的 Model ID，可参考DigitalOcean 英文文档，按照对照表选择你需要的model。

https://docs.digitalocean.com/products/gradient-ai-platform/details/models/#foundation-models-deepseek

![Pasted image 20260327100914.png](https://blog.aidroplet.com/uploads/Pasted_image_20260327100914_77e76c3377.png)


6.验证成功

![6.png](https://blog.aidroplet.com/uploads/6_42691cd5a5.png)

7.可以重复以上步骤，添加多种模型。


此时，你的Openclaw已经成功接入了DigitalOcean GradientAI平台。将会使用GradientAI来管理所有token调用。

注意，**新注册**的账号可能部分模型调用会被限制，系统会提示401报错，如遇到这类情况，请联系[卓普云（aidroplet.com）](https://www.aidroplet.com/)申请解除限制。

---
相关阅读：

- [多个 OpenClaw 智能体部署：弹性扩展、零运维](https://blog.aidroplet.com/product-updates/openclaw-digitalocean-app-platform/)
- [Moltbot/Clawdbot是什么？如何在云服务器部署 Moltbot/Clawdbot？](https://blog.aidroplet.com/tutorials/Clawdbot-quickstart-guide/)
- [不用海外卡、不怕封号，OpenClaw 稳定跑 Claude / GPT 的最简单方法](https://blog.aidroplet.com/tutorials/openclaw-use-claude-or-GPT/)
- [使用 DigitalOcean 实现 Claude Code “低配订阅 + 外部 Token”](https://blog.aidroplet.com/tutorials/claude-code-gradient-connect/)




large_17738226706ddb.png

medium_17738226706ddb.png

small_17738226706ddb.png

thumbnail_17738226706ddb.png

xsmall_17738226706ddb.png

17738226706ddb.png

不论是本地龙虾还是云端龙虾，都可以轻松接入多个模型。

教程：让OpenClaw一次接入Claude、Qwen、DeepSeek 多个模型

无服务器推理理所当然地成为人工智能用户技术圈和非技术圈最热门的话题之一，这背后有其充分理由。虽然部署自定义模型通常需要控制部署的方方面面，但无服务器技术免去了维护和管理模型部署及 API 端点的麻烦。这对于众多不同的智能体大语言模型用例来说，可能极为有用。

在本教程中，我们将展示如何使用 DigitalOcean  [Gradient Platform](https://www.aidroplet.com/product/serverless-inference/) 无服务器推理 API。之后，我们将讨论该方法在生产环境和日常工作流程中的一些潜在用例。

## 在 Gradient 平台上访问无服务器推理

首先，我们可以使用 DigitalOcean API 或云[控制台](https://cloud.digitalocean.com/)。让我们来看看这两种方法。

### 步骤 1A：创建 DigitalOcean API 密钥

首先，你需要创建自己的 DigitalOcean 帐户并登录。完成后，导航到你选择的团队空间。在这里，我们将创建一个 DigitalOcean API 密钥。这稍后将帮助我们创建模型访问Token，所以我们可以跳过此步骤，直接进入“步骤 2b：使用云控制台创建模型访问密钥”部分。

使用主页左侧的导航栏，向下滚动直到看到“[API](https://cloud.digitalocean.com/account/api/tokens)”。点击进入 API 主页。然后我们可以使用右上角的按钮创建一个新密钥。

![Pasted image 20260326144033.png](https://blog.aidroplet.com/uploads/Pasted_image_20260326144033_646b4af333.png)

在密钥创建页面，根据需要为你的密钥命名并授予适当的权限。为此，你可以授予完全权限，或者在自定义范围选择中向下滚动到“genai”并全选。然后，创建密钥。保存此值以备后用。

注意：新注册用户建议可以先使用 qwen 模型，把API跑通。再更换model ID使用其他模型。目前 Opus 4.6、GPT 5.2等高级模型，对新注册账号是不开通权限的。如果新注册用户想使用，可联系[卓普云](https://www.aidroplet.com/)来申请解除限制。

### 步骤 2A：使用 API 创建模型访问密钥

接下来，我们将为 Gradient 的无服务器推理创建模型访问密钥。为此，我们可以使用控制台或 API。要使用 API，请使用之前保存的 API 密钥，在终端中执行以下 curl 请求。将“$DIGITALOCEAN_TOKEN”的值替换为你自己的。

```
curl -X POST -H 'Authorization: Bearer $DIGITALOCEAN_TOKEN' https://api.digitalocean.com/v2/gen-ai/models/api_keys
```

这将输出我们的模型访问密钥。保存此值以备后用。我们在查询模型时会需要它。

### 步骤 2B：使用云控制台创建模型访问密钥

![Screenshot 2025-05-28 at 10.20.12 AM.png](https://blog.aidroplet.com/uploads/Screenshot_2025_05_28_at_10_20_12_AM_88f5e2646b.png)

如果我们想使用控制台，只需在控制台中导航到 Gradient 平台的“Serverless Inference”选项卡。到达后，使用右下角的按钮“Create model access key”。

![Screenshot 2025-05-28 at 10.44.53 AM.png](https://blog.aidroplet.com/uploads/Screenshot_2025_05_28_at_10_44_53_AM_2a86741797.png)

然后，我们只需为密钥命名。保存输出的值以备后用！我们稍后在 Python 中进行无服务器推理时会需要它。

### 步骤 3：使用 Python 和无服务器推理生成文本

有了新的模型访问密钥，我们就可以从任何能访问互联网的机器上开始运行 DigitalOcean 无服务器推理了！我们建议使用 Jupyter Notebook。按照本[教程](https://blog.aidroplet.com/tutorials/do-gpu-jupyter-dl-setup/)中概述的步骤，为本文设置你的环境。

环境设置好后，打开一个新的 .ipynb IPython Notebook 文件。使用下面的代码片段开始生成文本，具体来说，是回答法国首都是什么。编辑代码片段，将第 5 行的 API 密钥值替换为你自己的。

```
from openai import OpenAI
import os

client = OpenAI(
    api_key= **“你的模型访问密钥”**,
    base_url="https://inference.do-ai.run/v1"
)

stream = client.chat.completions.create(
    model="llama3-8b-instruct",
    messages=[
        {
            "role": "developer",
            "content": "你是一个乐于助人的助手。",
        },
        {
            "role": "user",
            "content": "法国的首都是什么？",
        },
    ],
    stream=True,
    max_completion_tokens=10
)

for chunk in stream:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)
```

这应该会输出“法国的首都是巴黎”。我们建议根据需要更改诸如 `max_completion_tokens` 之类的值，以更好地适应你的提示词。我们还可以编辑第 10 行的模型值，将其更改为 DigitalOcean Gradient 模型产品中列出的任何可用模型。这个模型库会不断更新以反映行业的发展，所以请经常回来查看更新。

## DigitalOcean 无服务器 AI 的用例

现在我们已经设置好了运行无服务器推理的环境，我们可以使用该模型进行大量的活动。从大语言模型所能做的一切出发，我们可以创建强大的智能体应用程序，利用 AI 模型的优势。一些可能的用例包括：

- 事件驱动型应用程序：特定事件触发大语言模型的运行，这在智能体用例中很常见
- 可扩展的后端服务：当后端的推理可能需要无限扩展时，无服务器可以确保你的用户永远不会等待
- 数据处理：批处理作业和数据处理可以有效且高效地处理，而无需昂贵的服务器配置置 

## 结语

对于寻求基于大语言模型的解决方案，但又不想费心聘请人员或学习部署自己服务器所需步骤的公司来说，无服务器推理是一个真正的答案。借助 DigitalOcean 的 Gradient Platform，从强大的 NVIDIA GPU 访问无服务器推理变得比以往任何时候都更容易！我们鼓励大家尝试这个新的解决方案！

感谢你与 DigitalOcean 社区一起学习。查看我们提供的计算、存储、网络和托管数据库产品，或新注册的用户希望使用 DigitalOcean Gradient AI 平台上的 Opus 4.6、GPT 5.2等高级模型，可直接联系[卓普云（aidroplet.com）](https://www.aidroplet.com/)。

large_images (18).png

medium_images (18).png

small_images (18).png

thumbnail_images (18).png

xsmall_images (18).png

images (18).png

只需要两步就可以调用 Qwen、Kimi、GPT、Claude等模型，无需搭建服务器。

教程：如何使用DigitalOcean Gradient 平台上的无服务器推理

本文将介绍，通过开源工具，配合DigitalOcean云平台的大模型 API 服务，直接使用Claude Opus 4.6、Sonnet以及其他任意一种模型。价格与官方持平的同时，统一平台管理，多team、多token、支付宝支付。

## 解决思路：引入 Claudo 开源项目

解决这一问题的工程方案是引入一个**本地代理层**。开源项目 **claudo** 正是这一思路的优雅实现。

Github：[https://github.com/digitalocean/claudo](https://github.com/digitalocean/claudo?tab=readme-ov-file)

它的工作原理并非修改 Claude Code 源码，简单来说，架构是这样的：

```
┌────────────┐         ┌────────────┐         ┌────────────┐
│ Claude Code│  ──▶    │  LiteLLM   │  ──▶    │  DO Grad.  │
│   (CLI)    │Anthropic │   Proxy    │ OpenAI  │  AI API    │
│            │ format  │ (localhost) │ format  │            │
└────────────┘         └────────────┘         └────────────┘
```

这个结构的关键点在于：

- 不修改 Claude Code
- 不改变开发者使用方式
- 仅调整请求的“出口”

这是一次**调用路径重构**，而不是工具替换。而且以现在 [DigitalOcean 官方的计费标准](https://docs.digitalocean.com/products/gradient-ai-platform/details/pricing/#foundation-model-pricing-anthropic)来看，Token 成本基本不会有变化（注：Sonnet 4.6 在 200K Token 以内的价格与官方完全持平）。根据公开数据显示，Claude Code官方使用的是3.5 Sonnet（默认）和 Claude 3.5 Opus，而DigitalOcean 云平台还可以提供更 Sonnet 4.5/4.6 与 Claude Opus 4.6。

DigitalOcean 既是 [developer.amd.com 的云基础设施](https://blog.aidroplet.com/product-updates/mi300x-droplet-launch/)，也是给 [build.nvidia.com 提供 Serverless 推理服务的能力提供者](https://blog.aidroplet.com/news/building-ai-factory-for-agentic-era-nvidia-gtc/)，是经过两大GPU厂商认可的。所以不仅提供的是官方认可的 大模型与开源模型，而且能为全球用户提供稳定的网络连接。你的Claude Code 不会再断连了。

## 使用Claudo后会带来哪些变化？

相比于直连，使用 `claudo` 重构路径带来了显著的工程收益：

### 集中的Token成本管理

Claudo 会在本地启动一个 LiteLLM 代理，它把你的 Claude Code 请求转发到 DigitalOcean Gradient AI 云平台。

所有的 Token 消耗均通过 DigitalOcean 账户统一结算。这对于团队开发尤为关键：你可以像管理云服务器一样管理 AI 成本，实现**从“黑盒计费”到“结构化控制”的转变。**

### 网络环境自愈与并发支持

Claudo 在底层做了大量工程细节工作：

- **自动化环境**：它会自动创建并管理一个 Python 虚拟环境（venv）来运行 LiteLLM，无需开发者手动干预。
- **动态端口映射**：它支持在 `4100–4200` 范围内自动寻找空闲端口，支持多个并发会话，每个会话都有独立的代理实例。
- **统一接口**：API 请求会通过 DigitalOcean 云平台欧美的数据中心转发到 Claude Code，所以网络环境获得企业级云平台保障，不会再出现断连或掉线。


### 可观测性与审计

因为引入了本地代理层，所有的模型映射和请求状态（Status）都变得透明可见。你可以通过 `claudo status` 查看运行中的实例，或者通过日志追踪潜在的调用故障。

默认情况下，Claude Code 更像一个“工具”。

但当调用路径可控之后，它可以变成系统的一部分：

- 统一 API Key 管理
- 调用限流与权限控制
- 请求日志与审计

这些能力在个人使用时不明显，但在团队或企业环境中非常关键。

## 从零跑通一遍配置流程

整个过程比较轻量，可以在几分钟内完成。

### 1. 安装

```bash
npm install -g claudo
```


### 2. 初始化配置

```bash
claudo setup
```

需要输入 [DigitalOcean Gradient AI 的 API Key](https://docs.digitalocean.com/reference/api/create-personal-access-token/)，用于请求鉴权。注意：新注册的DigitalOcean账号可使用的模型、Token 每秒吞吐量是有上限的，如果遇到问题或需要提高上限，可联系[卓普云](https://www.aidroplet.com/)来开通提升限额。


### 3. 启动代理

```bash
claudo
```

启动后，本地会开启一个代理端口，并自动完成：

- 请求地址重写
- 协议转换（Anthropic → OpenAI 兼容接口）

此后，Claude Code 的使用方式不会发生变化。


## 总结：从“工具”到“基础设施”的工程化转型

在不修改任何业务代码的前提下，引入 **claudo** 将调用路径从“直连 Anthropic”重构为“本地代理 + DigitalOcean”，其核心价值在于：**在体验无感的同时，实现了链路的可控。**

虽然从表面上看，你的调用方式和交互体验没有变化，且 DigitalOcean 针对 **Claude Sonnet 4.6** 的阶梯定价与 Anthropic 官方完全持平，但在长期的团队协作中，这种“工程化路径”会逐渐显现出其不可替代的稳定性与财务透明度。

当大模型能力日趋同质化时，未来的技术壁垒不再仅仅取决于“用了什么模型”，而在于“如何更稳、更省、更专业地接入模型”。**claudo** 展示了一种极简的思路：通过重构调用路径，将一个简单的 CLI 插件升级为了企业级的可靠基础设施。如果你也正受困于 API 调用波动或账单管理，这种“中间代理”的架构思维无疑是目前的最佳解法。

**项目参考：** [digitalocean/claudo](https://github.com/digitalocean/claudo)

---
相关阅读：
- [不用海外卡、不怕封号，OpenClaw 稳定跑 Claude / GPT 的最简单方法](https://blog.aidroplet.com/tutorials/openclaw-use-claude-or-GPT/)
- [教程：让OpenClaw一次接入Claude、Qwen、DeepSeek 多个模型](https://blog.aidroplet.com/tutorials/openclaw-multiple-model/)

large_images-2.png

medium_images-2.png

small_images-2.png

thumbnail_images-2.png

xsmall_images-2.png

images-2.png

通过开源工具 claudo + DigitalOcean Gradient，使用 Claude Code 的价格与官方持平，同时支持支付宝付款、团队统一管理、两大 GPU 厂商认证的稳定网络连接

使用 DigitalOcean 实现 Claude Code “低配订阅 + 外部 Token”

上周在 NVIDIA GTC 上发布的 [NVIDIA Dynamo 1.0](https://developer.nvidia.com/blog/nvidia-dynamo-1-production-ready/) 现已面向 DigitalOcean 客户开放，有助于提升性能并降低成本。NVIDIA Dynamo 1.0 在 NVIDIA GB200 NVL 系统上提供 7 倍推理性能提升，通过与 [DigitalOcean 的智能推理云](https://www.aidroplet.com/product/serverless-inference/)结合，客户可以以更低的成本获得更高性能，同时受益于无缝部署。在共同努力下，DigitalOcean 与 NVIDIA 的优化已经为 Workato 等客户实现了 67% 的成本节省，而这一代新的 Dynamo 可以为企业级智能体（AI Agent）工作流解锁更大的收益。DigitalOcean 客户可以通过容器镜像获取 NVIDIA Dynamo 1.0，可以在 [Droplet 云服务器](https://www.aidroplet.com/product/cloudcpu/) 上运行，也可以与推理运行时（vLLM、SGLang、TensorRT）一起直接部署在 DigitalOcean Kubernetes 上。

## 什么是 NVIDIA Dynamo 1.0？

NVIDIA Dynamo 是一个高性能推理服务框架，专为加速和优化大规模生成式 AI 和推理模型而设计。Dynamo 作为一个编排层，运行在 vLLM、SGLang 和 NVIDIA TensorRT-LLM 等引擎之上。你可以把它想象成 GPU 集群的分布式交通控制器，无缝编排跨集群的 GPU 和内存资源，并通过智能路由减少瓶颈。

Dynamo 1.0 提供的关键技术突破包括：

- **7 倍性能提升**：与 NVIDIA Blackwell Ultra GPU 搭配使用时，Dynamo 可将推理性能提升高达 7 倍，显著降低每个 token 的成本。
- **KV 感知路由**：Dynamo 摒弃了简单的轮询负载均衡，而是将请求路由到已在对话历史中缓存了相关“记忆”的特定 GPU 上。
- **分离式服务**：Dynamo 将“预填充”（读取提示词）和“解码”（生成答案）两个阶段拆分到不同的 GPU 上执行，从而最大化利用率并降低延迟。
- **内存卸载**：KV 块管理器（KVBM）在高速 GPU 内存与低成本的存储层之间动态迁移数据，使您能够处理超长上下文窗口而无需担心内存上限。

## DigitalOcean 如何使用 Dynamo 优化推理工作负载以提升吞吐量和降低延迟

使用 DigitalOcean 上的 NVIDIA Dynamo，客户既能享受出色的性价比，又能获得简单的部署流程以及与 Dynamo 架构高度契合的运行环境，尤其是在需要严格管控 GPU 集群、进行 KV 缓存优化和路由的场景下。DigitalOcean 已通过 NVIDIA Dynamo 为客户带来了实实在在的成效。近期，我们与 Workato 的 AI 研究实验室合作，在其平台上扩展了代理型 AI 能力，该平台处理着超过 1 万亿次自动化工作负载。为满足生产级推理对效率与成本的严苛要求，该团队在 [DigitalOcean 托管 Kubernetes (DOKS)](https://www.digitalocean.com/products/kubernetes) 上部署了 NVIDIA Dynamo 与 vLLM。

在 DOKS 上使用 NVIDIA Dynamo v0.4.1 与 vLLM，Workato 实现了：

- **每 GPU 吞吐量提升 67%**，端到端延迟降低 79%，首 token 响应时间降低 77%（相较于在相同硬件上的其他配置）
- **硬件成本降低 33%**：在实现同等性能的前提下，使用 NVIDIA H200 GPU 相比 NVIDIA A100 GPU 成本更低
- **模型成本降低 67%**，同时所用 GPU 数量减半

欢迎查阅卓普云官网的技术博客，了解更多 [Workato 如何在 DigitalOcean 上取得如此显著成效的细节](https://blog.aidroplet.com/news/workato-nvidia-technical-deep-dive-agentic-inference-cloud/)。

借助 Dynamo 1.0 的强大能力以及全新推出的 NVIDIA HGX B300s，我们期待为像 Workato 这样的客户带来更进一步的性能提升与成本优化。

## NVIDIA 和 DigitalOcean 推理优化的未来

除了 Dynamo 1.0，作为今年 NVIDIA GTC 的一部分，我们激动地分享其他产品发布和更新，以进一步增强 DigitalOcean 智能推理云的能力。包括我们全新的 AI 优先 Richmond 数据中心，无缝体验 NVIDIA Agent Toolkit 和 NemoClaw 并部署到 DigitalOcean，支持 NVIDIA Nemotron 3 Super 等高性能模型，以及更多内容。了解更多关于 [DigitalOcean 和 NVIDIA GTC 的详细信息](https://blog.aidroplet.com/news/building-ai-factory-for-agentic-era-nvidia-gtc/)，可访问卓普云AI Droplet官网博客。

目前 [NVIDIA B300 GPU 云服务器](https://www.aidroplet.com/product/b300/)已经开放预约申请，现在联系卓普云AI Droplet可提前锁定 B300 GPU 云服务器资源。

NVIDIA Dynamo 1.0 现已面向 DigitalOcean 客户开放，提供 7 倍推理性能提升，大幅降低企业级 AI 推理成本。

高性能、低成本推理新标准：NVIDIA Dynamo 1.0 现已上线 DigitalOcean 推理云平台



目前，很多企业与个人开发者都已经用上了OpenClaw（小龙虾）。但是，不论你的OpenClaw是部署在本地电脑，还是部署在国内的云平台上，很多AI团队在实际使用时，都会遇到这些问题：

- **国内龙虾不支持Claude、OpenAI**：部署在国内云平台的OpenClaw，仅支持国内部分大模型，无法使用Claude、OpenAI、Gemini 等海外大模型
    
- **账号封禁风险**：使用Claude、OpenAI等模型时，经常因为地区、风控、支付方式导致账号被限制或封禁，业务无法持续运行
    
- **多平台、多Key管理混乱**：团队往往需要同时使用多个模型，不同平台的API Key、支付方式、调用方式都不同，运维复杂度极高
    
- **企业采购困难**：很多团队使用个人账号、个人信用卡、非正式渠道。这对于企业来说：不安全、不稳定、不适合长期业务
    
这些问题本质上是因为缺乏一个稳定、合规的“Token聚合平台”来统一管理和调用海外大模型API。

今天提供一个方法，无需你重新部署OpenClaw，只需要更改几行配置，即可稳定使用Claude、OpenAI等海外知名大模型，而且成本可控。

  

## 为什么你的OpenClaw很难稳定使用Claude？

对于中国团队来说，要在云端的OpenClaw上使用Claude、GPT等海外大模型主要面临两大痛点：

**1. 账号封禁风险**

首先，所有国内云平台都默认不支持Claude、OpenAI、Gemini这些海外模型。所以用户需要自己开账号购买这几个大模型，然后将API配置到云端的OpenClaw中。但是由于这些大模型存在地区限制，否则，你的Claude、OpenAI等账号就会被限制或封禁。这对需要持续运行的业务来说是致命打击——账号一旦被封，业务就会中断。

**2. 企业采购困难**

要想用Claude，你就就需要使用海外的信用卡或支付方式，否则账号也会被禁。但是绝大部分国内企业都很难解决这个问题。如果团队用个人账号和个人信用卡，这对企业来说也存在安全隐患，不利于长期发展。

另外，如果你是将OpenClaw部署在自己公司的机房服务器，接入多种大模型的话，不同模型的API Key需要分别管理，支付方式、调用接口都不同。团队需要维护多套系统，运维成本高。而且，由于你的服务器在国内，要使用Claude、OpenAI，你仍然要解决海外信用卡、网络连接等一系列问题。

### 一个更简单的思路：通过Token聚合平台，不要直连模型

很多团队的问题，本质在于：

> **直接对接模型厂商 API（OpenAI/ Claude）**

其实，还有一种更稳定的方式：

> **通过“统一推理网关”来调用模型**

这正是 DigitalOcean 提供的解决方案。

## 怎么给OpenClaw配置Claude、GPT模型？

答案就是：使用[DigitalOcean Gradient Serverless Inference](https://www.aidroplet.com/product/serverless-inference/)。即便你已经在阿里云、腾讯云等平台部署了 OpenClaw，也可以通过它来接入稳定可用的 Claude、GPT API。

### 什么是DigitalOcean Gradient Serverless Inference？—— 一个企业级Token聚合平台

DigitalOcean 云平台的 Gradient Serverless Inference，是其 DigitalOcean Gradient AI 平台中的核心能力之一，本质上是一种：无需管理任何基础设施，即可直接调用主流大模型的统一推理服务。

你可以把它理解为：

> **“OpenAI / Claude API 的统一网关 + Serverless 托管层”**
实际上，这就是一种面向企业和开发者的 Token聚合平台：它不再要求你直接对接每个模型厂商，而是通过一个统一的API入口，聚合了多个模型的Token计费与调用能力。

通过它：

- 不需要直接对接 OpenAI 或 Anthropic
    
- 不需要自己处理账号与支付
    
- 不需要部署模型或 GPU
    

👉 只需要一个 API Key，就可以调用多个模型。

### 它解决了什么问题？

使用 Gradient Serverless Inference 后：

- 不再需要多个 API Key
    
- 不再需要海外信用卡
    
- 不再担心账号封禁
    
- 不再处理复杂网络问题
    

👉 本质上，它将你从“管理多个模型厂商”的繁琐中解放出来——这正是下一代 Token聚合平台 的核心价值。

### 已经使用腾讯云、阿里云，怎么配置Claude、OpenAI？

如果你已经部署了 OpenClaw，只需要做一件事：

👉 **修改模型配置**

举个例子，假设你已在腾讯云、阿里云上部署了OpenClaw。你可以在后台重新配置OpenClaw的模型。

#### 1. 获取 API Key

首先，在 DigitalOcean 控制台中开通 Gradient Serverless Inference，并获取OpenAI 的 API Key。

![Pasted image 20260318145622.png](https://blog.aidroplet.com/uploads/Pasted_image_20260318145622_08cc31c57f.png)

然后创建 Access Key，你可以在这个DigitalOcean 后台直观地看到从OpenAI 到 Claude、Kimi等不同模型的Token价格。

![Pasted image 20260318150131.png](https://blog.aidroplet.com/uploads/Pasted_image_20260318150131_f8e2be95df.png)

通常你会拿到类似如下信息：

```Plain
Access_Key  
BASE_URL=https://api.digitalocean.com/v2/ai/inference
```

#### 2.进入阿里云或腾讯云后台，更改OpenClaw配置

如下图所示，是阿里云部署的OpenClaw。你可以在Model Settings 中选择“Add Model”，然后将你在DigitalOcean后台获取的Access Key 填写到 API Key字段里，然后把Base URL填写进去，就完成了模型的添加。这里的Model Name可以在DigitalOcean文档中找到。

对应文档地址：https://docs.digitalocean.com/products/gradient-ai-platform/details/models/#foundation-models-openai

![img_v3_02vs_8f689852-6ab1-49f8-842a-e6c64bee6f1g.jpg](https://blog.aidroplet.com/uploads/img_v3_02vs_8f689852_6ab1_49f8_842a_e6c64bee6f1g_06556298d6.jpg)

DigitalOcean 平台提供统一调用接口，开发者无需为不同模型编写不同代码。只需要在DigitalOcean后台修改模型，即可切换不同模型。不需要更改API Key。

> 注意：新注册账号可使用的模型、Token每秒吞吐量是受限的，需要联系[卓普云](https://www.aidroplet.com/product/serverless-inference/)来开通提升限额。

如果你是使用了腾讯云的OpenClaw，那么你的配置修改页面如下图所示。

![20260318-163537.jpg](https://blog.aidroplet.com/uploads/20260318_163537_5344b9baac.jpg)

在这里，我们可以填写成：

```JSON
"provider": "digitalocean-gradient",
  "base_url": "https://inference.do-ai.run/v1",
  "api": "openai-completions",
  "api_key": " YOUR KEY",
  "model": {
    "id": "openai-gpt-5.2",
    "name": "GPT-5.2"
```

完成以上修改，你就可以直接让你的OpenClaw调用OpenAI或Claude模型了。

  

### 专为AI Agent与OpenClaw场景优化

随着OpenClaw等Agent框架的普及，越来越多企业需要稳定调用多个模型。[DigitalOcean Gradient](https://www.aidroplet.com/product/serverless-inference/)专为这一场景优化：

**核心优势**：

- **支持企业支付**，中国企业只需联系卓普云（aidroplet.com）签署企业合作，即可。企业可以避免通过个人账号注册Claude等模型，并费尽周折地搞定海外信用卡支付等问题。
    
- **统一管理Agent所需模型**。企业可以在DigitalOcean后台通过建立多个Access Key，接入多种不同的模型，灵活分配给企业内部不同的团队。例如给研发团队配置Claude模型，给无代码需求的团队配置其它模型，发挥不同模型所长。
    
- 由于是DigitalOcean 系统对接了OpenAI、Claude，所以模型可以稳定使用，**中国企业可以完全避免账号封禁导致Agent停止运行。**
    
- **支持快速切换不同模型能力**。企业只需要在DigitalOcean 后台，修改Acceess Key 配置的模型，即可快速切换。
    
- **DigitalOcean平台提供的模型****API****来自官方API封装或官方授权模型部署**，并非通过共享账号或灰色转售方式提供。企业可以放心将其用于正式产品与业务系统。
    
- DigitalOcean 是美国上市云服务平台，有14年运营经验，全球60万付费用户，并通过多项安全认证，包括SOC2、SOC3、CSA、GDPR、CBPR。
    

## 总结

对于已经部署了 OpenClaw 的团队来说，真正的瓶颈往往并不在 Agent 框架本身，而是在**模型接入这一层**：账号门槛高、调用不稳定、运维复杂、企业合规困难。这些问题如果不解决，再好的 Agent 也难以稳定落地到实际业务中。

本文提供的思路，本质上是对架构的一次“轻量优化”：

> **不动 OpenClaw，只替换模型调用方式 —— 引入一个可靠的 Token聚合平台。**

通过 DigitalOcean 的 Gradient Serverless Inference，将原本“直连 OpenAI / Claude”的方式，升级为通过统一推理网关调用模型。这样带来的变化是：

- 从“多平台、多 Key 管理” → **一个 Access Key 统一调用所有模型**
- 从“高风险账号体系” → **平台级稳定接入**
- 从“复杂部署与网络依赖” → **标准化 API 调用**
- 从“不可控成本” → **按量计费、可预测成本结构**
    

更重要的是，这种方式对现有系统几乎是零侵入的：

> **只需修改几行配置，无需重装、无需迁移、无需重构**

对于企业而言，这不仅是一次技术优化，更是一次**可持续 AI 架构的升级**：既保证了模型能力的灵活性，也确保了业务运行的稳定性与合规性。

如果你正在为团队寻找一个稳定、合规、企业级的 Token聚合平台 来支持 OpenClaw 或其他 AI Agent，可以直接联系[卓普云（aidroplet.com](https://www.aidroplet.com/product/serverless-inference/)）。

相关阅读：

- [Moltbot/Clawdbot是什么？如何在云服务器部署 Moltbot/Clawdbot？](https://blog.aidroplet.com/tutorials/Clawdbot-quickstart-guide/)
- [教程：让OpenClaw一次接入Claude、Qwen、DeepSeek 多个模型](https://blog.aidroplet.com/tutorials/openclaw-multiple-model/)
- [使用 DigitalOcean 实现 Claude Code “低配订阅 + 外部 Token”](https://blog.aidroplet.com/tutorials/claude-code-gradient-connect/)
- [OpenClaw 多智能体部署：弹性扩展、零运维](https://blog.aidroplet.com/product-updates/openclaw-digitalocean-app-platform/)
- [OpenClaw Skills 是什么？功能、安装与使用指南](https://blog.aidroplet.com/tutorials/what-are-openclaw-skills/)


本文提供一种无需重构的方案，仅改配置即可稳定调用Claude、OpenAI等多种模型，并且成本可控。

为什么你的OpenClaw很难稳定使用Claude？一个“Token聚合平台”轻松接入海外模型



OpenClaw Skills 旨在让使用 OpenClaw 的 AI 智能体更加实用、模块化且功能强大。你不需要从零构建所有能力，而是可以将特定功能——例如调用 API、查询数据库、检索文档或执行工作流——打包为可复用组件，让智能体在需要时调用。

这种方式可以让智能体逻辑保持清晰和灵活，同时也更容易在不重写核心架构的情况下持续扩展能力。  
目前，[ClawHub](https://clawhub.ai/) 上已经拥有超过 **2,857 个 Skills**，你只需几次点击即可下载并集成到自己的 OpenClaw 系统中。

**核心要点：**

- OpenClaw 是一个开源 AI 助手，设计用于在本地系统运行，并基于消息应用、文件、浏览器和终端数据构建自动化工作流。
- OpenClaw Skills 是包含指令代码的 Markdown 文件，可帮助智能体执行特定任务或扩展工作流能力。
- Skills 可以从 ClawHub、OpenClaw Skills 或私有仓库获取。任何开发者都可以创建 Skill 并分享给 OpenClaw 使用。
- 常见 Skills 包括支持编码、生产力、沟通和协作等场景的功能模块。

## 什么是 OpenClaw Skills？

OpenClaw Skills 是包含操作说明的 Markdown 文件，用于指导智能体完成特定任务或使用特定工具。每个 Skill 本质上是一个目录，其中包含一个带有 YAML frontmatter 的 `skill.md` 文件。

此外，Skill 目录中还可能包含额外的参考文件或可执行脚本，用于实现相关功能。这种打包方式让你可以轻松为 OpenClaw 添加新的能力。一旦添加 Skill 文件，系统就可以立即按照说明调用新的工具、API 或工作流。

目前，这些 Skills 覆盖多种类别，包括编码、写作、数据分析、DevOps、AI 与 ML、社区工具以及生产力应用等。

如果你想更系统地了解 [OpenClaw](https://blog.aidroplet.com/tutorials/Clawdbot-quickstart-guide/)，我们还写过一篇入门文章，对 OpenClaw 框架进行了实用概述。通过这些内容，你可以在决定部署和实验之前，快速了解 OpenClaw 的能力边界。


## OpenClaw Skills 的优势

OpenClaw Skills 可以帮助你扩展系统能力，并充分利用 OpenClaw 的实时自动化和应用连接能力。这意味着你可以构建一个 AI 助手，让它自动与 WhatsApp、Slack、IDE 以及家庭服务器等应用协同工作，例如管理消息、自动化代码部署，同时根据用户的响应偏好、通知方式和工作流步骤持续优化行为。

OpenClaw Skills 的主要优势包括：

- **生态系统丰富**  
通过 ClawHub、私有仓库以及 Reddit 讨论社区，你可以持续发现新的 Skills 并集成到 OpenClaw 中。每天都有新的 Skills 被开发出来，覆盖从编程到生产力工具的各种任务场景。

- **安装简单**  
只需要 Skill 的 Markdown 文件以及 OpenClaw CLI，就可以在你的系统环境中运行它并快速集成新功能。一旦 Skill 安装到本地机器，它会自动连接到 OpenClaw 系统并立即可用。

- **任务自动化**  
这些 Skills 可以帮助自动化大量重复任务，例如日历和邮件管理、服务器健康监控、代码管理等。

- **主动执行能力**  
OpenClaw 通过本地系统访问和持久化记忆来保持长期上下文，使其能够主动完成任务，并在后台运行 Skills，从而在无需持续人工监督的情况下完成工作。


## OpenClaw Skills 的注意事项

虽然 OpenClaw Skills 大幅扩展了 AI 助手的能力，但它们也带来了新的安全风险。OpenClaw 允许任何开发者在 ClawHub 上发布 Skill 文件，这意味着攻击者也可能在这些 Markdown 文件中植入恶意指令，从而危害系统安全。

OpenClaw 已知的一个重要漏洞是 **CVE-2026-25253**，该漏洞可能导致 AI 网关被攻击者利用，从而向系统注入任意命令。

使用 OpenClaw Skills 时还可能面临一些更具体的风险，例如 **未经授权删除邮件**（这一案例曾被 Summer Yue 记录）。如果你决定使用 OpenClaw Skills，至少应采取以下安全措施：

- **审查来源**  
查看 Skill 的创建者、其 GitHub 仓库，以及项目获得的 Star 数量或 ClawHub 上的用户评价。

- **检查权限**  
查看 Skill 文件请求的权限，只授予运行所需的最小权限。

- **验证功能范围**  
确保 Skill 只执行你愿意让智能体代为完成的操作。Skills 不仅可能包含恶意行为，也可能执行安装者未充分考虑的操作。

- **隔离环境测试**  
在独立的测试环境中部署 Skill 文件，观察其运行行为，并在确认安全后再部署到生产环境。

- **编写运维手册（Runbook）**  
记录哪些 Skills 会被触发、需要哪些输入，以及如何进行回滚操作，从而在出现异常行为时能够及时干预。

- **保持警惕**  
注意潜在的安全异常，例如助手尝试访问与任务无关的内部 URL 或 API，或者响应中出现底层系统指令片段或“隐藏”的 Markdown 内容等。  你也可以通过 **ClawDex** 对 Skills 进行初步安全扫描。




## 如何获取 OpenClaw Skills

OpenClaw Skills 可以通过 **ClawHub、OpenClaw Skills 网站以及私有仓库**下载。运行这些 Skills 所需的条件只有两个：**OpenClaw CLI** 和 **Skill 文件**。

如果你通过 ClawHub 安装，可以运行命令：

```
clawhub install <skill-slug>
```

如果你通过 DigitalOcean 的 **1-Click Marketplace** 部署（例如 OpenClaw Droplet 或 App Platform），则需要使用：

```
npx clawhub install <skill-slug>
```

那么这些 Skill 文件在 OpenClaw 中具体存放在哪里？通常，Skills 会从以下三个位置加载：

- **Bundled skills**：随安装包一起提供（npm package 或 OpenClaw.app）
- **Managed/local skills**：`~/.openclaw/skills`
- **Workspace skills**：`<workspace>/skills`


如果出现同名 Skill，优先级顺序为：

```
<workspace>/skills（最高）
~/.openclaw/skills
bundled skills（最低）
```

此外，你还可以通过 `~/.openclaw/openclaw.json` 中的  
`skills.load.extraDirs` 配置额外的 Skill 目录（优先级最低）。

在 **多智能体（multi-agent）环境** 中，每个 Skill 文件也有独立的工作空间：

- 每个智能体的专属 Skills 位于该智能体的 `<workspace>/skills` 目录
- 共享 Skills 位于 `~/.openclaw/skills`，同一台机器上的所有智能体都可以使用
- 如果需要为多个智能体共享一组 Skills，也可以通过 `skills.load.extraDirs` 添加共享目录

如果同名 Skill 存在于多个位置，仍然遵循上述优先级规则：**workspace > local > bundled**。

如果你想了解如何更高效地安装 OpenClaw Skills（以及如何连接 Moltbook），可以参考[卓普云官网往期教程](https://blog.aidroplet.com/tutorials/Clawdbot-quickstart-guide/)。



## OpenClaw Skills 示例


目前 OpenClaw 生态中已经存在大量 Skills。为了帮助你了解其应用场景，下面列出一些示例（截至 2026 年 2 月）。

### 软件开发

这些 Skills 可以自动化编码流程，并执行常见的软件管理任务。

**Cron-backup by zfanmy**

Cron-backup 是一个面向编码工作流的 OpenClaw Skill，用于设置带有版本跟踪和自动清理机制的定期备份。适用于以下场景：

- 定期备份目录或文件
- 在版本更新时自动执行备份
- 自动清理旧备份以节省存储空间
- 为配置文件、代码仓库或用户数据制定备份策略


**Security-check by wolffan**

Security-check 用于在安装 Skills 之前检查安全漏洞，并执行定期安全审计。例如：

- 检查 Skills 是否存在安全漏洞
- 验证 Skill 描述与实际行为是否一致
- 扫描可能的 Prompt Injection 攻击
- 检查是否存在硬编码的密钥或凭证

**Agentmail-integration by synesthesia-wav**

该 Skill 用于集成 **AgentMail API**，实现 AI 智能体的邮件自动化功能，例如：

- 创建和管理专用邮箱
- 以编程方式发送和接收邮件
- 通过 webhook 和实时事件处理邮件工作流


### 智能家居与 IoT

如果你希望使用 AI 管理家庭设备，以下 Skills 可以提供帮助。

**Home Assistant by iAhmadZain**

用于控制 Home Assistant 智能家居设备，例如灯光、开关、温控、场景或脚本，并接收 webhook 事件。支持通过 REST API（外部调用）和 webhook（HA 自动化触发）实现双向通信。

**Home Assistant CLI by JonesChi**

使用官方 **hass-cli** 工具进行高级 Home Assistant 控制，支持：

- 自动补全
- 事件监控
- 历史查询
- 更丰富的输出格式


它是基于 curl 的 Home Assistant skill 的替代方案，适合希望获得更强交互式 CLI 体验的用户。

**Homeassistant N8n Agent by enchantedmotorcycle**

该 Skill 用于将 OpenClaw 与 [n8n 自动化平台](https://blog.aidroplet.com/tutorials/n8n-workflow-automation-guide/)连接，从而实现 Home Assistant 自动化。 

它仅包含操作说明，并不会请求额外凭证或执行未声明操作，但说明中假设使用本地 webhook，并未提供完整的认证配置指南。

### 健康与个人发展

对于更偏个人化的应用场景，这些 Skills 可以帮助你获取健康和健身相关数据。

**Longevity Assistant by lofimichael**

根据证据等级评估延寿干预措施，并提供关于补充剂、睡眠、运动以及健康协议的研究分析。适用于抗衰老研究、健康寿命分析或论文评估。

**Apple Health Skill by nftechie**

允许你使用 AI 与 Apple Health 数据进行交互，例如查询：

- 运动记录
- 心率数据
- 活动环
- 健身趋势

**Personal Finance Tracker by aka-anoop**

用于管理个人财务，例如：

- 按类别记录支出
- 设置预算
- 接收 EMI 或年度费用提醒

### 搜索与研究

如果你希望使用 OpenClaw 进行数据收集或趋势研究，可以考虑以下 Skills。

**Tavily Web Search by arun-8687**

通过 Tavily API 实现针对 AI 优化的网页搜索，并返回简洁且相关的结果。

**Academic Deep Research by kesslerio**

一个透明且严谨的研究工具，提供完整方法论，而不是简单的 API 包装。其特点包括：

- 每个主题执行两轮研究
- 使用 APA 第七版引用
- 提供证据层级分析
- 设置 3 个用户检查点

适用于文献综述、竞争情报分析以及需要可重复研究流程的场景。

**Proactive-research by robbyczgw-cla**

用于自动监控特定主题，并在重要变化出现时提醒用户，例如：

- 产品发布
- 价格变化
- 新闻事件
- 技术更新

它支持定期 Web 搜索、AI 重要性评分、智能提醒和每周摘要，并提供带上下文记忆的总结。

## OpenClaw Skills 常见问题

**什么是 OpenClaw Skills？**

OpenClaw Skills 是包含智能体行为指令的 Markdown 文件，通常用于执行特定任务（例如安全审计）或与特定工具（如 Slack、Gmail）协同工作。

**OpenClaw Skills 可以做什么？**

它们可以自动化任务，并指导智能体按照特定方式执行工作，例如编码、生产力工具、创意写作或沟通任务。

**如何找到 OpenClaw Skills？**

可以在 ClawHub、OpenClaw Skills 网站、GitHub、Reddit 社区以及私有仓库中找到。这些仓库包含数千个 Skills，因为任何开发者都可以创建并上传它们。

**如何安装 OpenClaw Skills？**

通过 OpenClaw CLI 执行：

```
clawhub install <skill-slug>
```

如果使用 DigitalOcean 的 1-Click Marketplace 部署，则运行：

```
npx clawhub install <skill-slug>
```

**OpenClaw Skills 是否安全？**

并非天然安全。由于任何人都可以上传 Skill，因此可能包含恶意代码。在安装前务必检查代码内容。

此外，即使 Skill 本身并不恶意，也可能包含功能强大的操作。例如，如果某个 Skill 拥有发送短信的权限，它可能会向通讯录中的朋友、同事或企业联系人发送消息。

是否使用 OpenClaw Skills 完全取决于用户，用户需要根据自己的使用场景进行安全评估。

**如何判断一个 Skill 是否可能存在恶意行为？**

- 确认 Skill 名称拼写是否正确（例如 clawhub vs claw__d__hub）
- 使用 ClawDex 等工具扫描已知漏洞
- 使用 `clawhub uninstall <skill-slug>` 删除未使用或未知 Skills
- 在连接到包含敏感信息的 OpenClaw 实例时格外谨慎，例如邮箱、信用卡、手机或即时通讯应用，因为 OpenClaw 可以代表你自动执行操作


## 在 DigitalOcean 上部署 OpenClaw Skills

在系统中运行 OpenClaw Skills 需要提前做好规划和安全设计。如果你决定使用 OpenClaw，将其部署在独立的云服务器上虽然不能完全消除风险，但可以有效限制影响范围，并避免智能体直接访问你的个人文件或其它隐私数据。

DigitalOcean 为此提供了两种部署方式。

**OpenClaw DigitalOcean 应用托管**

适合希望在无需管理基础设施的情况下大规模运行多个智能体的团队：

- 在一个 [App Platform（应用托管平台）](https://www.aidroplet.com/product/app-platform/) 配置中声明多个智能体（如销售、客服、个人助手）
- 通过 Git 推送更新，实现零停机部署和自动回滚
- 通过调整实例规格实现可预测的扩展，并保持透明定价

**DigitalOcean 1-Click部署 OpenClaw**

起价 **$12/月**，自动创建一个安全加固的服务器环境：

- 基于容器的隔离机制，使智能体运行与主机系统相互隔离
- 默认启用身份验证，每次部署生成唯一网关令牌
- 自动配置防火墙规则、非 root 执行和权限限制


---
相关阅读：

- [Moltbot/Clawdbot是什么？如何在云服务器部署 Moltbot/Clawdbot？](https://blog.aidroplet.com/tutorials/Clawdbot-quickstart-guide/)
- [不用海外卡、不怕封号，OpenClaw 稳定跑 Claude / GPT 的最简单方法](https://blog.aidroplet.com/tutorials/openclaw-use-claude-or-GPT/)
- [教程：让OpenClaw一次接入Claude、Qwen、DeepSeek 多个模型](https://blog.aidroplet.com/tutorials/openclaw-multiple-model/)
- [使用 DigitalOcean 实现 Claude Code “低配订阅 + 外部 Token”](https://blog.aidroplet.com/tutorials/claude-code-gradient-connect/)
- [OpenClaw 多智能体部署：弹性扩展、零运维](https://blog.aidroplet.com/product-updates/openclaw-digitalocean-app-platform/)


本文介绍 OpenClaw Skills 的概念、工作机制与安装方式，并分析其自动化能力、应用场景及安全风险。

OpenClaw Skills 是什么？功能、安装与使用指南

随着大语言模型在各行各业的快速落地，GPU选型已成为AI企业最重要的技术决策之一。2026年初正式出货的 [NVIDIA B300（Blackwell Ultra）](https://www.aidroplet.com/product/b300/)凭借其288GB HBM3e显存和强大的推理性能，正在成为企业部署DeepSeek等大模型的新选择。本文将为你全面解析B300的技术规格、与前代产品的性能差异，以及在运行DeepSeek系列模型时的实际表现。

##  B300带来了什么革命性提升？

NVIDIA B300基于Blackwell Ultra架构，于2026年1月正式出货，是目前NVIDIA发布的**最强单GPU计算平台**。与上一代Hopper架构相比，B300在多个关键指标上实现了质的飞跃。

从架构迭代的角度来看，Blackwell Ultra并非简单的制程升级，而是NVIDIA针对大模型推理场景的深度优化。**14 petaFLOPS的稀疏FP4算力**、**288GB HBM3e显存**、**8 TB/s显存带宽**——这些数字背后代表的是单卡即可承载更大参数规模模型的能力，以及更高的推理吞吐量。

对于正在考虑GPU选型的AI企业来说，B300的出现意味着几个关键变化：

1. 单卡可承载更大模型：288GB显存意味着单卡即可加载70B参数模型（FP16精度），还能剩余100GB以上空间用于KV Cache
2. 推理成本显著降低：相比H100，B300可实现**11-15倍**的推理吞吐量提升
3. 支持更长上下文：更大的显存空间可以完整保留长文本的KV Cache，避免因内存不足导致的性能降级


## NVIDIA B300 GPU参数是什么？

### B300 的核心计算能力

| GPU  | 架构              | FP8（Dense）算力 | FP16 算力     | 显存          | 显存带宽      | NVLink   |
| ---- | --------------- | ------------ | ----------- | ----------- | --------- | -------- |
| B300 | Blackwell Ultra | 7000 TFLOPS  | 3500 TFLOPS | 288GB HBM3e | 8 TB/s    | 1.8 TB/s |
| B200 | Blackwell       | 4500 TFLOPS  | 2250 TFLOPS | 192GB HBM3e | 8 TB/s    | 1.8 TB/s |
| H200 | Hopper          | 756 TFLOPS   | 378 TFLOPS  | 141GB HBM3e | 4.8 TB/s  | 900 GB/s |
| H100 | Hopper          | 756 TFLOPS   | 378 TFLOPS  | 80GB HBM3e  | 3.35 TB/s | 900 GB/s |

根据 NVIDIA 官方技术文档，B300 的​**显存容量是 H200 的 2 倍**​，是 H100 的​**3.6 倍**​；B200 ≈ H200 的**~6倍 FP8推理能力**。这种代际间的巨大提升，主要得益于 Blackwell 架构在计算密度和内存系统上的双重优化。

### B300 功耗与散热


如果你是希望自己购买B300 GPU 自建机房的，那么需要特别关注的是，B300的TDP（热设计功耗）达到了**1,400W**，这意味着在实际部署时必须采用**液冷方案**（Direct Liquid Cooling, DLC）。相比H200/H100的风冷方案，这增加了基础设施的复杂度，但对于追求极致性能的企业级部署而言，这是必须接受的现实。


一个8卡DGX B300系统的峰值功耗约为**14kW**，相当于两个H100 DGX系统的功耗。企业在规划机房时需要充分考虑电力和散热能力。所以与其自己购买，不如直接使用云服务的B300 GPU，这样可以将功耗与散热问题交给云平台去处理，可以节省大量的运维成本。

### B300 的网络与互联

B300配备了**ConnectX-8**网卡，支持**1.6Tbps**的网络带宽。在多节点集群部署时，这为大规模推理提供了充足的网络吞吐能力。对于需要跨节点部署的大型模型服务，网络带宽往往是瓶颈所在，B300在这方面提供了充足的冗余。

DigitalOcean 云平台的 B300 GPU Droplet云服务器会支持 25 Gbps 的机器间网络带宽，10 Gbps的公网带宽，满足大规模分布式推理和训练对节点间通信的基本需求，在性能和成本之间取得理想平衡。

**结论：**

- NVIDIA B300 GPU显存达到 **288GB HBM3e**
- FP8算力达到 **7000 TFLOPS**
- 相比H200显存提升 **2倍**
- 相比H100显存提升 **3.6倍**

## B300与H200、AMD MI350X GPU云服务器规格对比

  

对于计划使用云端GPU资源的企业，以下是DigitalOcean即将推出的B300 GPU Droplet与现有H200、AMD MI350的配置对比：

  

| 规格项         | H200 GPU Droplet            | AMD MI350 GPU Droplet        | B300GPU Droplet                   |
| ----------- | --------------------------- | ---------------------------- | --------------------------------- |
| **GPU显存**   | 141×8 GB                    | 288×8 GB                     | 288×8 GB                          |
| **vCPU数量**  | 192                         | 192                          | 224                               |
| **CPU型号**   | 2×Intel Xeon Platinum 8592+ | 2×Intel Xeon Platinum 8568Y+ | 2×Intel Xeon Emerald Rapids 6767P |
| **主机内存**    | 1920 GiB                    | 2048 GiB                     | 3600 GiB                          |
| **启动存储**    | 2 TiB NVMe                  | 2 TiB NVMe                   | 2 TiB NVMe                        |
| **临时存储**    | 40 TiB NVMe                 | 40 TiB NVMe                  | 40 TiB NVMe                       |
| **公网/私网带宽** | 10/25 Gbps                  | 10/25 Gbps                   | 10/25 Gbps                        |
| **GPU互联带宽** | 3.2Tbps RoCE2               | 3.2Tbps RoCE2                | 6.4Tbps RoCE2                     |
| **月流量配额**   | 60TB                        | 60TB                         | 60TB                              |


从对比表中可以发现，B300 GPU Droplet在以下几个维度具有明显优势：

- **显存翻倍**：288GB vs 141GB，可加载更大参数规模的模型
- **CPU核心数增加**：224 vCPU vs 192 vCPU，数据预处理能力更强
- **主机内存大幅提升**：3600 GiB vs 1920 GiB，约为1.9倍
- **GPU互联带宽翻倍**：6.4Tbps vs 3.2Tbps，多GPU协同效率更高


这些硬件层面的提升，将直接转化为更快的模型加载速度、更高的并发处理能力、以及更流畅的多GPU分布式推理体验。

  

## NVIDIA B300可以运行DeepSeek吗？实测性能解析

### 为什么B300特别适合运行DeepSeek

DeepSeek系列模型（尤其是DeepSeek R1等推理模型）在运行时有一个显著特点：**chain-of-thought推理过程中会产生巨大的KV Cache**。这意味着模型需要将大量的注意力键值对保存在显存中，以保证推理的连续性和准确性。

传统的80GB或141GB显存在面对长上下文推理时，往往需要频繁地在显存和内存之间交换数据（KV Cache eviction），这会显著增加推理延迟并影响输出质量。而B300的**288GB超大显存**提供了充足的Headroom，可以完整保留长文本的KV Cache，**直接提升推理质量和响应速度**。

这对于企业部署DeepSeek R1等推理模型来说尤为重要——更长的上下文保持能力意味着更连贯的思考过程，最终体现为更准确的输出结果。

### DeepSeek-V3.2性能实测数据


根据[vLLM官方博客在2026年2月发布的深度测试报告](https://vllm.ai/blog/gb300-deepseek)，DeepSeek-V3.2在GB300（B300系列）上的性能表现如下：

| 场景 | 吞吐量（TGS） |
|------|--------------|
| **Prefill-only** (输入序列长度=1) | **7,360** |
| **混合上下文** (输入2k, 输出1k) | **2,816** |


测试配置采用**NVFP4量化 + TP2（张量并行2卡）**方案。NVFP4是一种NVIDIA开发的4位浮点量化格式，在保持模型精度的同时大幅提升推理效率。

### DeepSeek-R1性能实测数据

DeepSeek R1作为当前最受关注的推理模型之一，在B300上的表现更为亮眼：

| 场景 | 吞吐量（TGS） |
|------|--------------|
| **Prefill-only** (输入2k, batch=256) | **22,476** |
| **混合上下文** (输入2k, 输出1k) | **3,072** |


实测数据显示，DeepSeek R1的Prefill吞吐量约为DeepSeek V3.2的**3倍**，这得益于R1模型架构的优化。


### FP4 vs FP8：量化方案选择


| 量化方案 | Prefill提升 | 混合上下文提升 |
|----------|-------------|----------------|
| **NVFP4 + TP2** vs FP8 | **1.8倍** | **8倍** |


实测数据表明，**NVFP4 + TP2**是目前B300上运行DeepSeek系列模型的**最优配置**。相比FP8量化，NVFP4在保持模型输出质量的同时，实现了数倍的吞吐量提升。


### Blackwell Ultra vs Hopper：代际性能对比


| 指标 | B300 vs H200 |
|------|--------------|
| Prefill吞吐量 (ISL=2k) | **8倍** |
| 短输出吞吐量 (ISL=2k, OSL=128) | **20倍** |

  

这一数据意味着，对于典型的在线推理场景，B300可以提供**远高于H200的并发处理能力**。在相同的服务品质（SLA）下，企业可以使用更少的GPU资源承载相同规模的流量，从而显著降低推理成本。

## B300推理性能有多强？与H100/H200成本对比

### 主流GPU推理性能对比


| GPU | 预估吞吐量 (Llama 70B) | 每GPU每小时成本 | 相对Token成本 |
|-----|----------------------|----------------|--------------|
| H100 SXM | ~21,800 tok/s | $2.00 | 1.0x（基准） |
| H200 SXM | ~31,700 tok/s | $3.50 | 0.83x（省17%） |
| B300（FP8） | ~100,000+ tok/s | ~$8.00* | ~0.58x（省42%） |
| B300（FP4） | ~150,000+ tok/s | ~$8.00* | ~0.39x（省61%） |



*注：DigitalOcean 的 B300 GPU 服务器按需定价尚未正式公布，2026年2月外部猜测价格约为 $8/GPU/小时，价格会有偏差。最终实际定价请根据DigitalOcean与卓普云（aidroplet.com）官方公布信息为准。*

  

### 主流云厂商B300价格对比


| 供应商 | 实例类型 | 每GPU每小时价格 |
|--------|----------|----------------|
| DigitalOcean | B300 GPU Droplet（即将推出） | ~$8* |
| AWS | p6-b200.48xlarge（8卡B300） | $11.70 |


*注：DigitalOcean B300 GPU Droplet定价尚未最终确定，表中所列为其外部猜测价格。*

  

### 关键洞察：按输出付费，而非按小时



B300的定价策略带来了一个重要的思维转变：**不要只看每小时成本，而要计算每个Token的成本**。
  

虽然B300的每小时成本高于H100，但带来的推理吞吐量提升更为显著。在实际应用中，这意味着：


- **相同的推理吞吐量，B300的总体成本更低**：3-5倍的吞吐量提升远超成本增幅。
- **相同的预算，B300可以支撑更大规模的模型服务**：适合高并发生产环境。
- **对于DeepSeek R1这类推理密集型工作负载，B300的性价比优势尤为明显**。
- **相比AWS等顶级云厂商，DigitalOcean B300价格优势明显**：预计可节省约30%左右。

*数据来源：Spheron GPU Cloud 2026年2月定价、AWS EC2定价（2026年3月）；性能数据仅供参考，实际表现可能因工作负载、配置和环境差异而有所不同。*



按照以往DigitalOcean的定价规律推测，DigitalOcean即将推出的B300 GPU Droplet定价将**远低于AWS和OCI**等顶级云厂商的同类产品。作为面向中小企业的云服务提供商，DigitalOcean一直以高性价比著称，此次B300 GPU Droplet的推出，将进一步降低企业使用高性能GPU的门槛。


对于初创公司和研究团队而言，能够以更低的价格获得同等性能的GPU资源，意味着可以**将更多预算投入到模型开发和业务创新**中，而非基础设施成本。

## B300适用场景与选型建议

### 最佳应用场景


B300特别适合以下应用场景：

1. **大规模推理服务**：70B+参数模型的在线推理，单GPU吞吐量可达10万+ tokens/秒
2. **推理密集型工作负载**：DeepSeek R1、OpenAI o系列等推理模型，288GB显存可完整保持KV Cache
3. **多节点训练集群**：6.4Tbps的GPU互联带宽，有效支撑分布式训练的通信需求
4. **400B+参数模型部署**：8卡DGX B300提供2.3TB总显存，可完整加载400B参数模型

### 选型建议

  

| 场景 | 推荐配置 |
|-----|----------|
| **DeepSeek R1在线服务** | B300 + NVFP4 + EP2（专家并行） |
| **DeepSeek V3推理+训练** | B300 + NVFP4 + TP2（张量并行） |
| **长上下文文档理解** | B300（充分利用288GB显存） |
| **成本敏感型推理** | B300 Spot + FP4量化 |


### 需要注意的挑战


- **液冷需求**：必须配置液冷方案，增加基础设施投入
- **功耗较高**：单卡1,400W，需要评估机房电力和散热能力
- **软件生态**：需要CUDA 12.x、cuDNN 9.x、TensorRT-LLM 0.15+支持


## 总结与展望

| GPU  | 显存    | 带宽       | 推理性能  | 适合场景  |
| ---- | ----- | -------- | ----- | ----- |
| H100 | 80GB  | 3.35TB/s | 基准    | 中型LLM |
| H200 | 141GB | 4.8TB/s  | 2-3x  | 长上下文  |
| B300 | 288GB | 8TB/s    | 8-20x | 推理模型  |

NVIDIA B300（Blackwell Ultra）的推出，标志着AI基础设施进入了一个新的性能时代。凭借**288GB HBM3e显存**、**8 TB/s带宽**和**14 petaFLOPS算力**，B300为大模型推理提供了强大的硬件基础。

对于正在部署DeepSeek等大模型的企业而言，B300的实测性能令人印象深刻：

- **DeepSeek R1** Prefill吞吐量达到**22,476 TGS**，是H200的**8倍**
- **NVFP4量化**可将推理效率进一步提升**1.8-8倍**
- 单卡即可承载完整70B模型+KV Cache，大幅简化部署复杂度



## 哪里可以获得B300 GPU云服务器？

目前部分GPU云平台已经开始提供B300 GPU服务器测试资源，如果您希望**提前体验和测试**可联系[卓普云（aidroplet.com）](https://www.aidroplet.com/product/b300/)名额有限，先到先得！


## NVIDIA B300 GPU常见问题（FAQ）

### NVIDIA B300 GPU显存是多少？

NVIDIA B300 GPU 配备 **288GB HBM3e显存**，显存带宽达到 **8 TB/s**。相比上一代 NVIDIA H200 GPU 的141GB显存，容量约提升 **2倍**；相比 NVIDIA H100 GPU 的80GB显存提升约 **3.6倍**。更大的显存使B300能够单卡部署70B参数级别的大模型，并保留充足的KV Cache空间。

### NVIDIA B300和H200性能差多少？

在大模型推理场景中，NVIDIA B300 GPU 的性能通常明显高于 NVIDIA H200 GPU。根据公开测试数据，在长上下文推理任务中：

- Prefill吞吐量可达到 **约8倍提升**
- 短输出推理吞吐量可达到 **约20倍提升**

性能提升主要来自 **Blackwell Ultra架构Tensor Core升级、FP4量化支持以及更大的HBM3e显存容量**。


### NVIDIA B300 GPU可以运行DeepSeek模型吗？

可以。NVIDIA B300 GPU 非常适合部署 DeepSeek R1 和 DeepSeek V3 等大模型。  
B300的 **288GB显存** 可以容纳更大的模型参数，并保留大量 **KV Cache**，在长上下文推理任务中能够显著降低显存交换带来的延迟问题，从而提升推理速度和稳定性。

### NVIDIA B300 GPU功耗是多少？

NVIDIA B300 GPU 的热设计功耗（TDP）约为 **1400W**，明显高于上一代 NVIDIA H100 GPU 的700W。因此大多数企业级部署环境需要采用 **液冷散热方案（Direct Liquid Cooling）**。在8卡服务器系统中，总功耗通常会达到 **14kW左右**。

### NVIDIA B300 GPU适合哪些AI应用场景？

NVIDIA B300 GPU 主要面向高性能AI计算场景，例如：

- **大模型推理服务**（如DeepSeek、Llama等）
- **长上下文LLM应用**    
- **高并发AI API服务**
- **多节点分布式训练**

由于显存容量大、带宽高，B300特别适合 **70B以上参数模型推理和推理密集型AI工作负载**。

---
参考资料：
https://www.aidroplet.com/product/b300/
https://www.aidroplet.com/product/h200/
https://www.nvidia.com/zh-tw/data-center/dgx-b300/
https://vllm.ai/blog/gb300-deepseek
https://www.spheron.network/blog/nvidia-b300-blackwell-ultra-guide/

large_google-deepmind-LaKwLAmcnBc-unsplash-scaled.jpg

medium_google-deepmind-LaKwLAmcnBc-unsplash-scaled.jpg

small_google-deepmind-LaKwLAmcnBc-unsplash-scaled.jpg

thumbnail_google-deepmind-LaKwLAmcnBc-unsplash-scaled.jpg

xlarge_google-deepmind-LaKwLAmcnBc-unsplash-scaled.jpg

xsmall_google-deepmind-LaKwLAmcnBc-unsplash-scaled.jpg

google-deepmind-LaKwLAmcnBc-unsplash-scaled.jpg

解析NVIDIA B300与H200 GPU的参数差异、推理性能及运行DeepSeek模型时的表现，帮助企业选择适合的大模型算力方案。

NVIDIA B300 vs H200：GPU参数、性能与DeepSeek推理能力解析

Workato 的 AI 研究实验室专注于帮助客户利用智能体 AI 能力扩展生产自动化，这些系统可以推理、执行并协调跨业务的工作。目前，Workato 服务 **超过 12,000 家全球企业客户**，例如 Broadcom（博通）、Intuit（财务软件领域的 SaaS 巨头）、Box 等公司。

在 Workato 的业务规模下，**每月需处理 1 万亿次自动化工作流**，LLM 推理效率是硬性要求：每毫秒延迟和每个浪费的 GPU 周期直接影响成本、吞吐量和可靠性。为了使智能体（AI Agent）工作负载达到生产就绪状态，团队需要一个为生产规模设计的推理栈——提供可预测的性能和规模化下的单位经济效益，而不仅仅是原始算力。

DigitalOcean 与 Workato 的 AI 研究实验室团队合作，在其智能推理云上设计和调优这个部署，使用 [NVIDIA Dynamo](https://developer.nvidia.com/dynamo) 搭配 vLLM 运行在 [DigitalOcean Kubernetes 托管服务（DOKS）](https://www.aidroplet.com/product/kubernetes/) 上。为了支持 100K Token 上下文长度而不降低性能，Workato 选择了 [NVIDIA H200 GPU 云服务器](https://www.aidroplet.com/product/h200/)，因为它的显存有 141GB HBM3e。

工作负载的内存占用约为 125 GB（包括模型权重、键值缓存和激活缓冲区），因此单个 NVIDIA H200 GPU 能够容纳整个 footprint。然而，团队在每个节点使用 8 路张量并行来最大化持续吞吐量和并发负载下的延迟稳定性。

DigitalOcean 针对 Workato 的需求帮助他们最终实现了：

- **在所有测试配置中实现最高的每秒查询数**
- **每 GPU 吞吐量提升 67%**，**端到端延迟降低 79%**，**首 Token 时间降低 77%**（与相同硬件上的不同配置相比）
- **使用 NVIDIA H200 GPU vs NVIDIA A100 GPU 达到相同性能，硬件成本降低 33%**
- **模型成本降低 67%**，同时使用的 GPU 数量减少一半

关键在于引入键值（KV）感知路由，以减少冗余并在推理栈中最大化性能和成本的价值。

本文，我们将详细拆解 DigitalOcean 是如何帮助 Workato 的AI 研究实验室团队实现这些优化成果的。如果你的团队也在追求同样的目标，欢迎联系[卓普云（aidroplet.com）](https://www.aidroplet.com/)进一步了解 DigitalOcean 云平台的各项 AI 相关产品与云服务。

## LLM 如何处理请求以及为什么规模化后成本变高

在讨论架构决策之前，值得先理解驱动推理成本 mechanics 以及为什么这是一个 Workato 需要解决的复杂问题。每个 LLM 推理请求都经过两个阶段：

- **Prefill** 是模型处理整个输入提示词并为它读取的每个 Token 构建内部内存（称为键值/KV 状态）的阶段。这个阶段是计算密集型的，与输入序列长度呈二次方复杂度（O(n²)）。对于长上下文工作负载（例如 10K-100K Token 提示词），prefill 可能占据总推理成本的大部分。主要原因是模型需要为提示词中的每个 Token 计算与其他所有 Token 的自注意力分数。例如，如果提示词是 1000 个 Token，模型大约执行 1000 × 1000 次注意力运算。如果提示词是 100,000 个 Token（与 Workato 的工作负载相同），这些运算会激增到 100 亿次。100K Token 的 prefill 需要每秒大量浮点运算（FLOPs），可能需要 GPU 满负荷运行数秒，导致每 GPU 吞吐量降低，直接增加成本。
- **Decode** 是模型使用缓存的 KV 状态逐个生成 Token、预测下一个 Token 的阶段。这个阶段受限于显存带宽；decode 阶段的性能直接影响 Token 流式输出的延迟。

存在真实的工作负载共享公共输入前缀，其中很大一部分相同的文本块在多个请求中重复使用。在企业 SaaS 应用（如 Workato 的 AI 研究实验室）中，推理请求之间通常存在高度的Prefix共享。当 GPU 执行 prefill 操作时，它会构建内存中的上下文（KV 缓存），这对于长提示词工作负载来说构建成本很高。

现在，如果后续查询都被路由到不同的 GPU，每个 GPU 都需要重建 KV 缓存，导致消耗冗余的 FLOPs，而这些 FLOPs 本可以用于服务其他查询。

## KV 感知路由如何解决这个问题

KV 感知路由是一种利用前缀共性并将它们路由到同一 GPU 的技术。这有助于使 GPU 能够利用预热的 KV 缓存（通常通过 RadixCache）完全跳过计算密集的 prefill 阶段。

这有助于大幅降低用户的首 Token 延迟（TTFT），并通过回收本会花在冗余 prefill 计算上的 GPU FLOPs 来显著提升集群的总吞吐量。

## NVIDIA Dynamo + DOKS：KV 感知路由的编排大脑

[NVIDIA Dynamo](https://www.nvidia.com/en-us/ai/dynamo/) 是一个开源的、低延迟的、模块化推理框架，设计用于在各个推理引擎之上运行。它与引擎无关，可以编排 vLLM（这就是我们在这里使用的）、TensorRT-LLM 和 SGLang 等后端。Dynamo 不是为了让单个 GPU 更快而设计的，而是为了防止集群做冗余工作并让正确的 GPU 保持在正确的推理阶段忙碌。在 Workato 的场景中，我们使用 Dynamo 的 KV 感知路由能力。

![workato-kv-aware-image3.png](https://blog.aidroplet.com/uploads/workato_kv_aware_image3_153b6f4619.png)

NVIDIA Dynamo 通过引入复杂的编排层改变了标准 LLM 基础设施，其能力远远超过普通多节点设置。Dynamo 的核心是一个全局调度器，全面了解集群中的每个 GPU，超越了只能看到自己本地资源的 worker 的局限性。这种全局视角由集群级 KV 缓存管理器管理，该管理器精心跟踪哪些 Token 驻留在特定的 worker 上，识别哪些块是"热"的或可以驱逐的，并确定重用、卸载或重新计算各种缓存段的最佳时机。

这个架构的定义特性是 KV 感知路由器，它用 LLM 感知的请求路由取代了传统的、"盲目的"轮询分配。路由器不是将所有 worker 视为平等的，而是使用复杂的成本函数根据现有缓存重叠和系统指标之间的关键权衡对候选 worker 进行评分。具体来说，它平衡了最小化 prefill 成本的需求（改善首 Token 时间 TTFT）与有效 decode 性能的要求，如 Token 间延迟（ITL）和每输出 Token 时间（TPOT）。通过整合对全局缓存状态的实时感知，Dynamo 确保路由决策是全局最优的，从而实现无缝的 KV 缓存卸载和跨不同请求的最大化重用。

然而，部署像 NVIDIA Dynamo 这样的集群感知推理栈会引入真正的运营复杂性。你不再是在负载均衡器后面运行几个 vLLM 服务器，而是在运行一个分布式系统，包含路由前端、检测过的 worker 后端、KV 缓存管理器，以及它们之间的实时协调。要做到这一点，既需要正确的框架，也需要支持它的平台。虽然 NVIDIA Dynamo 提供了逻辑，但 DOKS 提供了使 KV 感知路由成为可能的执行环境。DOKS 不仅仅是"运行"pod；其原生服务发现和智能调度允许 Dynamo 前端充当集群范围的调度器。这确保传入的请求被即时路由到相关 KV 缓存已经存在的特定 GPU 节点，从而消除冗余计算并从完整推理栈中获取最大价值，具体包括：

- **路由前端和 worker 后端的独立副本管理**意味着团队可以在调优配置时分别扩展每一层。
- **Kubernetes 原生的服务发现**让路由器前端干净地找到并路由到 worker pod，无需自定义网络工作。
- **运营简单性**：DOKS 完全抽象掉控制平面，因此 Workato 的工程师可以专注于推理优化，而不是 Kubernetes 编排。

## 推理栈架构

我们使用 **nvidia/Llama-3.3-70B-Instruct-FP8** 作为模型，在各种 DOKS 集群上进行了评估：

- 1 节点，8 个 NVIDIA H200 GPU
- 2 节点，16 个 GPU
- 4 节点，32 个 GPU

我们还针对 NVIDIA Dynamo + vLLM（选择它是因为其广泛的特性覆盖和干净的集成界面）在两种配置下比较了每种拓扑：一种没有 KV 感知路由，另一种启用了 KV 感知路由。这将为 Workato 提供真正的性能-成本权衡空间地图，而不仅仅是单个数据点。

2 节点部署的完整集群架构如下：

![Workato-architecture-diagram.png](https://blog.aidroplet.com/uploads/Workato_architecture_diagram_904a820b74.png)

NVIDIA Dynamo 的前端路由器是位于 GPU worker pod 前方的轻量级 DOKS 服务。Worker 是配备 Dynamo 代理的完整 vLLM 实例，持续将 KV 缓存状态发布回路由器和缓存管理器。KV 缓存管理器是一个独立的 Pod，维护全局视图，跟踪哪些节点上的缓存是"热"的，发出驱逐信号，并向路由器的评分函数提供新鲜状态。将路由器、worker 和缓存管理器分离为独立的 DOKS 工作负载，使 Workato 能够独立调优每一层，并使架构能够随着工作负载需求的增长水平扩展。

## 两种测试配置

### 配置 1：无 KV 感知路由

此配置使用相同的模型、相同的 GPU，但启用了 vLLM 自己的优化：前缀缓存、块状 Prefill、FP8 权重和 KV 缓存。这**不包含** KV 感知集群路由——每个节点做出智能的本地决策，但没有跨集群的全局缓存状态视图。

```
vllm serve nvidia/Llama-3.3-70B-Instruct-FP8 \
  --tensor-parallel-size 8 \
  --enable-prefix-caching \
  --enable-chunked-prefill \
  --quantization fp8 \
  --kv-cache-dtype fp8 \
  --trust-remote-code
```

当此配置在 100K Token prefill 负载下运行时会发生什么？当两个提示词共享很长的公共前缀但落在不同的 worker 上时，两个节点都会冗余地重新计算相同的 prefill，因为双方都不知道对方已经完成的工作。在这种情况下，缓存局部性完全是偶然的——也就是说，一个请求是否受益于预热的 KV 缓存纯粹取决于运气，而不是战略性放置。这种缺乏协调导致严重负载不均衡的出现；一些 worker 被长 prefill 拖累，而其他 worker 处理 decode 重度流量，导致它们的处理队列发散。最终，在更高并发下尾延迟会激增，因为单个不幸的路由决策可能会将特定 worker 固定在多个重型 prefill 上，而其他可用资源却闲置。

### 配置 2：KV 感知路由

这是架构从根本上发生改变的地方，在我们测试的两种配置中，这是明显的赢家。总的来说，NVIDIA Dynamo 部署利用集群感知路由，将系统分为 1）前端（路由器 + 调度器），2）Worker 集合（配备 Dynamo 的 vLLM 实例）

#### Dynamo 前端（启用 KV 路由器）

```
python3 -m dynamo.frontend --http-port 8000 --router-mode kv
```

NVIDIA Dynamo 前端主动计算与可用 worker 的 KV 重叠分数，并应用专门的路由成本函数来决定 prefill 和 decode 阶段应该精确在哪里执行。通过跟踪集群范围的负载和当前全局缓存状态，系统确保每个请求都以最大效率处理。在这种设置下，前端完全启用 KV 路由运行，以验证这些架构改进。

#### Worker（部署为 GPU 节点上的 DOKS pod）：

每个 worker 都是通过 NVIDIA Dynamo 的包装器启动的 vLLM 实例。集成暴露了：

- **KV 缓存事件**：创建、重用或驱逐了哪些块
- **指标**：队列深度、decode 负载、内存压力

#### 配方：Dynamo + vLLM Worker

```
python3 -m dynamo.vllm \
  --model nvidia/Llama-3.3-70B-Instruct-FP8 \
  --tensor-parallel-size 8 \
  --enable-prefix-caching \
  --enable-chunked-prefill \
  --quantization fp8 \
  --kv-cache-dtype fp8 \
  --trust-remote-code \
  --enable-log-requests
```

#### 核心概念：KV 感知路由

对于每个传入请求和每个 worker，NVIDIA Dynamo 估计一个成本：

```
cost = overlap_score_weight * prefill_blocks + decode_blocks
```

其中：

- **prefill_blocks**：需要计算多少新 KV（缓存未命中成本）
- **decode_blocks**：worker 在 decode 端的繁忙程度
- **overlap_score_weight**：权衡 TTFT 与 decode 延迟

这将路由从**盲目的负载均衡器**转变为**状态感知的调度器**。

## 调优

到目前为止，我们讨论了 NVIDIA Dynamo + vLLM 之所以有效的原因：KV 感知路由、分离的 prefill/decode 和集群级调度。但在实践中，除非正确转动正确的旋钮，否则这些都没有意义。

我们将使用 Workato 的结果来分解这一点，并关注三个关键指标：

- **TTFT（首 Token 时间）**：请求到达后第一个 Token 产生的速度。
- **TPOT / ITL（每输出 Token 时间 / Token 间延迟）**：后续 Token 生成的速度。
- **吞吐量（QPS / 每 GPU 每秒 Token 数）**：系统可以处理的持续工作。

### TTFT：Prefill 成本与 KV 重用

首 Token 时间（TTFT）由 prefill 工作主导，即模型处理提示词构建 KV 状态的时间。这里的调优旋钮是：

- `--enable-prefix-caching`：为共享前缀重用 KV 块。
- `--enable-chunked-prefill`：将 prefill 分割成可管理的块以避免 GPU 停滞。
- `--kv-cache-dtype fp8`：减少显存占用和压力，改善缓存驻留。

**为什么 NVIDIA Dynamo 表现出色**：Dynamo 将请求路由到大多数 KV 前缀已经缓存的 worker，避免冗余 prefill。即使在 高并发（32 个提示词）下，TTFT 优势也很明显。

![workato-Median-TTFT-image5.png](https://blog.aidroplet.com/uploads/workato_Median_TTFT_image5_f9e69594c0.png)

**中位 TTFT(ms)（2 节点，16-32 个请求）：**

| 请求数 | NVIDIA Dynamo KV 感知路由 | 无 KV 感知路由 | 提升幅度 |
|--------|--------------------------|----------------|----------|
| 16 | 566.7 | 684.1 | +17.2% |
| 32 | 1454.9 | 6451.9 | +77.5% |


![workato-p50-latency-image4.png](https://blog.aidroplet.com/uploads/workato_p50_latency_image4_08c354b2ce.png)

**P50 延迟(s)（2 节点，16-32 个请求）：**

| 请求数 | NVIDIA Dynamo KV 感知路由 | 无 KV 感知路由 | 提升幅度 |
|--------|--------------------------|----------------|----------|
| 16 | 7.3 | 7.2 | -1.4% |
| 32 | 14.2 | 69.2 | +79.5% |

![workato-Median-TPOT-graph1.png](https://blog.aidroplet.com/uploads/workato_Median_TPOT_graph1_96a7568cad.png)


### TPOT / ITL：Decode 负载均衡

TPOT 和 ITL 取决于 GPU 在 decode 期间的繁忙程度。块状 prefill 防止单个重型请求阻塞 decode 管道。NVIDIA Dynamo 进一步跨 worker 平衡 decode 负载，即使在突发情况下也能保持 TPOT 稳定。

**数据快照（2 节点，16-32 个请求）：**

| 请求数 | NVIDIA Dynamo KV 感知路由 | 无 KV 感知路由 | 提升幅度 |
|--------|--------------------------|----------------|----------|
| 16 | 13.57 | 13.07 | -3.8% |
| 32 | 25.55 | 125.72 | +79.97% |

没有前缀感知路由，朴素的 vLLM 在高并发下崩溃，因为一些 worker 收到"prefill 重"的请求而其他则空闲，导致 TPOT 和尾延迟膨胀。

Dynamo 的优点:

- **KV 重用**：避免重新计算大型 prefill 段
- **路由**：将请求发送到具有热 KV 缓存的 worker
- **调度**：平衡 decode 负载，防止热点 GPU 拥塞

### QPS 和 Token 吞吐量：GPU 利用率

在 SLA 下每 GPU 的吞吐量（Token/秒/GPU）：

![workato-Token-throughput-graph2.png](https://blog.aidroplet.com/uploads/workato_Token_throughput_graph2_df898b4988.png)

**数据快照（2 节点，16-32 个请求）：**

| 请求数 | NVIDIA Dynamo KV 感知路由 | 无 KV 感知路由 | 提升幅度 |
|--------|--------------------------|----------------|----------|
| 16 | 525,898 | 515,279 | +2.06% |
| 32 | 216,978 | 129,785 | +67.19% |

通过 KV 感知路由，我们实现了**每 GPU 13,561 Token/秒，而没有 KV 感知路由时是 8,111 Token/秒**，**在相同硬件上提升了 67%**。这一改进从根本上改变了容量需求。对于固定的 SLA 和 Token 吞吐量目标，GPU 数量与每 GPU 吞吐量成反比。1.67 倍的吞吐量增益意味着每个 GPU 现在执行 1.67 个基准 GPU 的工作，将所需容量减少到原始占用的大约 60%，或者相同工作负载减少 40% 的 GPU。实际上，以前需要 10 个 GPU 的部署现在大约可以用 6 个 GPU 维持相同的负载。

更少的 GPU 意味着更少的节点、更低的每小时消耗和更少的扩展开销。每 GPU 更高的吞吐量不仅仅让系统更快：它减少了服务相同负载所需的 GPU 数量，将性能提升转化为可衡量的成本节约。

## 最后总结一下

Workato 在 DigitalOcean 智能推理云上的结果表明，规模化下的推理性能更多地取决于系统如何围绕模型架构，而不是模型本身。

对于长上下文、高并发工作负载，冗余的 prefill 计算和不均衡的 decode 负载迅速成为主要的成本和延迟驱动因素。仅仅增加 GPU 数量无法解决这些低效问题。协调路由和缓存感知调度可以做到。

通过在 DOKS 上部署 NVIDIA Dynamo + vLLM 并启用 KV 感知路由，Workato 消除了冗余的 prefill 工作，改善了 worker 之间的负载均衡，并在并发下稳定了延迟。在相同硬件上，这转化为每 GPU 每秒 Token 数提升 67%，负载下端到端延迟降低高达 79%，TTFT 降低 77%——从而降低每个 Token 的成本，并减少满足 SLA 所需的 GPU 数量。

关键结论是架构层面的：推理效率主要是一个系统问题。当路由、缓存管理、GPU 拓扑和 Kubernetes 编排协调一致时，收益会叠加。

最后，如果你希望测试体验 DigitalOcean GPU云服务器以及 AI 推理云产品，欢迎联系 DigitalOcean中国区独家战略合作伙伴卓普云。另外，DigitalOcean 即将在2026年初上线 NVIDIA B300 GPU 服务器，现在可预约测试，**预约渠道**：[卓普云官网 aidroplet.com](https://www.aidroplet.com/)。


large_images (14).png

medium_images (14).png

small_images (14).png

images (14).png

一文详解如何针对 Workato 的长上下文、高并发工作负载，实现了每 GPU 吞吐量提升 67%、端到端延迟降低 79%、首 Token 时间（TTFT）降低 77%，同时使用的 GPU 数量减少了一半，推理成本降低了 67%。

AI 成本太高怎么办？用推理路由自动分配 Claude、Qwen、DeepSeek

产品更新

既要 LLM 推理性能可预测，又要成本可控？专用推理了解一下

AI 正在变成智能体，传统云不够用了：DigitalOcean 的新解法

DigitalOcean 打造 AI 原生云，帮助 AI 应用大幅降低成本与运维复杂度

DigitalOcean 收购 Katanemo Labs：迎接 Agent 时代，重塑基础设施

教程

AI 成本太高怎么办？用推理路由自动分配 Claude、Qwen、DeepSeek

如何在无服务器推理上运行 Hermes Agent？

AI 推理产品省钱指南：如何通过基建优化降低 80% 推理成本？

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

新闻

DigitalOcean 助力 ACE Studio：推理延迟降40%，训练效率翻倍

DigitalOcean 助力 Bright Data 构建高稳定数据平台

当所有人都在讨论 AI 工具时，我们已经用 AI 跑通了一家公司

DigitalOcean 亮相 NVIDIA GTC 2026：为智能体时代打造 AI 工厂