Skip to content

[diffusion] feat: opt-in uint8 rollout video via rollout_video_dtype - #3

Draft
Rockdu wants to merge 1 commit into
feat/rollout-timingfrom
h3-perf-proto
Draft

[diffusion] feat: opt-in uint8 rollout video via rollout_video_dtype#3
Rockdu wants to merge 1 commit into
feat/rollout-timingfrom
h3-perf-proto

Conversation

@Rockdu

@Rockdu Rockdu commented Aug 21, 2026

Copy link
Copy Markdown
Owner

What

rollout_video_dtype on RolloutRequest: "keep" (default, unchanged) returns the decoded video as-is; "uint8" quantises it engine-side before serialisation, with the same formula the training-side reward path applies, so scores are unaffected.

Draft: stacked on feat/rollout-timing. Counterpart of radixark/miles_diffusion#198's --rollout-video-dtype; an older client that never sends the field gets today's behaviour.

Why

H3's rollout response is 1384 MiB of raw float video per sample, of which the consumer keeps 8 of 107 frames after a uint8 cast — 177 GiB moved per 128-sample rollout. Quantising at the source cuts the body to 436 MiB (3.2x). Opt-in because some consumers legitimately need the unquantised tensor.

Validation

  • 17-GPU H3 run with the flag on: resp_bytes 1384 -> 436 MiB, 0 non-200 over the run, log_prob_mean_abs_diff 3.0e-05 (training numerics untouched — they ride the latents, not the video).
  • Reward equivalence: the client-side conversion this mirrors was verified bit-identical across unit-scale/byte-scale/bf16 inputs.

Checklist

  • Unit test for the quantise path — not added
  • Default behaviour unchanged; field absent -> today's payload

CI States

Latest PR Test (Base): ❌ Run #32523050643
Latest PR Test (Extra): ❌ Run #32523050373

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant