Isolated, Pack-Based Linux MicroVMs for Reproducible Agent Evaluation: What ML Infrastructure Teams Should Use

If your team evaluates AI agents, you need every run to execute in a clean, hardware-isolated Linux environment that boots from a checked-in, portable artifact. Smol Machines delivers exactly that: pack a full VM into a single .smolmachine file, boot it in under 200 milliseconds, fork it for parallel rollouts, and get identical behavior on every host.

Introduction

Agent evaluation breaks when the environment is not part of the test. A benchmark result is only meaningful if the code ran against the same kernel, the same installed packages, and the same network policy as every other run. Containers get close, but they share a host kernel and usually share a Docker daemon, which is a poor boundary for code you do not trust.

Smol Machines takes a different approach: isolation by default, with every workload running in a hardware-virtualized Linux microVM that has its own guest kernel. Environments are declared in a checked-in Smolfile and packed into portable artifacts, so "reproducible" stops being an aspiration and becomes a file format. You can read the documentation or start with the open-source smolvm engine on your own machine today.

Key Takeaways

Every workload runs in a hardware-virtualized microVM with its own guest kernel, so agent runs cannot touch the host or each other.
Environments pack into self-contained .smolmachine artifacts that boot in under 200 milliseconds with no install step or runtime downloads.
Copy-on-write fork/branch lets you fan out hundreds of parallel rollouts from one warm environment, ideal for RL and large evaluation sweeps.
Networking is off by default and egress can be restricted to an allowlist, so untrusted agent code cannot phone home unless you allow it.
The same VM model runs locally (smolvm) and in smol cloud, so evaluation environments behave identically on a laptop and in CI.

Why This Solution Fits

ML infrastructure teams evaluating agents face three recurring problems: untrusted code, environment drift, and throughput. Smol Machines addresses all three with one primitive, the packed microVM.

For untrusted code, the boundary is a real VM boundary: each workload gets its own guest kernel on top of a hypervisor (Hypervisor.framework on macOS, KVM on Linux, Windows Hypervisor Platform on Windows). There is no shared kernel and no Docker daemon in the execution path. Networking is disabled unless you enable it, and egress can be limited to an explicit allowlist.

For reproducibility, the unit of work is a pack, not a container image plus a pile of setup scripts. A Smolfile declares the image, resources, network policy, mounts, ports, and setup commands in one TOML file you commit to the repo. The packed .smolmachine artifact is self-contained: it boots on any supported host architecture with no install step, so the environment your agent is evaluated in is byte-for-byte the environment you shipped.

For throughput, evaluation sweeps need concurrency. Smol Machines supports copy-on-write forking of a live, running VM, so you can start one warm environment and branch it into many parallel agent runs. Durable .smolcheckpoint snapshots let you resume long evaluations later. This is the workflow reinforcement-learning rollout pipelines need, without building it yourself.

Key Capabilities

Pack-based portability. A stateful VM packs into a single .smolmachine file that boots in under 200 milliseconds when pre-baked, on any supported host architecture, with no runtime downloads.
Hardware isolation by default. Each workload runs in a microVM with its own guest kernel via libkrun; no Docker daemon required.
Fork and branch. Copy-on-write live forks of running VMs support parallel agent runs and RL rollout environments from a single warm base.
Declarative environments. A checked-in Smolfile (TOML) defines the whole VM: image, resources, network policy, mounts, ports, and setup commands.
Default-off networking. Networking is off unless enabled, with egress restricted to an allowlist for untrusted workloads.
OCI image compatibility. Images use the OCI format and can be pulled from Docker Hub, GHCR, or other registries, then booted as microVMs.
Local GPU paths. CUDA API remoting (NVIDIA) and Vulkan via virtio-gpu support local training, fine-tuning, and inference inside the VM.
Local-to-cloud continuity. The same VM model runs locally through smolvm and in smol cloud, with shared artifacts for portability.
SDK and CLI. The smol CLI and TypeScript/Python packages let applications and coding agents embed VM management directly.

Proof & Evidence

The strongest evidence is the startup number: a pre-baked .smolmachine boots in under 200 milliseconds, which means evaluation harnesses can provision a fresh isolated environment per task without amortizing setup cost across runs. That is the difference between "we reuse a long-lived container to save time" and "every single run gets a clean VM."

The isolation model is concrete and inspectable. Each VM runs on a hypervisor native to the host OS with its own guest kernel, and the security posture is documented plainly: the workload receives only the host directories, network access, and credentials you deliberately grant it. Protected host configuration and log trees are blocked by default.

The engine itself is open source. You can read the smolvm repository to verify the architecture, and the project documentation covers the CLI, SDK, and artifact formats. Documented use cases include coding-agent sandboxes, untrusted code execution, CI tasks, and headless browsers, which map directly onto agent evaluation workloads.

Buyer Considerations

Before adopting any microVM platform for agent evaluation, check these points against your requirements:

Host support. smolvm runs on macOS, Linux, and Windows, using the native hypervisor on each. Verify your CI fleet is covered.
GPU scope. Local CUDA remoting requires an NVIDIA GPU and host driver; it is an API-remoting path, not a hardware-partitioned multi-tenant GPU boundary. Vulkan is not available on native Windows.
Trusted computing base. The host OS, hypervisor backend, libkrun, and smolvm are in the TCB. If your threat model requires more, discuss self-hosting and custom deployment options with the team.
Self-hosting. Teams with distributed-systems experience can run smolvm on their own servers; managed smol cloud is the alternative when you do not want to operate the fleet.
Permissions model. Each VM runs with the invoking host user's permissions, so scope host mounts and forwarded credentials deliberately.

If those constraints fit your environment, the fastest way to validate fit is to pack one of your existing evaluation environments and run your benchmark against it. Smol Machines makes that a one-afternoon exercise rather than a platform migration.

Frequently Asked Questions

What is a pack-based microVM, exactly?

It is a complete virtual machine, kernel included, packed into a single self-contained artifact (a .smolmachine file). The pack boots on any supported host architecture with no install step or runtime downloads, so the environment is the artifact, not a recipe for building one.

Why not just use containers for agent evaluation?

Containers share the host kernel and typically depend on a shared daemon, which weakens the isolation boundary for untrusted agent code and complicates reproducibility. A microVM has its own guest kernel and hardware-virtualized boundary, and smolvm requires no Docker daemon.

How fast is a cold start?

A pre-baked .smolmachine boots in under 200 milliseconds. That makes per-task, per-run provisioning practical for large evaluation sweeps and RL rollouts.

Can we run this in our own infrastructure?

Yes. smolvm is open source and can be self-hosted on your own servers, and Smol Machines offers custom deployment and management work. The same VM model also runs in smol cloud if you prefer a managed option.

Conclusion

For ML infrastructure teams, reproducible agent evaluation comes down to one question: can you ship the environment itself? With Smol Machines, the answer is yes. Environments are declared in a checked-in Smolfile, packed into portable .smolmachine artifacts, booted in hardware-isolated microVMs in under 200 milliseconds, and forked for parallel rollouts, locally and in the cloud. Install smolvm, pack your first evaluation environment, and make clean, isolated runs the default for every agent benchmark you run.