Related Pages

Related topics: Supported PEFT Methods and Tuner Architecture, Configuration, Training Workflow & Troubleshooting

Introduction, Installation & Quickstart

What is PEFT

PEFT (Parameter-Efficient Fine-Tuning) is a Hugging Face library that enables adapting large pre-trained models to downstream tasks by training only a small number of additional parameters, leaving the original model weights frozen. The library integrates with the Hugging Face ecosystem, particularly transformers, diffusers, and accelerate, and is designed to make fine-tuning large language and diffusion models computationally tractable on consumer hardware. Source: README.md:1-15

The library currently supports a broad catalog of methods, including LoRA, prefix tuning, prompt tuning, P-tuning, IA³, AdaLoRA, LoHa, LoKr, OFT, HRA, SHiRA, and many more recent additions such as GraLoRA, RoAd, ALoRA, Arrow, WaveFT, DeLoRA, and OSF introduced across the 0.16–0.19 release line. Source: docs/source/index.md:1-40

Installation

PEFT is distributed as a regular Python package on PyPI and can be installed with pip. The minimum runtime requirements are documented in the install guide and historically require torch >= 1.13 plus a recent transformers. Source: docs/source/install.md:1-30

pip install peft

For users who want to test unreleased changes or contribute, an editable install from a local clone is recommended:

git clone https://github.com/huggingface/peft
cd peft
pip install -e .

Optional integrations are surfaced through the standard transformers, accelerate, and (optionally) safetensors/bitsandbytes/tiktoken extra dependencies. As of v0.18.1, PEFT also ships fixes that allow it to run on AMD ROCm environments. Source: docs/source/install.md:31-60, Release v0.18.1:1-5

Public API Surface

The top-level peft package re-exports the most commonly used classes, configuration objects, and helper functions. Notable entries include the config classes (LoraConfig, PrefixTuningConfig, PromptTuningConfig, PromptEncoderConfig, IA3Config, AdaLoraConfig, etc.), the model wrappers (PeftModel, PeftModelForCausalLM, PeftModelForSeq2SeqLM, PeftModelForSequenceClassification), and convenience functions like get_peft_model, inject_adapter_in_model, prepare_model_for_kbit_training, and load_peft_weights. Source: src/peft/__init__.py:1-120

This single import surface lets users mix and match PEFT methods without needing to learn module-internal paths:

from peft import LoraConfig, get_peft_model, PeftModel

Quickstart: Fine-Tuning with LoRA

The standard quickstart workflow has three steps: load a base model, wrap it with a PEFT config, and train or infer. The quicktour documentation walks through this end-to-end. Source: docs/source/quicktour.md:1-60

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import LoraConfig, get_peft_model

model_id = "meta-llama/Llama-2-7b-hf"
model = AutoModelForCausalLM.from_pretrained(model_id, torch_dtype=torch.bfloat16, device_map="auto")
tokenizer = AutoTokenizer.from_pretrained(model_id)

lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

model = get_peft_model(model, lora_config)
model.print_trainable_parameters()

get_peft_model freezes the base weights, injects the LoRA adapter modules, and returns a PeftModel whose trainable-parameter count is typically <1% of the base model. Source: docs/source/quicktour.md:60-100

Loading and Sharing Adapters

After training, only the lightweight adapter weights need to be persisted. They can be saved with model.save_pretrained("my_adapter") and later reloaded with PeftModel.from_pretrained(base_model, "my_adapter"). This is the workflow used in the README's common examples and is the recommended way to share adapters on the Hugging Face Hub. Source: README.md:40-80

A common alternative is to merge the adapter back into the base weights for deployment:

merged_model = model.merge_and_unload()

This is particularly relevant for environments like GPT-2 era models and smaller deployments where loading a separate adapter at inference time is inconvenient. Source: Issue #365:1-8

High-Level Workflow

The end-to-end lifecycle can be summarized as a linear flow from a frozen base model to a deployable artifact.

flowchart LR
    A[Base Model<br/>from_pretrained] --> B[PEFT Config<br/>LoraConfig, ...]
    B --> C[get_peft_model<br/>freeze + inject]
    C --> D[Train / Continue<br/>fine-tuning]
    D --> E[save_pretrained<br/>adapter only]
    E --> F{Deploy?}
    F -- "Yes" --> G[PeftModel.from_pretrained]
    F -- "Merge" --> H[merge_and_unload]
    G --> I[Inference]
    H --> I

Common Pitfalls Seen in the Community

