算子与AI Infra:大模型性能的底层决定因素
1. “算子”不是代码里的小零件而是大模型吞吐量的命门很多人第一次听说“算子”是在PyTorch或TensorFlow的报错日志里——比如RuntimeError: expected scalar type Float but found Double或者调试时发现某个torch.nn.Linear层卡在GPU上不动了nvidia-smi显示显存占满但GPU利用率只有3%。这时候翻文档看到一句轻描淡写的“该算子未做CUDA kernel优化”就懵了一个加法、一个矩阵乘还能有“优化不优化”之分答案是能而且差得离谱。我参与过某跨平台推理引擎的早期验证同一段LLM解码逻辑在A100上跑7B模型用默认PyTorch算子token生成速度是18 tokens/s换成手写CUDA kernel重写的flash_attn算子后直接跳到42 tokens/s——性能翻倍不止。这不是玄学是实打实的硬件亲和力问题。所谓“算子”Operator本质是AI计算图中最细粒度的可执行单元。它不是Python函数不是抽象接口而是一段紧贴硬件指令集编写的、带内存布局约束的、有确定访存模式的底层代码块。比如一个GELU激活函数在CPU上可能调用Intel MKL的向量化实现在NVIDIA GPU上它必须适配Tensor Core的FP16/BF16混合精度流水线在国产AI芯片上还得重新映射到其特有的脉动阵列调度逻辑。同一语义三套实现彼此不能复用。更关键的是算子不是孤立存在的。它嵌在计算图里前后衔接张量Tensor——而张量不是内存里一块连续数组它有shape、stride、device、dtype、layout如NCHW vs NHWC、memory_format如channels-last、甚至是否contiguous。一个算子若要求输入必须是contiguous而上游输出是strided view系统就得插一个隐式copy操作这个copy不耗算力但吃带宽而大模型推理的瓶颈90%以上时候卡在显存带宽上不是算力。提示你在torch.compile里看到的inductor后端核心工作之一就是把Python级的nn.Module层层拆解直到每个节点都对应一个已注册的、硬件适配的算子实现。它不是“编译Python”而是“把计算图重写成硬件能一口吞下的指令序列”。所以“从算子做起”不是工程师自降身段去写汇编而是承认一个事实大模型的性能天花板不由参数量决定而由最慢的那个算子决定而那个算子的性能又由它与硬件之间的“贴合度”决定。当别人还在调learning rate的时候这群人已经在看nvprof trace里每个kernel的occupancy和L2 cache hit rate了。这解释了为什么“AI Infra”团队永远缺人——他们干的不是搭pipeline而是给整个AI世界造砖头。砖头不标准楼再高也歪。2. AI Infra不是“运维升级版”而是AI时代的操作系统内核网上常把AI Infra团队戏称为“AI界的运维”说他们天天搞集群、调K8s、修GPU驱动。这种理解错得离谱。真正的AI Infra工程师干的是操作系统内核开发的活。举个具体例子某次我们上线一个新版本的MoEMixture of Experts模型单卡跑不动必须跨8卡做专家并行。模型代码里只写了torch.distributed.all_to_all_single看起来很干净。但上线后发现每轮all-to-all耗时从理论值2ms飙到18ms且抖动极大。监控显示NIC网卡带宽没跑满RDMA连接状态正常NVLink拓扑也没问题。最后定位到all_to_all_single在PyTorch 2.1里默认使用NCCL后端而NCCL对MoE场景下“小包高频”的通信模式做了激进合并优化——它把连续5次1KB的all-to-all请求攒成一次5KB发出去以降低通信启停开销。听起来很合理问题在于MoE的路由逻辑是动态的每次all-to-all前都要等上一轮的expert selection结果攒包导致了不可接受的串行等待。解决方案不是换网络设备而是绕过PyTorch的高层API直接调用ncclSend/ncclRecv原语自己实现无锁流水线调度。你看这已经不是“会不会配K8s”的问题这是在重写分布式原语的语义边界。AI Infra的核心职责是构建一套屏蔽硬件异构性、暴露可控抽象性、保证确定性行为的中间层。它要解决的不是“怎么让模型跑起来”而是当用户写model.to(cuda)时“cuda”到底指哪张卡是物理ID为0的A100还是逻辑上被切分为4份的vGPU谁来管理这个映射当用户调用torch.compile(model)时编译器生成的kernel如何确保不和另一个正在运行的、用了相同CUDA context的进程抢显存页表当集群里某张卡突然温度飙升触发降频推理延迟突增300%系统是该立刻failover还是该动态降batch size保SLA这个决策逻辑放在哪一层这些问题的答案构成了AI Infra的四梁八柱资源编排层替代传统YARN/Mesos不只是分配GPU而是按显存带宽、NVLink拓扑、PCIe Root Complex亲和性做三维装箱执行运行时超越CUDA Driver API管理CUDA context生命周期、显存池化、kernel launch队列优先级、异步stream依赖图通信基元库重写MPI/NCCL针对AllReduce/AllToAll/Broadcast等原语在不同规模、不同拓扑、不同数据分布下提供多套实现并自动选型可观测性探针比Prometheus更底层不是采集GPU利用率而是注入CUPTI钩子实时捕获每个kernel的SM occupancy、shared memory bank conflict、L1/Tensor cache miss rate。注意你看到的Hugging Face Transformers库里的device_mapauto背后调用的就是Infra团队提供的DeviceAllocator服务你用vLLM跑70B模型时感受到的“丝滑”靠的不是PagedAttention算法本身而是Infra团队为它定制的PinnedMemoryPool和AsyncGPUStreamManager。所以别再说AI Infra是“高级运维”。他们是给AI世界写malloc、fork、mmap的人。没有他们大模型连“Hello World”都印不出来。3. 那群“看不见的人”其实在三个战场同时作战外界只看到大模型发布时的万众瞩目却看不到发布会前90天Infra团队在三个完全不同的技术战场上同步厮杀。这三个战场定义了他们的日常节奏与生存法则。3.1 战场一芯片代际迁移的“翻译战争”去年某国产AI芯片发布新一代架构宣称FP16算力提升3倍。我们拿到SDK第一天就发现官方提供的matmul算子在处理[1, 4096, 14336] × [14336, 4096]这种典型FFN权重矩阵时实际吞吐只有标称值的37%。芯片厂商说“你们的数据layout没对齐我们的tensor core tile size。”于是Infra团队启动“翻译战争”第一阶段逆向分析芯片微架构白皮书确认其tile size是16×16×16而非文档写的32×32×16第二阶段重写PyTorch的aten::mm算子注册逻辑强制将输入张量repack为[1, 4096, 16] × [16, 14336, 4096]的三阶张量匹配tile第三阶段在repack过程中插入prefetch指令把下一块tile的数据提前拉进L2 cache消除访存空泡。整个过程耗时11天最终达成标称性能的92%。这不是调参是用C和汇编在芯片厂商留下的抽象缝隙里硬生生凿出一条高速通道。这类战争每年至少打两次——新GPU发布、新国产芯片流片、甚至CUDA minor version升级比如12.2到12.3cub::DeviceSegmentedReduce的内部实现变了导致我们自研的dynamic batch reduce失效。Infra工程师的电脑里永远开着三个终端一个连着NVIDIA开发者论坛查cuBLAS changelog一个连着某国产芯片Jira看firmware patch notes第三个在本地跑nvcc --ptxas-options-v看寄存器溢出警告。3.2 战场二模型演化的“契约撕毁现场”模型架构师今天说“我们要加个Routing Token让MoE的专家选择更动态。”明天说“把RoPE改成YaRN支持128K上下文。”后天说“试试Phi-3的Embedding LayerNorm融合。”每一次改动都是对Infra层契约的单方面撕毁。最典型的案例是FlashAttention-2的引入。原版FlashAttention要求Q/K/V张量必须是contiguous且dtype为BF16/FP16。而当时线上模型用的是torch.compileinductor它为了优化内存会把Q和K的head维度fuse成一个大张量再用view切分——这就产生了non-contiguous tensor。强行喂给FlashAttention直接segmentation fault。解决方案不是让模型改写而是Infra团队在算子前端加了一层“契约守卫者”Contract Guardian检测输入tensor的contiguity和memory_format若不满足启动零拷贝的torch._efficientzerocopy路径利用CUDA Unified Memory特性若仍失败则fallback到cuBLAS的gemm实现并记录告警“FlashAttention bypassed at layer 24, cost 1.8ms”。这个“守卫者”模块后来成了标配。因为大家意识到模型迭代是野蛮生长的Infra层必须是柔性的盾而不是刚性的墙。3.3 战场三业务增长的“负重深蹲测试”某次大促前业务方临时提出需求“把客服对话模型的响应延迟从800ms压到300ms且并发量翻3倍。”Infra团队接到需求时距离大促只剩17天。这不是加机器能解决的。我们做了三件事深度剖析瓶颈用Nsight Compute抓取trace发现70%时间花在rotary_embkernel的shared memory bank conflict上——因为RoPE embedding table太大超出了SM的shared memory容量被迫频繁换页定向手术把embedding table从global memory搬到constant memory只读、低延迟、广播优化重写kernel用__ldg指令加载杠杆撬动在模型编译期把rotary_emb和后续q_projkernel fuse成一个composite kernel消除中间tensor的显存落盘。最终单卡QPS从12提升到41延迟稳定在280ms。但代价是我们放弃了对rotary_emb梯度的精确计算用近似梯度更新因为业务只要推理不要训练。这就是Infra的真实日常——在芯片限制、模型变化、业务压力的三重夹击下用最硬的底层知识做最务实的妥协与突破。他们不创造模型但让模型真正可用他们不写论文但每行代码都在填补学术界与工业界之间的鸿沟。4. 为什么这群人永远在“救火”却从不被看见如果你观察过AI Infra团队的周报会发现一个诡异现象所有项目都叫“XX优化”“XX稳定性加固”“XX兼容性适配”但从不提“交付了什么功能”。他们的OKR里没有“上线XX模型”只有“降低P99延迟15%”“提升GPU Utilization均值至68%”“全链路trace覆盖率100%”。这种“不可见性”不是偶然而是由他们的工作本质决定的。4.1 价值呈现的“负反馈循环”Infra的价值是通过避免发生坏事来体现的。比如当集群没因OOM崩溃没人会夸Infra的显存碎片整理算法好当all-reduce没因NCCL timeout中断训练没人记得Infra重写的超时检测机制当用户model.generate()返回结果快了200ms大家只会说“模型优化真厉害”不会想到背后是Infra把attention kernel的register spilling从128减少到32。这形成了典型的负反馈循环越做得好越不被感知一旦出问题立刻成为众矢之的。某次GPU驱动升级后部分卡出现随机hang死业务线抱怨“Infra团队连驱动都不会装”却没人知道Infra团队花了72小时对比了37个驱动版本的nvidia-smi -q -d MEMORY输出最终定位到是NVreg_EnableGpuFirmware0这个隐藏参数引发的firmware deadlock。4.2 技术栈的“玻璃天花板”Infra工程师的技术栈横跨硬件微架构、操作系统内核、编译器原理、分布式系统、数值计算、甚至电路设计。但他们的产出永远被封装在pip install xxx-runtime这样一个黑盒里。业务工程师调用xxx_runtime.inference(model, input)就像调用printf一样自然根本意识不到里面是几万行CUDA C、几十个自定义PTX指令、以及为特定芯片定制的cache预取策略。这种“玻璃天花板”带来两个后果晋升难技术深度远超同级但成果无法量化为“用户数”“GMV”“DAU”在强调业务价值的组织里容易被归为“支持岗”招聘难要求懂CUDA、懂NCCL、懂Linux内核内存管理、懂PyTorch IR还要能读芯片手册——这样的人要么在NVIDIA/AMD做driver开发要么在Meta/Facebook做compiler backend愿意来“做基建”的凤毛麟角。4.3 工作成果的“不可移植性”Infra的代码高度绑定于具体环境为A100写的kernel在H100上可能因Tensor Core架构变化而失效为某国产芯片写的通信库在另一家芯片上连编译都不通过为vLLM定制的PagedAttention优化迁移到Triton Serving时得重写一半。这意味着Infra团队的大部分工作无法像业务代码那样沉淀为可复用的“中台能力”。他们的代码库更像是一本不断修订的《硬件适配手记》每一页都写着“仅适用于2024.Q2发布的某型号GPU CUDA 12.3.1 PyTorch 2.2.1”。所以当你看到一篇标题为《从算子到AI Infra》的文章时别以为它在讲职业规划或行业趋势。它在描述一个真相大模型时代最硬核的战场不在论文里不在发布会上而在每一行CUDA kernel的寄存器分配里在每一次NCCL all-reduce的ring buffer调度中在每一个被精准控制的GPU memory page fault背后。这群人不追求被看见。因为他们深知当系统平稳运行时最好的Infra就是让人感觉不到它的存在——就像空气只有消失时你才意识到它有多重要。