1. 从一次线上故障说起AI infra到底在解决什么问题去年冬天我参与的一个推理服务在晚高峰突然出现大面积超时。排查了整整一个下午最后发现问题不在模型本身也不在业务代码而是出在GPU显存碎片化导致的调度排队上——一个典型的infra层问题。这件事让我意识到很多做算法、做应用的同行对AI infra的理解还停留在就是搭个环境跑模型的层面而真正决定一个AI系统能不能扛住生产流量的恰恰是这层看不见的骨架。AI infra全称AI Infrastructure中文一般叫人工智能基础设施。它不是某一个具体框架也不是某一款硬件而是一整套支撑AI模型从训练到推理、从单机到集群、从实验到生产的底层系统集合。你可以把它理解成AI世界的水电煤交通网算力是电数据管道是水调度系统是交通信号灯而模型服务框架则是把这一切串起来的城市路网。没有这套东西再漂亮的模型也只能待在notebook里。这篇文章适合三类人看。第一类是算法工程师你可能天天调参但很少关心模型怎么被部署、显存怎么被管理了解infra能让你写出更落地的代码第二类是后端或平台工程师你正在被要求支持一下AI业务需要快速建立全局认知第三类是想转行做AI平台的技术人需要一个从零到一的知识地图。我会尽量避开纯学术的堆砌用我踩过的坑和实际项目里的取舍来讲清楚每个模块为什么这么设计。需要先说明一点AI infra是个极其庞大的领域一篇文章不可能覆盖所有细节。我的策略是抓住主干——算力、存储、调度、训练、推理、可观测性这几条线把每条线的核心矛盾讲透再补充一些容易被忽略但实际很要命的细节。读完你至少能知道当有人说我们的AI infra不行时他到底在说什么。2. 算力层GPU不是插上就能跑显存和互联才是真瓶颈2.1 为什么大家张口闭口都是显存刚入行的时候我以为GPU算力看的是TFLOPS后来被现实教育了绝大多数训练和推理任务瓶颈根本不在算力而在显存容量和显存带宽。原因很简单Transformer架构的参数量动辄几十亿上百亿每个参数在训练时还要存梯度、优化器状态Adam的话是两倍参数量再加上激活值显存需求是参数量的十几倍。一个7B的模型全量微调轻松吃掉80G以上的显存这就是为什么A100的80G版本比40G版本在AI圈更受欢迎。推理场景稍微好一点但也有KV Cache这个隐形杀手。自回归生成时每生成一个token都要缓存之前所有token的Key和Value矩阵序列越长、并发越高这部分占用越夸张。我见过一个案例模型权重只占13G但因为并发请求的KV Cache没管好显存直接爆到40G以上。所以现在做推理优化PagedAttention这类技术vLLM的核心才会这么火——它把KV Cache像操作系统管理内存页一样分块管理大幅减少碎片。提示评估一张卡能不能跑某个模型别只看参数量。经验公式是推理显存 ≈ 参数量 × 2字节FP16 KV Cache 框架开销训练则要再乘以4到6倍。留20%余量是底线。2.2 卡间互联被低估的性能杀手单卡再强也有上限大模型必须多卡并行。这时候卡与卡之间怎么通信就成了关键。NVLink和PCIe的带宽差距是数量级的——NVLink 4.0单卡双向能到900GB/s而PCIe 5.0 x16只有128GB/s左右。做张量并行Tensor Parallelism时每层都要做All-Reduce通信如果走PCIe通信时间可能比计算时间还长多卡加速比惨不忍睹。这也是为什么NVSwitch这种交换芯片重要——它让8张卡之间能全互联不用两两直连。实际选型时如果你要做70B以上模型的训练8卡NVLink机器基本是标配如果只是做小模型推理PCIe机器性价比更高。我个人的经验是先想清楚你的并行策略再倒推需要什么样的互联拓扑别盲目追求顶配。2.3 异构算力的现实不是所有任务都值得上GPU很多人一提AI infra就默认全是GPU其实CPU、NPU、甚至FPGA都在不同场景有位置。数据预处理、特征工程、小模型推理用CPU往往更划算一些特定算子用NPU能效比更高。真正的挑战在于异构调度——怎么让一个任务自动落到最合适的硬件上。这需要抽象出统一的资源描述和调度接口也是Kubernetes设备插件机制想解决的问题。我在项目里用过的一种做法是给不同硬件打标签任务提交时声明资源偏好调度器按标签匹配简单但有效。3. 数据与存储喂不饱的GPU背后往往是IO在拖后腿3.1 训练数据管道GPU等数据是最大的浪费GPU一小时几十块钱如果它有一半时间在等数据加载等于钱在烧。我见过最离谱的案例一个团队用NFS存训练数据几千张小图随机读IOPS直接打满GPU利用率长期在30%以下。后来换成对象存储加本地SSD缓存利用率才拉到80%以上。数据管道的核心设计原则是预取并行格式友好。预取是指用多进程/多线程提前把下一批数据读进内存并行是指读取、解码、增强这些步骤要能重叠格式友好是指别用一堆小文件尽量用TFRecord、WebDataset、Parquet这类适合顺序读的格式。WebDataset这个方案我特别推荐它把样本打包成tar分片配合流式读取对对象存储非常友好还能天然支持大规模分布式训练。3.2 检查点存储训练中断时的救命稻草大模型训练动辄几天几周中间挂了要从头来是不可接受的。所以检查点Checkpoint机制是刚需。但检查点本身也是个大问题——一个百亿参数模型的检查点可能几百G频繁写会拖慢训练写太慢又怕丢进度。常见的优化手段有几个。一是异步保存训练继续跑后台线程慢慢写盘二是分片保存每张卡只存自己负责的那部分参数避免单点写瓶颈三是分级存储最近几个检查点放高速存储老的归档到对象存储。我踩过的一个坑是检查点保存时没做原子性保证写到一半进程被kill结果检查点文件损坏回滚都回不去。后来改成先写临时文件再rename才算稳了。3.3 特征存储推理和训练的一致性难题做推荐、风控这类场景特征工程是核心。但训练时算特征和线上推理时算特征如果逻辑不一致就会出现训练效果好、上线就崩的经典问题。特征存储Feature Store就是为了解决这个——把特征的定义、计算、存储统一管理训练时读历史特征推理时读实时特征保证同一套逻辑。这块我建议中小团队别一上来就上重型特征存储平台先把特征计算逻辑抽成公共库训练和推理都调这个库就能解决80%的一致性问题。等规模上来了再考虑专门的存储系统。4. 调度与编排让成百上千个任务和谐共处4.1 为什么Kubernetes成了事实标准早年的AI任务调度是各搞各的Slurm管HPCYARN管大数据自己写脚本管GPU。Kubernetes出现后因为它强大的抽象能力和生态逐渐成了AI infra的调度底座。核心原因是它把资源抽象成了可扩展的对象通过Device Plugin机制能纳管GPU、NPU等各种设备通过Operator模式能编排复杂的分布式训练任务。但K8s原生调度器对AI任务并不友好。它默认是先到先得不理解Gang Scheduling要么全部卡都分到要么一个都不分。分布式训练如果只分到一半的卡任务会一直卡着等白白占资源。所以实际生产里通常要装Volcano、Kueue这类批调度器支持Gang Scheduling、队列、优先级、抢占这些能力。4.2 资源利用率AI集群最烧钱的地方一个GPU集群如果利用率只有30%等于70%的钱打了水漂。提升利用率的手段主要有几个层次。最基础的是资源配额和队列防止某个团队把卡占满进阶的是碎片整理把分散的小空闲卡拼成大块再往上是在离线混部把对延迟不敏感的离线训练和对延迟敏感的在线推理混在一起用优先级和抢占来动态调配。我参与过的一个项目通过引入抢占式调度把整体GPU利用率从45%提到了70%以上。关键设计是给在线任务设高优先级离线任务用低优先级但可以借资源一旦在线任务需要就立刻让出。难点在于让出时的检查点保存要快否则频繁抢占反而伤效率。4.3 多租户隔离别让一个任务拖垮整个集群共享集群最怕吵闹的邻居。一个任务疯狂读写存储或者占满网络其他任务全遭殃。隔离手段包括cgroup限制CPU和内存、GPU显存隔离MPS或MIG、网络QoS、存储IO限速。NVIDIA的MIG技术能把一张A100切成7个独立实例每个有独立的显存和计算单元隔离性很好适合多租户推理场景。但MIG会损失一些整体性能且切分后单实例显存有限要按业务需求权衡。5. 训练框架与并行策略把大模型塞进有限的卡里5.1 三种并行的取舍逻辑大模型训练绕不开三种并行数据并行DP、张量并行TP、流水线并行PP。数据并行最简单每张卡存完整模型喂不同数据梯度做All-Reduce。缺点是显存没省模型大了就放不下。张量并行是把单层内的矩阵运算切开分到多卡省显存但通信频繁适合卡间带宽高的场景比如同一台机器内。流水线并行是把不同层分到不同卡像工厂流水线一样通信量小但有气泡空闲等待需要精心设计微批次来填满。实际训练大模型通常是3D并行机器内用TP机器间用PP最外层用DP。比如训练一个百B模型可能8卡TP、若干组PP、再叠加DP。这个组合怎么定取决于你的集群拓扑和模型结构没有标准答案得实测调优。5.2 ZeRO与显存优化用通信换显存微软的ZeRO系列是显存优化的里程碑。它的核心思想是把数据并行里每张卡都存的冗余状态梯度、优化器状态、参数切分开每张卡只存一部分需要时再通信获取。ZeRO-1切优化器状态ZeRO-2再切梯度ZeRO-3连参数都切。级别越高越省显存但通信量也越大。实践中ZeRO-2是性价比比较高的选择ZeRO-3适合显存极度紧张的情况。配合混合精度训练FP16/BF16前向反向FP32主权重显存还能再降一半左右。BF16比FP16动态范围大不容易溢出现在新卡基本都优先用BF16。5.3 训练稳定性loss尖刺和通信超时分布式训练最让人头疼的是不稳定。loss突然尖刺spike是常见现象可能来自数据里的脏样本、梯度爆炸、或者某张卡算错了。应对手段包括梯度裁剪、loss scaling、跳过异常批次。我遇到过一次loss尖刺排查半天发现是某台机器的网卡有问题导致All-Reduce结果偶尔出错换了网卡就好了。所以训练不稳定时别只盯着算法硬件和网络也要查。通信超时也很常见尤其是跨机房或者网络抖动时。NCCL有一堆超时相关的环境变量可以调但治本还是要保证网络质量。我的经验是训练前先跑一遍NCCL的带宽测试心里有底。6. 推理服务从能跑到跑得又快又省6.1 推理引擎选型vLLM、TensorRT-LLM还是TGI现在主流推理引擎就那么几个。vLLM以PagedAttention和易用性著称社区活跃适合快速上线TensorRT-LLM是NVIDIA亲儿子性能极致但编译复杂适合追求极致吞吐的场景TGI是HuggingFace出品和生态集成好。选型时我会先看模型支持度再看团队维护能力。如果模型比较新vLLM通常跟进最快。一个容易忽略的点是批处理策略。静态批处理要等齐一批才处理延迟高连续批处理Continuous Batching能动态插入新请求吞吐和延迟都更好。vLLM和TensorRT-LLM都支持连续批处理这是它们相比朴素实现的核心优势。6.2 量化用精度换速度和显存量化是把模型权重从FP16降到INT8、INT4甚至更低直接减少显存占用和带宽压力。常见方案有GPTQ、AWQ、GGUF等。INT8量化通常精度损失很小INT4就要看模型和任务了有些任务掉点明显。我的建议是先在验证集上测精度别盲目追低比特。另外量化后的模型不一定在所有硬件上都加速有些卡对INT4支持不好反而更慢要实测。6.3 弹性伸缩与冷启动推理流量波动大白天高峰晚上低谷弹性伸缩能省不少钱。但AI推理的冷启动很慢——加载模型权重、初始化CUDA上下文、预热动辄几十秒。所以不能像普通微服务那样缩到零。常见做法是保留最小副本数用HPA按QPS或GPU利用率扩容同时做模型预热和镜像预拉取来缩短冷启动。我见过用模型缓存共享内存的方案多个副本共享一份权重能显著降低内存占用和启动时间。7. 可观测性出问题时你得知道去哪找7.1 指标、日志、追踪三件套AI系统的可观测性和普通后端有重叠也有特殊。指标方面除了常规的QPS、延迟、错误率还要盯GPU利用率、显存占用、SM占用率、NVLink带宽、温度功耗。日志方面训练日志要能关联到具体的rank和step推理日志要能追踪到请求级别的耗时分解。追踪方面一个请求经过网关、预处理、模型推理、后处理每一段都要能串起来。Prometheus Grafana是标配DCGM Exporter能采集GPU指标。但要注意指标基数别爆炸GPU指标按卡采集几百张卡就是几千个时间序列得做好聚合和降采样。7.2 训练任务的黑盒困境训练任务跑起来后除了loss曲线很多时候是黑盒。想看某层梯度分布、某张卡的通信耗时得额外埋点。我习惯在训练脚本里定期dump一些关键指标到TensorBoard或WandB包括梯度范数、学习率、各rank的step耗时。这些数据在排查性能瓶颈和稳定性问题时非常有用。有一次训练速度突然变慢就是靠对比各rank的step耗时定位到是某张卡所在的机器降频了。7.3 成本可观测性算清楚每块钱花在哪AI infra很烧钱所以成本可观测性越来越重要。要能按团队、按任务、按时间段统计GPU小时数算出每个模型、每个实验的成本。这需要调度层和计费系统打通。我见过一些团队用标签label来标记任务的归属调度器按标签聚合资源使用月底出账单。虽然粗糙但比一笔糊涂账强得多。8. 一些没人明说但很重要的经验先说一个反直觉的别过早追求先进架构。我见过太多团队一上来就搞3D并行、搞异构调度结果基础的数据管道都没理顺GPU天天等数据。正确的顺序是先保证单机训练跑得稳、数据喂得饱再考虑分布式。很多所谓的大规模需求其实优化一下单机效率就解决了。第二个经验是把环境一致性当回事。训练和推理的CUDA版本、驱动版本、依赖库版本不一致是无数诡异问题的根源。容器化是基本解法但要注意GPU容器的驱动是宿主机提供的容器里只装CUDA运行时。用NVIDIA Container Toolkit能省很多事。我建议把镜像版本和驱动版本做成矩阵明确哪些组合验证过。第三个是监控要覆盖沉默的失败。有些故障不报错只是变慢或者结果不对。比如静默的数据损坏、某张卡算力悄悄下降、网络丢包。这些靠错误日志发现不了得靠指标异常检测。给关键指标设合理的告警阈值比事后救火强。最后分享一个我常用的排查思路从下往上逐层排除。出问题时先看硬件层GPU是否降频、网络是否丢包再看系统层驱动、容器、调度再看框架层NCCL、PyTorch最后才怀疑模型和代码。因为底层问题往往表现为上层各种奇怪症状从下往上查能少走弯路。这个顺序帮我省过无数次瞎折腾的时间。AI infra这个领域变化很快新硬件、新框架、新论文层出不穷。但底层的那几个核心矛盾——算力与显存、计算与通信、吞吐与延迟、成本与性能——短期内不会变。抓住这些矛盾去理解每个新技术在解决什么比死记工具名有用得多。
AI基础设施实战：从线上故障到GPU调度与推理优化
1. 从一次线上故障说起AI infra到底在解决什么问题去年冬天我参与的一个推理服务在晚高峰突然出现大面积超时。排查了整整一个下午最后发现问题不在模型本身也不在业务代码而是出在GPU显存碎片化导致的调度排队上——一个典型的infra层问题。这件事让我意识到很多做算法、做应用的同行对AI infra的理解还停留在就是搭个环境跑模型的层面而真正决定一个AI系统能不能扛住生产流量的恰恰是这层看不见的骨架。AI infra全称AI Infrastructure中文一般叫人工智能基础设施。它不是某一个具体框架也不是某一款硬件而是一整套支撑AI模型从训练到推理、从单机到集群、从实验到生产的底层系统集合。你可以把它理解成AI世界的水电煤交通网算力是电数据管道是水调度系统是交通信号灯而模型服务框架则是把这一切串起来的城市路网。没有这套东西再漂亮的模型也只能待在notebook里。这篇文章适合三类人看。第一类是算法工程师你可能天天调参但很少关心模型怎么被部署、显存怎么被管理了解infra能让你写出更落地的代码第二类是后端或平台工程师你正在被要求支持一下AI业务需要快速建立全局认知第三类是想转行做AI平台的技术人需要一个从零到一的知识地图。我会尽量避开纯学术的堆砌用我踩过的坑和实际项目里的取舍来讲清楚每个模块为什么这么设计。需要先说明一点AI infra是个极其庞大的领域一篇文章不可能覆盖所有细节。我的策略是抓住主干——算力、存储、调度、训练、推理、可观测性这几条线把每条线的核心矛盾讲透再补充一些容易被忽略但实际很要命的细节。读完你至少能知道当有人说我们的AI infra不行时他到底在说什么。2. 算力层GPU不是插上就能跑显存和互联才是真瓶颈2.1 为什么大家张口闭口都是显存刚入行的时候我以为GPU算力看的是TFLOPS后来被现实教育了绝大多数训练和推理任务瓶颈根本不在算力而在显存容量和显存带宽。原因很简单Transformer架构的参数量动辄几十亿上百亿每个参数在训练时还要存梯度、优化器状态Adam的话是两倍参数量再加上激活值显存需求是参数量的十几倍。一个7B的模型全量微调轻松吃掉80G以上的显存这就是为什么A100的80G版本比40G版本在AI圈更受欢迎。推理场景稍微好一点但也有KV Cache这个隐形杀手。自回归生成时每生成一个token都要缓存之前所有token的Key和Value矩阵序列越长、并发越高这部分占用越夸张。我见过一个案例模型权重只占13G但因为并发请求的KV Cache没管好显存直接爆到40G以上。所以现在做推理优化PagedAttention这类技术vLLM的核心才会这么火——它把KV Cache像操作系统管理内存页一样分块管理大幅减少碎片。提示评估一张卡能不能跑某个模型别只看参数量。经验公式是推理显存 ≈ 参数量 × 2字节FP16 KV Cache 框架开销训练则要再乘以4到6倍。留20%余量是底线。2.2 卡间互联被低估的性能杀手单卡再强也有上限大模型必须多卡并行。这时候卡与卡之间怎么通信就成了关键。NVLink和PCIe的带宽差距是数量级的——NVLink 4.0单卡双向能到900GB/s而PCIe 5.0 x16只有128GB/s左右。做张量并行Tensor Parallelism时每层都要做All-Reduce通信如果走PCIe通信时间可能比计算时间还长多卡加速比惨不忍睹。这也是为什么NVSwitch这种交换芯片重要——它让8张卡之间能全互联不用两两直连。实际选型时如果你要做70B以上模型的训练8卡NVLink机器基本是标配如果只是做小模型推理PCIe机器性价比更高。我个人的经验是先想清楚你的并行策略再倒推需要什么样的互联拓扑别盲目追求顶配。2.3 异构算力的现实不是所有任务都值得上GPU很多人一提AI infra就默认全是GPU其实CPU、NPU、甚至FPGA都在不同场景有位置。数据预处理、特征工程、小模型推理用CPU往往更划算一些特定算子用NPU能效比更高。真正的挑战在于异构调度——怎么让一个任务自动落到最合适的硬件上。这需要抽象出统一的资源描述和调度接口也是Kubernetes设备插件机制想解决的问题。我在项目里用过的一种做法是给不同硬件打标签任务提交时声明资源偏好调度器按标签匹配简单但有效。3. 数据与存储喂不饱的GPU背后往往是IO在拖后腿3.1 训练数据管道GPU等数据是最大的浪费GPU一小时几十块钱如果它有一半时间在等数据加载等于钱在烧。我见过最离谱的案例一个团队用NFS存训练数据几千张小图随机读IOPS直接打满GPU利用率长期在30%以下。后来换成对象存储加本地SSD缓存利用率才拉到80%以上。数据管道的核心设计原则是预取并行格式友好。预取是指用多进程/多线程提前把下一批数据读进内存并行是指读取、解码、增强这些步骤要能重叠格式友好是指别用一堆小文件尽量用TFRecord、WebDataset、Parquet这类适合顺序读的格式。WebDataset这个方案我特别推荐它把样本打包成tar分片配合流式读取对对象存储非常友好还能天然支持大规模分布式训练。3.2 检查点存储训练中断时的救命稻草大模型训练动辄几天几周中间挂了要从头来是不可接受的。所以检查点Checkpoint机制是刚需。但检查点本身也是个大问题——一个百亿参数模型的检查点可能几百G频繁写会拖慢训练写太慢又怕丢进度。常见的优化手段有几个。一是异步保存训练继续跑后台线程慢慢写盘二是分片保存每张卡只存自己负责的那部分参数避免单点写瓶颈三是分级存储最近几个检查点放高速存储老的归档到对象存储。我踩过的一个坑是检查点保存时没做原子性保证写到一半进程被kill结果检查点文件损坏回滚都回不去。后来改成先写临时文件再rename才算稳了。3.3 特征存储推理和训练的一致性难题做推荐、风控这类场景特征工程是核心。但训练时算特征和线上推理时算特征如果逻辑不一致就会出现训练效果好、上线就崩的经典问题。特征存储Feature Store就是为了解决这个——把特征的定义、计算、存储统一管理训练时读历史特征推理时读实时特征保证同一套逻辑。这块我建议中小团队别一上来就上重型特征存储平台先把特征计算逻辑抽成公共库训练和推理都调这个库就能解决80%的一致性问题。等规模上来了再考虑专门的存储系统。4. 调度与编排让成百上千个任务和谐共处4.1 为什么Kubernetes成了事实标准早年的AI任务调度是各搞各的Slurm管HPCYARN管大数据自己写脚本管GPU。Kubernetes出现后因为它强大的抽象能力和生态逐渐成了AI infra的调度底座。核心原因是它把资源抽象成了可扩展的对象通过Device Plugin机制能纳管GPU、NPU等各种设备通过Operator模式能编排复杂的分布式训练任务。但K8s原生调度器对AI任务并不友好。它默认是先到先得不理解Gang Scheduling要么全部卡都分到要么一个都不分。分布式训练如果只分到一半的卡任务会一直卡着等白白占资源。所以实际生产里通常要装Volcano、Kueue这类批调度器支持Gang Scheduling、队列、优先级、抢占这些能力。4.2 资源利用率AI集群最烧钱的地方一个GPU集群如果利用率只有30%等于70%的钱打了水漂。提升利用率的手段主要有几个层次。最基础的是资源配额和队列防止某个团队把卡占满进阶的是碎片整理把分散的小空闲卡拼成大块再往上是在离线混部把对延迟不敏感的离线训练和对延迟敏感的在线推理混在一起用优先级和抢占来动态调配。我参与过的一个项目通过引入抢占式调度把整体GPU利用率从45%提到了70%以上。关键设计是给在线任务设高优先级离线任务用低优先级但可以借资源一旦在线任务需要就立刻让出。难点在于让出时的检查点保存要快否则频繁抢占反而伤效率。4.3 多租户隔离别让一个任务拖垮整个集群共享集群最怕吵闹的邻居。一个任务疯狂读写存储或者占满网络其他任务全遭殃。隔离手段包括cgroup限制CPU和内存、GPU显存隔离MPS或MIG、网络QoS、存储IO限速。NVIDIA的MIG技术能把一张A100切成7个独立实例每个有独立的显存和计算单元隔离性很好适合多租户推理场景。但MIG会损失一些整体性能且切分后单实例显存有限要按业务需求权衡。5. 训练框架与并行策略把大模型塞进有限的卡里5.1 三种并行的取舍逻辑大模型训练绕不开三种并行数据并行DP、张量并行TP、流水线并行PP。数据并行最简单每张卡存完整模型喂不同数据梯度做All-Reduce。缺点是显存没省模型大了就放不下。张量并行是把单层内的矩阵运算切开分到多卡省显存但通信频繁适合卡间带宽高的场景比如同一台机器内。流水线并行是把不同层分到不同卡像工厂流水线一样通信量小但有气泡空闲等待需要精心设计微批次来填满。实际训练大模型通常是3D并行机器内用TP机器间用PP最外层用DP。比如训练一个百B模型可能8卡TP、若干组PP、再叠加DP。这个组合怎么定取决于你的集群拓扑和模型结构没有标准答案得实测调优。5.2 ZeRO与显存优化用通信换显存微软的ZeRO系列是显存优化的里程碑。它的核心思想是把数据并行里每张卡都存的冗余状态梯度、优化器状态、参数切分开每张卡只存一部分需要时再通信获取。ZeRO-1切优化器状态ZeRO-2再切梯度ZeRO-3连参数都切。级别越高越省显存但通信量也越大。实践中ZeRO-2是性价比比较高的选择ZeRO-3适合显存极度紧张的情况。配合混合精度训练FP16/BF16前向反向FP32主权重显存还能再降一半左右。BF16比FP16动态范围大不容易溢出现在新卡基本都优先用BF16。5.3 训练稳定性loss尖刺和通信超时分布式训练最让人头疼的是不稳定。loss突然尖刺spike是常见现象可能来自数据里的脏样本、梯度爆炸、或者某张卡算错了。应对手段包括梯度裁剪、loss scaling、跳过异常批次。我遇到过一次loss尖刺排查半天发现是某台机器的网卡有问题导致All-Reduce结果偶尔出错换了网卡就好了。所以训练不稳定时别只盯着算法硬件和网络也要查。通信超时也很常见尤其是跨机房或者网络抖动时。NCCL有一堆超时相关的环境变量可以调但治本还是要保证网络质量。我的经验是训练前先跑一遍NCCL的带宽测试心里有底。6. 推理服务从能跑到跑得又快又省6.1 推理引擎选型vLLM、TensorRT-LLM还是TGI现在主流推理引擎就那么几个。vLLM以PagedAttention和易用性著称社区活跃适合快速上线TensorRT-LLM是NVIDIA亲儿子性能极致但编译复杂适合追求极致吞吐的场景TGI是HuggingFace出品和生态集成好。选型时我会先看模型支持度再看团队维护能力。如果模型比较新vLLM通常跟进最快。一个容易忽略的点是批处理策略。静态批处理要等齐一批才处理延迟高连续批处理Continuous Batching能动态插入新请求吞吐和延迟都更好。vLLM和TensorRT-LLM都支持连续批处理这是它们相比朴素实现的核心优势。6.2 量化用精度换速度和显存量化是把模型权重从FP16降到INT8、INT4甚至更低直接减少显存占用和带宽压力。常见方案有GPTQ、AWQ、GGUF等。INT8量化通常精度损失很小INT4就要看模型和任务了有些任务掉点明显。我的建议是先在验证集上测精度别盲目追低比特。另外量化后的模型不一定在所有硬件上都加速有些卡对INT4支持不好反而更慢要实测。6.3 弹性伸缩与冷启动推理流量波动大白天高峰晚上低谷弹性伸缩能省不少钱。但AI推理的冷启动很慢——加载模型权重、初始化CUDA上下文、预热动辄几十秒。所以不能像普通微服务那样缩到零。常见做法是保留最小副本数用HPA按QPS或GPU利用率扩容同时做模型预热和镜像预拉取来缩短冷启动。我见过用模型缓存共享内存的方案多个副本共享一份权重能显著降低内存占用和启动时间。7. 可观测性出问题时你得知道去哪找7.1 指标、日志、追踪三件套AI系统的可观测性和普通后端有重叠也有特殊。指标方面除了常规的QPS、延迟、错误率还要盯GPU利用率、显存占用、SM占用率、NVLink带宽、温度功耗。日志方面训练日志要能关联到具体的rank和step推理日志要能追踪到请求级别的耗时分解。追踪方面一个请求经过网关、预处理、模型推理、后处理每一段都要能串起来。Prometheus Grafana是标配DCGM Exporter能采集GPU指标。但要注意指标基数别爆炸GPU指标按卡采集几百张卡就是几千个时间序列得做好聚合和降采样。7.2 训练任务的黑盒困境训练任务跑起来后除了loss曲线很多时候是黑盒。想看某层梯度分布、某张卡的通信耗时得额外埋点。我习惯在训练脚本里定期dump一些关键指标到TensorBoard或WandB包括梯度范数、学习率、各rank的step耗时。这些数据在排查性能瓶颈和稳定性问题时非常有用。有一次训练速度突然变慢就是靠对比各rank的step耗时定位到是某张卡所在的机器降频了。7.3 成本可观测性算清楚每块钱花在哪AI infra很烧钱所以成本可观测性越来越重要。要能按团队、按任务、按时间段统计GPU小时数算出每个模型、每个实验的成本。这需要调度层和计费系统打通。我见过一些团队用标签label来标记任务的归属调度器按标签聚合资源使用月底出账单。虽然粗糙但比一笔糊涂账强得多。8. 一些没人明说但很重要的经验先说一个反直觉的别过早追求先进架构。我见过太多团队一上来就搞3D并行、搞异构调度结果基础的数据管道都没理顺GPU天天等数据。正确的顺序是先保证单机训练跑得稳、数据喂得饱再考虑分布式。很多所谓的大规模需求其实优化一下单机效率就解决了。第二个经验是把环境一致性当回事。训练和推理的CUDA版本、驱动版本、依赖库版本不一致是无数诡异问题的根源。容器化是基本解法但要注意GPU容器的驱动是宿主机提供的容器里只装CUDA运行时。用NVIDIA Container Toolkit能省很多事。我建议把镜像版本和驱动版本做成矩阵明确哪些组合验证过。第三个是监控要覆盖沉默的失败。有些故障不报错只是变慢或者结果不对。比如静默的数据损坏、某张卡算力悄悄下降、网络丢包。这些靠错误日志发现不了得靠指标异常检测。给关键指标设合理的告警阈值比事后救火强。最后分享一个我常用的排查思路从下往上逐层排除。出问题时先看硬件层GPU是否降频、网络是否丢包再看系统层驱动、容器、调度再看框架层NCCL、PyTorch最后才怀疑模型和代码。因为底层问题往往表现为上层各种奇怪症状从下往上查能少走弯路。这个顺序帮我省过无数次瞎折腾的时间。AI infra这个领域变化很快新硬件、新框架、新论文层出不穷。但底层的那几个核心矛盾——算力与显存、计算与通信、吞吐与延迟、成本与性能——短期内不会变。抓住这些矛盾去理解每个新技术在解决什么比死记工具名有用得多。