HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
basujindal
stable-diffusion
Jupyter Notebook2022–2022
basujindal / stable-diffusion

stable-diffusion

Optimized Stable Diffusion modified to run on lower GPU VRAM

23Distinct people
28Mentions
0Explicit recommenders
3.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Optimized Stable Diffusion modified to run on lower GPU VRAM

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by day28 dated mentions

Observed mentions: 2022-08-22 20:22:24 UTC to 2022-09-19 18:13:14 UTC.

0369122022-08-22 00:00:00 UTC to 2022-08-23 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 commentsAug 222022-08-23 00:00:00 UTC to 2022-08-24 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-08-24 00:00:00 UTC to 2022-08-25 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-08-25 00:00:00 UTC to 2022-08-26 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022-08-26 00:00:00 UTC to 2022-08-27 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-08-27 00:00:00 UTC to 2022-08-28 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-08-28 00:00:00 UTC to 2022-08-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-08-29 00:00:00 UTC to 2022-08-30 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-08-30 00:00:00 UTC to 2022-08-31 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-08-31 00:00:00 UTC to 2022-09-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-09-01 00:00:00 UTC to 2022-09-02 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-02 00:00:00 UTC to 2022-09-03 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-03 00:00:00 UTC to 2022-09-04 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-04 00:00:00 UTC to 2022-09-05 00:00:00 UTC (exclusive): 12 mentions; 1 submissions, 11 comments2022-09-05 00:00:00 UTC to 2022-09-06 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsSep 52022-09-06 00:00:00 UTC to 2022-09-07 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-07 00:00:00 UTC to 2022-09-08 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-08 00:00:00 UTC to 2022-09-09 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-09 00:00:00 UTC to 2022-09-10 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-10 00:00:00 UTC to 2022-09-11 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-11 00:00:00 UTC to 2022-09-12 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-12 00:00:00 UTC to 2022-09-13 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-13 00:00:00 UTC to 2022-09-14 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-14 00:00:00 UTC to 2022-09-15 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-15 00:00:00 UTC to 2022-09-16 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-16 00:00:00 UTC to 2022-09-17 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-09-17 00:00:00 UTC to 2022-09-18 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-18 00:00:00 UTC to 2022-09-19 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-19 00:00:00 UTC to 2022-09-20 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsSep 19

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Aug 222022-08-22 00:00:00 UTC2022-08-23 00:00:00 UTC202
Aug 232022-08-23 00:00:00 UTC2022-08-24 00:00:00 UTC101
Aug 242022-08-24 00:00:00 UTC2022-08-25 00:00:00 UTC101
Aug 252022-08-25 00:00:00 UTC2022-08-26 00:00:00 UTC202
Aug 262022-08-26 00:00:00 UTC2022-08-27 00:00:00 UTC101
Aug 272022-08-27 00:00:00 UTC2022-08-28 00:00:00 UTC000
Aug 282022-08-28 00:00:00 UTC2022-08-29 00:00:00 UTC000
Aug 292022-08-29 00:00:00 UTC2022-08-30 00:00:00 UTC000
Aug 302022-08-30 00:00:00 UTC2022-08-31 00:00:00 UTC303
Aug 312022-08-31 00:00:00 UTC2022-09-01 00:00:00 UTC303
Sep 12022-09-01 00:00:00 UTC2022-09-02 00:00:00 UTC000
Sep 22022-09-02 00:00:00 UTC2022-09-03 00:00:00 UTC000
Sep 32022-09-03 00:00:00 UTC2022-09-04 00:00:00 UTC000
Sep 42022-09-04 00:00:00 UTC2022-09-05 00:00:00 UTC12111
Sep 52022-09-05 00:00:00 UTC2022-09-06 00:00:00 UTC101
Sep 62022-09-06 00:00:00 UTC2022-09-07 00:00:00 UTC000
Sep 72022-09-07 00:00:00 UTC2022-09-08 00:00:00 UTC000
Sep 82022-09-08 00:00:00 UTC2022-09-09 00:00:00 UTC000
Sep 92022-09-09 00:00:00 UTC2022-09-10 00:00:00 UTC000
Sep 102022-09-10 00:00:00 UTC2022-09-11 00:00:00 UTC000
Sep 112022-09-11 00:00:00 UTC2022-09-12 00:00:00 UTC000
Sep 122022-09-12 00:00:00 UTC2022-09-13 00:00:00 UTC000
Sep 132022-09-13 00:00:00 UTC2022-09-14 00:00:00 UTC000
Sep 142022-09-14 00:00:00 UTC2022-09-15 00:00:00 UTC000
Sep 152022-09-15 00:00:00 UTC2022-09-16 00:00:00 UTC000
Sep 162022-09-16 00:00:00 UTC2022-09-17 00:00:00 UTC101
Sep 172022-09-17 00:00:00 UTC2022-09-18 00:00:00 UTC000
Sep 182022-09-18 00:00:00 UTC2022-09-19 00:00:00 UTC000
Sep 192022-09-19 00:00:00 UTC2022-09-20 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Optimized Stable Diffusion This repo is a modified version of the Stable Diffusion repo, optimized to use less VRAM than the original by sacrificing inference speed. To reduce the VRAM usage, the following opimizations are used: the stable diffusion model is fragmented into four parts which are sent to the GPU only when needed. After the calculation is done, they are moved back to the CPU. The attention calculation is done in parts. Installation All the modified files are in the optimizedSD folder, so if you have already cloned the original repository you can just download and copy this folder into the original instead of cloning the entire repo. You can also clone this repo and follow the same installation steps as the original (mainly creating the conda environment and placing the weights at the specified location). Alternatively, if you prefer to use Docker, you can do the following: Install Docker, Docker Compose plugin, and NVIDIA Container Toolkit Clone this repo to, e.g., ~/stable-diffusion Put your downloaded model.ckpt file into ~/sd-data (it's a relative path, you can change it in docker-compose.yml) cd into ~/stable-diffusion and execute docker compose up --build This will launch gradio on port 7860 with txt2img. You can also use docker compose run to execute other Python scripts. Usage img2img img2img can generate 512x512 images from a prior image and prompt using under 2.4GB VRAM in under 20 seconds per image on an RTX 2060. The maximum size that can fit on 6GB GPU (RTX 2060) is around 1152x1088. For example, the following command will generate 10 512x512 images: python optimizedSD/optimized_img2img.py --prompt "Austrian alps" --init-img ~/sketch-mountains-input.jpg --strength 0.8 --n_iter 2 --n_samples 5 --H 512 --W 512 txt2img txt2img can generate 512x512 images from a prompt using under 2.4GB GPU VRAM in under 24 seconds per image on an RTX 2060. For example, the following command will generate 10 512x512 images: python optimizedSD/optimized_txt2img.py --prompt "Cyberpunk style image of a Tesla car reflection in rain" --H 512 --W 512 --seed 27 --n_iter 2 --n_samples 5 --ddim_steps 50 inpainting inpaint_gradio.py can fill masked parts of an image based on a given prompt. It can inpaint 512x512 images while using under 2.5GB of VRAM. To launch the gradio interface for inpainting, run python optimizedSD/inpaint_gradio.py. The mask for the image can be drawn on the selected image using the brush tool. The results are not yet perfect but can be improved by using a combination of prompt weighting, prompt engineering and testing out multiple values of the --strength argument. Suggestions to improve the inpainting algorithm are most welcome. Using the Gradio GUI You can also use the built-in gradio interface for img2img, txt2img & inpainting instead of the command line interface. Activate the conda environment and install the latest version of gradio using pip install gradio, Run img2img using python optimizedSD/img2img_gradio.py, txt2img using python optimizedSD/txt2img_gradio.py and inpainting using python optimizedSD/inpaint_gradio.py. img2img_gradio.py has a feature to crop input images. Look for the pen symbol in the image box after selecting the image. Arguments --seed Seed for image generation, can be used to reproduce previously generated images. Defaults to a random seed if unspecified. The code will give the seed number along with each generated image. To generate the same image again, just specify the seed using --seed argument. Images are saved with its seed number as its name by default. For example if the seed number for an image is 1234 and it's the 55th image in the folder, the image name will be named seed_1234_00055.png. --n_samples Batch size/amount of images to generate at once. To get the lowest inference time per image, use the maximum batch size --n_samples that can fit on the GPU. Inference time per image will reduce on increasing the batch size, but the required VRAM will increase. If you get a CUDA out of memory error, try reducing the batch size --n_samples. If it doesn't work, the other option is to reduce the image width --W or height --H or both. --n_iter Run x amount of times Equivalent to running the script n_iter number of times. Only difference is that the model is loaded only once per n_iter iterations. Unlike n_samples, reducing it doesn't have an effect on VRAM required or inference time. --H & --W Height & width of the generated image. Both height and width should be a multiple of 64. --turbo Increases inference speed at the cost of extra VRAM usage. Using this argument increases the inference speed by using around 700MB of extra GPU VRAM. It is especially effective when generating a small batch of images (~ 1 to 4) images. It takes under 20 seconds for txt2img and 15 seconds for img2img (on an RTX 2060, excluding the time to load the model). Use it on larger batch sizes if GPU VRAM available. --precision autocast or --precision full Whether to use full or mixed precision Mixed Precision is enabled by default. If you don't have a GPU with tensor cores (any GTX 10 series card), you may not be able use mixed precision. Use the --precision full argument to disable it. --format png or --format jpg Output image format The default output format is png. While png is lossless, it takes up a lot of space (unless large portions of the image happen to be a single colour). Use lossy jpg to get smaller image file sizes. --unet_bs Batch size for the unet model Takes up a lot of extra RAM for very little improvement in inference time. unet_bs > 1 is not recommended! Should generally be a multiple of 2x(n_samples) Weighted Prompts Prompts can also be weighted to put relative emphasis on certain words. eg. --prompt tabby cat:0.25 white duck:0.75 hybrid. The number followed by the colon represents the weight given to the words before the colon. The weights can
Read the full README on GitHub

What Hacker News says

28 sources
in this case a lot of the large change is actually "upstream". We Have Neon, who is making a PR. We have Upstream, SD source. We have basu, repo maintainer. Neon pulled in upstream changes, and are trying to merge those into basu's repo AND then on top of that, apply neon edits to the code. Ways to make this cleaner: - Basu pulls in upstream changes, Neon just puts theirs on top. (Slow, you have to wait for Basu) - Neon makes two PRs, one to pull in upstream changes, another for his edits on top of those changes. (More work, and coordination, but each PR is "one unit of work") - Better commit messages: https://github.com/basujindal/stable-diffusion/pull/103#comm... <- notice the repeated and non-descript commit messages? That makes it hard for non-experts to cherry pick out the bits that are really relevant. (Fastest)
In Stable Diffusion PR optimizes VRAM, generate 576x1280 images with 6 GB VRAM

Showing the 15 most recent of 28 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.