FLUX Modular Diffusers
Collection
Training-free & open-weight FLUX capabilities as one-line Modular Diffusers community pipelines • 11 items • Updated
Terry Rodriguez
terry-remyx
AI & ML interests
None yet
Recent Activity
updated a collection about 1 month ago
FLUX Modular Diffusers updated a collection about 1 month ago
FLUX Modular Diffusers updated a collection about 1 month ago
FLUX Modular DiffusersOrganizations
updated a
collection about 1 month ago
reacted to salma-remyx's post with 🔥 about 1 month ago
Post
2460
New diffusion methods can take months or years to reach
Until then, trying them means working through fragmented research repos with different dependencies, APIs, and implementation choices. Maintainers also can’t review and maintain every promising method in the main repo.
We’re sharing
Each one is adapted to the same
@sayakpaul suggested this path on our HRDiT PR. We added Outrider, our open-source GitHub Action that discovers relevant methods and implements them as draft PRs.
Outrider drafted each pipeline against the repo’s shared conventions. We reviewed the implementations, ran the GPU validation, and published the ones that passed.
This helped us quickly grow the test bed to 10 pipelines covering:
* High-res + panoramic generation: HRDiT, DyPE, Panorama
* Identity + virtual try-on: PuLID, CatVTON
* Image editing + regional control: FlowEdit, KV-Edit, Regional Prompting
* Style + character consistency: StyleAligned, StoryDiffusion
Users get new methods sooner and a consistent way to test them. Maintainers can review the implementation and results without taking on every method in core.
Resources:
🧩 Modular Diffusers: https://huggingface.co/blog/modular-diffusers
🧪 FLUX test bed: https://github.com/remyxai/flux-modular-diffusers
📚 FLUX Modular Diffusers collection: https://huggingface.co/collections/remyxai/flux-modular-diffusers
🤖 Outrider: https://github.com/remyxai/outrider
diffusers.Until then, trying them means working through fragmented research repos with different dependencies, APIs, and implementation choices. Maintainers also can’t review and maintain every promising method in the main repo.
We’re sharing
flux-modular-diffusers as a shared test bed for new FLUX methods. https://github.com/remyxai/flux-modular-diffusersEach one is adapted to the same
ModularPipeline interface, validated with a GPU notebook, and published as its own Hub artifact.@sayakpaul suggested this path on our HRDiT PR. We added Outrider, our open-source GitHub Action that discovers relevant methods and implements them as draft PRs.
Outrider drafted each pipeline against the repo’s shared conventions. We reviewed the implementations, ran the GPU validation, and published the ones that passed.
This helped us quickly grow the test bed to 10 pipelines covering:
* High-res + panoramic generation: HRDiT, DyPE, Panorama
* Identity + virtual try-on: PuLID, CatVTON
* Image editing + regional control: FlowEdit, KV-Edit, Regional Prompting
* Style + character consistency: StyleAligned, StoryDiffusion
Users get new methods sooner and a consistent way to test them. Maintainers can review the implementation and results without taking on every method in core.
Resources:
🧩 Modular Diffusers: https://huggingface.co/blog/modular-diffusers
🧪 FLUX test bed: https://github.com/remyxai/flux-modular-diffusers
📚 FLUX Modular Diffusers collection: https://huggingface.co/collections/remyxai/flux-modular-diffusers
🤖 Outrider: https://github.com/remyxai/outrider
liked a
model about 1 month ago
reacted to salma-remyx's post with 🚀 about 1 month ago
Post
2368
We just published two training-free 🧩 Modular Diffusers community pipelines that push off-the-shelf FLUX to 4096².
No fine-tuning, no extra weights, no upscaler.
The methods take different routes around positional extrapolation:
✅ **HRDiT:** resolution ladder + NTK RoPE + spatial-position alignment + structure guidance
✅ **DyPE:** single-pass, timestep-dynamic RoPE (κ=t²), plus an optional SEGA spectral mode that removes high-frequency speckle
Because both expose the same block interface, you can A/B the two methods on the same FLUX.1-Krea-dev weights by swapping the repo ID:
Both implementations address open
Check out the collection! https://huggingface.co/collections/remyxai/training-free-high-resolution-generation-with-flux
No fine-tuning, no extra weights, no upscaler.
The methods take different routes around positional extrapolation:
✅ **HRDiT:** resolution ladder + NTK RoPE + spatial-position alignment + structure guidance
✅ **DyPE:** single-pass, timestep-dynamic RoPE (κ=t²), plus an optional SEGA spectral mode that removes high-frequency speckle
Because both expose the same block interface, you can A/B the two methods on the same FLUX.1-Krea-dev weights by swapping the repo ID:
import torch
from diffusers import ModularPipeline
repo_id = "remyxai/dype-flux-modular"
# or "remyxai/hrdit-flux-modular"
pipe = ModularPipeline.from_pretrained(
repo_id,
trust_remote_code=True,
)
pipe.load_components(dtype=torch.bfloat16)
pipe.to("cuda")
img = pipe(
prompt="...",
height=4096,
width=4096,
).images[0]Both implementations address open
diffusers requests (#14480, #14520).Check out the collection! https://huggingface.co/collections/remyxai/training-free-high-resolution-generation-with-flux
liked 2
models about 1 month ago
reacted to salma-remyx's post with ❤️ about 2 months ago
Post
2729
If you can’t explain why your AI-generated contribution belongs in the repo, don’t put it in a maintainer’s queue 🙅🏻♀️
Before asking for review, you should be able to answer:
1. What project need does it address?
2. Where does it fit, and does it duplicate existing work?
3. What evidence shows it works, and will you own it through review?
If you can’t answer those, you haven’t saved anyone time. You’ve passed the buck to the maintainer.
Outrider has made us better contributors by doing more of this work before upstream review by
* reading contribution rules, accepted PRs, and open issues
* finding needs and integration points
* drafting the code, tests, and context.
We still decide what deserves to go upstream, verify the claims, coordinate with maintainers and contributors, and stay involved through review.
On huggingface/peft, only 4 of 20 Outrider runs opened draft PRs. Two contributions have now merged:
✅ Riemannian-preconditioned LoRA: https://github.com/huggingface/peft/pull/3382
✅ Super-Tuning: https://github.com/huggingface/peft/pull/3518
We have more contributions in review and far more ideas were filtered out before they reached a maintainer.
Full case study: https://remyx.ai/case-study
Outrider: https://github.com/remyxai/outrider
Before asking for review, you should be able to answer:
1. What project need does it address?
2. Where does it fit, and does it duplicate existing work?
3. What evidence shows it works, and will you own it through review?
If you can’t answer those, you haven’t saved anyone time. You’ve passed the buck to the maintainer.
Outrider has made us better contributors by doing more of this work before upstream review by
* reading contribution rules, accepted PRs, and open issues
* finding needs and integration points
* drafting the code, tests, and context.
We still decide what deserves to go upstream, verify the claims, coordinate with maintainers and contributors, and stay involved through review.
On huggingface/peft, only 4 of 20 Outrider runs opened draft PRs. Two contributions have now merged:
✅ Riemannian-preconditioned LoRA: https://github.com/huggingface/peft/pull/3382
✅ Super-Tuning: https://github.com/huggingface/peft/pull/3518
We have more contributions in review and far more ideas were filtered out before they reached a maintainer.
Full case study: https://remyx.ai/case-study
Outrider: https://github.com/remyxai/outrider
- 11 replies
reacted to salma-remyx's post with 🚀 about 2 months ago
Post
3535
Inspired by the methods described in "Batch-wise Adaptive Pruning" (arxiv 2608.14003, COLM '26), we implemented a training-free FFN-neuron-pruning knob for SGLang.
Authors were motivated by the reality that decode is HBM-bandwidth-bound; the gated MLP is the bulk of weights read per step. Threshold methods (TEAL/CATS) collapse under batching; BWAP's periodic top-k over a max-aggregated score keeps the shared batch mask stable.
The method is complementary to KV-sparsity (FFN-weight bandwidth vs KV read, context-length-independent).
Our implementation uses an adaptive mask under a captured graph (topology static = k-wide GEMM; mask change = between-replay buffer update via version-gated post_fill; prune steps replay, explore steps eager).
Preliminary Results GSM8K n=50, ±6pp: 7B dense 92% → ρ=0.5 84% (−8pp) at up to 1.40× (probe ceiling; ~10% realistic under the adaptive schedule; smaller models need lower ρ as accuracy scales with size).
Read more in the upstream issue: https://github.com/sgl-project/sglang/issues/35987
Authors were motivated by the reality that decode is HBM-bandwidth-bound; the gated MLP is the bulk of weights read per step. Threshold methods (TEAL/CATS) collapse under batching; BWAP's periodic top-k over a max-aggregated score keeps the shared batch mask stable.
The method is complementary to KV-sparsity (FFN-weight bandwidth vs KV read, context-length-independent).
Our implementation uses an adaptive mask under a captured graph (topology static = k-wide GEMM; mask change = between-replay buffer update via version-gated post_fill; prune steps replay, explore steps eager).
Preliminary Results GSM8K n=50, ±6pp: 7B dense 92% → ρ=0.5 84% (−8pp) at up to 1.40× (probe ceiling; ~10% realistic under the adaptive schedule; smaller models need lower ρ as accuracy scales with size).
Read more in the upstream issue: https://github.com/sgl-project/sglang/issues/35987
- 5 replies
reacted to TravisMuhlestein's post with ❤️ about 2 months ago
Post
3870
One of the most underrated parts of AI-assisted engineering may have nothing to do with the model.
It's the infrastructure around the engineer.
Shriyash Balshetwar and Shubham Jangle, engineers at GoDaddy, were spending roughly 16 mechanical pull requests per week managing localization branches. None of the work was particularly difficult—it was repetitive, easy to forget, and occasionally capable of blocking releases.
They built a GitHub App to remove the entire workflow.
What I find interesting is what happened underneath the simple idea of "automate the PRs."
The production system needed idempotent webhook handling, installation-scoped authentication, retry logic around GitHub's asynchronous mergeability state, per-repository configuration, and safe pattern matching.
The app itself is under 900 lines of JavaScript.
The interesting lesson is that the hard part of automation isn't always the automation.
It's building the reliability around it.
As AI agents take on more software engineering tasks, I expect this distinction to become even more important. The systems surrounding an agent—events, permissions, state, retries, validation, and feedback—may matter as much as the model making the decision.
🔗 https://www.godaddy.com/resources/news/how-a-github-app-saved-us-hours-of-manual-effort
Curious what other engineering workflows people have found worth automating end-to-end.
It's the infrastructure around the engineer.
Shriyash Balshetwar and Shubham Jangle, engineers at GoDaddy, were spending roughly 16 mechanical pull requests per week managing localization branches. None of the work was particularly difficult—it was repetitive, easy to forget, and occasionally capable of blocking releases.
They built a GitHub App to remove the entire workflow.
What I find interesting is what happened underneath the simple idea of "automate the PRs."
The production system needed idempotent webhook handling, installation-scoped authentication, retry logic around GitHub's asynchronous mergeability state, per-repository configuration, and safe pattern matching.
The app itself is under 900 lines of JavaScript.
The interesting lesson is that the hard part of automation isn't always the automation.
It's building the reliability around it.
As AI agents take on more software engineering tasks, I expect this distinction to become even more important. The systems surrounding an agent—events, permissions, state, retries, validation, and feedback—may matter as much as the model making the decision.
🔗 https://www.godaddy.com/resources/news/how-a-github-app-saved-us-hours-of-manual-effort
Curious what other engineering workflows people have found worth automating end-to-end.
- 6 replies
reacted to salma-remyx's post with 🔥 2 months ago
Post
2006
Auto mode for coding agents has improved over the last year.
Devs are relying more on them for code review, and less on manual line-by-line checks.
But this leaves coding agents vulnerable to indirect injection attacks.
IssueTrojanBench (arxiv 2607.20759) studies this in the context of malicious issue requests.
I also observed these prompt injection vulnerabilities in my own harness, testing on the issue: https://github.com/smellslikeml/curator/issues/3
But even red teaming your own repos with toy examples like this can trigger AI safeguards and corrupt your session.
Adopting popular mitigation techniques like 'spotlighting' and 'known answer detection' can help but the researchers show it's not enough.
So our latest updates to Outrider implement additional layers for greater defense-in-depth to ensure that by time a human has to review the code, we've filtered this kind noise.
Devs are relying more on them for code review, and less on manual line-by-line checks.
But this leaves coding agents vulnerable to indirect injection attacks.
IssueTrojanBench (arxiv 2607.20759) studies this in the context of malicious issue requests.
I also observed these prompt injection vulnerabilities in my own harness, testing on the issue: https://github.com/smellslikeml/curator/issues/3
But even red teaming your own repos with toy examples like this can trigger AI safeguards and corrupt your session.
Adopting popular mitigation techniques like 'spotlighting' and 'known answer detection' can help but the researchers show it's not enough.
So our latest updates to Outrider implement additional layers for greater defense-in-depth to ensure that by time a human has to review the code, we've filtered this kind noise.
- 2 replies