Hippocratic AI 致力于构建生成式 AI 智能体，它们可以致电患者、指导术后康复计划、跟进慢性病管理，并协助弥补可能被疏忽的医疗服务缺口。该公司的 Polaris 星座架构（Polaris constellation architecture）采用一个核心主模型来主导每次患者对话，同时有 20 多个专业支持模型并行运行，以此减少幻觉、提供临床依据，并对主模型的输出进行安全性交叉检查。截至目前，Hippocratic AI 在慢性病管理、服药依从性、医疗缺口填补和临床排程等方面已实现超过 1.8 亿次患者互动，其运行规模已达到了让“基础设施性能”与“患者安全”两者界限相融合的境地。通过与 DigitalOcean 在 NVIDIA GPU 架构上的紧密合作，**Hippocratic AI 在超过 1000 万次真实患者通话中达到了 99.9% 的临床安全评分，并在实时临床对话所需的低延迟下，支持了 2 倍的生产环境推理吞吐量。**

在通话中途断线的服药依从性提醒电话，绝不仅仅是一个用户体验缺陷，而是一次医疗中断。由 DigitalOcean 设计、运行在 NVIDIA Hopper 和 Blackwell Ultra 硬件上，并根据 Hippocratic AI 临床需求量身定制的生产堆栈，已经成功交出了答卷。

