Hugging Face、旧式kernelモデルリポジトリを閉鎖――未移行の推論プログラムが即座に動作不能になる可能性

Hugging Faceは、`kernels-community/flash-attn3`など、通常の「model」タイプとして作成された旧式のkernelリポジトリの削除を開始した。これは単なるHubページの整理ではない。旧版の`kernels`、固定されたrevision、または旧リポジトリのパスから直接バイナリを取得している推論イメージでは、再ビルド、キャッシュの消去、新規ノードへのスケールアウト時になって初めて、リソースが存在しないことが判明する可能性がある。すでにキャッシュされているkernelは当面動作する可能性があるものの、再現可能なデプロイとはみなせない。

新しいアーキテクチャでは、CUDA、Metal、XPUなどの演算kernelが、独立したkernel repository typeへと格上げされた。リポジトリカードには、OS、アクセラレータ、PyTorch、ABIの互換性が表示される。`kernels` 0.15.1以降では、`get_kernel()`に`version`を明示的に渡すことも必須となった。破壊的変更がインターフェースに加えられた場合、同一の呼び出しが気付かないうちに異なるAPIを取得するのではなく、メンテナーがメジャーバージョンを引き上げる必要がある。オフライン環境では`HF_HUB_OFFLINE=1`を設定できるが、必要なバージョンがすでにローカルキャッシュに保存されていることが前提となる。

セキュリティも今回の移行におけるもう一つの重要な柱だ。kernelはPythonプロセスと同じ権限で実行されるネイティブコードであり、新しいクライアントはデフォルトで信頼できる公開者のものだけをロードする。それ以外のソースについては、`trust_remote_code=True`を明示的に設定する必要がある。ビルドツールは、ファイルハッシュとSigstore署名をメタデータへ記録できるようになっており、署名検証を手動で実行することも可能だ。しかし、0.16のロード処理は、署名が検証されていないkernelをまだ自動的には拒否しない。このため、「新しいkernel Hubから取得した」ことを、完全なソフトウェアサプライチェーン検証と同一視することはできない。

エンジニアリングチームは、イメージとロックファイルに含まれる旧Hub URLを検索し、クライアントをアップグレードしたうえで、kernelごとにバージョンを固定し、キャッシュのないクリーンなコンテナで起動テストを再実行する必要がある。また、社内ミラーがkernel repository typeのメタデータを保持しているかも確認しなければならない。バイナリファイルだけをコピーすると、互換性や来歴に関する情報が失われる可能性がある。