企业官网建设流程全解析

1. AI-Infra是什么：先别急着学框架，把这句话读懂

我第一次听到"AI-Infra"这个词是在一次内部技术分享会上，当时隔壁组的大佬在台上讲"GPU利用率优化"，台下坐了二十几个做推荐、搜索、CV的算法工程师。他放了一张图，图上是某大模型训练任务里GPU的实时利用率曲线——乍一看一片黄绿色，绿得发慌，但细看时间线，每隔一两个小时就有一段明显的"低谷"，蓝色占比骤降。大佬说，这些低谷，全是存储瓶颈、网络同步、数据预处理卡顿造成的，不是GPU不够，而是Infra没跟上。

那会儿我就意识到，大家天天追着新模型、新Loss、新榜单跑，但真正让模型能跑起来、跑得快的，其实是底下这套看不见的"地基"——AI-Infra。

所谓AI-Infra，全称是Artificial Intelligence Infrastructure，直译是AI基础设施，但这个词的实际含义比字面大得多。它不是一个单独的软件、一个框架或一台机器，而是支撑AI系统全生命周期的一套组合能力：从GPU等算力硬件选型、集群网络组网，到资源调度与编排平台，再到数据存储与预处理管道，再往上还有分布式训练框架、模型推理引擎、模型服务化平台，以及贯穿全程的监控、告警、日志和成本治理。

一句话：算法工程师负责让模型"想得聪明"，AI-Infra工程师负责让模型"跑得动、跑得快、跑得省"。

这个领域为什么这两年突然火起来？因为大模型把算力和复杂度推到了临界点。单卡已经塞不下模型，单机也无法完成训练，分布式训练、模型并行、算子融合、推理加速这些技术不再是论文里的概念，而是每天都要面对的生产问题。一个推理服务需要支撑几十路并发，响应时间还不能超过两秒——网络抖动、显存碎片、调度排队、量化误差，随便哪个环节出问题，体验都会崩。

所以越来越多团队开始设专门的AI-Infra岗位，要求你懂Linux、懂K8s、懂GPU、懂CUDA，还得懂一点模型结构和训练框架。这条路刚走的人不多，但确实值得走。这篇就当第一章，我根据自己的实践把AI-Infra的地图先铺开，讲清楚里面有哪些模块、各自解决什么问题，再给一条可落地的入门路径，最后聊几个我已经踩过的坑。

2. 一张图拆解AI-Infra的六大核心板块

很多第一次接触AI-Infra的人会以为这就是"装显卡驱动、配环境、写个Dockerfile"，其实那只是最外围的皮毛。真正干活的时候，你面对的是下面这六个彼此咬合的部分。

2.1 硬件与网络层：GPU不只是算力，更是"显存+带宽"的组合

这一层最容易理解，但最容易被低估。做AI-Infra不要求你能焊电路板，但你必须清楚几类硬件参数对性能的影响。

GPU的核心指标不只看FLOPS，还有显存容量、显存带宽、卡间互联带宽。举个例子，NVIDIA A100的显存带宽是2TB/s级别，H100更高；而消费级RTX 4090虽然FP16算力不差，但显存带宽只有1TB/s左右，NVLink也没有。如果你要跑大模型训练，4090在多卡通信时就会成为瓶颈——不是说不能跑，而是每过一个通信点，整体效率都往下掉。

网络层面，多机训练时必须了解IB（InfiniBand）和RoCE的区别。IB是专用网络协议，延迟低、可靠性高，但贵；RoCE是以太网上的RDMA方案，性价比高，但对网络的丢包率极其敏感。组网时如果交换机缓冲不足，一旦发生微突发丢包，NCCL的AllReduce效率会断崖式下跌。我见过一个场景，训练任务隔几个小时就出现一次"NCCL timeout"，排查到最后发现是网卡firmware版本不一致。

