Skip to content

DEP: Update dependency kernels to >=0.17.0,<0.18.0 - #84

Closed
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/kernels-0.x
Closed

DEP: Update dependency kernels to >=0.17.0,<0.18.0#84
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/kernels-0.x

Conversation

@renovate

@renovate renovate Bot commented Sep 14, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
kernels >=0.16.0,<0.17.0 → >=0.17.0,<0.18.0 age confidence

Release Notes

huggingface/kernels (kernels)

v0.17.0

Compare Source

New features

Device architecture checks

get_kernel now raises an exception if the kernel does not support the architecture of the GPU in the machine. For instance, if a kernel is only compiled for Hopper (CUDA capability 9.0) is loaded on a Blackwell GPU with CUDA capability 12.0 an exception is raised. Previously, an incompatible kernel would load fine and then (loudly or quietly) fail at kernel launch time.

In some cases, an AOT kernel may support more architectures than the metadata declares, for instance when the kernel has a Triton fall-back path. For such kernels, the check can be disabled:

from kernels import get_kernel, has_kernel

has_kernel("kernels-community/flash-attn3", version=1, check_arch=False)
flash_attn3 = get_kernel("kernels-community/flash-attn3", version=1, check_arch=False)
Kernel dependencies (experimental)

Kernels can now depend on other kernels from the Hub. Dependencies are declared in the general section of build.toml. For example:

[general]

# ...
kernel-depends = [
    { repo-id = "kernels-community/activation", version = 1 },
    { repo-id = "kernels-community/einops", version = 1 },
]

The kernel dependencies can than be retrieved when the kernel is imported using the new get_kernel_dep function:

import kernels

activation = kernels.get_kernel_dep("kernels-community/activation")
einops = kernels.get_kernel_dep("kernels-community/einops")

Warning: using kernel dependencies breaks support for kernels<0.17. For this reason, we recommend you to only start using kernel dependencies when version 0.17.0 has been out for a while. The kernels minimum version metadata described below will be ported to kernels 0.16 and will help with this and future migrations.

kernels minimum version

To introduce new features more gracefully in the future, using newer kernels features (such as kernel dependencies) will write the minimum required version to the kernel metadata. The kernels client will use this to verify that it is compatible with the kernel and, if not, suggest what version of kernels to install.

Conditional kernelization of layers

use_kernel_forward_from_hub now accepts an optional condition argument. This condition is applied to the layer when kernelize is called. This is useful when a layer supports multiple configurations, but kernelization is only supported for one configuration:

@use_kernel_forward_from_hub(
    "SwiGLUMLP",
    condition=lambda module: module.config.hidden_act == "silu",
)
class MyMLP(nn.Module):
    ...
Experimental TPU backend

kernel-builder now has experimental support for building TPU torch_tpu/Pallas kernels. backends = ["tpu"] produces a torch-tpu noarch variant.

Intel Crescent Island (cri) support

The XPU/SYCL build supports Intel Crescent Island.

Helion support

The Helion DSL is now supported through the new helion Python dependency (python-depends = ["helion"]). See the blog post Helion x 🤗 HF Kernels: Building and Shipping Out-of-the-box Performant Kernels for more information.

Trusting specific repositories

kernels only loads kernels from a curated set of trusted publishers. Until now, the only way to load a kernel from another publisher was to opt in with trust_remote_code=True, which disables the check entirely. You can now pass a list of repository IDs instead, so that only the given repositories are allowed:

get_kernel(
    "some-other-org/my-kernel",
    version=1,
    trust_remote_code=["some-other-org/my-kernel"],
)
kernels info

The new kernels info subcommand describes a kernel from a Hub repo ID or a local path, printing its name, version, license, upstream/source repositories, Python dependencies, and supported backends:

$ kernels info kernels-community/activation
Repository: kernels-community/activation
Revision: v1
Name: activation
Version: 1
License: Apache-2.0
Upstream: -
Source: -
Python dependencies: -
Backends: cuda, metal
Build provenance and dirty builds

Kernel metadata now records the provenance of a build in a provenance object. The provenance information contains the Git commit of the kernel and the builder and whether both were in a clean or dirty state.

Backend-scoped stable ABI

kernels 0.15.1 added experimental support for the Torch stable ABI. The stable ABI was enabled by setting torch.stable-abi to the stable ABI version that the kernel should be compiled with. Unfortunately, the stable ABI is not complete enough yet to be supported on all backends. For this reason, we have decided to change the torch.stable-abi option to take a table with versions per-backend:

[torch.stable-abi]
cuda = "2.11"
rocm = "2.9"

Backends that are not listed are compiled without the stable ABI. This makes it possible to opt-in to the stable ABI per backend and use different stable ABI versions per backend.

Torch 2.13 and 2.14

This release adds support for Torch 2.13 and 2.14 and removes Torch 2.11 and 2.12.

Major documentation improvements

Breaking changes

  • stable-abi is now a table rather than a single Torch version. build.toml files can be migrated to edition 5 with kernel-builder update-build.
  • Device architecture checks are enabled by default. Kernels that support more architectures than they declare (e.g. through a Triton fallback) must be loaded with check_arch=False.
  • The compat module is not generated anymore. Kernel tests must use get_kernel instead of importing the kernel directly.

Packaging

kernels-data is not a separate Python package anymore, but is directly integrated into the kernels package.

What's Changed

New Contributors

Full Changelog: huggingface/kernels@v0.16.1...v0.17.0

Configuration

📅 Schedule: (in timezone America/New_York)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot added dependencies Pull requests that update a dependency file python Pull requests that update python code labels Sep 14, 2026
@renovate renovate Bot changed the title DEP: Update dependency kernels to >=0.17.0,<0.18.0 DEP: Update dependency kernels to >=0.17.0,<0.18.0 - autoclosed Sep 16, 2026
@renovate renovate Bot closed this Sep 16, 2026
@renovate
renovate Bot deleted the renovate/kernels-0.x branch September 16, 2026 21:21
@jshn9515 jshn9515 changed the title DEP: Update dependency kernels to >=0.17.0,<0.18.0 - autoclosed DEP: Update dependency kernels to >=0.17.0,<0.18.0 Sep 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@jshn9515 jshn9515

Labels

dependencies Pull requests that update a dependency file python Pull requests that update python code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@jshn9515