Several recurring issues surface in the issue tracker and are worth being aware of when starting out:

• target_modules is matched against module names as strings, and the library normalizes them through a set during weight conversion. If a module is not recognized, no adapter is injected, and the trainable-parameter count will be smaller than expected. Source: Issue #3229:1-15
• When continuing training, users must re-instantiate the optimizer and scheduler against the PEFT model — attempting to resume with the original optimizer state causes "element 0 of tensors does not require grad" errors. Source: Issue #137:1-17, Issue #184:1-14
• Older CUDA stacks (e.g., CUDA 10.2 with torch <= 1.12) are unsupported because the package requires torch >= 1.13. Source: Issue #207:1-18

Versioning and Releases

PEFT follows semantic versioning and ships minor releases on a roughly quarterly cadence. The most recent releases add new adapter families almost every cycle: v0.19.0 introduced nine new methods including GraLoRA, v0.18.0 added RoAd, ALoRA, Arrow, WaveFT, DeLoRA, and OSF, and v0.17.0 brought SHiRA, MiSS, and MoE-friendly LoRA targeting. Patch releases (e.g., v0.19.1, v0.18.1, v0.17.1) focus on regressions such as modules_to_save handling under DeepSpeed ZeRO-3 and compatibility with the upcoming transformers v5. Source: Release v0.19.0:1-30, Release v0.18.0:1-20, Release v0.17.0:1-20, Release v0.19.1:1-5

For new users, pinning to the latest patch release on the most recent minor is generally the safest starting point.

Related Pages

Related topics: Introduction, Installation & Quickstart, Configuration, Training Workflow & Troubleshooting

Supported PEFT Methods and Tuner Architecture

The peft library provides a unified, pluggable framework for Parameter-Efficient Fine-Tuning (PEFT) of large pretrained models. Its design centers on a tuner abstraction, where each supported PEFT method (LoRA, AdaLoRA, prompt tuning, IA³, etc.) is implemented as a self-contained module under src/peft/tuners/. A central registry maps user-facing string identifiers to the corresponding tuner classes, allowing methods to be selected via PeftModel.from_pretrained(..., peft_config=...) without users needing to import the underlying tuner directly.

1. The Tuner Plugin Architecture

Every PEFT method lives under src/peft/tuners/<method_name>/ and follows a three-file convention:

• config.py — a PeftConfig subclass defining hyperparameters
• model.py — the PeftModel subclass that injects adapters into a base model
• layer.py — the actual torch.nn.Module adapters (e.g. LoRA's Linear)

A shared base class, BaseTuner, lives in src/peft/tuners/tuners_utils.py and provides common machinery: target-module discovery, layer replacement, parameter freezing, and modules_to_save handling. LoRA's model class extends this base:

Source: src/peft/tuners/lora/model.py:1-30

class LoraModel(BaseTuner):
    prefix: str = "lora_"

    def __init__(self, model, config, adapter_name):
        super().__init__(model, config, adapter_name)
        ...

The prefix attribute is reserved on the base model so that adapter parameters can be identified unambiguously even when multiple adapters are attached to the same layer. Source: src/peft/tuners/tuners_utils.py:100-160

2. Method Registration via the Mapping

The src/peft/mapping.py module is the single source of truth for which methods exist. It exposes a PEFT_TYPE_TO_CONFIG_MAPPING (string name → PeftConfig class) and PEFT_TYPE_TO_TUNER_MAPPING (string name → PeftModel class). When a user calls get_peft_model(model, peft_config), peft looks up peft_config.peft_type in these dicts to dispatch to the correct tuner.

Source: src/peft/mapping.py:1-40

PEFT_TYPE_TO_CONFIG_MAPPING: dict[str, type[PeftConfig]] = {
    "LORA": LoraConfig,
    "ADALORA": AdaLoraConfig,
    "PROMPT_TUNING": PromptTuningConfig,
    "P_TUNING": PromptEncoderConfig,
    "PREFIX_TUNING": PrefixTuningConfig,
    "IA3": IA3Config,
    ...
}

This indirection means new methods are added by (a) creating a tuner directory, (b) importing the config and model classes, and (c) registering them in the two mappings.

3. Currently Supported PEFT Methods

Based on the registration in mapping.py and the directories under src/peft/tuners/, the library supports the methods summarized below. New methods are added regularly; release notes (e.g. v0.19.0 introducing GraLoRA and others; v0.18.0 introducing RoAd, ALoRA, Arrow, WaveFT, DeLoRA, OSF) document each addition.

Source: src/peft/mapping.py:1-80 ; src/peft/tuners/__init__.py:1-60

Each method's config.py defines its own hyperparameter schema, but they all inherit from PeftConfig in src/peft/config.py, which standardizes fields such as target_modules, modules_to_save, and bias. Source: src/peft/config.py:50-120

4. Common Workflow: How a Tuner Is Applied

The end-to-end flow when a user instantiates a PEFT model is:

1. Configuration: User constructs e.g. LoraConfig(r=8, lora_alpha=16, target_modules=["q_proj"]).
2. Dispatch: get_peft_model reads config.peft_type and looks up the tuner in mapping.py.
3. Target discovery: The tuner (via BaseTuner) walks the base model and matches modules against target_modules (as a list, regex string, or set — note issue #3229 reports target_modules being coerced to set in the weight-conversion path, which can affect string-based targeting).
4. Replacement: Each matching nn.Linear is swapped with the tuner's adapter layer, e.g. lora.Linear defined in layer.py.
5. Freezing: Base-model parameters have requires_grad=False; only adapter parameters remain trainable. Source: src/peft/tuners/lora/layer.py:1-80
6. Multi-adapter support: The BaseTuner enables add_adapter, set_adapter, and disable_adapter for switching among adapters at runtime.

This architecture is why the same trainer.train() pipeline works regardless of the chosen PEFT method — the base model is replaced by a PeftModel whose forward pass delegates to adapter layers.

Community-Relevant Notes

Several recurring community questions map onto this architecture:

• "How do I continue training?" (#184) — handled by PeftModel.load_adapter and the multi-adapter machinery in tuners_utils.py.
• "Will merge_and_unload work for my model?" (#365) — the merge_and_unload method lives on each tuner's model.py and folds adapter weights back into the base nn.Linear.
• target_modules as a string (#3229) — interaction between string/regex targets and set conversion in transformers_weight_conversion.py.
• Proposals like FIM-guided rank allocation (#3203) — would slot in as a new init_lora_weights mode, extending the existing LoRA initialization switch in lora/layer.py.

The tuner architecture's extensibility is what makes such additions low-friction: a new init_lora_weights="fim" value, a new FimConfig, and one new model.py entry in mapping.py are typically sufficient.

Related Pages

Related topics: Supported PEFT Methods and Tuner Architecture, Integrations, Quantization, Merging & Examples

Configuration, Training Workflow & Troubleshooting

Overview

PEFT (Parameter-Efficient Fine-Tuning) wraps a pretrained base model with adapter layers configured through a single PeftConfig instance. The workflow has three well-defined phases: configuration (choosing a method, rank, targets), training (forward/backward with frozen base weights and trainable adapter weights), and deployment (saving, loading, merging, troubleshooting). The configuration object is the contract that governs everything downstream, while PeftModel is the runtime entity that exposes a transformers-compatible interface (forward, save_pretrained, from_pretrained).

Configuration Layer

Each PEFT method is paired with its own PeftConfig subclass. LoraConfig is the most widely used, exposing parameters such as r (rank), lora_alpha, target_modules, target_parameters, lora_dropout, bias, and init_lora_weights. The config is serialized into adapter_config.json and shipped with the adapter weights.

target_modules accepts strings, regex patterns, or lists, while target_parameters (introduced in v0.17.0 and patched in v0.17.1) targets nn.Parameter objects directly, which is useful for Mixture-of-Experts layers. Source: src/peft/config.py:1-50.

A commonly reported regression is that string entries in target_modules or target_parameters are coerced into a set rather than a list during weight conversion, which breaks ordered iteration and regex matching in some downstream code. The conversion site is transformers_weight_conversion.py. Source: src/peft/utils/transformers_weight_conversion.py:371-372. When the base model exposes only a single occurrence of a module name, the set-ification is benign; when multiple variants exist (e.g. q_proj, q_proj_1), ordering matters.

Training Workflow

The standard training workflow follows these stages:

get_peft_model returns a PeftModel (or a method-specific subclass such as LoraModel) whose __init__ walks the base model, replaces targeted modules with wrapped adapter modules, and freezes the base weights. Source: src/peft/peft_model.py:1-120.

Only adapter parameters end up with requires_grad=True. The total trainable share is typically under 1% of the base model. For LoRA, the model constructs lora_A (down-projection) and lora_B (up-projection) matrices of shape (r, in_features) and (out_features, r) respectively; their initialization is controlled by init_lora_weights (e.g. "gaussian", "loftq", or a custom callable). Source: src/peft/config.py:50-180.

During the forward pass, the original module's output is combined with the adapter's scaled output (alpha/r):

y = W x + (alpha/r) * (B (A x))

Because W is frozen but A and B carry gradients, gradients flow only through the adapter path. This is what enables the well-known RuntimeError: element 0 of tensors does not require grad and does not have a grad_fn issue (community issue #137) when users inadvertently pass a model that has been .detach()-ed, cast to bfloat16 without a gradient-allowing leaf tensor, or when input_embeds is returned from a non-grad-enabled path. The fix is to ensure the inputs are requires_grad=False tensors with grad_fn retained through the adapter layers.

Saving, Loading, and Merging

save_pretrained writes adapter_model.safetensors (or adapter_model.bin) plus adapter_config.json. The saver is set_peft_model_state_dict aware, which makes it compatible with distributed training frameworks such as FSDP and DeepSpeed ZeRO-3 — a fix for modules_to_save placeholder bugs landed in v0.15.1 (issue #2450). Source: src/peft/utils/save_and_load.py:1-80.

PeftModel.from_pretrained(base_model, peft_model_id) re-injects the adapter weights into a fresh copy of the base model. The target_modules resolution at load time must match the resolution at save time; mismatches are the most common source of KeyError or size mismatch for ... errors.

For deployment, merge_and_unload() folds the adapter weights into the base linear layers and returns a standard transformers model, eliminating the adapter overhead at inference. Source: src/peft/utils/merge_utils.py:1-100.

Troubleshooting

The official troubleshooting guide is the canonical entry point. Source: docs/source/developer_guides/troubleshooting.md:1-60. The most frequently observed issues are:

1. element 0 of tensors does not require grad — caused by detached inputs, an unfreezing mistake, or by accidently training the base model in eval() mode without re-enabling adapter gradients. Verify with model.print_trainable_parameters() and confirm model.base_model.model... parameters show requires_grad=False.

1. target_modules ordering / set issue (v0.19) — strings are coerced to a set, breaking ordered iteration. Source: src/peft/utils/transformers_weight_conversion.py:371-372. Workaround: pass an explicit list[str] downstream or pin to a fixed version once a patch ships.

1. modules_to_save checkpoint corruption with DeepSpeed ZeRO-3 — fixed in v0.15.1. Upgrade if you see placeholder zeros for newly initialized modules after a reload. Source: src/peft/utils/save_and_load.py:80-160.

1. PromptEncoder / P-tuning silently broken — fixed in v0.15.2 (issue #2477). Upgrade to ≥ v0.15.2 if prompt learning methods throw shape or attention-mask errors.

1. Continuing training from a checkpoint (community issue #184) — load with PeftModel.from_pretrained(base, ckpt) and then re-enable training mode on the adapter; do not call merge_and_unload if you intend to continue.

1. GPT-2 merge compatibility (community issue #365) — the tied_weights pattern in GPT-2 interferes with merge; check model.config.tie_word_embeddings and use safe_merge=True when calling merge_and_unload. Source: src/peft/utils/merge_utils.py:50-120.

1. ROCm / AMD GPU support — added in v0.18.1 (PR #2963); ensure bitsandbytes and accelerate are ROCm-compatible builds. Source: src/peft/utils/peft_types.py:1-40.

For environment compatibility (community issue #207, asking about PyTorch ≤ 1.12.1 and CUDA ≤ 10.2), PEFT requires torch >= 1.13. Downgrading is not supported; the recommended path is to upgrade the CUDA toolkit and PyTorch build.

Related Pages

Related topics: Introduction, Installation & Quickstart, Configuration, Training Workflow & Troubleshooting

Integrations, Quantization, Merging & Examples

PEFT is designed to interoperate with the broader Hugging Face ecosystem and the wider PyTorch tooling landscape. Beyond the core tuner logic, the library ships dedicated utilities for integrating with third-party libraries (Transformers, Accelerate, TRL, LoRA-FA), running and merging quantized adapters, initializing adapters with quantization-aware strategies (LoftQ, ALoRA, DoRA), hotswapping adapters at inference time, and merging adapter weights back into the base model for deployment.

This page walks through those subsystems, the public APIs they expose, and the example patterns that the repository ships to demonstrate end-to-end usage.

1. Library Integrations

The src/peft/utils/integrations.py module centralizes detection logic and helper functions that adapt PEFT to other libraries.

Key responsibilities:

• Transformers integration: helpers such as prepare_model_for_kbit_training (re-exported in src/peft/utils/integrations.py:1-50) ensure that quantized or frozen base models have input_requires_grad=True, embeddings are unfrozen where needed, and LayerNorm parameters are kept in fp32. This is the standard recipe referenced by most PEFT examples and resolves community issues such as #137 (element 0 of tensors does not require grad).
• Wandb / Trackio integration: a lightweight callback (trackio_callback, wandb_callback) is provided to log adapter hyperparameters, trainable-parameter counts, and training metrics without forcing a hard dependency. The callbacks auto-detect the trainer class and register themselves during add_callback.
• TRL / SFTTrainer compatibility: PEFT inspects the trainer's signature to decide whether to pass a peft_config, an already-wrapped PeftModel, or a raw model. This avoids double-wrapping bugs when users compose TRL's SFTTrainer with peft_config.
• DeepSpeed ZeRO-3 support: when modules_to_save is used together with ZeRO-3, PEFT coordinates with the DeepSpeed engine to gather partitioned parameters before persisting adapter checkpoints. This was the root cause of v0.15.1 release notes (issue #2450).

Source: src/peft/utils/integrations.py:1-120

2. Quantization Support

Quantization in PEFT covers three distinct concerns: (a) quantizing the *base* model, (b) initializing the adapter from quantized statistics, and (c) running the adapter on top of a quantized base layer.

2.1 BitsAndBytes (bnb)

The LoraLayer subclass in src/peft/tuners/lora/bnb.py is the entry point for 4-bit (NF4/FP4) and 8-bit base models. It overrides Linear.__init__ to:

• Detect the quantization config from Linear4bit / Linear8bitLt modules.
• Compute the adapter output as x @ (B @ A).T * scaling, with the matmul executed in the base layer's compute dtype.
• Provide merge_and_unload-safe paths that re-quantize the merged linear when the base is 4-bit.

Source: src/peft/tuners/lora/bnb.py:1-200

2.2 LoftQ Initialization

src/peft/utils/loftq_utils.py implements LoftQ (LoRA-Fine-Tuning-aware Quantization), which iteratively initializes LoRA matrices A and B such that W + B @ A ≈ Q(W). The helper initialize_lora_loftq is invoked by LoraConfig(init_lora_weights="loftq"). It accepts a quantization configuration object, performs SVD-based refinement for a configurable number of iterations, and returns the corrected A, B, and quantization residual.

Source: src/peft/utils/loftq_utils.py:1-150

2.3 Quantization Utilities

The quantization_utils.py module centralizes helper logic used by both bnb and LoftQ paths: dtype inference, per-layer fallback handling, and sharding for very large models.

Source: src/peft/utils/quantization_utils.py:1-120

3. Merging Adapters

Merging collapses the adapter contribution B @ A * scaling back into the base weight W, producing a single standard nn.Linear that no longer depends on PEFT at inference time. The main entry points live in src/peft/tuners/lora/layer.py and src/peft/utils/merge_utils.py.

The merge step is dtype-aware: when the base is 4-bit (bnb), PEFT performs the operation in fp16/fp32 and re-quantizes the result, so the merged checkpoint can still be loaded by bitsandbytes. Community issue #365 ("GPT2 Models Merge and Unload") was resolved by adding explicit GPT-2 module-name handling in the same merge path.

4. Hotswapping and Optimizer Examples

4.1 Hotswap Adapters

src/peft/utils/hotswap.py enables swapping one adapter for another at inference time without recompiling the model graph. It validates that both adapters share the same target_modules, r, alpha, and lora_dropout, then performs an in-place weight copy. This is useful for serving multiple LoRA specializations from a single model copy.

Source: src/peft/utils/hotswap.py:1-180

4.2 LoRA-FA Optimizer

The LoFAOptimizer in src/peft/optimizers/lorafa.py implements LoRA-FA (LoRA-Free Adapter): it freezes the B matrix and only updates A, reducing optimizer state memory by ~50%. It extends torch.optim.AdamW and is enabled by passing optimizers=(LoFAOptimizer, lr) to the trainer.

Source: src/peft/optimizers/lorafa.py:1-160

4.3 End-to-End Examples

The examples/ directory at the repo root contains runnable scripts covering the workflows above:

• examples/loftq_finetuning/ — LoftQ initialization on top of a 4-bit base.
• examples/int8_training/ — 8-bit base + LoRA training (community use case referenced in issue #184).
• examples/merge_lora_weights/ — merge_and_unload for deployment.
• examples/lora_fa/ — LoRA-FA optimizer integration with HF Trainer.
• examples/hotswap/ — runtime adapter swapping.

These examples are the canonical reference for the public APIs discussed on this page and reflect the patterns most frequently asked about in community discussions.

Doramagic Pitfall Log

Found 19 structured pitfall item(s), including 1 high/blocking item(s). Top priority: Configuration risk - Configuration risk requires verification.

1. Configuration risk: Configuration risk requires verification

• Severity: high
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/huggingface/peft/issues/3229

2. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: 0.17.0: SHiRA, MiSS, LoRA for MoE, and more
• User impact: Upgrade or migration may change expected behavior: 0.17.0: SHiRA, MiSS, LoRA for MoE, and more
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: 0.17.0: SHiRA, MiSS, LoRA for MoE, and more. Context: Observed when using python
• Evidence: failure_mode_cluster:github_release | https://github.com/huggingface/peft/releases/tag/v0.17.0

3. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: Proposal: FIM-guided adaptive LoRA rank allocation (FimConfig + initialize_lora_fim_ranks)
• User impact: Developers may misconfigure credentials, environment, or host setup: Proposal: FIM-guided adaptive LoRA rank allocation (FimConfig + initialize_lora_fim_ranks)
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Proposal: FIM-guided adaptive LoRA rank allocation (FimConfig + initialize_lora_fim_ranks). Context: Observed when using python, cuda
• Evidence: failure_mode_cluster:github_issue | https://github.com/huggingface/peft/issues/3203

4. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: [BUG] peft 0.19 target_modules (str) use set
• User impact: Developers may misconfigure credentials, environment, or host setup: [BUG] peft 0.19 target_modules (str) use set
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: [BUG] peft 0.19 target_modules (str) use set. Context: Observed when using python
• Evidence: failure_mode_cluster:github_issue | https://github.com/huggingface/peft/issues/3229

5. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: v0.15.0
• User impact: Upgrade or migration may change expected behavior: v0.15.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.15.0. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_release | https://github.com/huggingface/peft/releases/tag/v0.15.0

6. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | https://github.com/huggingface/peft

7. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Developers should check this migration risk before relying on the project: 0.16.0: LoRA-FA, RandLoRA, C³A, and much more
• User impact: Upgrade or migration may change expected behavior: 0.16.0: LoRA-FA, RandLoRA, C³A, and much more
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: 0.16.0: LoRA-FA, RandLoRA, C³A, and much more. Context: Observed when using cuda
• Evidence: failure_mode_cluster:github_release | https://github.com/huggingface/peft/releases/tag/v0.16.0

8. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/huggingface/peft

9. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | https://github.com/huggingface/peft

10. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | https://github.com/huggingface/peft

11. Runtime risk: Runtime risk requires verification

• Severity: low
• Finding: Developers should check this performance risk before relying on the project: 0.18.0: RoAd, ALoRA, Arrow, WaveFT, DeLoRA, OSF, and more
• User impact: Upgrade or migration may change expected behavior: 0.18.0: RoAd, ALoRA, Arrow, WaveFT, DeLoRA, OSF, and more
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: 0.18.0: RoAd, ALoRA, Arrow, WaveFT, DeLoRA, OSF, and more. Context: Observed when using python
• Evidence: failure_mode_cluster:github_release | https://github.com/huggingface/peft/releases/tag/v0.18.0

12. Runtime risk: Runtime risk requires verification

• Severity: low
• Finding: Developers should check this performance risk before relying on the project: v0.19.0
• User impact: Upgrade or migration may change expected behavior: v0.19.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.19.0. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_release | https://github.com/huggingface/peft/releases/tag/v0.19.0

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using peft with real data or production workflows.

• [[BUG] peft 0.19 target_modules (str) use set](https://github.com/huggingface/peft/issues/3229) - github / github_issue
• Proposal: FIM-guided adaptive LoRA rank allocation (FimConfig + initiali - github / github_issue
• v0.19.1 - github / github_release
• v0.19.0 - github / github_release
• 0.18.1 - github / github_release
• 0.18.0: RoAd, ALoRA, Arrow, WaveFT, DeLoRA, OSF, and more - github / github_release
• 0.17.1 - github / github_release
• 0.17.0: SHiRA, MiSS, LoRA for MoE, and more - github / github_release
• 0.16.0: LoRA-FA, RandLoRA, C³A, and much more - github / github_release
• v0.15.2 - github / github_release
• v0.15.1 - github / github_release
• v0.15.0 - github / github_release