vllm.triton_utils.dispatcher
¶
Registry for overriding Triton kernels with platform implementations.
Non-CUDA platforms can replace Triton kernels defined in vLLM core without modifying core code:
from vllm.triton_utils.dispatcher import register_kernels
register_kernels({
"vllm.v1.sample.rejection_sampler.expand_kernel": my_expand_impl,
"vllm.v1.worker.mamba_utils.batch_memcpy_kernel": my_memcpy_impl,
})
The same call covers Triton device functions (@triton.jit helpers
called from inside other kernels and inlined at compile time): an
implementation that is itself a Triton kernel is swapped in directly, so
outer kernels keep compiling and launchable kernels run natively. Only
non-Triton implementations (plain callables, grid-remapping launchers)
are wrapped in a launch adapter.
Classes:
-
KernelOverride–Stand in for a Triton kernel, routing launches to a non-Triton
impl.
Functions:
-
register_kernels–Register platform-specific implementations for Triton kernels.
KernelOverride
¶
Stand in for a Triton kernel, routing launches to a non-Triton impl.
Used by :func:register_kernels for implementations that are not
themselves Triton kernels (plain callables, grid-remapping launchers);
Triton kernel implementations are swapped in directly and never wrapped.
The JIT warmup infrastructure launches kernels as
kernel[grid](**kwargs) where kwargs are keyed by the original
kernel's argument names. This wrapper forwards those launch arguments
to the platform implementation: by keyword when the implementation's
parameter names match the kernel's, otherwise positionally in the
kernel's parameter order. An implementation that reimplements the
kernel[grid] protocol (a grid-remapping launcher) receives the
caller's grid. Compile-only JIT warmup (kernel.warmup(grid,
**kwargs)) is delegated to the implementation's own warmup when
present, and is a no-op otherwise.
Methods:
-
__getitem__–Bind a launch grid, mirroring Triton's
kernel[grid]. -
warmup–Delegate compile-only warmup to the implementation.
Source code in vllm/triton_utils/dispatcher.py
__getitem__(grid)
¶
Bind a launch grid, mirroring Triton's kernel[grid].
A platform override that is itself a Triton kernel (or any object
implementing __getitem__) takes over the launch natively:
impl[grid](*args, **kwargs) binds against the override's own
signature, so the caller's grid reaches the override unchanged.
Such an override must mirror the original kernel's parameter names
(or order), since launch sites key arguments by the original names.
Plain-callable overrides are invoked with the launch arguments
directly.
Source code in vllm/triton_utils/dispatcher.py
warmup(grid=None, **kwargs)
¶
Delegate compile-only warmup to the implementation.
The JIT warmup machinery compiles warmup-owned kernels as
kernel.warmup(grid, **kwargs). Forward that to the
implementation's own kernel so the override is what gets compiled.
Implementations without a warmable Triton kernel (plain callables,
grid-remapping launchers) have nothing to warm up and compile
lazily on first launch.
Source code in vllm/triton_utils/dispatcher.py
_is_triton_kernel(obj)
¶
Whether obj is a real Triton kernel (JITFunction).
Triton kernels (both launchable kernels and device functions called from inside other kernels) expose the JIT launch protocol; plain callables and grid-remapping launcher objects do not.
Source code in vllm/triton_utils/dispatcher.py
_kernel_arg_names(kernel)
¶
Return the argument names of a Triton kernel or its fallback.
Source code in vllm/triton_utils/dispatcher.py
_rebind_impls(replacements)
¶
Point every reference to each original object at its replacement.
A kernel or device-function object can be captured in two kinds of places besides its defining module, and both must be patched for the overrides to take effect everywhere:
- plain attributes of other modules (
from mod import kernelcopies), rebound to the replacement; - JIT warmup owners, whose
kernelattribute is the kernel they launch; swapped, and their cached_kernel_arg_namesinvalidated so the launch binding re-derives from the replacement.
One pass over sys.modules handles all objects in replacements.
Source code in vllm/triton_utils/dispatcher.py
_resolve_kernel(name)
¶
Return the (host object, attribute) holding the kernel name.
Source code in vllm/triton_utils/dispatcher.py
register_kernels(overrides)
¶
Register platform-specific implementations for Triton kernels.
Parameters:
-
(overrides¶Mapping[str, Callable[..., Any]]) –Mapping from fully qualified kernel name to the platform implementation. Kernel names look like "vllm.v1.sample.rejection_sampler.expand_kernel"; for kernels owned by a JIT warmup class, include the attribute path, e.g. "vllm.v1.worker.block_table.ComputeSlotMappingKernel.kernel".
An implementation that is itself a Triton kernel (also the only kind that works for Triton device functions, which are inlined into other kernels at compile time) is swapped in directly and launches natively:
impl[grid](*args, **kwargs)binds against the implementation's own signature and the caller's grid reaches it unchanged. Such an implementation must mirror the original kernel's parameter names (or order).Any other implementation (a plain callable, or a launcher that rewrites the grid for a non-CUDA device) is invoked with the launch arguments in the original kernel's parameter order (or by keyword when its parameter names match the kernel's).