NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
PyPI · #4250 most downloaded on PyPI
Kernels data structures (Python bindings)
Last release 19 days ago
15 Sep 2026
Ships fairly regularly
a new release about every 3 weeks
Most releases are documented
notes for 6 of 8 stable releases
Nothing withdrawn
no release was ever pulled
5 months old
10 releases · first in 2026
One column per month.
This release adds a version check to require the user to upgrade when a kernel does not support this kernels version.
This release adds a version check to require the user to upgrade when a kernel does not support this kernels version.
Nothing published for this version
use_kernel_func_from_hub , FuncRepository , LocalFuncRepository , and LockedFuncRepository are now deprecated.
This release adds preliminary support for signing kernels. Kernel signing is currently in an experimental phase and the details may still change. For this reason, signatures are currently not yet validated when downloading a kernel. Kernel verification consists of two parts:
metadata.json. During verification, all files must be present and have the correct hash. Verification also fails when there are files that are not specified in the digest.metadata.json.sigstore. The signature is made using sigstore, which signs artifacts using ephemeral signing keys, reducing the impact of key theft. During verification, the signature is used to validate that metadata.json was not tampered with and that the signature was made from a trusted repository and workflow.Since the kernel is not verified yet during retrieval during the experimental stage, we provide the kernels verify-signature command-line utility that can be used to verify a kernel on the Hub. The kernel and kernel version to verify should be provided as arguments:
$ kernels verify-signature kernels-community/flash-attn4 0
✅ torch-cuda: kernel metadata is correctly signedAll kernels-community kernels are signed. If you want to experiment with kernel signing yourself, there are two changes you need to make:
nix flake update to get the latest version of kernel-builder. The latest version embeds the kernel digest in the metadata.cosign to sign the kernel. This cannot be done as part of the build itself, since signing using ephemeral kernels requires internet access and the kernel build sandbox does not provide internet access. You can use the kernels-community workflow as an example of how to set up metadata signing.kernel-builder now supports the cpu-kernels skill for writing, optimizing, and benchmarking C++ kernels using AVX2/AVX512. For example, to add the skill to Claude, use:
$ kernel-builder skills add --skill cpu-kernels --claudeuse_kernel_func_from_hub, FuncRepository, LocalFuncRepository, and LockedFuncRepository are now deprecated.
To make a function extensible by a layer, you can now use the same decorator as for layers (use_kernel_forward_from_hub). This makes it clearer that the function is actually replaced by a layer. We have also added the use_kernelized_func decorator to attach such a function to the layer wherein it is used to make it discoverable by kernelize. Here is a full example:
# Make silu_and_mul replaceable with a kernel layer registered as `silu_and_mul`.
@use_kernel_forward_from_hub("silu_and_mul")
def silu_and_mul(x: torch.Tensor) -> torch.Tensor:
d = x.shape[-1] // 2
return F.silu(x[..., :d]) * x[..., d:]
# Attach the function to the layer where it is used to make it discoverable by `kernelize`.
@use_kernelized_func(silu_and_mul)
class FeedForward(nn.Module):
def __init__(self, in_features: int, out_features: int):
self.linear = nn.Linear(in_features, out_features)
def forward(self, x: torch.Tensor) -> torch.Tensor:
return silu_and_mul(self.linear(x))The FuncRepository, LocalFuncRepository, and LockedFuncRepository classes will not be replaced. They allowed using an arbitrary function from a kernel as a layer. However, this was easily misused and did not have a clean way of marking such a function as supporting torch.compile or backwards passes. Going forward, they should be made available as regular kernel layers that can be used with LayerRepository and its local/locked versions.
For more information, see the layer documentation.
Kernels support a small set of curated Python dependencies, such as einops, nvidia-cute-dsl, and apache-tvm-ffi. These dependencies are now also provided as extras of the kernels package, curated for CUDA and curated-xpu for XPU:
# CUDA
$ pip install 'kernels[curated]'
# XPU
$ pip install 'kernels[curated-xpu]'This can be used to install all dependencies that a kernel might use.
The documentation now provides an overview of the kernel-builder architecture.
FuncRepository] Add ability of detecting flags by @vasqu in #607hash subcommand and hook up in Nix by @danieldk in #618--filter-unsigned by @danieldk in #653OIDCSourceRepositoryURI by @danieldk in #652pyext in torch-noarch by @danieldk in #658kernel repo publishing rights by @sayakpaul in #662ptxas version than CUDA version by @danieldk in #671Full Changelog: v0.15.1...v0.16.0
This release adds support for can_torch_compile / can_backward to FuncRepository .
This release adds support for can_torch_compile/can_backward to FuncRepository.
As announced by deprecation warnings in previous releases, specifying the kernel version is now required when loading a kernel. E.g.
As announced by deprecation warnings in previous releases, specifying the kernel version is now required when loading a kernel. E.g.
# Not valid anymore!
activation = kernels.get_kernel("kernels-community/activation")is now invalid, instead use:
activation = kernels.get_kernel("kernels-community/activation", version=1)The Hub page for a kernel shows the latest available kernel version. kernels will also warn if the loaded kernel is not the latest version. Full specification of the version helps avoiding breaking existing code as a result of kernel API changes. When the API of a kernel changes, the kernel author must bump up the API version so that downstream code that hasn't been updated for the API change yet, can continue to use the previous version.
This release adds support for the Torch stable ABI. When a kernel uses the Torch stable API and sets the the ABI version in build.toml, the kernel will be built to be compatible with that Torch version and later. For instance, the targeted Torch version can be set to 2.10 by setting stable-abi in build.toml:
[torch]
stable-abi = "2.10"Using the stable ABI has large benefits:
Functions like get_kernel that normally use rely on network access now work with HF_HUB_OFFLINE=1. The kernel will be loaded if it was downloaded before, otherwise an exception will be raised. Using HF_HUB_OFFLINE disables trusted publisher verification (since this requires internet access).
kernel-builder now offers a skill for writing Intel XPU kernels contributed by @danielfleischer. For instance, to add the XPU kernels skill for Claude, use:
$ kernel-builder skills add --claude --skill xpu-kernelsUp till this release, kernel-builder has always linked libstdc++ statically. However, this lead to issues for some kernels where both the statically linked instance and the dynamically linked instance would try to initialize the same global memory, leading to segfaults and other issues. We didn't encounter this behavior before because most kernels only use C++ code for simple wrapping of the actual compute functions. However, we have encountered some kernels using facilities like C++ std::regex, which triggers global locale initialization. To resolve these issues, we switched to dynamic linking of libstdc++.
To enable dynamic linking while still being fully compatile with manylinux_2_28, we rewrap the EL8 gcc toolchain that is used by manylinux_2_28 using Nix and expose it as a stdenv. This allows us to build kernels with this toolchain. For more technical details, see: https://huggingface.co/docs/kernels/builder/design-nix-builder#manylinux228-compatibility
We now have a page that describes how to set up a kernel development environment in your IDE. Currently Visual Studio Code is covered, but we plan to add additional IDEs and editors in the future.
--major option by @danieldk in #550Device by @danieldk in #571LocalLayerRepository.__str__ by @danieldk in #597kernel-builder check-abi by @danieldk in #596Full Changelog: v0.14.1...v0.15.1
This is a bugfix release to use the Hub API to check that a publisher is trusted.
This is a bugfix release to use the Hub API to check that a publisher is trusted.
deprecation for version and revision check. by @sayakpaul in #450
Kernels are now a separate repository type on the Hub. This brings many usability improvements to kernels. For example, you can view all kernels that are hosted on the Hub on the kernel overview page:
https://huggingface.co/kernels
This page allows you to filter kernels by supported backends (CUDA, XPU, Metal, etc.) and specific accelerators such as NVIDIA H100 or Apple M5 Max. The page for a kernel will also show the supported accelerators, operating systems, architectures and Torch versions. For instance, the flash-attn2 page shows all supported hardware and architectures:
https://huggingface.co/kernels/kernels-community/flash-attn2
Starting with kernels 0.14, we only support the new kernel repository type. If you would like to upload kernels to the Hub, you can request support for kernel repositories for your user or organization under Settings -> Account.
Kernels have had support for optional metadata to state dependencies, etc. However, we have made including metadata mandatory. This allows users of kernels to query metadata such as the kernel's license and name. But it also made it possible to load kernels by their unique identifier that is also used in their Torch ops name. This makes it easier to debug kernels, since the dynamically loaded name corresponds to the operator name.
We have also added support for querying metadata of kernels that have been loaded:
>>> for kernel in kernels.get_loaded_kernels():
... metadata = kernel.metadata
... repo_info = kernel.repo_info
... print(metadata.id, repo_info.repo_id, metadata.backend.backend_type)
_relu_metal_c835f43 kernels-community/relu metalTo improve security and restrict loading of arbitrary code, kernels will by default only load kernels from trusted publishers. To load other kernels, use the trust_remote_code option:
get_kernel("some-other-org/my-kernel", version=1, trust_remote_code=True)This release adds support for Torch 2.12, currently based on RC9. The main branch will be updated with the final release when it is available, but there are typically no ABI changes in (late) release candidates, so building kernels with RC9 should also work on the final release.
get_loaded_kernels() by @cbensimon in #428result, build, or target dir by @danieldk in #464Metadata by @danieldk in #481build.toml when specified by @danieldk in #485None by @danieldk in #493make pin-actions target to pin all GitHub actions by @danieldk in #498Metadata from kernels-data by @danieldk in #499Full Changelog: v0.13.0...v0.14.0
* feat: add test and docs for get_loaded_kernels.
Fix failing tests (#497)
* feat: add test and docs for get_loaded_kernels.
* fix existing failing tests
* fix 2
* style
---------
Co-authored-by: Daniël de Kok <me@danieldk.eu>
Nothing published for this version
Nothing published for this version
Your coding agent can read these notes before it upgrades. Set up the MCP server →