AI FinOps 警钟敲响：Uber 在四个月内耗尽了全年的 AI 预算

过去几年，软件工程领域关于生成式 AI 的讨论，主要集中在提高生产力、加快开发速度和加速功能发布上。但就在本周，一个全新的焦点浮出水面——一个完全围绕公司资产负债表展开的故事。

据最新报道，Uber 在仅仅四个月内就烧光了全年的 AI 预算，目前已被迫对员工的 AI 支出实施严格的上限。这一惊人的事态发展给全球的研发团队敲响了震耳欲聋的警钟：如果不加监控，大规模推广生成式 AI 会带来极具不确定性的可变成本，而这些成本很容易失控。

#事情经过

和许多具有前瞻性的科技巨头一样，Uber 曾积极推动将 AI 整合到日常工作流中。这类举措通常包括采购开发者 Copilot 的企业许可证、在全公司开放高级聊天界面的访问权限，更关键的是，向内部团队分发 API Key 以构建定制化的内部工具。

其初衷是减少阻力，让员工能够利用大语言模型 (LLM) 解决日常问题。然而，正是这种“无缝接入”的特性成为了阿喀琉斯之踵。由于缺乏严格的防护栏和对 Token 消耗的细粒度监控，内部使用量呈爆炸式增长。CI/CD 流水线中疯狂调用 LLM 接口的自动化脚本、工程师为处理数据而启动的 Autonomous Agents，以及塞满了无用样板代码的庞大上下文窗口，这些因素共同导致了预算的迅速见底。

到 4 月底，原本计划撑到 12 月的预算就已荡然无存。作为应对，Uber 不得不紧急踩下刹车，实施了硬性的使用上限、对 API Key 发放进行更严格的治理，并为单个员工设定了配额，以止住财务上的“大出血”。

#为什么这很重要

Uber 的困境绝非个例；它是许多组织即将面临的“AI FinOps”危机的一次预演。

一直以来，企业软件的支出通常是相对可预测的。你根据坐席数谈判 SaaS 合同，支付固定的年费，无论员工使用软件的频率如何，成本都保持静态。而生成式 AI 从根本上打破了这种模式。LLM 的使用高度依赖于用量计费 (consumption-based)。每一次 Prompt 提示、每一次代码补全建议、每一次 API 调用都在消耗 Token。

当你将这种模式扩展到数以千计的工程师、数据科学家和产品经理时，你的财务模型就从可预测的资本支出/运营支出 (CapEx/OpEx) 变成了极其不稳定的、由使用量驱动的账单。必须清醒地认识到，让开发者毫无限制地访问最先进的推理模型，本质上就等于递给他们一张额度无限的公司信用卡。

#技术启示

管理 AI 的消耗不仅仅是一个会计问题；它更是一个复杂的工程挑战。当企业意识到必须遏制 LLM 成本时，建立必要防护栏的重担不可避免地落在了平台和基础设施团队的肩上。

以下是我们观察到这种转变所带来的主要技术启示：

#1. “万能 API Key”的终结

为内部工具分配单个、共享的企业级 API Key 简直就是灾难的配方。现在的研发团队必须构建代理层 (Proxy)，来拦截发往外部 LLM 供应商的请求。这些代理通常具备多种功能：

• 认证与归因： 将每次 API 调用追溯映射到特定的用户、团队或项目成本中心。
• 限流 (Rate Limiting)： 实施专门针对 Token 数量（而不仅仅是原始请求量）进行调优的令牌桶 (token bucket) 或漏桶 (leaky bucket) 算法。

#2. 语义缓存 (Semantic Caching) 成为标配

如果一位工程师每天运行相同的测试套件，而生成式 AI 工具将完全相同的失败日志总结了 10 次，那么为这 10 次推理付费纯粹是浪费钱。缓存精确匹配的请求很容易，但 LLM 的 Prompt 往往会存在细微的差异。

# Example: Implementing a basic Redis semantic cache wrapper
import redis
from sentence_transformers import SentenceTransformer
from sklearn.metrics.pairwise import cosine_similarity

class SemanticCache:
    def __init__(self, threshold=0.95):
        self.cache = redis.Redis(host='localhost', port=6379, db=0)
        self.embedder = SentenceTransformer('all-MiniLM-L6-v2')
        self.threshold = threshold

    def get_cached_response(self, prompt):
        # 1. Convert incoming prompt to an embedding vector
        prompt_embedding = self.embedder.encode([prompt])[0]
        
        # 2. Compare against cached prompt embeddings (simplified for illustration)
        for key in self.cache.keys():
            cached_emb = self.get_embedding_from_key(key)
            similarity = cosine_similarity([prompt_embedding], [cached_emb])[0][0]
            
            # 3. Return cached LLM response if similarity is high enough
            if similarity > self.threshold:
                return self.cache.get(key)
        return None

像 GPTCache 这样的工具或基于 Redis 自研的语义缓存，可以拦截查询、计算 Embedding 并为语义相似的 Prompt 返回缓存的响应，从而大幅减少对外的 API 调用。

#3. 模型路由与分级

并非所有问题都需要动用最顶尖的模型 (Frontier Model)。目前业界正在向“模型路由架构 (Model Routing)”发生重大转变。简单的任务——例如基础的文本格式化、语法检查或日志解析——会被路由到体积更小、成本更低的模型上。而复杂的推理任务则只在必要时，才会升级分配给参数量更大、更昂贵的高级模型。

#下一步是什么？

“不计成本搞 AI”的时代已正式宣告结束。我们正在进入生成式 AI 炒作周期中的“优化阶段”。

在接下来的 12 到 18 个月中，预计会涌现大量专注于 AI 可观测性 (AI Observability) 的内部专用工具。监控大盘 (Dashboard) 将不再只关注 CPU 和内存，还会追踪“每秒 Token 数”以及“每次部署成本”等指标。此外，工程团队需要认识到：Prompt Engineering (提示词工程) 不仅仅是为了获得更好的答案，更是一项至关重要的降本措施——通过优化上下文窗口，确保只发送绝对必要的最少数据。

我们也很可能会看到本地化、开源权重模型 (open-weights models) 重新受到追捧。在开发者的本地硬件上运行较小参数的模型，可以彻底避开日常编码任务中云端 API 的成本开销，从而将宝贵的云端预算留给那些真正需要强大算力的繁重任务。

#结语

Uber 四个月烧光预算是一则警世寓言，它不仅彰显了现代 AI 整合的巨大能量，也暴露了其同样高昂的代价。作为开发者，我们天然地倾向于使用那些能降低摩擦、让工作更轻松的工具，但底层算力的经济账却不容我们无限期地忽视。

展望未来，最成功的研发团队将不再只是那些拥抱 AI 最快的团队；而是那些能够设计出最智能、最具性价比方案来驾驭 AI 的团队。是时候像对待数据库查询、内存泄漏和网络带宽那样，用同样严谨的优化和监控手段来对待 AI API 调用了。