← TinyGPT · docs · devlog · roadmap · speedup
source: docs/prds/5.5-sparse-moe-kernels.md · view on GitHub ↗

PRD — Custom Metal kernels for sparse MoE routing

Goal

Build the missing-upstream Metal kernels (sparse top-K routing, scatter_add equivalent, expert-parallel matmul gather) so MoE in TinyGPT can run hard routing — actually skipping inactive experts’ compute — instead of the dense soft-routing fallback that currently ships. Measure FLOP reduction vs the dense baseline; publish as “from-scratch sparse-MoE kernels on Apple silicon.”

Tier-5 research arc. Blocked upstream: MLX-Swift has no scatter_add primitive, which is the root reason hard routing isn’t shipped. Unblocks once either (a) MLX adds the op, or (b) we write the Metal shader ourselves through the MLXFast.metallib extension surface.

This PRD documents the design + the gate work that makes the implementation viable when unblocked. Implementing the kernel itself is the actual ship.

Why now

Scope — in

Scope — out

Files to touch (when unblocked)

FileChange
Sources/TinyGPTModel/MoESparse.swiftnew — Swift wrapper around the Metal kernels
Sources/TinyGPTModel/MoE.swiftroute between dense (existing) and sparse (new) based on a --moe-routing {dense,sparse} flag
kernels/moe_topk.metalnew — Metal shader for top-K + dispatch
kernels/moe_combine.metalnew — scatter_add equivalent
evals/moe-flops-sparse-vs-dense.shnew — measurement
docs/research/sparse-moe-metal.mdnew — publishable doc
docs/PLAN.md5.5 from blocked → ✅ when shipped

Don’t touch (until unblocked)

Acceptance criteria (when implementation ships)

Reference patterns

Open questions