从 DSL 到性能：FlagKernel 对比 FlashInfer

先看结果：八种规模均领先

2026 年 9 月 1 日的 P0be 记录中，FlagKernel 的通用映射实现在八种 attention 规模上均快于固定版本的 FlashInfer FA3。延迟比的几何平均为 0.896738，即延迟几何平均降低 10.33%，约为 1.115× 加速。

这组结果来自公开 DSL 算子源码，并由编译器的正式映射选择规则接受，无诊断强制开关。它展示了 DSL 表达经过编译器推导后，能够得到有竞争力的 GPU 算子。

在相同问题上读数字

测试条件为 H20，dense attention，B=1、H=1、D=64、FP16、non-causal，softmax scale=0.125。Q∈{128,256}，KV∈{1024,4096,16384,32768}。每个规模在一张独立 H20 上完成 mapped、unmapped 与 FlashInfer 的同卡对比，总计八张卡。

这里是八种规模的覆盖测试，每种规模只有一张卡的观察，不是每种规模都重复八张卡。最大进程内 CV 为 0.9623%。每项都通过独立 full-softmax 正确性检查，以及最终代码的零 STACK/LOCAL 检查。

为什么它是编译器成果

同一份算子源码还生成了未应用该映射的对照实现。映射版本相对该对照的延迟几何平均降低 8.82%。这项对照比仅比较两个算子库更接近问题本身：编译器选择的映射是否带来了收益？

正式选择规则根据解析后的循环 trip count 推导时间维度剩余量、空位惩罚与收益；报告中 KV 增长对应 trip count 31、127、511、1023。选择器不依据 benchmark 行号或 Q/KV 白名单决定是否启用。

Layout 和 DomainMap 提供可理解的关系，编译器结合这些关系与资源、调度条件构造实现。当前证据支持映射选择有效；它不能把整个收益归因于 Layout 一个组件，因为流水线、存储与硬件指令也参与了最终结果。

Batch / GQA：另一个有代表性的结果

2026 年 8 月 31 日的 P0z 记录测试 B2/Q96/KV65/QH8/KVH2/D64/FP16/non-causal，scale=0.125。该场景同时包含 batch、4:1 GQA 头关系，以及 query 和 key 尾块。

八张 H20 各自完成一组配对测试，同卡延迟比的中位数为 0.564988，即约 43.5% 延迟降低，约 1.77× 加速。两侧各捕获 1000 次调用，预热 CUDA Graph 五次，取七次 CUDA-event 样本；编译、分配、capture 和 warmup 不计入。

编译后的调度使用四个 stage、256 线程和 49,152 字节动态共享内存，并应用 warpgroup overlap 与跨迭代 PV 窗口。用户 workload 无需写出 grid、线程数、尾块谓词或 overlap 坐标。这让“从计算关系推导执行细节”有了具体的结果。

如何理解这些成绩

这两组结果分别回答“是否覆盖多种规模”与“一个复杂关系是否能跨八卡重复”。它们具有不同测试设计，不能混算成一个总加速比。FlashInfer 固定为 091dd7d9ca228b23f36b3f6f0943be62d38a3c05，比较目标为显式 FA3 路径。

P0be 也记录了取舍：历史专用 stage-4 方案在相同八种逻辑规模上的归一化延迟比为 0.658169，比通用映射更低；两个历史编译版本不同，这不是同一二进制的消融实验。它提出了下一步明确的问题：如何在保留通用合法性与收益判断的同时，恢复专用物理调度的优势。