Popcorn: Democratized Fast Kernel Dispatching | Tilde

Back<br>Popcorn: Democratized Fast Kernel Dispatching<br>8.11.2026<br>Timor Averbuch*,  Dhruv Pai<br>* Core Contributor; Correspondence to timor@tilderesearch.com

cite ↓

TL;DR<br>Frontier model architecture research keeps changing the op inventory, but most of the stack still assumes a small, stable set of fused kernels. Choosing a correct, fast implementation across packages, shapes, dtypes, and GPUs is hard — and a speedup is worthless if it produces the wrong answer.<br>Popcorn sits between kernels and users. You call a stable, reference-backed op API; Popcorn routes each call to the fastest implementation validated for those inputs and hardware. Today we are open-sourcing it.<br>Read the docs ↗GitHub ↗PyPI ↗

Outline

Introduction — Kernel selection as infrastructure

Design — Contracts, dispatch, correctness, agents

Optimize Modeling Code — Uniform Popcorn API

How to Write a Kernel — Reference, impl, validate, bench

The Popcorn Bundle — Dispatch portfolio and explorer

The Future of Popcorn — More devices, agentic loops, contributions

1: Introduction

Frontier model architecture research presents an open engineering question that most of the stack was never designed to answer: how do you train, optimize, and ship models when the model architecture itself keeps changing? Most libraries and modeling code presume that the op inventory stays somewhat stable. Although it becomes increasingly clear that model architecture is a huge lever in pushing the frontier, current infrastructure is built so that the same handful of fused kernels cover the hot path. That is not our world. Over the past year we have trained thousands of models while pushing the boundaries of model architecture, and we have had to build custom infrastructure to keep up with that pace of experimentation.

One of the sharpest pain points is deciding which kernel to use. The open-source ecosystem is rich: research releases ship kernels, some are tested, some are integrated into libraries, and collections like FLA [1] and Liger [2] gather many of them in one place. But with so many collections, lone kernels, and vendor paths in play, there is no practical way to hand-pick the fastest correct implementation for every op, shape, dtype, and GPU we care about. Numerical errors show up constantly and quietly derail progress. A speedup is worthless if it produces the wrong answer, so confidence in correctness has to come before chasing milliseconds. We want to squeeze performance as we scale, and we want to take full advantage of open source. But inconsistent APIs, mismatched test grids, and incomparable benchmarks make it hard to compare kernels, trust them, or even wire them into a training stack without constant glue work.

To make this ecosystem usable at the pace of model architecture research, kernel selection and development has to become a measured infrastructure problem rather than a recurring integration project that arises with each model architecture. That is why we built Popcorn. Popcorn is a layer between kernels and users. Users call a stable, reference-backed op API, and Popcorn routes each call to the fastest implementation validated for those inputs and hardware. This lets model code benefit from an evolving kernel ecosystem without inheriting its fragmentation or correctness risks.

Today, we're open-sourcing Popcorn and publishing it as a Python package on PyPI. The recommended install is uv pip install popcorn. We hope it gives researchers and kernel engineers a common foundation for comparing implementations, integrating new work, and sharing improvements across the ecosystem.

DocumentationGitHubPyPI<br>Open

2: Design

Popcorn is built around a few deliberate bets:

Five bets<br>01contract02dispatch03validate04local05agents<br>01<br>A contract per op

@kernel(reference=torch_op)<br>def op(x: Tensor["..."]) -> Tensor["..."]: ...

candidate.supports(case) # optional<br>candidate(case) ≈ reference(case) # required

Figure 1. The five principles behind Popcorn's validation and dispatch model.<br>A contract per op. Every kernel has a pure PyTorch reference that defines semantics (shapes, dtypes, defaults, and gradients) and serves as the correctness oracle. Together, these properties form a contract: for any supported input, a valid implementation must produce the same output as the reference. The contract is one-sided : an implementation may support only a subset of valid inputs, but it must match the reference on every input it claims to support.

Dispatch is data-driven. Every kernel call is implicitly a dispatch request: given inputs, the Dispatcher's goal is to match it with the fastest implementation that satisfies the contract. Candidate implementations are filtered by package availability, shape and dtype support, and optional predicates. A cached performance grid is referenced to map regions of the input space to the best backend, avoiding repeated benchmarking while adapting its choice to the...