Hugging Face has launched a new repository type called “kernel” on its Hub, allowing developers to distribute custom compute kernels alongside models and datasets.
The update also introduces stricter security controls, separates command-line tools, and adds support for the Torch Stable ABI and Apache TVM FFI.
Kernels – a new repository type
The new “kernel” repository type on the Hub categorises compute-related code specifically. Users can now browse available kernels to check which accelerators, operating systems, and backend versions are supported.
Browsing all available kernels is possible at https://huggingface.co/kernels.
Listing these repositories as first-class citizens on the Hub helps users identify trends across kernels, models, and applications. This change makes the code more discoverable.
Improved security
Kernels run native code with the same privileges as the Python process that loads them. A malicious kernel can therefore cause real harm to a system. Security has always been a priority for the project.
The team focused early on reproducibility. Users should be able to recompile a kernel and verify it matches the publicly available source. Nix handles this by keeping builds pure through hermetic evaluation and a strongly isolated sandbox. The project embeds the source Git SHA1 into the kernel itself to improve provenance.
Recent months have added additional layers of defence: trusted kernel publishers and code signing.
Trusted kernel publishers
The new repository type introduced “trusted publishers”. Since kernels execute code on a machine with the same privileges as the Python process, an attacker could compromise a machine by uploading a malicious kernel and convincing a user to load it.
To prevent this, the kernels package will only load kernels from trusted publishers by default. A trusted publisher is an organisation the community trusts to act in good faith.
The project still supports loading kernels from untrusted sources, but users must explicitly opt in using the trust_remote_code argument when loading a kernel from the Hub:
from kernels import get_kernel
kernel_module = get_kernel(
"Atlas-Inference/gdn", version=1, trust_remote_code=True
)
By default, users cannot publish kernel repositories on the Hub. They must request access to become a kernel publisher. Users and organisations can request this from their account settings. This allows the team to review requests on a case-by-case basis.
Kernel signing
Code signing adds another security layer. This protects against a scenario where an attacker uploads a malicious kernel to a repository owned by a trusted publisher whose Hub credentials were compromised.
In code signing, a kernel is signed with a private key known only to the developer. The signature is validated with a public key available to everyone. If an attacker compromises a trusted publisher’s Hub account, they cannot sign a malicious kernel because they do not possess the private key.
The project uses Sigstore’s cosign to sign kernels with ephemeral private keys. These keys are valid only for a limited time. Even if a key is leaked, an attacker typically cannot use it. The system also verifies that the kernel was signed by a trusted GitHub workflow from a trusted repository.
Kernel signing is already supported by kernel-builder. The kernels verify-signature command allows users to verify a kernel. The system does not verify the signature upon loading a kernel yet. The team wants to test this functionality more before fully rolling it out. Preliminary notes on setting up code signing are in the kernels 0.16.0 release notes: https://github.com/huggingface/kernels/releases/tag/v0.16.0.
Revamped CLIs
Previously, utilities were intertwined between kernels and kernel-builder. The project has now established a better separation of concern between the CLI of kernels and kernel-builder.
The mental model is that kernels is a library for loading and preparing kernels for use. It should not include anything related to “building” kernels.
As a result, both kernels and kernel-builder are now much leaner and more specific. Refer to the documentation to learn more.
More coverage of frameworks and backends
Support for frameworks has extended. The most visible changes include:
- The project added support for the Torch Stable ABI to kernels and kernel-builder. This ABI allows developers to target a particular Torch version or any version released after it for roughly two years. A kernel targeting the Torch 2.9 Stable ABI supports Torch >= 2.9.
- Apache TVM FFI is the first framework supported besides Torch. TVM FFI is a standardized ABI for kernels that interoperates with other frameworks such as PyTorch, Jax and CuPy. This allows developers to make kernels that run across frameworks.
Foundation for agentic kernel development
kernel-builder and kernels complement the rise of agentic kernel development. This involves an agent creating an optimized kernel from scratch. Together, they support a workflow where agents can scaffold, build, benchmark, and iteratively optimize kernels.
Agentic kernel development is still nascent. The right development loops will continue to evolve. Simple, clear fundamentals are especially important where tools should be easy to compose into whatever agent workflows people choose.
kernel-builder enforces a structure for how kernel source code should be scaffolded and used to perform reproducible builds. This gives agents a predictable project layout and repeatable workflow. Its CLI is also meant to be agent-optimized. This can mean non-interactive commands and outputs straightforward for an agent to interpret programmatically.
The tool also has backend-specific skills to help agents navigate the idiosyncrasies of different backends. These skills capture backend-specific toolchains, compilation paths, and performance considerations.
Building a kernel successfully is not the only goal. The code must deliver actual speedups over a baseline on the target hardware. A successful build is therefore only the first validation step. The target hardware can include many different accelerators, even different families of the same accelerator.
It is important to evaluate results across hardware vendors and generations where relevant. Tight integration with HF Jobs makes this benchmarking process easy. Agents can use this integration to run benchmark suites, collect performance results, and compare them against a defined baseline.
Agents can run tests across different hardware configurations to get reliable feedback on the performance of generated kernels. This feedback informs the next optimization iteration.
Below are examples of agent-augmented kernels. These illustrate the kinds of kernels that can be developed and evaluated through this workflow.
Misc
Environment setup
Setting up an environment for building kernels with kernel-builder can be daunting. To make it easier, the project now has an installation script for setting up an environment in one click. Users who prefer working with ephemeral instances should follow the Terraform setup guide.
System card for kernels
After kernels are built, the project creates a system card for each kernel. This exposes useful information, including how to use it and its exposed interfaces. When the kernel is pushed to the Hub, this system card becomes the front matter for the repository.
Is a kernel compatible on my system?
Users often ask whether a kernel is compatible with their system. The has_kernel() method handles this:
from kernels import has_kernel
print(has_kernel("kernels-community/activation", version=1))
It returns a bool. If you need more explanations around why a kernel is not supported, use get_kernel_variants():
from kernels import get_kernel_variants, VariantAccepted
for decision in get_kernel_variants("kernels-community/activation", version=1):
name = decision.variant.variant_str
if isinstance(decision, VariantAccepted):
print(f"{name}: compatible")
else:
print(f"{name}: rejected ({decision.reason})")
This prints output depending on the machine you are on:
torch212-cxx11-cu130-aarch64-linux: compatible
torch210-cu128-x86_64-windows: rejected (CPU (x86_64) does not match system CPU (aarch64))
torch211-cu128-x86_64-windows: rejected (CPU (x86_64) does not match system CPU (aarch64))
torch212-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux))
torch211-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux))
torch210-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux))
torch29-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux))
…
Improved manylinux_2_28 support
Kernel-builder has targeted manylinux_2_28 almost since the beginning. The project used to target manylinux by using a modern gcc toolchain compiled with glibc 2.28. To avoid compatibility issues with older versions of libstdc++, it statically linked libstdc++.
However, this approach recently resulted in some issues. Some libstdc++ functionality uses global initialization. This can lead to corrupted data when multiple libstdc++ versions come into play. This includes the libstdc++ linked dynamically by PyTorch and the libstdc++ linked statically by a kernel. Some recent kernels use functionality, such as C++ regexes, that trigger global initializations. This causes corrupted data, leading to segfaults and other issues.
To solve this, kernels now link libstdc++ dynamically. To ensure compatibility with old libstdc++ versions, the project now compiles kernels with the official manylinux_2_28 toolchain.
Conclusion
The goal with the Kernels project is to serve both kernel developers and users of custom kernels. The team is keen on receiving feedback from the community on how to improve it. Users are encouraged to contribute.
Acknowledgements: Thanks to Aritra for reviewing the post.
