# Pearl’s grouped GEMM kernel for MoE models, explained Pearl Research Labs runs every expert of a Mixture-of-Experts layer in one Blackwell kernel, up to 15% faster than the best baseline it tested. Mainnet mining stays dense. By Pearl Pulse Research Desk · 2026-10-21 Pearl Research Labs has written a GPU kernel that multiplies every expert of a Mixture-of-Experts (MoE) layer in a single launch, and reports it faster than the other implementations it tested for NVIDIA’s Blackwell GPUs in most cases, by up to 15%, mostly in small decode shapes. The post adds that Pearl’s mining on MoE models runs through it. That needs a boundary: since block 91,630, Mainnet has rejected MoE proofs, so for now this is inference engineering, not something today’s blocks can carry. ## Why MoE needs a grouped GEMM An MoE layer holds many experts, each its own weight matrix, and sends each token to a few of them. The post’s example is GLM 5.3, with 256 routed experts and 8 per token, served on eight B200 GPUs: a decode batch of 512 tokens leaves each GPU 32 experts and about 16 tokens for each, so 32 small multiplications of a 16 × 6,144 matrix by a 6,144 × 4,096 one. Launched one by one, each pays a launch’s overhead and fills only part of a B200’s 148 streaming multiprocessors. A grouped GEMM (general matrix multiplication) runs them all in one launch: each block of threads computes one tile of one expert’s output, 2,048 of them in this example instead of 64 per launch. The post assumes tokens spread evenly across experts, as training usually encourages, and leaves out the layer’s shared expert. Sources: [Pearl Research Labs: Optimizing Grouped GEMM for MoE on Blackwell](https://pearlresearch.ai/research/blog/grouped-gemm) ## Four changes, three of them measured The kernel began as a port of FlashInfer’s C++ kernel to CuTe DSL and borrows techniques from quack, an open-source kernel library. The post describes four changes. It writes results straight from registers to GPU memory instead of staging them in shared memory, with 256-bit stores to keep that fast, and spends the freed shared memory on a seventh pipeline stage: about 2% faster at small batches. It uses 64-row tiles on a single thread block, which quack offers only in its two-block mode; that halves each activation stage and adds blocks, and where the autotuner picked it (experts averaging 64 tokens or fewer) it saved 2–3%. It loads larger slices of the weights at once, two K tiles per copy, keeping more data in flight: about 5% on the smaller cases, across three runs. And for its largest tiles it synchronizes the accumulator’s two halves separately, so one tile’s epilogue overlaps the next tile’s main loop; for that the post gives no figure. The common thread: below a fairly large problem size, the post says, the kernel is bound by memory traffic, not arithmetic, so most of the changes keep more bytes moving. Sources: [Pearl Research Labs: Optimizing Grouped GEMM for MoE on Blackwell](https://pearlresearch.ai/research/blog/grouped-gemm) · [quack: the baseline kernel library](https://github.com/Dao-AILab/quack) ## What the 15% measures The headline compares kernels, not served models. On the gate and up projections of three MoE models (GLM 5.3, DeepSeek V4 Pro and Kimi K3), Pearl’s kernel was in most cases faster than every implementation the team tested (its charts show CUTLASS, DeepGEMM, FlashInfer and quack), by up to 15% over the best of them, quack, mostly in small decode shapes; where it lost, the post says, it lost by less than 2%. Each implementation was tuned and timed inside a CUDA graph, which leaves out the host’s launch overhead. The post doesn’t name the GPU or the number format of its benchmarks or break the 15% down by change, and its per-shape results are charts. A projection that runs 15% faster speeds up a served model by less: by its share of each decoding step, which the post doesn’t measure. The optimized kernel isn’t public yet: the post says it will be released with Pearl’s FP8 scheme, whose open pull request so far holds an earlier grouped kernel without these changes. We have not reproduced the results. Sources: [Pearl Research Labs: Optimizing Grouped GEMM for MoE on Blackwell](https://pearlresearch.ai/research/blog/grouped-gemm) [Read a speedup as a comparison](https://pearl-pulse.com/research/gpu-hashing) ## Mining on MoE, and the dense-only rule The post says this is also the kernel through which Pearl mining runs on MoE workloads, and that the team plans to bring mining inside fused kernels such as DeepSeek’s Mega MoE. On Mainnet, that mining has nowhere to go for now. A hard fork at block 71,935 (12 Jun 2026) allowed MoE proofs; a soft fork at block 91,630 (23 Jul) rejected them again, and Pearl’s node still requires every block’s certificate to carry a dense proof, V3 certificates included. The FP8 scheme the post points to is in an open pull request on Pearl’s repository (#311, “feat(fp8): certificate-v4 + mining”), unmerged as of 21 Oct 2026. As it stands, its new V4 certificates can carry MoE proofs again and fall outside the dense-only rule, but its fork is set only for test networks, with no Mainnet height. Until that changes, the kernel speeds up MoE inference, and Mainnet’s mining proves dense multiplications only. Sources: [Pearl Research Labs: Optimizing Grouped GEMM for MoE on Blackwell](https://pearlresearch.ai/research/blog/grouped-gemm) · [Pearl node source: the certificate rules](https://github.com/pearl-research-labs/pearl) · [Pearl pull request #311: the FP8 scheme and certificate V4](https://github.com/pearl-research-labs/pearl/pull/311) [The proof-era timeline](https://pearl-pulse.com/protocol) · [Inspect a block’s certificate](https://pearl-pulse.com/proofs) ## The Pearl Pulse view — Editorial perspective Fast MoE kernels matter to Pearl for a reason the 15% doesn’t show. Many of the largest open models, including the three the post benchmarks, are Mixture-of-Experts, and mining that can’t run inside their expert layers sits beside the most demanding inference rather than within it. The FP8 scheme, as its pull request stands, would bring MoE proofs back: a consensus change with its own security case, after Mainnet once turned them off. We would judge it on the rules as activated and an independent reproduction of the kernel, not on the benchmark. ## Primary sources - [Pearl Research Labs: Optimizing Grouped GEMM for MoE on Blackwell](https://pearlresearch.ai/research/blog/grouped-gemm) - [quack: the baseline kernel library](https://github.com/Dao-AILab/quack) - [Pearl node source: the certificate rules](https://github.com/pearl-research-labs/pearl) - [Pearl pull request #311: the FP8 scheme and certificate V4](https://github.com/pearl-research-labs/pearl/pull/311) This article draws on Pearl Research Labs’ post (read in full on 21 Oct 2026; it carries no date or author), Pearl’s node source and the FP8 pull request. We quote only figures the post’s text gives, not its charts, and have not reproduced any of them.