您的 VPS 能运行 Firecracker microVM 吗？

您的 VPS 能运行 Firecracker microVM 吗？

只有在 VPS 向您提供 /dev/kvm 时，才能运行 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

第 1 行是 KVM 设备节点，其所属组为 kvm。第 2 行表示此计算机本身是运行在 KVM 上的 guest，这在 VPS 中正常且符合预期。第 3 行统计报告硬件虚拟化标志的 CPU 核心数：Intel 使用 vmx，AMD 使用 svm。在 guest 中，该数量大于 0 表示 hypervisor 已向你提供嵌套虚拟化。

然后检查你的用户是否可以打开该设备。这是 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 可以运行。请跳转到资源 sizing 部分，因为剩余限制是内存，而不是 CPU 特性。

没有节点，systemd-detect-virt 输出 kvm 或 qemu，且标志计数为 0。 您的 VPS 是一台虚拟机，但其宿主机没有传递虚拟化支持。因为该标志是 hypervisor 为您创建的虚拟 CPU 的属性，所以在 guest 中安装任何软件都无法改变这一点。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，而不是容器

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

对于编码代理，这一差异很重要，因为代理运行的代码事先无人审查。它会安装软件包、运行构建脚本，并在失败时以机器速度重试。独立内核意味着错误步骤只会破坏一台您可以删除的机器，不会影响其他系统。

这一要求直接源于隔离机制。硬件隔离需要硬件虚拟化，而您的 VPS 方案可能不提供硬件虚拟化。容器不需要这些条件，这也是容器能够运行在所有曾经出售过的方案上的原因。

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

微型 VM 代理主机需要什么

Nehemiah 是这类工具的一个实际示例：它是一个采用 Apache-2.0 许可证的 daemon，可按需为 AI 提供一台真实的 Linux 机器，每台机器对应一个 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，以及一个可选的带浏览器的 desktop image；同时还会创建两个名为 nehemiahd.service 和 boring-net.service 的 systemd unit。随后，daemon 会在端口 8080 上提供服务；健康检查失败时会输出 /healthz didn't return ok。SKIP_DESKTOP=1 可跳过 desktop image 的构建；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 在 guest 中列出了 claude、codex、cursor 和 pi，以及 node、python 和 git。项目说明 guest 位于出口防火墙之后，隔离边界本身确实有效。但 guest 按设计仍可访问网络，因为无法获取软件包的编码代理没有实际用途。请据此规划，不要假设这里存在气隙环境。

没有标记的发行版本。 截至 10 August 2026，该仓库完全没有 tag，因此克隆 main 会获取当天早些时候提交的任意内容。请固定到某个 commit，并在脚本以 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 都包含一个真实的客户机内核，以及分配给它的内存。只要主机运行，这部分内存就会持续占用。因此，应根据客户机规格和计划同时运行的数量来确定主机配置。以下数值是算术结果，不是实测数据。无界面客户机分配 1 GB，带浏览器的桌面客户机分配 2 GB。主机还要预留固定的 2 GB，用于自身、守护进程和镜像构建。

[
  {
    "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 通常可以满足这一需求。运行 4 台需要 6 GB。运行 8 台桌面客户机时，按相同方法计算，在计入任何磁盘空间前就需要 18 GB。

磁盘空间是最容易被忽略的部分。主机需要存储客户机内核、基础根文件系统、每种客户机规格对应的一个镜像，以及每台运行中机器对应的一个快照。带浏览器的桌面镜像占用空间最多。README 没有给出磁盘需求，因此首次构建时应监控 df -h /，不要依赖估算值。

因此，对于“哪种 VPS 可以运行 Firecracker”这个问题，诚实的答案通常是“需要另一档服务器”。裸机可以直接提供所需的 CPU 标志，不会受到虚拟机管理程序的限制；这也是选择 VPS 还是独立服务器时需要权衡的因素。有些服务商会在虚拟化套餐中提供嵌套虚拟化，在 VPS 上使用嵌套虚拟化介绍了如何在付款前确认这一点。如果硬件已经属于你，在 Proxmox 与普通 VPS 之间进行选择则是从虚拟机管理程序角度提出的同一个问题。

服务器只是成本较低的一部分。分配给代理的每台机器只要运行，就会持续消耗模型 token。因此，空闲 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 的无头 guest，加上主机预留的 2 GB，总共约需要 3 GB；8 台每台 2 GB 的桌面 guest，约需要 18 GB。磁盘空间需要单独计算，而且很容易低估，因为主机会保留一个内核、根文件系统、每种 guest 类型各一个镜像，以及每台运行中机器对应的一个快照。