Kubernetes联合创始人Brendan Burns探讨AI如何重塑基础设施，认为AI代码将如汇编般无需审查，重点在于规范与测试。他还讨论了GPU调度和AI应用监控的挑战。
译自：Kubernetes co-founder Brendan Burns: AI-generated code will become as invisible as assembly
作者：Frederic Lardinois
在本期《The New Stack Makers》节目中，我与Kubernetes的联合创始人之一Brendan Burns坐下来，探讨AI如何改变他所帮助创建的基础设施。在Google完成Kubernetes的工作后，Burns十年前加入了Microsoft，现在负责Azure大约1400名工程师和项目经理的容器基础设施和资源管理组织。
与许多在公司中晋升的开发者不同，他仍然亲自维护着几个Kubernetes客户端库。他说：“我宁愿写代码，也不愿看YouTube。”
“你是否忘记了，如果你使用编译器，100%的代码都是机器生成的？我们不再关心那些代码了。”
在这次广泛的对话中，我们探讨了AI工作负载如何迫使Kubernetes以其创建者未曾预料的方式进行调整，为什么监控AI应用程序意味着重新思考“工作”的真正含义，以及Burns为何相信AI生成的代码最终将像我们对待汇编语言一样：作为一种没有人阅读的瞬时产物。
GPU调度不仅仅是“另一种资源类型”
当Burns构建Kubernetes时，调度器只关注两件事：CPU和内存。GPU增加了第三个，但它们不仅仅是另一种需要分配的基础资源。它们还带来了额外的硬件要求，例如快速互连，这使得协同定位变得至关重要。
Burns说：“这不仅仅是‘我想要这台机器上运行一个东西’。而是‘我想要这两个东西落在同一台机器上。我不在乎是哪台机器，但要让它们落在同一台机器上。’”
这就是组调度，这是Kubernetes为AI工作负载做出的几项调整之一。为了向调度器展示GPU拓扑，Microsoft与Nvidia等公司合作开发了动态资源分配（Dynamic Resource Allocation），这是一个Kubernetes原语，允许硬件供应商以通用方式描述给定节点上可用的资源。
Burns说，整体工作负载配置文件也发生了变化。Kubernetes是为在线、无状态服务而构建的。如果一个容器（或其底层硬件）失败了，那没关系，因为可以立即启动其他容器并接管。AI模型训练也是批处理工作负载，但正如Burns所指出的，它对检查点很敏感。即使是基本的硬件故障也可能意味着回滚数小时的计算，这可能会花费很多钱。Burns说，AI训练工作负载“将失败视为一件非常糟糕的事情”，这是原始无状态Kubernetes模型没有考虑到的。
然后是当模型投入生产时的利用率问题。推理在白天达到高峰，在夜间下降，但那些高端GPU在空闲时并不会停止耗费资金。团队希望在非工作时间将它们用于训练和微调，这意味着调度器需要进行抢占和重新调度，这是Kubernetes最初未设计的功能。
Burns的团队正在通过KAITO，Kubernetes AI工具链操作符等项目在Kubernetes之上添加AI原生原语，该项目通过自定义资源处理分布式推理和微调编排。
Burns说，这里的模式类似于服务网格是如何进入Kubernetes的：通过扩展模型分层添加新功能。这种模式也是Burns认为Kubernetes如此成功的部分原因：“供应商中立的开源对成功至关重要。你必须具备让多家不同公司押注于一个单一解决方案的能力。”
AI监控必须有所不同
然而，大多数公司不会只构建模型并运行它们。他们想要做的是在这些模型之上构建应用程序。这带来了它自己的一系列新挑战，尤其是在可观测性方面。
Burns说：“现在突然间，你的监控必须转变——你的监控必须包含人为因素。它不能仅仅是错误率。它必须是说，‘我是否给出了一个好的答案？’不仅仅是我得到了一个答案，而是我得到了一个好的答案吗？”
Microsoft及其他公司这样做的一种方式是，通过基本的点赞/点踩按钮征求用户反馈。Burns说，这里发生的情况是，团队经常因为高点踩率而感到沮丧。但原因很简单：得到好答案的用户不会点击任何东西。
Burns说：“这是一个相对指标，而不是绝对指标。如果你的点踩率从50%降到40%，那是好事。如果它从10%升到20%，那是坏事，即使你会说，嗯，20%也不算太糟。”
在测试方面，Burns借鉴了他当年在Google做网页搜索时的一个模式：你不是测试一个查询，而是测试10,000个。同样的原则适用于AI应用程序。你必须通过系统运行数千个提示，然后评估响应是否有所改善。要大规模做到这一点，使用另一个LLM作为评估器往往是唯一的选择，虽然这个信号不完美，但足以告诉你前进的方向。
另一种测试方法是使用1%实验，这曾经是用户体验团队的领域。但Burns认为，这种测试现在需要贯穿整个技术栈。对于从事AI应用程序的工程师来说，这是唯一能看到他们的改变如何应对真实用户行为的方式。
Burns说：“[用户]正试图完成某件事。如果他们与这个东西聊天10、15、20次迭代，你可能没有给他们正确的答案。但即使是访问聊天记录也很棘手。人们需要选择同意将数据发送给我们，我们才能看到交互。所以有所有这些复杂性，这在你只是问‘我的商店页面是否渲染了？我是否正确地发回了HTML？’的时候是不存在的。”
代码审查只是一个阶段
当前关于编程代理的许多讨论都围绕着这些代码在投入生产之前是否能够被审查。Burns说，许多高级领导告诉他，他们需要更多的首席工程师来处理所有需要审查的AI生成代码。
他告诉他们：“我认为你们做错了。”
Burns从两个层面进行反驳。首先是实际层面：如果AI正在生成更多的代码，那么代码审查就不再是几年繁重工作后获得的隐性技能——而是初级工程师需要在工作中学习的东西，就像前一代人必须学习版本控制一样。
Burns说：“这项工作实际上正在改变，以至于每个人的工作都是审查代码。”
但Burns也认为，当前对代码审查的关注本身就是一个阶段。
他说：“我看到这些统计数据，比如，我们97%的代码是机器生成的，或者别的什么。我心想，你是否忘记了，如果你使用编译器，100%的代码都是机器生成的？我们已经不再关心那些代码了。”
Burns说，现在没有人再审查编译器输出了。测试套件对其进行验证，开发人员隐式信任编译器能够正确执行。Burns认为，随着AI测试框架和规范的改进，AI生成的代码将简单地成为一个瞬时产物，在每次运行时重新生成，并且从不打算供人工审查。他说：“重要的是规范和测试。”
然后是语言本身的问题。Burns将当前AI编程的状态比作“通过建造一个抓住方向盘的机器人来建造一辆自动驾驶汽车”。今天的AI使用为人类可读性而设计的语言进行编写。但具有更严格形式保证的编程语言一直存在。Burns认为，人类不喜欢用它们编写，因为人体工程学感觉受限，但AI不会有这个问题。
Burns问道：“未来的编程语言会是什么样子？它真的是为人类编写的吗？”
