为什么AI Infra仍在大量招聘GPU算子工程师？

一、招聘热度背后的疑问

过去两年，大模型训练与推理的成本控制压力，让AI Infra团队对GPU算子工程师的需求持续走高。一个常见的疑问随之而来：如今智能编程工具已经能生成质量不错的Kernel，行业也在推进DSL与编译器的自动化，为什么各大团队还在大量招聘专职算子工程师？

笔者近一年从应用开发转向算子方向做了一些实践：先通过在线判题式的算子练习平台完成入门，随后尝试用智能体自动生成并提交Kernel；再研读了近期一项面向真实场景GPU Kernel的性能基准研究。这些经历让我对“算子工程师的价值”有了更具体的判断。本文从SOL指标讲起，结合实例与Agent实践，说明为什么这个岗位短期内不会消失，反而愈发关键。

二、SOL：给Kernel性能标定“光速”

2.1 什么是SOL

SOL（Speed of Light，光速）在算子开发语境中指硬件的理论性能上限，也就是常说的“打满”。推理框架宣传中的“打满带宽”“打满算力”，其量化依据正是SOL。它的计算公式为：

T_SOL = max(总浮点运算量 ÷ 峰值计算吞吐， 总访存字节数 ÷ 峰值显存带宽)

直观理解：一个算子再快，也快不过两件事——

• 总计算量除以峰值算力，得到“至少要算多久”；
• 总访存量除以峰值带宽，得到“至少要搬多久”。

真实耗时不可能低于两者中的较大值，这个较大值就是SOL时间。实际耗时与SOL时间的比值越接近1，说明Kernel越逼近硬件极限。

2.2 两类瓶颈，两条优化主线

公式中的max结构揭示了优化的两条主线：

• 计算受限（compute-bound）：瓶颈在计算单元，典型如大矩阵乘法。优化方向是提高矩阵计算单元的占用率、掩盖数据供给延迟，例如合理分块、软件流水、双缓冲。
• 访存受限（memory-bound）：瓶颈在带宽，典型如逐元素操作、规约，以及小batch推理中的多数环节。优化方向是减少冗余读写、提高访存合并度、利用片上高速存储复用数据。

许多优化手段的本质，是把问题从访存受限推向计算受限，或者干脆同时降低两边的工作量。算子融合（fusion）就是代表：把相邻算子合并进同一个Kernel，中间结果留在片上，既省一次显存往返，也省一次Kernel启动开销。

2.3 MFU：系统视角的补充

除SOL外，业界还常用MFU（Model FLOPs Utilization）衡量算力利用率，即实际计算吞吐与理论峰值算力之比。MFU反映“模型/算子 + 实现 + 硬件”这一整体系统的利用结果：如果某类硬件上MFU普遍偏低，可能是算子实现不够好，也可能是算力与带宽配比失衡、模型结构对硬件不友好。两个指标结合使用，才能定位性能损失到底出在哪一层。

三、实例：注意力输出投影 + 残差融合

基准研究中的一个典型题目很适合作为案例：对注意力输出执行o_proj线性投影，并与残差相加。用主流框架的接口风格示意，基线实现大致如下：

def run(attn_output, residual, weight):
    # 形状约定（fp16）：
    #   attn_output: (16, 512, 2560)
    #   residual:    (16, 512, 2560)
    #   weight:      (2560, 2560)
    projected = matmul(attn_output, weight.transpose())  # o_proj 线性投影
    output = projected + residual                        # 残差相加
    return output

先做定量估算：

• 计算量：2 × 16 × 512 × 2560 × 2560 ≈ 107 GFLOPs（矩阵乘按一次乘一次加计）；
• 访存量：attn_output、residual、output三个张量各约40 MB，权重矩阵约13 MB，合计约140 MB。

该算子的算术强度（FLOPs/Bytes）远高于常见GPU的平衡点，属于典型的计算受限场景。而基线实现把matmul和逐元素加法拆成两个Kernel，带来三重浪费：残差加法单独一次显存读写往返；中间结果projected额外一次写出与一次读入；多一次Kernel启动延迟。

