Linuxカーネルは依然としてGPUを周辺機器と見なしている――そして、AIサーバー向けOSの再構築

更新：2026年8月。

オペレーティングシステムは、ある一つの目的のために生まれた。それは、高価なハードウェアと貪欲なプログラム群の間に立ち、誰一人としてすべてを独占しないようリソースを分配することだ。過去40年間、LinuxカーネルはCPU、メモリ、ディスク、ネットワークに対して、その役割を見事に果たしてきた。 しかし2026年、サーバーの中で最も高価な部品はもはやCPUではなく、筐体内部に収められた8枚のGPUであり、これらがコストの大部分を占めるようになった。そして、その最も高価な部品に対して、カーネルはほとんど管理を行っていないのが実情だ。

抽象的な4つの柱があるが、GPUはそれには含まれていない

リソースを真に「所有」するために必要な要素を挙げてください。 CPUの場合：プロセスという概念があり、公平なタイムシェアリングスケジューラがあり、サイクル単位でカウントするcgroupがあり、そして最も重要なのは「奪取」の権利があることです――クロックが爆発的に中断され、優先度の低いプロセスは許可を求めることなく即座にコアから追い出されます。 メモリについては：ページングがあり、物理メモリ以上の容量を要求できる仮想メモリがあり、メモリ不足時のソフトランディングを可能にするスワップがあります。ディスクとネットワークについては：inode、ソケット、キュー、およびポリシーがあります。

GPUの場合、そのリストにはほとんど何もありません。カーネルの観点から見れば、GPUは単なるデバイスファイルに過ぎません。プロセスが /dev/nvidia* を開き、ベンダー固有の ioctl コマンドをいくつか呼び出すと、あとはすべてドライバとファームウェア内部で処理されます。 カーネルは、どれだけの「カーネル」計算がキューに入っているのか、どれがまもなく完了するのか、どれが帯域幅をすべて消費しているのかを知りません。「このジョブは2分の1、あのジョブは1分の1」と指定するgpu.weightのようなものはありません。 VRAM用のスワップ領域もありません。GPUメモリが尽きれば、ジョブは終了、それきりです。また、プリエンプションもありません。3日間のトレーニングジョブは、たとえその後ろに緊急のジョブが並んでいても、3日間ずっと8つのGPUを独占し続けます。

アーキテクチャ上の影響は甚大です。ノードにはポリシーを配置する場所がないため、すべての決定は上位――Kubernetesやクラスタのスケジューラ――に委ねられてしまいます。 そのレイヤーはPodやラベルは認識できますが、GPUの内部までは見通せません。ただ「このマシンには8枚のGPUがあり、8枚を割り当てた。以上」と数えることしかできません。

経済コーナー：稼働率の1パーセントポイントあたりどれほどの価値があるのか

リソースがクラスタ単位でしか割り当てられない場合、余剰分は誰も利用しない。2026年初頭に発表された、2万以上のクラスタを対象としたKubernetesの最適化に関するレポートでは、衝撃的な数値が示された。GPUの平均利用率は約5％だった。 他のFinOps調査ではより控えめな数値が示されており、適切に管理されたクラスターでも通常20～40％程度とされています。 どの数値を基準にしても結論は同じだ。ほとんどの時間、地球上で最も高価なシリコンチップはただ待機している――データを待ったり、同期を待ったり、あるいは単にポッドに占有されたまま放置されたりしているのだ。

大手クラウドサービスにおけるオンデマンド型のデータセンター級GPUのレンタル料金は、1時間あたり10ドル強です。長期契約の方が数倍安くなりますが、その分、使用していない間も料金を支払わなければなりません。 いずれにせよ、アイドル状態のGPUは1時間あたり数ドルものコストがかかるのに対し、アイドル状態のCPUはわずか数セントのコストしかかかりません。 この2桁もの差が、技術的な優先順位を完全に逆転させています。稼働率がわずか20％の場合、実際に利用できる計算時間は定価の5倍のコストがかかります。 20％から40％に引き上げることは「2倍の速度」ではなく、同じ作業量に対するコストを半減させることに他なりません。追加のGPUを購入する必要も、工場の完成を待つ必要も、追加の電力を申請する必要もありません。

HBMやパッケージング能力が業界全体のボトルネックとなっている中、計算能力を増強するための最も安価な方法は、ハードウェアを追加購入することではなく、現在無駄になっているリソースを取り戻すことにある――つまり、cgroupや スケジューラ、チェックポイントといった堅実な要素が、AIクラスターにおいて財務面で最も重要な項目となっている。

補正を開始：VRAM用のcgroup、BPFによる書き込みスケジューリング

