过去一年，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 工厂

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

thumbnail_images (14).png

xsmall_images (14).png

images (14).png

一文详解如何针对 Workato 的长上下文、高并发工作负载，实现了每 GPU 吞吐量提升 67%、端到端延迟降低 79%、首 Token 时间（TTFT）降低 77%，同时使用的 GPU 数量减少了一半，推理成本降低了 67%。

DigitalOcean 基于 NVIDIA GPU 如何为 Workato 降低 67% AI 推理成本


Camperoni 是一个帮助家长为孩子寻找夏令营、课外活动和各类课程的在线平台，所有信息都可以在一个地方查找和管理。这个产品的想法，源于两位创始人一次共同的“吐槽时刻”。她们都是母亲，在为孩子安排各种活动时发现，要分别在不同渠道报名和管理信息非常麻烦。

Camperoni 联合创始人兼 CTO Tzikis 说：“我们一共有三位创始人，但只有我不是家长。另一位两位都是妈妈，而且她们几乎是在同一周——也就是夏令营报名周——产生了同样的想法。”

两位创始人约出来吃午饭，本来是打算各自聊聊自己的创业点子，结果发现想法几乎完全一致。意识到这是个值得尝试的机会后，她们决定一起把这个平台做出来，并邀请 Tzikis 加入，负责技术方向。

Tzikis 回忆说：“她们最开始只是来问我，这个产品在技术上应该怎么做。后来聊着聊着，我就直接以联合创始人的身份加入，负责整个技术团队。”

在正式开发产品之前，团队先用一个简单的无代码 MVP 验证了市场需求。确认确实有用户愿意使用之后，他们决定从头搭建一个可以长期发展的正式平台。

“当我们发现这个想法确实有人感兴趣时，就决定认真把产品做起来。”Tzikis 说。

## 从创业开始就选择了 DigitalOcean

在选择云基础设施时，Tzikis 参考了自己多年使用不同云平台的经验，包括 **AWS亚马逊云服务** 和 **微软云 Azure**。对于一个团队规模很小的早期创业公司来说，他很清楚：过于复杂的平台只会拖慢开发速度。

他说：“如果你想快速推进产品，就不希望把时间花在配置各种权限、学习一堆名字奇怪的服务上。那些额外的复杂度其实没什么必要。”

由于团队里没有专门的 SRE 或 DevOps 工程师，Camperoni 需要的是既稳定又简单、易于管理的基础设施。

“我一直习惯用有限的资源把事情做好。”Tzikis 说，“如果没有人专门负责策略管理、权限体系这些事情，那么平台本身越复杂，维护成本就越高。”

因为他之前在个人项目中使用过 **DigitalOcean**，所以很快就做出了决定。

“我很清楚，对我们来说 DigitalOcean 会比那些更复杂的平台更合适。所以我们就直接用了它，而且到现在我都觉得这是个非常正确的选择。”

## 在 DigitalOcean 上构建 Camperoni 平台

随着 Camperoni 从最初的 MVP 逐渐发展为正式上线的平台，团队的后端架构基本都建立在 DigitalOcean 的托管服务之上。

平台的一个核心功能，是收集并整理某个地区的夏令营和活动信息。

