AI基础设施技术栈解析：从GPU推理服务到集群运维

AI基础设施正在成为企业智能化转型中最关键的一类投入。“联想不断向AI基础设施公司靠拢”这类战略表述，放在IT产业里并不意外。个人电脑、服务器、存储、网络设备之外，真正决定一家厂商能否持续服务企业AI需求的能力，正在向算力资源、模型服务、数据平台和自动化运维延伸。对技术团队来说，这类新闻背后真正值得关注的不是某家公司的市值变化，而是AI基础设施的技术栈已经逐渐清晰，并且每个企业都需要根据自己的业务规模做取舍。

这篇文章不准备复盘联想的公司战略，而是把“AI基础设施”拆成可理解、可落地、可排查的技术体系。先说明AI基础设施包含哪几层，再讲怎么从业务需求倒推资源，然后给出一个最小可复用的GPU推理服务搭建过程，接着分析扩展成集群级基础设施需要补充的组件，最后整理常见故障排查和选型建议。内容面向正在规划AI平台的架构师、运维工程师和应用开发工程师，也适合想理解企业AI基础设施底层逻辑的高年级开发者。

1. 先理解“AI基础设施”这个概念，以及厂商转型的技术逻辑

1.1 从传统IT基础设施到AI基础设施，多了什么

传统IT基础设施通常由计算、存储、网络三部分组成。计算包括CPU服务器和超融合节点，存储包括SAN、NAS和对象存储，网络包括交换机、负载均衡和安全设备。企业上ERP、上网站、跑数据库，用的都是这套体系。

AI基础设施并不是把这些全部替换掉，而是在原有底座上新增一层专门服务算法和数据的能力。最直观的变化有三点：

• 算力从以CPU为主变成以GPU、NPU等加速卡为主。
• 数据访问从随机读写为主变成高吞吐顺序读写为主，因为训练要反复读取数据集和checkpoint。
• 软件栈从虚拟机、数据库扩展到CUDA、深度学习框架、模型推理引擎、模型仓库和特征存储。

所以AI基础设施可以理解为：以加速计算为核心，以高性能数据读写为支撑，以模型训练和推理服务为目标的软硬件一体化平台。

1.2 AI基础设施的四大层次：硬件、资源、平台、运维

为了便于讨论，可以把AI基础设施分成四层。不同厂商说的AI基础设施，往往侧重不同的层。

在真实项目里，四层边界并不完全固定。小团队可能只用到Docker和一台GPU服务器，不碰Kubernetes；大公司则会把平台层和运维层做成一套内部的AI中台。理解层次之后，再读联想、浪潮这类厂商的“AI基础设施”发布会，就不会只看到一堆服务器参数，而是能看到它们分别补齐了哪一层。

1.3 为什么传统硬件厂商不断向AI基础设施公司靠拢

传统IT硬件厂商过去交付的是设备，客户买回去自己装操作系统、部署应用、做运维。进入AI时代，硬件与软件之间的关系变得比过去紧密得多。

同一个GPU服务器，驱动版本不同、CUDA版本不同、分布式训练框架不同，性能差异可能非常明显。企业在私有化部署大模型推理服务时，除了需要硬件，还希望厂商能提供预装好的镜像、调优过的推理引擎、统一的资源调度方案和后续的故障支持。也就是说，客户购买的不再只是一台机器，而是一个能持续运行算法业务的底座。

因此，联想等厂商向AI基础设施公司靠拢，本质上是把交付物从“裸金属设备”变成“可以运行AI负载的环境”。这样做对厂商有好处：硬件毛利被服务价值覆盖，客户粘性更高；同时也对客户有好处：降低了从零搭建AI环境的技术门槛。但要注意，这类转型是否成功，还要看软件生态是否开放、文档是否完整、升级路径是否清晰，不能只看发布了多少台带GPU的服务器。

2. 建设AI基础设施之前，先用业务需求倒推资源配置

