1. 从零搭建AI Infra知识全景一个后端老兵的学习路线复盘这两年AI应用层卷得飞起但真正把模型跑起来、跑稳、跑便宜的那批人反而越来越稀缺。我自己是从传统后端转过来的刚开始以为“不就是调个API嘛”结果第一次自己部署推理服务就被显存、并发、量化、调度这些概念按在地上摩擦。后来花了小半年时间把AI Infra这条线上的知识点从头到尾捋了一遍形成了一套自己的学习笔记。这篇文章就是把这套笔记重新整理出来讲清楚AI Infra到底包含哪些模块、每个模块的核心技术点是什么、学习顺序应该怎么安排、以及我在实操中踩过的那些坑。如果你是有后端基础想转AI Infra的开发者或者已经在做算法但想把工程侧补齐的工程师再或者是对“模型怎么从训练到上线”这件事好奇的技术管理者这篇内容应该都能给你一个相对完整的知识地图。我不会只列概念每个模块都会说清楚它解决什么问题、关键参数怎么算、实操时注意什么。全文比较长建议先收藏按章节顺序看。2. AI Infra知识全景的整体框架拆解2.1 为什么需要一张“全景图”而不是零散学我一开始学的时候是典型的“哪疼医哪”服务OOM了去查显存优化延迟高了去看批处理成本超了才想起来量化。这种学法的问题是你永远在救火而且每次救完不知道下一个火在哪。AI Infra本质上是一个系统工程从硬件选型、集群调度、模型压缩、推理引擎、服务框架到监控运维每一层都跟上下层强耦合。比如你选了INT8量化推理引擎得支持服务框架的batch策略也得跟着调不然精度掉了你还以为是模型问题。所以我的建议是先建立一张全景图知道每个模块在整条链路里的位置和职责然后再逐个深入。这样你在遇到问题时能快速定位是哪个层出了问题而不是盲目试错。2.2 六层架构从硬件到业务的全链路我把AI Infra拆成六个层次从下往上依次是硬件层GPU/CPU/NPU、显存带宽、互联技术NVLink、PCIe、存储IO。这一层决定了你的算力上限和成本基线。集群与调度层K8s、Slurm、Ray、Volcano等负责资源分配、任务编排、多租户隔离。核心问题是“怎么让有限的卡跑更多的任务”。训练框架层PyTorch、TensorFlow、JAX以及分布式训练策略DDP、FSDP、Megatron、DeepSpeed。这一层关注的是“怎么把大模型训起来”。模型压缩与转换层量化PTQ/QAT、剪枝、蒸馏、ONNX导出、TensorRT编译。核心目标是“让模型更小更快”。推理引擎与服务层vLLM、TensorRT-LLM、TGI、Triton、SGLang以及服务框架的批处理、缓存、路由策略。这一层直接决定线上延迟和吞吐。监控与运维层Prometheus、Grafana、DCGM、日志采集、告警、成本核算。没有这一层前面所有优化都是盲人摸象。这六层不是孤立的比如你在推理层做continuous batching底层调度层就得支持弹性扩缩容监控层得能采集到batch size和queue length。理解层与层之间的接口和约束比单独学某一层更重要。2.3 学习顺序为什么我建议“自顶向下”而不是“自底向上”很多人建议先学CUDA、再学分布式、再学推理我觉得对转行者来说这个顺序容易劝退。我的实际路径是反过来的先从推理服务入手把模型跑起来遇到性能问题再往下挖。具体来说先学推理引擎的基本用法比如用vLLM起一个服务然后观察它的瓶颈在哪——是显存不够、还是batch调度不合理、还是KV Cache管理有问题。带着这些问题再去学量化、学调度、学显存优化学习动力和效果完全不一样。自底向上适合科班做系统研究的人自顶向下适合工程背景想快速上手的人。3. 核心模块深度解析与关键技术点3.1 推理引擎vLLM、TensorRT-LLM、TGI怎么选推理引擎是AI Infra里最直接影响线上表现的一层。我实际用过的三个主流方案各有适用场景。vLLM最大的卖点是PagedAttention把KV Cache按页管理显存利用率能提升到90%以上。它的continuous batching也是标配适合请求长度差异大的场景。缺点是自定义算子不如TensorRT灵活极端性能场景下略逊。TensorRT-LLM是NVIDIA亲儿子编译后性能最强尤其在小batch低延迟场景。但它对模型结构有要求编译过程复杂换模型要重新编译迭代速度慢。适合模型稳定、追求极致性能的生产环境。TGIText Generation Inference是HuggingFace出的生态好、上手快支持动态批处理和流式输出。性能介于前两者之间适合快速验证和中小规模部署。选型时我会问三个问题模型会不会频繁换延迟要求是P99还是平均团队有没有精力维护编译流程答案不同选择就不同。下面这张表是我自己的经验总结维度vLLMTensorRT-LLMTGI上手难度低高低极致性能中高高中模型兼容性好中好迭代速度快慢快适合场景通用生产稳定高性能快速验证3.2 显存优化KV Cache到底吃多少显存这是我最开始完全没概念的地方。KV Cache的大小可以粗略估算KV Cache显存 ≈ 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × batch_size × 数据类型字节数举个例子一个7B模型32层32个头头维度128FP162字节序列长度2048batch_size为1时2 × 32 × 32 × 128 × 2048 × 1 × 2 ≈ 1.07 GB看起来不大但batch_size到32就是34GB直接爆掉一张24G的卡。所以线上服务必须做KV Cache管理要么用PagedAttention分页要么限制最大序列长度要么做量化。我实测下来把KV Cache量化到INT8显存能省将近一半精度损失在可接受范围内。3.3 量化PTQ和QAT的取舍量化是降本最直接的手段。PTQ训练后量化不需要重新训练拿现成模型校准一下就行适合快速上线。QAT量化感知训练要在训练时模拟量化误差精度更好但成本高。我一般先用PTQ试如果精度掉得厉害比如超过2个点再考虑QAT。校准集的选择很关键不能用训练集要用真实分布的验证集否则量化参数会偏。另外注意不是所有层都适合量化attention的softmax前后、layer norm这些对精度敏感的地方通常保留FP16。3.4 分布式训练DDP、FSDP、张量并行的适用边界训练侧的知识点也很多但作为Infra工程师至少要理解三种并行策略数据并行DDP每张卡一份完整模型数据切分。适合模型能放进单卡的情况。全分片数据并行FSDP/ZeRO模型参数、梯度、优化器状态分片到各卡。适合中等规模模型通信开销可控。张量并行流水并行把单层切开或按层切分。适合超大模型但通信复杂调试难度高。选择依据很简单模型能不能放进单卡能就用DDP不能但能放进单节点多卡用FSDP再大就得上张量并行。我踩过的坑是FSDP的sharding策略配错了导致通信量翻倍训练速度反而比DDP慢。后来发现是reshard_after_forward参数没设对这个细节文档里写得很隐蔽。4. 实操过程从模型到线上服务的完整链路4.1 环境准备与依赖管理我习惯用容器化环境避免依赖冲突。基础镜像选CUDA runtime版本注意驱动版本要匹配。Python依赖用conda或uv管理推理引擎单独建环境。这里有个细节vLLM和TensorRT-LLM对CUDA版本要求不同别装在一个环境里。# 以vLLM为例的环境准备 conda create -n vllm python3.10 conda activate vllm pip install vllm # 验证 python -c import vllm; print(vllm.__version__)4.2 模型量化与转换实操以PTQ为例用GPTQ或AWQ做4bit量化。我一般用AWQ因为它在小模型上精度保持更好。校准集准备128到512条真实样本太多没必要太少会偏。# AWQ量化示意基于常见实践 from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path your-model-path quant_path your-quant-path quant_config {zero_point: True, q_group_size: 128, w_bit: 4, version: GEMM} model AutoAWQForCausalLM.from_pretrained(model_path) tokenizer AutoTokenizer.from_pretrained(model_path) model.quantize(tokenizer, quant_configquant_config) model.save_quantized(quant_path)量化后一定要做精度对比用同样的测试集跑一遍看输出差异。我遇到过量化后模型开始重复输出的问题后来发现是校准集里长文本太少调整后就好了。4.3 推理服务部署与参数调优用vLLM起服务关键参数有几个--max-model-len最大序列长度直接影响KV Cache显存。--gpu-memory-utilization显存利用率默认0.9我一般设0.85留余量。--max-num-seqs最大并发序列数跟batch策略相关。--tensor-parallel-size张量并行度多卡时设置。python -m vllm.entrypoints.openai.api_server \ --model your-quant-path \ --max-model-len 4096 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 64 \ --tensor-parallel-size 1启动后先用小流量压测观察显存和延迟。我习惯用locust或wrk做压测重点看P99延迟和吞吐量随并发的变化曲线。如果P99突然飙升通常是batch排满了需要调max-num-seqs或加卡。4.4 监控指标与告警配置线上服务必须监控这几个指标GPU利用率、显存占用、请求队列长度、P99延迟、每秒token数。用DCGM exporter采集GPU指标Prometheus存储Grafana展示。告警阈值我一般设显存超过90%告警、P99延迟超过基线1.5倍告警、队列长度持续大于阈值告警。这里有个经验不要只看平均值要看分位数。平均延迟可能很好看但P99已经炸了用户体验照样差。5. 常见问题与排查技巧实录5.1 显存OOM的排查思路OOM是最常见的问题。我的排查顺序是先看是不是KV Cache太大调小max-model-len或max-num-seqs再看是不是模型本身太大量化或换更小模型最后看是不是有内存泄漏长时间运行后显存持续增长。有个隐蔽的坑PyTorch的缓存分配器会保留已释放的显存导致nvidia-smi看到的占用比实际高。可以用torch.cuda.empty_cache()手动清理但线上不建议频繁调用会影响性能。5.2 推理延迟突然升高的定位方法延迟升高通常有三个原因请求量突增、batch调度不合理、某个请求卡住了。我会先看队列长度如果队列长但GPU利用率低说明调度有问题如果GPU利用率高但延迟高说明计算量到了瓶颈。还有一个容易忽略的点网络IO。如果模型权重放在远程存储加载时会拖慢首次推理。建议把权重预加载到本地或内存。5.3 量化后精度下降的补救措施精度下降先别急着放弃量化。可以尝试换校准集、调整量化粒度per-channel比per-tensor好、对敏感层保留FP16、用QAT替代PTQ。我遇到过4bit量化后精度掉3个点的情况把校准集从128条增加到512条后降到1个点以内。5.4 多卡并行时的通信瓶颈多卡推理时张量并行的通信开销可能成为瓶颈。如果发现加卡后吞吐没提升甚至下降先检查NVLink是否启用、通信是否走了PCIe。另外tensor-parallel-size不是越大越好一般不超过单节点卡数跨节点通信延迟太高。下面这张表是我整理的高频问题速查问题现象可能原因排查动作显存OOMKV Cache过大/模型过大调小序列长度/量化P99延迟高batch排满/调度问题调max-num-seqs/看队列吞吐上不去通信瓶颈/GPU利用率低检查NVLink/调并行度精度下降量化误差/校准集偏差换校准集/保留敏感层服务不稳定内存泄漏/资源竞争长跑监控/隔离资源6. 学习资源与进阶路径建议6.1 我实际用过的学习材料类型我不太推荐一上来就看论文容易陷进去出不来。我的路径是先看官方文档和quickstart把服务跑起来然后看源码里的关键模块比如vLLM的scheduler和block manager最后再回头看论文理解设计动机。这样看论文时能对应到具体代码理解更深。6.2 从单机到集群的能力跃迁单机跑通只是第一步。集群环境下要考虑资源隔离、任务优先级、故障恢复、多租户计费。我建议先在单机上把推理服务调优到极限再上K8s做编排。上集群后重点学Volcano或Ray的调度策略以及怎么做弹性扩缩容。6.3 成本核算每百万token的真实成本怎么算这是很多团队忽略的。成本包括GPU租用或折旧、电力、运维人力。粗略估算一张A100按每小时10元算吞吐1000 token/s那每百万token成本约2.8元。量化到INT8后吞吐翻倍成本降到1.4元。这个账算清楚了才知道优化方向在哪。我个人在实际操作中的体会是AI Infra的学习没有捷径但有一条相对高效的路径先跑通再调优再深入原理。每遇到一个问题就把它当成一个学习入口挖到底。半年下来你会发现那些曾经陌生的概念已经变成你排查问题时的直觉了。最后分享一个小技巧养成记录的习惯每次调参、每次踩坑都记下来三个月后回看进步速度会超出你想象。