nemo_gym.environment.in_process
nemo_gym.environment.in_process
Run a Gym benchmark from Python: plan it in one call, then run single tasks against running servers.
To start the servers from Python too, serve the benchmark and give the yielded registry server to the runner:
plan_benchmark builds the plan gym eval plan --benchmark NAME writes and collates the benchmark’s
rows. It reads no command-line arguments and leaves Gym’s process-wide configuration untouched,
so a long-lived process can call it. serve_benchmark starts the servers gym env start --benchmark NAME
starts, from the same kind of config dict; each server runs in its own process and environment either way.
The registry server is the server that serves the run’s config and the other servers’ addresses; a TaskRunner
talks to it.
This is the API for callers outside Gym. They import the names nemo_gym.environment exports (plan_benchmark,
serve_benchmark, TaskRunner, PlannedBenchmark, TaskResult and EvalPlan) and ConfigError from
nemo_gym.config. Signatures and result fields change only additively, and tests pin them. TaskResult.results
holds Gym’s raw /run responses, whose keys can change: depend on rewards, and use results for debugging.
Module Contents
Classes
Functions
API
A prepared benchmark: its plan (task ids and input digests) and the collated rows to run.
The Gym commit the plan was made with, or None when Gym was not installed from a git checkout.
Each planned task’s id mapped to the digest of its input, which changes when the input changes.
The planned benchmark as JSON text, for handing it to another process; from_json reads it back.
One task’s rollouts: a reward per repeat and Gym’s raw /run results, in the same order.
Runs single tasks of collated rows against Gym servers that are already running.
The rows are checked and indexed by task id once. Each run_task call then selects one task’s row,
repeats it, sends it through the agent’s /run and returns the rewards. Concurrent calls in one
event loop are supported.
Run num_repeats rollouts of one task.
rollout_id names the rollouts for Gym’s rollout correlation (e.g. verification events); repeats
get <rollout_id>-r<n>. It must differ between concurrent calls; a fresh one is made when it is None.
The resolved config for one benchmark, built without reading sys.argv or caching it process-wide.
The overrides as a dict, refusing a dotted key at any depth.
Merged as a dict, "judge.model" would be one key with a dot in its name, while ++judge.model=x on the
command line sets model inside judge. Refusing it keeps the dict and the command line from disagreeing.
Resolve the benchmark NAME[/FLAVOR], prepare its data, build its plan and collate its rows.
overrides are config keys merged on top, as a nested dict like the config file’s; a dotted key is refused
(ConfigError), because it would be one literal key here but a path on the command line.
work_dir receives the collated files; a temporary directory is used when it is None.
The caller’s command line and active exporters are left alone. The benchmark’s prepare script sees
overrides as its Gym configuration, which is this process’s configuration only while it runs.
Start the benchmark’s servers, and stop them on exit. Yields the registry server a TaskRunner talks to.
The benchmark NAME[/FLAVOR] and the model type are named as in
gym env start --benchmark NAME --model-type TYPE. overrides are config keys merged on top, as in
plan_benchmark, so planning and serving read the same dict: nested dicts, and a dotted key is refused
(ConfigError). The model’s
policy_base_url, policy_api_key and policy_model_name are among them. registry_port fixes the registry
server’s port, so a caller that serves from another process can know the address before the servers start;
Gym chooses the port when it is None.
Returns once every server is ready; raises ConfigError if a server or a model endpoint is not, or if
registry_port is in use. Like gym env start, it sets this process’s Gym configuration, so serve one
benchmark per process.