微软研究人员深入研究了1350万次GitHub Copilot会话，得出一个明确结论：AI编码工具底下的基础设施并非为它们的实际工作方式而构建。基于这一庞大数据集的研究指出了三个具体问题领域——缓存效率低下、重试级联和空闲时间——如果AI助手要顺利扩展，这些都需要重新思考。
数据揭示了什么
这项研究是迄今为止对开发者如何真正使用AI结对程序员的最大规模观察之一。通过分析数百万次会话，研究人员看到了小型测试无法发现的模式。他们发现，请求到达系统的方式以及系统的响应方式，会迅速累积成低效问题。
最大的问题之一是缓存。当许多开发者提出类似问题时，设计良好的缓存应该能快速响应。但论文认为，当前的缓存策略无法应对Copilot生成的大量独特、上下文密集的长尾请求。这导致重复的高成本计算。
重试级联和空闲时间
另一个发现涉及请求失败或超时时的情况。系统不是进行单次重试，而是可能触发级联——多次重试堆积起来，使后端过载。研究人员表示，这不仅仅是网络问题，更是重试逻辑与AI模型服务交互方式的设计缺陷。
还有空闲时间问题。AI模型不像传统网络服务器。它们需要保持“热”状态才能快速响应，但保持“热”状态需要花费金钱和能源。研究表明，当前管理空闲资源的方式效率低下，要么导致响应缓慢，要么浪费计算资源。
为什么基础设施必须改变
论文的核心论点是，AI基础设施不能只是普通云服务成功方案的放大版。AI工作负载的模式——突发性、上下文依赖性和易失败性——需要不同的架构。作者建议提供商投资更智能的缓存、更具弹性的重试机制和自适应的空闲管理。
这不仅仅是技术细节。随着AI编码工具成为开发标准，这些系统的成本和性能将决定其被采用的范围。如果工具运行太慢或太贵，开发者就会转向其他选择。
该研究除了Copilot外没有点名具体供应商或产品，但其发现广泛适用于任何构建AI助手的人。那1350万次会话的数据对整个行业来说是一个警钟。
该论文可供研究人员和工程师深入研读。悬而未决的问题是，基础设施提供商会多快根据这些发现采取行动——以及下一代AI系统能否避免同样的瓶颈。
