如何设计经久耐用的企业 AI 服务运行框架

企业 AI 的下一个竞争优势，与其说取决于你选择哪种模型，不如说取决于你围绕它构建什么。

这是一个重要的转变。过去几年，AI 领域的讨论大多聚焦于模型能力：更大的模型、更强的推理能力、更长的上下文窗口、更高的基准测试分数。这些进步非同凡响。但随着 AI 从试验走向生产，企业领导者面临的问题已经改变——不再是“模型能做什么？”，而是“我们能否可靠、经济且大规模地交付这种智能？”

越来越多时候，答案取决于服务运行框架——也就是围绕模型构建的工程系统，包括架构、内存管理、调度和优化决策；这些因素决定了如何高效地将模型智能转化为生产能力。

对于技术高管而言，这改变了 AI 投资的方向，也改变了他们应对底层架构提出的要求。

不存在普遍“最佳”的模型或 AI 架构，只有适合业务问题的解决方案。

针对快速响应进行优化的面向客户助手，与可在夜间运行的文档处理流水线，需求截然不同。内部知识应用与高流量客户服务平台或许使用同一基础模型，却需要迥异的服务架构。

工作负载决定约束条件，约束条件应决定架构。

这听起来简单，却与许多组织早期部署 AI 的做法背道而驰。在概念验证阶段，讨论自然会以模型准确率为主。进入生产环境后，则会遇到一系列约束；当用户只有寥寥数人时，这些约束很容易被忽略：延迟、并发、内存压力、GPU 利用率、基础设施成本以及不可预测的流量。

如果某个模型只是略微改善了回答，却让推理成本翻倍，或无法满足应用的延迟要求，那么它未必是更好的生产选择。并非每种工作负载都需要法拉利。有时，更明智的工程决策是选择能够恰好满足业务所需性能、又无需为用不上的能力买单的模型。

目标应是针对工作负载，以合适的成本部署恰当的智能。这意味着服务架构不只是工程问题，更是一项投资决策：在哪些方面投入算力、在哪些方面进行优化，以及在哪些情况下，额外的模型能力并不值得其成本。

AI 进入生产环境后，看似孤立的工程决策会开始相互影响。服务架构影响内存利用率；内存管理影响并发能力；并发会影响批处理和调度，而调度又会影响 GPU 利用率和延迟。

只有做好这些工作，量化、推测解码或优化注意力机制等技术才能充分发挥价值。这种相互依赖关系至关重要，因为组织可能大幅增加基础设施投入，却仍未解决限制性能的瓶颈。

GPU 内存就是一个很好的例子。在推理过程中，模型权重保持不变，但键值（KV）缓存会随着活跃请求数量和上下文长度而增长。随着并发量增加，即使计算能力仍有余量，系统也可能耗尽可用 GPU 内存。如果不了解这一瓶颈就增加算力，可能只会让低效系统变得更加昂贵。

给科技领导者的启示不止于内存管理：先测量，再优化。找出主要制约因素。解决它。测量结果。然后判断是否出现了另一个瓶颈。如此反复。

不要把优化技术当作宝可梦卡牌：目标不是集齐所有技术，而是应用能消除影响最大的制约因素、同时满足应用业务要求的技术。

这要求科技领导者采用不同的治理思路。与其问组织可以部署哪些 AI 能力，不如问：已验证的能力与可持续的业务价值之间，存在哪些制约因素？

投资于服务框架或许有一个最重要的理由：今天领先的模型很可能不是明天的领先模型。模型会不断改进，硬件会持续演进，新的优化技术也会不断涌现。围绕这些技术构建的架构，应当让组织更容易适应变化，而不是每逢技术进步就迫使企业重建 AI 平台。

因此，适应能力正成为 AI 战略日益重要的成果。

围绕工作负载需求、明确的服务级别目标以及可衡量的生产经济效益构建服务系统，能让组织根据业务的实际需求评估新模型和基础设施。模型变更可以成为评估和配置决策，而不必引发架构重置。

EXL 的研究人员在EXL《构建工程化服务框架》系列文章中深入探讨了这些生产环境中的挑战。该系列分析服务架构、内存管理、调度和推理优化如何协同工作，从而使企业 AI 更高效、更具可扩展性，并在经济上更具可持续性。

企业能够使用许多相同模型的情况日益普遍。可持续的差异化优势，来自组织将这些智能有效转化为业务成果的能力。

模型提供智能。服务框架决定企业能否可靠、经济且大规模地交付成果。

本内容由 EXL 制作，并非由《MIT Technology Review》的编辑团队撰写。