以下是 Hippocratic AI 在[ DigitalOcean 的 AI 原生云](https://blog.aidroplet.com/product-updates/powering-the-inference-era/)（AI-Native Cloud）上取得的成果：

- **2 倍生产环境推理吞吐量**：通过使用 NVIDIA H200 和 B300 GPU 的平台级推理优化得以实现。

- **P99 端到端延迟降低 40%**：通过将 DigitalOcean 的基础设施与 Hippocratic AI 的模型级优化相结合得以实现。

- **Prefill（预填充）延迟降低至原有一半**：在长上下文临床会话中，相比上一代无状态服务配置，延迟缩减了 2 倍。

- **单节点吞吐量提升约 30%**：由硬件感知调度、模型量化（如 NVIDIA B300 GPU 节点上的 NVFP4 方法）以及定制内核驱动。


## 为医疗 AI 选择云合作伙伴

Hippocratic AI 的 Polaris 系统编排了一个由 22 个专用大语言模型组成的架构，参数总量达 4.2 万亿。这些模型与患者进行实时的语音和文本交互，每次对话都要求亚秒级的响应速度，且对会话中途故障的容忍度为零。该系统已在超过 1000 万次真实患者通话中保持了 99.9% 的临床安全评分，平均患者满意度高达 8.95 分（满分 10 分），并获得了 7,500 多名临床医护人员的验证。

为了在生产规模下保持 400 毫秒的中位数首字延迟（time-to-first-token），Hippocratic AI 必须在最新可用的 GPU 硬件上运行。该公司在内部运行着多云基础设施，不同的模型架构需要不同类型的 GPU。

“NVIDIA 拥有令人惊叹的硬件，比如 Hopper 和 Blackwell GPU，而 DigitalOcean 堪称我们以最快速度获取这些硬件的核心合作伙伴之一，”Hippocratic AI 联合创始人 Debajyoti Datta 表示。

Hippocratic AI 此前一直在寻找能够支持其规模化发展的云合作伙伴，而事实证明，DigitalOcean 是获取最新 NVIDIA 硬件的最快路径之一。DigitalOcean 不仅提供了对 [NVIDIA HGX™ B300 GPU 节点](https://www.aidroplet.com/product/b300/)的早期访问权限和对 [NVIDIA H200 节点](https://www.aidroplet.com/product/h200/)的即时访问权限，还在针对持续推理负载进行优化的平台上提供了手把手的工程支持。Hippocratic AI 的团队通过 DigitalOcean 将生产负载顺利迁移到了 NVIDIA GPU 上，双方的合作自此不断加深。

“我们的合作基于一个共识：我们必须处于最新的硬件之上，并拥有最出色的推理堆栈，”Datta 说道。

## 打造保障患者安全的推理堆栈

在过去的一年里，DigitalOcean 与 Hippocratic AI 及 NVIDIA 紧密合作，对推理路径的每一层进行了优化。结合 Hippocratic AI 的真实生产需求，凭借对 NVIDIA HGX™ B300 GPU 的早期访问权以及对 Hopper 和 Blackwell 架构的深度技术支持，DigitalOcean 对其 AI 原生云进行了工程改造以满足这一严苛标准。其成果包括：硬件感知调度、针对持续高并发负载优化的推理运行时，以及对 FP8 和 NVFP4 量化、定制 MoE（混合专家模型）内核、KV 缓存优化和缓存感知路由架构的平台级支持。这种路由架构最大程度地提高了长周期临床会话中的 KV 缓存命中率和上下文复用率。

在长上下文临床会话中，这些联合优化的成果带来了约 30% 的单节点吞吐量提升，且与上一代无状态服务配置相比，预填充延迟降低了一半。这些进展与 Hippocratic AI 在 2026 年 4 月的 DigitalOcean Deploy 大会上宣布的生产环境改进相得益彰，当时该公司报告称其生产推理吞吐量提高了 2 倍，端到端 P99 延迟降低了 40%。

对于 Hippocratic AI 而言，这些绝非抽象的基准测试数据。达到延迟目标意味着系统可以在通话中途生成思考 Token（thinking tokens），从而使更新后的软硬件堆栈带来了 4 倍的吞吐量提升。这意味着在保持相同质量水平的前提下，能够支持更多并发的患者会话，从而实现从试点向全民规模的跨越。

“安全关键型 AI 负载的需求与消费级应用有着本质的不同。DigitalOcean 和 Hippocratic AI 展示了基于 NVIDIA H200 和 B300 硬件的紧密集成基础设施（打破软件和硬件的物理边界，云服务器的每一条连线、每一个调度算法，都是为了跑这个 AI 模型而优化和定制的）与推理优化，如何在规模化运行时同时兼顾高性能与高可靠性，”NVIDIA 加速计算产品总监 Dave Salvator 解释道。

得益于 DigitalOcean 与 NVIDIA 的合作，Hippocratic AI 也是首批在 NVIDIA HGX™ B300 硬件上运行生产负载的客户之一。对于每一个 Token 都会影响临床体验的业务负载，NVIDIA Blackwell Ultra 实现了单节点容量的阶跃式提升。它允许 Hippocratic AI 在相同的延迟目标下支持更多的并发会话，并在漫长的临床对话中扩展上下文窗口。NVIDIA B300 GPU 节点还支持更先进的量化方法（如 NVFP4），在吞吐量和延迟方面带来了可衡量的显著改善，并直接转化为了更优质的患者体验。

## 突发故障时，AI 云的选择至关重要

Datta 坦言在如此规模下运营的现实情况：GPU 基础设施一直在演进，驱动更新和节点中断是常态，恢复速度才是关键。

“我深切关注的是，当出现故障时，我们是否有可靠的合作伙伴与我们共同承担和扩展？DigitalOcean 团队在这方面表现得非常出色，”Datta 说道。

DigitalOcean 为驱动更新和节点维护提供手把手式的技术支持，并在硬件发生故障时提供快速更换。当 Hippocratic AI 对推理堆栈、硬件升级或新节点可用时间表有具体疑问时，DigitalOcean 的工程团队会直接与他们对接解决。

“哪怕是小事，比如对我们节点的支持，每当我们遇到关于推理堆栈和硬件的非常具体的问题时，DigitalOcean 在这方面都给予了极大的帮助，”Datta 表示。

DigitalOcean 首席执行官 Paddy Srinivasan 及公司领导团队也直接参与了与 Hippocratic AI 针对基础设施决策和扩展需求的深度沟通。

## 1.8 亿次互动，且在持续增长

Hippocratic AI 目前在其临床工作流中已处理了超过 1.8 亿次患者互动。在这一数字背后，是患者得到了关于其药物的及时提醒，或是术后接到了跟进电话，在症状恶化为急诊之前被及时捕获。Hippocratic AI 的智能体已经帮助患有慢性病的患者发现了关键的医疗服务缺口，团队内部强调，这种情况每天都会发生数百次。保障这些对话不间断运行的基础设施，与它们所带来的临床成效是不可分割的。

“Hippocratic AI 在医疗 AI 领域所构建的成果令人瞩目——在人们生命中某些最复杂、最敏感的时刻，完成了数亿次真实的患者互动。在 99.9% 的临床安全级别下交付这一成果，这就是关乎生死的生产级 AI 该有的样子。这就是专属推理堆栈所能带来的成效，也是我们的 AI 原生云让其成为可能的原因。Hippocratic AI 的成果就是最好的证明，”Srinivasan 表示。

该公司正在继续扩大其在 DigitalOcean 上的版图，定期增加节点，并计划在平台上最新硬件和 GPU 发布时第一时间采用。

这项工作的意义已经超越了基础设施的指标。Hippocratic AI 既是一个技术产品，同时也是一家医疗公司。其工程师在顶级 AI 研究期刊上发表论文，其临床团队对照真实的患者安全标准评估每一个模型的输出。其结果是一个基础设施与临床验证服务于单一目标的系统：确保患者安全。

最初为了解决医疗系统无暇顾及的电话人手问题而诞生的项目，如今已演变为更宏大的事业：一个在不断壮大的雄心壮志基础设施之上构建的、面向全民规模提供临床护理的基石。

“我对生成式 AI 在各处的应用都非常看好，医疗领域更是充满了巨大机遇。我认为现在是投入构建的绝佳时机，”Datta 说道。

large_images (21).png

medium_images (21).png

small_images (21).png

thumbnail_images (21).png

xsmall_images (21).png

images (21).png

Hippocratic AI 基于 DO 的 AI 原生云与 NVIDIA 最新硬件，实现两倍推理吞吐量，以顶级算力守护医疗安全。

承载 1.8 亿次互动：Hippocratic AI 联合 DigitalOcean 升级下一代 AI 原生推理架构

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

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

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

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

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

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

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

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

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

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

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

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

## 延迟优化策略

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

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

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

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

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

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

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

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

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

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

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

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

large_images-14.png

medium_images-14.png

small_images-14.png

thumbnail_images-14.png

images-14.png

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

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

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

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

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

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

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

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

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

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

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

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

## 迁移至 DigitalOcean Kubernetes

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

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

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

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

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

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

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

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

large_images (15).png

medium_images (15).png

small_images (15).png

thumbnail_images (15).png

xsmall_images (15).png

images (15).png

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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


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



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

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

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

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

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

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


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

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

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

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

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

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

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


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

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


当前阶段：

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


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

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

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


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

下一步，我们正在探索：

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

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

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

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

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



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

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

答案是：**会。**

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

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


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

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

在这个过程中：

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


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



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

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

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

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

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

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

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


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

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

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

  

**关于卓普云**

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

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

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

这意味着：

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

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

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

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

恰恰相反：

对人的要求变得更高了。

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

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

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

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

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

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


## 最后

  

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

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


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

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

更重要的是：

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

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

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

  

**AI 协同声明**

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

large_zach-m-pd9jBKNLyj4-unsplash.jpg

medium_zach-m-pd9jBKNLyj4-unsplash.jpg

small_zach-m-pd9jBKNLyj4-unsplash.jpg

thumbnail_zach-m-pd9jBKNLyj4-unsplash.jpg

xlarge_zach-m-pd9jBKNLyj4-unsplash.jpg

xsmall_zach-m-pd9jBKNLyj4-unsplash.jpg

zach-m-pd9jBKNLyj4-unsplash.jpg

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

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

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

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

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

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

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

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

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

通常由平台管理：

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


由你掌握：

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

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



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

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

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

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


## 高层架构

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

large_images (17).png

medium_images (17).png

small_images (17).png

thumbnail_images (17).png

xsmall_images (17).png

images (17).png

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

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

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

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

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

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

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

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

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


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

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


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


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


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


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

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


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


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

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


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


以下是新功能：


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

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


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



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


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

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


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


新功能包括：


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


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


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


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


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


新功能包括：


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


## 全栈的复合效应


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

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

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

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


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


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

images.svg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

**扩展模型与服务**  

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

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

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

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

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

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

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

**Knowledge Bases（知识库）**  

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

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

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

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

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

**展望未来**

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

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

medium_luke-jones-tBvF46kmwBw-unsplash.jpeg

small_luke-jones-tBvF46kmwBw-unsplash.jpeg

thumbnail_luke-jones-tBvF46kmwBw-unsplash.jpeg

xsmall_luke-jones-tBvF46kmwBw-unsplash.jpeg

luke-jones-tBvF46kmwBw-unsplash.jpeg

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

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

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

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

## 跨越生产落地鸿沟

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

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

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


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

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

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

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

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

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

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

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

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

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

large_images (10).png

medium_images (10).png

small_images (10).png

thumbnail_images (10).png

xsmall_images (10).png

images (10).png

苏姿丰预言AI智能体将引发CPU紧缺。未入局企业如何利用DigitalOcean打破Token高价税、部署全天候Agent？

2026 AI 下半场变天：从 GPU 狂热到 CPU 翻倍，未入局的企业如何全面部署 AI Agent？



就在不久前，全球科技界与华尔街投资人刚刚经历了一场认知上的剧烈震荡。在最新的一场行业峰会上，AMD（超威半导体）CEO 苏姿丰抛出了一份让人有些始料未及的行业预测：她将全球数据中心服务器 CPU 的市场规模预期直接翻倍，暴力拉升至 1200 亿美元，其年复合增长率从原本温和的 18% 陡峭地飙升至 35% 以上。

这个数据一经发出，立刻在科技圈引发了广泛的讨论与不解。

要知道，过去几年整个科技行业在谈论 AI 时，脑海里唯一的硬通货就是英伟达那让人望而却步的 GPU（图形处理器）。从 H100 到新一代算力架构B300，几乎所有的资金、闪光灯和创业故事都在围绕着“显存、张量核心、GPU 吞吐量”打转。而在传统认知里，负责基础通用计算的 CPU 似乎早就成了 AI 时代的“边缘配角”。

那么，为什么在 AI 浪潮不仅没有降温、反而愈演愈烈的今天，见惯了行业大风大浪的“芯片女皇”苏姿丰，却言之凿凿地宣称“**数据中心 CPU 业务正在疯狂升温**”？

答案其实并不在硬件本身，而在软件和应用生态正在经历的一场深刻质变。苏姿丰在演讲中敏锐地指出，全球算力基础设施正在经历一场反向回归：**AI 正在告别单纯的大模型训练与单次对话阶段，全面迈入 Agentic AI（智能体）时代。随着智能体的爆发，数据中心中 CPU 与 GPU 的数量比例，正在从过去的 1:4 甚至 1:8，快速向 1:1 回归。**

这场由 AI Agent 引发的底层算力变革，正像一场悄无声息的暗流，席卷着从硅谷巨头到独立开发者在内的整个科技生态。而作为这场变革的最直接承载者，**CPU（或者说承载 CPU 算力的 VPS 服务器）的需求量，正在迎来一场历史性的爆发。**

## 为什么 Agent 的爆发，让 CPU 重新成为 AI 核心？

要理解苏姿丰这个 1200 亿美金预言背后的硬核逻辑，我们需要先厘清当一个 AI Agent（智能体）在实际生产中运转时，它到底在消耗什么样的算力。

在过去的 AI 1.0 阶段，我们和 AI 的互动是“单次问答”模式。你输入一个问题，大模型在后端进行高强度的矩阵乘法运算，吐出答案。这个“在大模型推理的一瞬间闪烁脑细胞”的过程，确实是 GPU 的绝对主场。

但在 Agent 时代，AI 彻底告别了“提线木偶”的形态。无论是开源社区里大火的 [**Hermes  Agent** ](https://blog.aidroplet.com/tutorials/hermes-agent-serverless-inference/)，还是强调多智能体协同的 **[OpenClaw](https://blog.aidroplet.com/tutorials/openclaw-multiple-model/)** 框架，它们所构建的“数字打工人”，在日常工作中的行为模式其实是这样的：

1. **常驻后台与事件监听**：一个用来盯盘的金融 Agent，或者一个监控跨境电商竞品价格的 Agent，需要 24 小时挂在后台，每隔 5 分钟去抓取一次网页，或者随时等待外部系统发来的网络钩子（Webhook）唤醒。
2. **逻辑推理与任务编排**：当 Agent 被唤醒后，它需要运行极其复杂的业务逻辑。比如它要先读写本地的轻量级数据库（如 SQLite），对比历史数据；然后调用 Python 脚本处理一段文本；接着通过网络协议将数据打包。
3. **调用大模型大脑**：此时，它才会把准备好的 Prompt 通过 API 发送给云端的大模型（如 Claude 3.5 或 GPT-4o），等待大模型返回一个几十个字的行为决策指令。
4. **工具执行与安全沙盒（Sandbox）**：收到指令后，Agent 回到本地环境，通过 MCP（Model Context Protocol，模型上下文协议）去执行一系列本地终端命令、读写文件或者调用第三方 API。


在这个完整的生命周期里，你发现了什么？

真正消耗 GPU 算力的“思考（大模型推理）”部分，其实只占了不到 10% 的时间，而且这部分算力已经被 OpenAI、Anthropic 等巨头通过 Serverless API 的形式低成本地承包了。而 Agent 在绝大多数时间里干的事情——**高频的网络 IO 请求、复杂的条件判断、多进程的任务调度、Docker 容器的运行、本地文件与数据库的读写——全都是最传统的、对单核性能要求极高的 CPU 密集的绝对主场！**

如果为了让这些需要 24 小时常驻后台、静默监控、随时准备执行 Python 自动化的 Agent 运行，而去租用一台带有 GPU 的服务器，这就好比开着重型坦克去菜市场买菜。不仅成本高到让任何一家企业破产，其硬件利用率也低得令人发指。

正如苏姿丰所洞察到的趋势：**在 Agent 时代，轻量、高效、具备高单核性能、且能够提供稳固独立操作系统的 CPU 节点（即 [VPS 服务器](https://www.aidroplet.com/product/cloudcpu/)），才是圈养这些“数字打工人”性价比最高的黄金土壤。**

## 从芯片到云端——个人与企业如何跟上这波 1200 亿的红利？

当芯片女皇在行业的最高处为我们点明了“CPU + Agent = AI 下半场”的未来走向后，摆在广大开发者、独立黑客以及出海企业面前的问题就变得非常具体了：**我们该如何将这个宏大叙事，落地到自己的业务和日常生产力中？**

首先，**“自主部署”已经成为了无法逆转的必然选择。**

在 Agent 发展的早期，市面上曾涌现过不少一键配置 Agent 的 SaaS 网页平台。但很快，这些平台就在实际商用中碰了壁。

第一个无法逾越的大山是**数据隐私与安全**。当一个企业希望 Agent 帮它处理核心的客户名单、订单财务数据或者内部源代码时，把这些数据天天往第三方的 SaaS 平台上托管，无异于将商业机密拱手让人。

第二个痛点则是**深度定制的无能为力**。当你需要 Agent 调用一个极其偏门的 Linux 命令行工具，或者连接一个内网数据库、挂载特定的网络协议时，封闭的 SaaS 平台根本无法提供 Root 权限。

因此，大伙儿纷纷选择将开源的 Hermes Agent 或 OpenClaw 下载下来，自主部署。而要自主部署一个 24 小时不能断电、不能断网、需要独立安全边界的 Agent，一台高品质的 VPS（虚拟专用服务器）就成了最核心的基础设施。

然而，并不是所有的 VPS 都能随随便便当好 Agent 的“数字宿舍”。要承载苏姿丰所说的这种高频交互、自进化的智能体架构，开发者在挑选服务器时，面临着以下几个隐形的门槛：

- **核心门槛一：与全球主流 AI API 的网络连接质量**。Agent 需要极其频繁地与海外的 AI 节点通信。如果你的 VPS 所在的网络环境经常出现丢包、高延迟，甚至其 IP 经常被 OpenAI 或 Anthropic 的防火墙风控系统判定为“高风险代理”而直接封禁 API，那你的 Agent 就会瞬间陷入瘫痪。
- **核心门槛二：环境配置的摩擦力**。配置一个现代开源 Agent 极其折腾，Node.js、Python、Docker 镜像、向量数据库、SSL 证书……各种依赖盘根错节。如果服务商无法提供对开发者友好的生态，开发者就会把大把的黄金时间浪费在枯燥的系统调优和排错上。
- **核心门槛三：计费的透明度与抗突发流量能力**。多智能体系统在协同工作时，网络吞吐和 CPU 占用往往呈现出极强的“爆发性”。我们需要服务商提供能稳稳吃下突发峰值、且计费完全透明、不会在月底抛出一张天价账单的基础设施。


## DigitalOcean Droplets：完美承载“苏氏 AI 架构”的蓝色大洋

顺着这些挑剔的隐形门槛在市场上进行筛选，你会发现，在 2026 年的今天，曾经在开发者群体中拥有图腾般地位的 DigitalOcean（简称 DO），几乎完美地踩中了 Agent 时代所有的底层刚需，成为了承载“苏氏 AI 架构”的首选超级底座。

DigitalOcean 自诞生之日起，就将“为开发者简化云端体验”刻进了骨子里。当这种纯粹的极客基因在 2026 年与 AI Agent 浪潮迎头相撞，便释放出了巨大的基础设施红利。

### 1. 扎实的 CPU 性能，稳稳吃下 Agent 的逻辑洪流

呼应苏姿丰对 CPU 重要性的强调，DigitalOcean （简称 DO）的核心产品 **[Droplets（云主机）](https://www.aidroplet.com/product/cloudcpu/)** 提供了质量极高的通用计算算力。尤其是其 Premium 档位的 Droplets，配备了高单核性能的现代化处理器。在面对多智能体系统复杂的链式思考、密集的本地 Python 脚本执行、以及 Docker 沙盒内的高频 IO 读写时，DO 的 CPU 能够提供极具弹性的性能支撑，确保 Agent 在高并发处理任务时绝不卡顿、掉链子。

而且，英伟达AI体验网站 [build.NVIDIA.com](https://build.nvidia.com/) 上的模型均部署于 DigitalOcean 的高性能基础设施上，同时 **AMD 开发者云**也是选择由 DigitalOcean 提供技术支持。两大 GPU 阵营都选择了 DigitalOcean 的云基础设施作为阵地，足以证明其稳定性与高性价比。
### 2. 原生海外骨干网，让智能体“思维”畅行无阻

DigitalOcean 的数据中心广泛分布于纽约、旧金山、新加坡、法兰克福、阿姆斯特丹等全球核心网络节点。它的网络对于 Anthropic、OpenAI、Groq 以及各大主流托管推理平台的服务器有着天然的路由优化。 当你的 Agent 驻扎在 DO 的 Droplet 里时，它每一次向大模型大脑发送请求、接收指令，都能在毫秒级的延迟内完成。这种极低的网络延迟，对于需要成百上千次高频对答的多智能体协同系统来说，带来了整体执行效率的质的飞跃。更重要的是，DO 提供的公网 IP 质量极佳，极少遭到 AI 巨头的无故风控，给智能体提供了一个稳定、安全的通信环境。

不仅如此，**2026 年的 DigitalOcean 早已不再只是一个纯粹的 VPS 厂商，更是一个全栈的 AI 生态级平台。** 针对智能体开发，DO 官方推出了全新的 **Serverless Inference（无服务器推理）服务**，并与 Anthropic、OpenAI 等顶尖大模型厂商达成了官方深度合作。无论你是想接入最新版的 Claude 系列（如 Opus、Haiku），还是 GPT 核心商业模型，甚至是社区主流的开源大模型，DO 都能提供原生的一站式支持。

通过其内置的**智能推理路由（Inference Router）**，系统能够帮助用户根据 Agent 不同的任务类型，自动在速度、成本与智能水平之间动态切换最适合的模型：需要深度推理时走顶级商业大模型，需要快速响应和清洗数据时走轻量级开源模型。

这种“底层靠高品质 VPS 筑基，上层由官方 Serverless 推理导航”的软硬一体化设计，彻底打通了智能体“身体与大脑”之间的最后一道屏障。它让数据在 DO 的全球骨干网上流转时，不仅免去了跨平台对接的繁琐配置与风控风波，更将网络的延迟和损耗降到了理论极限。**这才是真正意义上的原生骨干网，它让你的 Agent 在执行任何复杂的多智能体协同任务时，思维不仅永远在线，更能畅行无阻。**

### 3. 拒绝一切“账单背刺”

对于独立开发者和小微创业团队来说，DigitalOcean 几十年来为人称道的“透明计费”在 AI 时代依然是一剂强心针。入门级 Regular Droplet 每月仅需几美元，按小时计费，用多少扣多少，试错成本低到可以忽略不计。

当然，需要理性说明的是，**DigitalOcean 的流量并不是完全无限制免费的**。每一个 Droplet 套餐都会自带一个极其慷慨的、通常以 **1TB 起步的免费公网出站流量包**（入站流量完全免费）。如果你的 Agent 变成了一个超高频全网抓取素材、每天疯狂吞吐数据的“吞吐怪”，导致出站流量最终超出了套餐额度，DO 对超额流量的计费标准也极其简单粗暴——**一律按 $0.01/GB（每 GB 仅 1 美分）计算。**

这个价格是什么概念？对比一下行业巨头你就懂了：AWS、Google Cloud（GCP）以及阿里云等平台的公网出站流量费用，通常在 **$0.07 到 $0.12/GB** 之间不等，甚至还会根据全球不同的目的地设计极其复杂的阶梯式计费表格。

相比之下，DO 的超额流量成本几乎只有传统云巨头的几分之一甚至十分之一，且计算方式毫无套路。在 DigitalOcean 的庇护下，你再也不用盯着后台那随时可能暴涨的计费槽战战兢兢，不仅能放开手脚让 Agent 去跑自动化任务，更能彻底告别突发流量带来的天价账单风险。

## 未来展望：在 DO 上开启你的“AI 多智能体公司”

当苏姿丰所预言的高性能 CPU 算力，撞上 DigitalOcean 那几乎没有摩擦力的开发者生态，我们能在实际生产中玩出哪些让人大呼过瘾的实战狂想？

- **场景一：24小时不间断的“全球市场首席情报官”** 你在 DigitalOcean 纽约机房开了一台 5 美元的普通 Droplet，通过一键镜像部署了 OpenClaw 框架。这个 Agent 拥有独立的海外 IP，一年 365 天从不睡觉。它每隔 10 分钟就会用自动化浏览器把全网关于你行业竞品的动态、独立站改价信息、Product Hunt 上的爆款新品、以及社交媒体上的技术讨论默默抓取一遍。 它利用低延迟网络把数据送给云端大模型清洗、提炼，一旦发现真正有价值的行业异动，立刻通过安全端点向你的手机推送一条精简到一句话的“精准警报”。你合上电脑去睡觉，而你的情报网络在全球骨干网里昼夜不停。
    
- **场景二：出海电商的“多智能体虚拟运营部”** 通过 **DigitalOcean AI Agent Builder**，你在一台 Premium Droplet 里圈养了一个由三个 Agent 组成的小团队：客服 Agent、风控 Agent、文案 Agent。它们共享一个挂载在 DO 上的向量记忆库，并安全地连接着你的店铺后台。 当海外消费者半夜发来一封措辞复杂的退换货邮件时，DO 服务器的 Webhook 瞬间唤醒它们。客服 Agent 启动，在服务器内部向风控 Agent 询问该用户的历史信用，风控 Agent 给出评估后，文案 Agent 自动组织出一封极其地道的英文安抚信，并在后台把退货标签生成好一并发送。全流程在几秒钟内优雅完成，而你付出的成本，仅仅是那台 Droplet 每一小时清爽、透明的微量扣费。
    

## 写在最后

科技大潮的演进，总是遵循着特定的客观规律。当人们依然沉浸在大模型参数量的不断狂飙、以及各种惊艳的 Agent 框架层出不穷的宏大叙事中时，苏姿丰用一份 1200 亿美金的预言，把整个行业的目光重新拉回到了最扎实、最务实的基础设施地面上。

大模型的上半场，是属于科技巨头们在神坛上的 GPU 军备竞赛；而 AI 的下半场——也就是 Agent 真正走向千家万户、重构每一个普通人生产力的时代，它的胜负手则悄然转移到了**长尾、清爽、离开发者最近的 CPU 与 VPS 服务器上。**

在这个激荡的时代拐点面前，你不需要去排队订购昂贵的硬件，也不需要将自己的核心业务隐私交托给充满不确定性的第三方平台。

现在，只需注册 **DigitalOcean**，获取新用户专属的免费试用额度，你就能用一张电影票的成本，为你那永不疲倦的第一个 AI Agent，安上一个稳固、自由、全天候在线的数字家园。亲自去参与、去见证这场由芯片女皇预言的、正在发生的算力大变革。

最后，DigitalOcean 中国区战略合作伙伴[卓普云（aidroplet.com）](https://www.aidroplet.com/)全权负责DigitalOcean 在亚太地区的销售与技术支持。企业用户通过卓普云可获得最新的折扣优惠信息，与DigitalOcean直签，更多详情可直接咨询卓普云。

large_images-2.png

medium_images-2.png

small_images-2.png

thumbnail_images-2.png

xsmall_images-2.png

images-2.png

当全网都在为 GPU 疯狂时，苏姿丰却将 CPU 市场预测暴力翻倍。AI 下半场变天，谁在悄悄囤积底层算力？

狂热的 GPU 背后：为什么苏姿丰的 1200 亿美金预言里，主角是 CPU？

在大模型能力深度融入生产环境的当下，后端 AI 架构的选择往往决定了应用的生死。从早期的“调用一个接口”到如今复杂的智能体（Agent）工作流，开发团队在底座选型上面临着两条截然不同的演进路径：一条是追求便利与极致轻量化的 Token 聚合平台；另一条则是在提供大模型的同时，提供更加自主可控的云基础设施的AI原生云。

本文将不带偏见地拆解这两条路径，深入探讨团队在何种阶段、何种场景下应该选择 Token 聚合平台，并在何时、何种业务规模下，必须坚定地转向基础设施更加完备的 AI 原生云。

## 什么业务场景和团队规模最适合使用 Token 聚合平台？

对于许多处于萌芽期或快速试错阶段的项目而言，Token 聚合平台（如各种第三方多模型聚合 API）是完美的冷启动跳板。它将底层复杂的算力、供应商网络和繁琐的账号体系进行了抽象，为开发者提供了一种“即插即用”的极简体验。

### 1. 产品处于 PMF（产品与市场匹配）验证期

在产品的最初阶段，最大的风险不是网络延迟，也不是架构的优雅度，而是“用户根本不需要这个产品”。在这个时期，业务量表现出极高、极不稳定的波动性：今天可能因为某个推文或推广动作带来几万 Token 调用，明天可能就直接归零。

Token 聚合平台采用的是完全“用多少付多少（Pay-as-you-go）”的散装计费模式，没有任何基础设施的固定投入成本。团队不需要去评估要租多少张 GPU，也不用去管底层是 Serverless 还是按时计费，非常适合用来跑通最小可行性产品（MVP）。

### 2. 多模型“杂食性”业务与快速组合实验

现代 AI 应用很少再依靠单一模型打天下。一个成熟的 AI Agent 架构内部往往是高度异构的：

- **日常文案与总结**：可能调用 GPT-4o-mini 或 Gemma 这种高性价比模型。
- **复杂的逻辑推理与代码审查**：可能需要接入 Claude 或 DeepSeek 等前沿模型。
- **特定垂类任务或多模态分析**：又需要接入其他的专项视觉/语音模型。

如果直接对接原生厂商，团队的工程师需要去 OpenAI、Anthropic、DeepSeek 等数家官网分别注册账号、绑定不同的境外企业信用卡，处理不同格式的 API 文档。而 Token 聚合平台最大的贡献在于“统一协议（通常兼容 OpenAI 格式）”与“统一账单”。它用一把 API Key 解决了多模型杂食的混乱局面，让产品经理和前端工程师能在几分钟内随意切换、组合各种模型，极大地提升了研发的效率。

### 3. 微型团队与独立开发者的极致“无运维”追求

如果你的团队只有 1 到 3 个人，甚至你本人就是一个独立开发者，团队里根本没有专职的运维（DevOps）或云基础设施专家。此时，将精力耗费在配置网络、管理密钥和搭建高可用架构上是极为奢侈的。聚合平台将 Base URL 一换，填入 Key 就能在几小时内让应用全球上线的特性，能够将团队有限的精力100%聚焦在业务逻辑和用户体验的雕琢上。

## 繁华背后的暗礁：Token 聚合平台的先天短板

然而，天下没有免费的午餐。Token 聚合平台在封装了便利性的同时，也隐藏了其商业模式和技术架构上的原生缺陷。随着业务规模从“每天几千次请求”激增到“每秒数百次并发（QPS）”，这层漂亮的“包装”就会开始在生产环境中大面积脱落。

### 1. 无法根治的网络延迟与“长尾效应”

Token 聚合平台本质上是一个架设在公网上的**公共代理网络**。由于聚合平台绝大多数不拥有底层的物理硬件和机房算力，你的每一次 API 请求都可能经历多跳网络：

$$\text{客户端} \xrightarrow{\text{公网}} \text{聚合平台网关} \xrightarrow{\text{二次鉴权/路由}} \text{上游真正的模型供应商} \xrightarrow{\text{模型推理}} \dots$$

这种多跳架构在低并发时可能表现尚可，但在真实生产环境的高并发（High Concurrency）场景下，会引发灾难性的**长尾延迟（Tail Latency）**。由于其中任意一跳遭遇网络抖动或上游拥堵，就会导致终端用户遇到明显的卡顿甚至连接超时。对于追求即时交互（如实时客服聊天、协同代码补全）的应用，这种不确定性是致命的。

### 2. 数据合规与企业隐私红线

这是出海业务中一块无法逾越的雷区。当你的 AI 产品开始接触企业级客户（B 端），或者面临欧盟 GDPR、美国 SOC 2 等严苛的合规审查时，客户会极其严肃地审视其数据的流向：

> “我们的商业机密或用户的个人隐私数据，在传输过程中究竟经过了谁的手？”

如果你的后端架构中包含一层不知名或缺乏最高级别安全合规的第三方 Token 聚合平台，你几乎无法在欧美市场推广你的业务。即便是在中国地区提供业务，也很难被大型企业信任。聚合平台的数据缓存机制、日志留存政策对其而言是一个完全的黑盒，这直接卡死了产品走向商业变现的大门。

### 3. 并发黑洞与突发性的限流

Token 聚合平台的上游账号往往是**共享或池化管理**的。这就带来了一个经典的“坏邻居效应（Bad Neighbor Effect）”：同一个平台上的其他客户如果突然遭遇大流量攻击或进行了恶意的并发测试，平台持有的上游供应商账号可能会被瞬间触发速率限制或临时封禁。这意味着，即使你的应用本身表现十分规范，也会因为其他用户的问题而在毫无征兆的情况下收到大量的报错，导致核心业务中断。

## 生产级跨越：何时需要转向 AI 原生云？

当你的应用成功度过了生存验证期，有了稳定的日活（DAU）和持续增长的调用量，技术架构的目标就必须从“快速上线”演进为“极致的稳定性与单位经济效益（Unit Economics）”。

这种情况下，像 **DigitalOcean (简称 DO)云平台的 [Inference Engine（推理引擎）](https://www.aidroplet.com/product/serverless-inference/)** 这样的AI原生云基础设施就成为了更安全、更强大的解法。根据DO官方的客户案例显示，在切换至 DO 推理引擎后，很多团队不仅获得了全栈的可控性，其**综合推理成本更是实现了高达 40% 甚至 67% 的大幅缩减**。

这种成本和性能的跨越，来自于云平台在其原生生态中提供的一系列 Token 聚合平台完全无法复制的核心优势：

### 1. 取代“If/Else”的 Inference Router

传统上，如果你想在聚合平台上做成本优化，你的后端工程团队必须在业务代码里写满复杂的 `if/else` 逻辑：如果提示词字符数少于 500 且属于简单分类，则调用模型 A；如果涉及复杂数学，则调用模型 B。这种做法极其脆弱，一旦更换模型或业务规则微调，整个路由树就要重写。

DigitalOcean 推理引擎引入了 **Inference Router（推理路由器）**。它将这种复杂的分类和分流逻辑，直接做进了云平台的**底层 AI 中间件/推理管线**中。

```
                       [ 统一的 API 终点入口 ]
               (https://inference.do-ai.run/v1)
                              │
                              ▼
                 ┌─────────────────────────┐
                 │ DO Inference Router     │
                 │ (基于自然语言策略的 MoE 路由) │
                 └────────────┬────────────┘
                              │
             ┌────────────────┼────────────────┐
             ▼                ▼                ▼
       【 任务分类 A 】  【 任务分类 B 】  【 辅助/离线任务 】
       (如: 严谨推理)    (如: 快速回复)    (如: 结构化抽取)
             │                │                │
             ▼                ▼                ▼
       [ 前沿大模型 ]    [ 轻量高吞吐模型 ] [ 异步批量推理 ]
       (如: DeepSeek-R1) (如: Llama-3-8B)  (享高达 50% 折扣)
```

开发者只需要在控制面板中一次性定义好任务池（Task Pool），并为不同的任务分配对应的模型备选范围，然后设置你偏好的选择策略。在运行时，你只需要把所有请求统一发送到一个固定、稳定的端点：

`https://inference.do-ai.run/v1`

并将模型名称指定为 `router:<your-router-name>`。DO 底层由专为智能体优化的 MoE（混合专家）模型驱动的路由器会自动读取完整的请求、系统提示词和上下文，对其进行秒级的语义分类和智能派发：

- **对于简单的辅助任务**（如邮件格式验证、Session 缓存搜索、网页 HTML 结构化特征提取）：路由器会自动将其定向到极便宜的轻量模型上（通过 `auxiliary: config` 辅助配置块进行固定）。
- **对于真正的逻辑核心或长文本推理**：才会动态调用顶尖的模型，比如Claude opus 4.7、Openai等。

这种“非固定、基于业务场景动态流转”的自适应路由机制，是生产规模扩大后成本下降的根本原因。它让团队可以无需改动任何一行应用程序代码，就能享受到模型与任务之间最优配对带来的便利。

### 2. 批量任务的异步处理：Batch Inference

在生产环境中，并非所有的 AI 请求都需要即时响应（如生成报告、跑离线评测数据集、历史数据清洗、自动化 RAG 向量库构建等）。

Token 聚合平台由于底层缺乏存储和任务调度系统的支持，对这类离线任务也只能收取一视同仁的实时 API 溢价。而 DigitalOcean 推理引擎直接提供了 [Batch Inference（批量推理） 能力](https://blog.aidroplet.com/product-updates/powering-the-inference-era/)。你可以将这些庞大的非实时工作流以异步文件的形式打包提交，系统提供内置的自动重试、失败隔离，并在承诺的 24 小时内完成。作为回报，**Batch 模式直接给予一定的折扣**，这让高吞吐、大批量的离线 AI 任务在单位经济效益上展现出了无与伦比的优势。

### 3. 稳定的网络

如果你的 Web 主机、Droplets（云服务器）、托管数据库（如支持 pgvector 的 PostgreSQL）或者 Kubernetes (DOKS) 本身就已经运行在 DigitalOcean 的生态系统内，那么接入 DO 推理引擎将带来质的飞跃。

此时，你的 AI 流量不再需要跨越茫茫公网和各家不同的 CDN 代理节点，而是完全运行在**云平台 400G RoCE RDMA 高速架构的内部私有网络**中。这种“近场通讯”消灭了所有跨提供商的网络握手延迟，网络拓扑极其干净。对于大规模、多步骤的 AI Agent 工作流（一个复杂任务往往需要连续进行十几次甚至几十次串行 LLM 调用），内网级别的超低延迟和高度稳定性会产生滚雪球般的累积优势。

### 4. 系统弹性与故障自愈

在聚合平台上，如果某个上游模型挂了，你的系统通常只能暴露出错信息给最终用户。但在 DO 推理引擎的路由机制中，系统被赋予了原生的**故障自愈弹性**。你可以为每一个定制任务配置多3 个候选模型。一旦首选模型遭遇高负载下的速率限制、上游提供商突发错误或者响应过慢，路由器会在毫秒级内自动、透明地降级切换到候选模型池中的下一个模型进行兜底（你可以预先设置决定是哪个模型），确保你的前端生产服务永远不会中断或“掉链子”。

## 相比 AWS 或 GCP 巨头，DO 推理引擎的独到优势

当我们把目光投向云厂商巨头（如 AWS Bedrock 或 Google Cloud Vertex AI）时，DigitalOcean 并没有盲目地去堆砌繁复的企业级功能，而是凭借其一贯的 **“务实与克制”**，针对中小型企业和出海初创团队精准解决了巨头的痛点：

### 1. 彻底打破“全家桶”式的上手高墙

在 AWS 这样的超大型云中运行一个生产级的 AI 推理任务，通常意味着你需要先跨越一道陡峭的认知鸿沟。你需要去配置庞杂的 IAM 权限策略、划分 VPC 终端节点（Endpoints）、绑定 S3 存储桶安全策略，还要理解错综复杂的资源组关联。这被称为“巨头税”——为了使用一小部分功能，你不得不雇佣高昂的专职架构师去梳理庞大的全家桶基建。

DO 推理引擎延续了其经典的“开发者友好”基因。无论是通过控制面板（Control Panel）进行点选，还是直接通过一条 `POST` 请求访问 `[https://api.digitalocean.com/v2/gen-ai/models/routers](https://api.digitalocean.com/v2/gen-ai/models/routers)` 的统一 API 格式，你都可以在几分钟内完成一个生产级路由器的配置与部署，将底层复杂的 GPU 虚拟化、KV 缓存亲和性路由（KV-cache affinity routing）完全屏蔽掉。

### 2. 拒绝隐形账单与网络出向（Egress）陷阱

传统云巨头最广为人知也最令创业团队头疼的，就是其密密麻麻、如同迷宫般的**隐形账单**。特别是网络出向流量费（Egress Fees），当你在不同的云服务之间搬运大量上下文、Embedding 向量或多模态数据时，每月的流量账单往往会演变成一个惊人的数字。

DO 提供了完全透明、基于消耗的极简计费体系，且在其多层 AI 原生云（从 Droplet、数据库到推理引擎）之间**免收数据传输与出向费用**。数据的出站费用则比AWS便宜至少80%。同时，Serverless 模式下更是具备极高的弹性，甚至提供**离峰/非尖峰时段定价（Off-peak Pricing）**，让夜间或低峰期的自动化测试和后台跑批成本进一步降低。

### 3. 卓越的底层工程优化与惊人的性能表现

DO 推理引擎绝非仅仅是对大模型做了一层套壳。在底层，它深度集成并定制优化了诸如 vLLM、NVIDIA TensorRT 以及 SGLang 等前沿的开源推理加速栈。配合 GPU 亲和性调度和专门优化的键值缓存（KV-Cache）管理，其性能展现出了极强的爆发力。

根据独立 AI 基准测试机构 **Artificial Analysis** 的最新评测数据，在处理类似 DeepSeek-V3/R1 等大模型的多并发长文本输入（10,000 个输入Token）时：

> DigitalOcean 推理引擎展示出了极强的性能碾压优势——其**首字返回时间（TTFT）和输出吞吐速度（Output Speed），最高可达 Amazon Bedrock 同类配置的 3 倍**，在响应延迟的连贯性和吞吐量稳定性上，稳稳占据了评测象限中最优的“Most Favorable”位置。

## 选型决策指南：一张表看清技术路线

为了让团队能够有据可依，我们从四个最核心的业务维度梳理了具体的量化决策矩阵：

|**评估维度**|**推荐使用：Token 聚合平台**|**必须转向：DigitalOcean 推理引擎**|
|---|---|---|
|**产品生命周期**|0 -> 1 探索阶段、原型（MVP）验证、黑客马拉松项目。|1 -> 10 成长期、生产环境商业化落地、DAU 稳定上升期。|
|**网络延迟与 QPS**|低并发、对偶发的网络延迟抖动或长尾延迟（Tail Latency）不敏感。|高并发、高吞吐，严苛要求毫秒级低延迟与延迟的一致性稳定性。|
|**核心业务诉求**|多模型频繁轮换、杂食测试、快速验证不同大模型的语义表现。|依赖高频智能体（Agentic）工作流、需要结合内网数据库/ Droplets 的综合架构。|
|**企业安全与财务合规**|团队处于初期，无严苛审计压力；账单多为开发者个人信用卡支付。|需要通过欧美 B 端客户安全审计（GDPR/SOC 2），要求单一、合规的云厂商 Invoice 统一账单。|

## 结语：架构是上演进出来的，不是设计出来的

优秀的架构师从不追求一步到位的完美，而是追求**技术与当下业务规模的最优适配**。

如果你现在正带着两三名伙伴，在出海的风口上疯狂寻找方向、验证想法，那么请毫不犹豫地选择 **Token 聚合平台**。不要把宝贵的创业初期时间浪费在任何服务器、网络和算力基建上，快就是唯一的真理。

然而，当你的产品成功跨越了生存线，日活用户开始破万，甚至大企业的采购经理拿着安全合规问卷单敲响你的大门时；当你面对每月成千上万、包含了大量多步智能体调用和离线批量清洗任务的杂乱账单陷入沉思时——这意味着你的产品已经真正进入了比拼“内功”的工业级时代。此时，果断地将 AI 基础设施迁移切换到 **DigitalOcean Inference Engine**，利用其强大的语义路由、异步批量折扣、内网超低延迟以及主流云厂的合规背书，方能让你的 AI 应用在波谲云诡的商业落地中行稳致远。

如需进一步了解DigitalOcean AI推理引擎，可直接联系[卓普云（aidroplet.com）](https://www.aidroplet.com/)。新注册用户，如果需要使用DigitalOcean上的Claude、openAI模型，可与卓普云申请权限。

large_images (18).png

medium_images (18).png

small_images (18).png

thumbnail_images (18).png

xsmall_images (18).png

images (18).png

AI推理架构选错可能“生死攸关”。聚合平台和原生云，到底该怎么取舍？答案藏在业务发展的每个阶段里。



Token聚合平台 vs 传统云 vs AI原生云，AI推理应用怎么选？

large_images (20).png

medium_images (20).png

small_images (20).png

thumbnail_images (20).png

xsmall_images (20).png

images (20).png

用推理路由器，自动将不同任务匹配最佳模型，代码任务交给claude，文本任务交给deepseek，成本比全用前沿模型降低 71%。

实战指南：AI调用成本降71%——利用“推理路由”告别大模型胡乱开销

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

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

large_images.png

medium_images.png

small_images.png

thumbnail_images.png

xsmall_images.png

images.png

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

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


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

---

## 什么是 DigitalOcean 推理引擎？

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

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

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

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



## 无服务推理 Serverless Inference

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

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

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

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

### 最佳适用场景

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

### 关键特性

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

### 快速开始

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

### 真实案例

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



## 专用推理 Dedicated Inference

### 按 GPU 运行时间计费

[Dedicated Inference](https://www.digitalocean.com/blog/dedicated-inference-technical-deep-dive) 为你提供一个私有、单租户的 GPU 端点——一台 DigitalOcean 为你管理的云端专属推理服务器。没有其他人与你共享 GPU。你可以选择 GPU 类型（H100、H200、B300、MI300、MI325 等）、选择模型，获得一个完全属于你的专属 HTTPS 端点。

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

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

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

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

### 最佳适用场景

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

### 关键特性

- 单租户、私有 GPU 实例
- 无冷启动，始终保持热备
- 支持[自带模型（BYOM）](https://www.digitalocean.com/blog/powering-the-inference-era)用于微调 LLM
- 通过加速器和节点配置控制扩缩容行为
- 独立的 DI 访问令牌（出于安全考虑，有意与通用 DO API 令牌区分）

### 快速开始

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

### 真实案例

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



## 批量推理 Batch Inference

### 成本显著低于实时推理

[Batch Inference](https://docs.digitalocean.com/products/inference/how-to/use-batch-inference/) 适用于你有大量工作要做、但没有任何任务需要立即完成的情况。你不需要一个一个发送请求并等待每个响应，而是将所有内容打包成 JSONL 文件，作为单一任务提交，然后在完成后回来取结果，通常在 24 小时内。

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

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

### 最佳适用场景

- 大规模文档分类
- 隔夜数据富化管道
- 针对大型测试集运行模型评估套件
- 构建 [RAG 知识库](https://www.digitalocean.com/resources/articles/rag) 索引
- 对大型文本语料库进行情感分析或实体提取

### 关键特性

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

### 三步工作流程

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

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

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

### 真实案例

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



## 推理路由 Inference Router

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

[Inference Router](https://docs.digitalocean.com/products/inference/how-to/use-inference-router/) 位于你的模型前方，自动根据任务类型、当前延迟和成本决定每个传入请求应由哪个模型处理。路由不再将每个请求都发送到最昂贵的前沿模型，而是将复杂度与能力匹配。

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

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

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

### 最佳适用场景

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

### 关键特性

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

### 快速开始

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

### 真实案例

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



## 四种模式横向对比

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



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

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

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

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

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

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

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

### 典型演进路径

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

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

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



## 指标和盈亏平衡清单

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

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



## 快速入门链接

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

- **推理引擎控制台：** [cloud.digitalocean.com/model-studio](https://cloud.digitalocean.com/model-studio)
- **完整文档：** [docs.digitalocean.com/products/inference](https://docs.digitalocean.com/products/inference/)
- **Serverless 快速入门：** [使用 Serverless Inference](https://docs.digitalocean.com/products/inference/how-to/use-serverless-inference/)
- **Dedicated 快速入门：** [使用 Dedicated Inference](https://docs.digitalocean.com/products/inference/how-to/use-dedicated-inference/)
- **Batch 快速入门：** [使用 Batch Inference](https://docs.digitalocean.com/products/inference/how-to/use-batch-inference/)
- **Router 快速入门：** [使用 Inference Router](https://docs.digitalocean.com/products/inference/how-to/use-inference-router/)
- **定价详情：** [推理定价](https://docs.digitalocean.com/products/inference/details/pricing/)
- **API 参考：** [DigitalOcean AI Inference API](https://docs.digitalocean.com/products/inference/reference/api/)



## 常见问题

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

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

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

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

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

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

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

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

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

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



## 结语

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



## 相关链接

- [DigitalOcean 推理引擎官方文档](https://docs.digitalocean.com/products/inference/)
- [Serverless Inference 产品页](https://www.digitalocean.com/products/inference-engine)
- [Dedicated Inference 技术深度解析](https://www.digitalocean.com/blog/dedicated-inference-technical-deep-dive)
- [推理时代：DigitalOcean AI 原生云内部解读](https://blog.aidroplet.com/product-updates/powering-the-inference-era/)


large_images (2).jpeg

medium_images (2).jpeg

small_images (2).jpeg

thumbnail_images (2).jpeg

xsmall_images (2).jpeg

images (2).jpeg

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

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



近日，[DigitalOcean App Platform（应用托管）](https://www.aidroplet.com/product/app-platform/) 上基于请求的自动伸缩功能现已正式推出。你的应用现在可以根据实时的 HTTP 流量信号（每秒请求数和 P95 响应延迟）自动扩缩容，让你的基础设施对实际正在发生的事情做出反应，而不是对几分钟前的事情做出反应。

## 现已支持共享和专用 CPU 实例

到目前为止，App Platform（应用托管）上的自动伸缩需要[专用 CPU 服务器计划](https://www.aidroplet.com/product/cpu-optimized/)。这意味着相当一部分 App Platform 用户（所有运行在共享 CPU 实例上的用户）完全没有自动水平伸缩的途径。

今天，这一切改变了。基于请求的自动伸缩同时适用于共享和专用 CPU 实例。无论你是在共享计划上运行一个早期项目，还是在专用资源上运行一个高吞吐量的生产服务，现在都可以配置自动伸缩来匹配你的流量——无需升级计划。

### 更快速、更灵敏的伸缩

基于 CPU 的自动伸缩本质上是反应式的。CPU 是一个滞后指标：在伸缩器知道有问题之前，你的容器必须已经明显挣扎，而到那时，你的用户已经在等待了。

基于请求的自动伸缩则依据真正反映用户体验的信号来行动：

- **每实例每秒请求数**：每个容器当前正在处理多少请求
- **P95 请求延迟**：95% 的用户正在经历的响应时间


当流量上升并且任一阈值被超过时，新容器会立即启动。当负载下降并且所有指标都回到目标值以下时，伸缩器会将容器缩减回去。你能更快地获得所需的容量余量，并且只为实际使用量付费。

在专用计划上，你还可以结合使用基于请求和基于 CPU 的指标。当*任何*配置的阈值被越过时，自动伸缩器都会扩容，只有当*所有*指标都回到范围内时才会缩容。

### 设置阈值前，先了解你的基线

配置良好的自动伸缩阈值始于理解你的正常流量模式。App Platform 控制台中的 **Insights 标签页** 正好能给你这个。

![App Platform - Image 1 - 5.22.png](https://blog.aidroplet.com/uploads/App_Platform_Image_1_5_22_cc83477fbc.png)

Insights 标签页随时间展示 **HTTP 入口请求速率**（每秒请求数）和 **HTTP 入口请求持续时间 P95**（你的 95 分位延迟）。在调整你的自动伸缩规则之前，利用这些信息来了解你的服务在正常负载下的行为。

## 如何配置基于请求的自动伸缩

### 使用控制面板

前往云后台的 [Apps 页面](https://cloud.digitalocean.com/apps)，选择你的应用，打开 **Settings** 标签，然后选择你的 web 服务组件。在 **Resource Size** 部分，点击 **Edit**。

选择 **Shared CPU** 或 **Dedicated CPU** 标签。在 **Scaling** 下，将 **Autoscale** 开关打开。设置你的 **Minimum Containers** 和 **Maximum Containers**，然后至少配置一条自动伸缩规则：

![App Platform - Image 2 - 5.22.png](https://blog.aidroplet.com/uploads/App_Platform_Image_2_5_22_0da97c2717.png)

- **按每秒请求数伸缩**：设置每实例目标 RPS
- **按响应时间和速度（P95）伸缩**：设置以毫秒为单位的目标 P95 延迟
- **按 CPU 使用率阈值伸缩**：适用于专用 CPU 计划


点击 **Save**。自动触发重新部署，你的应用便开始自动伸缩。

### 使用应用规格（App Spec）

在你的应用规格中，为服务组件添加一个自动伸缩块。下面的示例在 1 到 10 个容器之间伸缩，目标为每实例每秒 100 个请求和 500 毫秒的 P95 延迟：

```

name: my-app

services:

- name: web

  github:

    repo: your-org/your-repo

    branch: main

  autoscaling:

    min_instance_count: 1

    max_instance_count: 10

    metrics:

      requests_per_second:

        per_instance: 100

      request_duration:

        p95_milliseconds: 500

```

通过 doctl apps update 或 [Apps API](https://docs.digitalocean.com/reference/api/reference/apps/) 提交更新后的应用规格。你可以随时调整这些值——如果你的服务比你期望的更早开始伸缩，就提高目标值；如果在新的容器到达之前就已经看到延迟，就降低目标值。

**几点注意事项：**

- 基于请求的自动伸缩适用于接收外部 HTTP 流量的 **web 服务组件**。Worker 和函数组件不适用。
    
- 它不能与同一服务上的 **缩容至零**（闲置休眠）同时使用。
    
- 伸缩决策基于 5 分钟的速率窗口，因此自动伸缩器响应的是持续性负载，而不是瞬间尖峰。
    

## 开始使用基于请求的自动伸缩

你的流量不会按日程表到来，你的伸缩也不该如此。基于请求的自动伸缩现已在所有 DigitalOcean 账户上可用。前往 Insights 标签页了解你的流量模式，然后直接在控制台或通过应用规格配置你的自动伸缩规则。

App Platform 现在支持基于实时 HTTP 请求数和 P95 延迟的自动伸缩，共享和专用 CPU 实例均可使用。

DigitalOcean App Platform 基于请求的自动伸缩功能现已正式上线



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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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



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

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

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

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

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

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

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

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


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

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

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

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

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



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

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

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

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

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


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

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

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

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

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

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

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

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



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

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

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


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

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



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

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



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

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

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

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

**最后的话：**

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

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

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

large_images (16).png

medium_images (16).png

small_images (16).png

thumbnail_images (16).png

xsmall_images (16).png

images (16).png

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 数字背后的工程

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

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

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

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

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

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

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

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

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

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

## 真实世界的性能

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

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

## 前进之路：扩展智能

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

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

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


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

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

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

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

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

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

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

## 1. 权限开通


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

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


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

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

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


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

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

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

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

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

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

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

模型ID: claude-opus-4-7

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

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

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

预期结果：

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

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

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


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

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

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

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

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

模型ID：anthropic-claude-opus-4.7

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

预期结果

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

## 4. 安装配置Claude Code

### 安装Claude code


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

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

  

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


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

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

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

  

### 启动Claude Code


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

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

```Plain
claude /logout
```

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

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

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

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

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

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

  

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


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

### 安装Claude code

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

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

### 打开Claude Code Extension的设置

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

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

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

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

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

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

最终如下

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

测试一下：

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

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

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

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

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

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

## 前提条件

开始之前，你需要准备：

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

## 第 1 步 - 从 Marketplace 创建 Droplet

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

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

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

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

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

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

Droplet 就绪后，用 SSH 连上去：

```
ssh root@your_server_ip
```

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

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

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

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

### 沙箱名称

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

### NVIDIA API Key

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

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

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

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

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

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

### 策略预设

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

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

在底部，向导会问：

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

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

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

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

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

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

## 第 4 步 - 连接 NemoClaw

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

```
nemoclaw my-assistant connect
```

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

```
openclaw tui
```

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

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

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

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

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

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

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

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

```
nemoclaw my-assistant connect
```

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

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

## 下一步做什么

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

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

small_0_bInE0mjf_zoaE4Db.webp

thumbnail_0_bInE0mjf_zoaE4Db.webp

xsmall_0_bInE0mjf_zoaE4Db.webp

0_bInE0mjf_zoaE4Db.webp

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

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

large_gpu-fleet-1.png

medium_gpu-fleet-1.png

small_gpu-fleet-1.png

thumbnail_gpu-fleet-1.png

xsmall_gpu-fleet-1.png

gpu-fleet-1.png

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

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

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

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

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

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

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



## 真正的问题是碎片化

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

## 胶水代码的隐性成本

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

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

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

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

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

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

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

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

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

## 用 DigitalOcean 重新定义问题

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

## 结论

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

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

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

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

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

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

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

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



## 解决常见安全挑战

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

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

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



## 云安全态势管理功能

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

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

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



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

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

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

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

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

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

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


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

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

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

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

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

## 核心要点

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

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

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

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

## 什么是推理即服务？

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

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

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

 

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

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

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

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

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

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

## 推理即服务的好处

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

**部署更快**

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

**可扩展**

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

**基础设施优化**

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

**模型可访问性**

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

**初期成本节省**

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

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

## 推理即服务怎么工作

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

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

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

### 2. API 端点创建

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

### 3. 输入数据提交

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

```json
POST /v1/chat/completions

{

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

  "messages": [

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

  ]

}
```

### 4. 预处理

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

### 5. 推理执行

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

### 6. 后处理和输出

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

```json
{

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

}
```

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

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

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

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

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

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

**GPU 加速可用性**

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

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

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

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

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

**扩展和流量管理**

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 常见问题

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

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


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

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


**推理需要 GPU 吗？**

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


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

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

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

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

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

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

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

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

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

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

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

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

large_WX20250721-151435@2x.png

medium_WX20250721-151435@2x.png

small_WX20250721-151435@2x.png

thumbnail_WX20250721-151435@2x.png

xlarge_WX20250721-151435@2x.png

xsmall_WX20250721-151435@2x.png

WX20250721-151435@2x.png

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

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

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

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

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

## 操作步骤


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

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

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

### Continue插件配置


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

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

  

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

  

**配置Continue插件**

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

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

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

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

配置文件如下：

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

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

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

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

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

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

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

  

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

  

### Kilo Code插件配置


搜索并安装Kilo插件

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

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

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

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

API 提供商：OpenAI Compatible

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

API密钥：DO平台Model Access Key

模型：anthropic-claude-opus-4.6

最大输出Token：128000

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

large_images (11).png

medium_images (11).png

small_images (11).png

thumbnail_images (11).png

xsmall_images (11).png

images (11).png

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

### 前置条件

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

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

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

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

**请求：**

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

**响应要点：**

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

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

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

**请求：**

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

**响应要点：**

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

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

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

**请求：**

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

**响应要点：**

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

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

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

**请求：**

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

**响应要点：**

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

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

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

### 前置条件

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

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

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

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

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

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

输出将显示您的新密钥。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## DigitalOcean Functions 更安全的未来

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

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

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

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

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

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

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

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


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

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

在 DigitalOcean App Platform 上使用 OpenClaw：

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

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

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

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

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

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

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

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

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

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

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

智能体需要保持私有、隔离，并具备状态能力。即使在重启、更新或扩展时也是如此。

DigitalOcean App Platform 上的 OpenClaw 默认满足这些要求：

### 默认私有

- 以后台 worker 运行，没有公共 URL
- 不暴露任何公网入站端口
- 访问仅限于：私有 Tailscale 网络（用于 Web UI），或 DigitalOcean CLI（用于无头操作）

### 强化且可替换的运行环境

- 运行在可替换的容器中，而非长期运行的虚拟机
- 每次部署都从干净、已知状态开始
- 减少配置漂移，降低手动加固和打补丁的需求

### 无需持久服务器的状态持久化

- 配置、会话和智能体记忆可通过用户配置，实时备份到 DigitalOcean Spaces（可选，需额外费用）
- 即使容器是临时的，智能体在重启和更新后仍可保留状态

### 天然隔离设计

- 基于容器和私有网络实现隔离
- 限制配置错误或故障的影响范围
- 随着系统扩展，降低误暴露风险

## 部署模式

App Platform 上的 OpenClaw 支持两种常见的生产部署方式，满足不同团队在进入常驻运行后对访问和运维的需求。

### 使用 Tailscale（支持 Web UI）

如果需要通过 Web 界面配置或监控 OpenClaw，部署会同时运行 Tailscale 服务。你的 OpenClaw 实例会获得一个私有地址（例如 openclaw.your-tailnet.ts.net），且无法从公网访问。

### 无头模式（仅网关）

如果只需要消息网关，不需要 Web UI，可以选择无头部署。容器作为 worker 运行，没有入站端口，默认私有。可以通过 DigitalOcean CLI 查看日志和执行命令：

`doctl apps console <app-id> openclaw`

两种模式都支持通过 DigitalOcean Spaces（用户自行配置）进行状态同步。


## 开始使用

OpenClaw 现已支持在 DigitalOcean App Platform 上运行。你可以通过以下方式部署：

- 使用 GitHub 模板仓库中的 Deploy-to-DigitalOcean 按钮
- 通过 App Platform 控制台
- 或使用 [doctl](https://docs.digitalocean.com/reference/doctl/reference/) 从你的 Git 仓库部署

如果需要详细步骤，可以参考 OpenClaw 官方教程。对于更复杂的使用场景，可能需要额外配置，但 App Platform 已提供一个快速且安全的生产环境起点。


## 不确定该选择哪种 OpenClaw 部署方式？

### 一键部署 OpenClaw 到 Droplet 服务器

适合实验、学习 OpenClaw，或需要完整虚拟机控制和手动管理基础设施的场景。

### 在 App Platform 上运行 OpenClaw

适合希望实现弹性扩展、简化运维、并保持成本可预测的团队。尤其适用于从单一智能体扩展到多智能体的场景。

以上两种方案基于相同的 OpenClaw 架构。区别在于，随着系统规模扩大，你会承担的运维工作量不同。

---
 相关阅读：
 
 - [Moltbot/Clawdbot是什么？如何在云服务器部署 Moltbot/Clawdbot？](https://blog.aidroplet.com/tutorials/Clawdbot-quickstart-guide/)
 - [不用海外卡、不怕封号，OpenClaw 稳定跑 Claude / GPT 的最简单方法](https://blog.aidroplet.com/tutorials/openclaw-use-claude-or-GPT/)
 - [教程：让OpenClaw一次接入Claude、Qwen、DeepSeek 多个模型](https://blog.aidroplet.com/tutorials/openclaw-multiple-model/)
 - [使用 DigitalOcean 实现 Claude Code “低配订阅 + 外部 Token”](https://blog.aidroplet.com/tutorials/claude-code-gradient-connect/)

large_images (19).png

medium_images (19).png

small_images (19).png

thumbnail_images (19).png

xsmall_images (19).png

images (19).png

当 AI 助手开始“常驻运行”，真正的难题才刚刚出现——你准备好了吗？

OpenClaw 多智能体部署：弹性扩展、零运维 

本文将介绍，如何在本地安装的Openclaw中，使用DigitalOcean GradientAI 的Key配置大模型。可用的大模型包括：Claude opus、Claude Sonnet、gtp-oss、Kimi、DeepSeek、Qwen、MiniMax，以及 NVIDIA Dynamo 1.0等数十种大模型。本文中介绍的API 接入方法，对云端部署的Openclaw同样适用。


## 必要条件

1.确认已经安装好Openclaw（本地或云端皆适用）

2.注册Digitalocean账号，[创建Gradient Access Key](https://blog.aidroplet.com/tutorials/serverless-inference-gradient/)。方法见卓普云官网博客。

## 开始配置

1.打开终端，输入 openclaw configure , 激活Openclaw的配置

2.使用键盘方向键，选择 model

![1280X1280.PNG](https://blog.aidroplet.com/uploads/1280_X1280_0256964eb2.PNG)

3.Model /auth provider 选择 Custom Provider

![1280X1280 (1).PNG](https://blog.aidroplet.com/uploads/1280_X1280_1_d57e91c29e.PNG)

4.配置按照下图填写


API Base URL：https://inference.do-ai.run/v1

Paste API key now ： 把你的DigitalOcean Gradietn Serverless Inference Access Key 粘贴在这里。

![3.PNG](https://blog.aidroplet.com/uploads/3_3f1463c9fb.PNG)

5.完整配置如图
 
![4.PNG](https://blog.aidroplet.com/uploads/4_cc21506e78.PNG)

这里填写的 Model ID，可参考DigitalOcean 英文文档，按照对照表选择你需要的model。

https://docs.digitalocean.com/products/gradient-ai-platform/details/models/#foundation-models-deepseek

![Pasted image 20260327100914.png](https://blog.aidroplet.com/uploads/Pasted_image_20260327100914_77e76c3377.png)


6.验证成功

![6.png](https://blog.aidroplet.com/uploads/6_42691cd5a5.png)

7.可以重复以上步骤，添加多种模型。


此时，你的Openclaw已经成功接入了DigitalOcean GradientAI平台。将会使用GradientAI来管理所有token调用。

注意，**新注册**的账号可能部分模型调用会被限制，系统会提示401报错，如遇到这类情况，请联系[卓普云（aidroplet.com）](https://www.aidroplet.com/)申请解除限制。

---
相关阅读：

- [多个 OpenClaw 智能体部署：弹性扩展、零运维](https://blog.aidroplet.com/product-updates/openclaw-digitalocean-app-platform/)
- [Moltbot/Clawdbot是什么？如何在云服务器部署 Moltbot/Clawdbot？](https://blog.aidroplet.com/tutorials/Clawdbot-quickstart-guide/)
- [不用海外卡、不怕封号，OpenClaw 稳定跑 Claude / GPT 的最简单方法](https://blog.aidroplet.com/tutorials/openclaw-use-claude-or-GPT/)
- [使用 DigitalOcean 实现 Claude Code “低配订阅 + 外部 Token”](https://blog.aidroplet.com/tutorials/claude-code-gradient-connect/)




large_17738226706ddb.png

medium_17738226706ddb.png

small_17738226706ddb.png

thumbnail_17738226706ddb.png

xsmall_17738226706ddb.png

17738226706ddb.png

不论是本地龙虾还是云端龙虾，都可以轻松接入多个模型。

教程：让OpenClaw一次接入Claude、Qwen、DeepSeek 多个模型

无服务器推理理所当然地成为人工智能用户技术圈和非技术圈最热门的话题之一，这背后有其充分理由。虽然部署自定义模型通常需要控制部署的方方面面，但无服务器技术免去了维护和管理模型部署及 API 端点的麻烦。这对于众多不同的智能体大语言模型用例来说，可能极为有用。

在本教程中，我们将展示如何使用 DigitalOcean  [Gradient Platform](https://www.aidroplet.com/product/serverless-inference/) 无服务器推理 API。之后，我们将讨论该方法在生产环境和日常工作流程中的一些潜在用例。

## 在 Gradient 平台上访问无服务器推理

首先，我们可以使用 DigitalOcean API 或云[控制台](https://cloud.digitalocean.com/)。让我们来看看这两种方法。

### 步骤 1A：创建 DigitalOcean API 密钥

首先，你需要创建自己的 DigitalOcean 帐户并登录。完成后，导航到你选择的团队空间。在这里，我们将创建一个 DigitalOcean API 密钥。这稍后将帮助我们创建模型访问Token，所以我们可以跳过此步骤，直接进入“步骤 2b：使用云控制台创建模型访问密钥”部分。

使用主页左侧的导航栏，向下滚动直到看到“[API](https://cloud.digitalocean.com/account/api/tokens)”。点击进入 API 主页。然后我们可以使用右上角的按钮创建一个新密钥。

![Pasted image 20260326144033.png](https://blog.aidroplet.com/uploads/Pasted_image_20260326144033_646b4af333.png)

在密钥创建页面，根据需要为你的密钥命名并授予适当的权限。为此，你可以授予完全权限，或者在自定义范围选择中向下滚动到“genai”并全选。然后，创建密钥。保存此值以备后用。

注意：新注册用户建议可以先使用 qwen 模型，把API跑通。再更换model ID使用其他模型。目前 Opus 4.6、GPT 5.2等高级模型，对新注册账号是不开通权限的。如果新注册用户想使用，可联系[卓普云](https://www.aidroplet.com/)来申请解除限制。

### 步骤 2A：使用 API 创建模型访问密钥

接下来，我们将为 Gradient 的无服务器推理创建模型访问密钥。为此，我们可以使用控制台或 API。要使用 API，请使用之前保存的 API 密钥，在终端中执行以下 curl 请求。将“$DIGITALOCEAN_TOKEN”的值替换为你自己的。

```
curl -X POST -H 'Authorization: Bearer $DIGITALOCEAN_TOKEN' https://api.digitalocean.com/v2/gen-ai/models/api_keys
```

这将输出我们的模型访问密钥。保存此值以备后用。我们在查询模型时会需要它。

### 步骤 2B：使用云控制台创建模型访问密钥

![Screenshot 2025-05-28 at 10.20.12 AM.png](https://blog.aidroplet.com/uploads/Screenshot_2025_05_28_at_10_20_12_AM_88f5e2646b.png)

如果我们想使用控制台，只需在控制台中导航到 Gradient 平台的“Serverless Inference”选项卡。到达后，使用右下角的按钮“Create model access key”。

![Screenshot 2025-05-28 at 10.44.53 AM.png](https://blog.aidroplet.com/uploads/Screenshot_2025_05_28_at_10_44_53_AM_2a86741797.png)

然后，我们只需为密钥命名。保存输出的值以备后用！我们稍后在 Python 中进行无服务器推理时会需要它。

### 步骤 3：使用 Python 和无服务器推理生成文本

有了新的模型访问密钥，我们就可以从任何能访问互联网的机器上开始运行 DigitalOcean 无服务器推理了！我们建议使用 Jupyter Notebook。按照本[教程](https://blog.aidroplet.com/tutorials/do-gpu-jupyter-dl-setup/)中概述的步骤，为本文设置你的环境。

环境设置好后，打开一个新的 .ipynb IPython Notebook 文件。使用下面的代码片段开始生成文本，具体来说，是回答法国首都是什么。编辑代码片段，将第 5 行的 API 密钥值替换为你自己的。

```
from openai import OpenAI
import os

client = OpenAI(
    api_key= **“你的模型访问密钥”**,
    base_url="https://inference.do-ai.run/v1"
)

stream = client.chat.completions.create(
    model="llama3-8b-instruct",
    messages=[
        {
            "role": "developer",
            "content": "你是一个乐于助人的助手。",
        },
        {
            "role": "user",
            "content": "法国的首都是什么？",
        },
    ],
    stream=True,
    max_completion_tokens=10
)

for chunk in stream:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)
```

这应该会输出“法国的首都是巴黎”。我们建议根据需要更改诸如 `max_completion_tokens` 之类的值，以更好地适应你的提示词。我们还可以编辑第 10 行的模型值，将其更改为 DigitalOcean Gradient 模型产品中列出的任何可用模型。这个模型库会不断更新以反映行业的发展，所以请经常回来查看更新。

## DigitalOcean 无服务器 AI 的用例

现在我们已经设置好了运行无服务器推理的环境，我们可以使用该模型进行大量的活动。从大语言模型所能做的一切出发，我们可以创建强大的智能体应用程序，利用 AI 模型的优势。一些可能的用例包括：

- 事件驱动型应用程序：特定事件触发大语言模型的运行，这在智能体用例中很常见
- 可扩展的后端服务：当后端的推理可能需要无限扩展时，无服务器可以确保你的用户永远不会等待
- 数据处理：批处理作业和数据处理可以有效且高效地处理，而无需昂贵的服务器配置置 

## 结语

对于寻求基于大语言模型的解决方案，但又不想费心聘请人员或学习部署自己服务器所需步骤的公司来说，无服务器推理是一个真正的答案。借助 DigitalOcean 的 Gradient Platform，从强大的 NVIDIA GPU 访问无服务器推理变得比以往任何时候都更容易！我们鼓励大家尝试这个新的解决方案！

感谢你与 DigitalOcean 社区一起学习。查看我们提供的计算、存储、网络和托管数据库产品，或新注册的用户希望使用 DigitalOcean Gradient AI 平台上的 Opus 4.6、GPT 5.2等高级模型，可直接联系[卓普云（aidroplet.com）](https://www.aidroplet.com/)。

只需要两步就可以调用 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 厂商认证的稳定网络连接

承载 1.8 亿次互动：Hippocratic AI 联合 DigitalOcean 升级下一代 AI 原生推理架构

产品更新

既要 LLM 推理性能可预测，又要成本可控？专用推理了解一下

AI 正在变成智能体，传统云不够用了：DigitalOcean 的新解法

DigitalOcean 打造 AI 原生云，帮助 AI 应用大幅降低成本与运维复杂度

DigitalOcean 收购 Katanemo Labs：迎接 Agent 时代，重塑基础设施

教程

2026 AI 下半场变天：从 GPU 狂热到 CPU 翻倍，未入局的企业如何全面部署 AI Agent？

狂热的 GPU 背后：为什么苏姿丰的 1200 亿美金预言里，主角是 CPU？

Token聚合平台 vs 传统云 vs AI原生云，AI推理应用怎么选？

实战指南：AI调用成本降71%——利用“推理路由”告别大模型胡乱开销

新闻

承载 1.8 亿次互动：Hippocratic AI 联合 DigitalOcean 升级下一代 AI 原生推理架构

DigitalOcean 助力 ACE Studio：推理延迟降40%，训练效率翻倍

DigitalOcean 助力 Bright Data 构建高稳定数据平台

当所有人都在讨论 AI 工具时，我们已经用 AI 跑通了一家公司