🤗 Kernels：重大更新

来源：https://huggingface.co/blog/revamped-kernels 返回文章 (https://huggingface.co/blog)

https://huggingface.co/login?next=%2Fblog%2Frevamped-kernels-

• Kernels – 一种新的仓库类型 (https://huggingface.co/blog/revamped-kernels#kernels–a-new-repository-type)
• 增强的安全性 (https://huggingface.co/blog/revamped-kernels#improved-security) - 可信的 Kernel 发布者 (https://huggingface.co/blog/revamped-kernels#trusted-kernel-publishers) - Kernel 签名 (https://huggingface.co/blog/revamped-kernels#kernel-signing)
• 重塑的命令行工具 (https://huggingface.co/blog/revamped-kernels#revamped-clis)
• 更广泛的框架与后端覆盖 {#more-coverage-of-frameworks-and-backends} (https://huggingface.co/blog/revamped-kernels#more-coverage-of-frameworks-and-backends-more-coverage-of-frameworks-and-backends)
• 为智能体驱动 Kernel 开发奠定基础 (https://huggingface.co/blog/revamped-kernels#foundation-for-agentic-kernel-development)
• 其他 (https://huggingface.co/blog/revamped-kernels#misc) - 环境设置 (https://huggingface.co/blog/revamped-kernels#environment-setup) - Kernel 的系统卡片 (https://huggingface.co/blog/revamped-kernels#system-card-for-kernels) - 我的系统兼容某个 Kernel 吗？ (https://huggingface.co/blog/revamped-kernels#is-a-kernel-compatible-on-my-system) - 改进的 manylinux_2_28 支持 (https://huggingface.co/blog/revamped-kernels#improved-manylinux228-support)
• 结论 (https://huggingface.co/blog/revamped-kernels#conclusion)

在之前的文章《从零到 GPU》 (https://huggingface.co/blog/kernel-builder) 中，我们介绍了 🤗 Kernels 项目，旨在规范化自定义 kernel 的打包、分发和使用方式。我们希望这个项目既流畅又安全，同时尽可能与 Hub 保持友好。

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

目录

• Kernels – 一种新的仓库类型 (https://huggingface.co/blog/revamped-kernels#kernels–a-new-repository-type)
• 增强的安全性 (https://huggingface.co/blog/revamped-kernels#improved-security)
• 重塑的命令行工具 (https://huggingface.co/blog/revamped-kernels#revamped-clis)
• 更广泛的框架与后端覆盖 (https://huggingface.co/blog/revamped-kernels#more-coverage-of-frameworks-and-backends)
• 为智能体驱动 Kernel 开发奠定基础 (https://huggingface.co/blog/revamped-kernels#foundation-for-agentic-kernel-development)
• 其他 (https://huggingface.co/blog/revamped-kernels#misc)
• 结论 (https://huggingface.co/blog/revamped-kernels#conclusion)

https://huggingface.co/blog/revamped-kernels#kernels–a-new-repository-typeKernels – 一种新的仓库类型

我们在 Hub 上引入了一种名为 “kernel” 的新仓库类型 (https://huggingface.co/kernels)。这使我们能够满足用户对计算相关特性的需求。例如，用户可以了解某个 kernel 支持哪些加速器、操作系统和后端版本：

Flash Attention 3 Kernel 页面Kernel 页面：kernels-community/flash-attn3 (https://huggingface.co/kernels/kernels-community/flash-attn3)用户可以在 Hub 上浏览所有可用的 kernel：https://huggingface.co/kernels。

将这些 kernel 提升为 Hub 的一等公民也有利于 AI 生态系统。用户现在可以看到 kernel、模型以及使用它们的应用之间的趋势。Kernel 对用户来说变得更易发现。

https://huggingface.co/blog/revamped-kernels#improved-security增强的安全性

Kernel 以与加载它们的 Python 进程相同的权限运行原生代码，因此恶意 kernel 可能会造成实际损害。因此，安全性一直是 Kernels 项目的重中之重。

这就是我们早期着重于可重现性的原因：您应该能够自行重新编译一个 kernel，并验证其与公开源码一致。我们使用 Nix 来实现这一点，因为它通过封闭式评估构建配方和强隔离沙箱来保持构建的纯净。我们通过将源 Git SHA1 嵌入到 kernel 本身来进一步提高可追溯性。

最近几个月，我们增加了额外的防御层：可信 kernel 发布者和代码签名。

https://huggingface.co/blog/revamped-kernels#trusted-kernel-publishers可信的 Kernel 发布者

随着新仓库类型的引入，我们还引入了“可信发布者”。由于 kernel 在与使用它们的 Python 进程相同的权限下在机器上执行代码，攻击者可以通过上传恶意 kernel 并诱使您使用该 kernel 来破坏机器。为了帮助您避免此类恶意 kernel，kernels 包现在默认只加载 可信发布者 的 kernel。可信发布者是指社区信任其诚信行事的组织。

我们仍然支持加载来自非可信发布者组织或用户的 kernel，但您必须在从 Hub 加载 kernel 时使用 trust_remote_code 参数显式选择加入：

`` from kernels import get_kernel

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

默认情况下，用户不能在 Hub 上发布 kernel 仓库。他们必须申请成为 kernel 发布者。用户和组织可以从其账户设置中申请访问权限。这让我们有时间逐案处理这些请求。

https://huggingface.co/blog/revamped-kernels#kernel-signingKernel 签名

我们正在添加的另一个安全层是代码签名。代码签名可防止以下场景：攻击者从一个其 Hub 凭证已泄露的可信发布者的 kernel 仓库上传恶意 kernel。在代码签名中，kernel 使用只有 kernel 开发者知道的私钥进行签名，并使用公钥进行验证，公钥是公开可用的。在 Hub 凭证泄露的情况下，攻击者无法对恶意 kernel 进行签名，因为他们没有签名所需的私钥。

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

Kernel 签名已得到 kernel-builder 的支持，并且我们提供了 kernels verify-signature 来验证 kernel。Kernels 在加载 kernel 时尚未验证签名，因为我们希望在完全推广之前更多测试这一新功能。关于为自有 kernel 设置代码签名的初步说明，请参见 kernels 0.16.0 发布说明：https://github.com/huggingface/kernels/releases/tag/v0.16.0。

https://huggingface.co/blog/revamped-kernels#revamped-clis重塑的命令行工具

以前，许多实用工具混合在 kernels 和 kernel-builder 之间。我们重新明确了 kernels 和 kernel-builder 的命令行工具之间的职责分离。这里的思维模型是：kernels 是一个用于加载和准备 kernel 以使用的库，因此它不应包含任何与“构建”kernel 相关的内容。

因此，kernels 和 kernel-builder 现在都更加精简和专注。请参考文档了解更多信息：

• kernels 命令行工具 (https://huggingface.co/docs/kernels/en/cli)
• kernel-builder 命令行工具 (https://huggingface.co/docs/kernels/en/builder-cli)

https://huggingface.co/blog/revamped-kernels#more-coverage-of-frameworks-and-backends-more-coverage-of-frameworks-and-backends更广泛的框架与后端覆盖 {#more-coverage-of-frameworks-and-backends}

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

• 我们为 kernels 和 kernel-builder 添加了对 Torch Stable ABI 的支持。Torch Stable ABI 允许 kernel 开发者针对特定 Torch 版本或其之后发布的大约两年内的任何版本进行开发。例如，针对 Torch 2.9 Stable ABI 的 kernel 支持 Torch >= 2.9。
• Apache TVM FFI 是除 Torch 之外首个受支持的框架。TVM FFI 是一个标准化的 ABI，用于 kernel 与其他框架（如 PyTorch、Jax 和 CuPy）互操作。这允许 kernel 开发者制作可在多个框架上运行的 kernel。

https://huggingface.co/blog/revamped-kernels#foundation-for-agentic-kernel-development为智能体驱动 Kernel 开发奠定基础

kernel-builder 和 kernels 补充了智能体驱动 kernel 开发的兴起，其中利用智能体从头开始生成（优化后的）kernel。两者共同支持一个工作流，其中智能体可以搭建、构建、基准测试和迭代优化 kernel。

智能体驱动的 kernel 开发仍处于起步阶段，正确的开发循环将继续演变。这使得简单清晰的基础知识尤为重要，工具应易于组合到用户选择的任何智能体工作流或框架中。

kernel-builder 有助于强制执行一种结构，规定 kernel 源码应该如何搭建和使用以执行可重现构建。这为智能体提供了可预测的项目布局和可重复的工作流程。其命令行工具也设计为对智能体友好 (https://huggingface.co/blog/is-it-agentic-enough)。例如，这意味着非交互式命令和输出，使智能体更容易以编程方式解释。为此，我们还有后端特定技能 (https://huggingface.co/docs/kernels/en/cli-skills)，以帮助智能体导航不同后端的特性。这些技能可以捕获后端特定的工具链、编译路径和性能考虑。

成功构建一个 kernel 并非唯一目标，我们还需要确保它在目标硬件上提供相对于基线的实际加速。因此，成功的构建只是第一步验证。通常，目标硬件可能包括许多不同的加速器，甚至同一加速器的不同系列。

这使得在相关硬件供应商和代际之间评估结果变得重要。我们与 HF Jobs (https://huggingface.co/docs/kernels/en/builder/github-actions) 的紧密集成可以使基准测试过程变得容易。智能体可以使用此集成运行基准测试套件，收集性能结果，并将其与定义的基线进行比较。

这样，智能体可以在不同硬件配置上运行测试，以获得对生成 kernel 性能的可靠反馈，并确定需要做什么。然后，该反馈可以指导下一次优化迭代。

以下是一些智能体增强 kernel 的示例。这些示例说明了可以通过此工作流开发和评估的 kernel 类型：

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

https://huggingface.co/blog/revamped-kernels#misc其他

https://huggingface.co/blog/revamped-kernels#environment-setup环境设置

使用 kernel-builder 构建 kernel 的环境设置可能令人望而生畏。为了简化用户操作，我们现在提供一个安装脚本 (https://huggingface.co/docs/kernels/en/builder/writing-kernels#quick-install)，一键设置环境。如果您更喜欢使用临时实例，我们的 Terraform 设置指南 (https://github.com/huggingface/kernels/tree/main/terraform) 值得参考。

https://huggingface.co/blog/revamped-kernels#system-card-for-kernelsKernel 的系统卡片

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

Kernel 的系统卡片kernel 的系统卡片 for kernels-community/flash-attn3 (https://huggingface.co/kernels/kernels-community/flash-attn3)

https://huggingface.co/blog/revamped-kernels#is-a-kernel-compatible-on-my-system我的系统兼容某个 Kernel 吗？

这是一个您可能会多次询问以更好规划的问题。使用 has_kernel() (https://huggingface.co/docs/kernels/main/en/api/kernels#kernels.has_kernel) 方法：

`` from kernels import has_kernel

print(has_kernel(“kernels-community/activation”, version=1)) ``

它返回一个 bool 值。如果您需要更多关于为何某个 kernel 不受支持的解释，请使用 get_kernel_variants() (https://huggingface.co/docs/kernels/main/en/api/kernels#kernels.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: compatible torch210-cu128-x86_64-windows: rejected (CPU (x86_64) does not match system CPU (aarch64)) torch211-cu128-x86_64-windows: rejected (CPU (x86_64) does not match system CPU (aarch64)) torch212-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux)) torch211-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux)) torch210-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux)) torch29-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux)) ...

https://huggingface.co/blog/revamped-kernels#improved-manylinux_2_28-support改进的 manylinux_2_28 支持

Kernel-builder 几乎从一开始就针对 manylinux_2_28。我们之前通过使用使用 glibc 2.28 编译的现代 gcc 工具链来针对 manylinux。为了避免与旧版本 libstdc++ 的兼容性问题，我们静态链接了 libstdc++。

然而，这种方法最近导致了一些问题。某些 libstdc++ 功能使用全局初始化。当多个版本 libstdc++ 同时发挥作用时，例如 PyTorch 动态链接的 libstdc++ 和 kernel 静态链接的 libstdc++，这可能导致数据损坏。最近的一些 kernel 使用了触发全局初始化的功能（例如 C++ 正则表达式），导致此类数据损坏，进而引发段错误和其他问题。

为了解决这个问题，kernel 现在动态链接 libstdc++。为了确保与旧版本 libstdc++ 的兼容性，我们现在使用官方的 manylinux_2_28 工具链编译 kernel。

https://huggingface.co/blog/revamped-kernels#conclusion结论

我们通过 Kernels 项目旨在服务 kernel 开发者和自定义 kernel 的用户。我们始终热切期待社区反馈，以便我们进行改进。请随时贡献！

致谢：感谢 Aritra (https://huggingface.co/blog/ariG23498) 审阅本文。