自回归解码的每一毫秒里，H100 的大部分显存带宽其实都在空转。Cohere 刚开源的 megakernel serving 引擎给了一组扎眼的数字：vLLM 服务 North Mini Code（30B 参数、每 token 激活 3.3B）时，解码吞吐只有 185 tok/s，占 H100 内存带宽理论极限（Speed-of-Light，约 470 tok/s）的 39%；换成他们的 megakernel，同一张卡跑到 292 tok/s、62%——批大小 1 下解码比 vLLM 快 1.58 倍。

解码是带宽游戏，不是算力游戏

BF16 下，这个模型每个解码步要流过 6.6 GB 权重，8K 上下文再加约 0.5 GB KV cache，而 H100 的 HBM 带宽是 3.35 TB/s。传统 serving 栈把一次前向拆成上百个小 kernel 逐个发射：kernel 边界要等最慢的 SM 收齐、wave 量化浪费整波算力、算子间的伪依赖让权重流断断续续。Cohere 统计，这些停摆让典型推理引擎浪费了约 61% 的带宽。

一个 persistent kernel 跑完整个解码步

megakernel 的做法是把整个前向压进单个持久 kernel：每个 SM 一个常驻线程块，从全局内存的任务列表领活，同步粒度从「整个 GPU」缩到「我真正依赖的生产者」。收益大头有三块：消 wave 量化（200 个 tile 摊到 132 个 SM，不再被迫凑整波）、拆伪依赖（O-proj 不必等全部 attention 组收齐）、权重预取（权重与激活无关，上一层 O-proj 收尾时就开始流 router/QKV 的权重）。North Mini Code 的并行 transformer 层——attention 与 MoE 吃同一份归一化输入、出口处用融合 residual+RMSNorm 汇合——让空闲 SM 能被确定性回填。整套引擎是单个 CUDA 文件，16 个 opcode 覆盖完整解码图，没有编译器，没有新编程范式。

从 demo 到完整 serving 系统

以往 megakernel 工作多是 batch 1 的独立演示；Cohere 自称这是第一个围绕 decode megakernel 搭建的完整 serving 系统：连续批处理、paged attention、ragged 序列长度、带 tool calling 的 OpenAI 兼容端点，接上 OpenCode 就能写码。端到端比 vLLM v0.24 快 1.25–1.41 倍，加速保持到 256K 上下文，无可测精度损失。

冷水与看点

定位是 research release：单张 H100（sm_90a）、批大小上限 8、要求 CUDA 13+。思路源头是 Hazy Research 的 "Look Ma, No Bubbles!"（把 Llama-3.2-1B 前向融成单 kernel，吃到 78% 带宽）。真正值得记的有两条：其一，Cohere 称 megakernel「远比名声好写」，靠统一 ABI（3 个 warp group、32 个 int32 的任务描述符）把工程难度压了下来；其二，模型结构在给系统留口子——并行层设计正是激进回填的前提。当模型侧加速卷到边际收益递减，推理竞赛的下一程，可能落在 kernel 调度与模型-系统协同设计上。

参考：https://cohere.com/blog/megakernels ；代码 https://github.com/cohere-ai/cohere-megakernel