pytorch / pytorch/rl

Feature request: public async evaluator API for dedicated eval devices

Open
#3,610 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
3.6k
Forks
487
Avg merge
1d 1h
Merged PRs (30d)
207

Description

Summary

TorchRL could use a public, documented evaluator API for the common setup where:

  • training runs on one device,
  • collection runs on one or more other devices,
  • evaluation runs on a dedicated device,
  • evaluation should not block the training loop.

In the current installed build I tested, torchrl.trainers.Evaluator is not importable, and I couldn't find a public MultiAsyncCollector symbol either. That leaves users implementing custom background threads/processes around:

  • creating a separate eval env,
  • copying policy weights over,
  • running deterministic rollout,
  • handling logging/video manually,
  • polling/joining results.

Concrete use case

I am training PPO with:

  • collectors on cuda:4,cuda:6,
  • optimizer on cuda:5,
  • evaluation on cuda:7.

The desired behavior is:

  1. trigger eval every N training iterations,
  2. keep the hot training loop running,
  3. poll the eval result later,
  4. log scalar metrics and optional video once the result is ready.

That pattern is useful enough that it would be better as a first-class TorchRL API than repeated custom code in downstream projects.

What would help

Something along these lines:

  • a public Evaluator (or similarly named) object that is part of the installed API,
  • support for sync and async modes,
  • explicit support for a dedicated eval device,
  • simple trigger(...), poll(), and wait() semantics,
  • a clear contract for how policy weights are transferred,
  • integration with VideoRecorder / loggers, or at least a recommended pattern documented in TorchRL.

Why this matters

Without this, async eval tends to become a pile of downstream boilerplate that is easy to get subtly wrong:

  • stale weights,
  • blocking behavior,
  • duplicate env setup,
  • awkward video handling,
  • ad hoc thread/process lifecycle management.

If there is already a recommended API for this that is just not exported/documented, exposing it would already help a lot.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by checking the installed API around torchrl.trainers.Evaluator and the reported MultiAsyncCollector symbol, then review the requested VideoRecorder and logger integration points. Define the public sync and async behavior, dedicated-device handling, trigger/poll/wait semantics, and policy-weight transfer contract; done means the API is importable and the documented evaluation workflow covers the stated use case.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
distributed-systems, machine-learning
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.