优化思路因此非常明确：写一个融合Kernel，在矩阵乘的结果分块算出后立即与残差相加并写回，残差只需读一次，中间张量完全不落显存。理论上可以把残差加法的额外开销基本清零，让整体耗时逼近矩阵乘本身的SOL时间。

这个例子也说明：知道“该融合”并不难，难的是在具体硬件上把融合后的Kernel写到位——分块大小如何适配片上存储、如何让矩阵计算单元持续有活干、如何避免片上共享存储的bank冲突、尾块如何处理、不同shape下如何泛化……每一步都是经验与硬件知识的比拼。

四、我的尝试：从入门到Agent自动写Kernel

4.1 在线判题平台入门

去年出现了在线判题式的算子练习平台，题库覆盖常见真实算子，提交后在真实GPU上运行并给出评分。笔者借此完成了算子开发的入门：从向量加法、规约，到softmax、GEMM优化。这一阶段的体会是——依靠对提示词的反复修改与调优，智能编程工具确实能生成“还不错”的Kernel，很多时候一次就能通过功能校验，性能也能达到参考实现的相当比例。

4.2 用Agent冲击基准

近期某GPU厂商公开了一项面向真实场景Kernel的性能基准，题目取自真实推理负载中的算子，以SOL比值作为统一评分。笔者起初以为它只是“官方版刷题平台”，便直接用Agent批量生成算子并提交，成绩尚可。

但认真读完配套论文后，我开始重新审视自己工作的价值。结合自己在榜单上的观察与论文的方法论设计，可以提炼出几点判断：

• 当前通用代码生成智能体在简单题目上表现尚可，但在逼近硬件极限的区间内，每提升一个百分点的性能，所需投入呈指数级增长；
• 简单的“生成—运行—报错—重试”循环对性能优化帮助有限，因为性能反馈信号远比编译错误稀疏；
• 接近SOL的提交始终寥寥，专家级优化依赖对硬件特性的长期积累，这恰恰说明瓶颈不在“写代码”，而在“懂硬件”。

换句话说：Agent已经解决了“从0到0.6”的问题，而算子工程师的价值区间在“从0.6到0.95”。这段路没有捷径。

五、为什么算子工程师依然不可替代

第一，成本优化的最后一段路只能靠人（或人机协同）走完。模型结构确定后，训练与推理成本的正比项就是硬件利用率。SOL从0.7提到0.9，等价于同样的卡多服务近三成流量，省下的都是真金白银。这最后一小段往往涉及精度重排、指令级优化、非规则shape处理，正是自动化工具最薄弱的环节。

第二，长尾算子持续产生。新模型结构（长上下文、稀疏专家、多模态）不断带来新的算子形态，通用框架与高性能库的覆盖永远滞后。判断哪些算子值得手写、哪些交给编译器生成、哪些直接复用现成库，本身就需要专家经验。

第三，DSL与编译基础设施需要懂Kernel的人来建。行业正从“手写Kernel”走向“DSL描述 + 编译器生成 + 专家兜底”，但DSL的设计、调度原语的抽象、自动调优搜索空间的定义，全部依赖深厚的算子工程经验。岗位没有消失，而是上移了。

第四，性能诊断能力稀缺。线上推理变慢，可能出在Kernel、调度、通信、显存管理的任何一层。能把一个SOL比值拆解成“哪一段访存不合并、哪一段流水被打断”的人，在团队里天然是关键角色。

六、给想转型者的建议

1. 先补硬件常识：存储层次、SIMT执行模型、矩阵计算单元的工作方式，比背API重要得多；
2. 用判题平台练手感：从memory-bound的小算子入手，逐步挑战GEMM与融合算子，始终以SOL比值为目标；
3. 把智能工具当队友而非替代：让Agent负责脚手架与正确性迭代，自己聚焦瓶颈分析与极限调优；
4. 精读一流实现：高性能算子库的源码是最好的教材，重点看分块策略与流水设计，而非语法细节。

七、结语

智能体确实在快速降低算子开发的入门门槛，但“打满硬件”这件事的天花板，依然由对硬件的理解深度决定。AI Infra大量招聘GPU算子工程师，招的不是“会写Kernel的人”，而是“能榨干硬件、并能定义下一代自动化基础设施的人”。理解了SOL，也就理解了这个岗位的真实价值。