smolvm v1.6.13：CUDA forkとクローンVMを実運用へ近づける最新アップデート

v1.6.13が取り組むのは「GPUを使える」の次の課題

smolvm v1.6.13は、CUDA-over-vsockとCUDA forkを中心に、GPUワークロードを隔離VMへ展開する際の運用上の不確実さを減らす更新です。GPUをゲストから呼び出せること自体は重要ですが、推論APIやAIエージェント基盤では、モデルを初期化した後に複数の実行環境へどう増やすか、失敗したワーカーをどう扱うかが同じくらい重要になります。

今回のリリースでは、クローン先ワーカーのハンドシェイク、障害時の復旧・再接続、マルチGPUのピン留め、GPU非搭載ホストでの早期エラーが強化されました。直後の開発でもfork-cloneサービングの修正やVM内でのsm90対応、レプリカ単位のモジュール配布が続いており、機能追加だけでなく実行経路を固める段階に入っていると読めます。

CUDA forkを「GPU状態を引き継ぐクローン」として捉える

一般的な水平スケールでは、新しいコンテナやVMを起動してから、モデル、依存ライブラリ、実行コンテキストをそれぞれ準備します。大きなモデルや複雑な推論ランタイムでは、この初期化時間とGPUメモリへのロードがスケールアウトのボトルネックになります。

CUDA forkは、この問題に対し、初期化済みの実行状態を起点にクローンを扱うアプローチです。ここで重要なのは「すべてを共有する」ことではありません。各リクエストを同じプロセスへ押し込むのではなく、VMという隔離単位を保ちつつ、準備済み状態を有効活用して起動・配備の待ち時間を縮めることに価値があります。

共有する対象を明確にする：モデルやモジュールの配布経路、GPU側の初期化状態、リクエストごとの実行状態を一括りにせず、どこまでを複製・再利用するかを設計します。
分離する対象を残す：テナントの入力、ファイル、ネットワーク到達先、認証情報はクローン元から持ち込まないという原則を守ります。
失敗を局所化する：クローンが不調になったとき、親VMや他レプリカまで巻き込まない監視・再作成の単位を決めます。

つまりCUDA forkは、単なる高速化フラグではなく、推論サーバーの「温まった状態」と「利用者ごとの隔離」の境界を再設計する機能です。コンテナのレプリカ数を増やす感覚で導入する前に、共有資源の台帳を作る価値があります。

ワーカー復旧とマルチGPU割り当てを先に設計する

本番環境では、正常時のクローン作成よりも例外経路のほうが設計を難しくします。v1.6.13でクローンワーカー障害時の復旧・再接続・明示的なハンドシェイクが強化されたのは、制御側が「起動したはずのワーカー」を曖昧な状態のまま使い続けないためです。

利用側では、ワーカーをreadyとみなす条件、リクエストを切り離すタイムアウト、再試行の上限を独自に定義しておくべきです。特にGPU処理は、初回ロード、カーネルのコンパイル、長い生成リクエストなどでCPU中心のサービスより状態判定が複雑になります。接続できることと、必要なGPUリソースで推論できることを別のヘルスチェックとして扱うと、障害解析が容易になります。

マルチGPUではピン留めが鍵になります。自動配置に任せると、あるGPUだけがモデルを保持したり、クローンの増減に伴ってメモリ断片化が進んだりする可能性があります。GPU番号・モデル系統・レプリカ上限を対応付け、次のような運用ルールに落とし込むのが安全です。

GPUごとに許容するモデル、最大クローン数、予約メモリを決める
新規クローンを作る前に空きメモリだけでなく、既存レプリカの待ち行列とエラー率を確認する
GPUが利用できないホストでは即時に失敗させ、CPUへの暗黙フォールバックを発生させない
GPU障害時は同一GPUへの無限再接続ではなく、隔離・退避・再配置の順で扱う

vsockとUnixソケット転送は「便利な権限経路」でもある

v1.6.13ではCUDA-over-vsock向けのCLI／SDKリソース設定が拡充され、任意のUnixソケットを転送する--expose-socketと--mount-socketも追加されました。ゲストからホスト側のサービスへ接続しやすくなる一方、ソケットは単なる通信路ではありません。多くの場合、接続できる主体にホスト側の操作能力を与えます。

たとえばDocker APIソケットを渡せば、VM内のプロセスがホスト上のコンテナを操作できる範囲は、VMのファイルシステム隔離とは別に評価する必要があります。SSH agent転送も秘密鍵のコピーを避ける有効な方法ですが、許可された署名操作をゲストが要求できることには変わりません。

smolvmのネットワークが標準で無効、許可先を明示できるという設計は、ここで活かせます。ソケット転送を許可するVMは短命にし、用途別の専用ソケットだけを渡し、ホスト側サービスにも最小権限の認可を置く──この三層で考えると、「VMだから安全」という過信を避けられます。

導入前に確認したい実務チェックリスト

CUDA forkとクローンVMを評価する際は、性能測定だけで判断せず、以下をレビュー対象にしてください。

クローン境界：初期化済み状態、モデルデータ、テナント入力、環境変数のうち、どれが複製・共有・再生成されるかを説明できるか。
GPU配置：GPUごとのピン留め方針、メモリ上限、混在させないワークロード、障害時の退避先が決まっているか。
復旧手順：ワーカーハンドシェイク失敗、GPU初期化失敗、推論タイムアウトのそれぞれで、誰がどの単位を再作成するか。
ソケット権限：転送するソケットごとに、ゲストが実行できる操作と、利用を終えた際の失効方法が記録されているか。
観測性：クローン数、GPUメモリ、再接続回数、リクエスト失敗率を同じダッシュボードで追えるか。

最初の検証では、単一モデル・単一GPU・短いリクエストという最小構成で、クローン作成から破棄までを繰り返し測定するのがおすすめです。その後にマルチGPU、障害注入、ソケット転送を一つずつ追加すれば、性能低下や権限の広がりを原因別に把握できます。

まとめ：スケールの速度と隔離の境界を同時に扱う段階へ

smolvm v1.6.13は、GPUを隔離VMから利用する機能を、クローンのライフサイクル、障害復旧、複数GPUの配置まで広げたリリースです。CUDA forkはAI推論の立ち上がりを短くできる可能性がありますが、実用性はクローン元と先の境界、GPUの割り当て、ソケットで持ち込む権限をどれだけ明文化できるかで決まります。

セキュリティとサンドボックス、Smolfileの解説と併せて、自組織の推論基盤に必要な最小構成から確認してください。リリースノートの更新を追いつつ、実負荷・実障害を前提とした評価へ進める価値がある段階です。