🤗 Kernels: Major Updates

🤗 Kernels：重大更新

返回文章列表

[-1

]

[0

2026年7月6日发布

GitHub上更新

点赞

1

[

Sayak Paul

sayakpaul

关注

Daniël de Kok

danieldk

David Holtz

drbh

在我们之前的博文（从零到GPU）中，我们介绍了🤗 Kernels项目，该项目旨在标准化自定义内核的打包、分发和使用方式。我们希望该项目能够实现无摩擦且安全，同时尽可能地与Hub兼容。

在过去几个月中，我们朝着这个目标努力。在这个过程中，我们几乎完全重新设计了该项目。本文将总结我们已发布的重大更新以及未来计划。

目录

• Kernels – 一种新的仓库类型
• 安全性提升
• CLI工具全面升级
• 更广泛的框架和后端支持
• 代理式内核开发的基础
• 其他改进
• 结论

Kernels – 一种新的仓库类型

我们在Hub上引入了一种名为"kernel"的新仓库类型。这使我们能够满足具有计算相关特殊需求的用户。例如，用户可以直观了解某个内核支持的加速器、操作系统和后端版本：

内核页面：kernels-community/flash-attn3

您可以在以下链接浏览Hub上所有可用内核：https://huggingface.co/kernels

将这些内核作为Hub的一等公民，也对AI生态系统有益。用户现在可以跨内核、模型和使用它们的应用程序查看趋势。内核对用户来说也更容易被发现。

安全性提升

内核以与加载它们的Python进程相同权限运行原生代码，因此恶意内核可能造成实际危害。因此，安全性一直是Kernels项目的核心关注点。

这就是我们早期专注于可重复性的重要原因：您应该能够自行重新编译内核并验证其是否与公开的源代码匹配。我们使用Nix来实现这一点，因为它通过构建配方的密封评估和强隔离沙箱保持构建过程的纯净性。我们进一步通过将源代码的Git SHA1嵌入内核本身来增强来源可追溯性。

在最近几个月中，我们增加了更多防御层：可信内核发布者和代码签名。

可信内核发布者

随着新仓库类型的引入，我们同时推出了“可信发布者”机制。由于内核以与使用它们的Python进程相同权限在机器上执行代码，攻击者可能通过上传恶意内核并诱使您使用该内核来危害机器。为了帮助您避免此类恶意内核，内核包现在默认只会加载可信发布者发布的内核。可信发布者是指被社区信任以善意行事的组织。

我们仍然支持从非可信发布者组织或用户加载内核，但您必须在从Hub加载内核时显式使用trust_remote_code参数进行授权：

from
kernels
import
get_kernel

kernel_module = get_kernel(  
   “Atlas-Inference/gdn”, version=
1
, trust_remote_code=
True
)

默认情况下，用户无法在Hub上发布内核仓库。他们必须申请成为内核发布者。用户和组织可以通过账户设置请求访问权限。这使我们能够逐个案例处理这些请求。

我们新增的安全措施是代码签名。代码签名可以防范攻击者利用被入侵的可信发布者Hub凭证，将恶意内核上传到内核仓库的场景。在代码签名机制中，内核会使用仅内核开发者知晓的私钥进行签名，并通过公开可获取的公钥进行验证。在Hub凭证被入侵的场景中，攻击者无法对恶意内核进行签名，因为他们无法获取用于签名的私钥。

为进一步提升安全性，我们使用Sigstore的cosign工具，通过临时私钥进行签名。由于这些签名密钥仅在有限时间内有效，即使私钥泄露，攻击者通常也无法使用。我们还验证内核是否由可信GitHub仓库中的可信GitHub工作流签名。

内核签名功能已由kernel-builder支持，我们提供了kernels verify-signature工具用于验证内核。目前加载内核时暂不验证签名，因为我们希望在全面部署前对这一新功能进行更多测试。关于如何为自己的内核设置代码签名的初步说明，请参阅kernels 0.16.0版本发布说明：https://github.com/huggingface/kernels/releases/tag/v0.16.0

改进后的命令行工具

此前，kernels和kernel-builder之间存在大量工具功能的耦合。我们已对两者命令行工具的职责划分进行了优化。其核心理念是：kernels作为加载和准备内核使用的库，不应包含任何与"构建"内核相关的功能。

因此，目前kernels和kernel-builder都变得更加精简且功能明确。有关更多细节，请参阅文档：

• kernels CLI
• kernel-builder CLI

更广泛的框架和后端支持 {#more-coverage-of-frameworks-and-backends}

我们已扩展了对框架的支持，最显著的变更包括：

• 我们为kernels和kernel-builder新增了对Torch Stable ABI的支持。Torch Stable ABI允许内核开发者针对特定Torch版本或在其发布后约两年内的任意版本进行开发。例如，针对Torch 2.9 Stable ABI的内核可支持Torch >= 2.9。

• Apache TVM FFI成为继Torch之后首个获得支持的框架。TVM FFI是专为内核设计的标准ABI接口，可与PyTorch、Jax和CuPy等其他框架实现互操作。这使内核开发者能够开发跨框架运行的内核。

代理式内核开发的基础架构

kernel-builder和kernels共同支撑着代理式内核开发的兴起，该模式通过代理从零开始生成（优化后的）内核。两者协同支持代理完成内核的框架搭建、构建、基准测试和迭代优化的完整工作流。

目前代理式内核开发仍处于早期阶段，合适的开发循环将持续演进。这使得简单清晰的基础架构尤为重要，工具应易于集成到用户选择的任意代理工作流或框架中。

kernel-builder 有助于规范内核源代码的搭建和使用方式，以实现可重复的构建过程。这为代理提供了可预测的项目布局和可重复的工作流程。其 CLI 也针对代理进行了优化。例如，这意味着非交互式命令和易于代理程序化解析的输出。为此，我们还提供了特定于后端的技能，帮助代理应对不同后端的特殊性。这些技能可以捕获特定于后端的工具链、编译路径和性能考量。

成功构建内核并不是唯一目标，我们需要确保它在目标硬件上相比基准有实际的加速效果。因此，成功的构建只是第一步验证步骤。通常，目标硬件可能包含许多不同的加速器，甚至同一加速器家族的不同代际产品。

这使得在相关情况下跨硬件供应商和代际评估结果变得尤为重要。我们与 HF Jobs 的紧密集成可以简化这一基准测试流程。代理可以利用这一集成运行基准测试套件，收集性能结果，并与定义的基准进行对比。

通过这种方式，代理可以在不同硬件配置上运行测试，以获得对生成内核性能的可靠反馈，并识别需要改进的地方。这些反馈可以指导下一步的优化迭代。

以下是一些经过代理增强的内核示例。这些示例展示了可以通过此工作流程开发和评估的内核类型：

• https://huggingface.co/kernels/drbh/yamoe

• https://huggingface.co/kernels/sayakpaul/qk-norm-rope

其他信息

环境设置

使用 kernel-builder 构建内核的环境设置可能令人望而生畏。为了简化用户操作，我们现在提供了一键安装脚本，用于快速设置环境。如果您倾向于使用临时实例，建议遵循我们的 Terraform 设置指南。

内核系统卡片

内核构建完成后，我们会为每个内核创建系统卡片，以公开有用信息，包括如何使用它及其暴露的接口。当内核推送到 Hub 时，该系统卡片将成为内核的前置信息：

内核系统卡片 kernels-community/flash-attn3

我的系统是否兼容该内核？

这是一个需要多次询问以更好地规划的问题。为此，请使用 has_kernel() 方法：

from
kernels
import
has_kernel
print
(has_kernel(
"kernels-community/activation"
, version=
1
))

它将返回一个布尔值。如果您需要了解某个内核不被支持的具体原因，请使用 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}
)"
)