还有存储。GPU训练的数据读取是高速并发，数据如果放在机械盘上，很容易出现"GPU在等数据"的尴尬状态。现代训练集群的存储方案普遍是NVMe SSD加高性能并行文件系统，比如Lustre、GPFS，或者云上的高性能ESSD，缓存热点数据，尽量让数据读取速度大于GPU消化速度。

2.2 资源调度层：排队比"榨干每一块显卡"更重要

有了硬件资源，接下来是调度。很多小团队一开始的做法是"谁要用卡，直接上去占"，但不出一周就会出现问题：有人占着8卡跑一个单卡任务好几天，有人排队等卡等到心态爆炸，还有人不小心把训练进程跑到了登录节点上，直接把整个集群搞卡。

生产环境的调度核心是两套主流方案：Slurm和Kubernetes（K8s）。

Slurm是HPC领域的元老，在传统科学计算和超算中心里用得非常多。它的优势是成熟、稳定，作业管理语义清晰，适合长时运行的大规模训练任务。你在国内很多智算中心里看到的基本都是这类方案。

K8s则更偏向云原生，适合需要弹性伸缩、混合部署多种应用的团队。K8s里跑GPU任务通常需要配合NVIDIA Device Plugin、Node Feature Discovery这些组件，让调度器感知GPU资源。更专业的做法是部署Volcano、Kueue这类支持队列和优先级的高级调度器，它们懂得把"8卡任务"作为一个整体来调度，而不是拆成8台机器上的单个容器分别调度。

但这里有一个认知很关键的转变：调度系统的目标是"让全局资源利用率维持在合理区间"，而不是"把每张卡都榨到100%"。因为训练任务对资源是"整块"需求，如果把8卡任务拆到两台各4卡的机器上，跨机通信带来的开销可能让任务变慢20%，单位产出反而更差。一个设计良好的调度策略，有时候宁可让部分资源空闲，也要保证流转任务的性能一致性。

2.3 数据管道层：GPU一分钟吃掉的数据，够CPU处理一小时

数据管道是AI-Infra里最容易被忽视、但最影响效率的环节之一。原因很简单：模型训练是GPU高速消化数据，它一秒钟能处理成千上万张图片或几十万token，如果上游数据管道太小水管，GPU就只能干等。

数据管道通常包含三个环节：采集/存储、预处理、加载。

预处理环节最容易出问题的是数据解压和格式转换。比如原始数据是压缩的TFRecord或WebDataset，如果直接在训练进程里做解码，每张图都要解压、缩放、增广，CPU负担会非常重。合理的做法是启动多个独立的DataLoader Worker进程，让它们并行地做解码和预处理，把处理好后的数据直接送到GPU显存里。

更高级一点的做法是使用缓存层。实践中常用两种：

• 本地缓存：训练机的SSD上划出一块空间，存放频繁读取的数据集切片，避免每次都走网络存储。
• 内存缓存：把热点数据集直接映射到Page Cache里，尤其适合反复迭代的小数据集。

再往上层的框架是数据编排工具，例如TF Data、PyTorch DataLoader与WebDataset的组合使用。PyTorch 2.0之后的DataLoader支持了更细粒度的数据集切分、worker动态调整等能力，可以直接通过参数配置。想优化数据管道，建议先用nvidia-smi或DCGM观测GPU的利用率曲线，如果GPU利用率在低峰和高峰之间剧烈波动，大概率是数据加载跟不上。

2.4 分布式训练框架层：从单卡到千卡的跨越

现在很多工程师入门AI-Infra，都是从分布式训练框架开始的，这也是最"程序员友好"的一层。

单卡训练好理解，模型加载到显存，数据一批批算梯度，更新参数。多卡训练就有四种基本并行策略：

• 数据并行（DP/DDD）：每张卡都放一个完整模型副本，喂不同批次的数据，定期同步梯度。简单但显存占用大。
• 张量并行（TP）：把层内部的矩阵运算切成多份，分给多张卡，适合超大单层。
• 流水线并行（PP）：把模型按层切开，每张卡负责若干层，数据像流水线一样流过各卡。
• ZeRO优化：把优化器状态、梯度、参数分片，配合通信，让显存需求接近数据并行但容量要求大幅降低。