Tzikis 介绍说：“我们会抓取一个地区所有夏令营的信息，然后整理到平台上。最开始其实只是一个运行在 [Droplet（DigitalOcean的云主机）](https://www.aidroplet.com/product/cloudcpu/) 上的小 Python 脚本。”

随着产品不断完善，团队将后端升级为基于 Django 的架构，并逐渐使用更多托管服务来减少运维工作。

目前 Camperoni 的技术架构主要包括：

- **[DigitalOcean App Platform（应用托管）](https://www.aidroplet.com/product/app-platform/)**：托管 Django 后端服务
- [**PostgreSQL托管服务**](https://www.aidroplet.com/product/postgresql/)：作为主数据库
- **Droplets**：运行 Python 抓取任务
- [**Spaces** 对象存储](https://www.aidroplet.com/product/spaces/)：存放图片和静态资源，并通过 CDN 分发
- Marketplace 集成工具，例如 **Datadog**，用于日志和监控

其中，托管数据库为团队节省了大量时间。

Tzikis 说：“这些事情没必要自己管理。对我们来说，云端托管服务一直都很稳定，而且自动更新小版本的功能也非常省心。


## 用更小的团队，更快推进产品

对 Camperoni 来说，使用 DigitalOcean 最大的收益并不是某一个具体性能指标，而是节省下来的时间。

Tzikis 坦言：“我其实就是团队的瓶颈。如果没有这种几乎不用操心运维的体验，我不可能一边管理六个开发者、一边还负责基础设施。”

由于基础设施管理的工作大幅减少，Camperoni 可以用一个精简的工程团队持续推进产品开发。

虽然团队很少需要联系技术支持，但 Tzikis 仍然很看重这种“需要时有人可以帮忙”的感觉。

有一次团队遇到一个间歇性的容器网络问题，DigitalOcean 的支持团队一直跟进，直到问题彻底解决。

Tzikis 说：“这就是你希望从合作伙伴那里得到的服务——真正人与人之间的沟通，而不是被复杂的流程卡住。”

## 持续增长，基础设施保持“隐形”

随着 Camperoni 的用户逐渐增加，团队也会持续关注 DigitalOcean 的新功能，并在合适的时候引入。

Tzikis 说：“基本上每隔一两个月，总会发现一些新的功能可以用，比如最近托管数据库告警的改进。”

目前 Camperoni 还没有在产品中大量使用 AI，但团队对未来的可能性保持开放。

他说：“如果有一天我们需要运行自己的内部大语言模型，我第一反应还是会先看看这些现成的解决方案。毕竟我们已经深度使用 DigitalOcean 的生态。”

对 Camperoni 来说，理想的基础设施状态其实很简单——**尽可能“无感知”**。

Tzikis 总结说：“我希望 DigitalOcean 就像我们业务背后的影子一样。只要我几乎想不到它的存在，就说明它做得很好。”

在这样的基础设施支持下，Camperoni 可以把全部精力放在产品和用户体验上，而不用被底层技术分散注意力。

如果你也想使用DigitalOcean作为你的第一个出海云平台，欢迎联系[卓普云AI Droplet](https://www.aidroplet.com/)了解产品服务。



large_images-2.png

medium_images-2.png

small_images-2.png

thumbnail_images-2.png

xsmall_images-2.png

images-2.png

三位创始人打造儿童活动平台 Camperoni，在没有 SRE 的情况下，通过 DigitalOcean 托管服务快速构建并稳定运营整个平台。

没有 SRE 的创业团队，如何用 DigitalOcean 搭建一整套儿童课程在线平台

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量身打造的基础组件，从而缩短上线时间，降低运维成本。

large_images (17).png

medium_images (17).png

small_images (17).png

thumbnail_images (17).png

xsmall_images (17).png

images (17).png

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

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

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

为了帮助团队在生产环境中可靠运营，并对潜在安全问题保持清晰可见，我们今天推出 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 云安全态势管理功能正式上线

随着团队规模扩大和无服务器工作负载的增长，安全管理变得与代码管理同等重要。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 安全性和可管理性的重要进步。通过将访问权限与个人身份关联，我们实现了自动访问撤销、更好的可审计性，以及更安全的无服务器应用环境。

large_images (15).png

medium_images (15).png

small_images (15).png

thumbnail_images (15).png

xsmall_images (15).png

images (15).png

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 多智能体部署：弹性扩展、零运维 

在 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 托管等。

large_images (20).png

medium_images (20).png

small_images (20).png

thumbnail_images (20).png

xsmall_images (20).png

images (20).png

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

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

推理是大多数 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

上周在 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中，使用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/)

通过开源工具 claudo + DigitalOcean Gradient，使用 Claude Code 的价格与官方持平，同时支持支付宝付款、团队统一管理、两大 GPU 厂商认证的稳定网络连接

使用 DigitalOcean 实现 Claude Code “低配订阅 + 外部 Token”



目前，很多企业与个人开发者都已经用上了OpenClaw（小龙虾）。但是，不论你的OpenClaw是部署在本地电脑，还是部署在国内的云平台上，很多AI团队在实际使用时，都会遇到这些问题：

- **国内龙虾不支持Claude、OpenAI**：部署在国内云平台的OpenClaw，仅支持国内部分大模型，无法使用Claude、OpenAI、Gemini 等海外大模型
    
- **账号封禁风险**：使用Claude、OpenAI等模型时，经常因为地区、风控、支付方式导致账号被限制或封禁，业务无法持续运行
    
- **多平台、多Key管理混乱**：团队往往需要同时使用多个模型，不同平台的API Key、支付方式、调用方式都不同，运维复杂度极高
    
- **企业采购困难**：很多团队使用个人账号、个人信用卡、非正式渠道。这对于企业来说：不安全、不稳定、不适合长期业务
    

今天提供一个方法，无需你重新部署OpenClaw，只需要更改几行配置，即可稳定使用Claude、OpenAI等海外知名大模型，而且成本可控。

  

## 为什么你的OpenClaw很难稳定使用Claude？

对于中国团队来说，要在云端的OpenClaw上使用Claude、GPT等海外大模型主要面临两大痛点：

**1. 账号封禁风险**

首先，所有国内云平台都默认不支持Claude、OpenAI、Gemini这些海外模型。所以用户需要自己开账号购买这几个大模型，然后将API配置到云端的OpenClaw中。但是由于这些大模型存在地区限制，否则，你的Claude、OpenAI等账号就会被限制或封禁。这对需要持续运行的业务来说是致命打击——账号一旦被封，业务就会中断。

**2. 企业采购困难**

要想用Claude，你就就需要使用海外的信用卡或支付方式，否则账号也会被禁。但是绝大部分国内企业都很难解决这个问题。如果团队用个人账号和个人信用卡，这对企业来说也存在安全隐患，不利于长期发展。

另外，如果你是将OpenClaw部署在自己公司的机房服务器，接入多种大模型的话，不同模型的API Key需要分别管理，支付方式、调用接口都不同。团队需要维护多套系统，运维成本高。而且，由于你的服务器在国内，要使用Claude、OpenAI，你仍然要解决海外信用卡、网络连接等一系列问题。

### 一个更简单的思路：不要直连模型

很多团队的问题，本质在于：

> **直接对接模型厂商 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？

DigitalOcean 云平台的 Gradient Serverless Inference，是其 DigitalOcean Gradient AI 平台中的核心能力之一，本质上是一种：无需管理任何基础设施，即可直接调用主流大模型的统一推理服务。

你可以把它理解为：

> **“OpenAI / Claude API 的统一网关 + Serverless 托管层”**

通过它：

- 不需要直接对接 OpenAI 或 Anthropic
    
- 不需要自己处理账号与支付
    
- 不需要部署模型或 GPU
    

👉 只需要一个 API Key，就可以调用多个模型。

### 它解决了什么问题？

使用 Gradient Serverless Inference 后：

- 不再需要多个 API Key
    
- 不再需要海外信用卡
    
- 不再担心账号封禁
    
- 不再处理复杂网络问题
    

👉 本质上是把“模型接入问题”变成一个标准 API 调用问题。

### 已经使用腾讯云、阿里云，怎么配置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，只替换模型调用方式**

通过 DigitalOcean 的 Gradient Serverless Inference，将原本“直连 OpenAI / Claude”的方式，升级为通过统一推理网关调用模型。这样带来的变化是：

- 从“多平台、多 Key 管理” → **一个 Access Key 统一调用所有模型**
- 从“高风险账号体系” → **平台级稳定接入**
- 从“复杂部署与网络依赖” → **标准化 API 调用**
- 从“不可控成本” → **按量计费、可预测成本结构**
    

更重要的是，这种方式对现有系统几乎是零侵入的：

> **只需修改几行配置，无需重装、无需迁移、无需重构**

对于企业而言，这不仅是一次技术优化，更是一次**可持续 AI 架构的升级**：既保证了模型能力的灵活性，也确保了业务运行的稳定性与合规性。

如果你希望了解DigitalOcean Gradient Serverless Inference 的详情，可直接联系[卓普云（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 / GPT 的最简单方法



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推理能力解析

medium_images (13).png

small_images (13).png

thumbnail_images (13).png

xsmall_images (13).png

images (13).png

本文深入解析了Kimi K2.5的技术架构，并逐步讲解了如何在GPU服务器上部署。

如何在云端运行Kimi K2.5：从配置到部署全攻略

从2026年年初开始，AI行业内很多大佬都开始说“模型不再是唯一核心，Agent才是未来”。现在已经有不少不同行业的公司开始将AI Agent作为未来的产品方向，有的是开发Agent，有的是将Agent集成到自己的业务中。但很多团队并未看到产品化之后要面对的问题。

如果一家团队只是通过 OpenAI、DeepSeek、MiniMax、Alibaba（Qwen）的 API 做简单 prompt 调用，生成一次性回答，没有复杂 workflow、没有系统级治理需求，那么确实没有必要迁移。API 足够轻量、足够高效，而且在 2026 年已经具备文件检索、Tool Calling、JSON Schema 等能力。

但问题在于，大多数 AI 产品都会经历一个阶段跃迁——从“能用”到“可运营”。

一旦 AI 不再只是一个功能，而是产品核心能力，系统复杂度就会迅速上升。这时，模型调用不再是问题的核心，工程化能力才是。

  

产品引入 AI 能力，可以通过2个方式：

- 租用 GPU 服务器来进行推理。
- 直接调用大模型平台的API，进行推理。

现在，DigitalOcean的Gradient AI 提供了第三种选择，这是一种 Severless 推理服务。支持企业通过一套API接入多种模型并实现调度。同时支持知识库、多Agent路由、日志、评估等生产级功能。

本文将会对比这3种方案。

  

## 三种 AI 部署方案的对比
### DigitalOcean Gradient AI 的五个核心能力

#### 1. 内建 Knowledge Base：系统级 RAG 管理

到2026年，主流大模型API已普遍支持文件检索与检索增强生成（RAG）功能。然而，当企业级应用提出更高要求时——如管理Embedding生命周期、精细化控制文本分块策略、细粒度访问权限管理、统一日志追踪以及版本评估与回归测试——这些能力往往需要团队投入大量额外工程资源自行实现。

DigitalOcean Gradient平台通过提供托管的[Knowledge Base服务](https://docs.digitalocean.com/products/gradient-ai-platform/how-to/create-manage-agent-knowledge-bases/)，将RAG从单纯的功能实现提升至“可管理、可追踪、可评估”的企业级能力，显著降低了复杂RAG应用的落地门槛。

#### 2. Multi-Agent Routing：复杂任务的系统编排

多智能体路由（Multi-Agent Routing）是实现复杂任务系统化编排的关键。相较于简单的API调用链路（用户→模型→答案），复杂应用通常涉及更精细的流程：路由层根据意图分发请求至多个专业智能体，这些智能体可能调用外部工具，最终汇总结果返回给用户。当应用场景包含多步骤决策、多工具协同调用、合规性审查以及多角色分工时，问题的本质已从提示词工程跃升为系统架构设计。

DigitalOcean Gradient平台通过提供托管式的[智能体编排能力](https://docs.digitalocean.com/products/gradient-ai-platform/how-to/route-agents/)，使开发者能够专注于业务逻辑，而无需从零构建底层的协调（orchestration）层。

#### 3. Guardrails：跨模型的结构化控制

主流模型API虽然提供基础的内容过滤，但当企业需要：

- 跨模型统一敏感信息脱敏规则（如信用卡、身份证号）
- 统一内容安全审核策略（如过滤暴力、仇恨言论）
- 防止提示词注入等越狱攻击
- 对输入输出进行实时规则校验


就需要一个独立于模型之上的安全控制层。DigitalOcean Gradient通过托管的[Guardrails服务](https://docs.digitalocean.com/products/gradient-ai-platform/how-to/manage-agent-guardrails/)，为所有智能体提供了一致的、可配置的安全护栏，确保不同模型驱动的应用都能遵循统一的安全与隐私标准。

#### 4. Trace & Log：生产级可观测性

主流模型API虽提供基础日志，但当系统涉及多模型协作、多智能体路由和多步骤工具调用时，需要一个统一的可观测性层。DigitalOcean Gradient通过[追踪（Traces）、指标（Metrics）和洞察（Insights）](https://docs.digitalocean.com/products/gradient-ai-platform/how-to/view-agent-observability/)提供了这一能力：

- 查看完整决策路径：通过分步时间线，清晰还原每一次提示的处理流程和资源调用。
- 追踪工具与知识库调用：运行时日志详细记录函数、知识库等资源的访问情况。
- 分析Token与性能指标：实时监控Token用量、延迟和吞吐量，为成本优化和性能调优提供数据支撑。
- 支持SLA管理：通过端到端延迟、首token时间等关键指标，确保服务质量。 Gradient让AI应用从一个黑盒调用，转变为一个可观测、可调试、可优化的透明系统。

#### 5. Evaluation：系统级模型治理与数据驱动优化

在多模型、多智能体的生产环境中，关键问题不再是“哪个模型更好”，而是：

- GPT-4 与 Claude 在处理特定任务时，客观指标上谁更优？
- 如何用量化数据来平衡模型的高准确率与运行成本？
- 模型升级或提示词调整后，如何准确判断效果是提升还是退化？ DigitalOcean Gradient 提供统一的[智能体评估（Agent Evaluations）框架](https://docs.digitalocean.com/products/gradient-ai-platform/how-to/evaluate-agents/)，让你可以通过自定义测试用例和数据集，对单个或所有智能体进行自动化测试。评估结果提供从平均指标分数到单次调用细节的全面洞察，让模型选型、成本控制和版本迭代成为清晰的数据驱动决策，而非主观判断。

  

## 成本结构的真实对比

很多人只对比 token 单价，这是不完整的。真正应该比较的是 TCO（Total Cost of Ownership）：

- 模型成本
- 向量数据库
- 应用服务器
- 日志系统
- 运维成本
- 多模型管理成本

当调用量与复杂度上升后，平台层成本往往高于模型成本。但是当你使用 DigitalOcean Gradient AI 的时候，你的模型成本没有变化，但是其它的基础设施能力都实现托管，其成本远低于你自行部署、运维的成本。


## 写在最后

如果 AI 只是一个功能，简单调用 API 完全合理。

但如果 AI 是未来的核心产品能力，那么你们需要的就不仅是模型能力，而是系统工程能力。

DigitalOcean Gradient 的本质，是在模型之上提供系统抽象层。

当 AI 只是一个按钮，它是功能。

当 AI 具备统一模型管理、知识库体系、可观测性与评估能力，它才会成为真正的系统资产。

真正的门槛，从来不在模型本身，而在系统工程。

如果你希望进一步了解 DigitalOcean Gradient AI 平台，欢迎访问[卓普云AI Droplet官网（aidroplet.com）](https://www.aidroplet.com/)，直接与卓普云的技术团队沟通交流。

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

仅调用大模型API不足以构建企业级AI系统，还需要知识库管理、Agent编排、可观测性等系统工程能力，DigitalOcean Gradient AI提供了一站式托管解决方案。

构建企业级 AI 系统，只调用 DeepSeek、MiniMax、Kimi 之类的 API 够吗？

DigitalOcean Gradient™ AI 平台现已原生集成 LlamaIndex——这是构建 RAG（检索增强生成）应用最流行的框架之一。

这意味着你现在可以直接将 Gradient AI 平台的知识库和 LLM（大语言模型）连接到 LlamaIndex 工作流中，使用你已经熟悉的抽象接口。无需额外的基础设施，无需复杂的设置。只需安装两个包，即可开始构建。

## 为什么这很重要

如果你之前构建过 RAG 应用，你一定熟悉这样的流程：配置向量数据库、设置嵌入管道、跨服务管理凭证，然后将所有东西拼接在一起。在你编写一行应用程序逻辑代码之前，就已经有大量的前期工作了。

借助DigitalOcean新集成的LlamaIndex，我们已经为你完成了这些繁重的工作。你的知识库负责处理文档的导入、分块和嵌入生成。LlamaIndex 检索器直接连接到它。再加上我们平台上集成的 LLM （Gemini、Claude、OpenAI），你就拥有了一个在托管的 DigitalOcean 基础设施上运行的完整 RAG 管道。

## 新增功能

现在 PyPI 上提供了两个包：

*   [llama-index-retrievers-digitalocean-gradientai](https://pypi.org/project/llama-index-retrievers-digitalocean-gradientai/)：将你的知识库作为 LlamaIndex 检索器连接。支持混合搜索（关键词 + 语义）、元数据过滤和异步操作。
*   [llama-index-llms-digitalocean-gradientai](https://pypi.org/project/llama-index-llms-digitalocean-gradientai/)：在你的 LlamaIndex 工作流中使用 Gradient AI 平台托管的 LLM。支持流式响应和适用于高吞吐量应用的异步操作。

这两个包都能与 LlamaIndex 的查询引擎、聊天引擎、回调函数以及更广泛的生态系统协同工作。

## 几分钟内即可使用

安装这些包：

```bash
pip install llama-index-retrievers-digitalocean-gradientai llama-index-llms-digitalocean-gradientai
```

然后，配置你的 Gradient AI 平台凭证，并将检索器和 LLM 集成到你现有的 LlamaIndex 代码中。查看我们的[文档](https://docs.digitalocean.com/products/gradient/)以获取完整的操作指南和代码示例。

### 你可以构建什么

这些集成为你开启了一系列可能性：

*   基于你的产品文档构建的**技术支持助手**
*   用于查询公司维基和操作手册的**内部工具**
*   能理解私有代码库上下文的**代码助手**
*   用于基于文档的问答的**研究工具**

如果你已经在使用 LlamaIndex，你现在可以将 Gradient AI 平台集成到你现有的应用程序中。如果你是从零开始，你现在拥有了一条从知识库到生产级 RAG 应用的完全托管路径。

## 接下来

这仅仅是个开始。我们将继续扩展 Gradient AI 平台与主流 AI 框架的集成，我们很期待听到你正在构建的应用。

立即开始使用 LlamaIndex——或咨询[DigitalOcean中国区战略合作伙伴卓普云AI Droplet](https://www.aidroplet.com/)，或者探索 [Gradient AI 平台文档](https://docs.digitalocean.com/products/gradient/)，以了解有关[GPU服务器](https://www.aidroplet.com/product/gpu/)、知识库和托管 LLM 的更多信息。

祝你编程愉快！

DigitalOcean Gradient AI平台原生集成LlamaIndex，通过两个PyPI包简化RAG应用开发，让开发者快速构建生产级AI应用。

DigitalOcean Gradient AI 推理云平台原生集成 LlamaIndex

过去几年间，以大型语言模型（LLM）和生成式 AI 为代表的新浪潮席卷全球，对算力基础设施提出了前所未有的严苛挑战。从 GPT-4 到 Llama 3.1，参数量级的飞跃不仅意味着计算复杂度的几何级数增长，更直接推动了对高性能 GPU 的需求井喷。然而，对于大多数创新型企业而言，自建集群面临的高昂成本与运维压力，使得像 **DigitalOcean** 这类按需付费、灵活扩展的 GPU 云服务成为了解决算力瓶颈的关键。

目前，DigitalOcean 提供了覆盖 NVIDIA 与 AMD 阵营的顶级 AI 训练与推理 GPU。本文将聚焦于目前 NVIDIA 与 AMD 的五款旗舰级“性能怪兽”——**[NVIDIA H100](https://www.aidroplet.com/product/h100/)、[H200](https://www.aidroplet.com/product/h200/)** 以及 **AMD MI300X、MI325X、MI350X**，深入对比它们的硬件规格、真实单价与适用场景。

> **注：** 文章数据参考 2026 年初 DigitalOcean 官网及合作伙伴信息。最终价格与优惠请咨询 [DigitalOcean 中国区独家战略合作伙伴卓普云 aidroplet.com](https://www.aidroplet.com/)。

## 旗舰 GPU 核心架构与优势概览

### 1. NVIDIA H100 / H200：不可撼动的生态霸主

**H100 (Hopper)**：作为 AI 时代的标杆，其核心优势在于 **Transformer Engine**。利用 FP8 精度，它能极大提升大模型训练速度，且拥有全球最成熟的 CUDA 生态支持。

**H200 (Hopper Upgrade)**：H100 的显存强化版。搭载 **141GB HBM3e**，带宽提升至 4.8 TB/s。它解决了 H100 在处理超长文本（Context Window）时的显存瓶颈，是追求极致推理吞吐量的首选。

### 2. AMD Instinct MI300X / MI325X：性价比与显存的颠覆者

**MI300X (CDNA 3)**：凭借 **192GB** 庞大显存，MI300X 实现了单卡运行更大参数模型的能力。在推理成本上，它对 NVIDIA 形成了强力冲击。

**MI325X (CDNA 3 Refresh)**：将显存推升至 **256GB HBM3e**，带宽高达 6.0 TB/s。它旨在打破显存上限，让超大规模模型的单机推理和微调变得更加轻松。


### 3. AMD Instinct MI350X：下一代性能天花板

**MI350X (CDNA 4)**：这是 AMD 的最新王牌。其 **288GB HBM3e** 显存和高达 8.0 TB/s 的带宽，配合 FP4/FP6 精度支持，使其在 AI 算力指标上实现了对当前 Hopper 架构的全面超越。

在2025年6月12日于圣何塞举行的"AMD Advancing AI 2025"大会上，苏姿丰也曾表示，MI350X系列是他们交付的Instinct产品历史上最大的一次代际性能飞跃。


## 核心参数横向对比表

为了直观展示性能差异，我们汇总了 DigitalOcean 平台 GPU Droplet 云服务器的配置数据：

| **GPU 型号**      | **架构** | **显存容量**   | **显存带宽**     | **FP8 算力 (稀疏)** | **内存**  | **vCPU** |
| --------------- | ------ | ---------- | ------------ | --------------- | ------- | -------- |
| **AMD MI350X**  | CDNA 4 | 288 GB | 8.0 TB/s | 9.2 PFLOPS  | 256 GiB | 24       |
| **AMD MI325X**  | CDNA 3 | 256 GB     | 6.0 TB/s     | 5.2 PFLOPS      | 164 GiB | 20       |
| **AMD MI300X**  | CDNA 3 | 192 GB     | 5.3 TB/s     | 5.2 PFLOPS      | 240 GiB | 20       |
| **NVIDIA H200** | Hopper | 141 GB     | 4.8 TB/s     | 3.96 PFLOPS     | 240 GiB | 24       |
| **NVIDIA H100** | Hopper | 80 GB      | 3.35 TB/s    | 3.96 PFLOPS     | 240 GiB | 20       |
## 价格与性价比分析

根据 DigitalOcean 云平台的最新报价（部分为 12 个月合约价），我们可以清晰地看到不同型号的成本梯度：

### 1. NVIDIA 阵营

- **H100 (8x 集群)**：合约价约 **$2.50/GPU/hour**。虽然价格较高，但 CUDA 生态的零门槛迁移成本使其在生产环境中极具吸引力。
- **H200 (单卡)**：按需价格约为 **$3.44/hour**。作为目前 NVIDIA 最强的现货推理卡，其溢价主要源于极高的显存带宽收益。

### 2. AMD 阵营

- **MI300X (8x 集群)**：合约价低至 **$1.49/GPU/hour**。其显存单价（每 GB 成本）仅为 H100 的 1/4 左右，是**长周期推理任务**的性价比之王。
- **MI325X (8x 集群)**：合约价为 **$1.69/GPU/hour**。相比 MI300X 略有提升，但显存容量增加了 33%，非常适合显存密集型科研任务。
- **MI350X (8x 集群)**：合约价为 **$3.18/GPU/hour**。虽然单价接近 H200，但考虑到其算力几乎是后者的两倍，对于**高性能预训练**任务而言，其“算力单价”反而更具优势。



## 如何精准选型？

在 DigitalOcean 平台上，选择 GPU 并非“越贵越好”，而应基于模型特性：

- **场景一：极致算力优先（Pre-training）**

**推荐：MI350X (8x) 或 H200 (8x)**。

如果您正在进行 175B 以上参数模型的预训练，MI350X 的高吞吐量将大幅缩减训练周期。若追求极致的软件兼容性或已有CUDA代码库，H200更适合；若愿意使用ROCm 6.4+，MI350X提供更高性价比

- **场景二：超大显存需求（Large Context Inference）**

**推荐：MI325X 或 MI350X**。    

处理百万级 Token 的长文本推理时，256GB/288GB 的显存能容纳更大的 KV Cache，避免频繁的任务切分。不过MI350X的计算性能更强，如果有需求可首选MI350X；如果预算有限，可以选择MI325X。

- **场景三：预算敏感型微调（Cost-effective Fine-tuning）**

**推荐：MI300X (8x)**。

以不到 $1.5/小时的单价获得 192GB 显存，适合中小企业进行 Llama 3 等开源模型的全量参数微调。

- **场景四：成熟生态与快速部署（Production Ready）**

**推荐：H100**。

如果您希望代码“开箱即用”，无需在 ROCm 环境下进行算子调优，H100 仍然是风险最低的选择。


## 您的 AI 算力伙伴

无论您是追求 NVIDIA 成熟的生态体系，还是青睐 AMD 极致的显存性价比，DigitalOcean 都能为您提供最匹配的 GPU 资源。

**现在就开启您的 AI 之旅：** 如果您在 GPU 选型或资源锁定上遇到难题，欢迎联系 [DigitalOcean 中国区战略合作伙伴——卓普云（aidroplet.com）](https://www.aidroplet.com/)。我们的专家团队将为您提供针对性的技术架构建议与最优的商务方案。

large_images (12).png

medium_images (12).png

small_images (12).png

thumbnail_images (12).png

xsmall_images (12).png

images (12).png

五大旗舰 GPU 终极对决：NVIDIA H100/H200 与 AMD MI300X/MI325X/MI350X，谁才是你的性价比之王？

GPU对比：MI350X、MI325X、MI300X、H200、H100

随着大语言模型能力的持续跃升和应用场景的指数级扩展，2026年的企业AI落地已经进入了全新的阶段。希望保持竞争力的企业正急于将人工智能能力融入其产品和服务。在[DigitalOcean](https://www.aidroplet.com/)针对成长型科技公司的调研报告中显示，25%的受访者正在用人工智能强化现有产品，而22%的受访者正在用人工智能开发新产品。无论是通过添加智能产品推荐来改善客户体验，实施自然语言处理来简化支持工作流程，还是纳入预测分析来指导业务决策，AI的集成都能带来实实在在的优势。
## 传统的模型部署方式

传统的方式是，企业通过**基于服务器的推理**来部署机器学习模型：
- 自行配置专用服务器或虚拟机
- 安装必要的框架
- 管理整个基础设施的生命周期

企业托管这些模型，并全权负责这些模型端点的可用性、可靠性和扩展。这种自我管理的方法主要适用于开源模型，尽管部署来自OpenAI或Anthropic等供应商的专有模型有其自身的复杂性，并且通常需要直接集成它们的API。

这种方式让组织拥有完全的控制权，但需要大量的开发运维专业知识来处理容量规划、扩展、安全补丁和监控——同时还要管理即使在需求低迷时期也要保持服务器运行的成本。
## 无服务器推理：一种强大的替代方案

**无服务器推理**（Serverless Inference）是一个引人注目的替代方案，它允许开发者通过简单的API调用强大的模型，而无需管理任何底层基础设施，并能根据需求自动扩展，同时仅按实际使用量收费。
### 核心观点
- **零基础设施管理**：开发者可以部署和运行AI/ML模型，而无需管理任何服务器基础设施。
- **按使用量付费**：仅在模型处理请求时产生费用，消除闲置服务器成本。
- **专注核心开发**：团队可以快速将AI模型集成到应用中，专注于模型开发和集成。
## 什么是无服务器推理（Serverless Inference）？

无服务器推理（Serverless Inference）是一种使用机器学习模型的方法，它消除了配置或管理任何底层基础设施的需要，同时仍使应用程序能够访问AI能力。

**无服务器推理的工作原理**：您只需向一项托管服务发起API调用，该服务会在后台处理所有复杂的资源分配、扩展和可用性问题。您只需为推理期间使用的令牌付费——无需闲置服务器，无需容量规划的困扰，也无需基础设施维护的开销。
### 应用示例

- **客服聊天机器人**：开发者通过简单API调用集成OpenAI的GPT模型，基于对话历史和支持文档生成回复。
- **电商搜索升级**：电商网站通过实施Anthropic的Claude 3.7 Sonnet来理解自然语言查询。

**提供该服务的云平台有**：AWS Bedrock、Google Cloud的Vertex AI、Azure AI Foundry 和 DigitalOcean Gradient AI Platform 等都提供无服务器推理（Serverless Inference）选项。
## 基于服务器的推理 vs 无服务器推理
### 基于服务器的推理

- **优势**：对模型选择、优化技术和硬件配置拥有精细的控制权
- **适用场景**：
  - 具有独特依赖关系的专业模型
  - 需要可预测成本的 guaranteed 性能
  - 计算密集型应用（实时音频生成、自动语音识别、高分辨率图像创建）
  - 有特定合规要求或持续高负载工作量的团队
### 无服务器推理
- **优势**：处理可变或不可预测的流量模式，消除闲置容量成本
- **适用场景**：
  - 流量模式不可预测的应用
  - 初创企业、快速原型开发阶段
  - 没有专门MLOps团队的组织
  - 希望将工程资源分配给构建AI应用而非基础设施管理的企业
## 无服务器推理的优势

1. **零基础设施管理**：工程团队摆脱服务器配置、集群大小调整等负担，无需处理安全补丁、框架更新和驱动兼容性问题。
2. **真正的按使用量付费定价**：只为模型执行期间实际使用的计算时间付费，空闲期间无费用产生。
3. **自动扩展**：平台自动处理资源编排，流量高峰时自动扩展资源，低谷时自动缩减，无需人工干预。
4. **简化的模型维护**：通过统一接口和认证系统访问不同提供商的模型，消除多供应商管理的复杂性。
5. **缩短上市时间**：省去大部分基础设施规划和部署阶段，几天内即可将AI能力集成到现有应用中。
## 无服务器推理的最佳实践
### 优化模型和资源以提高推理效率
- 选择适当优化的模型和运行时
- 对于简单任务，选择较小、较不复杂的模型
- 确保部署拥有足够的计算能力
### 最小化冷启动以实现低延迟性能
- 配置最小实例数或并发度，确保至少有一个工作单元保持"温暖"
- 考虑通过定期发送"ping"请求实施预热策略
- 对时间关键的应用使用较小或量化后的模型
### 使用自动扩展和吞吐量规划
- 设置适当的扩展参数（上限和非零最小值）
- 检查提供商的配额（每分钟请求数或令牌数）
- 考虑使用预留容量选项
### 监控推理性能和日志
- 跟踪关键指标：请求吞吐量、延迟、错误率
- 监控模型调用次数和令牌消耗
- 启用详细调用日志记录用于审计和调试
## DigitalOcean Gradient AI Platform：AI代理 vs 无服务器推理
DigitalOcean Gradient Platform提供两种强大的AI集成方法，都运行在相同基础设施（DigitalOcean 云平台）上，拥有统一计费方式。
### AI代理

智能的、具有上下文感知能力的助手，能维护对话历史，遵循特定指令，并能访问知识库。

**适用场景**：
- 客户支持自动化
- 虚拟产品顾问
- 互动学习工具
- 业务流程自动化
### 无服务器推理

通过简单API提供对强大AI模型的直接、低级别访问，无状态、灵活，允许与应用程序逻辑紧密集成。

**适用场景**：
- 内容增强工作流程
- 实时数据处理
- 自定义应用程序集成
- 快速原型设计和实验

与AWS、Google Cloud或Azure相比，不同平台在目标客户群体和复杂度上存在明显差异。

例如，AWS Bedrock和Google Vertex AI通常更适合已经深度使用其云生态的大型企业。这些平台功能全面，但配置体系、权限管理结构以及计费模型相对复杂，更适合拥有成熟云架构团队且预算充足的企业。

相比之下，DigitalOcean 的无服务器推理更强调**简洁性和可控成本**。它面向成长型科技公司与开发者团队设计，提供更直接的API接入方式、更透明的定价结构，以及与云主机、托管数据库、Kubernetes 等产品的一体化体验。

对于没有庞大云架构团队的公司而言，这种“减少平台复杂度”的设计本身就是一种效率优势。开发者可以在同一控制台内完成模型调用、应用部署和数据存储的管理，而无需在多个产品线之间切换或配置复杂的IAM策略。

这种差异，并不只是功能层面的区别，而是平台定位与服务对象的不同。
## 常见问题解答
### 无服务器推理和传统基于服务器的部署有什么区别？
基于服务器的部署需要您配置和管理基础设施，提供更多控制权但增加了运营开销。无服务器推理（Serverless Inference）完全消除了基础设施管理，具有自动扩展和按使用量付费的定价模式。
### 哪些云平台提供无服务器推理选项？
AWS SageMaker、Google Cloud Vertex AI、Microsoft Azure ML、DigitalOcean Gradient Platform，以及Modal、DataCrunch和Vultr等专业平台。
### 如何处理无服务器推理中的冷启动？
- 通过定期发送"ping"请求实施预热策略
- 对延迟不太敏感的工作负载采用异步优先的设计
- 对时间关键的应用使用较小或量化后的模型
## 结论
无服务器推理（Serverless Inference）通过消除传统障碍，简化了企业处理AI实施的方式。无论您是初创企业还是成熟企业，都可以利用这一技术快速将AI能力集成到应用中，无需管理底层基础设施，只需为实际使用付费。
如需要了解更多关于DigitalOcean 无服务器推理、GPU 服务器或其他AI相关产品服务，可直接咨询DigitalOcean中国区战略合作伙伴[卓普云AI Droplet](https://www.aidroplet.com/)。

相关阅读：
[面向 AI 推理的算力升级：AMD MI350X GPU Droplets云服务器上线](https://blog.aidroplet.com/product-updates/now-available-amd-instinct-mi350x-gpus/)
[NVIDIA HGX™ B300 GPU Droplet 服务器，即将上线DigitalOcean 云平台！](https://blog.aidroplet.com/product-updates/digitalocean-nvidia-b300-gpu-droplets/)
[Moltbot/Clawdbot是什么？如何在云服务器部署 Moltbot/Clawdbot？](https://blog.aidroplet.com/tutorials/Clawdbot-quickstart-guide/)
[NVIDIA H200 GPU 比 H100 强在哪？](https://blog.aidroplet.com/tutorials/h200-vs-h100/)



large_maxresdefault2.jpeg

medium_maxresdefault2.jpeg

small_maxresdefault2.jpeg

thumbnail_maxresdefault2.jpeg

xsmall_maxresdefault2.jpeg

maxresdefault2.jpeg

无服务器推理通过API调用AI模型，免管理、按需付费、自动扩展，加速AI应用落地。


无服务器推理（Serverless Inference）是什么？与传统AI推理部署方式全面对比

随着 DigitalOcean 的 Agentic Inference Cloud 持续扩展，现在推出全新的搭载了 AMD Instinct™ MI350X GPU 的高性能 GPU Droplets云服务器。通过将这一旗舰款 GPU 集成到 DigitalOcean 的云平台中，DigitalOceean 将继续为领先的 AI 企业和开发者提供可规模化运行复杂推理工作负载的算力资源与服务。
## 使用 AMD Instinct™ MI350X 优化生产级推理

AMD Instinct™ MI350X 系列为生成式 AI 和高性能计算（HPC）树立了新的标杆。该系列基于 AMD CDNA™ 4 架构打造，专为最严苛的任务而设计，包括大规模模型训练、高速推理以及复杂的科学仿真。

这款 GPU 专门针对计算密集型的 prefill 阶段进行了优化，同时在低延迟条件下保持较高的 token 生成吞吐量。它不仅可以承载更大的模型和更长的上下文窗口，还能在单张 GPU 上处理更多并发的推理请求。配合 DigitalOcean 优化过的推理平台，整体性能进一步提升，实现更低延迟和更高吞吐。
## 为 AI 创新者带来的验证成果

我们已经看到，当客户将 DigitalOcean 优化的平台与 AMD 硬件结合时，可以释放出怎样的潜力。今年早些时候，我们帮助 [Character.AI ](https://blog.aidroplet.com/news/DigitalOcean-AMD-GPUs-Delivers-2X-Performance-for-Character/)将生产环境中的请求吞吐量提升了 2 倍，同时将推理成本降低了 50%。

如今，像 ACE Studio 这样的客户正使用 DigitalOcean 软件与 AMD 硬件的组合，推动音乐创作的边界。“在 ACE Studio，我们的使命是打造面向未来音乐创作的 AI 驱动音乐工作站，”联合创始人兼 CTO Sean Zhao 表示。“随着我们在 DigitalOcean 上持续扩展部署，下一代 AMD Instinct™ MI350X 架构，以及 AMD 与 DigitalOcean 在推理优化方面的紧密合作，为我们进一步提升客户侧的性能与成本效率奠定了坚实基础。”
## 企业级性能，成本可控，运维简单

除了提供最新的 AMD GPU，我们也始终坚持透明与简洁的原则，确保这项强大的技术能够被开发者和成长型企业轻松采用：

**可预测且高性价比的定价**：我们提供透明的按使用量计费模式，支持灵活合约，无隐藏费用。

**简单部署**：GPU Droplets 可在数次点击内完成创建与配置，涵盖安全、存储和网络需求，相比复杂的云环境大幅简化部署流程。

**企业级特性支持**：GPU Droplets 提供企业级 SLA、可观测性功能，并支持 HIPAA 合规和 SOC 2 认证。

## 未来计划

全新的搭载了AMD Instinct™ MI350X 的 GPU Droplets 云服务器目前已在亚特兰大（ATL1）数据中心上线。下个季度，我们还将部署 AMD Instinct™ MI355X GPU，并引入液冷机架，以支持更大规模的数据集和模型。

准备好扩展你的 AI 生产环境了吗？欢迎联系DigitalOcean中国区战略合作伙伴[卓普云AI Droplet团队](https://www.aidroplet.com/)，了解更多关于 AMD Instinct™ MI350X 在 DigitalOcean 上的能力，并立即开始在 Agentic Inference Cloud 上构建你的应用。

搭载 AMD MI350X 的 GPU Droplets上线，提升 AI 推理性能与吞吐，兼顾低延迟与成本可控。

面向 AI 推理的算力升级：AMD MI350X GPU Droplets云服务器上线

large_images-28-2.png

medium_images-28-2.png

small_images-28-2.png

thumbnail_images-28-2.png

xsmall_images-28-2.png

images-28-2.png

这篇文章系统解析了 AI / ML 训练中的存储瓶颈问题，对比网络文件存储与块、对象存储的差异，并深入评估 DigitalOcean、AWS、GCP、Azure 等主流云厂商的 NFS 方案，帮助团队为 GPU 训练选择高性能、可预测成本的存储架构。

AI 训练用网络文件存储（NFS）怎么选？DigitalOcean NFS vs. AWS EFS vs. 谷歌云GCP vs. 微软云Azure

每次大型语言模型的主要发布似乎都在不断突破极限，带来越来越强大的功能，引发了关于未来的严肃思考。随着 [Claude Opus 4.6](https://www.anthropic.com/news/claude-opus-4-6) 的正式发布，那种迫在眉睫的感觉只会更加强烈。

现在，Claude Opus 4.6 已在 Anthropic Claude 和 [DigitalOcean Gradient AI 平台](https://blog.aidroplet.com/product-updates/claude-opus-4-6-gradient-ai-platform/) 上提供，在 DigitalOcean 上，用户无需部署、管理基础设施，通过 API 即可调用 Claude Opus 4.6。Claude Opus 4.6 在编码性能上相比其前代产品有显著提升。它展现出更强的规划能力、更持久的自主行为、在大型代码库中更高的可靠性，以及更敏锐的代码审查和调试能力，能帮助其识别并纠正自身错误。此外，Opus 系列首次在 4.6 版本中引入了 100 万令牌的上下文窗口。

本文中，我们将探讨是什么让 Claude Opus 4.6 如此备受瞩目，简单扼要地聊一聊使其区别于前代产品的特性，最后通过一个演示Demo，展示如何使用该模型配合 Claude Code 来改进我们自己的一个项目——实时语音翻译器。请跟随我们，全面了解这个已被证明是当前最有趣的新模型之一！

## 关键要点

*   自主编码达到新高度：Claude Opus 4.6 提供了更强的规划能力、更持久的自主行为和改进的自我审查能力，使其在处理大型、复杂的代码库时尤其有效。
*   长上下文解锁新工作流：100 万令牌上下文窗口的引入使开发者能够对整个项目、文档集和扩展任务进行推理，而无需担心上下文丢失。
*   通过 DigitalOcean 实现生产就绪：通过 Claude Code 或 DigitalOcean Gradient AI 平台的无服务器推理访问 Opus 4.6，使团队能够快速将其能力集成到实际应用中，在保持可靠性和控制的同时，显著缩短开发时间。

## Claude Opus 4.6：新特性与改进

![Screenshot 2026-02-06 at 11.19.21 AM.png](https://blog.aidroplet.com/uploads/Screenshot_2026_02_06_at_11_19_21_AM_3f45f5825f.png)

Claude Opus 4.6 是 Claude Opus 系列大型语言模型的一次真正飞跃。据报道，该模型在通用知识、编码能力、自主能力和跨学科推理方面都显示出显著的改进。让我们概述一些新特性：

*   扩展的长上下文能力：Opus 4.6 首次在 Opus 级别模型中提供了 100 万令牌的上下文窗口（测试版），使模型能够在更大的代码库、文档和扩展任务上进行推理并保持连贯性。
*   改进的性能和可靠性：在其前代基础上，Opus 4.6 提供了更强的编码性能、在复杂任务上更持久的自主行为，以及在扩展工作流中更好的代码审查、调试和规划能力。
*   新的自主和工作流特性：此次更新引入了对代理团队（并行任务处理）的支持、针对长期运行自主工作流的增强上下文压缩，以及用于微调性能和成本的自适应思考和努力控制。

这些改进共同作用，使这个本已出色的模型更上一层楼，让 Opus 成为这一代 LLM 中的佼佼者。现在，让我们更深入地了解如何使用 Opus。

## 使用 Claude Opus 4.6 和 Claude Code 改进项目

开始使用 Claude Opus 4.6 和 Claude Code 非常简单！你只需要一个 Anthropic Claude Pro 账户，默认情况下会自动获得访问权限。只需按照他们的 [入门指南](https://code.claude.com/docs/en/overview) 页面上的说明，并使用 Claude Code 提供的指南验证你的设备即可开始。

![Screenshot 2026-02-06 at 11.47.13 AM.png](https://blog.aidroplet.com/uploads/Screenshot_2026_02_06_at_11_47_13_AM_34d177d84e.png)

在机器上激活了 Claude Code 之后，导航到你想要工作的目录。在这个例子中，我们使用了为这篇 [教程](https://www.digitalocean.com/community/tutorials/real-time-speech-translation-pipeline) 发布的 [实时语音翻译器](https://github.com/Jameshskelton/realtime_speech_translation)。在该目录的终端中输入 `claude` 即可开始。

![Screenshot 2026-02-06 at 11.43.12 AM.png](https://blog.aidroplet.com/uploads/Screenshot_2026_02_06_at_11_43_12_AM_d210df7910.png)

在这个例子中，我们要求 Claude Opus 4.6 清理应用程序并更新其视觉主题，以更好地与 DigitalOcean 的品牌保持一致。我们首先让模型提出一系列改进建议，然后逐步应用这些更改，而不是一次性全部应用。它的建议包括添加更清晰的描述和居中网页应用布局。我们发现这种迭代方法比同时请求多个更改更有效，因为它有助于减少幻觉。

![Screenshot 2026-02-06 at 10.57.59 AM.png](https://blog.aidroplet.com/uploads/Screenshot_2026_02_06_at_10_57_59_AM_baba4264e8.png)

上图是网页应用最初的外观，下图是应用了请求更新后的结果。

![Screenshot 2026-02-06 at 11.08.29 AM.png](https://blog.aidroplet.com/uploads/Screenshot_2026_02_06_at_11_08_29_AM_de1e591bb4.png)

正如我们所见，这对用户界面来说是一个显著的改进，并且这些更改反映了我们的要求。虽然更改了数百行代码，但我们只需要向模型输入三次指令就完成了这些更改。这大大缩短了我们自己完成相同任务所需的时间。

## 通过 DigitalOcean 使用 Claude Opus 4.6

另一种访问 Claude Opus 4.6 的方式是通过 DigitalOcean Gradient AI 平台的无服务器推理功能！无服务器推理允许你仅用几行代码就能将 AI 直接插入你正在使用的任何功能中。立即点击 [此处](https://cloud.digitalocean.com/registrations/new?activation_redirect=%2Fgen-ai%2Fmodel-access-keys%3Fcreate%3Dtrue\&redirect_url=%2Fgen-ai%2Fmodel-access-keys%3Fcreate%3Dtrue) 创建模型访问密钥。

通过 DigitalOcean 启动，你可以将 DigitalOcean 生态系统的所有功能与 Claude Opus 4.6 的强大能力直接结合。我们可以利用这一点，通过创建自定义知识库或连接外部数据来增强我们的代理，使其具备真实世界的上下文。此外，内置的连接器使得从 AWS S3、Dropbox 等地方摄取文件变得容易，无需复杂配置。

## 总结

Claude Opus 4.6 代表了自主 AI 的一个重要转折点，特别是对于构建复杂、真实世界系统的开发者而言。凭借其扩展的上下文窗口、更强的长视野推理能力以及在大型代码库中显著提高的可靠性，Opus 4.6 给人的感觉不再像一个被动的助手，而更像一个真正的协作工程师。与 Claude Code 等工具和 DigitalOcean Gradient 等平台相结合，它极大地压缩了从想法到实现的时间：将需要数小时的重构、审查和 UI 改进工作转变为紧密引导的迭代工作流。随着像 Opus 4.6 这样的模型不断突破可能的边界，DigitalOcean 已做好准备，提供将这种原始能力转化为生产就绪影响力所需的基础设施和工具。

如果你需要使用 GPU 服务器、Kubernetes等服务构建自己的AI产品，欢迎咨询[卓普云](https://www.aidroplet.com/)，进一步了解Digitalocean 云平台提供的[计算（Droplet）](https://www.aidroplet.com/product/cloudcpu/)、[存储](https://www.aidroplet.com/product/spaces/)、网络和托管数据库产品。

相关阅读：

*   [Claude Opus 4.6 上线 DigitalOcean：百万上下文，一键调用](https://blog.aidroplet.com/product-updates/claude-opus-4-6-gradient-ai-platform/)
*   [Moltbot/Clawdbot是什么？如何在云服务器部署 Moltbot/Clawdbot？](https://blog.aidroplet.com/tutorials/Clawdbot-quickstart-guide/)
*   [实时对话 AI 虚拟人是怎么做出来的？语音合成 + 视频生成全流程拆解](https://blog.aidroplet.com/tutorials/character-ai-ltx2-agent/)


探讨是什么让 Claude Opus 4.6 如此备受瞩目，简单扼要地聊一聊使其区别于前代产品的特性，最后通过一个演示Demo，展示如何使用该模型配合 Claude Code 来改进我们自己的一个项目——实时语音翻译器。

Claude Opus 4.6 有什么新特性？如何与Claude Code结合开发？

2025年，DigitalOcean 云平台上线了 Serverless Inference。DigitalOcean Serverless Inference 是一种托管式的大模型推理服务。你不需要创建 GPU 实例、不用部署模型、不用关心扩缩容，只要通过 API 调用模型，DigitalOcean 就会在后台自动完成推理资源的调度与运行。

现在，Claude Opus 4.6 已经上线 DigitalOcean Serverless Inference，提供百万级上下文与 Agentic 能力，帮助团队在统一云环境中高效构建、部署并扩展 AI 推理应用。

## Claude Opus 4.6 上线 DigitalOcean：百万上下文的 Serverless 推理新选择

  

**Claude Opus 4.6 现已通过 Serverless Inference 服务上线 DigitalOcean Gradient™ AI Platform**，让团队可以在一个专为大规模稳定推理而打造的平台上，直接使用 Anthropic 最强大的模型。

  

你现在就可以通过 API，或在 DigitalOcean Cloud Console 中开始使用这一新模型。

  

凭借高达 **100 万 token 的超大上下文窗口**、**自适应推理能力**以及**先进的 Agentic 编码能力**，Claude Opus 4.6 可以帮助团队在一次推理中完成对海量数据的分析、整套代码库的重构，并生成高质量输出。同时，它也针对日常知识型工作进行了优化，包括报告、电子表格和演示文稿的生成。

  

## Opus 4.6 能解锁什么能力

  

**Agentic 编码与软件开发**

  

在大型代码库中进行规划、调试和迭代；执行根因分析；处理多语言编程和网络安全相关任务。

  

**知识型工作与研究**

  

分析金融数据、开展研究，并在文档、表格和演示文稿中完成多步骤任务管理。

  

**Agentic 自动化**

  

协调多个 AI Agent 并行执行读取密集型或长时间运行的任务；对超大上下文进行总结，并基于上下文做出自适应推理决策。

  

**信息检索与长上下文推理**

  

在庞大的数据集中检索难以定位的细节，并对数十万 token 的内容进行推理。

  

**办公效率提升**

  

生成结构化报告、电子表格和演示文稿；摄取非结构化数据，并一次性输出打磨完成的高质量结果。

  

## 在 DigitalOcean 上使用 Claude Opus 4.6有什么便捷之处？

  

Claude Opus 4.6 可直接运行在你现有的 DigitalOcean 环境中，与应用、数据、网络和存储并存，让推理成为你技术栈的一部分，而不是一个需要额外集成和运维的独立系统。

  

无需单独签署模型合同、创建厂商账号或管理多套计费体系。使用量会与其他 DigitalOcean 服务一起进行计费，计费规则简单透明、容易预估，推理服务默认托管，这意味着你无需配置或调优基础设施即可快速上手 Opus 4.6。

  

平台从一开始就内置了安全默认配置。Opus 4.6 在你的 DigitalOcean 项目（Project）内运行，采用安全的默认设置，随着工作负载规模扩大，可有效降低运维风险。

  

总之，你可以在同一个环境中，结合 App Platform（应用托管）、Kubernetes、托管数据库和存储服务，构建、部署并扩展基于 Opus 4.6 的 AI 应用。相比跨云调用第三方模型 API，这种原生集成方式组件更少，系统复杂度和运维成本也更低。

## 如何使用Claude Opus 4.6？

  

Opus 4.6 已上线 DigitalOcean Serverless Inference，无需任何基础设施的部署或管理。只需使用你的模型访问密钥进行身份验证，即可通过下面的 `curl` 请求立即获得响应：

  

```Bash
curl https://inference.do-ai.run/v1/chat/completions \
  -H "Authorization: Bearer YOUR_MODEL_ACCESS_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "model": "anthropic-claude-opus-4.6",
  "messages": [
    {
      "role": "user",
      "content": "What is the capital of France?"
    }
  ],
  "temperature": 0.7,
  "max_tokens": 1000
}'
```

  

你也可以在 [DigitalOcean Model Playground](https://cloud.digitalocean.com/gen-ai/model-playground) 中测试这一新模型，或将它与其他现有模型进行对比。

  

![CleanShot 2026-02-06 at 11.47.12@2x.png](https://blog.aidroplet.com/uploads/Clean_Shot_2026_02_06_at_11_47_12_2x_4cc38613ec.png)

  

🚀 **立即通过 DigitalOcean** **API** **或 Cloud Console 访问** **Opus** **4.6。**

  

想进一步了解 Opus 4.6 以及如何通过 DigitalOcean 使用它？欢迎访问卓普云官网博客，或联系咨询[卓普云](https://www.aidroplet.com/)。

Claude Opus 4.6 通过 DigitalOcean Serverless Inference 正式上线，提供百万级上下文与 Agentic 能力，帮助团队在统一云环境中高效构建、部署并扩展 AI 推理应用。

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

产品更新

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

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

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

OpenClaw 多智能体部署：弹性扩展、零运维

教程

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

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

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

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

新闻

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

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

DigitalOcean 基于 NVIDIA GPU 如何为 Workato 降低 67% AI 推理成本

没有 SRE 的创业团队，如何用 DigitalOcean 搭建一整套儿童课程在线平台