[misc]: Refactor separate training pipeline runner

[techverve]

What

Decoupled the CLI execution logic from the legacy training pipelines by introducing a centralized runner script (fastvideo/training/runner.py).

Why

To enforce separation of concerns and improve code maintainability. Previously, the legacy training pipelines coupled the class definitions directly with the script execution entry points. This architectural pattern resulted in redundant boilerplate across the codebase and made the pipeline modules harder to test and import in isolation.

How

• Abstracted the main() execution blocks and CLI argument parsing out of the individual pipeline modules.
• Implemented a generic runner.py entry point that uses importlib to dynamically load the target pipeline at runtime via --pipeline_class and --pipeline_module flags.
• Refactored the underlying finetune and distill shell scripts to target the new unified runner.

MERGE WORKFLOW:

1. Ensure pre-commit passes and you have at least 1 approval
2. Comment /merge (or add the "ready" label) to enter the Merge Queue
3. Full Test Suite runs automatically on a staging branch → auto-merge on success

ON-DEMAND TESTING (write access required):
/test full — Full Test Suite /test ssim — SSIM regression
/test training — Training pipeline /test encoder — Encoder tests
/test transformer — Transformer tests /test vae — VAE tests
/test kernel — CUDA kernel tests /test unit — Unit tests
See docs/contributing/pull_requests.md for all 17 test commands

Purpose

Fixes https://linear.app/fastvideo/issue/FAS-215/training-separate-trainingpipeline-class-definition-and-runner-script

Checklist

• I ran pre-commit run --all-files and fixed all issues
• I added or updated tests for my changes
• I updated documentation if needed
• I considered GPU memory impact of my changes

For model/pipeline changes, also check:

• I verified SSIM regression tests pass
• I updated the support matrix if adding a new model

[github-actions]

Welcome to FastVideo! Thanks for your first pull request.

How our CI works:

PRs run a two-tier CI system:

1. Pre-commit — formatting (yapf), linting (ruff), type checking (mypy). Runs immediately on every PR.
2. Fastcheck — core GPU tests (encoders, VAEs, transformers, kernels, unit tests). Runs automatically via Buildkite on relevant file changes (~10-15 min).
3. Full Suite — integration tests, training pipelines, SSIM regression. Runs only when a reviewer adds the ready label.

Before your PR is reviewed:

• pre-commit run --all-files passes locally
• You've added or updated tests for your changes
• The PR description explains what and why

If pre-commit fails, a bot comment will explain how to fix it. Fastcheck and Full Suite results appear in the Checks section below.

Useful links:

• Contributing Guide
• Development Roadmap
• Slack

[mergify]

Merge Protections

🔴 1 of 1 protections blocking · waiting on 👀 reviews and 🤖 CI

	Protection	Waiting on
🔴	PR merge requirements	👀 reviews and 🤖 CI

🔴 PR merge requirements

Waiting for

• #approved-reviews-by>=1
• check-success=full-suite-passed

This rule is failing.

• #approved-reviews-by>=1
• check-success=full-suite-passed
• check-success=fastcheck-passed
• check-success~=pre-commit
• title~=(?i)^\[(feat|feature|bugfix|fix|refactor|perf|ci|doc|docs|misc|chore|kernel|new.?model|skill|skills|infra)\]

[H1yori233]

Thanks for the contribution! This refactor makes sense. However, are many training scripts in the repo that invoke these pipeline files directly. Removing the existing entry points would break downstream compatibility. Could you keep backward-compatible entry points and update the in-repo scripts to use the new runner as well?

[mergify]

Pre-commit checks failed

Hi @techverve, the pre-commit checks have failed. To fix them locally:

# Install pre-commit if you haven't already
uv pip install pre-commit
pre-commit install

# Run all checks and auto-fix what's possible
pre-commit run --all-files

Common fixes:

• yapf: yapf -i <file> (formatting)
• ruff: ruff check --fix <file> (linting)
• codespell: codespell --write-changes <file> (spelling)

After fixing, commit and push the changes. The checks will re-run automatically.

For future commits, pre-commit will run automatically on changed files before each commit.

[techverve]

Thanks for the contribution! This refactor makes sense. However, are many training scripts in the repo that invoke these pipeline files directly. Removing the existing entry points would break downstream compatibility. Could you keep backward-compatible entry points and update the in-repo scripts to use the new runner as well?

Hi @H1yori233 , I have addressed your suggestions could you please have a look again.
Thanks !

[H1yori233]

Thx, LGTM now.