ARTICLE · 1292041
AI Infrastructure 是什么?企业部署 AI 为什么离不开基础设施?
假设一家企业准备建设一个 AI 项目管理助手。
项目经理希望它能够查询项目任务、识别延期事项、检索项目管理制度、生成项目健康报告，并在负责人审批后发送风险通知。
项目团队很快完成了第一步：接入大模型 API。
演示时，系统可以回答问题、生成报告，看起来一切顺利。
但进入测试阶段，新的问题开始出现：
多个用户同时提问时，响应时间明显变长； 处理长文档时，模型调用出现超时； 知识检索速度不稳定，回答有时准确、有时不准确； 测试环境运行正常，正式环境却出现依赖和兼容性问题 为了提高响应速度增加资源，成本也随之上升； 系统出现故障后，团队无法快速判断问题出在模型、网络、存储还是应用本身。
这些问题并不一定意味着大模型能力不够。
它们也可能来自计算资源不足、数据访问效率低、服务配置不合理、运行环境不稳定，或者缺少有效的资源管理与监控机制。
这就引出了企业部署 AI 时一个容易被忽略的问题：
我们关注了大模型，却是否认真规划过支撑大模型运行的基础设施？
在传统软件项目中，我们通常会讨论服务器、数据库、网络、操作系统和应用部署。到了 AI 项目，这些基础能力依然重要，但还需要进一步考虑 GPU 资源、模型推理、显存需求、并发请求、模型服务和计算资源调度等问题。
这套为 AI 工作负载提供运行支撑的软硬件体系，就是我们今天要讨论的 AI Infrastructure。
需要先说明：上面的项目管理助手是用于解释技术问题的示例场景，并非经过核实的真实企业案例。本文关于技术机制的判断，将结合微软、Kubernetes、Google Cloud、NVIDIA、MLCommons 等公开资料展开。
二、AI Infrastructure 到底是什么？
1. 先用一句话理解
AI Infrastructure，即人工智能基础设施，是为 AI 模型的训练、推理和相关应用运行提供计算、存储、网络、软件运行环境及资源管理能力的基础体系。
它既包括看得见的硬件，也包括让硬件能够被有效使用的软件和管理机制。
例如：
这张表是为了帮助读者建立概念地图而整理的参考框架，并非某个标准组织发布的统一分类。
NVIDIA 的 AI Infrastructure 相关资料将计算、存储、网络和软件等纳入 AI 基础设施的讨论范围。微软的 AI 工作负载架构指导则进一步强调，需要从完整工作负载出发考虑数据、模型、应用和运营等环节。
这两类资料的关注范围并不完全相同，但都说明：AI 的运行不能只看模型本身。
原始资料：
NVIDIA：What Is AI Infrastructure?
https://www.nvidia.com/en-us/glossary/ai-infrastructure/
Microsoft：AI workload architecture
https://www.nvidia.com/en-us/glossary/ai-infrastructure/
2. AI Infrastructure 与传统 IT 基础设施有什么区别？
两者并不是相互替代的关系。
AI 基础设施仍然依赖传统 IT 基础设施中的许多技术，例如服务器、存储、网络、操作系统和数据中心环境。
区别在于，AI 工作负载可能带来不同的资源需求和运行特点。
传统企业应用通常需要关注数据库访问、事务处理、接口响应、网络连接和服务可用性。
AI 工作负载还可能需要考虑：
模型参数和中间数据需要多少显存； 输入数据和模型文件如何高效加载； 多个计算设备之间如何协同； 推理请求如何调度； 并发请求增加时，时延和吞吐量如何变化； 模型版本、驱动和运行环境是否兼容； 计算资源的使用成本是否符合业务预期。
例如，一个普通业务接口可能主要受数据库查询或网络延迟影响；而一个大模型推理服务，即使接口和数据库都运行正常，也可能因为显存不足、请求排队或推理资源配置不合理而变慢。
这并不意味着所有 AI 应用都一定需要专用硬件。简单的文本分类、低频调用和轻量模型，可能完全可以运行在已有的计算环境或云端服务上。
AI 基础设施与传统 IT 基础设施的核心区别，不是前者必须使用某种特定芯片，而是企业需要根据 AI 工作负载的特点，重新评估计算、存储、网络、软件和资源管理之间的关系。
三、AI Infrastructure 的核心组成：从硬件到运行管理
理解 AI 基础设施，可以沿着一条完整的技术链路展开：
计算资源 → 存储与网络 → 软件运行环境 → 资源调度 → 模型运行 → 监控与运维。
这些环节相互依赖，任何一个环节成为瓶颈，都可能影响最终业务表现。
1. 计算资源：CPU、GPU、NPU 分别做什么？
计算资源负责执行程序和模型运算，但不同处理器的设计目标不同。
CPU：通用计算与系统协调
CPU 是通用处理器，适合执行操作系统任务、业务逻辑、数据预处理、控制流程以及大量通用计算工作。
在 AI 系统中，CPU 并不会因为 GPU 的出现而失去作用。
例如，AI 服务需要接收请求、检查参数、组织数据、调用模型、处理结果和记录日志，这些工作仍然需要通用计算能力。
GPU：并行计算的重要选择
GPU 具有适合大量并行计算的架构，因此被广泛用于深度学习训练和推理。
但不能简单地说 GPU 在所有任务中都比 CPU 快。
具体表现取决于任务类型、模型结构、数据规模、软件实现、内存访问以及硬件配置。
对于需要大量并行矩阵运算的模型，GPU 往往具有明显优势；对于数据量很小、控制流程复杂或计算并不密集的任务，GPU 未必能带来相应收益。
NPU：面向 AI 工作负载的专用处理器
NPU 通常指面向神经网络或特定 AI 工作负载优化的处理器。
不同厂商的 NPU 在架构、支持的算子、软件工具链和部署方式方面可能差异很大。
因此，企业评估 NPU 时，不能只看峰值算力，还需要确认目标模型、推理框架、算子支持和实际部署环境是否兼容。
项目经理需要记住：
选择 CPU、GPU 或 NPU，应该从模型和业务需求出发，而不是简单追求硬件规格。
选型前至少需要回答：
计划运行什么模型？ 是训练、微调，还是在线推理？ 模型规模和显存需求是多少？ 目标并发量和响应时间是多少？ 对功耗、成本和部署环境有什么限制？ 现有软件栈是否支持目标硬件？
在这些问题没有明确之前，直接决定购买多少张 GPU，通常为时过早。
2. 存储：模型能运行，不代表数据能及时到位
AI 系统需要保存和读取模型文件、训练数据、知识库文件、日志以及其他运行数据。
存储的影响不仅体现在容量上，还体现在读写性能、并发访问、可靠性和数据管理方式上。
例如：
模型部署时，需要读取模型文件； 训练任务可能需要持续加载大量数据； 知识检索应用需要读取索引和相关数据； 运行监控需要保存日志和指标； 企业还需要考虑数据备份、恢复和访问权限。
如果存储容量足够，但数据读取速度不能满足工作负载需求，系统仍可能受到影响。
不过，不能把所有 AI 场景都理解为高吞吐存储场景。不同任务的访问模式不同：训练、在线推理、知识检索和日志归档，对存储的要求并不相同。
存储规划应从数据访问模式出发，而不是只依据模型大小或服务器数量确定容量。
3. 网络：计算资源之间需要有效协作
网络负责连接计算节点、存储系统、模型服务和业务应用。
在单机推理场景中，网络可能主要影响请求接入、数据访问和服务调用。
在多节点训练或分布式计算场景中，节点之间还可能需要频繁交换数据，因此网络的带宽、时延、拓扑和稳定性可能对整体效率产生重要影响。
但网络并不是越贵、带宽越高就一定越好。
是否需要专门的高速互联方案，取决于工作负载、集群规模、通信模式、硬件架构和成本约束。
企业应当根据目标任务开展测试，而不是仅凭网络设备的规格判断最终效果。
4. 操作系统、驱动和容器：让硬件与软件能够协同运行
有了服务器和 GPU，还需要合适的软件环境才能运行 AI 工作负载。
常见组成包括：
操作系统； GPU 驱动； 相关计算运行库； 容器运行时； 模型框架及其依赖； 模型服务组件。
不同组件之间存在兼容关系。
例如，驱动版本、GPU 型号、容器运行环境和模型框架之间如果不匹配，可能导致模型无法启动、设备不可用或性能表现异常。
容器能够帮助封装应用及其依赖，降低环境差异带来的部署问题，但容器并不能自动解决所有兼容性、性能和安全问题。
因此，企业需要建立清晰的软件版本管理、环境配置和升级验证机制。
5. Kubernetes 与 GPU 调度：让资源可以被管理
当企业从单台服务器走向多台服务器、多种工作负载并行运行时，资源管理会变得更加复杂。
Kubernetes 是常见的容器编排平台，可以管理容器化应用的部署、调度和运行。
对于 GPU 工作负载，Kubernetes 可以通过设备插件机制识别和管理相应 GPU 资源，让工作负载在部署时申请所需资源。
Kubernetes 官方文档说明，相关 GPU 管理功能自 Kubernetes v1.26 起达到 Stable 状态。
原始资料：Kubernetes：Schedule GPUs
但这里需要区分三个概念：
容器： 提供应用运行环境的封装方式。 Kubernetes： 负责容器化工作负载的编排和资源调度。 GPU 管理组件： 帮助平台识别、暴露和管理 GPU 等设备资源。
它们协同工作，但不能相互替代。
NVIDIA GPU Operator 则展示了在 Kubernetes 环境中管理 GPU 驱动、设备插件及相关组件的方案。
原始资料：
NVIDIA GPU Operator
https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/
需要注意，Kubernetes 能够调度 GPU，不等于它自动解决了所有 GPU 共享、显存隔离、分布式训练或推理优化问题。具体能力还取决于硬件、驱动、插件、运行时和相关扩展方案。
对于企业项目经理，重要的不是记住所有组件名称，而是确认：
GPU 能否被平台正确识别； 工作负载能否申请到所需资源； 多个任务是否会发生资源争用； 资源使用情况是否能够监控； 驱动和软件升级是否经过兼容性验证； 出现节点故障时，系统如何处理。
6. 模型推理服务：让计算能力转化为可调用的服务
模型部署成功，并不意味着业务应用已经能够稳定使用它。
企业还需要一层推理服务，把模型执行能力封装成可调用的接口，并处理请求接入、执行、返回结果和运行管理。
NVIDIA Triton Inference Server 是这类软件的一个例子。其官方文档介绍了多种模型框架支持、请求调度、批处理、健康检查和性能指标等能力。
原始资料：
NVIDIA Triton Inference Server 官方文档
https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/index.html
这里要区分两个问题：
模型能不能运行？ 主要涉及模型、硬件和软件环境是否兼容。 模型服务能不能满足业务要求？ 还需要考虑并发、时延、错误率、资源利用率和运行稳定性。
这也是为什么企业验收不能只看“模型启动成功”，还应在约定的业务负载下进行测试。
四、为什么企业部署 AI 离不开基础设施？
理解了各组成部分，再来看它们为什么重要。
原因一：模型能力不等于业务服务能力
大模型可以提供文本理解、生成和推理等能力，但业务系统需要在实际环境中接收请求、访问数据、调用模型、处理结果并返回响应。
如果基础设施无法支撑预期负载，即使模型本身具备相应能力，业务应用也可能出现超时、排队或服务中断。
因此，企业真正需要的不是一个“能回答问题的模型”，而是一个能够在约定条件下持续提供服务的系统。
原因二：AI 工作负载会产生不同的资源需求
不同 AI 任务的资源需求可能有很大差异。
例如：
表格中的关注点是一般性的技术分析，不是对所有工作负载的绝对分类。具体资源需求仍需结合目标模型和测试结果确定。
AI 基础设施规划的核心，是让资源配置与业务负载相匹配，而不是一味追求最高算力。
原因三：系统性能取决于完整链路，而非单一硬件
假设一套模型服务响应速度不理想。
可能的原因包括：
模型推理本身需要较长时间； 请求过多，服务出现排队； 模型或中间数据受到显存限制； 数据读取和预处理效率不足； 网络通信成为瓶颈； 推理服务没有采用适合当前负载的调度方式。
这些只是可能的原因，并不能在没有测试的情况下确定某个系统的真实瓶颈。
这意味着，排查问题时需要观察完整链路，并结合监控数据、日志和负载测试定位原因。
MLCommons 的 MLPerf Inference 基准测试为比较不同系统在特定模型和测试条件下的推理性能提供了方法参考。
官方资料：
MLCommons：MLPerf Inference
https://mlcommons.org/working-groups/benchmarks/inference/
关键提醒：峰值算力、芯片规格或单次演示结果，都不能单独代表业务场景中的真实性能。
原因四：可靠性、安全和运维不能等到上线后再考虑
企业 AI 服务可能涉及内部制度、客户信息、项目数据和业务操作。
如果平台缺少可靠的身份认证、访问控制、监控告警和故障处理机制，即使模型运行正常，也可能无法满足企业的安全和运营要求。
基础设施规划应当考虑：
用户和服务的身份认证； 数据访问与网络隔离； 运行日志和异常告警； 资源容量及扩展策略； 备份与恢复要求； 软件版本和配置管理； 日常维护和故障责任分工。
这里需要注意，AI 基础设施本身并不自动保证系统安全。安全能力还需要通过架构设计、权限配置、应用控制和测试共同落实。
原因五：资源投入最终必须回到成本与业务价值
AI 基础设施的成本不仅是 GPU 或服务器的采购费用，还可能包括：
计算资源租用或折旧； 存储与网络； 电力和机房； 软件及相关服务； 平台部署与维护； 运维人员投入； 故障处理和升级成本。
对于云端服务，还应考虑调用量、资源使用方式、网络费用和服务条款等因素。
因此，不能简单得出“自建一定便宜”或“云端一定划算”的结论。
企业需要围绕实际工作负载、服务目标和统一的统计周期比较完整成本。
五、企业是否必须自建 GPU 集群？
这是 AI 基础设施选型中最值得先回答的问题之一。
答案是：不必须。
企业可以根据业务需求、数据要求、团队能力和成本约束，选择不同的部署方式。
三种常见部署方式
以上是分析框架，不是对三种方案成本或性能的实测结论。实际选择需要结合企业的具体约束进行评估。
企业应该如何选择？
可以从五个问题开始。
第一，模型是不是必须自己部署？
如果企业的需求可以通过满足安全和业务要求的模型 API 实现，就不必为了“拥有 AI 基础设施”而直接建设 GPU 集群。
第二，数据和合规要求是什么？
需要核查数据处理条款、部署区域、访问控制、数据保留和审计要求。不能仅凭“使用云服务”或“部署在内网”就直接判断是否合规。
第三，负载是否稳定？
如果调用量波动明显，需要评估不同方案在峰值、低谷和长期使用条件下的资源需求与成本。
第四，团队是否具备运维能力？
自建环境意味着企业需要承担更多软件兼容、故障排查、升级和容量管理工作。
第五，成本是否经过统一口径测算？
至少应明确比较周期、预计负载、资源利用率、人员投入、网络与存储费用，以及扩容和故障处理成本。
对尚处于 AI 探索阶段的企业，先验证业务场景、模型效果和实际负载，再决定是否需要自建基础设施，往往比先采购硬件更有利于控制风险。但对于有明确数据控制、持续负载或特殊部署要求的企业，也需要结合具体条件评估自建或混合架构。
六、项目经理如何规划 AI Infrastructure 项目？
对于项目经理而言，理解技术组成只是第一步，更重要的是将需求转化为可交付、可测试的项目计划。
建议采用以下六步。
第一步：明确业务场景和服务目标
先确定要支撑什么业务，而不是直接列出硬件采购清单。
例如，企业项目管理助手需要：
查询任务和延期任务； 检索项目管理制度； 生成项目健康报告； 在审批通过后发送风险通知； 记录运行日志和调用情况。
接下来需要明确用户规模、预期负载、响应时间要求、数据敏感程度，以及哪些操作必须经过人工审批。
如果这些条件没有明确，后续容量规划和技术选型就缺少依据。
第二步：梳理模型和工作负载
至少需要收集：
这些数据不必在项目启动时全部精确，但必须区分已经确认的需求、初步估算和仍需验证的假设。
第三步：进行资源评估和技术选型
根据目标模型和工作负载，评估 CPU、GPU、存储、网络和运行环境的需求。
对于大模型推理，还需要考虑显存占用、输入输出长度、并发、批处理和服务时延等因素。
这里不建议直接使用一个通用公式，推导所有企业都需要多少 GPU。
更稳妥的方法是：
选择候选模型； 明确目标硬件和软件版本； 建立代表性的测试负载； 测量吞吐量、时延和资源使用； 根据服务目标估算资源需求； 在预期峰值和合理冗余条件下验证容量。
没有目标模型和负载数据时，具体 GPU 数量应标注为待评估，而不是凭经验给出确定值。
第四步：建立部署与资源管理环境
根据所选方案，完成必要的环境部署和配置。
如果采用 Kubernetes 管理 GPU 工作负载，通常需要检查：
Kubernetes 版本和集群配置； GPU 驱动和设备插件； 容器运行环境； GPU 资源申请和调度； 模型部署与服务启动； 日志、监控和告警； 版本兼容与升级流程。
如果使用云端模型 API，则重点会转向服务接入、网络访问、身份认证、调用限额、错误处理和成本监控。
不同部署方式的实施范围不同，不应机械套用同一份技术清单。
第五步：开展性能、可靠性和安全测试
建议至少覆盖以下测试类别。
所有性能测试都应记录测试环境、模型版本、负载条件、统计方法和结果。
测试阈值需要根据业务需求确定。不能因为某个指标在测试中达到预期，就推断系统在所有环境下都具有相同表现。
第六步：建立持续运营机制
AI 基础设施上线后，仍然需要持续管理：
计算资源利用率； 模型服务的响应时间和错误率； 请求量及资源成本； 版本和配置变更； 容量增长与扩容计划； 安全更新和漏洞修复； 故障处理和恢复演练。
项目经理还应明确责任分工：谁负责基础设施，谁负责模型服务，谁负责应用，谁负责安全和运维。
否则，即使系统已经上线，一旦发生故障，也可能出现团队之间无法明确责任边界的问题。
七、一份可直接复用的 AI Infrastructure 项目检查清单
在启动企业 AI 基础设施项目时，可以用下面这份清单开展需求调研和项目评审。
A. 业务需求
明确 AI 应用场景和目标用户。 明确模型类型及部署方式。 明确平均负载、峰值负载和并发需求。 明确响应时间、吞吐量和可用性要求。 明确数据敏感程度及合规约束。
B. 技术架构
明确 CPU、GPU 或 NPU 的选择依据。 明确显存、内存、存储和网络需求。 明确操作系统、驱动、容器及模型框架版本。 明确是否需要 Kubernetes 或其他资源管理平台。 明确模型部署、推理服务和业务应用之间的接口。
C. 性能与容量
建立具有代表性的测试负载。 明确性能指标和统计方式。 验证峰值负载下的资源需求。 验证模型服务的时延和吞吐量。 明确容量不足时的扩容方案。
D. 安全与可靠性
完成身份认证和访问权限设计。 明确数据保护和网络访问控制要求。 建立监控、日志和异常告警。 明确备份、恢复和故障处理方案。 建立软件版本、补丁和变更管理流程。
E. 成本与运维
比较候选方案的完整成本。 明确资源使用和成本统计方式。 明确基础设施、模型服务和应用的责任边界。 明确日常巡检、故障处理和升级责任人。 明确后续容量评估和优化机制。
这份清单是项目规划参考，不是适用于所有场景的强制标准。企业应根据模型类型、部署方式、业务风险和服务目标增删条目。
八、结尾：真正需要建设的，是支撑业务的能力
回到最初的问题：AI Infrastructure 是什么？企业部署 AI 为什么离不开基础设施？
可以用三个判断来总结。
第一，AI Infrastructure 不只是 GPU。
它是计算、存储、网络、软件运行环境、资源管理和运行保障等能力的协同体系。
第二，企业不一定要自建基础设施，但必须解决基础设施问题。
无论采用云端模型 API、云端自部署还是企业自建环境，都需要明确性能、可靠性、安全、成本和运维责任。
第三，基础设施项目不能只按设备规格验收。
真正重要的是：在约定的模型、负载和业务条件下，系统能否达到目标性能，能否稳定运行，能否安全管理，并且能否在可接受的成本范围内持续运营。
对于项目经理而言，理解 AI Infrastructure，并不是为了成为硬件专家，而是为了能够将业务需求转化为技术要求，将技术要求转化为项目计划，再将项目计划转化为可验证的交付结果。
好的 AI 基础设施，不是把最先进的硬件堆在一起，而是让适当的资源、合适的软件和明确的管理机制，共同支撑真正需要的 AI 业务。
