生产AI应用的真实成本：生产中的推理系列

一位技术负责人在供应商评估之前提出了一个合理的问题：“哪家推理提供商的每 token 价格最优？”

这是一个错误的问题，或者至少是不完整的。不是因为 token 定价不重要（它确实重要），而是因为 token 定价只是账单中的一行，而账单有七八行之多。这一行占多大比重完全取决于你的架构，而且差异巨大。在本文后面的自下而上模型中，对于整合的单提供商 RAG 应用，推理占总成本的 81%；而对于在两家提供商之间拆分的相同工作负载，这一比例仅为 34%。你经常在供应商和分析师的对话中听到的经验法则是：“推理占总成本的 30–50%”——这描述的是第二种场景：运行多步骤智能体工作负载的多提供商技术栈，基础设施和运维开销围绕模型调用不断累积。它并不适用于简单、整合的部署，在后一种情况下，模型调用才是账单的大头。

这两个数字从相反的方向指向同一个结论。非推理的各个条目：后端计算、向量数据库、对象存储、容器编排、网络、可观测性，以及花在串联三四个云平台之间计费关系上的工程时间，永远不会是零，而且在大多数团队最终采用的架构中，它们占据了大部分成本。这些统统不会出现在“美元/百万 token”的对比中。

本文构建完整的成本图景，展示一个生产级 AI 应用在整个技术栈上实际运行的成本，以及 DigitalOcean 的全栈定位在哪些方面创造了结构性优势。

• Token 价格对比不等于总拥有成本（TCO）对比。推理成本可能约占总成本的 30% 到 80%，具体取决于架构。在引用任何百分比之前，请先说明你的假设——包括引用 30–50% 这个数字时也不例外。
• 在模型类别不变的前提下，单提供商整合在那些永远不会出现在每 token 美元价格表中的成本上占优：跨提供商出口流量和每家提供商的运维开销。
• DigitalOcean 发布的针对每月 100 万次预订的智能体的 Deploy 2026 分析：约 6.8 万美元/月 vs. 约 8.5 万美元（Baseten+AWS）vs. 约 11 万美元（AWS AgentCore）。
• Serverless（无服务器）是正确的默认选项；只有当预留 GPU 在你的利用率下优于按 token 计费时才迁移到专用实例，并将延迟容忍度高的 OpenAI 和 Anthropic 工作负载转入批处理（最高可节省 50%）。
• 全栈整合对于构建完整应用的团队最为重要；对于 API 封装类产品或已经深度绑定某家超大规模云厂商的团队，重要性则较低。
• 不要轻信任何供应商的 TCO 表格，包括本表。请针对你自己的工作负载自下而上地重建它；下面的模型展示了每一个条目，并标出了真正左右结果的两个关键假设。

你在网上能找到的每一个公开 LLM 定价对比大致都是这个样子。这里，同一个开源模型（Llama 3.3 70B）在不同 serverless 提供商之间定价，因此对比保持了模型类别一致，而不是混搭不同层级：

Llama 3.3 70B serverless 挂牌价，按每百万 token 计，2026 年 6 月抓取（DigitalOcean 的 $0.65 费率已于 2026 年 8 月对照定价文档重新核实）：Groq、DigitalOcean、Fireworks、Together。

这些是抓取时的挂牌价，而且价格变化很快：Together 的这个模型挂牌价在 2026 年第二季度从 $0.88 涨到了 $1.04。请把本表视为一张快照，而不是常量；在把任何数字写进预算之前，请重新核对每家提供商的官方定价页面。

这个对比就其本身而言是准确的。但这就像比较公寓时只列出房租，却忽略水电、停车、网络，以及大楼是否有正常的供暖。表面上的数字看起来很干净，实际上每月的支出要高得多。

一个生产级 AI 应用需要：

• 推理端点（serverless 或专用）
• 后端应用服务器（计算）
• 用于检索和语义搜索的向量数据库
• 用于文档、训练数据、日志的对象存储
• 用于部署的容器编排
• VPC 网络、负载均衡、TLS 终止
• 监控、告警和可观测性技术栈

当你从不同的提供商那里组装这些组件——用纯推理 API（Together、Fireworks、Groq）再加上 AWS 来处理其余一切——你就额外增添了计费关系、跨提供商 VPC 对等连接或互联网出口流量，以及用于集成和维护的工程时间，而这些永远不会出现在“美元/百万 token”的对比中。

让我们用一个代表性的架构来具体说明：一个基于 RAG 的 AI 应用，每月服务 100 万次请求，带有文档知识库、多轮对话历史和监控技术栈。

上述推理线路可通过三种方式提供服务，正确选择取决于流量形态：

