AI 应用成本怎么算？从推理费用到完整 TCO 拆解

一位技术负责人在评估不同平台之前，问了一个很合理的问题：

"哪家推理平台的 Token 单价最低？"

但这个问题其实问得不够完整。

并不是说 Token 价格不重要------它当然重要------而是因为 Token 费用只是整张账单里的其中一项，而一套完整的 AI 应用账单通常还有七八项。

推理费用在总成本里究竟占多大比例，完全取决于你的架构，而且不同架构之间的差异可能非常大。

在本文后面的自下而上成本模型中，对于一个整套基础设施都集中在单一云平台 上的 RAG 应用，推理费用占总成本的 81% ；而把完全相同的工作负载拆到两个平台 之后，推理费用只占 34%。

在云厂商和行业分析师的讨论中，你可能经常听到这样一个经验数字：

"推理成本通常占 AI 应用总成本的 30%～50%。"

这个数字描述的其实更接近第二种情况：使用多平台架构、运行多步骤 Agent 工作负载的系统。在这类架构中，模型调用之外还会叠加大量基础设施费用和运维开销。

但它并不能代表一个简单、集中部署的应用。在这种架构下，模型调用确实可能就是整张账单中最大的一部分。

从两个完全不同的方向出发，这两组数字其实都指向同一个结论：

除了推理之外，后端计算、向量数据库、对象存储、容器编排、网络、可观测性，以及工程团队为了把三四个平台的账号、计费、权限和服务连接起来所投入的时间成本，都不可能是零。

而在很多团队最终采用的实际架构中，这些非推理成本加起来甚至会成为大头。

但这些成本，没有一项会出现在简单的"$/百万 Token"价格对比表中。

本文要做的，就是把整张账单摊开来看：一个真正投入生产的 AI 应用，从模型到基础设施完整运行下来究竟要花多少钱，以及 DigitalOcean 的全栈式产品布局为什么可能带来结构性的成本优势。

Token 价格表只是账单中的一行，不是整张账单

你在网上看到的大多数公开 LLM 价格对比，大致都会长这样。

为了避免把不同档次的模型混在一起比较，这里选择的是同一个开放权重模型 Llama 3.3 70B，比较它在不同 Serverless 推理平台上的价格：

平台	输入（$/百万 Token）	输出（$/百万 Token）
Groq	$0.59	$0.79
DigitalOcean	$0.65	$0.65
Fireworks AI	$0.90	$0.90
Together AI	$1.04	$1.04

注：以上为 Llama 3.3 70B 的 Serverless 公开价格，按每 100 万 Token 计费，数据采集于 2026 年 6 月。其中 DigitalOcean 的 $0.65 价格已于 2026 年 8 月再次根据官方定价文档确认：Groq、DigitalOcean、Fireworks、Together。

这些价格只是采集当时的公开价格，而且变化速度很快。例如在 2026 年第二季度，Together 对这个模型的公开价格就从 $0.88上调到了0.88 上调到了$ 0.88上调到了1.04。因此，应当把这张表视为某个时间点的快照，而不是长期不变的常量。在真正做预算之前，最好重新查看每个平台的官方定价页面。

只看这张表，它本身没有错。

但这种比较有点像租房时只看租金，却不看水电、停车费、网费，甚至不管房子的暖气能不能正常使用。

最醒目的价格看起来很清楚，但真正每个月掏出去的钱通常远不止这些。

一个投入生产的 AI 应用通常还需要：

推理端点（Serverless 或 Dedicated）
后端应用服务器，也就是计算资源
用于检索和语义搜索的向量数据库
用于保存文档、训练数据和日志的对象存储
用于部署的容器编排系统
VPC 网络、负载均衡和 TLS 终止
监控、告警和可观测性系统

如果你把这些组件分散到不同平台上，例如推理使用 Together、Fireworks 或 Groq，而计算、数据库和存储继续放在 AWS，那么除了基础设施本身的费用，还要额外面对多套账号和账单、跨平台网络与公网出站流量，以及不同平台之间集成和维护所消耗的工程时间。

这些东西，全都不会出现在每百万 Token 的价格比较里。

一个生产级 RAG 应用横跨七层架构，推理只是其中一层

为了更具体一点，我们用一个比较典型的架构举例：

一个基于 RAG 的 AI 应用，每个月处理 100 万次请求，同时拥有文档知识库、多轮对话历史和监控系统。

