Skip to content

load the LoRA from the mounted bucket instead of re-downloading it from the hub - #1616

Closed
EnesYilmazcode wants to merge 1 commit into
modal-labs:mainfrom
EnesYilmazcode:fix/1106-lora-bucket-path
Closed

load the LoRA from the mounted bucket instead of re-downloading it from the hub#1616
EnesYilmazcode wants to merge 1 commit into
modal-labs:mainfrom
EnesYilmazcode:fix/1106-lora-bucket-path

Conversation

@EnesYilmazcode

@EnesYilmazcode EnesYilmazcode commented Jul 14, 2026

Copy link
Copy Markdown

The cloud bucket mount LoRAs example downloads each LoRA into the S3 bucket, then at inference time loads it with self.pipe.load_lora_weights(lora_id, weight_name=file.name). The first argument is lora_id, the Hugging Face repo id, so diffusers resolves the weights from the Hub and downloads them a second time into HF_HUB_CACHE instead of using the copy already sitting in the mounted bucket. That defeats the point of the example, which is to serve LoRAs from S3 ("we load whichever LoRA the user specifies from the S3 bucket").

file is the local path to the .safetensors file inside the mount, found by the rglob on the line above. Passing it as the first argument makes diffusers load straight from disk. Traced through the pinned diffusers==0.26.3: load_lora_weights calls lora_state_dict calls _get_model_file, where os.path.isfile(path) is true for the mount file and the path is returned directly (hub_utils.py), so no Hub download happens. weight_name=file.name is redundant in that branch but harmless, so I kept the change to the single argument.

Fixes #1106.

ruff check and ruff format --check pass on the file (ruff 0.9.6, the version pinned in CI).


Open in Devin Review

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Devin Review found 1 potential issue.

Open in Devin Review

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔍 Pre-existing mismatch between download path and check path in download_lora

In download_lora, the download destination uses repository_path.as_posix().replace('.', '_') (cloud_bucket_mount_loras.py:157), which transforms dots to underscores. However, the existence check at line 154 and the safetensors glob at line 160 both use the original repository_path (without the dot-to-underscore transformation). This means if a repository ID contains dots (e.g. user/model.v2), files would be downloaded to a different directory than where the code later checks for them. This is a pre-existing issue not introduced by this PR, but it's relevant because the inference code at line 195 also uses the untransformed path LORAS_PATH / lora_id to find safetensors files, which would similarly fail for dot-containing repository IDs.

(Refers to lines 154-160)

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

@charlesfrye

Copy link
Copy Markdown
Collaborator

Hello!

Due to incoming review requests exceeding internal review capacity, we are no longer accepting external PRs to this repository and we are closing outstanding external PRs.

Thank you for your interest in Modal and our documentation and apologies for any wasted time (or tokens).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

LoRAs not being loaded from the bucket

2 participants