[diffusion] warmup: default to model sampling resolution (declare Z-Image default)

[mickqian]

Motivation

Server-based image warmup defaulted to an area-capped "representative" resolution (SERVER_WARMUP_IMAGE_MAX_AREA = 768×768). For larger real requests (e.g. 1024×1024) the first request still paid first-shape kernel autotuning — a ~0.1s residual measured on H100, even though warmup ran.

Fix

_resolve_default_warmup_resolution: for image warmup, prefer the model's sampling_defaults width/height (the most likely real request shape) instead of the area-capped representative, so kernels are specialized for the actual shape. Video keeps the area/frame caps (a full-resolution video warmup is far costlier). Representative selection remains the fallback when a model declares no default width/height.

Z-Image declared no default resolution (it accepts arbitrary /16 resolutions, so width/height were left None), and therefore fell back to the cap. Declare its official default 1024×1024 (supported_resolutions stays None = all allowed, so other resolutions still work without spurious warnings).

Verification (H100)

serve --warmup with no explicit --warmup-resolutions now warms at the model default and matches the client-side-warmup baseline:

case	before (area cap)	after (model default)	baseline
FLUX.1-dev	4.80s (warm @ ≤768²)	4.70s (warm @ 1024)	4.68
Ideogram-4	5.26s	5.21s (warm @ 1024)	5.19
Z-Image-Turbo	512 fallback	warms @ 1024	0.65

Relationship

Complements the --warmup dead-zone fix (so server-based warmup actually runs) — that fix is tracked separately. This PR is purely about which resolution the default warmup uses.

🤖 Generated with Claude Code

---

CI States

Latest PR Test (Base): ⏳ Run #28311301454
Latest PR Test (Extra): ❌ Run #28311301354

[gemini-code-assist]

Code Review

This pull request updates the default resolution for Z-Image sampling parameters to 1024x1024 and adjusts the warmup request builder to use the model's default resolution for image generation tasks during server-based warmup, avoiding cold-start autotuning overhead. Feedback suggests evaluating the image generation check lazily to prevent potential attribute errors when server arguments are partially initialized or mocked in tests.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The is_image_gen variable is evaluated unconditionally, even when server_based_warmup is False. When server_based_warmup is False, the condition not server_based_warmup is True, meaning is_image_gen is not needed to determine the outcome.\n\nEvaluating this unconditionally can lead to unnecessary attribute access and potential AttributeError or NoneType errors if server_args is mocked or partially initialized (e.g., in unit tests).\n\nWe can leverage Python's short-circuit evaluation to lazily evaluate is_image_gen only when server_based_warmup is True.

    if (\n        width is not None\n        and height is not None\n        and (not server_based_warmup or server_args.pipeline_config.task_type.is_image_gen())\n    ):

References

1. Enforce defensive programming by ensuring appropriate guards exist before object property accesses, especially when inputs might be partially initialized or mocked in tests.

[mickqian]

/tag-and-rerun-ci