VPS 能執行 Firecracker microVM 嗎？

VPS 能否執行 Firecracker microVM？

只有在 VPS 提供 /dev/kvm 時，才能執行 Firecracker microVM。Firecracker 是建構於 KVM（kernel-based virtual machine）之上的 VMM（virtual machine monitor）。KVM 是 Linux 內部的虛擬化層，需要 CPU 提供虛擬化指令。在 VPS 上，只有供應商將這些指令傳遞給 guest 時，您才能使用；大多數方案都不提供這項功能。

因此，第一個問題不是要安裝哪個 microVM 工具，而是您目前付費使用的主機是否根本能夠承載 microVM。這是託管環境的問題，通常約 1 分鐘即可確認。

安裝任何套件前先檢查 /dev/kvm

請直接在 VPS 上執行以下 3 個指令。

ls -l /dev/kvm
systemd-detect-virt
grep -cE '\b(vmx|svm)\b' /proc/cpuinfo

能夠裝載 microVM 的主機會輸出如下：

crw-rw---- 1 root kvm 10, 232 Aug 10 09:12 /dev/kvm
kvm
16

第一行是 KVM 裝置節點，其擁有者群組為 kvm。第二行表示這台機器本身是由 KVM 執行的 guest；在 VPS 上這是正常且預期的情況。第三行會計算回報硬體虛擬化旗標的 CPU 核心數量；Intel 使用 vmx，AMD 使用 svm。在 guest 內計數大於 0，表示 hypervisor 已向你公開 nested virtualisation。

接著確認你的使用者是否能開啟該裝置。以下是 Firecracker 自有 getting started 文件中的測試：

[ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL"

在裝置節點存在時出現 FAIL，代表這是權限問題，而不是硬體問題。使用 sudo setfacl -m u:${USER}:rw /dev/kvm 授予自己的使用者存取權，或使用 sudo usermod -aG kvm ${USER} 將自己加入該群組，然後重新登入。

Ubuntu 也提供一項檢查功能，會以 2 行輸出摘要顯示上述資訊：

sudo apt update && sudo apt install -y cpu-checker msr-tools
sudo kvm-ok

運作正常的主機會先輸出 INFO: /dev/kvm exists，接著輸出 KVM acceleration can be used。無法運作的主機會先輸出 INFO: Your CPU does not support KVM extensions，接著輸出 KVM acceleration can NOT be used。在實體機器上，你可能會看到 INFO: KVM (vmx) is disabled by your BIOS；這可以在 firmware 中修正。在 VPS 上很少出現這項訊息，因為你檢查的不是實體 firmware。

每個 /dev/kvm 結果代表什麼？

節點存在，且 flag 計數大於零。 您具備硬體虛擬化功能，因此 Firecracker 可以執行。請跳至規模估算章節，因為剩餘限制是記憶體，而不是 CPU 功能。

沒有節點，systemd-detect-virt 顯示 kvm 或 qemu，且 flag 計數為 0。 您的 VPS 是虛擬機器，但主機未傳遞虛擬化功能。這是因為 flag 屬於 hypervisor 為您建立的虛擬 CPU，來賓系統內安裝任何軟體都無法改變。sudo modprobe kvm_intel 會因 modprobe: ERROR: could not insert 'kvm_intel': Operation not supported 而失敗，且 sudo dmesg | grep -i kvm 會記錄缺少硬體支援。這是共用 VPS 方案的常見情況。請詢問供應商該方案是否支援巢狀虛擬化。如果不支援，您需要更換託管方案，而不是改用其他命令。

systemd-detect-virt 顯示 lxc、lxc-libvirt 或 openvz。 您使用的是容器虛擬化，因此與主機共用 kernel。/dev/kvm 永遠不會出現，因為您沒有自己的 kernel 可供載入模組。安裝套件也無法解決這個問題。

存在 flags，但沒有節點。 這表示模組尚未載入。執行 sudo modprobe kvm_intel（AMD 則執行 kvm_amd），然後再次檢查 ls -l /dev/kvm。如果節點出現，請將模組名稱寫入 /etc/modules-load.d/kvm.conf，讓它在重新開機後自動載入。

您使用的是 arm64。 vmx 和 svm 是 x86 名稱，因此在所有 arm64 機器上，無論是否正常運作，grep 計數都會是 0。在 arm64 上，請改以裝置節點以及讀取和寫入測試為準。

為什麼代理程式工作應使用 microVM，而不是容器

容器是執行在你所使用的核心上的程序，透過 namespaces 和 cgroups 隔離。系統只有一個核心，而且由你掌控，因此核心層級的逃逸會直接進入主機。microVM 會在硬體虛擬化邊界內啟動自己的核心，並與精簡的模擬裝置模型通訊，而不是使用主機完整的 system call 介面。Firecracker 刻意將這個模型維持在很小的範圍，這正是其設計目的：模擬裝置越少，逃逸途徑就越少。

對 coding agent 而言，這項差異很重要，因為 agent 執行的程式碼事前沒有人審閱。它會安裝套件、執行建置指令碼，並在發生錯誤時以機器速度重試。使用獨立核心後，錯誤步驟只會破壞一台可以刪除的機器，不會影響其他系統。

這項需求可直接由運作機制推導出來。硬體隔離需要硬體虛擬化，而你的 VPS 方案不一定提供硬體虛擬化。容器完全不需要這項功能，因此容器才能在所有曾經銷售過的方案上執行。

因此，當 /dev/kvm 不存在時，採用容器的 供 coding agent 使用的一次性 VM 仍是正確選擇，而且這是真正的控制措施，不是退而求其次。使用不含任何重要憑證的主機，執行可丟棄的容器，並在容器行為異常時從 snapshot 還原，即可阻止大多數實際會發生的問題。在 VPS 上執行 coding agent 所介紹的較簡單設定也相同。當 agent 將在未經審閱的程式碼上無人看管地執行數小時，且主機由你自行控制時，再使用 microVM。

微型 VM 代理程式主機的需求

Nehemiah 是這類工具的現成範例：這是一個採用 Apache-2.0 授權的 daemon，可依需求提供一台真實的 Linux 機器給 AI 使用，每台機器對應一個 Firecracker microVM。其 README 直接說明需求：「具備 /dev/kvm 的 Linux 主機」，更精確地說，是「Ubuntu 24.04、x86_64 或 arm64，具備 /dev/kvm（裸機，或啟用巢狀虛擬化的 VM），而且你可以透過 root SSH 登入」。

文件記載的設定方式，是在該主機上執行一個命令：

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm install
NEHEMIAH_ANTHROPIC_KEY=sk-ant-... ./infra/setup.sh root@YOUR_BOX_IP

infra/setup.sh 會透過 SSH 執行安裝前檢查；主機不符合要求時，會提早停止。它拒絕硬體的兩段訊息如下：

/dev/kvm missing — the box needs hardware/nested virtualization
box arch is ${ARCH}; nehemiahd needs x86_64 or aarch64

第一段訊息正是本文的重點。安裝程式提出的問題，與你剛才使用 ls -l /dev/kvm 提出的問題相同；而在大多數 VPS 方案上，得到的答案也同樣令人失望。

通過安裝前檢查後，這會安裝整套主機環境：Firecracker 及其 jailer、Go 工具鏈、guest kernel 與 root filesystem、Python guest image、包含瀏覽器的選用桌面 image，以及兩個名為 nehemiahd.service 和 boring-net.service 的 systemd unit。daemon 之後會在 port 8080 上提供服務；health check 失敗時會輸出 /healthz didn't return ok。SKIP_DESKTOP=1 可略過桌面 image；README 表示建置該 image 約需 8 分鐘。

貼上該指令前，請先閱讀注意事項

它需要在全新主機上使用 root SSH。 安裝程式會以 root 身分寫入系統套件、systemd 單元與網路設定。請將它指向一台你願意從零重建的機器，不要指向已經執行網站的伺服器。

daemon 預設會繫結至 0.0.0.0:8080。 任何能連到該埠的使用者都能建立機器，而這些機器會使用你交給安裝程式的 model key。設定 NEHEMIAH_TOKEN 以要求驗證，或設定 BIND_LOCALHOST=1，讓 daemon 僅繫結至 127.0.0.1，再透過使用 ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP 的 tunnel 連線。該 key 應與主機上的其他 secret 一樣妥善保護，請參閱 避免讓 AI agents 接觸 secrets。

每台機器都是可存取網際網路，且預先安裝 agents 的電腦。 README 列出 guest 內的 claude、codex、cursor 與 pi，以及 node、python 和 git。專案表示 guest 位於 egress firewall 後方，隔離邊界本身確實存在。但 guest 仍會依設計存取網路，因為無法下載套件的 coding agent 沒有實際用途。請據此規劃，不要假設這是 air gap 環境。

目前沒有 tagged release。 截至 10 August 2026，repository 完全沒有 tags，因此執行 cloning main 會取得當天早上最新加入的內容。請鎖定某個 commit，並在以 root 身分於伺服器上執行 script 前先閱讀內容：

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah
git checkout ae743fd5c05aecb6ae4bb52bac6bce198b01ebaa
less infra/setup.sh

該 repository 建立於 2026 年 6 月底，因此請將它視為仍處於早期階段的軟體。每次 pull 更新後，都要再次閱讀 infra/setup.sh，因為你核准的是讓 root 存取一台機器，而不是單純更新 library 版本。

在責怪安裝程式前，先確認 KVM 可正常運作

如果設定失敗，而你想確認原因是否為 KVM，請單獨測試 Firecracker。以下是上游提供的下載步驟：

ARCH="$(uname -m)"
release_url="https://github.com/firecracker-microvm/firecracker/releases"
latest=$(basename $(curl -fsSLI -o /dev/null -w %{url_effective} ${release_url}/latest))
curl -L ${release_url}/download/${latest}/firecracker-${latest}-${ARCH}.tgz | tar -xz
./release-${latest}-${ARCH}/firecracker-${latest}-${ARCH} --version

輸出版本資訊只能證明該 binary 符合你的架構且能執行。這無法證明可存取 KVM，因此請搭配先前對 /dev/kvm 執行的讀取與寫入測試。兩者合併後，即可區分主機環境問題與套件問題，避免花時間除錯其實沒有問題的安裝程式。

數個 microVM 需要多少伺服器資源？

每個 microVM 都包含實際的 guest kernel，以及您配置給它的記憶體。這些記憶體會在機器執行期間持續保留。因此，請根據 guest 的大小與同時執行的數量來配置 host。以下數值是算術結果，不是實測值。無頭 guest 配置 1 GB，搭載瀏覽器的桌面 guest 配置 2 GB。Host 另外固定保留 2 GB，供自身、daemon 與映像檔建置使用。

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 3
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 6
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 10
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 18
  }
]