如果把这些组件对应到 DigitalOcean，大致如下：

层级	功能	DigitalOcean 对应产品
推理	LLM API 调用	无服务器推理（Serverless Inference）或专用推理（Dedicated Inference）
应用层	业务逻辑、API 网关	Droplets 云服务器或应用托管（App Platform）
向量数据库	语义搜索、RAG 检索	OpenSearch托管数据库或 PostgreSQL + pgvector
对象存储	文档、Embedding、日志	DigitalOcean Spaces对象存储
容器编排	部署、扩缩容、健康检查	DOKS（Kubernetes）
网络	VPC、负载均衡、DNS	Droplets独享云主机、Firewalls、负载均衡、DNS
可观测性	指标、日志、告警	Monitoring

在超大规模云平台或者多平台架构中，这些层级可能分别存在于不同的计费后台。而在 DigitalOcean 上，它们可以集中在一个账号、一个 VPC 和一张账单里。

从 Serverless 开始，只有利用率足够高时再转向 Dedicated

上面提到的推理层，实际上有三种主要部署方式，而应该选择哪一种，取决于你的流量形态。

无服务器推理（Serverless Inference，按 Token 计费） ------ 适合波动较大或突发性的流量、稳定但处于中低规模的请求量，以及所有希望避免闲置成本的场景。使用多少 Token 就付多少费用，没有请求时基本没有闲置推理成本。对于绝大多数应用以及所有非生产环境，它都应该是默认选择。
专用推理（Dedicated Inference，按 GPU 小时计费） ------ 适合高吞吐、持续稳定且能够预测的工作负载。当预留 GPU 的每小时成本除以实际吞吐之后，已经低于按 Token 计费时，就可以考虑 Dedicated。它也适合 Serverless 模型目录之外的模型，包括自行导入的 BYOM 权重。需要注意的是，目前托管式 Dedicated Inference 只运行在北美数据中心（截至 2026 年 8 月为 NYC2、TOR1、ATL1 和 RIC1）。
批量推理（Batch Inference，异步处理，最高优惠 50%） ------ 适合能够接受较高延迟的大规模批处理任务，比如文档处理、模型评估和夜间数据分析，这类任务可以接受最长 24 小时的完成窗口。根据官方价格文档，目前 Batch 折扣适用于 OpenAI 和 Anthropic 模型。

一个简单的经验原则是：先从 Serverless 开始；当稳定的大规模流量让预留 GPU 比按 Token 计费更便宜时，再迁移到 Dedicated；可以异步完成的 OpenAI 和 Anthropic 工作负载则尽量交给 Batch。

我们曾发过的《AI 推理引擎四大模式：无服务推理、专用推理、批量推理与智能路由，怎么选》和 Dedicated vs Serverless Inference as You Scale 两篇文章都详细计算了这种成本临界点。

真正容易踩坑的是：太早选择专用推理。

预留 GPU 不管你有没有流量，都是一天 24 小时持续计费。

所以，如果实际 GPU 利用率只有 10%，那么为了换取一张固定的 GPU 账单，你实际上可能正在支付相当于正常每 Token 成本 10 倍的有效价格。

同一个 Agent，6.8 万、8.5 万和 11 万美元

DigitalOcean 在 Deploy 2026 大会上发布了一组 TCO 对比数据，可以参考我们在卓普云官网的发布文章。

测试对象是一个典型的生产工作负载：每个月处理 100 万次预订的企业差旅 Agent。

这个 Agent 需要执行多轮推理、文档检索、实时价格查询以及合规日志记录。

每月成本对比如下：

平台	每月成本
DigitalOcean AI-Native Cloud	$67,727
Baseten + AWS	$84,827
AWS AgentCore	$110,337

以上是 DigitalOcean 在 Deploy 2026 公布的企业差旅 Agent TCO 对比，该场景每个月处理 100 万次预订。这些数字由厂商发布，因此更适合作为计算起点，而不应该直接当成最终结论。真正评估时，仍然应该根据自己的实际工作负载重新建立成本模型。

在这一工作负载下，DigitalOcean 的成本比 Baseten + AWS 低 20%，比 AWS AgentCore 低 39%。

造成这一差距的主要有两个因素。

第一，架构层之间的跨平台数据出站费用。

如果你的推理端点、向量数据库和应用层分别运行在不同平台的网络中，那么这些系统之间的数据传输就可能产生额外的出站流量费用。