实际工程里，Megatron-LM、DeepSpeed、PyTorch FSDP这几套方案都已经相当成熟。选型的核心是"显存够不够，通信快不快，代码改造大不大"。

DeepSpeed的ZeRO-3技术在预训练大模型时几乎是标配，它会在多个GPU之间对参数、梯度和优化器状态做动态分片。Hugging Face的Transformer库也提供Trainer接口，底层默认支持FSDP，开发效率很高，适合快速验证。

但框架不是万能的，训练跑得不快，很多时候是"框架参数没调对"。比如梯度累积步数、混合精度的fp16/bf16选择、通信后端（NCCL还是GLOO）、checkpointing策略等，都会直接影响吞吐。这些参数的具体意义，我后面在实操部分展开讲。

2.5 推理与服务化层：性能瓶颈从"跑得动"变成"响应快"

训练做得再好，模型最终要上线对外提供服务，这就是推理与服务化。

推理和训练的技术挑战完全不同。训练追求"总吞吐量"，推理追求"低延迟+高并发"。你能让一张卡每秒训练几万样本，但上线后可能只敢让一个模型同时服务几十个请求，因为每个请求都要求几秒内返回。

现代推理服务的核心是三块：

• 模型优化：量化（INT8、INT4）、剪枝、蒸馏、算子融合。常用的工具有TensorRT、ONNX Runtime、OpenVINO。大模型推理里还有KV Cache量化、连续批处理（Continuous Batching）这些技巧。
• 推理引擎：当下最火的是vLLM、TensorRT-LLM，它们都支持PagedAttention和Continuous Batching机制，大幅提高GPU利用率。
• 服务框架：Triton Inference Server在工业界是事实标准，支持多模型管理、动态batch、并发调度，还能混合跑PyTorch、TensorRT、ONNX等不同后端。

推理路径上还有一个关键概念是"SLA"，也就是服务等级协议，通常包含P50/P99延迟指标。你的服务器性能是否达标，不是看平均延迟，而是看P99延迟，也就是99%请求的响应时间，这是用户体验的真实感受。

2.6 可观测与运维层：没有监控的集群，就像没有仪表盘的飞机

最后一层，是贯穿前面所有层的"基础设施基础设施"——可观测性。

AI集群的监控和传统Web服务不大一样。除了常规的CPU、内存、网络，你还得盯GPU的细粒度指标：

• SM占用率：指示GPU计算核心被利用的比例，数据加载慢会导致这个值偏低。
• 显存占用量与显存带宽。
• GPU温度和功耗，影响降频风险。
• NVLink/PCIe/网络通信量。

NVIDIA官方提供的DCGM（Data Center GPU Manager）几乎是标配，它配合Prometheus和Grafana可以搭建一套完整的GPU监控看板。更进一步，还有专门面向训练任务的监控系统，可以分析各卡之间的同步等待时间，定位"最慢的卡"。

这一层还有成本治理。大模型时代的算力账单是非常惊人的，没有预算监控和配额管理，月底财务报表会非常难看。

3. 一线工程师的AI-Infra入门实操：从零搭建一套可用的GPU开发环境

前两节讲的是"地图"，这一节开始讲"走路"——怎么真正上手。我以最典型、也是新手最需要的场景为例：本地或者单机多卡环境下，搭建一套可用的GPU AI开发环境，先把模型跑起来，再逐步走向集群。

3.1 动手之前：先检查硬件、驱动和容器运行时

很多新手拿到一台GPU服务器，上来就pip install torch，结果跑模型报错说CUDA不可用，然后陷入"重装驱动-重启-再报错"的循环。这个坑我在早期踩得很惨，现在每次拿到新机器都会先走一遍固定检查流程。

第一步：查看GPU硬件是否被系统识别。

lspci | grep -i nvidia nvidia-smi

如果nvidia-smi命令找不到，说明驱动没装好，或者内核模块没加载。如果lspci能看到GPU但nvidia-smi看不到，建议先检查/proc/driver/nvidia/version是否存在，再检查dkms status，确认驱动是否成功编译进当前内核。

第二步：确认CUDA版本与GPU架构的匹配关系。

这里有一个常见误区：大家总以为要"装最新的CUDA"，其实更重要的是"CUDA版本和驱动版本兼容，和你将要安装的PyTorch版本兼容"。PyTorch的每个版本都对应一个编译时的CUDA版本，比如cu118代表CUDA 11.8，cu121代表CUDA 12.1。如果你用PyTorch 2.1（默认带CUDA 12.1），却装了个只支持CUDA 11.x的驱动，大概率会有兼容性报错。

最稳妥的办法是：先选定PyTorch版本，根据PyTorch官方说明确定需要的CUDA版本，再查NVIDIA官方驱动兼容表，用对应版本的驱动。这套顺序能避免90%的"环境装好但跑不了"问题。

第三步：确认容器运行时。

生产环境几乎都基于Docker跑GPU任务，而Docker默认不能直通GPU设备。需要安装NVIDIA Container Toolkit，并配置Docker使用nvidia作为默认运行时。这样容器内外GPU环境不一致的问题会大幅度减少。

# 安装nvidia-container-toolkit之后，确认Docker配置 docker info | grep -i runtime

3.2 用Docker构建可复现的训练开发环境

环境搭建的终极目标是"可复现"——同一个镜像在任何机器上跑出来的环境完全一致。实践中我通常基于NVIDIA官方镜像做二次封装。

我经常用的基础镜像是nvidia/cuda:12.1.1-cudnn8-devel-ubuntu22.04，然后在此之上装Python 3.10、PyTorch、以及项目依赖。

FROM nvidia/cuda:12.1.1-cudnn8-devel-ubuntu22.04 ENV DEBIAN_FRONTEND=noninteractive \ TZ=Asia/Shanghai RUN apt-get update && apt-get install -y \ python3.10 python3-pip git vim curl tmux \ && ln -s /usr/bin/python3.10 /usr/bin/python RUN pip install --no-cache-dir torch==2.1.0 --index-url https://download.pytorch.org/whl/cu121 RUN pip install --no-cache-dir \ transformers datasets accelerate deepspeed sentencepiece WORKDIR /workspace

这里有个经验：不要把大量数据文件放进镜像，镜像只负责环境；数据用Volume挂载进去。

构建完成后，运行容器：

docker run --gpus all -it --rm \ --shm-size=32g \ -v /mnt/data:/data \ -v $(pwd):/workspace \ my-ai-image:latest bash

注意--shm-size参数，PyTorch DataLoader的多进程通信依赖系统的/dev/shm共享内存，如果这个空间太小，加载数据时会报"Bus error"或"File descriptor limit"的错误。Docker默认shm大小只有64MB，这几乎是新手必踩的坑之一。

3.3 跑起第一个分布式训练脚本

环境通了，我们来做一个最小可行的分布式训练实验，用PyTorch的DistributedDataParallel（DDP）实现一个简单的图像分类训练。先确认你的集群能跑多卡。

python -c "import torch; print(torch.cuda.device_count(), torch.cuda.get_device_name(0))"

如果输出了GPU数量和型号，说明环境OK。下面是一个基础的单机多卡训练脚本模板，重点看两处：初始化进程组、切分数据集。

# train_ddp.py import os import torch import torch.distributed as dist import torch.nn as nn from torch.nn.parallel import DistributedDataParallel as DDP from torch.utils.data import DataLoader, DistributedSampler def init_process_group(): dist.init_process_group( backend="nccl", # GPU训练使用NCCL，CPU则用GLOO init_method="env://", # 从环境变量读取MASTER_ADDR和RANK ) def main(): # 这里的rank/gpu_id由训练启动器传入 local_rank = int(os.environ["LOCAL_RANK"]) global_rank = int(os.environ["RANK"]) torch.cuda.set_device(local_rank) init_process_group() device = torch.device("cuda", local_rank) model = nn.Linear(1024, 1024).to(device) ddp_model = DDP(model, device_ids=[local_rank]) dataset = torch.randn(20000, 1024) # 模拟数据集，实际换成你的数据 sampler = DistributedSampler(dataset, shuffle=True) loader = DataLoader(dataset, sampler=sampler, batch_size=256, num_workers=4) optimizer = torch.optim.SGD(ddp_model.parameters(), lr=0.01) criterion = nn.MSELoss() for epoch in range(5): sampler.set_epoch(epoch) # 每个epoch重新打乱数据 for x, y in loader: x = x.to(device) y = (x * 0.3).to(device) optimizer.zero_grad() loss = criterion(ddp_model(x), y) loss.backward() optimizer.step() if global_rank == 0: print(f"epoch {epoch} loss {loss.item():.4f}") dist.destroy_process_group() if __name__ == "__main__": main()

启动方式是使用PyTorch自带的torchrun：

torchrun --nnodes=1 --nproc_per_node=4 --rdzv_endpoint=localhost:29500 train_ddp.py

稍微解释一下几个关键点。

LOCAL_RANK是当前进程在本机内的编号（0到3），它决定进程使用哪张卡。RANK是全局编号，单机时和LOCAL_RANK一致，多机时每台机器上的RANK不重复。DistributedSampler的作用是让每个进程拿到数据集的不同切片，避免所有卡在每一轮都训练同一批数据。backend="nccl"是GPU训练几乎唯一的选择，因为NCCL在英伟达GPU间通信做了大量底层优化，GLOO的跨机性能和它没法比。

如果你发现多卡训练比单卡还慢，大概率就是以下三类问题：

• 数据加载是瓶颈：DataLoader的num_workers设置过低，GPU在等数据。把num_workers调到8~16，或者用prefetch_factor=4试试。
• 模型太小，通信开销大于计算收益：DDP每轮结束都会做梯度同步，如果计算量很小而通信频繁，多卡效率反而不如单卡。这种情况要加大batch size，让每次同步的"信息价值"更高。
• 跨机网络慢：经常发生在没有IB网络的环境里。可以用通信效率测试工具去验证，比如NCCL的all_reduce_perf工具。

3.4 从单机脚本到K8s集群调度

跑通了DDP脚本，算是拿到了第一块拼图。真正到了生产环境，你很快会发现直接在物理机上跑不符合工程化需求：没法弹性扩容、没有故障恢复、没有监控告警。

K8s集群里跑分布式训练，核心思路是"一个训练任务是一个Job，每个GPU进程是一个Pod"。当你有4张卡，就启动4个Pod，它们通过环境变量互相发现并建立通信。

为了让K8s感知GPU资源，需要部署NVIDIA Device Plugin，它把GPU资源暴露为可调度的扩展资源nvidia.com/gpu。然后在Pod声明中申请GPU：

apiVersion: v1 kind: Pod metadata: name: gpu-training spec: restartPolicy: OnFailure containers: - name: trainer image: my-ai-image:latest command: ["torchrun", "--nnodes=1", "--nproc_per_node=4", "train_ddp.py"] resources: limits: nvidia.com/gpu: 1

但这只是最朴素的写法。生产级方案会用Volcano或Kueue这类支持队列、优先级、公平调度的调度器，配合K8s的抢占机制和PodGroup概念，把一组Pod看成"一个任务"整体调度，而不是逐个Pod碰运气。

实际上现在国内不少智算平台提供的是"裸金属+Slurm"方案，K8s主要用于弹性推理服务。两条技术栈都有市场，入门阶段先把K8s的基础搞懂，再根据团队实际选型补第二步。

4. AI-Infra工具选型：训练、推理、调度、监控，逐个怎么选

AI-Infra工具生态更新快，经常有人问我"现在到底用什么"。我按照功能域给一张选型对照表，并写出我的取舍逻辑。

4.1 分布式训练框架选型对照