很多团队建设AI基础设施时犯同一个错误：先买GPU，再想跑什么业务。更合理的方式是先整理业务负载类型，再估算算力、存储和网络需求，最后形成资源配置清单。

2.1 先区分开发调试、模型训练、在线推理三类负载

三类负载对基础设施的要求差异很大。开发调试要求响应快、环境隔离好，训练要求长时间稳定运行，在线推理要求低延迟和高可用。

很多团队一开始只规划了训练服务器，忽略了推理服务也需要GPU。实际上，业务上线后推理服务的长期占用成本往往不低于训练成本。

2.2 算力需求怎么估算

算力需求无法精确计算，但可以用一个粗略估算公式帮助选型：

需要的GPU数量 = 单次训练迭代的耗时目标 / 单卡每秒迭代次数

更常见的训练场景估算逻辑是：

GPU总量 = 参数量 × 训练数据量 × 计算量系数 / (单卡有效算力 × GPU利用率)

这个公式里的计算量系数取决于模型架构、序列长度和优化器，实际需要靠小规模实验测量。以常见的大模型微调为例，70B参数的模型使用LoRA方式微调，显存需求远低于全参数微调；全参数微调可能需要几百GB显存，而LoRA在单张80GB显存上就可能跑起来。所以选型前先确认训练方式和量化精度，比盲目堆卡更重要。

一个实用做法是：先用实际数据集在一台服务器上跑几轮迭代，用nvidia-smi观察显存和GPU利用率，再按线性放大估算多机规模。这样得到的估算结果比拍脑袋准确得多。

2.3 存储和网络评估

训练场景存储容量估算：

• 数据集大小乘以版本数和备份数。
• 每轮训练生成的日志、模型checkpoint大小。
• 推理服务加载的模型文件大小。

大模型checkpoint动辄几十GB到几百GB，如果保存策略不当，会很快占满存储。生产环境建议至少区分热数据存储和冷数据存储，热数据用并行文件系统或NVMe阵列，冷数据放对象存储。

网络方面，单机推理环境用万兆网即可，多机训练则需要高带宽低延迟的RDMA网络。普通TCP网络在数据并行AllReduce阶段会成为瓶颈，即使GPU再多，节点间通信也会拖慢整体训练速度。

2.4 不同规模的硬件选型参考

下面表格是通用参考，不是绝对标准。实际选型要以业务需求、预算和厂商当前产品为准。

这里特别提醒，不要只看显存大小，还需要看GPU的算力、显存带宽和是否支持目标精度。消费级显卡在稳定性、驱动和企业级支持上与专业GPU存在差距，生产环境不建议长期使用消费级显卡承载关键推理服务。

3. 搭建一套最小可复用的GPU推理基础设施

理解了规划思路之后，动手搭建一套最小可用的GPU推理底座会很有价值。下面以单机Docker方案为例，演示从驱动检查到模型接口验证的完整链路。

3.1 学习环境的最简清单

在学习环境中，建议使用以下组合：

• 操作系统：Ubuntu 20.04或22.04 LTS。
• 显卡：NVIDIA GPU，驱动支持CUDA 12.x。
• 容器运行时：Docker Engine 24及以上。
• GPU容器工具：NVIDIA Container Toolkit。

如果原机器已经安装驱动，先用命令确认状态。

nvidia-smi

如果命令不存在，说明驱动未安装或未加入PATH。正常输出会显示GPU型号、驱动版本和CUDA版本。这里看到的是驱动支持的CUDA版本，并不代表宿主机已经安装CUDA工具包，容器里通常自带CUDA运行时。

3.2 安装NVIDIA Container Toolkit

默认Docker容器无法直接访问宿主机GPU，需要安装NVIDIA Container Toolkit，让Docker运行时可注入NVIDIA驱动和CUDA库。

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \ | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \ | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \ | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker

这些命令来自官方仓库的常见安装方式，具体路径可能随版本变化，安装前建议查阅当前官方文档。关键步骤是最后两条：向Docker注册nvidia运行时，然后重启Docker。

验证Docker是否能识别GPU。

docker run --rm --gpus all nvidia/cuda:12.1.1-base-ubuntu22.04 nvidia-smi

如果输出GPU信息，说明软硬件链路已经打通。如果这一步失败，问题通常集中在驱动冲突、Docker运行时配置未生效、镜像架构不匹配三个方面。

3.3 启动一个带PyTorch的推理容器

生产环境中不建议在容器内临时安装深度学习框架，最好直接使用官方镜像，例如PyTorch官方镜像或vLLM镜像。演示时可以用PyTorch官方镜像。

mkdir -p /opt/ai-infra/models mkdir -p /opt/ai-infra/logs docker run -d --name ai-server \ --gpus '"device=0"' \ -p 8000:8000 \ -v /opt/ai-infra/models:/models \ -v /opt/ai-infra/logs:/logs \ -e MODEL_PATH=/models/demo-model \ -e LOG_DIR=/logs \ pytorch/pytorch:2.2.0-cuda12.1-cudnn8-runtime \ python -c "import torch; print(torch.cuda.is_available()); import time; time.sleep(3600)"

这里用--gpus '"device=0"'指定第一张GPU，避免多个容器互相抢占显存。-v把模型目录和日志目录挂载进容器，方便宿主机更新模型。环境变量把模型路径和日志路径从代码中抽离出来，这是配置外置化的最小做法。

等待容器启动后，执行检查。

docker logs ai-server

如果输出True，说明容器内PyTorch能正常访问GPU。

3.4 用FastAPI写一个最小的模型推理接口

上面的容器只是为了验证GPU可用，没有业务能力。下面写一个FastAPI服务，接收文本输入后，返回模型推理结果。

先创建目录和文件。

mkdir -p /opt/ai-infra/app

在/opt/ai-infra/app/main.py中写入：

import os import logging from fastapi import FastAPI, HTTPException from pydantic import BaseModel app = FastAPI(title="AI Inference Demo") MODEL_PATH = os.getenv("MODEL_PATH", "/models/demo-model") LOG_DIR = os.getenv("LOG_DIR", "/logs") logging.basicConfig( filename=os.path.join(LOG_DIR, "inference.log"), level=logging.INFO, format="%(asctime)s %(levelname)s %(name)s %(message)s", ) logger = logging.getLogger(__name__) class PredictRequest(BaseModel): text: str max_length: int = 50 class PredictResponse(BaseModel): result: str @app.get("/health") def health(): return {"status": "ok", "model_path": MODEL_PATH} @app.post("/predict", response_model=PredictResponse) def predict(request: PredictRequest): if not request.text: raise HTTPException(status_code=400, detail="text must not be empty") try: # 这里替换成真实模型调用，例如transformers的pipeline result = f"echo: {request.text[:request.max_length]}" logger.info("predict text length=%s max_length=%s", len(request.text), request.max_length) return PredictResponse(result=result) except Exception as exc: logger.exception("predict failed") raise HTTPException(status_code=500, detail=str(exc))

这个代码演示了三个工程点：通过环境变量读取模型路径，把日志写到挂载目录，用健康检查接口暴露服务状态。真实项目里只需把中间注释替换为模型加载和推理逻辑。

3.5 从宿主机验证推理接口

容器内代码需要安装依赖并启动。为了演示完整链路，先进入容器安装依赖。

docker exec -it ai-server bash pip install fastapi uvicorn uvicorn app.main:app --host 0.0.0.0 --port 8000

注意此时容器内的代码目录需要挂载进去。上面启动容器时没有挂载/opt/ai-infra/app，实际运行时应该再加-v /opt/ai-infra/app:/app。调整后重新启动容器，再用宿主机curl请求。

curl -X POST http://127.0.0.1:8000/predict \ -H "Content-Type: application/json" \ -d '{"text": "AI infrastructure is the new core", "max_length": 20}'

预期返回：

{"result":"echo: AI infrastructure is the new"}

再检查写入的日志：

tail -f /opt/ai-infra/logs/inference.log

