停止围绕 GPU 设计 AI 基础设施

为什么 MSP 应该从工作负载而非硬件开始

在 AI 会议上只花五分钟，你很容易会认为每个成功的 AI 部署都始于购买更多 GPU。这很容易理解，因为硬件在讨论中占据主导。客户听到 Blackwell 系统、InfiniBand 互连、超大规模云以及日益庞大的 AI 集群。供应商自然倾向于最新的加速器和最快的系统，因为它们令人兴奋、相关且相对容易在市场上定位。

问题不在于计算不重要，计算非常重要。

问题在于从这里开始会导致组织提出错误的问题。AI 市场已经不再是实验阶段。AI 正在投入生产，企业投入真实资金，并期待可衡量的业务成果。基础设施决策比两年前更加重要。然而，仍有太多决策是由技术驱动的，而不是由业务需求驱动。

第一个问题不应该是“我们应该买哪款 GPU？”

应该关注“我们要支持什么工作负载？”

看似微小的改变会影响随后几乎所有的基础设施决策。

没有统一的 AI 基础设施标准

市场上最大的误解之一是认为 AI 基础设施有统一的蓝图。实际上并不存在。

我们常把 AI 当作单一工作负载来讨论。实际上，AI 包含了范围极广的业务应用，需求各不相同。语音 AI 平台的基础设施需求与医学影像截然不同。知识检索与图像生成不同。欺诈检测与预测分析不相似，亦不类似视频处理。它们都使用 AI，只是对基础设施的使用方式不同。

你并不是在为“AI”本身设计基础设施，而是在为使用 AI 的业务应用设计基础设施。这一区别很重要。每个工作负载对支撑它的基础设施都有独特需求。有的需要大量计算资源；有的高度依赖存储性能，因为它们持续检索大规模数据集；有的受网络吞吐量限制，另一些则对延迟极为敏感，因为每毫秒都影响客户体验。

还有一个实际情况。模型设计时所设想的基础设施并不一定在部署时可用。硬件供应、长交付周期或部署期限可能迫使组织使用与最初计划不同的 GPU、加速器或基础设施配置。这可能需要重新优化模型，甚至围绕实际可部署的硬件重新设计模型。

安全和治理需求同样取决于工作负载。处理公开信息的应用与处理金融交易、医疗记录或专有知识产权的应用在需求上截然不同。数据保护、身份与访问管理、合规性、主权、备份、恢复和可用性不能在部署后才简单添加，它们是架构层面的决策。

业务需求又增加了一层考量。应用需要多快扩展？可持续的运营成本是多少？业务要求的可用性水平如何？组织能够实际管理的复杂度有多少？这些问题会因客户而异。这就是为何没有通用的 AI 基础设施方案。

从首选云、硬件平台或供应商出发的组织并未正确构建 AI 基础设施。真正的领袖是从工作负载出发，围绕业务目标设计架构。

训练抢占头条，推理实现业务价值

业界对训练的痴迷是 AI 基础设施讨论走向错误方向的另一个原因。

训练大型语言模型是一项非凡的工程挑战。需要庞大的数据集、巨型 GPU 集群、巨量电力以及能够全负荷运行数天、数周乃至数月的基础设施。这既昂贵，又具技术亮点，自然吸引关注。

然而，大多数组织并未在构建下一代前沿模型。他们在使用已训练好的模型构建客服应用、语音 AI 系统、员工副驾、知识助理、搜索工具、文档摘要平台、欺诈检测系统以及其他数十种实用应用。

这些属于推理工作负载，推理改变了基础设施的方程式。与其仅仅针对最大计算进行优化，组织可能需要针对快速响应、低延迟、可预测的运营成本和一致的性能进行优化。

如果聊天机器人需要五秒才响应，客户并不在乎底层 GPU 有多强大。如果语音助理在对话中屡次误解请求或出现迟疑，来电者也不关心 AI 集群的规格。他们只知道应用表现不佳。

因此，把每个 AI 环境都按照训练基础模型的方式来设计通常是错误的，而且往往成本不必要地高。

大多数 MSP 客户的目标并不是构建全球最大的 GPU 集群。目标是让 AI 应用快速、可靠、安全且经济地投入生产。

