GPU Kernel 工程师为何依然抢手：从 SOL 评分看算子优化的价值

一、现象：算力扩张期，最缺的仍是“贴地飞行”的人

在大规模智算集群不断落地的今天，一个看似矛盾的现象长期存在：上层框架、推理服务、调度系统的人才供给相对充裕，而直接与硬件打交道、负责编写 GPU Kernel 的工程师却始终处于紧缺状态。很多人会问：编译器不是越来越聪明了吗？自动化调优工具不是越来越多了吗？为什么还要大量招聘写 Kernel 的人？

要回答这个问题，需要先厘清一个概念：算子优化的目标究竟是什么。答案不是“跑通”，而是“逼近硬件极限”。而衡量“离极限还有多远”的通用标尺，就是 SOL 评分。

二、SOL 评分：给“打满硬件”一个可计算的刻度

2.1 什么是 SOL

SOL 即 Speed of Light，直译为“光速”，在性能工程语境下指代性能上限或天花板。日常讨论中常说的“打满”，指的正是让 kernel 充分压榨硬件的计算单元与存储带宽。对于推理服务而言，模型结构确定之后，算子效率每提升一档，省下来的都是实打实的成本——无论是卡时、能耗还是排队延迟。

2.2 评分公式的物理含义

SOL 评分的核心表达式可以抽象为：

T_SOL = max( Total_FLOPs / Compute_Throughput,
             Total_Fused_Bytes / Memory_Bandwidth )

这两个分式分别回答两个问题：

• Total_FLOPs / Compute_Throughput：如果只考虑算力，这个算子至少需要多长时间；
• Total_Fused_Bytes / Memory_Bandwidth：如果只考虑访存，搬运这些数据至少需要多长时间。

二者取最大值，意味着一个 kernel 的理论下界由“更慢的那条路径”决定。因此，一个优秀的 kernel 必须同时把访存通路和计算单元覆盖到位：既不能让计算单元空转等数据，也不能让带宽闲着等指令。SOL 越接近 1，说明实现越逼近硬件极限；越接近 0，说明还有大量资源在空耗。

2.3 与 MFU 的关系

除了 SOL，另一个常被提及的指标是 MFU（Model FLOPs Utilization），它描述实际计算吞吐相对于理论峰值算力的比例。由于硬件带宽受存储层次（寄存器、共享内存、多级缓存、高带宽显存）与存储类型的限制，MFU 在一定程度上也能间接反映硬件中算力与带宽的配置是否均衡。换言之，MFU 体现的不只是“算子写得好不好”，而是“模型/算子 + 实现 + 硬件”这一整体系统的算力利用结果。

这也解释了一个常见误区：把 MFU 低简单归因于“代码不行”。实际上，如果一个算子的算术强度（Arithmetic Intensity，即每字节访存对应的浮点运算数）天然偏低，那么它注定是访存受限的，此时再强的计算优化也无法把 MFU 推上去。真正专业的做法是先判断算子属于计算受限还是访存受限，再决定优化方向。

三、实践路径：从“能写出来”到“写得接近极限”

3.1 入门阶段的可行方式

过去一段时间，笔者也曾尝试转向算子开发方向，目标是面向大模型时代的高层抽象与领域特定语言。入门阶段的一个有效手段是借助在线评测类平台：给定算子语义与形状约束，提交实现并获取性能反馈。这类平台的价值在于提供了闭环——写、测、比、改。

在实践中可以发现，借助提示词工程与参数调优，确实能够生成“还不错”的 kernel。典型流程包括：

1. 明确算子语义与边界条件（数据类型、布局、形状、是否融合）；
2. 选择切分策略：沿哪个维度分块、块大小如何与共享内存容量匹配；
3. 设计访存路径：合并访存、向量化加载、避免 bank 冲突；
4. 处理边界：尾块、非对齐长度、掩码；
5. 迭代调优：调整 tile 尺寸、展开因子、流水线深度。

一个简化的分块示例（示意，非特定框架语法）：

// 伪代码：分块矩阵乘的骨架
for tile_m in range(0, M, BM):
    for tile_n in range(0, N, BN):
        acc = zeros(BM, BN)
        for k in range(0, K, BK):
            a_tile = load_shared(A[tile_m:tile_m+BM, k:k+BK])
            b_tile = load_shared(B[k:k+BK, tile_n:tile_n+BN])
            acc += dot(a_tile, b_tile)
        store(C[tile_m:tile_m+BM, tile_n:tile_n+BN], acc)

这段骨架本身并不复杂，难点在于 BM/BN/BK 的选取、共享内存的复用、双缓冲与流水、寄存器压力之间的取舍。这些决策没有放之四海皆准的答案，必须结合具体硬件参数与具体形状分布反复试探。

3.2 自动化评测基准带来的冲击

近期出现的面向真实 GPU Kernel 的“光速基准”类工作，把评测目标直接对齐硬件极限。初步看，很容易把它理解为一个“收集提交、排名打榜”的评测集合，于是有人（包括笔者）第一反应是：直接用自动化代理去生成算子并提交即可。

但认真读完其设计思路后，会开始重新审视这类工作的价值定位。它真正想做的，不是比谁快，而是建立一个“相对硬件上限”的归一化评价体系：

• 用 SOL 分数把不同算子、不同形状、不同硬件的性能统一到同一刻度；
• 用真实负载中的形状分布替代人造 benchmark，避免“只对某个尺寸调优”的过拟合；
• 把访存与计算两条下界同时纳入，迫使实现者在两个维度上都给出交代。

这带来的直接后果是：单纯依靠自动化代理“试出”一个还行的实现，很容易在分布外的形状上崩掉。因为代理擅长的是在给定反馈下做局部搜索，而算子优化的许多关键决策（例如是否融合、是否改变数据布局、是否引入额外的规约步骤）需要跨层的结构性判断。

四、自动化能替代什么，不能替代什么

4.1 自动化已经做得不错的部分

• 样板代码生成：索引计算、边界判断、向量化加载的模板化展开；
• 参数搜索：在给定搜索空间内做 tile 尺寸、展开因子的自动调优；
• 快速验证：生成候选实现并跑正确性对拍与性能采样；
• 变体枚举：针对不同形状区间生成多套候选，再做离线选择。

4.2 仍然依赖人的部分

• 问题重构：判断一个算子是否应该融合、是否应该拆分、是否应该换一种数学等价形式，这类决策改变的是搜索空间本身，而不是空间内的一个点；
• 瓶颈归因：性能不达预期时，区分是带宽受限、指令吞吐受限、延迟受限还是占用率不足，需要读性能计数器、构造对照实验；
• 硬件特性运用：不同架构的存储层次、矩阵指令、异步拷贝机制差异很大，能否用对、用稳，依赖经验；
• 分布外鲁棒性：真实业务的形状长尾极长，如何设计分档策略与回退路径，是工程判断而非搜索问题。

这也是为什么“自动化越强，Kernel 工程师越少”的推论并不成立。自动化降低的是重复劳动的门槛，抬高的是“判断力”的溢价。当生成候选的成本趋近于零，真正稀缺的是“知道该往哪个方向生成”和“判断结果为什么不够好”的人。

五、给不同角色的建议

5.1 对算子开发工程师

• 把 SOL 与 MFU 作为日常语言：提交优化前后，不只报“快了多少”，而是报“离下界还差多少”；
• 建立形状分布意识：优化目标应是加权后的整体收益，而非单点峰值；
• 学会做对照实验：固定一个变量，逐项排除瓶颈，形成可复用的归因方法论；
• 重视正确性与数值稳定性：融合与重排会改变累加顺序，浮点误差与溢出边界必须验证。

5.2 对团队与招聘方

• 招聘时区分“会写 kernel”与“会调 kernel”：前者是编码能力，后者是系统判断力，后者更稀缺；
• 建设内部基准：用真实业务形状构建回归集，避免优化成果在版本迭代中悄悄退化；
• 给优化工作设定明确口径：以 SOL 分数或单位成本吞吐作为验收指标，而非模糊的“感觉快了”。

六、结语

GPU Kernel 工程师的持续紧缺，本质上是“逼近硬件极限”这件事无法被完全自动化。SOL 评分给出了一个清晰的刻度：它把“打满”从口号变成了可计算的目标，也让每一次优化都能被量化评估。自动化评测与代理生成会持续压缩重复劳动的空间，但问题重构、瓶颈归因、分布外鲁棒性这些依赖判断力的环节，仍然需要人来完成。理解了这一点，也就理解了为什么在算力规模不断扩张的今天，最贴近硬件的那一层，反而最需要人。