而在单一平台架构内部，同一数据中心或私有网络中的流量通常免费，或者费用非常低。

第二，多平台运维带来的额外开销。

跨平台架构意味着工程团队需要维护多套安全配置、多套账单告警、多个技术支持渠道，以及用于连接这些系统的定制集成代码。

这些成本不会出现在每 Token 价格对比中，但最终都会占用工程团队的时间和精力。

需要注意的是，这两个因素都是整个技术栈如何组合带来的成本，而不是某一个具体组件单价的问题。

把多个层集中到同一个云平台，可以减少系统之间的协调工作；而一旦拆分到多个平台，每增加一道边界，就会重新增加一层协调成本。

对于规模较小、架构简单的应用，这种协调成本可能并不明显。

但对于一个多层生产系统，它往往就是成本差距中的主要部分。

同样的一组组件，用两种方式组合。成本表中两列真正的差异，并不是某一个单独组件价格更便宜，而是每增加一个系统边界，都会增加额外的协调成本。

不要直接相信厂商给出的数字：自己算一遍

云厂商提供的 TCO 表格应该被看作一个起点，而不是最终结论。

与其要求你直接相信上面的数字，不如从底层重新建立一个模型，并把所有输入条件都明确列出来。这样，你可以把它复制到电子表格中，并修改任何你不认同的假设。

下面我们使用一个更简单的参考工作负载：

一个每月处理 100 万次请求的 RAG 应用，每次请求大约包含 2,500 个输入 Token 和 600 个输出 Token。

同时，两边使用相同档次的开放权重模型，这样可以把 Token 单价的影响排除掉，重点观察其他成本：

成本项目（每月）	单一平台	多平台
推理（Token）	$2,015	$2,015
应用计算资源	$192	$240
向量数据库 / 搜索	$210	$350
对象存储	$25	$30
编排 + LB + 监控	$60	$110
跨平台数据出站	$0	$135
多平台运维开销（工程师工时）	$0	$3,040
总计	$2,502	$5,920
推理占总成本比例	81%	34%

所有输入条件都列在这里，你可以自己重新计算：推理部分按照每月 100 万次请求 ×（2,500 输入 Token + 600 输出 Token）计算，输入和输出价格均为 0.65美元/百万 Token，即 DigitalOcean Serverless 上的 Llama 3.3 70B，价格来自官方定价文档。因此两种架构中的推理成本完全相同，都是 2,015美元，因为使用的是相同档次的模型。跨平台出站流量按照每月 1,500 GB、0.09美元/GB 计算------这是拆分架构中超大规模云平台一侧常见的第一档公网出站价格------合计 135美元。多平台运维开销按每月 32 个工程师工时计算，即每多维护一个平台每月增加约两天时间，这里额外涉及两个平台，并按照 95美元/小时的综合人工成本计算，共 3,040美元。其余项目使用相同类别基础设施的代表性公开价格。关于向量存储成本的独立比较，可以参考这篇针对 S3、OpenSearch、pgvector 和 Pinecone 的分析。修改任何一项输入，结果都会变化------这恰恰就是这个模型的意义。

结论并不依赖"运维成本"这一项才能成立。

$3,040 显然是整张表里最容易引起争议的数字，所以不妨直接测试一下。

把它完全设为零，假设同时维护两个平台完全不增加任何工程时间，那么仅仅依靠基础设施和出站流量差异，单一平台架构依然能够便宜 13%。

如果把运维成本翻倍，那么两者差距会扩大到 70% 以上。

也就是说，运维成本这个假设决定的是最终差距有多大 ，而不是决定哪种架构更便宜。

再看剩余成本差距来自哪里。

推理这一项完全一样，因为使用的是相同模型。

两边所有差异，全部来自跨平台数据出站，以及同时维护多套平台环境所产生的额外运维成本。

而这两项，恰恰都是 Token 价格表不会告诉你的。

另外，随着业务规模增加，固定的运维成本会逐渐被摊薄。

例如，把请求量提高到每月 500 万次，同时假设非推理基础设施成本基本保持稳定，而推理费用随请求量增长，那么在同一个成本模型下，单一平台架构大约会便宜 24%。

这个结果正好落在 DigitalOcean 公布的 20%～40% 差异区间内。

这张表也解释了文章开头提到的两个看似矛盾的比例。

对于完全相同的工作负载和完全相同的模型，左侧架构中的推理费用占总成本 81%，右侧则只有 34%。