我的建议：第一套环境用PyTorch DDP跑通流程，然后转FSDP或DeepSpeed。上来直接挑战Megatron不太适合入门，因为你连DDP踩坑经验都没有，会同时遇到环境、通信、模型结构多维度问题，很难定位。

4.2 推理引擎与服务框架选型

单看推理引擎，vLLM是当前最主流的选择。它兼容Hugging Face模型权重，OpenAI协议接口，部署大模型几乎是"零改造"完成。但如果你的服务容器里除了推理还要做很多业务逻辑，例如请求过滤、多租户管理、灰度发布，这时候建议把vLLM嵌到Triton后面，让Triton做流量调度和模型生命周期管理。

4.3 调度与监控选型

调度方面，如果你的集群以HPC训练为主，Slurm更直接——作业排队、资源分配都是现成的。如果团队已经全面拥抱云原生，K8s + Volcano是当前国内事实标准，Kueue也在快速崛起，它轻量、原生支持队列和弹性配额。

监控方面，我的建议是：Prometheus + Grafana + DCGM-Exporter三件套。DCGM-Exporter把GPU的关键指标暴露成Prometheus格式，Grafana里可以直接导入NVIDIA官方提供的Dashboard模板，10分钟就能看到完整的GPU监控视图。

在此基础上再加一层日志系统（EFK或Loki）和链路追踪（如果你跑推理服务）。训练任务排查问题，日志是刚需，分布式任务日志分散在各个Pod里，搞一个统一的日志采集（如Filebeat/Fluentd发到ES或Loki）能省下无数时间。

5. 一线踩坑实录：这些问题，文档里不会写

做AI-Infra这行，踩坑才是成长的加速器。这一节我把最典型的五个问题的排查过程写出来，读者如果遇到类似现象，可以直接按路径查。

5.1 显存"看起来"够用，但训练直接OOM

现象：nvidia-smi看显存占用，每个进程只占一小部分，总占用也没满，但PyTorch训练到中途直接报CUDA out of memory。

排查思路：先弄清显存分配机制。PyTorch有缓存分配器（Caching Allocator），为了减少分配开销，它会一次性预留一大块显存，即使当前实际只用了一部分。看torch.cuda.memory_summary()能知道真实分配情况。如果某个中间Variable在反向传播时被保留，比如把loss的中间结果存到列表里，显存就会逐步累积。

解决：阶梯排查是先把batch size调小，看是否还OOM；如果小了还会OOM，检查是否有张量被意外地保留引用。也可以打开显存快照工具torch.cuda.memory_profile去细查。另外，建议在训练脚本中设置os.environ["PYTORCH_CUDA_ALLOC_CONF"]="expandable_segments:True"，这个参数可以让PyTorch按需扩展显存块，减少碎片化。

5.2 GPU利用率很低，但看起来CPU也没满

现象：GPU利用率曲线长期低于30%，但用top看CPU占用也不高，似乎一切正常。

排查方向：这个问题最常见的原因是"数据管道串行化"。具体来说，就是DataLoader的num_workers设置太低，或者数据读取过程中有锁竞争。另外一个隐蔽原因是"CPU内存和GPU显存之间的H2D拷贝"阻塞，也就是每批数据在从CPU传到GPU时，传输时间比计算时间长。

我曾经遇到过一个离谱的案例，数据是几千个小文件，存放在NFS共享存储上。每次取一个batch要跨网络打开几百个文件，延迟极高。后来把数据打成WebDataset格式，顺序读取，再配合num_workers提升，GPU利用率直接从20%跳到90%。

5.3 多机训练卡在"NCCL timeout"

现象：多机训练一开始工作正常，但运行几个小时后，某个节点上所有卡报NCCL通信超时，任务直接崩溃。

排查步骤：

