Skip to main content

1. Model introduction

Stable Diffusion 3.5 Medium is the primary SD3 checkpoint used in miles-diffusion recipes. SD3 uses a DiT transformer with dual text-encoder conditioning (encoder_hidden_states + pooled_projections). Key highlights for RL training:
  • Single DiT component — weight sync targets --update-weight-target-module transformer (default).
  • LoRA on all attention projections (self-attn + cross-attn add projections).
  • Supports Flow-GRPO (OCR) and DiffusionNFT (PickScore) objectives.
  • Gated Hugging Face model — requires HF_TOKEN.

2. Supported variants

Override family detection when the checkpoint name does not match a registered pattern (e.g. a renamed local directory):

3. Environment setup

SD3.5 is gated — export your Hugging Face token:
Optional prefetch:
Prompt datasets live under rockdu/miles-diffusion-datasets: Launch scripts download the matching subset automatically via command_utils.hf_download_dataset. Override the download root with --data-dir (default /root/datasets → /root/datasets/miles-diffusion-datasets).

4. Family config

Registered in miles/backends/fsdp_utils/configs/sd3.py:
Family resolution (resolve_diffusion_model_family) matches --hf-checkpoint names against hf_ckpt_name_patterns. --hf-checkpoint is the single source for the HF repo / local directory used by both FSDP training and sglang-diffusion rollout; pass --diffusion-model-family only to override the auto-detected family.

SD3-specific training behavior

Rollout responses serialize SD3 conditions as single tensors (not lists), unlike some multi-encoder families.

5. Launch

All recipes are Python modules under scripts/. Each exposes a Typer CLI (ScriptArgs dataclass) and submits training through command_utils.execute_train. Common overrides: --cuda-visible-devices, --num-rollout, --data-dir, --extra-args.

5.1 Script inventory

5.2 Flow-GRPO + OCR (2 GPU colocate)

Canonical script: scripts/run_diffusion_grpo_sd3_ocr_sglang.py Status: 🛡️ FG — Fully gated
Walkthrough: Quick Start. E2E test: tests/e2e/short/test_sd3_ocr_grpo_2xGPU.py.

5.3 DiffusionNFT + PickScore (3 GPU)

Script: scripts/run_diffusion_nft_sd3_pickscore.py Status: 🛡️ FG — Fully gated
Smoke test (1 rollout, OCR dataset, 2 GPUs):

Recipe comparison

6. Recipe configuration

GPU layout

GRPO + OCR (default script): 2 GPUs colocated (--colocate); OCR on CPU Ray actors. NFT + PickScore: PickScore runs as a Ray actor pool on a dedicated GPU. With --colocate-reward (not used in the default script), reward workers share rollout GPUs at 0.05 GPU per worker — useful only when GPU count is tight.

Algorithm flags

Flow-GRPO + OCR: DiffusionNFT + PickScore:

7. LoRA and weight sync

Both SD3 recipes use LoRA with IPC weight sync:
See LoRA weight sync for the three updater paths and IPC merge internals.

8. Precision notes

Both SD3 launch scripts use fp16 DiT forward:
SD3.5 fp16 policy gradients are small enough to underflow without scaling. When --diffusion-forward-dtype fp16, the FSDP actor automatically enables ShardedGradScaler around backward / optimizer step (no extra flag — see miles/backends/fsdp_utils/actor.py). bf16/fp32 forward disables the scaler. Flow-GRPO recipes also set --diffusion-clip-range (e.g. 1e-4 in the OCR script) to clip importance ratios during the policy update. Train/rollout dtype alignment for Flow-GRPO is covered in SDE step backend.

9. Reference results

Flow-GRPO + OCR

Observed rollout/reward/raw_mean from one scripts/run_diffusion_grpo_sd3_ocr_sglang.py run (default batch, 600 rollouts). The curve is an example, not a CI acceptance range: Flow-GRPO OCR raw reward Online runs: wandb project miles-diffusion-grpo.

DiffusionNFT + PickScore

Observed rollout/reward/raw_mean from one scripts/run_diffusion_nft_sd3_pickscore.py run (100 rollouts): DiffusionNFT PickScore raw reward Online runs: wandb project miles-diffusion-nft. That run observed held-out eval/pickscore_test ≈ 0.78 with --eval-interval 30 and 50 denoise steps at eval time; this value is not asserted by the E2E fixture.

10. Pairs well with