深度复盘：$12K AI 架构教训——多模型时代解偶之道

最初发表于 AIdeazz——交叉发布于此，附有规范链接。

我去年在三个本可以避免的供应商锁定上花费了 12,000 美元。作为一名在 Oracle Cloud 上构建多 Agent AI 系统的独立创始人，没有 VC 资金支持，每一美元都是一个决策。这些在当时并不是"坏"的选择，但它们最终变成了代价高昂的陷阱。如果我今天以首席技术顾问的身份审计 AIdeazz，这是我首先会仔细审查的三个合同。

LLM API 合约：我无法摆脱的 Anthropic Claude 3 Opus

我最初的 Agent 架构在很大程度上依赖 Claude 3 Opus 来处理复杂的推理任务。当时，它的上下文窗口和推理能力相对于价格而言无与伦比。我围绕它的特定 prompt 格式和 tokenization 构建了我的核心编排层，包括 Agent 内省和规划。这是一个错误。

问题不在于 Claude 的质量，而在于缺乏真正的抽象层。我早期的代码直接嵌入了 Anthropic 的 API 调用、特定的系统和用户消息结构，甚至依赖于它对工具使用的独特处理方式。当 Groq 推出 Llama 3 8B 和 70B，以远低的成本提供每秒 500 个 token 时，我被困住了。重写核心 Agent 逻辑以适应 Groq 的不同 prompt 结构、工具调用约定和 tokenization（这影响成本计算和上下文窗口管理）会花费数周时间。而在发布功能的同时，我没有那么多时间。

成本影响是显著的。一个在 Claude 3 Opus 上可能花费 $0.05 的复杂推理任务在 Groq 的 Llama 3 70B 上可能只需花费 $0.0005。我目前的月度 LLM 支出约为 $1,500。如果其中 50% 可以转向 Groq，我会节省 $750/月。一年下来，那就是 $9,000。这是不抽象 LLM 调用的直接成本。

一个执行 AI 供应商锁定审计的首席技术顾问会立即查找核心业务逻辑中是否直接调用特定 LLM 提供商的 API。建议会是一个 LLMProvider 接口，即使是简单的接口，也能抽象 generate_response(messages, tools, temperature, max_tokens)，并在内部处理提供商特定的格式化。这允许在不重写核心 Agent 行为的情况下热切换提供商。

成本更高的数据库选择：Oracle 自主数据库

作为 Oracle Cloud Infrastructure（OCI）用户，Oracle 自主数据库（ADB）似乎是自然的选择。它是完全托管的，自动扩展，并与其他 OCI 服务深度集成。对于我的向量存储（在 ADB 内的 PostgreSQL 实例上使用 pgvector）和关系数据，它提供了简便性。

简便性带来了溢价。我最初的估计是基于通用的 PostgreSQL 实例。ADB 虽然功能强大，但其每 OCPU 和每 GB 的成本更高。对于一个小型、不断增长的应用程序来说，"自主"功能过度了。我目前在 ADB 上花费 $300/月来处理一个可以轻松在 OCI VM 上的自管理 PostgreSQL 实例上运行的工作负载，成本仅为 $50/月。这意味着每月超支 $250，或年度 $3,000。

这里的锁定不仅仅是成本；它是操作复杂性。从 ADB 迁移到标准 PostgreSQL 实例在技术上是可行的，但涉及设置复制、管理备份和配置监控——ADB 自动处理的任务。对于独立创始人来说，这种操作开销是真实的成本。

一个首席技术顾问会质疑对非关键工作负载的"完全托管"溢价。对于 AI Agent，特别是那些具有高吞吐量但低延迟要求的 Agent，一个更简单、更便宜的数据库解决方案通常就足够了。审计会建议针对实际使用模式（CPU、IOPS、存储）与自管理替代方案或更便宜的托管服务（如 OCI 的 MySQL HeatWave 甚至一个简单的带有 PostgreSQL 的 VM）的成本进行评估。决策应该由实际性能要求驱动，而不是感知的便利性。

基础设施押注老化：用于 Agent 编排的 OCI Functions

当我开始时，OCI Functions（无服务器函数）似乎非常适合无状态 Agent 编排。每个 Agent 步骤可以是一个函数调用，按需扩展，仅为执行时间付费。这对于简单的顺序工作流运行良好。

