AI 服务器采购避坑指南

概览

AI 服务器采购最常见的问题，是把采购动作简化成“买几张 GPU”。真正决定交付效果的是完整系统：GPU、CPU、PCIe、NVLink、网络、存储、供电、散热、驱动、容器、调度和模型服务框架。

这份指南用于把采购问题拆成可验收的技术清单，避免在报价阶段看起来规格很高，交付后却无法稳定跑训练或推理。

官方可确认的信息

NVIDIA H100、H200、L40S、HGX、DGX 等官方资料都明确区分 GPU、平台和整机系统。Kubernetes GPU 调度、NVIDIA GPU Operator、NCCL、Triton、vLLM 等官方文档也说明 AI 服务器不是纯硬件问题，而是硬件与软件栈共同决定可用性。

这些信息说明：采购时必须同时审查硬件规格和软件部署路径。

采购前先确认业务场景

AI服务器采购最关键的决策不是“买哪款GPU”，而是“业务场景需要怎样的计算系统”。一份完整的采购方案应覆盖GPU、CPU、PCIe拓扑、GPU互联、网络、存储、供电、散热、软件栈、交付验收和后续扩展等环节。本指南帮助技术决策者和采购负责人将采购问题拆解为可验证的检查项，避免出现“规格高、交付后无法稳定运行”的情况。

适用对象与不适用对象

适用对象

企业技术决策者、架构师、运维负责人
AI项目负责人、IT采购负责人
正在规划AI服务器采购、RAG私有化、推理服务器选型、训练服务器选型的技术团队

不适用对象

仅需了解GPU型号基本概念的用户
已完成完整系统测试、仅需单一GPU补货的团队
寻求“一键配置”方案的用户（本指南不提供未经测试的静态配置）

需求判断框架

采购前，需明确以下4个核心问题。如果这些问题的答案尚未确定，直接按GPU型号采购将面临较高风险。

问题	说明	决策影响
业务用途	训练、微调、推理、RAG，还是混合用途	决定GPU型号、互联等级和软件栈
模型规模与并发目标	模型参数规模、上下文长度、并发用户数	决定显存、显存带宽、并发处理能力
部署范围	单机、部门级平台，还是多机集群	决定网络拓扑、存储架构和调度系统
基础设施条件	机房供电容量、散热能力、网络和空间条件	决定服务器形态和是否需液冷

关键技术与配置维度

1. GPU型号精细化分析

需区分不同GPU的定位差异，直接从官方资料确认参数（如显存、带宽、功耗、互联和软件生态）。

建议重点关注维度：

显存容量与显存带宽（直接影响可承载模型规模和推理速度）
GPU互联方式（NVLink/NVSwitch等，影响多卡协同效率）
软件生态支持（CUDA版本、驱动、容器运行时等）

注意事项：

不推荐仅按单卡型号比较，需结合业务场景评估
消费级GPU与专业GPU在稳定性、驱动支持、多卡扩展上存在差异
国产算力需确认驱动、CUDA适配层或ROCm的可用性

2. CPU与PCIe拓扑

CPU型号、PCIe通道数量、NUMA节点布局、网卡和NVMe硬盘位置，会影响数据加载、网络通信和多卡稳定性。

检查要点：

确认PCIe通道数是否满足GPU、网卡、NVMe的总需求
评估NUMA架构下GPU与CPU之间的内存访问延迟
确认网卡和NVMe是否与GPU位于同一NUMA域（避免跨域通信）

3. GPU互联（NVLink/NVSwitch）

训练和大模型推理场景需重点评估互联等级；单卡推理或多副本推理场景对互联要求相对较低。

决策建议：

训练服务器：应优先选择支持NVLink/NVSwitch的GPU节点（如8-GPU HGX平台）
推理服务器：单卡推理可接受较低互联等级；跨卡推理需评估张量并行、流水线并行的互联需求
多服务器集群：需配合InfiniBand或高质量RoCE网络

4. 网络与存储

多机训练场景通常需要InfiniBand或高质量RoCE网络；RAG、训练数据和Checkpoint存储会对NVMe、共享存储和网络吞吐提出要求。

检查要点：

网络：带宽（例如400Gbps/200Gbps InfiniBand）、延迟、丢包率
存储：NVMe容量和IOPS（用于模型加载、数据缓存）、共享存储（NFS/GPFS/Lustre）的吞吐和可用性
网络拓扑：是否支持无阻塞架构（例如Fat-Tree或Dragonfly）

5. 电力与散热

高端GPU服务器可能受机柜供电、风冷能力或液冷条件限制。不能只看服务器标称功耗。

检查要点：

