Vime keeps slime's training loop and moves vLLM into the rollout seat

Three modules, and parameters move one way

The architecture is three modules, and the dataflow between them is the whole design.

Training is Megatron's job. It runs the main training process, reads data from the data buffer, and synchronises parameters back to the rollout module after each training step. Rollout is the vLLM side: it launches vLLM inference engines and routes generation requests to them, and a custom generate function can wrap generation in a multi turn loop, tool calls, environment or sandbox interaction, and verifier based rewards. Between them sits the data buffer, a bridge that manages prompt initialisation, custom data, and the rollout generation methods, and which is also where agentic workflows produce their samples through the same interface.

The inheritance is explicit in the README's own words. Vime keeps slime's training stack and data generation design, and uses vLLM with vllm-router as the default rollout backend. Model support comes from the same place: the Qwen series, the DeepSeek V3 series and Llama 3 are listed as inherited rather than validated by this project.

So the pitch is a swap of one component in someone else's system, and the risk that comes with it is the mismatch between two projects on different release cycles. The README addresses that directly, saying the aim is a production ready bridge that aligns both projects' rapid release cycles.

Agentic work is a custom generate function, not a second framework

The agentic section opens by closing a door. Agentic workloads use the standard rollout and data buffer loop through the customization interfaces, and they are not a separate framework. That sentence is the design decision, and it is why there is no agent module in the architecture diagram.

Three examples carry the capability. The multi agent example does multi agent generation through a custom generate function path passed as a flag. The fully asynchronous example handles fully asynchronous rollout for long tail agent generation, and it has its own entry script in the repository. The coding agent example is the ambitious one: end to end coding agent RL with Claude Code or Codex, sandboxed tool use, test based rewards, and trajectory segments that are token correct.

The sandbox is the part that generalises. The coding agent example ships with a backend compatible with E2B, and the shared sandbox contract can be implemented for Docker, for Modal, or for local virtual machines. So the same training run can execute tool calls in a hosted sandbox, a container, or a virtual machine next to the training job, and swapping the backend is a contract implementation rather than a fork.

Test based rewards and token correct segments are the other two ideas in that example worth pulling apart, because they are what makes a coding agent trainable: the reward comes from running tests rather than from a model's opinion, and a trajectory that gets truncated or padded in the wrong place is excluded from the training signal.

The router has two argument prefixes, and they mean different things

Arguments fall into three categories, and the third one is where a first time user will lose an afternoon.

Megatron arguments are read as they are, so a Megatron option like the tensor model parallel size is passed straight through. vLLM arguments carry a prefix, so a server option like GPU memory utilisation becomes a vllm prefixed flag. Framework specific arguments are the shared orchestration flags, covering rollout GPUs, data paths and RL algorithm choices, and they live in a different file from the vLLM ones.

The router is the awkward case, and the README splits it deliberately. Options that belong to the router itself are passed with a router prefix, and the two named examples are a policy setting and a request timeout. Knobs that tell Vime where the router lives, its address and its port, use a different prefix that includes vllm. So a flag that begins with the router name might be configuring the router's behaviour or might be telling Vime the router's location, and those are different questions with different owners.

Two other arguments are worth knowing. The number of GPUs per rollout engine sets that engine's tensor parallel size, which is how a single integer connects your cluster layout to vLLM's parallelism. And the default rollout entry point is a named function in the vLLM rollout module, which is the thing you replace when you write a custom generate function, and which is why the agentic examples plug in at a path rather than a subclass.

The line length is 320 with a note to fix it later

The packaging configuration has one line that tells you how the project actually runs its linting.

The formatter is set to 119 characters, and the import sorter is configured to be compatible with that formatter, targeting Python 3.11 as its version. Then the linter is configured with a line length of 320, followed by the comment TODO, and the error for long lines is explicitly ignored with a second comment saying it will be handled later. So the enforced line length in practice is the formatter's 119, and the linter's own limit is switched off in favour of it.

That is a defensible arrangement and an honest annotation, since the two tools normally disagree and somebody has to pick one. The reason it is worth reporting is that a line length of 320 in a configuration file reads as carelessness until you see the comment, and a reader who does not will conclude the wrong thing about the codebase.

The test configuration is the disciplined half. Pytest always gets verbose output, durations sorted ascending so the slowest tests are visible, and strict markers, with the test path written out explicitly because, as the comment says, that avoids importing another module called tests. Several directories are excluded from discovery, including examples, docs, scripts and tools, which is how a repository with thirteen example directories keeps its test run from collecting them.