日志中出现predict text length=...说明接口链路完整。

4. 关键配置与参数：让GPU推理服务稳定跑起来

小型服务跑通后，还要理解几个关键配置参数。很多生产事故都出在版本不匹配、显存隔离和模型加载路径上。

4.1 GPU驱动、CUDA、PyTorch三者的版本匹配

NVIDIA GPU驱动运行在宿主机上，容器内的CUDA运行库通过NVIDIA Container Toolkit注入驱动。驱动版本决定支持的最高CUDA版本，容器内CUDA版本不能高于驱动支持的版本上限。

最常见的错误是容器内CUDA版本高于宿主机驱动支持的版本，导致CUDA driver version is insufficient。排查时先在宿主机执行nvidia-smi，记录右上角的CUDA Version，再进入容器安装相同或更低的CUDA版本。

4.2 容器外的GPU隔离和显存限制

Docker的--gpus参数控制容器访问哪些物理GPU，但Docker本身不直接提供显存上限参数。要控制显存，常见做法有：

• 使用CUDA_VISIBLE_DEVICES环境变量控制可见GPU编号。
• 使用NVIDIA_DRIVER_CAPABILITIES=compute,utility限制驱动能力集。
• 在框架层设置显存限制，例如TensorFlow的set_memory_growth。
• 使用MIG或vGPU将单张物理GPU切成多个实例。

生产环境要注意：多个容器共享同一张GPU时，显存和算力并不会被严格隔离，某个容器大量申请显存可能会影响其他容器。关键推理服务建议独享GPU，开发调试环境才适合做显存共享。

4.3 模型文件和数据集怎么存储

模型文件通常很大，不适合打进Docker镜像。推荐链路是：

1. 模型文件上传到对象存储或共享NAS。
2. 容器启动时通过挂载目录或启动脚本下载。
3. 推理服务从环境变量读取模型路径。
4. 模型版本变更时，加载新路径并灰度发布。

启动容器时通过挂载暴露目录。

docker run -d --name ai-server \ --gpus '"device=0"' \ -p 8000:8000 \ -v /data/models:/models \ -e MODEL_PATH=/models/llama-2-7b-chat-v2 \ -e LOG_DIR=/logs \ -v /data/logs:/logs \ your-image:tag

这样做的好处是：模型不在镜像里，镜像可以保持很小；发布新模型时不需要重新构建镜像；回滚时只需切换环境变量里的路径。

4.4 推理服务的并发和队列设计

在线推理服务不能简单认为“加线程就有更高吞吐”。GPU推理接口的性能瓶颈往往在显存和推理引擎。增加并发请求时，如果不使用支持动态批处理的推理框架，大量请求会排队等待，P95延迟上升。

生产环境中建议参考以下思路：

• 单请求批大小设为1时，优先保证延迟。
• 高吞吐场景使用vLLM、TensorRT-LLM等支持Continuous Batching的引擎。
• 服务入口增加请求队列，设置超时时间，避免无限排队。
• 通过压测得到最大并发数，并在这个数值的60%到80%设置告警阈值。

4.5 推理服务参数速查表

参数调整后要同时关注吞吐和延迟两个指标，不能只看单次请求快不快。生产环境建议每次调整只改变一个参数，并用压测记录前后对比。

5. 从单机到集群：AI基础设施的扩展思路

单机方案适合验证和低并发场景。业务规模上来后，需要进入集群化阶段。这个阶段不是简单加几台机器，而是要把资源管理、任务调度、可观测性和模型版本一起纳入基础设施。

5.1 推理服务的水平扩展和负载均衡

多个GPU服务副本可以放在Nginx后面，由网关按负载策略转发。

