Parameter efficient fine tuning means freezing most of the pretrained model and training a small set of extra parameters. The usual full fine tuning recipe is expensive because every weight participates in backpropagation. You keep the model weights, gradients for those weights, and optimizer state for those weights. With Adam, the optimizer state alone is often larger than the model. PEFT changes the object you train. The base model stays fixed. A small task specific module learns the update.

LoRA

LoRA freezes a pretrained weight matrix $W$ and learns a low-rank update instead of modifying every element of the matrix:

The rank of $BA$ is much smaller than the dimensions of $W$, so only the small matrices $A$ and $B$ require gradients and optimizer state. This greatly reduces the number of trainable parameters and the memory needed for fine-tuning. LoRA adapters can be stored separately for different tasks or merged into the base weights for inference without adding another layer to the model.

Inference

A LoRA adapter can be merged into the base weight as $W' = W + BA$ before deployment. The server then performs the same linear operation as the original model, so LoRA adds no inference latency. To switch adapters, an implementation can subtract the current $BA$ update and add the next one, or maintain separate merged copies. It does not necessarily need another complete copy of the base-model weights.

Multi-LoRA serving keeps one copy of the base model and selects an adapter for each request. Systems such as Punica and S-LoRA use specialized kernels, batching, caching, and memory management to serve requests using different adapters efficiently. In this mode the adapters remain separate, so there is some computation and scheduling overhead, but many task-specific models can share the same base-model memory.

vLLM supports serving LoRA adapters and allows a request to specify which adapter should be applied. This makes it possible to expose multiple LoRA variants through one inference server without creating a separate full-model deployment for each variant.

Prompt tuning

Hard prompts are ordinary discrete text tokens written or selected to guide the model. They are human-readable and require no change to the model, but they consume context-window space and cannot be optimized directly with gradient descent. Hard prompting is usually an inference technique rather than parameter-efficient fine-tuning.

Soft prompts are trainable continuous embedding vectors prepended to the model input. The base model remains frozen, and gradient descent updates only these virtual tokens for a task. Soft prompts use few trainable parameters, but they are not human-readable and must be stored and loaded like other task-specific adapters.

Prefix-Tuning keeps the model frozen and learns task-specific prefix activations for every Transformer layer. Rather than propagating the prefix through the Transformer like ordinary tokens, Prefix-Tuning directly supplies learned key–value activations to each attention layer. The hidden states of the actual input tokens are computed normally from one layer to the next. Prefix-Tuning was designed and evaluated primarily for generation tasks.

P-Tuning inserts trainable continuous prompt embeddings alongside discrete tokens in a prompt template. A small prompt encoder, implemented with a bidirectional LSTM and an MLP, generates the continuous embeddings while the language model can remain frozen.

Prompt Tuning directly learns a sequence of soft embeddings prepended only at the model input. Unlike Prefix-Tuning, it does not add prefixes at every Transformer layer, and unlike P-Tuning, it does not require a separate prompt encoder.

P-Tuning v2 targets natural-language understanding tasks, including classification, extractive question answering, and sequence labeling such as named entity recognition and semantic role labeling. It is conceptually a continuation of P-Tuning, but architecturally it follows Prefix-Tuning by adding trainable continuous prefixes across Transformer layers while keeping the pretrained model frozen. The paper found that prefix capacity should depend on the task. Simple classification tasks often work best with fewer than 20 prefix tokens, while difficult sequence-labeling tasks may need around 100.