从硬件到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 服务器为例，它的配置结构通常如下：

值得注意的是，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 开销大的问题。现在主流方案是 RDMA（Remote 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 推理集群为例，硬件层面需要准备以下设备：

服务器到位后的初始化流程，可以按下面的顺序操作：

先安装操作系统，推荐 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 modeset=0' | 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

验证容器能否使用 GPU：

docker 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_FRONTEND=noninteractive 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_tokens=512)) 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-gpu=index,name,utilization.gpu,memory.used,memory.total,temperature.gpu,power.draw", "--format=csv,noheader,nounits"], capture_output=True, text=True ) 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", flush=True) time.sleep(10)

更完整的方案是接入 Prometheus + Grafana，通过nvidia_gpu_exporter暴露 GPU 指标。不过对于一个小型基础设施，用脚本做基础监控已经足够发现问题了。

5. AI 基础设施常见问题与排查思路

建设中踩坑是难免的。这里整理几个高频问题，按“现象 → 原因 → 解决方案”的思路给出。

其中，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 私有仓库
• 训练参数通过配置文件管理，写入 Git

6.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 zone=ai_limit:10m rate=100r/m; limit_req zone=ai_limit burst=20 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 基础设施的工程能力补齐，后面做项目时就会从容很多。