dstack VS diffusers

We build a similar tool except we focus on AI workloads. Also support on-prem clusters now in addition to GPU clouds. https://github.com/dstackai/dstack

Not exactly this, but something related. At https://github.com/dstackai/dstack, we build an alternative to K8S for AI infra.

You can use https://github.com/dstackai/dstack to deploy your model to the most affordable GPU clouds. It supports auto-scaling and other features.

Disclaimer: I’m the creator of dstack.

Great job on the project! It looks fantastic. Thanks to your post, I discovered Fly's GPUs. We are currently developing a platform called https://github.com/dstackai/dstack that enables users to run any model on any cloud. I am curious if it would be possible to add support for Fly.io as well. If you are interested in collaborating on this, please let me know!

I also noticed that the creator of this app, dstack, is affiliated with Tensordock, the top results for most if not all queries. If that's the case, perhaps a direct link to the cheapest machine could be provided? I haven't used Tensordock, so I don't know if this is mechanically possible.

Here's the repository with all the important links, including documentation, examples, and more: https://github.com/dstackai/dstack

Hey everyone, I'm happy to release dstack Hub, an open-source tool that helps teams manage their ML workflows more effectively without vendor lock-in.

dstack Hub extend dstack [1] with workflow scheduling capabilities and user management. Here's how it works: run dstack Hub via Docker, use its UI to configure projects and cloud credentials, then pass the URL and personal token to the dstack CLI. Now, you can run workflows through the CLI and Hub will orchestrate them in the cloud on your behalf.

This is a beta release and we plan to continuously improve it. We'd love to hear your feedback and answer any questions!

[1] https://github.com/dstackai/dstack

To help you overcome this challenge, we have written an article to guide you through the simple steps of using both diffusers and dstack to generate images from prompts, both locally and in the cloud, using a simple example.

I'm missing something about the random factor, from the sample code from https://github.com/huggingface/diffusers/blob/main/README.md

Hey people, I noticed that combining these two methods in a single forward pass increases the controllability of the generation quite a bit. I was kind of puzzled that sometimes ControlNet yielded better results than T2IAdapter for some cases, and sometimes it was the other way around, so I decided to test both at the same time, and results were quite nice. Some visuals and more motivation here: https://github.com/huggingface/diffusers/issues/5847 And it was already merged here: https://github.com/huggingface/diffusers/pull/5869

Open Parti Prompts: The better way to evaluate diffusion models (repo)

You have disabled the safety checker for by passing `safety_checker=None`. Ensure that you abide to the conditions of the Stable Diffusion license and do not expose unfiltered results in services or applications open to the public. Both the diffusers team and Hugging Face strongly recommend to keep the safety filter enabled in all public facing circumstances, disabling it only for use-cases that involve analyzing network behavior or auditing its results. For more information, please have a look at https://github.com/huggingface/diffusers/pull/254 .

For developers, TensorRT support also exists for the diffusers library via community pipelines. [1] It's limited, but if you're only supporting a subset of features, it can help.

In general, these insane speed boosts comes at the cost of bleeding edge features.

[1] https://github.com/huggingface/diffusers/blob/28e8d1f6ec82a6...

I was training sdxl UNET base model, with the diffusers library, which was going great until around step 210k when the weights suddenly turned back to their original values and stayed that way. I also tried with the ema version, which didn't change at all. I also looked at the tensor's weight values directly which confirmed my suspicions.

Merging LoRAs is essentially taking a weighted average of the LoRA adapter weights. It's more common in other UIs.

diffusers is working on a PR for it: https://github.com/huggingface/diffusers/pull/4473