过去几年AI 行业经历了一轮又一轮的洗牌从大模型的参数竞赛到 AI 应用层的密集落地再到算力基础设施的规模化建设每一层都涌入了大量玩家。如果仔细观察会发现一个非常明显的趋势原本以 PC、服务器、存储设备为核心业务的传统硬件厂商正在集体向 AI 基础设施公司转型。联想就是其中一个典型代表。这篇文章不打算讨论联想股价涨跌也不做商业模式的宏观分析。我更想从技术工程师的视角把“AI 基础设施公司”这个概念拆开来看它到底包含哪些技术栈联想这类硬件厂商转型的背后技术逻辑是什么如果一家普通企业想搭自己的 AI 基础设施应该从哪些方面着手中间会踩到哪些坑1. 联想转型背后的行业逻辑1.1 从“卖设备”到“卖基础设施”过去联想的核心业务非常清晰PC、笔记本、服务器、存储。卖设备本质上是一次性交易客户买回去自己安装、调试、维护厂商提供质保和售后就结束了。但 AI 时代不一样。企业上 AI 项目买几台 GPU 服务器只是第一步后面还有驱动安装、CUDA 环境配置、模型部署、推理性能调优、弹性扩缩容、成本核算等一系列问题。绝大多数企业并没有一个成熟的 AI 运维团队来支撑这些工作。这就催生了“AI 基础设施”这个概念。它不再只是硬件堆砌而是把算力、存储、网络、调度平台、模型服务封装成一种可以被上层应用直接调用的能力。硬件厂商如果还停留在“交钥匙交付”的模式会逐渐失去在 AI 产业链中的话语权因为利润会往基础设施服务商和模型平台方转移。联想不断向 AI 基础设施公司靠拢本质上是在做一次价值链迁移从硬件供应商转向 AI 算力与服务方案的整合者。1.2 AI 基础设施到底包含什么AI 基础设施不是单一产品而是一整套技术栈的组合。按层次来划分大致可以分成五层。最底层是物理硬件层包括 GPU 服务器、CPU 服务器、存储阵列、交换机、液冷系统、机房供电和散热设施。这一层是联想传统业务的强项。往上一层是系统软件层包括操作系统、GPU 驱动、CUDA 工具包、容器运行时、Kubernetes 调度系统。这一层是 AI 基础设施真正“软件化”的开始。再往上是平台服务层包括模型训练平台、推理服务平台、数据管理平台、模型仓库。这一层解决的是“如何让算法工程师方便地用上算力”的问题。接着是模型与算法层包括基础大模型、行业模型、微调工具链、RAG 框架、Agent 框架。这一层贴近业务通常由 AI 应用团队负责。最上层是业务应用层也就是最终面向用户的产品比如智能客服、AI 编程助手、智能数据分析等。一个真正的 AI 基础设施公司需要具备从底层到上层至少前三层的完整能力而不是只卖底层硬件。1.3 为什么硬件厂商很难被替代做 AI 基础设施硬件厂商有一个天然的门槛工程化能力。GPU 服务器不是简单地把显卡插进机箱就行。供电设计、散热设计、PCIe 拓扑、NVLink 互联、高速网络、稳定性测试每一样都需要深厚的硬件工程积累。AI 训练集群动辄几十台到上千台 GPU 服务器长时间满负荷运行对散热和供电的要求远高于普通数据中心。液冷就是一个典型方向。A100/H100 这类高功耗 GPU单卡功耗已经到 400W 甚至 700W 以上风冷方案在超高密度场景下会遇到散热瓶颈。液冷服务器、冷板式液冷机柜、浸没式液冷系统这些不是软件公司能随便做出来的需要长期的材料、流体、结构设计经验。联想在这方面的积累是几十年硬件制造和供应链管理沉淀下来的。这种工程基因恰恰是很多 AI 创业公司最缺的部分。2. AI 基础设施的核心技术栈拆解根据联想近年的产品布局和行业趋势AI 基础设施的技术栈可以从算力、存储、网络、软件平台四个维度展开。2.1 算力层GPU 服务器与异构计算算力层是 AI 基础设施最核心的组成部分。训练大模型需要大规模 GPU 集群推理服务需要高吞吐、低延迟的 GPU 或 NPU 资源。异构计算的概念也在这里体现一块 AI 训练集群里可能同时存在 GPU、CPU、DPU不同芯片各司其职。对于不太熟悉 AI 硬件的开发者可以先建立这样一个认知GPU 服务器和普通服务器的区别主要在 PCIe 通道、电源功率和散热设计上。以一台典型的 8 卡 GPU 服务器为例它的配置结构通常如下组件典型配置说明CPU双路 Intel Xeon 或 AMD EPYC负责数据预处理、调度、通信GPU8 x NVIDIA A100/H800 或国产加速卡承担张量计算内存512GB - 2TB DDR5供 CPU 侧使用容量越大越好系统盘2 x 480GB SSDRAID1安装操作系统数据盘8 x 3.84TB NVMe SSD存放训练数据集和模型权重网络8 x 25GbE 或 4 x 100GbE多机并行训练时的通信通道电源4 x 3000W 冗余电源8 卡 GPU 满负荷功耗非常惊人值得注意的是GPU 服务器的真实算力并不取决于 GPU 卡的数量还取决于卡间通信带宽。8 张卡如果只是通过 PCIe 连接通信效率比较低如果通过 NVLink 全互联数据交换速度会显著提升。这也是为什么高端 AI 服务器的价格差距如此之大。2.2 存储层高性能数据存储AI 训练过程中数据读取速度常常成为瓶颈。GPU 计算速度太快如果数据还在硬盘上慢慢读整个训练流程就会被拖慢。AI 场景下的存储方案通常分为三层热数据层常用数据集和 checkpoint存放在 NVMe SSD 或高性能并行文件系统上比如 Lustre、BeeGFS、JuiceFS。温数据层中间产物、离线数据集存放在大容量 HDD 或对象存储中。冷数据层历史数据、备份数据存放在低成本对象存储或磁带库中。企业在建设 AI 基础设施时容易犯的一个错误是只关注 GPU 的算力忽略了存储性能。结果训练任务一启动数据加载就花了几个小时GPU 长期处于等待状态利用率极低。2.3 网络层无损网络与 RDMA分布式训练是 AI 基础设施绕不开的话题。当模型参数规模超过单卡显存时必须把模型切分到多张卡、多台服务器上并行训练这时候网络通信的延迟和带宽直接决定训练效率。传统的 TCP/IP 网络在 AI 场景下存在高延迟、CPU 开销大的问题。现在主流方案是 RDMARemote Direct Memory Access网络让数据绕过 CPU 直接在网卡和内存之间传输。常见实现包括 InfiniBand 和 RoCEv2。在一个大规模 AI 集群中网络分区建议如下存储网络25GbE / 100GbE支持 RoCE用于访问共享存储计算网络InfiniBand NDR 或 RoCEv2用于 GPU 间通信管理网络1GbE / 10GbE用于 IPMI 带外管理和 SSH 登录很多人忽略的一点是RDMA 网络对交换机配置要求很高。如果配置不当会出现丢包问题而 RDMA 对丢包非常敏感一旦丢包性能会断崖式下降。这个后面在常见问题部分会详细说。2.4 软件层调度平台与模型部署有了硬件资源还需要一套软件平台把它们管起来。目前行业内的主流方案是 Kubernetes AI 调度插件。Kubernetes 负责资源编排AI 调度器负责感知 GPU 资源、队列优先级、任务亲和性。典型的一个 AI 平台软件栈如下资源层Kubernetes NVIDIA Device Plugin GPU Feature Discovery调度层Volcano、Kueue、Koordinator训练层PyTorch / TensorFlow Horovod / DeepSpeed推理层Triton Inference Server、vLLM、TensorRT-LLM数据层MinIO / JuiceFS / Weaviate这个软件栈的价值在于算法工程师不再需要关心底层 GPU 服务器长什么样只需要通过平台提交训练任务系统会自动分配资源。3. 联想 AI 基础设施布局的三个关键方向联想的 AI 基础设施布局可以从产品、方案、生态三个层面来理解。3.1 从 AI 服务器到液冷方案联想很早就推出了 AI 服务器产品线包括面向训练和推理的不同系列。与普通服务器相比AI 服务器的核心差异在于异构计算支持、GPU 拓扑优化和散热设计。液冷是联想布局比较早的方向。随着单 GPU 功耗持续上涨传统风冷方案在超过一定功率密度后无论是散热效率还是噪音控制都难以满足数据中心要求。联想推出的冷板式液冷方案通过水冷板直接接触 CPU、GPU 等发热元件将热量带走。这种方式相比风冷PUE 可以显著降低帮助数据中心降低电力成本。从技术角度讲液冷并不仅仅是把水循环系统接进机柜那么简单需要关注冷却液类型、管路材质、防漏检测、维护便利性等一系列问题。企业如果选择液冷方案需要评估自己的机房是否具备改造条件而不是盲目跟风。3.2 AI PC 与边缘基础设施除了数据中心侧的 AI 基础设施联想的另一条线是 AI PC。所谓 AI PC是指内置 NPU 的笔记本电脑可以在本地运行大语言模型和 AI 应用不依赖云端。从基础设施的视角看AI PC 是“端侧推理基础设施”。在隐私保护、网络不稳定、实时性要求高的场景中端侧推理有不可替代的价值。比如企业内部处理敏感文档不希望把数据传到云端再比如随时随地需要一个 AI 助手但又不想依赖手机流量。端侧 AI 的技术挑战在于模型压缩和推理优化。一个几十 GB 的大模型直接跑在笔记本上是不现实的需要通过量化、剪枝、蒸馏等技术将模型压缩到几个 GB 甚至几百 MB。这也是联想要自研 AI 模型压缩工具链的原因。3.3 混合式 AI 的落地形态联想这几年一直在推一个概念叫“混合式 AI”核心意思是 AI 能力不应只存在于云端也不应只存在于端侧而是应该根据业务场景在云、边、端之间动态分配计算任务。这种架构下基础设施的形态是多样的训练和重模型推理放在云端或企业私有化机房轻量推理放在边缘节点如工厂产线、零售门店实时响应放在端侧设备如 AI PC、AI 手机、智能摄像头混合式 AI 对基础设施提出了更高要求。因为它需要一套统一的调度管理系统去管理不同位置的算力节点同时还要打通云端和端侧的模型分发通道。从工程角度讲这是一套比纯云或纯端复杂得多的体系。4. 企业构建自己的 AI 基础设施从零到一的实战路径不管联想等厂商怎么布局对大多数企业来说真正的问题不是“联想怎么做”而是“我们自己怎么搭一套 AI 基础设施”。这一节从工程实操的角度给出一条比较完整的落地路径。4.1 需求评估与算力规划不要一上来就买设备。先回答下面这些问题你的业务需要训练模型还是只需要推理训练模型预计有多大参数量在几亿、几十亿还是千亿级别需要支持多少并发请求目标响应时延是多少数据量级是多少存储在本地还是对象存储业务对数据隐私有什么要求能不能用公有云答案不同基础设施的规模完全不同。一个原则是推理需求比训练需求更容易起步。如果只是把开源模型部署成内部工具一台 24GB 显存的中端 GPU 服务器就能撑起小团队的日常使用但如果需要训练千亿参数模型起步就是几十台 8 卡高端服务器。4.2 硬件选型与部署以一个小型 AI 推理集群为例硬件层面需要准备以下设备设备用途建议配置GPU 服务器模型推理2 张 RTX 4090 或 1 张 A100 40G存储服务器模型和数据存放4 块 4TB NVMe SSD组 RAID10接入交换机服务器互联万兆交换机支持 RoCE管理终端运维操作任意一台笔记本即可服务器到位后的初始化流程可以按下面的顺序操作先安装操作系统推荐 Ubuntu Server 22.04 LTS 或更新的 LTS 版本。安装时文件系统建议选择 ext4 或 xfs并单独划分/data分区存放模型文件。然后是 BIOS 设置优化打开 Resizable BAR 和 Above 4G Decoding确保 GPU 能利用完整显存关闭不必要的节能策略避免训练时性能不稳定。接着安装 NVIDIA 驱动和 CUDA。推荐使用 runfile 方式安装可以避免 apt 源版本冲突。安装前先卸载旧驱动# 卸载旧版 NVIDIA 驱动 sudo apt purge nvidia* -y sudo apt autoremove -y # 安装依赖 sudo apt update sudo apt install build-essential dkms linux-headers-$(uname -r) -y # 禁用到 nouveau 驱动 echo blacklist nouveau | sudo tee /etc/modprobe.d/blacklist-nouveau.conf echo options nouveau modeset0 | sudo tee -a /etc/modprobe.d/blacklist-nouveau.conf sudo update-initramfs -u安装完成后将驱动模块加载进系统# 重启后确认驱动生效 nvidia-smi如果nvidia-smi能显示出 GPU 型号和显存大小说明驱动安装成功。接下来需要安装 CUDA Toolkit。注意 CUDA 版本要和深度学习框架兼容不要盲目装最新。4.3 基础运行环境配置GPU 驱动就绪后需要配置容器运行环境。推荐用 Docker 来运行 AI 模型这样可以做到环境隔离和快速迁移。先安装 Docker 和 NVIDIA 容器工具包# 安装 docker以 Ubuntu 为例 curl -fsSL https://get.docker.com | sudo sh sudo usermod -aG docker $USER # 安装 NVIDIA Container Toolkit distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt update sudo apt install -y nvidia-container-toolkit # 重启 docker sudo systemctl restart docker验证容器能否使用 GPUdocker run --rm --gpus all nvidia/cuda:12.0-base nvidia-smi如果输出 GPU 信息说明 Docker 已经可以从容器内部访问显卡了。4.4 部署一个实际的推理服务环境和工具链就绪后下面用一个实际案例来演示推理服务的部署流程。假设我们要部署一个 Llama 系列的 7B 模型提供文本生成能力。使用 vLLM 作为推理引擎它的性能比原生 Hugging Face 的 transformers 高出不少而且兼容 OpenAI API 格式方便集成到现有代码中。创建一个工作目录编写 Dockerfile# 文件路径workdir/Dockerfile.vllm FROM nvidia/cuda:12.1.0-runtime-ubuntu22.04 ENV DEBIAN_FRONTENDnoninteractive RUN apt update apt install -y python3-pip git \ pip3 install vllm WORKDIR /app COPY serve.py /app/serve.py EXPOSE 8000 CMD [python3, /app/serve.py]编写启动脚本serve.py# 文件路径workdir/serve.py from vllm import LLM, SamplingParams # 加载模型这里模型路径按实际修改 llm LLM(model/data/models/llama2-7b-chat-hf) # 测试一次推理 prompt 请介绍一下人工智能的发展历史。 output llm.generate([prompt], SamplingParams(max_tokens512)) print(output[0].outputs[0].text)构建并运行容器docker build -t vllm-demo -f Dockerfile.vllm . docker run --gpus all -v /data/models:/data/models vllm-demo如果模型文件已经存在于宿主机/data/models目录容器启动后就会加载模型并输出推理结果。之后可以在此基础上封装成 HTTP 服务使用 FastAPI 或 vLLM 自带的 OpenAI 兼容接口。4.5 GPU 资源管理与监控AI 基础设施一旦运行起来监控是必不可少的。至少需要关注 GPU 利用率、显存占用、温度、功耗四个核心指标。写一个简单的 Python 脚本定期采集 GPU 状态并写入日志# 文件路径monitor/gpu_monitor.py import subprocess import time def get_gpu_info(): result subprocess.run( [nvidia-smi, --query-gpuindex,name,utilization.gpu,memory.used,memory.total,temperature.gpu,power.draw, --formatcsv,noheader,nounits], capture_outputTrue, textTrue ) return result.stdout.strip() if __name__ __main__: while True: info get_gpu_info() timestamp time.strftime(%Y-%m-%d %H:%M:%S) print(f[{timestamp}]\n{info}\n, flushTrue) time.sleep(10)更完整的方案是接入 Prometheus Grafana通过nvidia_gpu_exporter暴露 GPU 指标。不过对于一个小型基础设施用脚本做基础监控已经足够发现问题了。5. AI 基础设施常见问题与排查思路建设中踩坑是难免的。这里整理几个高频问题按“现象 → 原因 → 解决方案”的思路给出。问题现象常见原因解决思路GPU 利用率长期为 0%但训练任务在跑数据加载是瓶颈GPU 在等数据检查数据读取路径改用并行数据加载增加数据缓存多机训练速度远低于预期RDMA 网络丢包或未启用 RDMA检查交换机 RoCE 配置使用ib_write_bw测试带宽Docker 容器内无法识别 GPUNVIDIA Container Toolkit 未安装或版本不符重新安装 nvidia-container-toolkit重启 Docker训练时显存不足 OOM模型过大或 batch size 设置过大启用梯度累积降低 batch size使用模型并行策略服务器噪音大、温度高风冷方案已到极限考虑液冷方案或者降低机房功率密度vLLM 推理时报 CUDA errorCUDA 版本与 PyTorch 版本不匹配统一使用 PyTorch 官方镜像中的 CUDA 版本存储空间被 checkpoint 占满训练过程保存太多 checkpoint设置 checkpoint 清理策略只保留最近 N 个版本其中RDMA 网络配置问题是最隐蔽的。这里给一个排查思路先用ibstat检查 IB 设备状态确认物理链路正常。然后用ib_write_bw做带宽测试对比实际带宽和理论值。如果带宽明显偏低大概率是 DSCP 优先级或 PFC 流控配置不正确。RoCEv2 网络对交换机的要求是必须开启 PFC优先级流控否则拥塞时直接丢包导致性能暴跌。对于不走 InfiniBand 的普通千兆网络环境如果只是单机推理问题不大但一旦涉及多机并行训练网络就必须升级到 RoCE 或 InfiniBand这是省不掉的成本。6. 最佳实践与工程建议AI 基础设施建设和普通软件项目不太一样它涉及硬件、系统、框架、业务多个层面工程规范尤其重要。下面按几个维度给出建议。6.1 算力资源管理永远不要把 GPU 资源直接暴露给所有人。建议建立项目制和队列制。每个项目申请资源时设置配额上限训练任务提交到队列中按优先级调度。Kubernetes 配合 Volcano 或 Kueue 可以实现这个效果。简单场景下也可以先用资源清单表格管理人工分配。无论如何要保证两点一是 GPU 不能闲置浪费二是不能让单个任务独占所有资源拖垮整个集群。6.2 模型与数据版本管理模型文件和数据集的版本管理在 AI 基础设施中经常被忽略。训练时用了什么数据集、模型结构是什么、超参数是什么都必须有记录。否则一个月后回看根本无法复现实验结果。推荐的做法是数据集使用 DVC 或 JuiceFS 做版本管理模型权重放到 Model Registry 中如 MLflow、Hugging Face Hub 私有仓库训练参数通过配置文件管理写入 Git6.3 安全与权限边界AI 基础设施安全很重要尤其是模型接口。部署推理服务时至少要做到鉴权请求必须携带 API Token不能裸奔限流防止单个用户打爆推理服务数据隔离不同项目的模型和数据集放在不同命名空间审计记录谁在什么时候提交了什么训练任务、调用了哪些模型一个简单的 Nginx 反代配置可以帮助后端推理服务做一层基础防护# 文件路径nginx/conf.d/ai-gateway.conf upstream vllm_backend { server 127.0.0.1:8000; } server { listen 80; server_name ai-inference.internal; location /v1/ { proxy_pass http://vllm_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 简单的 Token 校验 if ($http_authorization ! Bearer your-internal-token) { return 401; } } # 限流每分钟 100 个请求 limit_req_zone $binary_remote_addr zoneai_limit:10m rate100r/m; limit_req zoneai_limit burst20 nodelay; }6.4 容错与高可用AI 训练任务动辄运行数天甚至数周中途失败是常态。基础设施必须支持断点续训。PyTorch 的 checkpoint 机制是基础但更重要的是基础设施层面要能自动感知节点故障重新调度任务避免人工盯场。推理服务的高可用也需要注意。可以在推理服务前面加一层负载均衡并保留 1.5 倍的冗余容量以应对高并发和单节点故障。6.5 成本控制AI 基础设施的成本不仅包括硬件采购还包括电力、制冷、运维人工。很多团队在采购 GPU 时只对比显卡单价忽略了后续运营成本。一个实用的建议是先按最小可行规模建设跑通流程后再扩展。如果公有云资源充足初期完全可以先用云 GPU 实例验证需求等模型稳定、调用量上来之后再考虑私有化部署。7. 给技术团队的建议联想向 AI 基础设施公司靠拢背后是整个行业的算力需求结构在发生变化。对技术团队来说与其纠结“要不要自己买 GPU”不如把精力放在这几个方向上第一掌握 AI 基础设施的基本运维能力。不需要成为硬件专家但至少要会装驱动、懂 Docker、会用 Kubernetes、能快速部署一个开源模型。这套技能组合在未来很长一段时间内都会非常稀缺。第二建立标准化的部署流程。把模型部署从“手工试错”变成“一键执行”需要把 Docker 镜像、依赖版本、启动参数、健康检查全部固化下来。这样无论是本机开发还是生产部署行为都是一致的。第三让基础设施具备可观测性。GPU 利用率、推理延迟、请求成功率、存储吞吐这些指标必须持续采集。没有监控的 AI 基础设施等于在黑暗中驾驶飞机。第四关注边缘推理和绿色计算。不是所有推理场景都需要上千瓦的 GPU 服务器能效比会越来越重要。液冷、NPU、量化压缩这些技术会逐步成为 AI 基础设施的主流配置。这一轮 AI 基础设施的升级会持续相当长的时间。对身处其中的开发者来说这是一次难得的技术体系升级窗口。早一步把 AI 基础设施的工程能力补齐后面做项目时就会从容很多。
从硬件到AI基础设施：企业构建GPU算力平台的全栈指南
过去几年AI 行业经历了一轮又一轮的洗牌从大模型的参数竞赛到 AI 应用层的密集落地再到算力基础设施的规模化建设每一层都涌入了大量玩家。如果仔细观察会发现一个非常明显的趋势原本以 PC、服务器、存储设备为核心业务的传统硬件厂商正在集体向 AI 基础设施公司转型。联想就是其中一个典型代表。这篇文章不打算讨论联想股价涨跌也不做商业模式的宏观分析。我更想从技术工程师的视角把“AI 基础设施公司”这个概念拆开来看它到底包含哪些技术栈联想这类硬件厂商转型的背后技术逻辑是什么如果一家普通企业想搭自己的 AI 基础设施应该从哪些方面着手中间会踩到哪些坑1. 联想转型背后的行业逻辑1.1 从“卖设备”到“卖基础设施”过去联想的核心业务非常清晰PC、笔记本、服务器、存储。卖设备本质上是一次性交易客户买回去自己安装、调试、维护厂商提供质保和售后就结束了。但 AI 时代不一样。企业上 AI 项目买几台 GPU 服务器只是第一步后面还有驱动安装、CUDA 环境配置、模型部署、推理性能调优、弹性扩缩容、成本核算等一系列问题。绝大多数企业并没有一个成熟的 AI 运维团队来支撑这些工作。这就催生了“AI 基础设施”这个概念。它不再只是硬件堆砌而是把算力、存储、网络、调度平台、模型服务封装成一种可以被上层应用直接调用的能力。硬件厂商如果还停留在“交钥匙交付”的模式会逐渐失去在 AI 产业链中的话语权因为利润会往基础设施服务商和模型平台方转移。联想不断向 AI 基础设施公司靠拢本质上是在做一次价值链迁移从硬件供应商转向 AI 算力与服务方案的整合者。1.2 AI 基础设施到底包含什么AI 基础设施不是单一产品而是一整套技术栈的组合。按层次来划分大致可以分成五层。最底层是物理硬件层包括 GPU 服务器、CPU 服务器、存储阵列、交换机、液冷系统、机房供电和散热设施。这一层是联想传统业务的强项。往上一层是系统软件层包括操作系统、GPU 驱动、CUDA 工具包、容器运行时、Kubernetes 调度系统。这一层是 AI 基础设施真正“软件化”的开始。再往上是平台服务层包括模型训练平台、推理服务平台、数据管理平台、模型仓库。这一层解决的是“如何让算法工程师方便地用上算力”的问题。接着是模型与算法层包括基础大模型、行业模型、微调工具链、RAG 框架、Agent 框架。这一层贴近业务通常由 AI 应用团队负责。最上层是业务应用层也就是最终面向用户的产品比如智能客服、AI 编程助手、智能数据分析等。一个真正的 AI 基础设施公司需要具备从底层到上层至少前三层的完整能力而不是只卖底层硬件。1.3 为什么硬件厂商很难被替代做 AI 基础设施硬件厂商有一个天然的门槛工程化能力。GPU 服务器不是简单地把显卡插进机箱就行。供电设计、散热设计、PCIe 拓扑、NVLink 互联、高速网络、稳定性测试每一样都需要深厚的硬件工程积累。AI 训练集群动辄几十台到上千台 GPU 服务器长时间满负荷运行对散热和供电的要求远高于普通数据中心。液冷就是一个典型方向。A100/H100 这类高功耗 GPU单卡功耗已经到 400W 甚至 700W 以上风冷方案在超高密度场景下会遇到散热瓶颈。液冷服务器、冷板式液冷机柜、浸没式液冷系统这些不是软件公司能随便做出来的需要长期的材料、流体、结构设计经验。联想在这方面的积累是几十年硬件制造和供应链管理沉淀下来的。这种工程基因恰恰是很多 AI 创业公司最缺的部分。2. AI 基础设施的核心技术栈拆解根据联想近年的产品布局和行业趋势AI 基础设施的技术栈可以从算力、存储、网络、软件平台四个维度展开。2.1 算力层GPU 服务器与异构计算算力层是 AI 基础设施最核心的组成部分。训练大模型需要大规模 GPU 集群推理服务需要高吞吐、低延迟的 GPU 或 NPU 资源。异构计算的概念也在这里体现一块 AI 训练集群里可能同时存在 GPU、CPU、DPU不同芯片各司其职。对于不太熟悉 AI 硬件的开发者可以先建立这样一个认知GPU 服务器和普通服务器的区别主要在 PCIe 通道、电源功率和散热设计上。以一台典型的 8 卡 GPU 服务器为例它的配置结构通常如下组件典型配置说明CPU双路 Intel Xeon 或 AMD EPYC负责数据预处理、调度、通信GPU8 x NVIDIA A100/H800 或国产加速卡承担张量计算内存512GB - 2TB DDR5供 CPU 侧使用容量越大越好系统盘2 x 480GB SSDRAID1安装操作系统数据盘8 x 3.84TB NVMe SSD存放训练数据集和模型权重网络8 x 25GbE 或 4 x 100GbE多机并行训练时的通信通道电源4 x 3000W 冗余电源8 卡 GPU 满负荷功耗非常惊人值得注意的是GPU 服务器的真实算力并不取决于 GPU 卡的数量还取决于卡间通信带宽。8 张卡如果只是通过 PCIe 连接通信效率比较低如果通过 NVLink 全互联数据交换速度会显著提升。这也是为什么高端 AI 服务器的价格差距如此之大。2.2 存储层高性能数据存储AI 训练过程中数据读取速度常常成为瓶颈。GPU 计算速度太快如果数据还在硬盘上慢慢读整个训练流程就会被拖慢。AI 场景下的存储方案通常分为三层热数据层常用数据集和 checkpoint存放在 NVMe SSD 或高性能并行文件系统上比如 Lustre、BeeGFS、JuiceFS。温数据层中间产物、离线数据集存放在大容量 HDD 或对象存储中。冷数据层历史数据、备份数据存放在低成本对象存储或磁带库中。企业在建设 AI 基础设施时容易犯的一个错误是只关注 GPU 的算力忽略了存储性能。结果训练任务一启动数据加载就花了几个小时GPU 长期处于等待状态利用率极低。2.3 网络层无损网络与 RDMA分布式训练是 AI 基础设施绕不开的话题。当模型参数规模超过单卡显存时必须把模型切分到多张卡、多台服务器上并行训练这时候网络通信的延迟和带宽直接决定训练效率。传统的 TCP/IP 网络在 AI 场景下存在高延迟、CPU 开销大的问题。现在主流方案是 RDMARemote Direct Memory Access网络让数据绕过 CPU 直接在网卡和内存之间传输。常见实现包括 InfiniBand 和 RoCEv2。在一个大规模 AI 集群中网络分区建议如下存储网络25GbE / 100GbE支持 RoCE用于访问共享存储计算网络InfiniBand NDR 或 RoCEv2用于 GPU 间通信管理网络1GbE / 10GbE用于 IPMI 带外管理和 SSH 登录很多人忽略的一点是RDMA 网络对交换机配置要求很高。如果配置不当会出现丢包问题而 RDMA 对丢包非常敏感一旦丢包性能会断崖式下降。这个后面在常见问题部分会详细说。2.4 软件层调度平台与模型部署有了硬件资源还需要一套软件平台把它们管起来。目前行业内的主流方案是 Kubernetes AI 调度插件。Kubernetes 负责资源编排AI 调度器负责感知 GPU 资源、队列优先级、任务亲和性。典型的一个 AI 平台软件栈如下资源层Kubernetes NVIDIA Device Plugin GPU Feature Discovery调度层Volcano、Kueue、Koordinator训练层PyTorch / TensorFlow Horovod / DeepSpeed推理层Triton Inference Server、vLLM、TensorRT-LLM数据层MinIO / JuiceFS / Weaviate这个软件栈的价值在于算法工程师不再需要关心底层 GPU 服务器长什么样只需要通过平台提交训练任务系统会自动分配资源。3. 联想 AI 基础设施布局的三个关键方向联想的 AI 基础设施布局可以从产品、方案、生态三个层面来理解。3.1 从 AI 服务器到液冷方案联想很早就推出了 AI 服务器产品线包括面向训练和推理的不同系列。与普通服务器相比AI 服务器的核心差异在于异构计算支持、GPU 拓扑优化和散热设计。液冷是联想布局比较早的方向。随着单 GPU 功耗持续上涨传统风冷方案在超过一定功率密度后无论是散热效率还是噪音控制都难以满足数据中心要求。联想推出的冷板式液冷方案通过水冷板直接接触 CPU、GPU 等发热元件将热量带走。这种方式相比风冷PUE 可以显著降低帮助数据中心降低电力成本。从技术角度讲液冷并不仅仅是把水循环系统接进机柜那么简单需要关注冷却液类型、管路材质、防漏检测、维护便利性等一系列问题。企业如果选择液冷方案需要评估自己的机房是否具备改造条件而不是盲目跟风。3.2 AI PC 与边缘基础设施除了数据中心侧的 AI 基础设施联想的另一条线是 AI PC。所谓 AI PC是指内置 NPU 的笔记本电脑可以在本地运行大语言模型和 AI 应用不依赖云端。从基础设施的视角看AI PC 是“端侧推理基础设施”。在隐私保护、网络不稳定、实时性要求高的场景中端侧推理有不可替代的价值。比如企业内部处理敏感文档不希望把数据传到云端再比如随时随地需要一个 AI 助手但又不想依赖手机流量。端侧 AI 的技术挑战在于模型压缩和推理优化。一个几十 GB 的大模型直接跑在笔记本上是不现实的需要通过量化、剪枝、蒸馏等技术将模型压缩到几个 GB 甚至几百 MB。这也是联想要自研 AI 模型压缩工具链的原因。3.3 混合式 AI 的落地形态联想这几年一直在推一个概念叫“混合式 AI”核心意思是 AI 能力不应只存在于云端也不应只存在于端侧而是应该根据业务场景在云、边、端之间动态分配计算任务。这种架构下基础设施的形态是多样的训练和重模型推理放在云端或企业私有化机房轻量推理放在边缘节点如工厂产线、零售门店实时响应放在端侧设备如 AI PC、AI 手机、智能摄像头混合式 AI 对基础设施提出了更高要求。因为它需要一套统一的调度管理系统去管理不同位置的算力节点同时还要打通云端和端侧的模型分发通道。从工程角度讲这是一套比纯云或纯端复杂得多的体系。4. 企业构建自己的 AI 基础设施从零到一的实战路径不管联想等厂商怎么布局对大多数企业来说真正的问题不是“联想怎么做”而是“我们自己怎么搭一套 AI 基础设施”。这一节从工程实操的角度给出一条比较完整的落地路径。4.1 需求评估与算力规划不要一上来就买设备。先回答下面这些问题你的业务需要训练模型还是只需要推理训练模型预计有多大参数量在几亿、几十亿还是千亿级别需要支持多少并发请求目标响应时延是多少数据量级是多少存储在本地还是对象存储业务对数据隐私有什么要求能不能用公有云答案不同基础设施的规模完全不同。一个原则是推理需求比训练需求更容易起步。如果只是把开源模型部署成内部工具一台 24GB 显存的中端 GPU 服务器就能撑起小团队的日常使用但如果需要训练千亿参数模型起步就是几十台 8 卡高端服务器。4.2 硬件选型与部署以一个小型 AI 推理集群为例硬件层面需要准备以下设备设备用途建议配置GPU 服务器模型推理2 张 RTX 4090 或 1 张 A100 40G存储服务器模型和数据存放4 块 4TB NVMe SSD组 RAID10接入交换机服务器互联万兆交换机支持 RoCE管理终端运维操作任意一台笔记本即可服务器到位后的初始化流程可以按下面的顺序操作先安装操作系统推荐 Ubuntu Server 22.04 LTS 或更新的 LTS 版本。安装时文件系统建议选择 ext4 或 xfs并单独划分/data分区存放模型文件。然后是 BIOS 设置优化打开 Resizable BAR 和 Above 4G Decoding确保 GPU 能利用完整显存关闭不必要的节能策略避免训练时性能不稳定。接着安装 NVIDIA 驱动和 CUDA。推荐使用 runfile 方式安装可以避免 apt 源版本冲突。安装前先卸载旧驱动# 卸载旧版 NVIDIA 驱动 sudo apt purge nvidia* -y sudo apt autoremove -y # 安装依赖 sudo apt update sudo apt install build-essential dkms linux-headers-$(uname -r) -y # 禁用到 nouveau 驱动 echo blacklist nouveau | sudo tee /etc/modprobe.d/blacklist-nouveau.conf echo options nouveau modeset0 | sudo tee -a /etc/modprobe.d/blacklist-nouveau.conf sudo update-initramfs -u安装完成后将驱动模块加载进系统# 重启后确认驱动生效 nvidia-smi如果nvidia-smi能显示出 GPU 型号和显存大小说明驱动安装成功。接下来需要安装 CUDA Toolkit。注意 CUDA 版本要和深度学习框架兼容不要盲目装最新。4.3 基础运行环境配置GPU 驱动就绪后需要配置容器运行环境。推荐用 Docker 来运行 AI 模型这样可以做到环境隔离和快速迁移。先安装 Docker 和 NVIDIA 容器工具包# 安装 docker以 Ubuntu 为例 curl -fsSL https://get.docker.com | sudo sh sudo usermod -aG docker $USER # 安装 NVIDIA Container Toolkit distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt update sudo apt install -y nvidia-container-toolkit # 重启 docker sudo systemctl restart docker验证容器能否使用 GPUdocker run --rm --gpus all nvidia/cuda:12.0-base nvidia-smi如果输出 GPU 信息说明 Docker 已经可以从容器内部访问显卡了。4.4 部署一个实际的推理服务环境和工具链就绪后下面用一个实际案例来演示推理服务的部署流程。假设我们要部署一个 Llama 系列的 7B 模型提供文本生成能力。使用 vLLM 作为推理引擎它的性能比原生 Hugging Face 的 transformers 高出不少而且兼容 OpenAI API 格式方便集成到现有代码中。创建一个工作目录编写 Dockerfile# 文件路径workdir/Dockerfile.vllm FROM nvidia/cuda:12.1.0-runtime-ubuntu22.04 ENV DEBIAN_FRONTENDnoninteractive RUN apt update apt install -y python3-pip git \ pip3 install vllm WORKDIR /app COPY serve.py /app/serve.py EXPOSE 8000 CMD [python3, /app/serve.py]编写启动脚本serve.py# 文件路径workdir/serve.py from vllm import LLM, SamplingParams # 加载模型这里模型路径按实际修改 llm LLM(model/data/models/llama2-7b-chat-hf) # 测试一次推理 prompt 请介绍一下人工智能的发展历史。 output llm.generate([prompt], SamplingParams(max_tokens512)) print(output[0].outputs[0].text)构建并运行容器docker build -t vllm-demo -f Dockerfile.vllm . docker run --gpus all -v /data/models:/data/models vllm-demo如果模型文件已经存在于宿主机/data/models目录容器启动后就会加载模型并输出推理结果。之后可以在此基础上封装成 HTTP 服务使用 FastAPI 或 vLLM 自带的 OpenAI 兼容接口。4.5 GPU 资源管理与监控AI 基础设施一旦运行起来监控是必不可少的。至少需要关注 GPU 利用率、显存占用、温度、功耗四个核心指标。写一个简单的 Python 脚本定期采集 GPU 状态并写入日志# 文件路径monitor/gpu_monitor.py import subprocess import time def get_gpu_info(): result subprocess.run( [nvidia-smi, --query-gpuindex,name,utilization.gpu,memory.used,memory.total,temperature.gpu,power.draw, --formatcsv,noheader,nounits], capture_outputTrue, textTrue ) return result.stdout.strip() if __name__ __main__: while True: info get_gpu_info() timestamp time.strftime(%Y-%m-%d %H:%M:%S) print(f[{timestamp}]\n{info}\n, flushTrue) time.sleep(10)更完整的方案是接入 Prometheus Grafana通过nvidia_gpu_exporter暴露 GPU 指标。不过对于一个小型基础设施用脚本做基础监控已经足够发现问题了。5. AI 基础设施常见问题与排查思路建设中踩坑是难免的。这里整理几个高频问题按“现象 → 原因 → 解决方案”的思路给出。问题现象常见原因解决思路GPU 利用率长期为 0%但训练任务在跑数据加载是瓶颈GPU 在等数据检查数据读取路径改用并行数据加载增加数据缓存多机训练速度远低于预期RDMA 网络丢包或未启用 RDMA检查交换机 RoCE 配置使用ib_write_bw测试带宽Docker 容器内无法识别 GPUNVIDIA Container Toolkit 未安装或版本不符重新安装 nvidia-container-toolkit重启 Docker训练时显存不足 OOM模型过大或 batch size 设置过大启用梯度累积降低 batch size使用模型并行策略服务器噪音大、温度高风冷方案已到极限考虑液冷方案或者降低机房功率密度vLLM 推理时报 CUDA errorCUDA 版本与 PyTorch 版本不匹配统一使用 PyTorch 官方镜像中的 CUDA 版本存储空间被 checkpoint 占满训练过程保存太多 checkpoint设置 checkpoint 清理策略只保留最近 N 个版本其中RDMA 网络配置问题是最隐蔽的。这里给一个排查思路先用ibstat检查 IB 设备状态确认物理链路正常。然后用ib_write_bw做带宽测试对比实际带宽和理论值。如果带宽明显偏低大概率是 DSCP 优先级或 PFC 流控配置不正确。RoCEv2 网络对交换机的要求是必须开启 PFC优先级流控否则拥塞时直接丢包导致性能暴跌。对于不走 InfiniBand 的普通千兆网络环境如果只是单机推理问题不大但一旦涉及多机并行训练网络就必须升级到 RoCE 或 InfiniBand这是省不掉的成本。6. 最佳实践与工程建议AI 基础设施建设和普通软件项目不太一样它涉及硬件、系统、框架、业务多个层面工程规范尤其重要。下面按几个维度给出建议。6.1 算力资源管理永远不要把 GPU 资源直接暴露给所有人。建议建立项目制和队列制。每个项目申请资源时设置配额上限训练任务提交到队列中按优先级调度。Kubernetes 配合 Volcano 或 Kueue 可以实现这个效果。简单场景下也可以先用资源清单表格管理人工分配。无论如何要保证两点一是 GPU 不能闲置浪费二是不能让单个任务独占所有资源拖垮整个集群。6.2 模型与数据版本管理模型文件和数据集的版本管理在 AI 基础设施中经常被忽略。训练时用了什么数据集、模型结构是什么、超参数是什么都必须有记录。否则一个月后回看根本无法复现实验结果。推荐的做法是数据集使用 DVC 或 JuiceFS 做版本管理模型权重放到 Model Registry 中如 MLflow、Hugging Face Hub 私有仓库训练参数通过配置文件管理写入 Git6.3 安全与权限边界AI 基础设施安全很重要尤其是模型接口。部署推理服务时至少要做到鉴权请求必须携带 API Token不能裸奔限流防止单个用户打爆推理服务数据隔离不同项目的模型和数据集放在不同命名空间审计记录谁在什么时候提交了什么训练任务、调用了哪些模型一个简单的 Nginx 反代配置可以帮助后端推理服务做一层基础防护# 文件路径nginx/conf.d/ai-gateway.conf upstream vllm_backend { server 127.0.0.1:8000; } server { listen 80; server_name ai-inference.internal; location /v1/ { proxy_pass http://vllm_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 简单的 Token 校验 if ($http_authorization ! Bearer your-internal-token) { return 401; } } # 限流每分钟 100 个请求 limit_req_zone $binary_remote_addr zoneai_limit:10m rate100r/m; limit_req zoneai_limit burst20 nodelay; }6.4 容错与高可用AI 训练任务动辄运行数天甚至数周中途失败是常态。基础设施必须支持断点续训。PyTorch 的 checkpoint 机制是基础但更重要的是基础设施层面要能自动感知节点故障重新调度任务避免人工盯场。推理服务的高可用也需要注意。可以在推理服务前面加一层负载均衡并保留 1.5 倍的冗余容量以应对高并发和单节点故障。6.5 成本控制AI 基础设施的成本不仅包括硬件采购还包括电力、制冷、运维人工。很多团队在采购 GPU 时只对比显卡单价忽略了后续运营成本。一个实用的建议是先按最小可行规模建设跑通流程后再扩展。如果公有云资源充足初期完全可以先用云 GPU 实例验证需求等模型稳定、调用量上来之后再考虑私有化部署。7. 给技术团队的建议联想向 AI 基础设施公司靠拢背后是整个行业的算力需求结构在发生变化。对技术团队来说与其纠结“要不要自己买 GPU”不如把精力放在这几个方向上第一掌握 AI 基础设施的基本运维能力。不需要成为硬件专家但至少要会装驱动、懂 Docker、会用 Kubernetes、能快速部署一个开源模型。这套技能组合在未来很长一段时间内都会非常稀缺。第二建立标准化的部署流程。把模型部署从“手工试错”变成“一键执行”需要把 Docker 镜像、依赖版本、启动参数、健康检查全部固化下来。这样无论是本机开发还是生产部署行为都是一致的。第三让基础设施具备可观测性。GPU 利用率、推理延迟、请求成功率、存储吞吐这些指标必须持续采集。没有监控的 AI 基础设施等于在黑暗中驾驶飞机。第四关注边缘推理和绿色计算。不是所有推理场景都需要上千瓦的 GPU 服务器能效比会越来越重要。液冷、NPU、量化压缩这些技术会逐步成为 AI 基础设施的主流配置。这一轮 AI 基础设施的升级会持续相当长的时间。对身处其中的开发者来说这是一次难得的技术体系升级窗口。早一步把 AI 基础设施的工程能力补齐后面做项目时就会从容很多。
