Skip to content

--include-adapters and --base-model filters are applied after download — all adapter sizes and names are fetched unnecessarily #3

Description

@lastras

When --adapters points to a HuggingFace adapter library, the entire repository is downloaded before any filtering is applied. Both the model-size filter (derived from --base-model) and the --include-adapters name filter are post-download — meaning adapters for every model size and every adapter name land on disk even when the user requested only a small subset.

Steps to reproduce:
```
python -m granite_switch.composer.compose_granite_switch
--base-model ibm-granite/granite-4.1-3b
--adapters ibm-granite/granitelib-core-r1.0 ibm-granite/granitelib-rag-r1.0
--include-adapters query_rewrite context-attribution
--output ./my-model
```

Expected: Only files under query_rewrite/granite-4.1-3b/ and context-attribution/granite-4.1-3b/ are downloaded from each repo.

Actual: All adapters for all model sizes (3b, 8b, 30b, …) are downloaded in full.

Root cause: resolve_repo_path() calls huggingface_hub.snapshot_download() with no allow_patterns, so the entire repo is fetched. The target-model filter (discover_adapters, adapter_discovery.py:59–71) and the name filter (filter_adapters, adapter_discovery.py:184) both run against the already-complete local copy.

Fix: Construct allow_patterns for snapshot_download from the known filters before the download starts — e.g. ["query_rewrite/granite-4.1-3b/**", "context-attribution/granite-4.1-3b/**"]. This requires detecting the adapter library type (or inferring it from the repo structure) before downloading, or a lightweight metadata-first pass.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions