TrueFoundry 联合创始人兼首席执行官 Nikunj Bajaj——访谈系列

在创立 TrueFoundry 之前，您曾从事机器学习研究、Facebook (META ) 的生产环境 AI，以及大规模推荐系统相关工作。哪些经历最直接地促使您创办一家面向企业的 AI 基础设施公司？您认为当时还有哪些痛点没有得到解决？

在 Meta，我们把机器学习视为软件的一种特殊情况，把生成式 AI 视为机器学习的一种特殊情况。由此形成了一个纵向技术栈：软件在底层，机器学习居中，生成式 AI 位于顶层。在这种架构下，如果我是一名机器学习开发者，我构建的模型就会沿用其他软件的部署模式，因此扩展系统规模非常直接。

然而，大多数企业部署的是相互平行的技术栈，即软件、机器学习和生成式 AI 各有独立的技术栈。一旦存在这些并行技术栈，机器学习和软件领域之间就需要交接工作，从而使扩展规模变得更加复杂。

我们的团队一直处于机器学习模型构建与机器学习基础设施的交汇处，因此形成了独特的视角：我们可以把类似的纵向技术栈带入企业，并根据其具体要求加以调整。2021 年底，我们还提出了一个假设：机器学习正在接近拐点，届时更多公司将需要纵向整合的技术栈，才能高效部署和扩展这些系统。这最终促使我们创立 TrueFoundry，而我们的假设得到了验证。2022 年底 ChatGPT 推出后，AI 的采用明显加速。

随着 AI 系统从实验走向日常运营，组织应如何看待可靠性和故障，这方面发生了哪些变化？

与传统机器学习系统相比，生成式 AI 所涉及的利害关系要重大得多。这些系统进入生产环境后，组织必须应对更高程度的模糊性和非确定性，因为 LLM 本质上具有随机性。在其之上构建的智能体系统又进一步增加了模糊性。

此外，故障不再是非此即彼的二元状态。系统不再只是发生故障或不发生故障，许多问题表现为局部故障或不易察觉的退化。随着时间推移，系统可能响应延迟增加、质量下降或出现错误行为。在许多情况下，这些退化更难被发现，有时造成的损害甚至大于彻底停机。

组织考虑可靠性时，不仅要看正常运行时间，还要关注性能随时间推移而出现的退化。

TrueFailover 推出时 正值云服务和 AI 服务接连发生备受关注的中断。最近哪些事件清楚表明，AI 可靠性已经从一个锦上添花的特性，变成核心架构要求？

我们的一位医疗行业客户会实时处理患者与处方有关的请求，这些请求需要及时响应。该客户因模型故障而遭遇服务中断。其工作流每秒创造数千美元收入，而此次中断影响了其中一些关键工作流。由于该客户较早采用了 TrueFailover，我们能够帮助其迅速恢复，并将影响控制在有限范围内。

这样的事件引出了一个重要问题：随着生成式 AI 系统所涉及的利害关系不断扩大，为什么恢复流程仍然主要依赖人工？这进一步印证了一个理念：构建系统时应当假设故障会发生，并让系统能够自动纠正问题。可靠性也必须内置于 AI 技术栈本身。AI 网关可以为此提供集中式路由、可观测性、安全防护机制，以及在不同提供商之间智能切换模型的能力。

许多 AI 服务中断仍被描述为小小的技术插曲。当 AI 系统停机时，您认为真正的经济代价和对人的影响开始体现在哪些方面？

企业 AI 已经发展到一个阶段，这些小问题不再只影响内部工作流。如今，中断和退化会直接、立即影响公众观感与利润，因为生产环境中的应用已经直接服务于客户。从内部测试转向面向公众、牵涉重大利害关系的应用，正是高管需要投入更多关注和监督的原因。

随着 AI 系统越来越深入地嵌入运营工作流，中断不再只是技术问题，而是日益带来直接的业务、客户和声誉后果。

在药房、医疗服务运营或客户支持等关键业务环境中，AI 停机能以多快的速度演变为运营风险或声誉风险？

在关键业务环境中，风险几乎会立即升级，因为这些系统支持实时且对时效要求严格的工作流。即使短暂中断，也可能导致关键流程停止、服务交付延迟，或使依赖这些输出的下游系统中断，进而在整个组织内引发连锁运营影响。

在医疗等领域，影响不仅限于运营中断，还会波及客户体验和服务结果。如果患者无法及时凭处方取药，就可能产生实际后果。这不仅是患者面临的问题，还可能损害药房或医疗服务提供者的声誉。在信任至关重要的关键业务环境中，维持系统在线极为重要。因此，组织越来越认识到，设计 AI 系统时必须假设故障会发生，并让恢复机制自动启动，以尽量降低风险。

您说过，许多团队设计架构时更重视能力，而非业务连续性。您认为，为什么 AI 系统设计过去常常没有优先考虑韧性？

这在很大程度上取决于组织内部的激励机制。新能力看得见，也令人兴奋，能够带来演示、功能以及领导层可以立即看到的产品新可能。

按照其本身的特点，当一切运转良好时，连续性是看不见的。因此，奖励机制往往更偏向推出新功能，而不是确保系统不出故障。结果是，组织通常在能力开发上投入过多，而在韧性工程上的投入相对不足。

随着企业越来越依赖外部模型和 API，AI 技术栈中出现了哪些新的脆弱环节，而领导者可能还没有充分认识到其重要性？

LLM 本质上是共享资源，企业并不像拥有传统基础设施那样拥有它们。此外，企业中重要的业务关键系统运行在尚未经过充分时间检验的外部系统上。LLM 本身发展很快，因此不能因为延迟或模型性能略有下降等问题，就要求模型提供商承担责任，因为他们正在以很快的速度迭代研究。

由于 LLM 是共享资源，另一个使用者的某项操作就可能导致延迟骤增。LLM 的这种基本性质带来了许多故障点，而企业在这个新世界中并没有完全的控制权。在无法完全控制的情况下，企业最好的做法是建立足够的系统冗余，从而设计出具有韧性的系统。

不针对具体产品，组织应如何重新思考 AI 架构，默认故障会发生，而不是把中断视为罕见的边缘情况？

组织应该回到分布式系统设计的基本原则。软件系统在构建时就假设网络组件和机器会发生故障，甚至整个区域都可能停止运行。

AI 系统也不应例外。我们应假设模型提供商会出现延迟、退化或中断，并纳入冗余设计，让应用在不同故障情景下仍能保持韧性。

您是否预计，AI 韧性会成为选择平台和供应商时的决定性因素，就像正常运行时间和冗余曾经影响云基础设施的决策一样？

随着更多 AI 系统进入生产环境，韧性将成为最低要求。如果供应商无法展示正常运行时间和整体韧性的图表与指标，甚至不会被纳入考虑。一旦韧性成为对所有供应商的基本期待，决定性因素就会转向用户体验、性能优化、可观测性和更高层次的产品能力。随着时间推移，AI 网关和自动故障转移等能力将成为企业 AI 基础设施的核心基础要素。

展望未来，在人们期待 AI 持续可用、而非只是偶尔有用的世界里，“生产就绪”的 AI 究竟意味着什么？

生产就绪的 AI 系统应当可观测、可控制、可恢复。这三项要求缺一不可。

要让生产环境中的 AI 具备可观测性，团队需要深入了解模型行为、延迟、错误率、token 使用量、漂移以及故障模式。如果没有强大的可观测性，就很难在用户开始察觉之前发现退化。

系统的可控制性包括流量整形、请求速率限制、安全防护机制、策略执行，以及在不同模型和提供商之间智能路由。AI 网关在这里成为基础，充当集中式控制平面，执行安全防护机制，提供一致的治理，并在性能或可靠性下降时实现动态模型切换。

最后，要具备可恢复性，系统应当假设组件可能部分或完全失效，无论原因是提供商服务中断、模型质量下降、请求速率限制，还是来自恶意行为者的意外输入。自动故障转移和自愈机制应当内置于架构，而不是等到问题发生后才启动人工操作流程。

这就是我们在 TrueFoundry 努力的方向。以这种方式定义生产就绪、结合可观测性、集中式控制和自动恢复的供应商，将赢得客户的长期信任，并能够持续解决不断出现的新问题。

感谢这次精彩的采访。希望了解更多的读者可以访问 TrueFoundry。