Profiled both engines at batch 1 and 64 with the torch profiler. Most of each decode step goes to the MoE and attention kernels, so kernels.py starts there: RMSNorm, RoPE, split-KV decode attention and a grouped MXFP4 MoE that arranges its weights once at load time.
Baselines are set on 1× H100. Tuned vLLM 0.31.0 reaches 330.9 tok/s on gpt-oss-20b at batch 1 and the tuned original reaches 264.8, so the bar to beat is vLLM, not the original.
kernels.py is 297 lines and imports only torch and triton, and the copied kernels/ folder is gone. Decode tok/s on 1× H100, median of 3 runs × 1000 tokens:
| Point | kernels.py | Tuned vLLM | vs vLLM |
|---|
| 20b, batch 1 | 381.3 | 330.9 | +15.2% |
| 20b, batch 64 | 9,843.5 | 8,880.7 | +10.8% |
| 120b, batch 1 | 267.7 | 232.9 | +14.9% |
| 120b, batch 64 | 4,780.4 | 4,269.5 | +12.0% |
Greedy outputs match an fp32 reference on 20 prompts × 1000 steps, and GPQA-D and AIME25 scores sit inside the published 95% intervals. One gap is left: 120b serving at saturation runs at 0.946× vLLM, because prefill pauses decoding.
A merged-upcast candidate measured 57.3 s against vLLM’s 58.66 s before its files were lost. Rebuilding it from P0025, checking its tokens, then profiling the extra 2.9 s in 120b prefill.