确认机柜供电容量（例如单机柜40A/60A/100A）
评估风冷能力（例如单机柜散热功率上限）
如选液冷方案，需提前确认液冷基础设施条件（管路、CDU、二次侧温度等）

6. 软件栈

验收时需确认驱动、CUDA/ROCm、容器运行时、Kubernetes/Slurm、NCCL、vLLM、TensorRT-LLM或Triton是否形成可复现的版本组合。

检查要点：

明确各软件组件的兼容版本（例如CUDA 12.1与驱动535.129的对应关系）
测试GPU调度能力（Kubernetes GPU Operator或Slurm的GPU管理）
验证网络通信性能（NCCL测试）
确认推理框架（vLLM/TensorRT-LLM/Triton）与模型的适配版本

分阶段实施路径

第一阶段：需求评估与方案设计

完成需求判断框架（见上文）
整理模型清单（含参数规模、精度、上下文长度、并发目标）
评估现有机房条件（供电、散热、空间）
输出《硬件配置建议书》和《软件栈需求清单》

第二阶段：硬件部署与验收

执行验收标准（见后文）
完成GPU、CPU、网络、存储的基础测试
验证GPU互联、多卡通信和网络性能
输出《硬件验收报告》

第三阶段：环境搭建与联调测试

部署操作系统、驱动、CUDA/ROCm、容器运行时
搭建调度系统（Kubernetes/Slurm）
验证训练/推理框架与模型的适配
进行负载测试（吞吐、延迟、稳定性）
输出《环境联调测试报告》

第四阶段：上线运维与扩展规划

建立监控体系（GPU利用率、显存、温度、网络流量）
制定故障处理和扩展计划
定期评估算力利用率，规划扩容节奏

配置或架构方向

以下为采购估算方向，不是固定配置清单，实际配置需结合需求评估和供应商咨询。

训练服务器配置方向

GPU：8-GPU节点，支持NVSwitch
网络：400Gbps InfiniBand或高质量RoCE
存储：NVMe + 共享存储（如Lustre/GPFS）
调度系统：Slurm或Kubernetes + GPU Operator
软件栈：NCCL + 训练框架（如DeepSpeed、Megatron-LM）

推理服务器配置方向

GPU：根据模型显存预算选择，优先高显存带宽的GPU（如H200、L40S）
网络：多节点推理需InfiniBand或RoCE，单节点可接受低带宽网络
推理框架：vLLM、TensorRT-LLM、Triton
调度系统：Kubernetes + GPU Operator

RAG系统配置方向

需拆分Embedding、向量库、reranker和生成层，不应只按主模型估算GPU
Embedding和向量库对GPU要求较低（可CPU部署或低端GPU）
生成层需按主模型推理要求单独配置
存储需保证文档处理、索引和检索的性能

风险与避坑清单

风险项	典型表现	规避措施
显存估算不足	选定GPU但模型加载失败	提前进行显存预算，结合量化、上下文长度和batch size估算
互联瓶颈	多卡训练性能不达预期	评估NVLink/NVSwitch等级，配合NCCL测试
网络瓶颈	多机训练或推理时通信超时	确认带宽、延迟、丢包率，配合InfiniBand或高质量RoCE
供电散热不足	服务器降频或宕机	提前核算机柜供电容量和散热能力，【待核验】需以机房实际条件为准
软件栈不兼容	驱动/CUDA/框架无法正常工作	在验收阶段完成版本组合测试
交付与验收不一致	到货配置与合同不符	严格执行验收标准，逐项检查

验收标准

采购合同或验收清单至少应包含以下验收指标【待核验】：验收内容需以供应商提供的官方测试环境和合同条款为准。

验收项	验收方法	通过标准
GPU识别与基本功能	nvidia-smi / rocm-smi	所有GPU正确识别，无报错
GPU互联	nvidia-smi topo -m / nvlink-status	NVLink/NVSwitch正确连接，带宽达预期
网络通信	NCCL测试（如allreduce/allgather）	带宽达预期，无异常重传
存储性能	fio测试	IOPS和吞吐达预期
供电散热	满负载运行1小时	GPU温度不超过供应商规定值
软件栈兼容	完整环境部署测试	驱动、CUDA/ROCm、调度、推理框架可协同工作

后续扩展建议

定期（如每季度）评估算力利用率，根据业务增长规划扩容节奏
关注GPU驱动、CUDA/ROCm和推理框架的版本更新，保持兼容性
建立模型部署清单，记录每个模型使用的GPU、显存、精度、上下文长度等参数，便于后续选型参考
如业务扩展至更大规模集群，需提前规划网络拓扑、存储架构和调度系统的扩展路径

选型支持

需要基于实际项目做选型判断？

结合模型、数据、预算和机房条件，形成更具体的采购与部署建议。

获取选型建议查看 AI 解决方案