真正改变比例的是整合。

把跨平台数据出站和多平台运维成本去掉之后，推理自然就成为剩余成本中的绝对大头。

因此，人们经常引用的"推理成本占总成本 30%～50%"，实际上描述的是右侧这种架构：一个跨多个平台部署的技术栈，而且通常运行的是多步骤 Agent，每次请求会访问更多基础设施，而不只是完成一次简单的 RAG 检索。

如果有人告诉你"推理占总成本的多少百分比"，却不告诉你这个数字对应的是哪种架构和什么工作负载，那么这个百分比基本没有参考价值。

钱实际上花在了哪里？在多平台架构中，跨平台数据出站和运维成本这两项------它们都不会出现在任何 $/百万 Token 表格中------加起来甚至超过了其他所有基础设施项目。

这里还有两个需要明确说明的限制条件。

首先，这个工作负载比 DigitalOcean 企业差旅 Agent 的场景要更小、更简单。多步骤 Agent 每完成一次预订会调用多个前沿模型，因此绝对成本自然会高得多。

其次，上面已经做过敏感性测试的运维成本，是一个明确可调整的输入参数。之所以把它直接列出来，就是为了让你可以质疑它，并用自己的数据替换。

重点并不是具体差几千美元。

真正重要的是：

那些每 Token 价格比较永远不会展示出来的基础设施层，反而可能最终决定整个成本结果。

全栈整合更适合构建完整应用的团队，而不是简单的 API Wrapper

并不是所有团队都能从全栈式方案中获得同样大的收益。

真正需要理解的是：什么情况下，全栈整合能够创造最大的价值。

价值最明显的场景：

构建完整应用的团队 ------ 包括创业公司和产品团队。他们需要的是整个技术栈，而不是只有一个推理 API。需要解决的集成问题越少，产品上线速度通常就越快。
有欧盟数据驻留要求的团队 ------ DigitalOcean 在基础设施层提供了一种方案：它在阿姆斯特丹运营欧盟 GPU 基础设施，包括 NVIDIA 裸金属 GPU 服务器。因此，目前可以通过在这些基础设施上自行管理模型服务器 实现欧盟境内推理。但这里有两个需要明确说明的限制：DigitalOcean 的 Serverless Inference 目前不能由用户自行选择运行区域；同时，托管式 Dedicated Inference 目前只运行在北美数据中心（NYC2、TOR1、ATL1、RIC1）。以上为截至 2026 年 8 月的可用情况，在根据这些信息进行架构设计之前，请重新检查最新区域列表。
希望降低运维复杂度的团队 ------ 一个 VPC、一套控制平面、一支支持团队。如果基础设施复杂性已经成为团队真正的负担，那么整合带来的价值会比较明显。
每月 AI 基础设施支出在 5 万～50 万美元的中型企业团队 ------ 到这个规模之后，多平台管理产生的运维成本已经不可忽略，但工程团队规模可能还没有大到可以为每个平台都安排专职平台工程师。

价值相对较低的场景：

整个产品实际上只有一次 API 调用的工作负载 ------ 如果你只是给某个前沿模型套了一层很薄的应用，没有向量数据库、没有文档存储，甚至没有什么真正意义上的应用层，那么全栈方案的优势就并不重要。直接选择 DigitalOcean 推理服务中最适合自己业务的模型即可。
必须在新一代前沿模型发布第一天就立即使用的团队 ------ DigitalOcean 的无服务器推理模型目录目前已经覆盖 70 多个模型，其中包括 OpenAI 和 Anthropic 的商业前沿模型，以及多种开放权重模型，并按照与模型提供方相对应的价格计费。

"运维开销"这笔钱到底花在了哪里？

表格中的 $3,040 是最容易被读者质疑的一项，因此有必要明确解释这笔成本到底代表什么。

它不是一种抽象的"生产力损失"。

它对应的是每个月都会真实出现在工程师日程表里的重复性任务，而且这些任务通常随着接入的平台数量增加，而不是随着业务流量增加。

密钥和访问权限轮换会随着平台数量增加。

每多接入一个平台，就意味着多一套需要定期轮换的凭证、多一种需要与其他平台保持一致的 IAM 权限模型，以及审计时需要额外收集的一套日志。

随着请求量增长，这些事情并不会自动变便宜。

这也是为什么在成本模型中，它更像是一项固定成本。

真正消耗工程时间的地方，往往是跨平台故障排查。