最初の基盤が整った：Linux 6.14 以降、カーネルには dmem（デバイスメモリコントローラ）用の cgroup が搭載され、cgroup ツリーに基づいてビデオメモリを制限できるようになった。当初は Intel Xe グラフィックスドライバに組み込まれていた。 控えめな表現に聞こえるかもしれませんが、これはアクセラレーションデバイスのメモリが、RAMに使用されるのと同じカーネルメカニズムによって正確に管理されるようになった初めての事例です。「DRM向けcgroup」というアイデアは、過去10年近くにわたり何度も却下されてきましたが、その欠如によって実際に代償を払うこととなった事例があったからこそ、今回実現に至ったのです。

スケジューリングの分野では、予想外の方面から追い風が吹いている。 sched_ext — BPFを使ってCPUスケジューラを記述し、カーネルにホットロードできるフレームワーク — は、物議を醸す存在から日常的なものへと変化した。多くの主要ディストリビューションではデフォルトで有効化されており、SteamOSではゲームプレイ時にBPFスケジューラをデフォルトとして使用している。 AIサーバーに関して注目すべきはロードマップだ。開発チームは「GPUの認識」をToDoリストに追加した。その理由は極めて現実的だ――どのCPUスレッドがどのGPUにデータを供給するかは決定的な情報であり、スレッドを別のNUMA領域のコアに誤って割り当ててしまうと、GPUはデータ不足に陥ってしまうからだ。

オーケストレーション層では、KubernetesのDynamic Resource Allocation（DRA）がv1.35で正式リリースされ、整数を数えることしかできなかった従来のデバイスプラグインの仕組みに完全に取って代わりました。 DRAでは、ワークロードが必要なリソース（デバイス、メモリ容量、NVLinkの接続タイプ、MIGスライスなど）を記述し、スケジューラにマッチングを任せることができます。 2026年のKubeCon Europeにおいて、NVIDIAは自社のDRAドライバーをCNCFに提供しました。これにより、このリソースモデルはもはや特定のベンダーに限定されたものではなくなりました。抽象化レイヤーはまだ存在しませんが、エコシステムは上位レイヤーで構築が進められ、標準化が進められています。

新手の権限奪取：GPUの全体を撮影してから実行を続ける

不足していた4つの要素のうち、プリエンプトは最も困難であり、かつ最も興味深い進展が見られた分野だ。ジョブを停止して処理リソースを解放するには、CPUメモリ、開いているファイル、VRAMの内容、さらにはCUDAのコンテキスト（スレッド、イベント、メモリマッピング）に至るまで、状態のすべてを保存しなければならない。 そのパズルのピースが今や揃いました。NVIDIAは「cuda-checkpoint」を提供しており、このツールはCUDA呼び出しをロックし、デバイスメモリをホスト側に引き寄せた後、GPUを解放します。 これを、Linuxのユーザー空間でプロセススナップショットを撮影するツールであるCRIUと組み合わせることで、CPUとGPUの両方を統一的にスナップショット化し、別のマシンであっても元のアドレスを正確に復元することが可能になります。

これは見た目以上に重要なことで、これによりGPUが「使い潰されるまで貸し出される」リソースから、回収可能なリソースへと変わるからです。 チェックポイントがあってこそ、進捗を損なうことなく必要な時にジョブを押し出せるため、空き時間を埋めるために優先度の低いジョブを実行したり、断片を回収するためにジョブを移行したり、あるいは「スポット」方式でアイドル状態の処理能力を販売したりすることが可能になります。上記の経済的な計算はすべて、この能力に依存しています。

メモリ層が4つに分割された

同時に、AIの第二の基盤となる前提も揺らいでいる。それは、「メモリはフラットなブロックであり、どこにアクセスしても同じである」という前提だ。 今日のAIサーバーにおいて、メモリはレイテンシが数千倍も異なる4段階の「はしご」のような構造になっている。GPUに内蔵されたHBM、CPUのローカルDRAM、CXL経由の拡張メモリ、そしてNVMeである。

新しい点は、アプリケーションに任せるのではなく、ノード自体がそのスケーリングを管理し始めたことです。 6.9以降、weighted interleaveポリシーにより、帯域幅に比例した重み付けに基づいてノード間でメモリを割り当てることが可能になりました。単純な均等割り当てとは異なり、CXL環境では均等割り当ては自滅行為に等しく、低速なノードがシステム全体のパフォーマンスを低下させてしまうからです。 続いて、カーネル内でメモリアクセスレベルを追跡するシステム「DAMON」が拡張され、単に監視するだけでなく、アクションを実行できるようになりました。具体的には、ホットページを高速ステージに押し上げ、コールドページを低速ステージに降格させ、2026年のアップデートでは、個別の重み付けを持つ複数の宛先ノードへ動的に分散させる機能も追加されます。 これこそが、多段階時代へと移行した仮想メモリである。依然として「カーネルがどのページをどこに配置すべきかを知る」という従来の考え方は変わらないが、違いは、GBあたりの価格が10倍も異なる4種類のメモリの中から選択しなければならない点にある。