同時執行一台無頭機器約需 3 GB；具備 KVM 的中型 VPS 通常可以容納。四台需要 6 GB。執行 8 台桌面機器時，依相同算式，在尚未計入任何磁碟空間前，就需要 18 GB。

磁碟空間是最容易被忽略的需求。Host 會儲存 guest kernel、基礎 root filesystem、每種 guest 類型各一份映像檔，以及每台執行中機器各一份 snapshot。搭載瀏覽器的桌面映像檔會較大。README 沒有提供磁碟需求，因此首次建置時請監控 df -h /，不要只依賴估算。

這就是為什麼對「哪種 VPS 能執行 Firecracker」這個問題，誠實的答案通常是「需要不同等級的機器」。Bare metal 不會受到 hypervisor 干預，因此能提供所需的 CPU flags；這也是選擇 VPS 或 dedicated server時需要權衡的事項。有些供應商會在虛擬方案中提供 nested virtualisation，在 VPS 上使用 nested virtualisation說明如何在付費前確認。若硬體已經由您持有，Proxmox 與一般 VPS 的比較則是從 hypervisor 端提出相同的問題。

伺服器也只是成本較低的一半。您交給 agent 的每台機器，只要持續執行就會消耗 model tokens；因此，閒置的 microVM 會持續消耗記憶體，忙碌的 microVM 則會同時消耗記憶體與 API 費用。1 GB 方案無法容納 host。即使某個方案足以容納 host，也不代表您負擔得起 key。

FAQ

如何檢查 VPS 是否能執行 Firecracker？

在 VPS 上執行 ls -l /dev/kvm、systemd-detect-virt 和 grep -cE '\b(vmx|svm)\b' /proc/cpuinfo。如果存在由 kvm 群組擁有的裝置節點，且旗標計數大於 0，表示 Firecracker 可以執行。若裝置節點不存在且計數為 0，表示 hypervisor 未傳遞虛擬化功能；從 cpu-checker 套件取得的 sudo kvm-ok 可用 KVM acceleration can NOT be used 確認這一點。在 arm64 上請忽略計數，因為 vmx 和 svm 是 x86 名稱。

可以從 VPS 內部啟用巢狀虛擬化嗎？

不行。巢狀虛擬化由主機在 hypervisor 自己的 kernel module 中啟用，之後會以 CPU flag 的形式提供給分配給你的 virtual processor。在 guest 內，sudo modprobe kvm_intel 會回傳 modprobe: ERROR: could not insert 'kvm_intel': Operation not supported，因為 virtual CPU 沒有可用的 VMX。你可以選擇方案中提供巢狀虛擬化的 provider，或選擇由你自行管理 hypervisor 的機器。

容器足以隔離 coding agent 嗎？

通常可以。容器共用你的 kernel，因此 kernel level escape 可能抵達主機；但在不存放重要 credentials 的機器上使用可丟棄的容器，可以排除你實際面對的大部分風險。如果 agent 會長時間無人看管地執行未審查的程式碼，且你能提供具備 /dev/kvm 的主機，請改用 microVM。無法提供時，每項工作完成後銷毀的容器，仍勝過始終無法成功啟動的 microVM。

microVM agent 主機需要多少 RAM？

先從 guest 大小估算。單一 1 GB 的無頭 guest 加上主機保留的 2 GB，總計約需 3 GB；8 個各使用 2 GB 的 desktop guest，總計約需 18 GB。磁碟空間則需另外計算，也很容易低估，因為主機需要保留 kernel、root filesystem、每種 guest flavour 各一份 image，以及每台執行中機器各一份 snapshot。