问题出现在复杂的、有状态的多 Agent 系统中。我的 Agent 经常需要跨多个轮次的持久上下文、Agent 间通信和长时间运行的进程。OCI Functions 是为短期的、无状态的执行而设计的。我最终在函数之间传递大型 JSON 有效负载来维持状态，导致延迟增加、调用成本更高（由于较大的有效负载和更多的调用）以及令人头疼的调试。

我目前的月度 OCI Functions 账单约为 $100。这可能看起来不多，但隐藏的成本是开发人员时间和架构复杂性。我花了无数小时调试状态序列化问题和优化函数冷启动。如果我在持久计算实例（例如，带有 FastAPI 等 Python 应用服务器的 OCI VM）上构建这个，计算成本会相似，但开发和调试开销会大幅降低。

一个首席技术顾问会识别无服务器范式与多 Agent 系统有状态性质之间的不匹配。审计会建议将核心 Agent 编排转移到持久计算层（VM、Kubernetes 或甚至 OCI Container Instances），其中状态可以更自然地管理。无服务器函数仍然对事件驱动的触发、webhook 或轻量级的独立任务非常优秀，但不适合复杂 AI 系统的核心。

首席技术顾问 AI 供应商锁定审计检查清单

根据我的错误，这是首席技术顾问应该执行的快速检查清单：

LLM 抽象层：

• LLM API 调用是否直接嵌入在核心逻辑中？（危险信号）
• 是否存在允许以最少代码更改交换 LLM 提供商的接口或包装器？
• Prompt 模板和 tokenization 是以通用方式处理，还是与特定提供商绑定？
• 如果您将 50% 的流量转向更便宜的等效 LLM，成本差异是多少？

数据库成本与需求：

• 是否为非关键或低流量数据使用了完全托管的高级数据库（例如 Oracle ADB、AWS Aurora）？
• 实际的 CPU、内存和 IOPS 要求是什么？
• 同一工作负载的自管理替代方案或更便宜的托管服务的成本是多少？
• 迁移到更便宜选项的操作开销是什么，它是否超过了节省的成本？

AI 编排的计算范式：

• 无服务器函数（例如 OCI Functions、AWS Lambda）是否被用于有状态的、长时间运行的或复杂的多步 AI 工作流？（危险信号）
• 无服务器调用之间的状态是如何管理的？（大型有效负载、外部存储 = 复杂性）
• 冷启动和函数间通信的延迟影响是什么？
• 持久计算实例（VM、容器）是否会简化架构并减少开发开销，即使原始计算成本相似？

这些问题并不是关于完全避免特定供应商。它们是关于有意识地决定在何处接受锁定，以及在何处它变成代价高昂的负债。我的 12,000 美元教训让我认识到，便利性往往有隐藏的价格标签，特别是在精益构建时。

常见问题

问：如果特定 LLM 提供商的独特功能提供了显著的优势，使用它总是坏的吗？

答：不一定，但这是一个经过计算的风险。如果一项功能（例如特定的工具调用、视觉能力）提供了关键的、独特的优势，应衡量这与如果出现更好或更便宜的替代方案时迁移成本的对比。围绕该特定功能构建一个抽象层，承认锁定。

问：您如何平衡完全托管数据库的便利性与自托管的成本节省？

答：对于早期产品或独立创始人，自托管的操作开销可能是一个重要的隐藏成本。从托管服务开始，但持续监控使用和成本。一旦您达到一定的规模或成本阈值（例如 $200/月），重新评估自托管节省的成本是否超过花费在维护上的时间。

问：无服务器函数何时适合 AI 工作负载？

答：无服务器函数对于事件驱动的任务非常出色：处理传入的 webhook、为视觉模型调整图像大小、为 LLM 预处理数据，或基于外部事件触发 Agent 工作流。它们不太适合多 Agent 系统的核心、有状态编排。

问：缓解现有供应商锁定的第一步是什么？

答：识别最昂贵或最关键的锁定点。对于 LLM，首先为最常见的 API 调用创建一个简单的包装器接口。对于数据库，分析您的实际使用情况以确定更便宜的替代方案是否满足性能需求。不要试图一次修复所有问题。

——Elena Revicheva · AIdeazz · Portfolio

如需进一步行动，您可能会考虑屏蔽此人和/或报告滥用