它将输出（具体取决于您使用的机器）：

torch212-cxx11-cu130-aarch64-linux: 兼容  
torch210-cu128-x86_64-windows: 被拒绝 (CPU (x86_64) 与系统 CPU (aarch64) 不匹配)  
torch211-cu128-x86_64-windows: 被拒绝 (CPU (x86_64) 与系统 CPU (aarch64) 不匹配)  
torch212-metal-aarch64-darwin: 被拒绝 (OS (darwin) 与系统 OS (linux) 不匹配)  
torch211-metal-aarch64-darwin: 被拒绝 (OS (darwin) 与系统 OS (linux) 不匹配)  
torch210-metal-aarch64-darwin: 被拒绝 (OS (darwin) 与系统 OS (linux) 不匹配)  
torch29-metal-aarch64-darwin: 被拒绝 (OS (darwin) 与系统 OS (linux) 不匹配)  
…

manylinux_2_28 支持改进

Kernel-builder 从一开始就几乎针对 manylinux_2_28 进行了优化。我们过去通过使用现代的 gcc 工具链（编译时使用 glibc 2.28）来实现 manylinux 支持。为了避免与旧版 libstdc++ 的兼容性问题，我们曾静态链接了 libstdc++。

然而，这种方法最近引发了一些问题。部分 libstdc++ 功能依赖全局初始化。当多个 libstdc++ 版本同时存在时（例如 PyTorch 动态链接的 libstdc++ 和内核静态链接的 libstdc++），可能导致数据损坏。近期部分内核使用了触发全局初始化的功能（如 C++ 正则表达式），从而引发数据损坏、段错误等异常。

为解决此问题，现在内核会动态链接 libstdc++。为确保与旧版 libstdc++ 的兼容性，我们现已使用官方 manylinux_2_28 工具链编译内核。

结论

Kernels 项目的目标是为内核开发者和自定义内核用户都提供服务。我们始终欢迎社区反馈以改进项目。欢迎积极参与贡献！

致谢：感谢 Aritra 对本文的审阅。

更多博客文章

kernels

kernels-community

guide

从零到 GPU：构建和扩展生产级 CUDA 内核指南

104

2025 年 8 月 18 日

cuda

amd

为 AMD MI300 创建自定义内核

54

2025 年 7 月 9 日

社区

编辑

预览

可通过拖拽、粘贴或点击此处上传图片、音频和视频

点击此处上传图片

评论

· 注册或登录以发表评论