假设一次请求在推理端点、向量数据库和应用层之间的某个环节失败，而这三个组件分别放在三个不同账号甚至三个不同平台上。

最耗时间的部分往往不是修复问题。

而是先弄清楚：

到底是哪一层出了问题？

如果所有服务都在一个平台里，可能只需要看一条完整 Trace。

跨三个平台，则意味着三个控制台、三种日志格式、三套日志保留策略，甚至还有三个响应速度完全不同的技术支持队列。

这就是成本模型中每个月 32 个工程师工时所代表的工作。

你完全可以记录自己的团队一个月究竟花了多少时间在这些任务上，然后用真实数字替换它。

同时别忘了前面的敏感性测试：即使把这一项设为零，结论依然成立，只不过两种架构之间的差距会缩小。

用五步建立你自己的 TCO 对比

在文章结束之前，这里给出一个可以直接用于建立自己 TCO（总体拥有成本）模型的方法：

列出应用需要的所有基础设施组件 ------ 不只是推理，还要包括计算、数据库、存储、网络和可观测性。
分别计算这些组件在候选平台上的价格 ------ 记得加入组件之间的数据出站费用。多平台架构会产生这类费用，而单一平台架构通常能够避免其中一部分。
加入工程运维成本 ------ 计算为了集成、维护和排查每一个额外平台所花费的人力时间。哪怕只是粗略假设每多维护一个平台每月需要两天工程师时间，当工程师年薪达到 15 万美元以上时，这一项也足以显著改变成本对比结果。
尽早检查合规要求 ------ 数据驻留、GDPR、SOC 2、HIPAA 等要求可能直接排除部分平台。因此最好在架构设计阶段解决，而不是等到安全审核时才发现。
按照真实的 P95 流量建立模型 ------ 一些推理平台依靠激进的免费额度，在低流量阶段看起来很便宜，但进入生产规模后，单位经济性往往会发生变化。

最终答案并不一定总是支持全栈整合。

但那些在确定架构之前就认真做过这套成本分析的团队，通常在十二个月之后遇到的意外会少得多。

关于这个话题的常见问题

1. 我的 AI 账单中，到底有多少比例是真正的推理成本？

这取决于你的架构，而且区间大到几乎不存在一个可以安全套用到所有场景的统一数字。

在前面的自下而上成本模型中，对于集中在一个平台上的 RAG 应用，推理占总成本的 81% ；把完全相同的工作负载拆到两个平台后，这一比例下降到 34%。

两者之间的差异完全来自跨平台数据出站以及多平台运维成本。

人们经常引用的 30%～50%，描述的通常是运行多步骤 Agent 工作负载的多平台架构。

因此，与其直接套用别人给出的百分比------包括本文的数据------不如根据自己的技术栈逐项列出成本。

2. 我只是在做一个很薄的 API Wrapper，全栈 TCO 对我重要吗？

大多数情况下并不重要。

如果你的产品基本就是调用一次模型 API，没有向量数据库、没有文档存储，也没有什么复杂的应用层，那么推理费用实际上就是你几乎全部的成本。

这时真正需要优化的，就是每 Token 的模型经济性。

在 DigitalOcean 上，这种场景可以直接使用推理引擎：通过 Serverless、按 Token 计费的方式访问超过 70 个模型，其中既包括开放权重模型，也包括 OpenAI 和 Anthropic 的商业模型，并按照与模型提供方相匹配的价格计费，同时没有闲置容量成本。

其中有两个功能对 API Wrapper 尤其有意义：

推理路由器可以按照成本或延迟，把每次请求路由到更适合的模型，而不是在代码中永久固定一个模型。

批量推理（Batch Inference）则可以让能够接受最长 24 小时处理窗口的 OpenAI 和 Anthropic 工作负载最高节省 50%。

当你开始加入检索、持久化对话状态，或者第二个平台时，全栈 TCO 才真正开始变得重要。

3. 运维成本看起来像是拍脑袋算出来的。应该怎么合理估算？

这确实是整个模型中最值得争论的一项，所以我们才把它作为一个独立输入参数，而不是直接藏进总成本里。

比较合理的计算方式是：

统计那些随着平台数量增加而反复发生的工作，包括密钥轮换、IAM / 安全配置、账单核对、跨平台故障排查，以及在 API 发生变化时维护集成代码。

然后实际记录一个月花了多少时间。

大多数团队每多接入一个平台，每个月大约会多出 1～3 个工程师工作日。