1. 用nvidia-smi topo -m查看GPU拓扑，确认每张卡之间的通信路径是否走NVLink/PCIe Switch。
2. 用ibstatus或者ethtool -S检查网络接口的健康状态，重点关注丢包率和重传率。
3. 检查NCCL环境变量是否合理。NCCL_IB_DISABLE、NCCL_SOCKET_IFNAME这些变量如果设置错误，会导致NCCL走了TCP回退，通信效率暴跌。
4. 如果确认为网络偶发拥塞，可以在训练启动命令里加上NCCL_IB_TIMEOUT=22、NCCL_IB_RETRY_CNT=7这组参数，让NCCL对临时故障有更高的容忍度。

但这个问题的根治方案是"网络架构层面解决"——设置合理的拥塞控制算法、保证交换机无损网络配置、IB模式下检查子网管理器是否正常。

5.4 K8s里申请GPU，Pod一直Pending

现象：在K8s集群中创建Pod请求GPU资源，它一直处于Pending状态，kubectl describe pod显示"0/8 nodes available: insufficient nvidia.com/gpu"。

排查流程：

1. 先看集群节点是否安装了NVIDIA Device Plugin：kubectl -n kube-system get pods | grep nvidia，如果没有，就部署官方DaemonSet。
2. 再检查节点的可分配GPU数量：kubectl describe node <node-name>，看nvidia.com/gpu的Allocatable是否大于0。
3. 检查Device Plugin是否误以为GPU健康检查失败。有时候卡被MIG切分或处于错误状态，Device Plugin不会向调度器上报该GPU。
4. 如果你用的是Volcano/Kueue这类自定义调度器，Pod的排队信息不会显示在普通Pod的describe里，要去对应调度器的日志里查。

这类问题的高频原因是"驱动版本太旧导致DCGM健康检查超时"，升级驱动和container-toolkit版本后大多能恢复。

5.5 推理服务吞吐低，延迟却不稳定

现象：用vLLM部署一个LLM服务，压测时发现P99延迟很高，但P50很低。

原因大概率是"长尾效应"——个别超大请求（超长的输入序列）会阻塞continuous batching的调度。模型在做Prefill阶段（处理输入token）时，计算量和输入长度成正比；如果混入一个超长输入，它会在GPU上占据大块时间，后面的短请求就得排队等。

优化思路：

• 在服务层做请求长度过滤，超过阈值的请求走单独的异步队列。
• 调整max_num_batched_tokens和max_model_len的配置，限制单次batch的token总量。
• 使用vLLM的--enable-prefix-caching特性，对系统提示词这类固定前缀做缓存，大幅缩短重复输入的Prefill时间。
• 如果P99依然难压下去，考虑用小batch、低并发的"专用算力"池单独服务高SLA业务。

6. 我的体会与入行建议

AI-Infra这个方向，技术上杂，但杂有杂的好处——它逼着你从硬件到软件、从单机到集群、从开发到运维，把整条链路摸一遍。我记得很清楚，第一次在Grafana上看到自己搭的监控看板上GPU利用率稳定在90%以上、训练loss平稳下降的时候，那种成就感不亚于跑通一个全新模型。

给想入这行的朋友三个小建议。

第一个，先养成本地环境的"肌肉记忆"。把Docker、NVIDIA Container Toolkit、torchrun这些基础操作练熟，能在无头服务器上直接部署训练环境，这是后续一切工作的前提。

第二个，遇到性能问题，永远从数据流角度排查——数据从存储到GPU，分了几步？每步的耗时是多少？GPU到底在等什么？这个排查框架能解决80%的疑难杂症。

第三个，尽早建立监控意识。刚入门时可以只在任务开始和结束时看一眼nvidia-smi，但建议尽早接入DCGM + Prometheus，因为很多问题不是每次都能复现，只有当数据积累到一定程度，你才能看清规律。

第一章就先写到这里，后面我会结合一个完整项目，从零开始部署一个可弹性伸缩的AI推理服务，把这一章里提到的调度、推理、监控全部串起来。如果你想上AI-Infra这条路，建议先把这篇里的概念和技能树自己动手过一遍，有任何具体问题都欢迎在评论区聊，我看到了都会尽量回。