エージェントが自らコードを実行する場合：サンドボックスが新たな境界となる

数年前には、これほど大規模には存在しなかった種類の作業がある。モデルによって生成され、自動的に実行され、誰も事前に目を通さないコードだ。各セッションは短いプロセスであり、数秒で始まり終わり、まったく信頼できない。

コンテナではこれには不十分です。その理由は極めて根本的なものです。1台のマシン上のすべてのコンテナが1つのカーネルを共有するため、攻撃対象となるのはそのカーネルのシステムコールインターフェース全体になってしまうからです。 2026年の業界のコンセンサスは、マイクロVMへと完全に傾いています。各エージェントセッションは、KVMの下で、独自のLinuxカーネルを備えた個別の仮想マシン上で実行されます。Firecrackerは、仮想マシン1台あたり数MiBのメモリを消費し、10分の1秒程度で起動します。 Kata Containersは、そのアイデアを「ランタイムクラス」としてまとめ、Kubernetesに直接組み込んでいます。もう一方のアプローチがgVisorです。これはユーザー空間で書き換えられたLinuxカーネルであり、システムコールが実際のカーネルに到達する前にそれをブロックします。 現在、2つの力がぶつかり合い、勢力図が逆転しつつあります。コンテナとマイクロVMの起動時間の差は、もはや言い訳にならないほど縮まった一方で、サンドボックスからの脱出にかかるコストは急騰しています。マシン内にはAPIキー、顧客データ、そして他のエージェントを実行し続ける権限が存在するからです。

共有端末：利用者は、データを盗み読みしていないことを証明しなければならない

最後の点は、共有レンタルによる結果です。モデルやデータが他人のマシン上で実行される場合、問題はもはや「隣人が読み取れるか」ではなく、「ホストが読み取れるか」となります。 シークレットコンピューティングは、仮想マシン全体をCPUによって暗号化された領域（AMD SEV-SNPまたはIntel TDX）でカプセル化することで、プロバイダーの仮想化レイヤーがゲストのメモリを読み取れないようにすることでこの課題に対応します。2025年から2026年にかけての新展開は、GPUをその信頼領域内に組み込むことです： H100以降のデータセンター向けGPUのシークレットモードは、デバイスメモリとPCIeおよびNVLinkの両方を暗号化し、CPU、GPU、およびそれらの間のバスがすべて封印されていることをテナント側が自ら確認できるよう、認証情報を発行します。 推論におけるパフォーマンスのオーバーヘッドは、現在数パーセント程度と公表されており、当初の予測よりもはるかに小さいため、この機能は「銀行向けのオプション」から、機密性の高いワークロードにおけるデフォルト設定へと移行しつつあります。

予測

• GPU向けのcgroupは、CPU向けcgroupの道をたどることになるだろう。デバイスメモリの確保に成功した後、次の課題となるのは、計算時間に対する一種の「重み付け」だ。各ベンダーがファームウェア内にスケジューラを隠しているため、このプロセスは遅々として進まず、議論も絶えないだろう――しかし、資金面ではこれを導入する側に軍配が上がっている。
• GPUのチェックポイントはもはや単なる「裏技」ではなく、基盤となるインフラとなる。今後12～18ヶ月以内に、GPUジョブの停止・移行・再開はクラスタプラットフォームのデフォルト機能となり、真の意味での「スポット」市場の道を開くだろう。
• 「利用可能時間あたりの価格」が公的な競争指標となる。プロバイダーは、カードごとの定価ではなく、「有効時間あたりの価格」を宣伝するようになるだろう。
• カーネル制御によるメモリ階層化がデフォルトとなる。CXLが普及するにつれ、DAMONに基づくウェイト付きインターリーブや階層化は、「専門家による手動調整」の領域を離れ、サーバーディストリビューションのプリセット構成に組み込まれるようになる。
• モデル生成コードに対しては、セッションごとのMicroVMがデフォルトとなる。コンテナは信頼性の高い内部ワークロードでは依然として健在だが、「カーネルを共有する未知のコード」は、かつてroot権限でのサービス実行が見直されたのと同様に、設定ミスと見なされるようになるだろう。
• 逆のリスク：AIへの投資ペースが鈍化し、GPUが突然余剰になった場合、この最適化への圧力は急速に冷めるだろう。歴史的に見て、インフラが適切に最適化されるのは、リソースが希少である場合に限られるからだ。

大局的に見れば、これは「LinuxにAI機能を追加した」というものではない。これは古くから繰り返されてきたサイクルだ。つまり、高価すぎて無駄にできないハードウェアが登場すると、OSはそれを公平に割り当て、最大限に活用するために、さらなる抽象化層を構築せざるを得なくなるのだ。 仮想メモリ、タイムシェアリング、cgroupは、いずれもまさにその論理に従って誕生したものだ。今回、主役はGPUであり、我々は物語のちょうど中盤に差し掛かっている。