VPS 能运行 Firecracker microVM 吗？如何检查 /dev/kvm

您的 VPS 能运行 Firecracker microVM 吗？

只有在 VPS 提供商向您暴露 /dev/kvm 时，您的 VPS 才能运行 Firecracker microVM。Firecracker 是构建在 KVM（基于内核的虚拟机）之上的 VMM（虚拟机监控器）。KVM 是 Linux 内部的虚拟化层，需要 CPU 提供虚拟化指令。在 VPS 中，只有提供商将这些指令传递给您的客户机，您才能使用它们，而大多数套餐并不支持这一点。

因此，首先要确认的不是安装哪个 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 下的来宾系统。在 VPS 上这是正常且预期的情况。第三行统计报告硬件虚拟化标志的 CPU 核心数：Intel 使用 vmx，AMD 使用 svm。在来宾系统中，如果计数大于 0，表示虚拟机监控程序已向您提供嵌套虚拟化。

然后检查您的用户是否可以打开该设备。以下是 Firecracker 自己的入门文档使用的测试：

[ -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 还提供了一个检查命令，用两行输出概括上述信息：

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；这个问题可以在固件中修复。在 VPS 上很少出现这条消息，因为您查看的并不是真实的固件。

每个 /dev/kvm 结果表示什么？

节点存在，且标志计数大于 0。 您的系统支持硬件虚拟化，因此 Firecracker 可以运行。请跳转到资源配置部分，因为剩余限制是内存，而不是 CPU 特性。

不存在节点，systemd-detect-virt 输出 kvm 或 qemu，且标志计数为 0。 您的 VPS 是一台虚拟机，而其宿主机未传递虚拟化功能。因为该标志是 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。 您使用的是容器虚拟化，与宿主机共享内核。/dev/kvm 永远不会出现，因为您没有自己的内核可用于加载模块。安装软件包也无法解决此问题。

标志存在，但节点不存在。 这表示模块尚未加载。运行 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，而不是用于代理任务的容器

容器是运行在您的内核上的进程，通过命名空间和 cgroups 进行隔离。系统中只有一个内核，而且该内核属于您，因此一旦发生内核级逃逸，就会进入主机。microVM 会在硬件虚拟化边界内启动自己的内核，并通过少量模拟设备模型与外部通信，而不是直接接触主机完整的系统调用接口。Firecracker 刻意将该模型保持在较小规模，这正是其设计目标：模拟设备越少，逃逸路径就越少。

对于编码代理而言，这一差异很重要，因为代理运行的代码通常没有经过人工预先审查。它会安装软件包、运行构建脚本，并在失败时以机器速度重试。使用独立内核后，即使某个步骤出错，也只会损坏一台可以删除的机器，不会影响其他系统。

这一要求直接来自底层机制。硬件隔离需要硬件虚拟化，而您的 VPS 方案可能恰好不提供硬件虚拟化。容器完全不需要这些条件，这也是容器能在所有曾经销售过的方案上运行的原因。

因此，当 /dev/kvm 缺失时，基于容器的用于编码代理的一次性 VM仍然是正确选择，而且它是真正的控制措施，不是退而求其次的方案。在不保存您关心的凭据的主机上运行一次性容器，并在容器行为异常时从快照恢复，可以阻止大多数实际会发生的问题。在 VPS 上运行编码代理中的简化配置也是如此。当代理将在无人值守的情况下运行数小时、处理您尚未审查的代码，并且主机由您控制时，再考虑使用 microVM。

微型虚拟机代理主机的要求

Nehemiah 是这类工具的一个当前示例：这是一个采用 Apache-2.0 许可证的守护进程，可按需为 AI 提供一台真实的 Linux 机器，每台机器对应一个 Firecracker 微型虚拟机。其 README 明确写出了要求：“一台带有 /dev/kvm 的 Linux 主机”，更具体地说，是“Ubuntu 24.04、x86_64 或 arm64，并具备 /dev/kvm（裸机，或启用了嵌套虚拟化的虚拟机），且可以通过 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 工具链、客户机内核和根文件系统、Python 客户机镜像、带浏览器的可选桌面镜像，以及名为 nehemiahd.service 和 boring-net.service 的两个 systemd 单元。随后，守护进程会监听 8080 端口；健康检查失败时会输出 /healthz didn't return ok。SKIP_DESKTOP=1 会跳过桌面镜像，而 README 说明构建该镜像大约需要 8 分钟。

粘贴命令前请先阅读注意事项

它需要在全新主机上使用 root SSH。 安装程序会以 root 身份写入系统软件包、systemd 单元和网络配置。请将其指向一台您愿意完全重装的机器，不要指向已经运行网站的服务器。

守护进程默认绑定 0.0.0.0:8080。 任何能访问该端口的人都可以创建机器，而这些机器会消耗您提供给安装程序的模型密钥。设置 NEHEMIAH_TOKEN 以强制要求身份验证，或设置 BIND_LOCALHOST=1，使守护进程仅绑定到 127.0.0.1，然后通过隧道使用 ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP 访问它。应像保护主机上的其他机密一样保护该密钥，例如 避免将机密交给 AI 代理。

每台机器都是一台可访问互联网且预装代理的计算机。 README 列出了来宾系统中的 claude、codex、cursor 和 pi，以及 node、python 和 git。项目说明来宾系统位于出站防火墙之后，隔离边界本身确实有效。但来宾系统仍会按设计访问网络，因为无法获取软件包的编码代理没有实际用途。请据此规划，不要假设这里是物理隔离网络。

项目没有带标签的发行版。 截至 10 August 2026，该仓库完全没有标签，因此克隆 main 会获取当天早些时候提交的内容。请固定到某个提交，并在脚本以 root 身份在服务器上运行前阅读它：

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

该仓库创建于 2026 年 6 月底，因此应将其视为较新的软件。每次拉取更新后，都要重新阅读 infra/setup.sh，因为您批准的是对一台机器的 root 访问，而不是一次库版本升级。

在归咎于安装程序之前，先确认 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

输出版本号只能证明该二进制文件与您的架构匹配，并且可以运行。它不能证明您可以访问 KVM，因此请将其与前文针对 /dev/kvm 的读写测试结合使用。两项测试可以区分主机环境问题和打包问题，避免您调试一个其实没有问题的安装程序。

多个 microVM 需要多大的服务器？

每个 microVM 都包含一个真实的 guest kernel，以及为其分配的内存。只要机器运行，这部分内存就会持续占用。因此，应根据 guest 大小和并发数量规划主机。下面的数字是算术结果，不是实测数据。无图形界面的 guest 分配 1 GB，带浏览器的桌面 guest 分配 2 GB。主机还要固定预留 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
  }
]

