云的隐藏成本

第五章 — 云的隐藏成本

过去五年占据主导地位的说法是，云是经济实惠、可扩展且简单的。对于许多工作负载而言，这是完全正确的。但对于企业级 RAG（检索增强生成）来说，情况越来越并非如此。而你意识到这一点的时间通常是在第一季度末，当账单到达时。

我们来谈谈账单中最容易被忽视的部分：视觉模型的 API。当一家公司将其照片档案导入到现代的 RAG 中时，每张照片都需要由一个多模态模型“描述”，从中提取内容、对象、上下文、任何叠加文本、情绪、构图。一家大型欧洲模型提供商——目前尚未公开名称——在 2025 年提供了一个出色的 Qwen 系列 320 亿参数模型，价格合理。问题在于，只有在实际应用中并且经过数月生产后才发现：在高负载下，该提供商会截断响应。并非总是如此，也不是以可预测的方式，也不是在测试团队面前发生：是随机的。每十张照片中，有时是每五张照片中，就会有一张返回一个被截断一半的 JSON，解析错误，包含部分或空缺的元数据。处理时间从每张照片的十秒飙升到两百秒，且没有规律可循。重试的成本——因为重试是需要付费的，每次调用都需要付费，即使服务器截断了响应——也超出了预期。数据库不一致：有些照片拥有丰富的元数据，而另一些则被截断。而且团队无法在测试环境中重现这个问题，因为在测试环境中负载较低，一切都正常工作。

解决方案分为三个部分：更简洁的提示词（较短的回复截断的可能性更小）、智能重试逻辑（如果回复超过五十年秒且为空，则立即重试）以及——当数量合理时——跳过云端，在一块较慢但确定的本地 GPU 上运行视觉模型。从这次经验来看，正确的架构不是“始终使用云端”，也不是“始终使用本地”。而是“根据当前需求，为每次调用选择”。

然后是查询问题。在经典的云原生 RAG 中，每个用户搜索都会触发一系列付费 API 调用。一个用于问题嵌入。一个用于意图分类（问题类型是什么？）。一个用于文档重新排序。一个用于生成最终回复。每个都花费几分钱。对于一个拥有五十名用户和每天一万次查询的内部服务——这不算少，但对于一家中型公司来说也不是一个庞大的数字——每月账单会达到即使是宽容的首席财务官也会皱眉的数字。而且增长是线性的：用户翻倍，账单也翻倍。消耗的 token 没有规模经济效益，对你来说没有。

还有一个在2025年潜伏着，并在2026年成为核心的问题：每一次查询都会将公司文件的碎片——有时是机密的，有时受保密协议约束，有时受行业法规约束——发送到外部供应商的服务器，这些服务器的管辖权并不总是与您的管辖权一致，日志保留策略也不总是清晰透明。在过去的十八个月里，有多家欧洲公司在审计期间才发现——通常是由担心客户或ISO审核触发——他们签订的合同、价目表和技术规格已被（并且可能为了“服务改进”目的而被记录）由欧盟以外的基础设施处理。通常，这种意外的发现所造成的损失，超过了当初想要避免的本地硬件成本节省。

替代方案不是完全相反的教条。“不要云，要本地” 就像 “总是云” 一样错误。替代方案是一种架构，它允许你为管道的每个部分——嵌入、分类、重新排序、视觉、最终生成——选择使用云模型还是本地模型，并且可以在一天内改变主意，而不是一个季度。这需要一种设计，在这种设计中，供应商是可以互换的，没有哪个部分被锁定到特定公司的名称上，从 Regolo 到 Ollama（或反之）的切换只需一行配置，而不是重写。而直到不久前，这还很罕见。流行的框架，尽管具有“供应商无关”的外观，实际上与某人紧密结合。