• 无服务器（按Token计费） — 适用于波动的或尖峰流量、低到中等的稳定用量，或者任何时候你想要零闲置成本。按Token付费，闲置时不产生费用。这是大多数应用和所有非生产环境的默认选择。
• 专用（按GPU小时计费） — 适用于高、稳定、可预测的用量，此时预留GPU的小时成本除以你的吞吐量低于按Token的费率。这也是无服务器目录之外模型（包括导入的BYOM权重）的路径。请注意，托管的专用推理目前仅在北美数据中心运行（截至2026年8月为NYC2、TOR1、ATL1、RIC1）。
• 批量（异步，最高可享5折） — 适用于可容忍延迟的批量任务（文档处理、评估、夜间分析），这些任务可接受24小时完成窗口。根据定价文档，批处理折扣目前适用于OpenAI和Anthropic模型。

经验法则：以无服务器起步；一旦在你的利用率下预留GPU比按Token计费更便宜，就将稳定的高吞吐流量迁移到专用；将异步的OpenAI和Anthropic任务推送到批量。DigitalOcean的无服务器 vs 专用 vs 批量推理和扩展时的专用 vs 无服务器推理文章详细分析了临界成本计算。

陷阱在于过早选择专用。预留GPU无论是否有流量，每天24小时都在计费，因此在10%利用率下，你支付的有效每Token费率是原来的十倍，只为了换取一张固定账单。

DigitalOcean在Deploy 2026大会上发布了一份TCO对比（参见新闻稿和DigitalOcean自己的发布博文），针对一个具有代表性的生产工作负载：一个每月处理100万次预订的企业差旅预订代理。该工作负载需要多轮推理、文档检索、实时价格查询和合规日志记录。

月度成本对比：

DigitalOcean发布的Deploy 2026 TCO对比，针对每月100万次预订的企业差旅代理。这些是供应商公布的数字——请将其作为参考起点，并根据自己的工作负载重新构建模型。

在此工作负载级别下，DigitalOcean定价比Baseten+AWS低20%，比AWS AgentCore低39%。有两个因素导致了这一差距：

层间出站流量费用。当你的推理端点、向量数据库和应用层位于不同提供商的网络中时，它们之间传输的数据会产生出站流量费用。在单一提供商架构中，数据中心内部流量通常是免费或近乎免费的。

运维开销。运行跨提供商架构意味着工程师需要维护多种安全配置、多种计费告警、多种支持关系，以及用于连接那些本非为协同工作而设计的组件的定制集成代码。这种开销不会出现在按Token对比中，但会体现在工程团队的人力上。

这两个因素都源于技术栈的组装方式，而非任何单个组件的单价。将各层整合到同一提供商上，消除了它们之间的协调工作；将其分散到多个提供商，则会在每个边界重新引入协调成本。在小型、简单的部署中，这种协调成本很小。而在多层生产技术栈中，它是差距中的主导项。

供应商的总拥有成本（TCO）表只是一个起点，而非最终结论。与其让你相信上述数字，这里提供一个自下而上的模型，并列出所有输入项，以便你可以在电子表格中重新构建，并修改你不同意的假设。

它为一个更简单的参考工作负载定价，即一个每月100万次请求的RAG应用（每次约2,500个输入Token / 600个输出Token），两侧使用相同的开放权重模型类别，从而使比较隔离除Token价格之外的所有因素：

所有输入项，以便你可以自行重建：推理费用为100万次请求 ×（2,500输入 + 600输出）Token，按每百万Token输入和输出各$0.65计算——即DigitalOcean无服务器上的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%”这一说法，描述的是右栏的情况，即多提供商堆栈，通常运行多步骤智能体，每个请求会比单个RAG查询触及更多基础设施。如果有人向你引用一个百分比，却不告诉你它来自哪种架构和哪种工作负载，那么这个数字是不可用的。

资金实际去向。在多提供商一栏中，跨提供商出口流量和运营开销（这两者均未出现在任何每百万Token价格表中）比所有基础设施行加起来还要大。

两个实事求是的提醒：这是一个比DigitalOcean的企业旅行代理场景更小、更简单的工作负载（多步骤智能体每次预订都会进行多次前沿模型调用，这就是其绝对数字高得多的原因），而且上述经过压力测试的运营开销行是一个明确、可调整的输入项，恰恰是为了让你能对它提出异议。重点不在于确切的美元数字，而在于每Token比较中永远不会显示的那些层面，正是决定结果的因素。

并非每个团队都能从全栈方法中获得同等收益。了解其创造最大价值的条件：

最适用的场景：

• 构建完整应用的团队——需要全栈的初创公司和产品团队，而不仅仅是一个推理端点。需要解决的集成问题越少，交付速度就越快。
• 有欧盟数据驻留要求的团队 — DigitalOcean的答案位于基础设施层：它在阿姆斯特丹运营欧盟GPU基础设施（NVIDIA裸金属GPU），因此，通过在该基础设施上自行管理模型服务器，如今即可实现欧盟驻留推理。有两个需要坦诚说明的注意点：DigitalOcean的无服务器推理不提供按区域选择的服务，并且托管Dedicated Inference 目前仅在北美数据中心运行（NYC2、TOR1、ATL1、RIC1）。可用性截至2026年8月。在围绕这些进行设计之前，请查看当前区域列表。
• 追求运维简单性的团队 — 单一VPC、单一控制平面、单一支持团队。对于基础设施的复杂性构成实际负担的团队，整合是值得的。
• 每月AI基础设施支出在5万至50万美元之间的中型企业团队 — 在这个规模下，多提供商管理的运维开销不容小觑，但工程团队的规模又不足以配备专门的平台工程师来管理每个供应商关系。