upstream ai_inference_backend { least_conn; server 192.168.1.10:8000 max_fails=3 fail_timeout=30s; server 192.168.1.11:8000 max_fails=3 fail_timeout=30s; server 192.168.1.12:8000 max_fails=3 fail_timeout=30s; } server { listen 8080; location /predict { proxy_pass http://ai_inference_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_read_timeout 120s; } }

需要注意，如果后端服务不支持动态批处理，单纯多副本无法解决单副本内并发请求的排队问题。水平扩展之前，先确认单副本的吞吐上限，再用副本数乘以上限设计容量。

5.2 训练和推理任务的资源池化

集群规模较大时，推荐用Kubernetes管理GPU资源和任务。NVIDIA Device Plugin能自动上报GPU显存，Volcano或Kueue能提供队列调度。下面是一个GPU推理Deployment的YAML示例。

apiVersion: apps/v1 kind: Deployment metadata: name: ai-inference labels: app: ai-inference spec: replicas: 2 selector: matchLabels: app: ai-inference template: metadata: labels: app: ai-inference spec: containers: - name: inference image: registry.example.com/ai-server:1.2.0 ports: - containerPort: 8000 resources: limits: nvidia.com/gpu: 1 env: - name: MODEL_PATH value: /models/llama-2-7b-chat-v2 volumeMounts: - name: model-storage mountPath: /models readinessProbe: httpGet: path: /health port: 8000 volumes: - name: model-storage persistentVolumeClaim: claimName: model-pvc

这段配置中，nvidia.com/gpu: 1是关键字段。Kubernetes调度到节点后，Device Plugin会为该Pod分配一块GPU，并将/dev/nvidia0等设备注入容器。

5.3 GPU可观测性：没有监控就没有基础设施

集群化之后，必须把GPU监控纳入基础设施。常用方案是DCGM Exporter + Prometheus + Grafana。

先启动DCGM Exporter，可以放在Kubernetes DaemonSet里，也可以先用Docker简单验证。

docker run -d --name dcgm-exporter \ --restart=always \ --gpus all \ -p 9400:9400 \ nvidia/dcgm-exporter:3.3.3-3.4.1-ubuntu22.04

在Prometheus配置中增加采集任务。

scrape_configs: - job_name: 'dcgm-exporter' static_configs: - targets: ['127.0.0.1:9400']

采集到的指标包括GPU利用率、显存使用、GPU温度、功率和SM利用率。告警规则至少要覆盖：

• GPU利用率长期低于20%，可能是任务调度问题。
• 显存使用超过90%，可能影响同机其他任务。
• GPU温度超过85度，需要检查散热。
• 容器重启次数超过阈值，需要查看前一个实例的日志。

5.4 模型版本和数据一致性管理

集群环境最常见的问题不是机器故障，而是模型版本和训练数据版本不一致。例如，A服务还在加载上一版模型，B服务已经加载了新模型；离线任务使用旧数据集，线上推理使用新数据集，导致行为不可控。

建议从第一天引入模型版本号，并使用独立的模型仓库。无论是对象存储中的目录、镜像tag，还是模型管理平台的artifact ID，都要形成统一命名规则，例如model-name/version/date-commit。

模型发布流程可以简化为：

1. 新模型完成评测，上传到模型仓库的v2目录。
2. 修改服务的MODEL_PATH环境变量或配置中心键值。
3. 灰度发布一个副本，校验指标。
4. 逐步推送新版本到所有副本。
5. 保留旧版本目录，便于回滚。

5.5 AI基础设施扩展排错清单

6. 常见问题排查：从看到的现象定位到根因

再完美的规划也会遇到故障。这里整理几个高频问题，按“现象、原因、检查方式、解决建议”展开。

6.1 容器内看不到GPU

现象：在Docker容器内执行nvidia-smi提示NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver。

常见原因：

• 没有安装NVIDIA Container Toolkit。
• Docker没有使用nvidiaruntime。
• 宿主机的NVIDIA驱动损坏或版本过旧。
• 容器镜像不是基于NVIDIA官方基础镜像，缺少CUDA库。

检查方式：

# 宿主机看驱动是否正常 nvidia-smi # 检查Docker是否注册了nvidia runtime docker info | grep -i runtime # 用官方基础镜像验证 docker run --rm --gpus all nvidia/cuda:12.1.1-base-ubuntu22.04 nvidia-smi

解决建议：如果宿主机正常但容器不行，先确认执行nvidia-ctk runtime configure --runtime=docker并重启Docker。官方基础镜像也失败时，检查驱动版本是否过老，建议升级到当前稳定发行版。

6.2 推理服务启动慢或者启动后立刻退出

现象：容器可以创建，但docker logs显示大量错误，或者服务进程启动几秒后被杀死。

常见原因：

• 模型路径不存在，服务启动时加载模型失败。
• 显存不足，模型无法加载到GPU。
• 服务代码引用了不存在的依赖或环境变量。
• 容器内存不足，被OOM-Killer杀掉。

检查方式：

docker logs --tail 200 ai-server nvidia-smi --query-gpu=memory.used,memory.total --format=csv cat /sys/fs/cgroup/system.slice/docker-xxx.service/memory.events

解决建议：先使用一个极简的PyTorch图像验证GPU环境，再逐步加入模型；模型路径务必通过环境变量注入，避免硬编码。启动服务前可以先free -g查看剩余内存。

6.3 推理接口响应慢，但GPU利用率并不高

现象：业务反馈接口需要几十秒，但nvidia-smi显示GPU利用率很低。

常见原因：

• 请求没有真正到达GPU服务，而是卡在网络或负载均衡层。
• 服务端使用同步等待，队列积压。
• 模型较小但日志同步磁盘，把大量时间花在IO上。
• Python GIL限制，多线程没有提升吞吐。

检查方式：

# 统计请求耗时分段 curl -w "time_total=%{time_total} time_connect=%{time_connect} time_starttransfer=%{time_starttransfer}\n" \ -X POST http://127.0.0.1:8000/predict \ -H "Content-Type: application/json" \ -d '{"text": "test"}'

如果time_connect很低但time_starttransfer很高，说明后端处理慢；如果time_connect都很高，需要排查负载均衡和后端连接。GPU利用率低但后端慢，通常要考虑推理引擎是否支持动态批处理，或者代码里是否频繁在CPU和GPU之间拷贝数据。

6.4 训练时显存OOM，但降低batch_size后还是报错

现象：训练任务使用CUDA out of memory。

常见原因：

• 存在显存碎片，即使有部分空闲显存也无法分配。
• 框架缓存或中间激活值占用过多。
• 同一张GPU上还有其他进程占用显存。
• 模型并行策略未正确配置，导致单卡加载完整个模型。

检查方式：

nvidia-smi nvidia-smi --query-compute-apps=pid,used_memory --format=csv

解决建议：先确认是否有其他容器占用显存；再尝试清空框架缓存；仍然不够时，降低batch_size、使用梯度累积、开启混合精度训练或改用模型并行。不要依赖重启解决显存泄漏问题，要找到显存增长日志。

6.5 模型回滚后行为没有恢复

现象：把服务切回旧模型版本，但输出仍是新模型的结果。

常见原因：

• 模型文件被覆盖，旧版本目录已不存在。
• 服务进程仍然加载旧模型，没有重新加载。
• 网关或客户端缓存了响应结果。
• 模型走的是外部API，本地环境变量并没有生效。

检查方式：

# 查看服务进程加载的模型路径 docker inspect ai-server | grep MODEL_PATH # 如果使用模型服务框架，查看模型加载日志 docker logs ai-server | grep -i "loaded"

解决建议：模型版本目录只新增不删除，回滚时通过环境变量指向旧目录，并滚动重启服务。对于大模型服务，建议在响应头中加入模型版本字段，例如X-Model-Version: v2，这样问题和流量都能快速定位。

7. 回到联想和行业：AI基础设施公司到底要沉淀什么能力

花了大量篇幅讨论技术细节后，再回到“联想不断向AI基础设施公司靠拢”这个话题。如果只看新闻标题，它像是一个商业报告；但站在技术团队角度，它揭示了一个趋势：AI基础设施不是一次性采购，而是一种需要持续运维、迭代和开放集成的基础能力。

7.1 硬件能力只是起点，服务和生态才是分水岭

能生产GPU服务器、存储阵列和交换机，不代表能提供AI基础设施。AI基础设施公司至少还需要三种能力：

• 软件集成能力：把CUDA、深度学习框架、推理引擎、调度平台预集成到一个稳定可复用的镜像或发行版中。
• 交付运维能力：客户环境不同，驱动版本、内核、网络配置都可能不同，需要能够快速适配和排障。
• 生态开放能力：能支持主流的Kubernetes、PyTorch、Triton、vLLM，而不是只能用厂商私有工具链。

这也是为什么很多传统硬件厂商在转型时，会反复强调“从设备销售到方案交付”，本质是希望往价值链上游移动。

7.2 企业选择AI基础设施厂商时应该问清楚的问题

在引入任何AI基础设施供应商之前，建议技术团队整理一份问题清单，至少覆盖以下内容。

这些问题比单纯比较GPU卡型号更有价值，因为AI基础设施的长期成本很大部分来自运维和升级。

7.3 自建AI基础设施与云托管方案怎么取舍

不同规模团队的决策截然不同。

对于大模型私有化场景，不少企业选择“核心数据在私有化环境，弹性算力在云端”的混合方案。关键是要保证模型、数据、代码可以跨环境迁移，避免被单一平台绑定。

7.4 给技术团队的一条可复用落地清单

无论是否采购厂商方案，团队自己建设AI基础设施时，可以逐项检查以下清单：

1. 是否已经按开发、训练、推理三类负载拆分容量规划。
2. 是否记录了宿主机驱动版本、CUDA版本和镜像版本。
3. 是否把模型文件、数据、日志通过挂载目录或对象存储独立于容器。
4. 是否用环境变量或配置中心管理模型路径和推理参数。
5. 是否部署了GPU监控和日志采集。
6. 是否对推理接口做了压测，并记录了P95延迟。
7. 是否制定模型发布和回滚流程。
8. 是否配置了显存和内存OOM告警。
9. 是否至少模拟过一次GPU服务器宕机演练。
10. 是否所有环境都能复用同一套镜像，避免生产环境临时装包。

这条清单也适合作为AI基础设施上线前的评审模板。逐项打勾后，再继续扩展多机集群。

7.5 对开发者、运维和架构师各自的学习建议

• 应用开发工程师：先掌握PyTorch模型加载、FastAPI接口封装、模型路径外置化，再学习vLLM或TensorRT-LLM的推理参数调优。
• 运维工程师：重点学习Docker GPU runtime、Kubernetes Device Plugin、DCGM Exporter、NCCL网络诊断，以及显存OOM和驱动升级的排查流程。
• 架构师：需要理解从业务需求倒推容量的方法，熟悉对象存储、共享文件系统、资源队列、模型仓库之间的衔接关系，并能在自建和云方案之间算清成本账。

8. 收尾：从一个最小可复用的推理底座开始积累经验

AI基础设施看起来宏大，但入门路径可以很小。建议从一台GPU服务器、一个Docker容器、一个模型目录开始，把今天文章里的最小链路跑通：启动容器、挂载模型、暴露接口、验证日志、配置监控。跑通之后再逐步加入多副本、队列、模型管理、多机训练。

在动手过程中要特别记住几个关键判断：先匹配驱动、CUDA和框架版本，再写业务代码；把模型和配置放在容器之外，避免每次发布都重新构建镜像；不要把GPU显存当成无限资源，先压测再定并发；监控和日志不是上线后补的东西，而是在第一天就接入。

联想这类厂商向AI基础设施公司靠拢，对行业的实际影响是让“AI基础设施”从一个营销词汇变成了可以被评估、被部署、被运维的交付物。技术团队的应对方式不是追逐硬件参数，而是把AI基础设施拆成算力、资源、平台、运维四层，结合实际业务逐项验证。今天从一个最小推理服务开始，后面所有扩展都会变得有章可循。