The Python floor is 3.10, from the setup script, with classifiers for 3.10 through 3.12 and an environment marker for NVIDIA CUDA, which is the shortest way to tell you this does not run on a laptop CPU.

No version pins in the requirements, and no Megatron in them

The dependency file is a plain list of names, and the absences in it are as informative as the entries.

There is one floor in the whole list, on the router package, and everything else is unpinned: the acceleration library, the Anthropic and OpenAI clients, the agents package, a compression library, blob storage, datasets, a sandbox provider, an HTTP client with HTTP2 support, the MCP command line extra, numba, a config system, Pillow, a LaTeX encoder, YAML, a vision language utility, Ray, safetensors, TensorBoard, transformers, a tracking library, zstandard. And a comment on the memory profiler says it is needed for debugging but is lightweight, and could be moved to a dev mode later.

Two entries are annotated with their purpose rather than their version. The vision language utility is there for the vision language models, and a hashing library is there for the checksum in disk based delta weight sync, which tells you the weight update path on disk is verified.

The absence that will surprise a reader is the training framework itself. Megatron is the training module, and the import sorter's configuration lists it as a known third party package, but it is not in the requirements file. So a fresh environment has to be told about the training stack separately from installing Vime, which is consistent with the project's own description of itself as inheriting slime's training stack rather than vendoring it.

The sandbox and agent dependencies are the other clue. They are runtime requirements of the examples, not optional extras, so a minimal installation pulls an agent framework and a sandbox client whether or not you use the coding agent example.

Two entry scripts, and thirteen examples

The repository root has two training entry points, one plain and one asynchronous, and the example directory has thirteen projects in it.

The two scripts are the visible form of a distinction the architecture makes elsewhere: a standard rollout loop, and a fully asynchronous rollout for the long tail of agent generation where waiting for every engine to finish is the bottleneck. The asynchronous one is a separate file rather than a flag, which is a heavier commitment than a switch and worth noticing before you start editing one of them.

The example list is a good index of what the framework is asked to do. There is a coding agent example, a multi agent one, a fully asynchronous one, a memory agent, a delta weight sync example matching the disk based weight update feature, a multi task evaluation example, and a helper whose name is a warning rather than a feature: it exists to investigate a mismatch between training and inference. There is a vision language example on a geometry dataset and a multi turn version of it, an on policy distillation example, and a tool use benchmark example.

That last group is the most telling. Vision language training, distillation, multi turn tool use and a train versus inference mismatch are four different problems, and an example directory that has one project for each is telling you the framework is a harness rather than a recipe.

The rest of the tree is ordinary and slightly large: a plugin package, the main package, tests, tools, scripts, a docker directory, documentation, both English and Chinese readmes, an agent instructions directory, and both a GitHub workflows directory and a Buildkite directory, so continuous integration runs in two places.

RL bugs are silent, so the test layers are split by cost

The correctness section opens with a problem statement rather than a feature list: reinforcement learning bugs can be silent. A training run that has gone wrong in a data flow does not crash, it just produces a worse model, which is the worst failure mode a research framework can have.

The answer described is structural rather than a test count. The dataflow is kept explicit, and there are separate debugging paths for rollout only and for train only, so a failure can be isolated to one side of the loop before anyone suspects the algorithm. The tests are layered to match: CPU unit tests, contract tests for the customization hooks, and GPU end to end suites, with each layer protecting a different part of the pipeline.

The customization hook contract tests are the layer that only makes sense for this design. If a user is expected to drop in a custom generate function, then a change to the signature of that hook has to fail a test rather than fail at three in the morning inside a rollout, and a contract test is what does that.

The rest of the project is positioned rather than claimed. The README lists the other post training frameworks the vLLM community supports, in alphabetical order, and describes Vime as the route for bringing the slime paradigm into that ecosystem rather than as a competitor to them. There is one release so far, v0.3.2 on 7 September 2026, a last push to main on 1 October, an Apache 2.0 licence, a Chinese translation of this page, and discussion split between a Slack channel and a WeChat group.

Editorial conclusion

Vime fits a team that already trains with slime and wants its rollouts served by vLLM, or a team that wants an agentic RL example with a coding agent in the loop and a sandbox it can swap. It does not fit someone looking for a new training algorithm, since it inherits model support and the training paradigm rather than adding either, and it does not suit a machine without NVIDIA GPUs. Before running anything, read the two router argument prefixes, since the same word means two different namespaces, and check which of the two entry points you want, because the asynchronous one is a separate script rather than a flag.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. vllm-project/vime on GitHub