AI解説

公式サイト: https://project-hami.io/ ／ GitHub: https://github.com/Project-HAMi/HAMi 情報源: 査読論文ではなく OSS プロジェクト。公式サイト（project-hami.io）と GitHub README を情報源に記述。アーキテクチャ全体・対応デバイス・スケジューリング方針・Pod のリソース名（nvidia.com/gpu / nvidia.com/gpumem）は公式記述で確認。一方、コンテナ内強制を担う HAMi-core（libvgpu）の CUDA API フック等の内部実装の詳細は公式 README では薄く、本ノートでは機能レベルの記述に留め、未確認の細部は記していない。

一言で

Kubernetes 上で GPU（および各種 AI アクセラレータ）を「丸ごと1枚」単位ではなく分割（1/2, 1/4, …, 1/N）して共有させる仮想化ミドルウェア。メモリと計算（コア）にハードな上限・隔離をかけつつ、複数ワークロードを少ない物理デバイスに詰め込んで稼働率を上げる。NVIDIA だけでなく Huawei Ascend・Cambricon など多ベンダのアクセラレータを同じ枠組みで扱える点が特徴。

背景・問題

Kubernetes の標準的な GPU 割り当ては 1 Pod に GPU を丸ごと 1 枚与える粒度しかなく、推論やノートブック的な軽いワークロードでは計算・メモリの大半が遊ぶ。結果、必要枚数が膨らみコストが上がる。問題は「GPU を細かく安全に分け合う仕組みが標準にない」こと。HAMi はここを、スライス（分割）＋ハード隔離＋スケジューリングで埋める。公式は「稼働率 50% → 100%」「GPU 4枚 → 2枚」「1 GPU あたり 1 → 2+ ワークロード」を効果例として掲げる。

何をするか（中核機能）

公式が掲げる柱は 4 つ：

1. GPU スライシング：1枚の物理アクセラレータを仮想パーティションに分け、複数ワークロードを同時に載せる。
2. 異種アクセラレータ管理：単一のワークフローで多ベンダのハードを統一的にスケジュール。対応は NVIDIA・AWS Neuron・Huawei Ascend・Cambricon・Enflame・Hygon・Iluvatar・Kunlunxin・Moore Threads・MetaX・Vaststream など 11+ ベンダ。
3. ハードなリソース隔離：メモリと計算（コア）の上限を実行時に強制。「ベストエフォート」ではなく精密な上限で、隣のワークロードに食われない。
4. Kubernetes ネイティブなスケジューリング：binpack（集約）／spread（分散）／topology-aware（トポロジ考慮）／dynamic MIG などの配置ポリシー。

加えて、QoS 制御（メモリ・コアのクォータで「より公平で安定した共有」）、ベンダ横断で統一された監視（Prometheus / OpenTelemetry メトリクス）、割り当て済みデバイス数・vGPU 利用率などのリアルタイム可視化を備える。

アーキテクチャ（どう動くか）

Pod の要求が入ってから、コンテナ内で隔離が効くまでが一本のパイプラインになっている。

• 入口（Request Entry）— MutatingWebhook：Pod の submission を割り込み（admission webhook）で捕まえ、仕様を書き換える。
• 制御面（Control Plane）— HAMi Scheduler / Scheduler Extender：filter → score → bind の流れで配置ポリシーを適用し、どのデバイスに載せるかを決定。割り当て結果は Pod の annotation に書き込まれる。
• データ面（Data Plane）— Device Plugin：Allocate() でコンテナにデバイスを割り当て、CDI（Container Device Interface）設定を注入する。
• コンテナ内強制 — HAMi-core（libvgpu）：コンテナ内に注入された仮想化レイヤが、メモリとコア利用の上限を実際に効かせる。これが「ハード隔離」の実体。

公式が示す処理フロー： Pod 投入 → HAMi mutating webhook → HAMi scheduler の filter / score / bind → 割り当てを Pod annotation に記録 → device plugin の Allocate() → コンテナランタイム環境 → HAMi の監視・メトリクス。

補足図（AI生成）: Pod 投入から MutatingWebhook → Scheduler（filter/score/bind）→ Device Plugin（Allocate / CDI 注入）→ コンテナ内 HAMi-core によるメモリ・コア隔離までの流れ。

Pod での要求のしかた（リソース名）

Pod の resources.limits に HAMi 独自のリソース名を書いて要求する。公式 README で確認できる例：

• nvidia.com/gpu：その Pod が要求する（v）GPU の枚数。HAMi 導入後、ノードに登録される nvidia.com/gpu の値は既定で vGPU の数になる（物理 GPU 要求とノード側の仮想 GPU 容量を区別）。
• nvidia.com/gpumem：割り当てる GPU メモリ量。例では「物理 NVIDIA GPU 1枚＋GPU メモリ 3 GiB」を nvidia.com/gpumem: 3000（MiB 単位）で要求している。

メモリだけでなく計算（コア）利用率にも上限をかけられる（柱③のハード隔離）。コア割合やメモリ割合を指定する追加のリソース名も用意されているが、本ノートでは公式 README 内で確認できた上記2つに絞って記す（その他の正確なリソース名表記は未確認）。

関連研究との関係（メモ）

• GaiaGPU（gu2018gaiagpu）：コンテナクラウドで GPU を分割共有する先行研究。HAMi はこの「コンテナ内でメモリ・計算を隔離して GPU を分け合う」系譜を、多ベンダ対応＋ Kubernetes ネイティブなスケジューラとして製品化・一般化したものと位置づけられる。
• ノートブック基盤の文脈では、JupyterHub / Kubernetes 上でノートブックに GPU を割り当てる際、1 ノートに GPU 丸ごとではなく分割で配る手段になりうる——軽い対話的ワークロードが多いノートブック環境と、HAMi の「稼働率を上げる分割」は相性がよい（自分の関心軸メモ）。

Q&A

（自分がAIに実際に質問したことだけを Q/A 形式で残す。まだなし。）

自分のコメント

（まだなし。）