Will Lin
1fe50c0092
The v2 top level had grown to ~27 dirs + 13 loose files — half of them
single-concept abstraction shells (memory/ 86 LOC, transport/ 222, parity/ 178,
extend/ 226) and half vendored fastvideo code sitting as peers to the actual v2
design. Regroup to mirror README section 3 "Planes & dependency order":
core/ enums+types, card, loop, program, parity, request, parallel
(the model-native contracts; no kernels)
runtime/ + folded-in substrate: cache, memory, transport, extend
(the import graph shows only runtime consumes them; compile/cudagraph
already lived here)
serving/ + deploy/ (products / fleet)
_vendor/ all copied fastvideo: models, layers, attention, configs, distributed,
platforms, api, hooks, logging_utils, third_party + fastvideo_args/
utils/logger/envs/forward_context — internal layout unchanged, still
mirrors upstream for diffing
28 dirs + 13 root files -> 8 dirs + 6 root files. Pure mechanical move: 947
absolute-import paths rewritten (v2.X -> v2.{core,runtime,serving,_vendor}.X),
boundary-anchored so platform/ (native dispatch) and platforms/ (vendored CUDA
detect) no longer collide and neither does hooks/ vs extend/. Deleted the empty
v2/loader/. README section 3 + 16 updated; stale test count corrected
(34 files/216 tests -> 22 files/143 tests).
Validated: `import v2` stays torch-free; `v2/run_tests.py` and `pytest v2/tests/`
-> 143 passed, 2 skipped on the numpy toy backend. (On a GPU box force the toy
backend with CUDA_VISIBLE_DEVICES="" or detect() picks cuda.) No external importer
changed — examples use the re-exported `from v2 import VideoGenerator`.
v2_examples/training — training & RL on the same loops
Runnable examples of every training method in v2. The load-bearing idea (designv4 §8): a method's
rollout drives the same loop the engine serves (in the ROLLOUT profile, with behavior capture) — there
is one numerics surface, not a second sampler. Each method differs only in loss math, roles, and capture.
CPU + numpy only; the toy ToyDiT.mse_grad_step / ToyPromptRefiner.pg_step are real gradient steps,
so the toy students actually learn — the structural stand-in for an FSDP/optimizer step. Run from anywhere:
python3 v2_examples/training/03_rl_diffusion_nft.py
| Script | Method | Kind |
|---|---|---|
01_finetune.py |
flow-match finetuning | supervised |
02_distillation_dmd2.py |
DMD2 (student + fake-score critic + teacher) | distillation |
03_rl_diffusion_nft.py |
DiffusionNFT (samples from the decay-blended old policy) | RL, likelihood-free (C2) |
04_self_forcing.py |
self-forcing on the causal chunk_rollout loop |
causal distillation |
05_joint_lm_generator_rl.py |
UniRL/PromptRL: LM refiner + flow generator, one reward | joint RL, likelihood-based (C2) |
06_nway_joint_rl.py |
N refiner experts + generator, one reward | N-way joint RL |
07_end_to_end_workflow_rl.py |
T2I + I2V trained from one final-video reward | end-to-end RL across a workflow |
Every method exposes the same entry point: method.train_step(batch, iteration) -> (loss_map, metrics).
RL methods (manages_optimization() == True) own their sample→score→update cadence inside that call.
See designv4 §9.3 (joint RL), §9.7 (N-way), §9.9 (workflow RL).