Uber 的“零增长技术栈”（Zero Growth Stack）提供了一种可扩展的基础设施解决方案，将容量增长与业务需求增长解耦，使公司能够在显著扩展服务规模的同时，减少物理硬件占用。通过优先推进自动化运行时优化以及严格的 AI 生命周期管理，这一战略转型降低了传统资源扩容带来的额外开销。该方法的核心在于系统性地转向动态系统控制，确保即使内部软件复杂度不断提升，基础设施性能依然能够保持高效。
这一计划的核心支柱之一，是对 Go 运行时性能进行系统性优化。Uber 发现，静态垃圾回收（GC）调优通常无法解决内存占用差异巨大的服务问题——这些服务的内存占用范围从 100MB 到 1GB 不等。因此，Uber 开发了一套动态解决方案：GOGCTunner。该库能够自动调整 GOGC 值，而 GOGC 决定了相对于堆增长速度而言，垃圾回收周期触发的频率。通过直接集成 cgroup 内存限制，并监控实时对象使用情况，该工具可以动态调整运行时参数。虽然这套自动化方案已经在 30 个关键任务服务中成功回收了 70,000 个 CPU 核心，但它也用一个控制循环替代了静态配置，该控制循环必须在堆大小（保持为实时对象大小的 1.25 倍）与严格的 70% 内存使用率阈值之间进行平衡，以避免发生 OOM（内存溢出）事件。
图片来源：Uber Engineering Blog
除了基础设施之外，Uber 还将生成式 AI 集成到了软件开发生命周期中，以提升开发效率。该架构包含多个层级：平台层（利用 Michelangelo AI 作为模型网关）、上下文层（通过 MCP Gateway 注入内部源代码）、专用层（部署 Minion 和 Shepherd 等后台 Agent），以及审查层（使用 uReview 和 Code Inbox 等工具）。目前，92% 的工程师每月都会使用这些 Agent，其中 31% 的新代码由 AI 编写，Autocover 每月生成超过 5,000 个单元测试。然而，快速采用这些工具也带来了显著的经济压力。自 2024 年以来，AI 相关成本增长了六倍，因为基于 Token 的计费模式导致预算耗尽，到 2026 年初，单个开发者的月度成本已经达到 2,000 美元。
为了解决这些挑战，Uber 从无限制采用模式转向严格的成本治理模式，将每位开发者的使用额度限制在 1,500 美元以内。公司目前正在审查 AI 生成代码的实际效果，希望量化自动化产出效率与基础设施开销之间的直接影响。为了进一步完善这些指标，各团队正在从整体成本追踪转向更细粒度的衡量方式。Uber 不再仅依赖单位劳动收入和 AI 计算支出来评估效率，而是建议衡量“净代码质量比”（net code quality ratio），即比较 AI 编写代码与人工编写代码在上线后出现热修复的频率。建立“每个功能的计算效率”（compute efficiency per feature）指标，可以帮助工程负责人判断 AI 生成代码所带来的额外开销——尤其是在考虑 Autocover 等工具生成的大量冗余测试之后——是否符合长期基础设施可持续发展的目标，从而确保基础设施优化能够与实际功能交付保持同步。
原文链接：
