What's Changed

• Set version to 0.12.1.dev0 by @danieldk in #233
• kernels: remove the version warning until we have the Hub UX by @danieldk in #234

Full Changelog: v0.12.0...v0.12.1

New features

Merge of kernels and kernel-builder repositories

kernel-builder has been merged into the kernels repository. This makes it easier for us to coordinate changes that affect both the kernels Python library and the builder. To switch to the new repo when building kernels, replace the following line in flake.nix

kernel-builder.url = "github:huggingface/kernel-builder";

by

kernel-builder.url = "github:huggingface/kernels";

As a result of the merge, the documentation of kernel-builder is now also available at: https://huggingface.co/docs/kernels/

Support for kernel versions

Before kernels 0.12, kernels could be pulled from a repository without specifying a version. This led to the issue that kernels would typically pull from main. As a result, incompatible changes to the main branch would break downstream use of kernels. To avoid this in the future, we introduce kernel versions. In the future, each kernel will have a major version and when a kernel is uploaded to the Hub, it will be uploaded to the corresponding version branch. The kernel author will bump the kernel version when there are incompatible changes. In this way, kernels can evolve their APIs without breakage for existing users. Versioning can be enabled for a kernel by specifying the version in build.toml:

[general]
version = 1

This will add the kernel version to the kernel's metadata and the kernel upload command will upload builds to the v1 version branch.

Kernel users can pull from a version branch using the version argument. For example:

activation = get_kernel("kernels-community/activation", version=1)

For more information, refer to the guide to adopting kernel versions. Getting kernels without a version is deprecated in kernels 0.12 and will become an error in 0.14 (except for local kernels).

PyTorch 2.10 support

Support for PyTorch 2.10 has been added to the builder. Support for Torch 2.8 has been removed in accordance with our policy to support the two latest Torch versions.

Kernel benchmarks

kernels 0.12 adds the experimental kernels benchmark subcommand. This will run benchmarks for a given kernel, if available. The kernels benchmark command will be extended and documented in the upcoming releases.

What's Changed

• Set version to 0.11.8.dev0 by @danieldk in #206
• Fix too-aggressive layer caching by @danieldk in #208
• [chore] remove explicit typing where possible. by @sayakpaul in #212
• Initial benchmark command by @drbh in #207
• docs: Update docs/source/kernel-requirements.md after release 0.11.4 by @onel in #214
• Update docs/source/layers.md with LocalFuncRepository example by @onel in #211
• Merge kernel-builder into the kernels repo by @danieldk in #215
• Merge the kernel-builder docs into the kernels docs by @danieldk in #216
• hotfix: restore the README by @danieldk in #218
• hotfix: build documentation by @danieldk in #219
• Merge Nix from kernel-builder with kernels/build2cmake by @danieldk in #217
• Use Makefile to copy Python dependency data by @danieldk in #221
• Add back README to the Python package by @danieldk in #222
• CI: fix some paths by @danieldk in #223
• Add support for kernel versions by @danieldk in #209
• hotfix: fixup get_kernel call in kernels README by @danieldk in #224
• docs: fix incorrectly resolved conflict by @danieldk in #225
• nix: genFlakeOutputs -> genKernelFlakeOutputs by @danieldk in #226
• python3Packages.kernels: build from local source by @danieldk in #227
• python3Packages.torch-bin_2_10: 2.10.0-rc7 -> 2.10.0 by @danieldk in #228
• Benchmark command fixes by @danieldk in #229
• Unbreak kernels upload without a benchmark by @danieldk in #230
• Set version to set-version-0.12.0.dev0 by @danieldk in #231

New Contributors

• @onel made their first contribution in #214

Full Changelog: v0.11.7...v0.12.0

What's Changed

• Set version to 0.11.7.dev0 by @danieldk in #204
• Tighten up build variant check by @danieldk in #205

Full Changelog: v0.11.6...v0.11.7

What's Changed

• Set version to 0.11.6.dev0 by @danieldk in #199
• Upgrade GitHub Actions for Node 24 compatibility by @salmanmkc in #200
• fix: adjust upload pattern by @drbh in #203

New Contributors

• @salmanmkc made their first contribution in #200

Full Changelog: v0.11.5...v0.11.6

What's Changed

• Set version to 0.11.5.dev0 by @danieldk in #196
• Add DNNL DLL path on Windows by @danieldk in #198

Full Changelog: v0.11.4...v0.11.5

This release extends support for curated Python dependencies and synchronizes support with upcoming kernel-builder changes.

What's Changed

• Remove to-wheel subcommand by @danieldk in #191
• fix local dev version by @MekkCyber in #193
• Add support for backend dependencies by @danieldk in #194
• Fetch Python dependencies from kernel-builder main branch by @danieldk in #195

Full Changelog: v0.11.3...v0.11.4

New features

Use kernel functions to extend layers

Up until now, it was only possible to extend existing layers with kernel layers from the Hub. Starting with this release it's also possible to extend them with kernel functions from the Hub. For instance, a silu-and-mul layer

@use_kernel_forward_from_hub("SiluAndMul")
class SiluAndMul(nn.Module):
    def forward(self, input: torch.Tensor) -> torch.Tensor:
        d = input.shape[-1] // 2
        return F.silu(input[..., :d]) * input[..., d:]

can now be extended with a silu_and_mul function from the Hub:

with use_kernel_mapping({
    "SiluAndMul": {
        "cuda": FuncRepository(
            repo_id="kernels-community/activation",
            func_name="silu_and_mul",
        ),
    }
}):
    kernelize(...)

We have added the FuncRepository, LocalFuncRepository, and LockedFuncRepository classes to load functions from regular, local, and locked repositories.

Making functions extensible

The counterpart to the previous enhancement is that functions can now also be made extensible using the new use_kernel_func_from_hub decorator:

@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:]

This will implicitly replace the function by a Torch nn.Module. Since Torch modules implement __call__, it can still be called as a function:

out = silu_and_mul(x)

However, when the function stored as part of a model/layer, it will also be kernelized:

class FeedForward(nn.Module):
  def __init__(self, in_features: int, out_features: int):
      self.linear = nn.Linear(in_features, out_features)
      # Note: silu_and_mul is a Torch module.
      self.silu_and_mul = silu_and_mul

  def forward(self, x: torch.Tensor) -> torch.Tensor:
      return self.silu_and_mul(self.linear(x))

Similar to layers, the function can be kernelized using both a Hub layer and a Hub function.

What's Changed

• Split up kernels.layer into several modules by @danieldk in #187
• Add discord link to the kernel requirements doc by @danieldk in #189
• Support functions as layers by @danieldk in #188

Full Changelog: v0.11.2...v0.11.3

New feature

This version supports the new noarch build variant that replaces universal kernels. Noarch builds use the build variant format torch-<backend>. This solves two issues that the universal variant has:

1. A kernel without AoT-compiled might still be backend-specific. E.g. NVIDIA CuTe-based kernels are not universal in the sense that they don't work on non-NVIDIA GPUs.
2. We cannot specify dependencies per backend.

This change introduces support for loading noarch kernels. In the future, we will start emitting deprecation warnings for universal kernels (to eventually remove support).

Full Changelog: v0.11.1...v0.11.2

Backport: support noarch build variants (torch-<backend>), see #190.

Backport: support noarch build variants (torch-<backend>), see #190.