如果你只是把大模型当工具用多半不会注意到“算子”这两个字。可一旦你碰过部署跑过推理迟早会被它折腾得睡不着觉同一个开源模型别人能跑到每秒几十个token自己手里却卡成“逐字输出”明明显卡堆了不少显存却总是不够用请求一多整个服务像堵了车。把这些烂摊子收拾干净的人干的不是写模型结构也不是调prompt而是在模型和硬件之间做“翻译”和“包工头”——他们每天打交道最多的东西就是“算子”和“AI Infra”。这篇文章想讲清楚的就是这群人到底在忙什么。我会从单个算子的性能优化说起再一路讲到训练集群、推理服务、资源调度、故障恢复这些被称为AI Infra的领域。如果你是个工程师或者正准备入行做AI基础设施方向这篇文章能帮你建立一条完整的技术认知链路如果你只是好奇大模型背后的工程世界这篇文章也会让你明白为什么“模型效果”和“产品能不能用”之间隔着一整支看不见的队伍。1. 先搞明白一个“算子”是怎么成为性能胜负手的1.1 一个矩阵乘为什么值得反复优化大多数人对“算子”的印象来自深度学习框架里那些张量操作函数——矩阵乘、卷积、归一化、注意力计算它们每一条都是一个算子。在框架里调用一行代码很简单但这行代码真正跑起来时硬件要完成的事远不止“算一下”数据要从内存搬进计算单元计算结果要写回内存不同线程要协调分工还要处理边界问题。一个算子写得好不好性能可以差出一个数量级。举个例子两个大矩阵相乘表面上就是一个三层循环的事情。但放到现代芯片上问题就变成了数据是按什么顺序读取的哪些数据可以留在片上缓存反复用一组线程是各自取数还是协同取数累加顺序不同会不会造成精度差异这些细节决定了一颗芯片的实际算力在这一次运算里能发挥出几成。算子工程师干的就是把数学表达式翻译成硬件指令并且让这个翻译过程尽量不浪费一点资源。生活里有个特别贴切的类比做饭。菜谱告诉你要把食材切好、炒熟、调味。但同样的菜谱有人能在二十分钟出菜并且锅碗用完就洗有人忙一小时还堆了一堆脏锅。算子优化就是研究“切菜顺序”“火力安排”“锅怎么用”这些细节的人。模型的数学原理人人能看但最终能跑多快全看算子这层“厨艺”到不到位。1.2 算子融合是怎么“把三道菜并成一锅”的在大模型里一个简单的计算流程往往被拆成好几步。比如先做一个线性变换再做激活函数再做一个归一化每一步原本都要把中间结果写回到显存里下一步再从显存读出来。这个“写出去再读回来”的动作耗的时间往往比计算本身还多。聪明的做法是把这几步合并成一个算子让中间结果留在片上缓存里不落地。这就是常说的算子融合。举个常见的例子注意力计算里原本要多次读写中间矩阵一旦把整个注意力流程融合成一个大算子每个子步骤的数据都在片上处理完再写回访存开销能降下一个量级。大模型尤其吃这一套因为模型参数动辄几十GB中间结果也都很大减少一次显存往返省下来的时间感动辄成倍提升。算子融合的代价是工程复杂度上升。融合后的算子一般不再依赖框架自动生成而是需要手工写实现手动管理数据块和线程调度。而且不同硬件平台、不同缓存大小最优的分块策略都不一样。这也是为什么懂算子的人越来越值钱他们写的不是应用代码而是决定整个模型在具体硬件上能跑多快的底层代码。如果你刚开始接触这个方向我的建议是先别急着学各种花哨的调优技巧先把“内存带宽”“计算吞吐”“访存比”这几个词搞明白。你能准确解释一次矩阵乘里计算花了多久、读数据花了多久就已经比很多只会调接口的人强了。2. AI Infra到底守的是哪几道关2.1 训练阶段并行切分与通信开销单个算子优化得再好模型训练一上规模问题就会从“单点快不快”变成“一大群设备能不能协同”。训练大模型时显存根本放不下完整模型和梯度必须把参数、数据、计算任务切到很多张卡上。这个切法就是并行策略。最常见的思路有这么几种。数据并行是每张卡都放一份完整模型只把数据切开来喂但每算完一步所有卡要同步一次梯度通信量跟着模型大小走。张量并行是把一个矩阵切成几块分给不同卡一起算适合单层计算量特别大的场景但通信频率很高。流水线并行则是按模型层数切第一层算完传给第二层适合上百层的大模型问题在于容易产生“流水线气泡”总有卡在空等。做AI Infra的工程师很大一部分工作就是在这些策略之间做权衡。模型的参数规模、卡的显存大小、卡间通信带宽这几个数一摆出来就要决定用哪种并行方式、每个维度切多大。通信开销是训练集群里最隐蔽的杀手——单卡计算效率高不代表整体训练速度快因为一旦通信和计算没有重叠卡就得停下来等数据。把通信藏在计算背后是训练性能优化的核心功课之一。我在实操里见过不少团队一上来就猛堆卡结果加速比惨不忍睹。问题往往不在计算量而在于数据搬运和同步开销占了主导。这个阶段最该做的是把训练链路里每个步骤的耗时打点统计出来看卡到底是在算还是在等。2.2 推理阶段吞吐、延迟与显存管理的博弈模型训练完真正的硬仗才刚刚开始。推理服务和训练不一样训练可以慢慢跑推理面对的是实时请求用户点了发送键就不能让人家等太久。而大模型生成文本时每个新token都依赖于已经生成的内容天然是串行的这让“快”变得格外困难。推理系统里有一类东西叫KV缓存。模型每生成一个新token都要使用之前所有token的键值信息。如果每次都从头重算成本无法接受所以要把这些中间结果缓存下来。问题在于KV缓存会随着并发请求数线性增长显存本来就紧张再加上模型权重、运行时开销内存压力非常大。很多推理框架后来借鉴了操作系统的内存分页管理思路缓存不需要一次性全量分配可以按需分页用完的还回去。这套机制让并发能力得到了极大提升。另一个关键设计是动态批处理。传统的批处理是凑够一批再一起算但大模型生成速度有快有慢如果一批里所有请求都要等最慢的生成完吞吐就废了。更好的做法是让请求在生成过程中动态进出一个请求生成完了立刻移出批次让下一个新请求补进来。这样每时每刻GPU都在为那些真正还在生成中的请求干活吞吐量能翻好几倍。推理引擎选型时有没有做类似的连续批处理是核心考察点。2.3 平台化不崩、可观测、能容错再往上一层AI Infra还包括一个特别不性感但极其关键的环节——平台化。所谓平台化就是把模型训练和推理当成一个稳定的线上服务来运营。GPU设备故障率不低显存可能被其他任务占走磁盘可能写满网络可能抖动这些都不能指望着人肉盯着。平台化要做的事包括任务排队与调度避免不同任务互相抢资源检查点与容错训练中途崩了能从最近的位置恢复监控与告警把显存占用、吞吐、延迟、错误率这些指标采集上来异常时自动报警以及自动扩缩容峰值来了多开几个副本低谷了回收资源。说句实话这些工作里的很多部分听起来不如“调算子”那么酷但它们恰恰决定了AI产品能不能长期稳定跑下去。一个能演示一分钟的模型demo和一条能支撑上千人日常使用、持续运行半年不崩的推理链路之间差的正是这套平台化能力。大模型背后的隐形团队相当大一部分人就是在干这件事。3. 一次部署实战从模型文件到稳定服务要过多少关3.1 第一步先别急着优化把目标和资源量化我接过一个内部知识库助手的需求用一个开源大语言模型跑在自有GPU服务器上给公司内部几百人做问答。需求听起来简单但一开始如果不把目标说清楚后面全是扯皮。先量化约束条件。模型本身是百亿参数量级服务器是4张GPU卡单卡显存80GB左右。使用场景是办公问答回答长度一般为两三段文字。产品上的硬性要求是首字返回要在1.5秒以内一次完整回答不超过15秒峰值并发在50个左右。把这些数字写下来之后很多后续决策立刻有了方向。这里我建议大家养成一个习惯把性能指标分为吞吐、延迟、资源占用三类分别记录。吞吐看的是每秒能处理多少个请求、每秒能生成多少个token延迟看的是用户实际等待多久尤其是首token延迟资源占用看显存、算力、带宽这些硬件指标。没有这些基线数据后面做优化就是盲人摸象。3.2 第二步跑基线找到第一个瓶颈目标定完了不要直接优化先把模型原样跑起来测一组基线数据。这一步的意义是弄清楚“默认状况下到底哪里不行”。我当时的做法是先单请求跑一遍记录首字延迟和生成耗时再开并发压测看吞吐和显存变化最后用性能分析工具统计一次完整推理过程中每个算子的耗时占比。实测出来的结果往往和直觉不太一样。我们那个场景里模型本身的单请求速度还算能接受但显存占用非常紧张并发稍微上来一点就快爆了。也就是说真正的瓶颈不在“算得太慢”而在“能装下多少并发请求”。这个判断直接决定了后面的优化方向——优先解决显存效率而不是追求单请求延迟做到极致。这里也分享一个判断技巧当GPU利用率不高但响应很慢时通常不是算力不够而是数据没喂上去瓶颈在内存带宽或者预处理链路当显存占用接近极限时第一优先级是省显存而不是堆算力。弄清楚瓶颈在哪个资源上才能对症下药。3.3 第三步三件收益最大的事拿到基线和瓶颈判断后我们做了三件事每一件都有明确的收益逻辑。第一件事是模型压缩。把模型权重从高精度改成低精度存储显存占用立刻降了接近一半。量化不是简单粗暴地砍精度核心是让量化后的数值分布尽量接近原始分布最好拿一批真实业务数据来做校准让缩放参数贴合实际使用场景。做完这一步单卡能承载的并发请求数大幅提升。第二件事是调整KV缓存策略。之前系统为每个请求预留的缓存空间非常浪费改用按需分配和管理后多个请求可以共用显存不会再出现“一个请求占着一块地别人进不来”的情况。配合动态批处理并发能力又上了一个台阶。第三件事是算子层面的优化。我们把性能分析里耗时最高的几个算子单独拿出来看看有没有冗余的访存动作。有一类归一化和激活函数的组合在原来流程里要多次读写中间结果融合成一个实现后整个前向链路的耗时明显改善。这部分的优化是啃骨头收益可能没有量化那么立竿见影但体现的是实打实的技术深度。整个过程中我们坚持一次只改一个变量改完立刻回跑基线记录前后对比。这样任何一步出了问题都能快速定位是哪次改动引起的。上线前再做一次完整的并发压测和灰度验证确保真实场景下表现稳定。把这一套流程走下来模型才算是真正从“能跑”变成了“能用”。4. 我踩过的五个大坑和排查思路4.1 显存和利用率数字都很健康响应就是慢有一段时间我们看监控数据显存占用不低GPU利用率也不差但用户反馈响应特别慢。这其实是个典型的障眼法GPU利用率高只能说明硬件没闲着不能说明它在干正事。后来细查才发现问题是数据从CPU搬到显存、以及从显存搬回来的环节上带宽早就打满了。一部分时间花在了“把数据搬到计算单元”上真正用来计算的比例非常小。这类问题把batch调大看吞吐有没有跟着涨就能验证——如果涨得很慢甚至不涨基本可以断定是访存瓶颈。解决办法是优化数据布局让数据访问更连续或者用算子融合减少中间结果的搬动。4.2 加卡之后训练反而变慢训练大模型时多上几张卡总计算能力是涨了但如果并行策略没配对通信开销会吃掉所有收益。我见过最夸张的情况从4张卡加到8张卡训练速度不仅没翻倍反而比原来还慢。原因在于梯度同步频率太高每算一小步就要把梯度广播给所有卡网络通信成了瓶颈。排查时先看通信时间占比如果超过一定比例就要考虑调整并行方式或者把通信和计算在时间上重叠起来——让卡在等待数据的时候手里还有别的活能算而不是干等。4.3 量化一开效果肉眼可见地变差低精度量化是最容易上手也最容易翻车的优化手段。有一次量化完模型回答质量明显下降一开始怀疑是精度压缩太狠后来才发现问题出在校准集上。我们当时用的校准数据和真实业务数据分布差异很大导致量化时的数值缩放参数完全跑偏。解决办法很简单换一批贴近真实场景的数据重新校准再保留少数敏感层的高精度。这里提醒一句不是所有层对量化的敏感度都一样有的层动一点就崩有的层压得很狠也不影响结果。挨个层级跑一遍敏感度分析比一股脑全量量化靠谱得多。4.4 并发一高整条服务像“假死”高并发压测通常能逼出各种意想不到的问题。有一次我们测到50个并发时服务响应时间突然从几秒飙到几十秒像是直接扛不住了。表面看是CPU被打满实际原因是请求排队机制设计得不好——大批请求挤在一起互相等待还有一部分请求占着显存资源迟迟不释放。这类问题通常要靠两层优化一层是推理侧开启动态批处理和流式处理别让请求死死占着资源另一层是服务侧加合理的队列和超时机制对耗时过长的请求及时降级或拒绝保护整体服务的稳定性。高并发场景下最重要的指标不是单请求多快而是系统在压力下能不能保持平稳。4.5 升级依赖后结果对不上了还有一个容易忽略的坑换了框架版本或换了硬件平台之后同一个模型跑出来的结果可能会有细微差异。这不是玄学而是浮点数累加顺序不同、某些算子在不同实现里采用了不同算法导致的。有一次我们升级依赖后模型回答开始偶尔出现明显错误。排查了半天代码逻辑完全没变最后确认是新版本框架里某个算子的默认实现路径变了前向计算的数值分布和原来产生了偏差。从那以后我们养成了一个习惯任何依赖升级都要先跑一遍一致性测试用相同的输入对比输出并设一个可以容忍的误差范围。大模型场景里一个微小数值差异可能被逐层放大最终变成完全不同的回答。下面把这几类典型问题整理成一个速查表方便现场排查时对照现象首选怀疑方向快速验证方法常见解法GPU利用率高但响应慢访存带宽瓶颈、数据搬运开销增大batch看吞吐是否同步提升算子融合、数据布局优化增加卡数但训练变慢通信开销占比过高、没有负载均衡统计通信时间和计算时间占比调整并行策略、通信计算重叠量化后效果下降校准集偏差、敏感层被过度压缩对比量化前后每层输出分布换校准数据、敏感层保留高精度并发上来延迟飙升排队机制差、显存分配不合理看平均排队时间和显存占用曲线动态批处理、超时与降级机制升级后结果不一致算子实现变化、数值微小差异固定输入跑一致性测试固定算子实现、设置误差范围5. 给想入行的人别被“框架”吓住先学会拆链路5.1 先跑通一条完整的链路很多想入行AI Infra的年轻人一上来就研究并行策略、手写算子结果被各种底层细节劝退。我的建议相反先别管原理找一个大模型开源项目在自己的机器上跑通一次完整的“加载模型、发起推理、生成回答、开启并发压测”流程。哪怕只是在一张显卡上跑通你也会立刻遇到真实的问题显存不够、速度太慢、进程崩了、压测时服务假死。这些问题的解决过程比读十本理论书都有用。5.2 看懂三类指标和一张时间轴入门AI Infra最容易忽略但又最该掌握的能力是“定位瓶颈”。我建议你养成一个习惯把一次请求拆成时间轴从排队开始到预处理、加载权重、输入编码、前向计算、输出采样、后处理、网络传输每一个环节都打点记录耗时。然后看哪一段占比最大那一小段就是你的第一优化目标。配合这个习惯日常只需要盯住三类指标吞吐、延迟、资源占用。吞吐告诉你系统总体干活的能力延迟告诉你用户体验资源占用告诉你瓶颈在哪儿。很多人被庞大的技术栈吓住其实剥开来看AI Infra的大部分工作都是在“看指标、找拐点、改一两个变量、再测一轮”这个循环里打转。5.3 把故障复盘当成学习素材如果让我给一条最实在的建议那就是多参与故障复盘。大模型系统的故障往往不是单一原因而是一串因素叠加的结果可能是某张卡显存被占可能是某个请求异常占用可能是调度器没有及时回收也可能是监控没有提前告警。每次复盘都像一次全链路教学你能看到系统所有环节是怎么咬合在一起的。而且这类经验完全无法从文档里学到。我自己也是踩过“显存看着还剩很多但任务启动失败”“缓存命中率正常但延迟很高”“通信和计算没有重叠导致加速比接近零”这些坑之后才慢慢建立起对AI Infra的整体直觉。这个行业不需要你从底层原理一路啃到框架源码但需要你手里握着一条完整的链路认知数据从用户请求发出到计算结果返回中间经过了哪些环节每一环的容量上限是多少。你脑子里这条链路越清晰定位问题就越快。我个人实操里最深的一点体会是大模型工程的世界里“算子”和“AI Infra”表面上是两个层次的事实际是一条线上的两端。算子工程师把每一块硬件的潜力榨干AI Infra工程师把成千上万块硬件拧成一股绳中间靠的是同一个能力——分解问题、量化资源、找出瓶颈。写模型结构的人决定了效果上限而算子和基础设施决定了产品能不能走出实验室。如果你也对这个方向感兴趣别被“框架”“并行策略”“底层优化”这些词吓住。下一次跑实验的时候顺手记下显存峰值和单次迭代耗时再试着画一条从请求到响应的完整时间轴——从这两个动作开始你就迈进这个领域了。