同时运行 1 台无图形界面的机器大约需要 3 GB。支持 KVM 的中型 VPS 通常可以满足这一需求。运行 4 台需要 6 GB。运行 8 台桌面机器时，按相同算法需要 18 GB，这还没有计算任何磁盘空间。

磁盘空间是最容易被忽略的部分。主机会存储 guest kernel、基础 root filesystem、每种 guest 类型各一个镜像，以及每台运行中机器各一个快照。带浏览器的桌面镜像占用空间最多。README 没有给出磁盘需求，因此首次构建时应监控 df -h /，不要依赖估算值。

因此，对于“哪个 VPS 可以运行 Firecracker”这个问题，诚实的答案通常是“需要更高规格的机器”。裸机可以直接提供所需的 CPU flags，不受 hypervisor 影响；这也是选择 VPS 还是 dedicated server时需要权衡的因素。一些服务商会在虚拟化套餐中提供 nested virtualisation，在 VPS 上使用 nested virtualisation介绍了付款前如何确认这一点。如果硬件已经归你所有，那么将 Proxmox 与普通 VPS 对比就是从 hypervisor 角度提出的同一个问题。

服务器也只是成本中较低的一部分。你交给 agent 的每台机器在运行期间都会持续消耗模型 tokens，因此空闲 microVM 会占用内存，繁忙 microVM 还会产生 API 费用。1 GB 套餐无法容纳主机。即使某个套餐能够容纳主机，也不代表你能承担密钥费用。

FAQ

如何检查 VPS 是否可以运行 Firecracker？

在 VPS 上运行 ls -l /dev/kvm、systemd-detect-virt 和 grep -cE '\b(vmx|svm)\b' /proc/cpuinfo。如果存在由 kvm 组拥有的设备节点，且标志计数大于 0，则表示 Firecracker 可以运行。如果设备节点不存在且计数为 0，则表示 hypervisor 未提供虚拟化透传；sudo kvm-ok 来自 cpu-checker 软件包，使用 KVM acceleration can NOT be used 可确认这一点。在 arm64 上忽略该计数，因为 vmx 和 svm 是 x86 名称。

可以从 VPS 内部启用嵌套虚拟化吗？

不可以。嵌套虚拟化由主机在 hypervisor 自身的内核模块中启用，然后以 CPU 标志的形式传递到分配给您的虚拟处理器。在 guest 内部，sudo modprobe kvm_intel 返回 modprobe: ERROR: could not insert 'kvm_intel': Operation not supported，因为虚拟 CPU 没有可用的 VMX。您的选择是使用套餐提供嵌套虚拟化的服务商，或使用由您自行管理 hypervisor 的机器。

容器是否足以隔离编码代理？

通常足够。容器共享您的内核，因此内核级逃逸会到达主机；但如果机器上没有重要凭据，在该机器上运行一次性容器可以消除您实际面临的大部分风险。当代理长时间无人值守地处理未经审核的代码，并且您可以为它提供带有 /dev/kvm 的主机时，应选择 microVM。如果无法满足这些条件，每项任务完成后销毁的容器，也优于始终无法成功启动的 microVM。

microVM 代理主机需要多少 RAM？

从 guest 的大小开始计算。一台使用 1 GB RAM 的无头 guest，加上 2 GB 的主机预留，通常总共需要约 3 GB；8 台每台使用 2 GB RAM 的桌面 guest，通常需要约 18 GB。磁盘需求需要单独计算，而且很容易低估，因为主机需要保存一个内核、根文件系统、每种 guest 类型各一个镜像，以及每台运行中机器的一个快照。