推論基礎設施
Hugging Face Shuts Down Legacy Kernel Model Repositories, Potentially Breaking Unmigrated Inference Code Immediately
Starting September 13, Hugging Face is removing legacy compute kernels stored in regular model repositories. Users must upgrade `kernels` and switch to the new kernel repository type. The migration also requires explicit API versioning and restricts loading to trusted publishers, but signature verification during downloads is still not enabled automatically.
Hugging Face has begun removing legacy kernel repositories such as `kernels-community/flash-attn3` that were created using the standard "model" repository type. This is not merely a cleanup of Hub pages: inference images that still use older versions of `kernels`, pin a revision, or download binaries directly from legacy repository paths may suddenly discover that the resources no longer exist when they are rebuilt, their caches are cleared, or new nodes are added. Previously cached kernels may continue to work temporarily, but they should not be considered reproducible deployments.
The new architecture promotes CUDA, Metal, XPU, and other compute kernels to a dedicated kernel repository type. Repository cards list compatibility information for operating systems, accelerators, PyTorch, and ABIs. Starting with `kernels` 0.15.1, `get_kernel()` also requires an explicit `version` argument. When an interface introduces a breaking change, maintainers should increment the major version instead of allowing the same call to silently retrieve a different API. Offline environments can set `HF_HUB_OFFLINE=1`, provided that the required version is already available in the local cache.
Security is another major focus of the migration. Kernels are native code that runs with the same privileges as the Python process, and the new client loads code only from trusted publishers by default. Other sources require explicitly setting `trust_remote_code=True`. Build tools can now record file hashes and Sigstore signatures in metadata, and signature checks can be run manually. However, the loading path in version 0.16 does not yet automatically reject unverified signatures, so obtaining a kernel from the new kernel Hub should not be equated with complete software supply chain verification.
Engineering teams should search container images and lockfiles for legacy Hub URLs, upgrade their clients, pin a version for every kernel, and rerun startup tests in clean containers without cached artifacts. They should also verify that internal mirrors preserve metadata associated with the kernel repository type. Copying only the binaries may discard compatibility and provenance information.