跳转到主要内容
Background

为什么现在的每个应用程序都是 AI 应用程序——这又带来了什么问题

了解 AI 如何改变应用程序架构、数据移动、工作负载部署位置和基础架构成本。

带时间戳的摘要

带时间戳的摘要

[00:00–02:30] 正在消失的 AI 边界:Swapnil Bhartiya 介绍了 AI 从孤立发展到全面渗透至每个应用程序和工作流的转变。Danielle Cook 指出,AI 应用程序和非 AI 应用程序之间明确的界限已不复存在。如今的应用程序都集成了 AI 技术,它们通过 API 与其连接、向其提供数据或者为其提供支持,这使得每个应用程序都成为了 AI 生态系统的参与者。

[02:31–03:25] 监测能力与影子 AI:Cook 探讨了各企业在 AI 应用方面所具备的不同程度的监测能力。尽管受监管行业可能维持严格管控,但大多数企业必须承认,其工作流中广泛存在未经批准的影子 AI 使用情况,这给平台团队和开发人员带来了严峻的监控挑战。

[03:26–04:56] 实验需求与生产需求之间的对比:将 AI 投入生产环境,意味着关注点从模型性能转向了应对真实用户需求、满足延迟要求、保障持续推理以及控制实际成本。Cook 强调,GPU 只是整体架构的一部分。生产环境同样需要计算、存储和网络资源,同时应认识到,许多辅助性任务(如 API 调用和数据库)可以在 CPU 上高效运行。

[04:57–06:09] 重新考虑基础架构战略:由于 AI 具备实时性和交互性,再加上数据会持续流动,因此架构师必须通过 AI 的视角来审视整个基础架构。这需要实施模型路由与语义缓存等策略,才能大规模提供兼具成本效益与高质量的客户体验。

[06:09–08:01] 数据引力与边缘计算:计算范式正在发生转变,逐步从“将数据移动到计算节点”转向“让算力靠近数据”。由于体量巨大、存在合规性限制或具备敏感性,数据往往是最难迁移的部分,因此工作负载的部署位置以及对出站流量成本的预估正在成为至关重要的架构决策。

[08:02–09:56] 单次 AI 请求的复杂度:用户向 AI 应用程序发出的单次请求,可能会触发数十个分布式后台请求,涉及多个模型、向量数据库以及 API。Cook 指出,由于这些系统并不总是由主机代管,因此反复出现的微小网络延迟会不断累加,从而导致网络或存储而不是 GPU 成为了实际的瓶颈。

[09:57–11:35] 管理分布式数据及出站流量成本:由于企业数据分散在公有云、私有基础架构以及边缘位置等多种环境中,因此受监管与地理因素的影响,数据移动不仅成本高昂而且非常复杂。Cook 强调,必须预先将数据传输费用纳入考量,以避免产生每年可能高达数十亿的意外出站流量成本。

[11:36–13:08] 从头开始设计 AI 架构:对于如今着手构建平台的团队而言,Cook 建议从第一天起就面向“动态数据”进行架构设计。这需要采用分布式应用程序,灵活地部署工作负载以高效服务用户,并具备基础的可移植性以适应模型与基础架构的快速变化。

[13:09–14:23] 重新设计架构的起点:在重新设计其基础架构时,团队应先评估可用的计算资源、确定要运行的模型、评估数据所有权、决定构建还是购买基础架构,并分析 Token 经济学。

[14:24–15:16] 小型模型的价值:尽管整个行业都痴迷于追求超大参数规模的模型,但 Cook 指出,小型模型有时能够交付更出色、更具成本效益的结果。借助合理的工作负载路由,在 CPU 上针对特定任务运行小型模型,能够节省成本并提升效率。

[15:17–16:15] 边缘计算的作用:边缘计算将计算资源部署在靠近最终用户的位置。这可能涉及分布式 GPU 位置或容器化的边缘环境,具体取决于客户如何在控制财务影响的同时需要采取何种方案来交付其所需的体验。

[16:16-20:23] 超越炒作,探索 AI 战略:Cook 指出,目前在 AI 领域尚不存在通用的成熟度模型。无论是直接使用外部 AI 服务、在内部运行 GPU 进行微调、从头开始训练模型,还是采用无服务器推理方案,企业都必须确保其 AI 基础架构的选择与其特定的业务目标相符。

分享