挑战在于为实际运行的工作负载找到性能、安全性、可扩展性、弹性和成本之间的最佳平衡。

也许 GPU 并非你的瓶颈

GPU 已成为 AI 基础设施的明星。它们昂贵、难以获取且易于比较，这使得它们成为无数基础设施讨论的核心。然而，一旦 AI 应用进入生产阶段，GPU 可能并不是限制因素。

“我们需要多少 GPU？”并不是我们应当提问的问题，真正应该问的是“六个月后是什么会拖慢该应用？”

答案可能也在架构的其他位置。

存储是一个很好的例子。AI 工作负载消耗巨量数据，且这些数据集会随时间增长。如果存储无法足够快速地提供信息，即使是极其强大的 GPU 也会花费宝贵的时间在等待而非工作。这些数据还需要在整个生命周期内得到保护、备份、保留、安全和管理。

网络同样重要。吞吐量、延迟、东西向流量以及 AI 集群之间的通信都会影响应用性能。即使计算环境设计良好，也无法无限弥补网络设计不佳的缺陷。

此外，安全必须从一开始就纳入架构。生产前必须解决的问题包括:敏感数据存放位置、网络如何分段、工作负载是通过私有还是公共连接进行通信，以及如何满足合规性和主权要求。

另一个容易被忽视的因素是连通性。虽然它们不一定能制造抢眼的标题，但光纤多样性、路由多样性、对等关系以及地理接近度会对用户体验产生关键影响，更不用说平台的弹性了。

终端客户并不知道也不在乎机架中装的是哪款 GPU。他们关心的是应用是否能立即响应，还是让他们等待。

物理基础设施同样值得关注。电力供应、冷却能力、机架密度和扩展容量决定了今天成功的部署是否能够容纳明日的增长。

还有数据重力。随着数据集的扩大，仅仅因为计算位于别处而在不同地点之间搬运 PB 级信息变得日益低效。在许多情况下，将计算靠近数据既更实际也更省钱。

这就是架构重要的原因。

想想赛车——即使它拥有最好的引擎，也不一定会赢。变速箱、轮胎、悬挂、赛道，尤其是司机同样重要。AI 基础设施的工作原理也大致相同。

从 AI 中创造最大价值的组织不一定是拥有最大 GPU 集群的公司。他们是那些懂得基础设施每一层如何协同工作的组织。

这就是购买基础设施与设计基础设施之间的区别。

以工作负载为先的规划框架

MSP 们有机会改变基础设施的讨论方式。

Instead of beginning with:

• 哪款 GPU？
• 哪家云？
• 哪家供应商？

Start with the workload:

• 我们在解决什么业务问题？
• 这是训练工作负载还是推理工作负载？
• 应用能容忍多少延迟？
• 数据存放在哪里，增长速度如何？
• 适用哪些安全、合规和主权要求？
• 工作负载将如何扩展？
• 业务需要什么水平的可用性？
• 可接受的运营风险水平是什么？
• 随着使用量增长，这个环境的运营成本将是多少？

答案应决定架构，而不是相反。

MSP 的机遇

这种转变改变了 MSP 的角色。

客户并不需要另一个只会向他们出售基础设施的合作伙伴。

工作负载优先的方法是必需的，因为它让 MSP 有机会将计算、存储、网络、连通性、安全、数据位置、可用性和成本作为单一架构的组成部分进行评估，而不是分别做采购决策。

通过这种方式，您可以在应用投入生产前控制成本、提升性能，并识别运营和安全风险。

这也为 MSP 创造了更好的商业模式。

MSP 可以围绕架构、部署、优化、安全、生命周期管理、容量规划和持续改进构建更高价值的持续服务——而不是主要在硬件利润缩减上竞争。

价值不在于推荐最新的 GPU 或最新的云平台，而在于了解客户何时需要它们、何时不需要，以及围绕它们还需要设计什么。

AI 基础设施归根到底不是硬件决策，而是由工作负载、数据以及客户试图实现的业务结果驱动的架构决策。

懂得这一区别的 MSP 将能够成为比基础设施供应商更有价值的合作伙伴。

他们将成为客户信赖的、帮助决定实际需要何种基础设施的人。