1. 为什么一线工程师都在聊AI-Infra这两年跟同行吃饭话题从“你们公司用啥框架”慢慢变成了“你们推理集群怎么管的”“模型上线卡在哪一步”。这个转变挺有意思说明大家关注的重心从“模型能不能跑通”挪到了“模型能不能稳定、便宜、高效地跑在线上”。这就是AI-Infra人工智能基础设施这个词被反复提起的背景。我自己是从业务后端转过来的头两年做推荐系统后来被拉去搞模型服务平台踩了无数坑。回头看AI-Infra这条路对一线工程师来说既是机会也是挑战。机会在于它横跨了传统后端、运维、数据、算法多个领域能建立比较宽的护城河挑战在于它没有一门课能从头教到尾很多东西得靠自己在真实场景里磨。这篇算是我个人梳理的第一章主要聊清楚三件事AI-Infra到底包含哪些东西、一线工程师日常在解决什么问题、以及想入门的话该从哪几个点切入。适合已经有一定后端或运维基础、想往这个方向靠的朋友也适合算法同学了解自己模型上线时对面那帮人在忙什么。2. AI-Infra到底在解决什么问题2.1 从“能跑”到“跑得好”的鸿沟很多人第一次接触AI-Infra是因为模型在本地notebook里跑得好好的一上线就出问题。这个鸿沟不是玄学拆开看无非几类资源利用率低、延迟不稳定、成本失控、故障难定位。举个我亲历的例子。早期我们做一个图像分类服务单机单卡部署QPS一上来GPU利用率只有15%左右但延迟已经飙到800ms。当时第一反应是模型太大想换小模型。后来用profiling工具一查发现瓶颈根本不在计算而在数据预处理——Python的PIL库做解码和resize是单线程的把GPU活活饿死了。换成GPU解码加批处理之后同样硬件QPS翻了六倍。这个例子说明一个核心问题AI-Infra的价值不在于让模型算得更快而在于让整个链路里没有明显的短板。木桶效应在这个领域特别明显。2.2 四层结构硬件、调度、服务、观测我习惯把AI-Infra分成四层来理解这样排查问题的时候能快速定位在哪一层。硬件层包括GPU、NPU、高速网络比如RDMA、存储。这一层工程师能动的空间其实不大主要是选型和拓扑设计。但选型错了后面很难救比如做大规模训练时网络带宽不够梯度同步就会成为瓶颈。调度层解决的是“谁用哪块卡”的问题。小团队可能直接用Kubernetes加设备插件就够了大团队会自研或采用更复杂的调度器考虑拓扑感知、抢占、配额、碎片整理。这一层做得好不好直接决定集群的整体利用率。服务层是模型对外提供能力的部分包括推理框架TensorRT、vLLM、TGI等、批处理策略、动态扩缩容、多模型混部。这一层跟业务贴得最近也是大多数一线工程师花时间最多的地方。观测层容易被忽视但出故障时全靠它。指标、日志、链路追踪三件套在AI场景下有特殊性比如要监控GPU显存、SM利用率、KV Cache命中率这些传统监控没有的指标。提示新手容易一上来就钻服务层觉得推理优化最酷。但实际工作中调度层和观测层的问题往往更消耗时间建议均衡投入。2.3 和传统后端的区别在哪有后端经验的同学转过来会觉得很多东西似曾相识不都是服务、不都要扩缩容、不都要监控吗区别主要在三个地方。第一是资源异构且昂贵。CPU服务扩缩容相对线性GPU不是一块A100和两块A100的性能关系取决于任务类型可能是1.8倍也可能是1.2倍。而且GPU贵闲置就是烧钱所以调度粒度、共享策略比CPU场景复杂得多。第二是性能瓶颈位置不同。传统后端瓶颈常在数据库或网络IOAI服务瓶颈可能在计算、显存带宽、数据搬运、甚至Python GIL。排查工具和思路都要换一套。第三是版本和依赖的复杂度。CUDA、驱动、框架、模型格式之间有一张兼容性矩阵升一个版本可能牵一发动全身。我见过因为驱动版本差一个小号导致某个算子性能掉一半的情况。3. 一线工程师的日常几个真实场景拆解3.1 场景一推理服务延迟毛刺排查线上服务P99延迟时不时冒尖平均延迟却正常这是最让人头疼的一类问题。我处理过一个典型案例现象是每隔几分钟P99跳到2秒以上持续几秒又恢复。排查思路是这样的先看监控时间线发现毛刺和某个定时任务的时间点吻合。那个任务是个日志归档脚本会大量读磁盘。但磁盘IO高为什么会影响到GPU推理继续查发现日志目录和模型文件目录在同一块盘上归档时把模型权重从page cache里挤出去了推理时重新加载权重导致卡顿。解决办法很简单把模型文件放到独立的SSD或者用tmpfs常驻内存。但发现问题的过程花了整整两天因为一开始大家都在盯着GPU看。这个案例的经验是AI服务的延迟问题答案经常不在GPU上。CPU、内存、磁盘、网络任何一个环节都可能成为元凶。排查时要有全局视角先看时间相关性再逐层排除。3.2 场景二多模型混部的显存博弈业务方总希望一个集群里塞尽可能多的模型但显存是硬约束。我们做过一个混部方案把几个中小模型放在同一张卡上用MPSMulti-Process Service做隔离。这里的关键是显存预留策略。如果每个模型都按峰值显存预留浪费严重如果按均值预留高峰期会OOM。我们的做法是给每个模型设一个软上限和一个硬上限软上限触发时开始驱逐低优先级请求硬上限触发时直接拒绝新请求。软硬上限之间留20%的缓冲。参数怎么定我们统计了每个模型过去一周的显存使用分布取P95作为软上限P99.9作为硬上限。这样既保证了绝大多数请求正常又不会因为个别异常请求拖垮整张卡。实测下来混部后单卡承载的模型数从2个提升到5个整体GPU利用率从40%提到65%左右。代价是运维复杂度上升需要一套精细的配额管理和告警机制。3.3 场景三训练任务排队与抢占训练集群和推理集群的管理逻辑完全不同。训练任务动辄跑几小时到几天排队是常态。我们早期用简单的FIFO队列结果小任务被大任务堵死用户体验很差。后来改成多级反馈队列加抢占。高优先级的小任务可以抢占低优先级大任务的资源被抢占的任务做checkpoint后重新排队。这里有个细节checkpoint的频率很关键。太频繁影响训练速度太稀疏被抢占时丢的进度多。我们最后定的是每15分钟或每500个step存一次取两者先到的。抢占策略还要考虑“抢占代价”。有些任务已经跑了很久快结束了这时候抢占它损失很大。我们加了一个“剩余时间预估”的权重剩余时间短的任务降低被抢占概率。这个预估用历史同类任务的平均时长来算虽然粗糙但有效。注意抢占策略一定要有上限不能让某个任务无限被抢占。我们设了最多被抢占3次超过就提升优先级避免饿死。4. 想入门AI-Infra该补哪些课4.1 基础能力清单如果你已经有后端或运维基础下面这些是需要额外补的。我按优先级排一下。第一优先级GPU编程模型和性能分析。不需要会写CUDA kernel但要理解SM、warp、显存层次这些概念会用nsight、nvprof这类工具看瓶颈在哪。这是跟算法同学对话的基础也是做优化的前提。第二优先级容器与编排。Kubernetes是事实标准设备插件、Operator、自定义调度器这些要熟悉。如果公司用的是别的编排系统原理也类似。第三优先级推理框架原理。至少深入用过一种比如TensorRT、vLLM或TGI。理解连续批处理、PagedAttention、量化这些技术解决了什么问题。第四优先级可观测性体系。Prometheus、Grafana、OpenTelemetry这套要会搭会用还要知道AI场景下该采集哪些特殊指标。4.2 学习路径建议我不建议一上来就啃论文效率低且容易劝退。比较务实的路径是先找一个真实的小项目练手比如把某个开源模型部署起来压测然后尝试优化。具体可以这样拿一个7B左右的模型用vLLM部署写个脚本压测记录QPS、延迟、显存占用。然后尝试调参数——改batch size、改max tokens、开量化——观察指标变化。这个过程会让你对推理服务的各种权衡有直观感受。第二步是把这个服务容器化用Kubernetes管理模拟多副本扩缩容。这时候会遇到调度、网络、存储的各种问题一个个解决就是最好的学习。第三步是搭监控把前面采集的指标可视化设置告警。然后故意制造一些故障比如kill进程、占满显存看告警是否准确、恢复是否自动。这三步走完你对AI-Infra的主要环节就有了实操层面的理解比看十篇综述都管用。4.3 常见误区提醒第一个误区是过度追求新技术。这个领域新东西确实多但生产环境讲究稳定。我见过团队为了用某个新框架把稳定的服务重构结果踩了一堆坑又回滚。新技术可以了解但上生产要谨慎。第二个误区是忽视成本核算。GPU很贵一个优化做下去省了10%延迟但多用了20%显存可能整体成本反而上升。做任何优化前先算清楚账。第三个误区是只关注单点性能。单模型推理再快如果调度不合理、扩缩容不及时整体吞吐也上不去。要有系统思维。5. 几个容易被忽略的实操细节5.1 模型加载速度优化模型冷启动慢是常见痛点。一个7B模型从磁盘加载到GPU可能要几十秒扩缩容时这段时间服务能力是缺失的。优化手段有几个。一是用内存文件系统缓存模型权重避免每次从磁盘读。二是做模型预热新实例起来后先跑几个假请求把CUDA上下文、显存池都初始化好。三是用模型分片加载先加载部分层就能开始服务剩下的后台继续加载。我们实测过组合使用这些手段冷启动时间从45秒降到8秒左右。对于需要快速扩缩容的场景这个提升很关键。5.2 批处理策略的取舍批处理是提升吞吐的利器但会牺牲延迟。怎么平衡我们的做法是设一个最大等待时间比如50ms在这个窗口内尽可能攒批窗口一到就发出去。这样延迟有上限吞吐也能提升。动态批处理比静态批处理复杂但效果好很多。静态批处理要求请求长度一致实际场景很难满足。动态批处理可以处理变长请求但要注意padding带来的浪费。现在主流推理框架都支持连续批处理能把不同请求的token拼在一起算浪费更少。提示批处理参数没有万能值要根据业务延迟要求和流量特征调。建议从保守值开始逐步放宽观察P99延迟变化。5.3 故障恢复的自动化AI服务故障原因多人工恢复慢。我们做了一套自动化恢复流程监控发现异常后先尝试重启容器如果重启无效尝试迁移到其他节点如果还不行触发告警让人介入。这里的关键是区分故障类型。有些故障重启能解决比如显存泄漏导致的OOM有些重启没用比如模型文件损坏。自动化流程要能识别这些差异否则会陷入重启循环。我们维护了一个故障特征库记录每种故障的表现和有效处理方式。新故障出现时先人工处理处理完把特征加进去下次就能自动处理。这个库慢慢积累现在能自动处理80%以上的常见故障。6. 关于这个系列后续想聊的内容第一章先搭个框架把AI-Infra的全貌和入门路径讲清楚。后面我计划深入几个专题推理服务的性能调优实战、训练集群的调度策略设计、以及成本优化的具体案例。每个专题都会尽量用真实数据和踩坑经历来说话少讲空泛的理论。如果你也在做类似的事情欢迎交流这个领域变化快一个人闭门造车容易走偏。我个人在实际操作中的体会是AI-Infra没有银弹每个优化都有代价关键是搞清楚当前系统的主要矛盾是什么。是延迟不够好还是成本太高还是稳定性差目标不同手段完全不同。先诊断再开药这个顺序不能反。 
长河君 · 2026/10/27 17:41:43 · 阅读 1.2k AI-Infra入门指南：一线工程师如何跨越模型上线的鸿沟
1. 为什么一线工程师都在聊AI-Infra这两年跟同行吃饭话题从“你们公司用啥框架”慢慢变成了“你们推理集群怎么管的”“模型上线卡在哪一步”。这个转变挺有意思说明大家关注的重心从“模型能不能跑通”挪到了“模型能不能稳定、便宜、高效地跑在线上”。这就是AI-Infra人工智能基础设施这个词被反复提起的背景。我自己是从业务后端转过来的头两年做推荐系统后来被拉去搞模型服务平台踩了无数坑。回头看AI-Infra这条路对一线工程师来说既是机会也是挑战。机会在于它横跨了传统后端、运维、数据、算法多个领域能建立比较宽的护城河挑战在于它没有一门课能从头教到尾很多东西得靠自己在真实场景里磨。这篇算是我个人梳理的第一章主要聊清楚三件事AI-Infra到底包含哪些东西、一线工程师日常在解决什么问题、以及想入门的话该从哪几个点切入。适合已经有一定后端或运维基础、想往这个方向靠的朋友也适合算法同学了解自己模型上线时对面那帮人在忙什么。2. AI-Infra到底在解决什么问题2.1 从“能跑”到“跑得好”的鸿沟很多人第一次接触AI-Infra是因为模型在本地notebook里跑得好好的一上线就出问题。这个鸿沟不是玄学拆开看无非几类资源利用率低、延迟不稳定、成本失控、故障难定位。举个我亲历的例子。早期我们做一个图像分类服务单机单卡部署QPS一上来GPU利用率只有15%左右但延迟已经飙到800ms。当时第一反应是模型太大想换小模型。后来用profiling工具一查发现瓶颈根本不在计算而在数据预处理——Python的PIL库做解码和resize是单线程的把GPU活活饿死了。换成GPU解码加批处理之后同样硬件QPS翻了六倍。这个例子说明一个核心问题AI-Infra的价值不在于让模型算得更快而在于让整个链路里没有明显的短板。木桶效应在这个领域特别明显。2.2 四层结构硬件、调度、服务、观测我习惯把AI-Infra分成四层来理解这样排查问题的时候能快速定位在哪一层。硬件层包括GPU、NPU、高速网络比如RDMA、存储。这一层工程师能动的空间其实不大主要是选型和拓扑设计。但选型错了后面很难救比如做大规模训练时网络带宽不够梯度同步就会成为瓶颈。调度层解决的是“谁用哪块卡”的问题。小团队可能直接用Kubernetes加设备插件就够了大团队会自研或采用更复杂的调度器考虑拓扑感知、抢占、配额、碎片整理。这一层做得好不好直接决定集群的整体利用率。服务层是模型对外提供能力的部分包括推理框架TensorRT、vLLM、TGI等、批处理策略、动态扩缩容、多模型混部。这一层跟业务贴得最近也是大多数一线工程师花时间最多的地方。观测层容易被忽视但出故障时全靠它。指标、日志、链路追踪三件套在AI场景下有特殊性比如要监控GPU显存、SM利用率、KV Cache命中率这些传统监控没有的指标。提示新手容易一上来就钻服务层觉得推理优化最酷。但实际工作中调度层和观测层的问题往往更消耗时间建议均衡投入。2.3 和传统后端的区别在哪有后端经验的同学转过来会觉得很多东西似曾相识不都是服务、不都要扩缩容、不都要监控吗区别主要在三个地方。第一是资源异构且昂贵。CPU服务扩缩容相对线性GPU不是一块A100和两块A100的性能关系取决于任务类型可能是1.8倍也可能是1.2倍。而且GPU贵闲置就是烧钱所以调度粒度、共享策略比CPU场景复杂得多。第二是性能瓶颈位置不同。传统后端瓶颈常在数据库或网络IOAI服务瓶颈可能在计算、显存带宽、数据搬运、甚至Python GIL。排查工具和思路都要换一套。第三是版本和依赖的复杂度。CUDA、驱动、框架、模型格式之间有一张兼容性矩阵升一个版本可能牵一发动全身。我见过因为驱动版本差一个小号导致某个算子性能掉一半的情况。3. 一线工程师的日常几个真实场景拆解3.1 场景一推理服务延迟毛刺排查线上服务P99延迟时不时冒尖平均延迟却正常这是最让人头疼的一类问题。我处理过一个典型案例现象是每隔几分钟P99跳到2秒以上持续几秒又恢复。排查思路是这样的先看监控时间线发现毛刺和某个定时任务的时间点吻合。那个任务是个日志归档脚本会大量读磁盘。但磁盘IO高为什么会影响到GPU推理继续查发现日志目录和模型文件目录在同一块盘上归档时把模型权重从page cache里挤出去了推理时重新加载权重导致卡顿。解决办法很简单把模型文件放到独立的SSD或者用tmpfs常驻内存。但发现问题的过程花了整整两天因为一开始大家都在盯着GPU看。这个案例的经验是AI服务的延迟问题答案经常不在GPU上。CPU、内存、磁盘、网络任何一个环节都可能成为元凶。排查时要有全局视角先看时间相关性再逐层排除。3.2 场景二多模型混部的显存博弈业务方总希望一个集群里塞尽可能多的模型但显存是硬约束。我们做过一个混部方案把几个中小模型放在同一张卡上用MPSMulti-Process Service做隔离。这里的关键是显存预留策略。如果每个模型都按峰值显存预留浪费严重如果按均值预留高峰期会OOM。我们的做法是给每个模型设一个软上限和一个硬上限软上限触发时开始驱逐低优先级请求硬上限触发时直接拒绝新请求。软硬上限之间留20%的缓冲。参数怎么定我们统计了每个模型过去一周的显存使用分布取P95作为软上限P99.9作为硬上限。这样既保证了绝大多数请求正常又不会因为个别异常请求拖垮整张卡。实测下来混部后单卡承载的模型数从2个提升到5个整体GPU利用率从40%提到65%左右。代价是运维复杂度上升需要一套精细的配额管理和告警机制。3.3 场景三训练任务排队与抢占训练集群和推理集群的管理逻辑完全不同。训练任务动辄跑几小时到几天排队是常态。我们早期用简单的FIFO队列结果小任务被大任务堵死用户体验很差。后来改成多级反馈队列加抢占。高优先级的小任务可以抢占低优先级大任务的资源被抢占的任务做checkpoint后重新排队。这里有个细节checkpoint的频率很关键。太频繁影响训练速度太稀疏被抢占时丢的进度多。我们最后定的是每15分钟或每500个step存一次取两者先到的。抢占策略还要考虑“抢占代价”。有些任务已经跑了很久快结束了这时候抢占它损失很大。我们加了一个“剩余时间预估”的权重剩余时间短的任务降低被抢占概率。这个预估用历史同类任务的平均时长来算虽然粗糙但有效。注意抢占策略一定要有上限不能让某个任务无限被抢占。我们设了最多被抢占3次超过就提升优先级避免饿死。4. 想入门AI-Infra该补哪些课4.1 基础能力清单如果你已经有后端或运维基础下面这些是需要额外补的。我按优先级排一下。第一优先级GPU编程模型和性能分析。不需要会写CUDA kernel但要理解SM、warp、显存层次这些概念会用nsight、nvprof这类工具看瓶颈在哪。这是跟算法同学对话的基础也是做优化的前提。第二优先级容器与编排。Kubernetes是事实标准设备插件、Operator、自定义调度器这些要熟悉。如果公司用的是别的编排系统原理也类似。第三优先级推理框架原理。至少深入用过一种比如TensorRT、vLLM或TGI。理解连续批处理、PagedAttention、量化这些技术解决了什么问题。第四优先级可观测性体系。Prometheus、Grafana、OpenTelemetry这套要会搭会用还要知道AI场景下该采集哪些特殊指标。4.2 学习路径建议我不建议一上来就啃论文效率低且容易劝退。比较务实的路径是先找一个真实的小项目练手比如把某个开源模型部署起来压测然后尝试优化。具体可以这样拿一个7B左右的模型用vLLM部署写个脚本压测记录QPS、延迟、显存占用。然后尝试调参数——改batch size、改max tokens、开量化——观察指标变化。这个过程会让你对推理服务的各种权衡有直观感受。第二步是把这个服务容器化用Kubernetes管理模拟多副本扩缩容。这时候会遇到调度、网络、存储的各种问题一个个解决就是最好的学习。第三步是搭监控把前面采集的指标可视化设置告警。然后故意制造一些故障比如kill进程、占满显存看告警是否准确、恢复是否自动。这三步走完你对AI-Infra的主要环节就有了实操层面的理解比看十篇综述都管用。4.3 常见误区提醒第一个误区是过度追求新技术。这个领域新东西确实多但生产环境讲究稳定。我见过团队为了用某个新框架把稳定的服务重构结果踩了一堆坑又回滚。新技术可以了解但上生产要谨慎。第二个误区是忽视成本核算。GPU很贵一个优化做下去省了10%延迟但多用了20%显存可能整体成本反而上升。做任何优化前先算清楚账。第三个误区是只关注单点性能。单模型推理再快如果调度不合理、扩缩容不及时整体吞吐也上不去。要有系统思维。5. 几个容易被忽略的实操细节5.1 模型加载速度优化模型冷启动慢是常见痛点。一个7B模型从磁盘加载到GPU可能要几十秒扩缩容时这段时间服务能力是缺失的。优化手段有几个。一是用内存文件系统缓存模型权重避免每次从磁盘读。二是做模型预热新实例起来后先跑几个假请求把CUDA上下文、显存池都初始化好。三是用模型分片加载先加载部分层就能开始服务剩下的后台继续加载。我们实测过组合使用这些手段冷启动时间从45秒降到8秒左右。对于需要快速扩缩容的场景这个提升很关键。5.2 批处理策略的取舍批处理是提升吞吐的利器但会牺牲延迟。怎么平衡我们的做法是设一个最大等待时间比如50ms在这个窗口内尽可能攒批窗口一到就发出去。这样延迟有上限吞吐也能提升。动态批处理比静态批处理复杂但效果好很多。静态批处理要求请求长度一致实际场景很难满足。动态批处理可以处理变长请求但要注意padding带来的浪费。现在主流推理框架都支持连续批处理能把不同请求的token拼在一起算浪费更少。提示批处理参数没有万能值要根据业务延迟要求和流量特征调。建议从保守值开始逐步放宽观察P99延迟变化。5.3 故障恢复的自动化AI服务故障原因多人工恢复慢。我们做了一套自动化恢复流程监控发现异常后先尝试重启容器如果重启无效尝试迁移到其他节点如果还不行触发告警让人介入。这里的关键是区分故障类型。有些故障重启能解决比如显存泄漏导致的OOM有些重启没用比如模型文件损坏。自动化流程要能识别这些差异否则会陷入重启循环。我们维护了一个故障特征库记录每种故障的表现和有效处理方式。新故障出现时先人工处理处理完把特征加进去下次就能自动处理。这个库慢慢积累现在能自动处理80%以上的常见故障。6. 关于这个系列后续想聊的内容第一章先搭个框架把AI-Infra的全貌和入门路径讲清楚。后面我计划深入几个专题推理服务的性能调优实战、训练集群的调度策略设计、以及成本优化的具体案例。每个专题都会尽量用真实数据和踩坑经历来说话少讲空泛的理论。如果你也在做类似的事情欢迎交流这个领域变化快一个人闭门造车容易走偏。我个人在实际操作中的体会是AI-Infra没有银弹每个优化都有代价关键是搞清楚当前系统的主要矛盾是什么。是延迟不够好还是成本太高还是稳定性差目标不同手段完全不同。先诊断再开药这个顺序不能反。