然后分别使用你的最低估值和最高估值运行一次模型。

如果两个估值之间会导致最终结论彻底反转，那就说明"运维成本"这个假设对结果影响太大，在做决定之前应该先收集更准确的真实数据。

4. 你的模型说便宜 58%，但 DigitalOcean 公布的数据只有 20%～39%。到底哪个对？

两个都对，只不过对应的工作负载和业务规模不同。

58% 来自一个每月 100 万次请求、规模较小且结构简单的 RAG 应用。

在这个场景中，固定的运维成本相对于整个基础设施账单来说占比较大。

而 DigitalOcean Deploy 2026 使用的是一个多步骤 Agent。这个 Agent 每完成一次预订都会调用多个前沿模型，因此推理费用本身要大得多，固定运维成本在总成本中的比例自然更小。

如果把同一个自下而上的模型扩展到每月 500 万次请求，结果会逐渐收敛到大约 24% 的成本差距，也就是落入 DigitalOcean 公布的范围。

所以两个数字之间的差距来自规模效应，并不矛盾。

5. Serverless 和 Dedicated 到底应该怎么选？

先从无服务器推理开始。

因为闲置容量不会产生费用，而且在业务刚开始时，你也不需要预测自己尚未见过的流量。

只有当稳定吞吐量已经足够高，使预留 GPU 的每小时成本低于对应的按 Token 账单，或者存在其他强制性需求时，才应该迁移到 专用推理。

例如，Serverless 模型目录之外的模型，以及自行导入的 BYOM 权重，都属于这类情况。

能够容忍较高延迟的 OpenAI 和 Anthropic 工作负载，则可以交给批量推理，最高可以把价格降低一半。

一个很常见、也很昂贵的错误，就是为了获得"可预测的固定资源"，过早购买 Dedicated 容量，结果 GPU 利用率长期只有 10%。

总结

Token 价格比较，不等于 TCO 比较。

一套完整 AI 应用最终比单纯的推理账单贵多少，取决于它是怎么搭出来的。

在前面的自下而上模型中，一个集中在单一平台上的 RAG 技术栈，总成本约为推理费用的 1.24 倍 ；而完全相同的工作负载拆到两个平台之后，总成本会达到推理费用的 2.9 倍。

两者之间的差距全部来自计算、存储、网络、数据库、数据出站和运维成本。

而这些项目，没有一个会出现在 $/百万 Token 的价格表中。

Deploy 2026 对一个每月处理 100 万次预订的企业差旅 Agent 给出的 TCO 数据为：

DigitalOcean AI-Native Cloud：$67,727/月
Baseten + AWS：$84,827/月（高 25%）
AWS AgentCore：$110,337/月（高 63%）

全栈架构的优势主要来自三个方面：减少跨平台出站流量费用、降低多平台运维开销，以及只需要维护一套账号和计费体系。

这种优势对构建完整应用的团队、有欧盟数据驻留要求的团队，以及那些已经明显感受到基础设施复杂度压力的中型企业团队最为明显。

更合理的方法是：先列出完整的基础设施组件，在所有候选平台上逐项计算价格，再加入工程团队的运维成本，同时在做架构决策之前提前确认合规要求。

你还可以继续阅读下面这些 系列文章：

参考资料

DigitalOcean 发布面向推理时代打造的 AI-Native Cloud --- Nasdaq / BusinessWire
驱动推理时代：深入了解 DigitalOcean AI-Native Cloud --- DigitalOcean
推理服务定价 --- DigitalOcean Documentation
推理服务区域可用性 --- DigitalOcean Documentation
DigitalOcean Inference 支持的模型 --- DigitalOcean Documentation
Batch Inference API 参考文档 --- DigitalOcean Documentation
如何使用 Inference Router --- DigitalOcean Documentation
DigitalOcean Inference Engine --- DigitalOcean
使用 DigitalOcean AI Platform 运行 Serverless Inference --- DigitalOcean
DigitalOcean Inference Engine 有哪些新功能？ --- DigitalOcean
Serverless、Dedicated 与 Batch Inference 对比 --- DigitalOcean
业务扩展之后，该选择 Dedicated 还是 Serverless Inference？ --- DigitalOcean
DigitalOcean 欧盟裸金属 GPU --- DigitalOcean
向量存储成本对比：S3、OpenSearch、pgvector 与 Pinecone --- Darryl Ruggles