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

更新：2026年8月。

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

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

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

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％の場合、実際に利用できる1時間あたりの計算コストは定価の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年のアップデートでは、個別の重み付けを持つ複数のターゲットノードへ動的に分散させる機能も追加されます。 これこそが、多階層時代へと踏み出した仮想メモリである。依然として「カーネルがどのページをどこに配置すべきかを知る」という従来の考え方は変わらないが、唯一の違いは、1GBあたりの価格が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であり、我々は物語のちょうど中盤に差し掛かっている。