世界を動かす技術を、日本語で。

Show HN: CoWメモリフォークを使用したサブミリ秒VMサンドボックス

2026年3月17日原文(github.com)

概要

  • Zeroboot は、 AIエージェント向けサブミリ秒VMサンドボックス を実現
  • Firecracker を活用し、 コピーオンライト(Copy-on-Write)フォーク による高速起動
  • 各サンドボックスは 本物のKVM仮想マシン で、ハードウェアレベルのメモリ分離を実現
  • APIやSDK を通じてPythonやTypeScriptから利用可能
  • 現状は プロトタイプ であり、プロダクション運用には未対応

サブミリ秒VMサンドボックスの仕組みと特徴

  • Firecracker でVMを一度だけ起動し、Pythonやnumpyなどランタイムを事前ロードした状態で スナップショット 取得

  • 新しい実行ごとに KVM VMをコピーオンライトでフォーク し、スナップショットメモリを MAP_PRIVATE でマッピング

  • 各サンドボックスは 独立したKVM VM として起動、 ゲストカーネル・メモリ・ページテーブル も完全に分離

  • コード実行後は即終了、 超高速なサンドボックス起動 を実現

    • 起動レイテンシ(p50): 0.79ms(従来のDaytonaやE2B microsandboxと比較して圧倒的に高速)
    • 起動レイテンシ(p99): 1.74ms
    • サンドボックスごとのメモリ消費: 約265KB
    • Pythonでのfork+exec時間: 約8ms
    • 同時1000フォーク時の合計時間: 815ms
  • ハードウェアレベルのメモリ分離 により、セキュリティ・アイソレーションを確保

  • LinuxのCoW機能 により、メモリ効率も抜群

API・SDKによる利用方法

  • API エンドポイント例
    • curlコマンドでPOSTリクエスト送信し、コードを即時実行
  • Python SDK
    • from zeroboot import Sandbox
    • sb = Sandbox("zb_live_your_key")
    • result = sb.run("print(1 + 1)")
  • TypeScript SDK
    • import { Sandbox } from "@zeroboot/sdk";
    • const result = await new Sandbox("zb_live_your_key").run("console.log(1+1)");

アーキテクチャと現状

  • Firecracker でテンプレートVMを一度だけ起動し、 スナップショット を取得
  • 新規リクエストごとに KVM VMをフォーク し、 CoWメモリ を利用しつつCPU状態も復元
  • 完全なVM分離 によるセキュリティ
  • Rust で実装、 Apache-2.0ライセンス
  • プロトタイプ段階 であり、商用運用前の状態
  • 興味があれば GitHub Issue で問い合わせ可能

技術的な工夫点

  • 毎回新規VMをブートせず、スナップショットから即時復元
  • CoW自体よりも、スナップショットVMの正しい再開処理が難関
  • 各サンドボックスは 本物のKVM VM であり、 コンテナとは異なる完全分離
  • 書き込み時は個別ページを自動複製、高いセキュリティと効率性

まとめ

  • AIエージェントやコード実行基盤 に最適な、 超高速・高セキュリティなサンドボックス基盤
  • 従来技術と比較して圧倒的な起動速度・省メモリ
  • 今後の本番運用やOSS貢献にも期待

Hackerたちの意見

特定のバージョンのファイアクラッカーでしか動かないの?それに、1つのvCPUのVMだけ?サブミリ秒の起動時間よりも、VMごとに258KBのRAMが必要なのが大きいね。

現在はフォークごとに1つのvCPUだね。マルチvCPUも可能だけど(vCPUごとの状態をループで復元する感じ)、フォーク時間が増えちゃう。Firecrackerのバージョンについては、v1.12でテストしたけど、vmstateパーサーがオフセットを自動検出するから、ハードコーディングせずにバージョンを跨いで動くはずだよ。

これがうまくいくのを見るのはいいね!exe.devを立ち上げる前にこれを試してみたんだけど、VM自体はすごく良く動いたよ。ただ、ネットワークを機能させるためのセットアップが結構大変だった。結局、我々のターゲットは~1秒の起動時間を気にしないユースケースだから、毎回クリーンなsystemdスタートをする方が楽だったんだ。それでも、最小限のもの、例えばPythonインタープリターのためにVMを使いたい人たちのユースケースもいくつか見たことがある。これはまさに彼らが使うべきアプローチだね。すごく期待してる、どこまで進められるか楽しみ!

simonwはいつもあなたが言ってることを求めてるみたいだけど、もっとwasm向けかもね。

みんなが見落としがちなのは、CoWが輝くのは基本イメージを更新する必要がないときだけで、更新が必要になると古いメモリやホットパッチで手間がかかるってこと。スナップショットは魔法のようなブートを提供してくれるけど、数百のフォークにセキュリティ修正を展開しなきゃならなくなったら、神様助けてって感じだよ。素早いスタートはいいけど、「信頼できるコードベースで普通のPythonを実行する」っていうワークロードなら勝てるけど、複雑になるとメンテナンスの負担が増えて、結局は無駄な作業に戻っちゃう。

これを本番環境でやるのは、ノード間でサンドボックスをクローンするのが難しいんだよね。常駐メモリやファイルシステム(またはrootfsの上にあるCoWレイヤー)をスナップショットして、データをノード間で移動させる必要がある。

これ、関係ある? https://codesandbox.io/blog/how-we-clone-a-running-vm-in-2-s...

そうだね、ノード間の連携が次の難しいステップだね。今のところ、シングルノードの密度でも意外と進むよ。$50のボックスで1000のサンドボックスが同時に動くからね。マルチノードが必要になったら、userfaultfdを使ってリモートページを取得するのが有力な道だと思う。

各ノードに起動を待っているウォームアップ済みのVMがあるなら、ノード間でクローンする必要はないね。

あなたの書き込みを見て思い出したのがこれだよ: https://codesandbox.io/blog/how-we-clone-a-running-vm-in-2-s... 似たようなことある?

これ、パススルーが必要なの?それとも、パススルーなしのクラウドVM/VPSでPVMを活用できるかも?

何を聞きたいのか正確にはわからないけど、Firecrackerは/dev/kvmにアクセスする必要があるから、VMでネスティングを有効にしないといけないよ。

Hacker Newsで議論の続きを見る