Hugging Face’s July 6 Kernels update crossed a threshold worth paying attention to: custom GPU kernels on the Hub are now signed, governed by a trusted publisher model, and require a dedicated repository type that replaces the old model-type repo format. If your team loads kernels directly from the Hub, the old format is no longer accepted. Migration is not optional.
What Are Hugging Face Kernels? #
Custom AI kernels are low-level GPU functions — written in CUDA, Triton, or similar — that swap out standard PyTorch or JAX operations for hand-optimized code. They are how production inference systems get real throughput gains: vLLM, for instance, achieves up to 24x higher throughput over vanilla Transformers largely through custom attention kernels. Hugging Face Kernels is the Hub infrastructure for packaging, distributing, and these artifacts.
The Breaking Change: New Repository Type Required #
The most urgent part of this update is structural. Kernels were previously stored in standard model-type Hub repositories. That path is now closed — the kernels
Python package no longer accepts model-type repos. Teams that built CI/CD pipelines, Dockerfiles, or inference servers that pull kernels from model-type Hub repos need to migrate to the new dedicated “kernel” repository type.
The new format is not just a rename. Kernel repos carry structured metadata: which accelerators are supported (NVIDIA CUDA, AMD ROCm, Apple Metal, Intel XPU), which operating systems, and which framework versions. That metadata enables the compatibility checks the new tooling performs before anything.
Security: Kernels Have Full Process Privileges #
Hugging Face is direct about the threat model: “Kernels run native code with the same privileges as the Python process that loads them — a malicious kernel can do real harm.” A compromised kernel is worse than a malicious pickle file because it runs as compiled native code with no interpreter sandbox.
The new security model has two layers. First, a trusted publisher list: by default, the kernels
package only loads kernels from organizations vetted and approved by Hugging Face. from any other source requires explicitly passing trust_remote_code=True
. Second, kernel artifacts are now signed using Sigstore cosign with ephemeral keys — no long-lived signing credential sits around waiting to be stolen. Signatures are recorded in Rekor, Sigstore’s transparency log, for auditability. Any developer can verify a kernel now with kernels verify-signature
.
Automatic signature verification on load is not yet live, but the infrastructure is in place. Run kernels verify-signature
in your CI pipelines now as an audit step — do not wait for it to become a hard gate.
Cleaner Tooling: kernels vs kernel-builder #
The update separates what was previously a tangled CLI into two distinct packages. kernels
handles and consuming kernels. kernel-builder
handles building, benchmarking, and publishing. Teams that only consume kernels no longer pull in the full build toolchain as a dependency. Both packages are leaner as a result — and the separation is the right call. The old design forced everyone to install build infrastructure whether they needed it or not.
Agentic Kernel Development Is Now a First-Class Workflow #
The more forward-looking addition is the agentic build workflow. Running kernels skills add
installs an agent skill compatible with Claude, Codex, and OpenCode, teaching the agent how to write and optimize production CUDA kernels. The kernel-builder
CLI is intentionally non-interactive with machine-readable output, so agents can scaffold a kernel project, write code, benchmark it, and iterate without human handoffs.
This is not a demo workflow. AI agents have been writing and publishing GPU kernels since early 2026, and Hugging Face’s agent skills for CUDA kernels have been available since February. The July update gives the publication side a proper signed-artifact destination. The loop is now complete: agent writes kernel, benchmarks it, and publishes a signed, metadata-tagged artifact to the Hub.
Multi-Framework Support Expands #
Two framework additions are worth noting. The Torch Stable ABI lets developers target a specific Torch version and get forward compatibility for roughly two years — write once for Torch 2.9 and the same kernel works on any version through approximately Torch 3.1. Apache TVM FFI is now supported as a tech preview, providing a standard C ABI that allows kernels to run across PyTorch, JAX, and CuPy via DLPack. The TVM FFI path is still in tech preview — build options may change — but the direction is clear: one kernel, multiple frameworks.
What to Do Now #
Audit your kernel code— identify any model-type Hub repos your stack currently pulls kernels from** Migrate to the kernel repo type**— follow theofficial Kernels documentationto move existing artifacts to the new formatUpdate CI/CD pipelines— anything referencing old model-type kernel repos will break** Run**on any third-party kernels loaded in productionkernels verify-signature
Review— add the trusted publisher check to your security review process for any kernel outside the HF vetted listtrust_remote_code=True
usages
The signing infrastructure and trusted publisher model are the right moves for an ecosystem where custom kernels have been a silent supply chain liability. The breaking change is painful, but the alternative — unverified native code running at full process privileges in your inference servers — is worse. Migrate now, before a dependency update does it for you at the wrong moment.