以下情况影响较小：

• 单次API调用就是整个产品的工作负载 — 如果你是在前沿模型之上构建一个轻量封装，没有向量数据库，没有文档存储，也没有真正的应用层，那么全栈方案并不适用。只需为你的用例选择带有最佳模型的DigitalOcean推理引擎。
• 需要在第一时间获得最新前沿模型的团队 — DigitalOcean的无服务器目录现已涵盖70多种模型，包括来自OpenAI和Anthropic的商业前沿模型，以及开放权重模型，按服务商对齐的费率计费。

3,040美元这一行是读者最难以接受的部分，因此有必要明确说明它代表的是什么工作。它不是某种生产力抽象，而是每个月都会落到某人日历上的重复性任务，并且这些任务随提供商数量增加而增加，而不是随流量增长。

密钥和访问权限轮换随提供商数量扩展。 每新增一个提供商，就意味着在轮换计划中再多一套凭据、需要与其他提供商保持一致的另一套IAM模型，以及在审计来临时需要汇聚到同一处的另一份审计日志。这些成本不会随着规模增长而变便宜，这也是它在模型中被视为固定成本的原因。

跨提供商的事件排查才是时间真正花费的地方。 当一个请求在你的推理端点、向量数据库和应用层之间的某处失败，而这三者分布在三个账户中时，慢的不是修复过程，而是确定其中哪个环节出了问题。在单一平台内，这是一条链路；跨越三个平台，则是三个控制台、三种日志格式、三种保留策略，而且往往还有三个响应时间不同的支持队列。

这就是模型按每月32个工程师小时定价的工作。花一个月时间测算你自己版本的任务耗时，并替换为真实数字，同时记住上面的敏感性测试：即使取值为零，结论依然成立，只是优势幅度更小一些。

在得出结论之前，这里有一个构建你自己的TCO比较的实用框架：

1. 列出你的应用程序需要的所有基础设施组件 — 不仅仅是推理，还包括计算、数据库、存储、网络、可观测性
2. 在候选平台上为每个组件定价 — 包括组件之间的出站流量费用，这是多提供商设置会产生、而单一提供商设置可以避免的
3. 加入工程开销 — 用于集成、维护和排查每个额外提供商问题所需的人时。即使粗略估计（每个额外提供商每月2天），在工程薪资15万美元以上的情况下，也会显著改变比较结果
4. 尽早对合规要求进行压力测试 — 数据驻留、GDPR、SOC2、HIPAA要求可能会完全排除某些提供商，而且在架构设计阶段比在安全审查中更容易发现这些问题
5. 按实际的P95流量建模 — 提供慷慨免费额度的推理提供商在低流量时看起来便宜；单位经济性往往在生产规模下发生变化

答案并不总是倾向于全栈整合。但在确定架构之前做了这些分析的团队，十二个月后遇到的意外情况确实更少。

1. 我的AI账单中实际有多大比例是推理？

这取决于你的架构，而且范围很广，引用任何单一数字都是不安全的。在上面的自下而上模型中，对于整合的单一提供商RAG应用，推理占总成本的81%；而对于在两家提供商之间拆分相同工作负载的情况，这一比例为34%，差异完全来自跨提供商的出站流量和每个提供商的运维开销。通常引用的30–50%描述的是运行多步骤代理工作负载的多提供商技术栈。请为你自己的技术栈构建详细的项目清单，而不是采用任何人的百分比，包括本文中的数字。

2. 我在构建一个轻量API封装，全栈TCO对我来说重要吗？

Token定价比较不是TCO比较。一个完整的AI应用比推理账单多出多少成本取决于它如何组装：在上面的自下而上模型中，整合的单供应商RAG技术栈总计为其推理支出的1.24倍，而相同工作负载拆分到两个供应商则达到2.9倍。差异完全来自计算、存储、网络、数据库、出口流量和运营开销，这些都不会出现在每百万token的价格表中。

针对每月100万次预订的企业差旅代理的Deploy 2026 TCO分析：

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

全栈优势来自三个方面：无跨供应商出口流量费用、整合的运营开销，以及单一的账单关系。它对于构建完整应用的团队、有欧盟数据驻留要求的团队，以及基础设施复杂性成为实际负担的中端市场团队最为重要。

正确的框架：在做出架构决策之前，构建完整的基础设施组件清单，在候选平台上为所有内容定价，加上工程开销，并浮现合规要求。

你可以参考下面这个生产环境推理系列的其他文章：

1. 为什么你的LLM账单是预期的3倍
2. 如何为推理用例选择合适的LLM模型
3. 提示缓存实践：命中率从7%到74%
4. 多供应商LLM路由不是问题，而是你的架构