[None][feat] add FLUX visual generation examples#14987
Conversation
|
/bot run --disable-fail-fast |
📝 WalkthroughWalkthroughThis PR extends the FLUX text-to-image generation examples by adding two new Python CLI scripts (flux1.py and flux2.py), corresponding single-GPU NVFP4 quantization configurations, and usage documentation. Both scripts implement identical CLI and generation workflows using the existing VisualGen API. ChangesFLUX Model Examples and Configuration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
examples/visual_gen/models/flux2.py (1)
37-37: ⚡ Quick winAdd return type annotation to
main().Per the coding guidelines, functions should always be annotated: "Always annotate functions. Make the return type
Noneif the function does not return anything." As per coding guidelines, Python functions and methods should use snake_case (e.g.,def my_awesome_function():), and type annotations should be complete.📝 Suggested fix
-def main(): +def main() -> None:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@examples/visual_gen/models/flux2.py` at line 37, The function definition for main lacks a return type annotation; update the signature of main (def main) to include an explicit return type of None (e.g., change to def main() -> None:) to satisfy the "Always annotate functions" guideline and keep the existing snake_case name; ensure any internal or related function docstrings/type hints remain consistent with the new annotation.examples/visual_gen/models/flux1.py (1)
37-37: ⚡ Quick winAdd return type annotation to
main().Per the coding guidelines, functions should always be annotated: "Always annotate functions. Make the return type
Noneif the function does not return anything." As per coding guidelines, Python functions and methods should use snake_case (e.g.,def my_awesome_function():), and type annotations should be complete.📝 Suggested fix
-def main(): +def main() -> None:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@examples/visual_gen/models/flux1.py` at line 37, The function definition for main lacks a return type annotation; update the signature of the main function (def main()) to include an explicit return type of None (i.e., def main() -> None:) per the coding guidelines, and verify the function name follows snake_case (main is fine) and that any other functions in this module likewise have complete type annotations.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@examples/visual_gen/models/flux1.py`:
- Line 37: The function definition for main lacks a return type annotation;
update the signature of the main function (def main()) to include an explicit
return type of None (i.e., def main() -> None:) per the coding guidelines, and
verify the function name follows snake_case (main is fine) and that any other
functions in this module likewise have complete type annotations.
In `@examples/visual_gen/models/flux2.py`:
- Line 37: The function definition for main lacks a return type annotation;
update the signature of main (def main) to include an explicit return type of
None (e.g., change to def main() -> None:) to satisfy the "Always annotate
functions" guideline and keep the existing snake_case name; ensure any internal
or related function docstrings/type hints remain consistent with the new
annotation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 7e50b627-95ac-4aa2-8494-3f815f4a459e
📒 Files selected for processing (5)
examples/visual_gen/README.mdexamples/visual_gen/configs/flux1-dev-fp4-1gpu.yamlexamples/visual_gen/configs/flux2-dev-fp4-1gpu.yamlexamples/visual_gen/models/flux1.pyexamples/visual_gen/models/flux2.py
|
PR_Github #52232 [ run ] triggered by Bot. Commit: |
karljang
force-pushed
the
feat/flux-examples
branch
from
cd9bde1 to
f509cb9
Compare
|
/bot run --disable-fail-fast |
|
PR_Github #52273 [ run ] triggered by Bot. Commit: |
|
PR_Github #52232 [ run ] completed with state |
|
PR_Github #52273 [ run ] completed with state
|
Signed-off-by: Kanghwan Jang <861393+karljang@users.noreply.github.com>
karljang
force-pushed
the
feat/flux-examples
branch
from
f509cb9 to
cacf20b
Compare
|
/bot run --disable-fail-fast |
|
PR_Github #52391 [ run ] triggered by Bot. Commit: |
3 participants
Description
Add lightweight VisualGen examples for FLUX.1 and FLUX.2, following the per-model example pattern used by
models/wan_t2v.pyand PR #14981:examples/visual_gen/models/flux1.pyexamples/visual_gen/models/flux2.pyThe examples start from
visual_gen.default_params, setnum_images_per_prompt, and save either one image or indexed image outputs for multi-image generation.Test Coverage
python3 -m py_compile examples/visual_gen/models/flux1.py examples/visual_gen/models/flux2.pygit diff --checkpre-commit run --files examples/visual_gen/README.md examples/visual_gen/models/flux1.py examples/visual_gen/models/flux2.py examples/visual_gen/configs/flux1-dev-fp4-1gpu.yaml examples/visual_gen/configs/flux2-dev-fp4-1gpu.yamlPR Checklist
Please review the following before submitting your PR:
PR description clearly explains what and why. If using CodeRabbit's summary, please make sure it makes sense.
PR Follows TRT-LLM CODING GUIDELINES to the best of your knowledge.
Test cases are provided for new code paths (see test instructions)
If PR introduces API changes, an appropriate PR label is added - either
api-compatibleorapi-breaking. Forapi-breaking, includeBREAKINGin the PR title.Any new dependencies have been scanned for license and vulnerabilities
CODEOWNERS updated if ownership changes
Documentation updated as needed
Update tava architecture diagram if there is a significant design change in PR.
The reviewers assigned automatically/manually are appropriate for the PR.
Please check this after reviewing the above items as appropriate for this PR.
Summary by CodeRabbit
Documentation
New Features