自回归解码（decode）在中小批量（batch size 小）时，几乎是被显存带宽，而非算力卡住的。每生成一个 token，GPU 要从 HBM 搬一大块权重出来，真正做的算术却很少。问题在于：传统框架把一次前向拆成几十个小 kernel 依次发射，kernel 与 kernel 之间要全网格同步——GPU 大量时间在「等」。
底层机制通俗拆解
Cohere 8 月开源的 megakernel serving engine（cohere-megakernel，Apache 2.0）针对自家的 North Mini Code 模型，把整个 decode 前向跑成「单个常驻 CUDA kernel」。具体做法：每个 SM（约 100–150 个独立处理器）常驻一个 threadblock，整个 decode 步不再交还驱动；threadblock 从全局内存读一份 host 预排的任务列表，任务间的依赖用全局内存里的计数器表达——某任务输入就绪就开始，而不是等全网格最慢的那个。调度从「按 kernel 边界」变成「按任务就绪」。
本次核心优化点
收益体现在三处：消除 kernel 边界的 wave quantization（哪个 SM 闲了就接活）、消除 false dependency（某 KV 组的 O-proj 不必等所有 head 跑完注意力）、以及权重预取（权重不可变，可在激活依赖解析前就流式搬进共享内存）。实测在单张 H100、BF16 下，batch size 1 达 292 tok/s，约为理论带宽上限（SoL）的 62%，比 vLLM 的 185 tok/s 快 1.58×；端到端在 AIME 2025、GPQA 等基准上比 vLLM v0.24 快 1.25×–1.41×，且到 256K 上下文无精度损失。它仍是完整 server：OpenAI 兼容接口、流式、工具调用、连续批处理、分页 KV、滑动窗口、前缀缓存、抢占都在。
技术取舍与固有局限
代价是通用性：目前仅验证于单张 H100、BF16、batch ≤ 8、纯 decode、且仅 North Mini Code 一款模型。megakernel 是手写单一 CUDA 文件（普通 tiled GEMM + paged attention，无编译器、无新编程模型），可移植性尚未跨模型、跨硬件验证。换句话说，这是一次「为特定模型把单卡吞吐榨到极致」的研究性发布，而非通用推理引擎。
同类方案对比
方向上有两条老路：一是编译器自动生成 megakernel，二是 batch size 1 的 standalone demo。Cohere 的增量在于把 megakernel 做成可运行 server 的「生产级」实现。更早的源头是 Hazy Research 的「Look Ma, No Bubbles!」。vLLM 仍是通用首选，单卡峰值之外的多模型、多租户场景它更稳。
开发者落地适配建议与踩坑提醒
对跑 coding agent、长上下文推理且单模型、单卡 H100 的工作负载，这套 megakernel 值得一试——延迟与成本改善直接。但生产环境若涉及模型混布、跨硬件、大批量高并发，请勿直接照搬；先在小流量验证精度与稳定性，再决定是否替换 serving 栈。把「快」建立在可复现的评测之上，才是工程落地的正确顺序。