Hugging Face：Kernels の主要アップデート

記事一覧に戻る

• Kernels – 新しいリポジトリタイプ
• 強化されたセキュリティ：信頼できるカーネルパブリッシャー
• カーネル署名
• 刷新された CLI
• フレームワークとバックエンドの対応範囲拡大 {#more-coverage-of-frameworks-and-backends}
• エージェント型カーネル開発のための基盤
• その他：環境設定
• カーネル用のシステムカード
• 私のシステムでカーネルは互換性がありますか？
• manylinux_2_28 サポートの改善
• 結論

私たちの 前回の投稿（ゼロから GPU へ） で、カスタムカーネルのパッケージ化、配布、利用方法を標準化する 🤗 Kernels プロジェクトを紹介しました。私たちは、このプロジェクトが摩擦なく安全でありながら、Hub にできるだけ親和性が高いものになることを目指しています。

過去数ヶ月間、私たちはこの目標に向けて取り組んできました。その過程で、プロジェクトの設計をほぼ完全に再構築することになりました。本稿では、私たちが実装した主要なアップデートと今後の予定についてまとめます。

目次

• Kernels – 新しいリポジトリタイプ

• 強化されたセキュリティ

• 刷新された CLI

• フレームワークとバックエンドの対応範囲拡大

• エージェント型カーネル開発のための基盤

• その他

• 結論

Kernels – 新しいリポジトリタイプ

私たちは、Hub に「kernel」と呼ばれる新しいリポジトリタイプを導入しました。これにより、計算資源に関する特定のニーズを持つユーザーに対応できるようになりました。例えば、ユーザーは特定のカーネルでサポートされているアクセラレーター、オペレーティングシステム、バックエンドバージョンの概要を把握することができます。

image

カーネルページ: kernels-community/flash-attn3

Hub 上で利用可能なすべてのカーネルは、こちらから閲覧できます: https://huggingface.co/kernels。

これらのカーネルを Hub のファーストクラス・シチズン（主要な要素）として扱うことは、AI エコシステムにとっても恩恵をもたらします。ユーザーは now、カーネル、モデル、およびそれらを利用するアプリケーション全体にわたるトレンドを確認できるようになりました。これにより、カーネルがユーザーにとってより発見しやすくなります。

セキュリティの強化

カーネルは、それを読み込む Python プロセスと同じ特権でネイティブコードを実行するため、悪意のあるカーネルは実際に重大な被害を与える可能性があります。したがって、セキュリティは Kernels プロジェクトにおいて常に最優先事項です。

そのため、私たちは初期段階から再現性-focused に取り組んできました：誰でも自分でカーネルを再コンパイルし、それが公開されているソースコードと一致することを確認できるべきだからです。これを可能にするために Nix を使用しています。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。

刷新された CLI

以前は、kernels と kernel-builder の間で多数のユーティリティが混在していました。これらに対し、kernels の CLI と kernel-builder の CLI の間に明確な責任分離を確立しました。ここで重要なのは、kernels はカーネルを読み込み、使用準備を整えるためのライブラリであるという概念モデルです。したがって、「ビルド」に関する機能は含まれるべきではありません。

この結果、kernels と kernel-builder の両方がより軽量で目的に特化したものとなりました。詳細については、以下のドキュメントを参照してください：

• kernels CLI

• kernel-builder CLI

フレームワークとバックエンドの対応範囲拡大 {#more-coverage-of-frameworks-and-backends}

フレームワークへのサポート範囲を拡張しました。最も目に見える変更点は次の通りです：

• Torch の安定 ABI（Application Binary Interface）へのサポートを kernels および kernel-builder に追加しました。Torch の安定 ABI を利用することで、カーネル開発者は特定の Torch バージョン、あるいはその後にリリースされたバージョンを対象に、約 2 年間にわたり対応することが可能になります。例えば、Torch 2.9 の安定 ABI を対象とするカーネルは、Torch >= 2.9 に対応します。

• Apache TVM FFI は、Torch に次いでサポート対象となった最初のフレームワークです。TVM FFI は、PyTorch、Jax、CuPy などの他のフレームワークと相互運用するカーネル向けの標準化された ABI です。これにより、開発者は複数のフレームワーク間で動作するカーネルを作成できるようになります。

エージェント型カーネル開発の基盤

kernel-builder と kernels は、エージェントを利用してゼロから（最適化された）カーネルを生成するという、エージェント型カーネル開発の台頭を支えるものです。両者は、エージェントがカーネルの骨組み作成、ビルド、ベンチマーク、そして反復的な最適化を行うワークフローをサポートします。

エージェント型カーネル開発はまだ初期段階にあり、適切な開発ループは引き続き進化していくでしょう。そのため、ツールが人々が選択するあらゆるエージェントワークフローやフレームワークに容易に組み合わせられるよう、シンプルで明確な基盤が特に重要となります。

kernel-builder は、カーネルソースコードをどのように構成し、再利用可能なビルドを実行するために使用すべきかという構造を強制する役割を果たします。これにより、エージェントは予測可能なプロジェクトレイアウトと反復可能なワークフローの中で動作できるようになります。その CLI もまた エージェント最適化 されることを意図しています。例えば、これは非対話型のコマンドや、エージェントがプログラムで直感的に解釈できる出力を意味します。この目的のために、私たちは バックエンド固有のスキル も用意しており、これによりエージェントは異なるバックエンドの個性的な特性をナビゲートできるようになります。これらのスキルは、バックエンド固有のツールチェーン、コンパイルパス、およびパフォーマンスに関する考慮事項を捉えることができます。

カーネルを正常に構築することだけが目標ではなく、ターゲットハードウェア上でベースラインに対して実際の速度向上をもたらすことを保証する必要があります。したがって、成功したビルドは単なる最初の検証ステップに過ぎません。通常、このターゲットハードウェアには多くの異なるアクセラレーター、さらには同じアクセラターファミリー内の異なる世代が含まれることがあります。

これは、関連するハードウェアベンダーや世代間で結果を評価することが重要であることを意味します。私たちの HF Jobs との緊密な統合 は、このベンチマークプロセスを容易にします。エージェントはこの統合を使用してベンチマークスイートを実行し、パフォーマンス結果を収集し、定義されたベースラインと比較することができます。

このようにして、エージェントは異なるハードウェア構成間でテストを実行し、生成されたカーネルのパフォーマンスに関する信頼性の高いフィードバックを得て、何をすべきかを特定できます。そのフィードバックは、次の最適化イテレーションを導く情報として活用されます。

以下に、エージェント支援型カーネルの例を示します。これらは、本ワークフローを通じて開発・評価可能なカーネルの種類を示しています：

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

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

雑多な項目

環境設定

kernel-builder を用いてカーネルを構築するための環境設定は、時に daunting（畏怖すべき）と感じられるかもしれません。ユーザーにとってこれを容易にするため、ワンクリックで環境を設定できる インストールスクリプト を用意しました。エフェメラルインスタンスでの作業を好まれる場合は、Terraform 設定ガイド もご参照ください。

カーネル用のシステムカード

カーネルが構築された後、各カーネルに対してシステムカードを作成し、その使用方法や公開されているインターフェースなど、有用な情報を開示します。カーネルを Hub にプッシュすると、このシステムカードがカーネルのフロントマター（前書き情報）となります：

image

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}: 互換性あり")

else:

print(f"{name}: 拒否されました ({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 をターゲットとしてきました。以前は、glibc 2.28 でコンパイルされた最新の gcc ツールチェーンを使用して manylinux をターゲットにしていました。libstdc++ の古いバージョンとの互換性問題を回避するため、libstdc++ は静的リンクされていました。

しかし、このアプローチが最近いくつかの問題を引き起こしました。一部の libstdc++ 機能はグローバル初期化を使用します。これにより、複数の libstdc++ バージョンが関与した場合にデータが破損する可能性があります。具体的には、PyTorch で動的にリンクされる libstdc++ と、カーネルで静的にリンクされる libstdc++ が混在する場合です。最近のいくつかのカーネルでは、グローバル初期化をトリガーする機能（例えば C++ の正規表現）を使用しており、これがデータ破損を引き起こし、segfault やその他の問題の原因となっています。

この問題を解決するため、カーネルは now libstdc++ を動的にリンクするようになりました。古い libstdc++ バージョンとの互換性を確保するために、公式の manylinux_2_28 ツールチェーンを使用してカーネルをコンパイルしています。

結論

Kernels プロジェクトの目標は、カーネル開発者とカスタムカーネルの利用者の両方にサービスを提供することです。私たちは、改善のためのコミュニティからのフィードバックを常に歓迎しています。遠慮なくご協力ください！

*謝辞：本稿のレビューをいただいた Aritra 氏に感謝いたします。*