Model Deployment | Ziyang Lin

LLM Hyperparameter Tuning Guide: A Comprehensive Analysis from Generation to Deployment

Fri, 27 Jun 2025 03:00:00 +0000

Introduction

Behind the powerful capabilities of large language models (LLMs) is a series of complex hyperparameters working silently. Whether you're deploying a local inference service like vLLM or calling OpenAI's API, precisely tuning these parameters is crucial for achieving ideal performance, cost, and output quality. This document provides a detailed analysis of two key categories of hyperparameters: Generation (Sampling) Parameters and Deployment (Serving) Parameters, helping you fully master their functions, values, impacts, and best practices across different scenarios.

Part 1: Generation (Sampling) Parameters — Controlling Model Creativity and Determinism

Generation parameters directly control the model's behavior when generating the next token. They primarily revolve around a core question: how to select from thousands of possible next words in the probability distribution provided by the model.

1. `temperature`

In one sentence: Controls the randomness of generated text. Higher temperature increases randomness, making responses more creative and diverse; lower temperature decreases randomness, making responses more deterministic and conservative.

Underlying Principle: When generating the next token, the model calculates logits (raw, unnormalized prediction scores) for all words in the vocabulary. Typically, we use the Softmax function to convert these logits into a probability distribution. The temperature parameter is introduced before the Softmax calculation, “smoothing” or “sharpening” this probability distribution.

The standard Softmax formula is: P(i) = exp(logit_i) / Σ_j(exp(logit_j))

With temperature (T) introduced, the formula becomes: P(i) = exp(logit_i / T) / Σ_j(exp(logit_j / T))
- When T -> 0, the differences in logit_i / T become dramatically amplified. The token with the highest logit approaches a probability of 1, while all other tokens approach 0. This causes the model to almost always choose the most likely word, behaving very deterministically and “greedily.”
- When T = 1, the formula reverts to standard Softmax, and the model behaves in its “original” state.
- When T > 1, the differences in logit_i / T are reduced. Tokens with originally lower probabilities get boosted, making the entire probability distribution “flatter.” This increases the chance of selecting less common words, introducing more randomness and creativity.
Value Range and Recommendations:
- Range: [0.0, 2.0] (theoretically can be higher, but OpenAI API typically limits to 2.0).
- temperature = 0.0: Suitable for scenarios requiring deterministic, reproducible, and highly accurate outputs. Examples: code generation, factual Q&A, text classification, data extraction. With identical inputs, outputs will be almost identical (unless the model itself is updated).
- Low temperature (e.g., 0.1 - 0.4): Suitable for semi-creative tasks requiring rigor and fidelity to source material. Examples: article summarization, translation, customer service bots. Outputs will vary slightly but remain faithful to core content.
- Medium temperature (e.g., 0.5 - 0.8): A good balance between creativity and consistency, recommended as the default for most applications. Examples: writing emails, marketing copy, brainstorming.
- High temperature (e.g., 0.9 - 1.5): Suitable for highly creative tasks. Examples: poetry writing, story creation, dialogue script generation. Outputs will be very diverse and sometimes surprising, but may occasionally produce meaningless or incoherent content.
Note:
- It's generally not recommended to modify both temperature and top_p simultaneously; it's better to adjust just one. OpenAI's documentation explicitly states that modifying only one is typically advised.

2. `top_p` (Nucleus Sampling)

In one sentence: Controls generation diversity by dynamically determining the sampling pool size through a cumulative probability threshold (p) of the highest probability tokens.

Underlying Principle: top_p is a more intelligent sampling strategy than temperature, also known as Nucleus Sampling. Instead of adjusting all token probabilities, it directly defines a “core” candidate set.

The specific steps are as follows:
1. The model calculates the probability distribution for all candidate tokens.
2. All tokens are sorted by probability from highest to lowest.
3. Starting from the highest probability token, their probabilities are cumulatively added until this sum exceeds the set top_p threshold.
4. All tokens included in this cumulative sum form the “nucleus” for sampling.
5. The model will only sample from this nucleus (typically renormalizing their probabilities), and all other tokens are ignored.
Example: Assume top_p = 0.9.
- If the highest probability token “the” has a probability of 0.95, then the nucleus will contain only “the”, and the model will choose it 100%.
- If “the” has a probability of 0.5, “a” has 0.3, and “an” has 0.1, then the cumulative probability of these three words is 0.9. The nucleus will contain {“the”, “a”, “an”}. The model will sample from these three words according to their (renormalized) probabilities.
Value Range and Recommendations:
- Range: (0.0, 1.0].
- top_p = 1.0: Means the model considers all tokens without any truncation (equivalent to no top_p).
- High top_p (e.g., 0.9 - 1.0): Allows for more diverse choices, suitable for creative tasks, similar in effect to higher temperature.
- Low top_p (e.g., 0.1 - 0.3): Greatly restricts the model's range of choices, making its output very deterministic and conservative, similar in effect to extremely low temperature.
- General Recommended Value: 0.9 is a very common default value as it maintains high quality while allowing for some diversity.
top_p vs temperature:
- top_p is more dynamic and adaptive. When the model is very confident about the next step (sharp probability distribution), top_p automatically narrows the candidate set, ensuring quality. When the model is less confident (flat distribution), it expands the candidate set, increasing diversity.
- temperature adjusts the entire distribution “equally,” regardless of whether the distribution itself is sharp or flat.
- Therefore, top_p is generally considered a safer and more robust method for controlling diversity than temperature.

3. `top_k`

In one sentence: Simply and directly samples only from the k tokens with the highest probabilities.

Underlying Principle: This is the simplest truncation sampling method. It directly selects the k tokens with the highest probabilities to form the candidate set, then samples from these k tokens. All other tokens are ignored.
Value Range and Recommendations:
- Range: Integers, such as 1, 10, 50.
- top_k = 1: Equivalent to greedy search, always choosing the most likely word.
- Recommendation: top_k is typically not the preferred sampling strategy because it's too “rigid.” In cases where the probability distribution is very flat, it might accidentally exclude many reasonable words; while in cases where the distribution is very sharp, it might include many extremely low-probability, useless words. top_p is usually a better choice.

4. `repetition_penalty`

In one sentence: Applies a penalty to tokens that have already appeared in the context, reducing their probability of being selected again, thereby reducing repetitive content.

Underlying Principle: After calculating logits but before Softmax, this parameter iterates through all candidate tokens. If a token has already appeared in the previous context, its logit value is reduced (typically divided by the value of repetition_penalty).

new_logit = logit / penalty (if token has appeared) new_logit = logit (if token has not appeared)

This way, the final probability of words that have already appeared decreases.
Value Range and Recommendations:
- Range: 1.0 to 2.0 is common.
- 1.0: No penalty applied (default value).
- 1.1 - 1.3: A relatively safe range that can effectively reduce unnecessary repetition without overly affecting normal language expression (such as necessary articles like “the”).
- Too High Values: May cause the model to deliberately avoid common words, producing unnatural or even strange sentences.

5. `frequency_penalty` & `presence_penalty`

These two parameters are more refined versions of repetition_penalty.

presence_penalty:
- Function: Applies a fixed penalty to all tokens that have appeared at least once in the context. It doesn't care how many times the token has appeared; as long as it has appeared, it gets penalized.
- Underlying Principle: new_logit = logit - presence_penalty (if token has appeared at least once).
- Scenario: This parameter is useful when you want to encourage the model to introduce entirely new concepts and vocabulary, rather than repeatedly discussing topics that have already been mentioned.
- Range: 0.0 to 2.0. Positive values penalize new tokens, negative values encourage them.
frequency_penalty:
- Function: The penalty is proportional to the frequency of the token in the context. The more times a word appears, the heavier the penalty it receives.
- Underlying Principle: new_logit = logit - count(token) * frequency_penalty.
- Scenario: This parameter is effective when you find the model tends to repeatedly use certain specific high-frequency words (even if they are necessary), leading to monotonous language.
- Range: 0.0 to 2.0.
Summary: presence_penalty addresses the question of “whether it has appeared,” while frequency_penalty addresses “how many times it has appeared.”

6. `seed`

In one sentence: By providing a fixed seed, you can make the model's output reproducible when other parameters (such as temperature) remain the same.

Function: In machine learning, many operations that seem random are actually “pseudo-random,” determined by an initial “seed.” Setting the same seed will produce the same sequence of random numbers. In LLMs, this means the sampling process will be completely deterministic.
Scenarios:
- Debugging and Testing: When you need to verify whether a change has affected the output, fixing the seed can eliminate randomness interference.
- Reproducible Research: Reproducibility is crucial in academic research.
- Generating Consistent Content: When you need the model to consistently produce outputs in the same style for the same input.
Note: For complete reproduction, all generation parameters (prompt, model, temperature, top_p, etc.) must be identical.

Part 2: Deployment (Serving) Parameters — Optimizing Service Performance and Capacity

Deployment parameters determine how an LLM inference service manages GPU resources, handles concurrent requests, and optimizes overall throughput and latency. These parameters are particularly important in high-performance inference engines like vLLM.

1. `gpu_memory_utilization`

In one sentence: Controls the proportion of GPU memory that vLLM can use, with the core purpose of reserving space for the KV Cache.

Underlying Principle (PagedAttention): The core of vLLM is the PagedAttention mechanism. Traditional attention mechanisms pre-allocate a continuous, maximum-length memory space for each request to store the Key-Value (KV) Cache. This leads to severe memory waste, as most requests are far shorter than the maximum length.

PagedAttention manages the KV Cache like virtual memory in an operating system:
1. It breaks down each sequence's KV Cache into many small, fixed-size “blocks.”
2. These blocks can be stored non-contiguously in GPU memory.
3. A central “Block Manager” is responsible for allocating and releasing these blocks.
gpu_memory_utilization tells vLLM: “You can use this much proportion of the total GPU memory for free management (mainly storing model weights and physical blocks of KV Cache).”
Value Range and Impact:
- Range: (0.0, 1.0].
- Default Value: 0.9 (i.e., 90%).
- Higher Values (e.g., 0.95):
  - Advantage: vLLM has more memory for KV Cache, supporting longer contexts and larger batch sizes, thereby increasing throughput.
  - Risk: If set too high, there might not be enough spare memory for CUDA kernels, drivers, or other system processes, easily leading to OOM (Out of Memory) errors.
- Lower Values (e.g., 0.8):
  - Advantage: Safer, less prone to OOM, reserves more memory for the system and other applications.
  - Disadvantage: Reduced available space for KV Cache, potentially causing vLLM to struggle with high concurrency or long sequence requests, degrading performance. When KV Cache is insufficient, vLLM triggers Preemption, swapping out some running sequences and waiting to swap them back in when there's enough space, severely affecting latency. vLLM's warning log "there is not enough KV cache space. This can affect the end-to-end performance." is reminding you of this issue.
Recommendations:
- Start with the default value of 0.9.
- If you encounter OOM, gradually lower this value.
- If you encounter many preemption warnings and confirm no other processes are occupying large amounts of GPU memory, you can gradually increase this value.

2. `max_num_seqs`

In one sentence: Limits the maximum number of sequences (requests) that the vLLM scheduler can process in one iteration (or one batch).

Underlying Principle: vLLM's scheduler selects a batch of requests from the waiting queue in each processing cycle. This parameter directly limits the size of this “batch.” Together with max_num_batched_tokens (which limits the total number of tokens across all sequences in a batch), it determines the scale of batch processing.
Value Range and Impact:
- Range: Positive integers, such as 16, 64, 256.
- Higher Values:
  - Advantage: Allows for higher concurrency, potentially improving GPU utilization and overall throughput.
  - Disadvantage: Requires more intermediate memory (e.g., for storing logits and sampling states) and may increase the latency of individual batches. If set too high, even if KV Cache still has space, OOM might occur due to insufficient temporary memory.
- Lower Values:
  - Advantage: More memory-friendly, potentially lower latency for individual batches.
  - Disadvantage: Limits concurrency capability, potentially leading to underutilization of GPU and decreased throughput.
Recommendations:
- This value needs to be adjusted based on your GPU memory size, model size, and expected concurrent load.
- For high-concurrency scenarios, try gradually increasing this value while monitoring GPU utilization and memory usage.
- For interactive, low-latency scenarios, consider setting this value lower.

3. `max_model_len`

In one sentence: Sets the maximum context length the model can process (including both prompt and generated tokens).

Underlying Principle: This parameter directly determines how much logical space vLLM needs to reserve for the KV Cache. For example, if max_model_len = 4096, vLLM must ensure its memory management mechanism can support storing KV pairs for up to 4096 tokens per sequence. This affects vLLM's memory planning at startup, such as the size of Position Embeddings.
Value Range and Impact:
- Range: Positive integers, cannot exceed the maximum length the model was originally trained on.
- Higher Values:
  - Advantage: Can handle longer documents and more complex contexts.
  - Disadvantage: Significantly increases memory consumption. Each token needs to store KV Cache; doubling the length roughly doubles the memory usage. Even if current requests are short, vLLM needs to prepare for potentially long requests, which occupies more KV Cache blocks.
- Lower Values:
  - Advantage: Significantly saves GPU memory. If you know your application scenario will never exceed 1024 tokens, setting this value to 1024 instead of the default 4096 or 8192 will free up a large amount of KV Cache space, supporting higher concurrency.
  - Disadvantage: Any requests exceeding this length will be rejected or truncated.
Recommendations:
- Set as needed! This is one of the most effective parameters for optimizing vLLM memory usage. Based on your actual application scenario, set this value to a reasonable maximum with some margin.

4. `tensor_parallel_size` & `pipeline_parallel_size`

These two parameters are used for deploying extremely large models across multiple GPUs or nodes.

tensor_parallel_size:
- Function: Divides each layer of the model (such as a large weight matrix) into N parts (N = tensor_parallel_size), placing them on N different GPUs. During computation, each GPU only processes its own portion of the data, then exchanges necessary results through high-speed interconnects (like NVLink) via All-Reduce operations, finally merging to get the complete output.
- Scenario: Used when a single model's volume exceeds the memory of a single GPU. For example, a 70B model cannot fit into a single 40GB A100, but can be deployed across two A100s by setting tensor_parallel_size=2.
- Impact:
  - Advantage: Achieves model parallelism, solving the problem of models not fitting on a single card.
  - Disadvantage: Introduces significant cross-GPU communication overhead, potentially affecting latency. Requires high-speed interconnects between GPUs.
pipeline_parallel_size:
- Function: Assigns different layers of the model to different GPUs or nodes. For example, placing layers 1-10 on GPU 1, layers 11-20 on GPU 2, and so on. Data flows through these GPUs like a pipeline.
- Scenario: Used when the model is extremely large and needs to be deployed across multiple nodes (machines).
- Impact:
  - Advantage: Can scale the model to any number of GPUs/nodes.
  - Disadvantage: Creates “pipeline bubbles” as additional overhead, where some GPUs are idle during the start and end phases of the pipeline, reducing utilization.
Combined Use: vLLM supports using both parallelism strategies simultaneously for efficient deployment of giant models on large clusters.

Summary and Best Practices

Scenario	`temperature`	`top_p`	`repetition_penalty`	`gpu_memory_utilization`	`max_num_seqs`	`max_model_len`
Code Generation/Factual Q&A	`0.0` - `0.2`	(Not recommended to modify)	`1.0`	`0.9` (Default)	Adjust based on concurrency	Set as needed
Article Summarization/Translation	`0.2` - `0.5`	(Not recommended to modify)	`1.1`	`0.9`	Adjust based on concurrency	Set to maximum possible document length
General Chat/Copywriting	`0.7` (Default)	`0.9` (Recommended)	`1.1` - `1.2`	`0.9`	Adjust based on concurrency	Set as needed, e.g., `4096`\|
Creative Writing/Brainstorming	`0.8` - `1.2`	`0.95`	`1.0`	`0.9`	Adjust based on concurrency	Set as needed
High Concurrency Throughput Optimization	(Task dependent)	(Task dependent)	(Task dependent)	Try `0.9` - `0.95`	Gradually increase	Set to the minimum value that meets business needs
Low Latency Interaction Optimization	(Task dependent)	(Task dependent)	(Task dependent)	`0.9` (Default)	Set to lower values (e.g., `16-64`)	Set as needed
Extremely Memory Constrained	(Task dependent)	(Task dependent)	(Task dependent)	Lower to `0.8`	Set to lower values	Set to the minimum value that meets business needs

Final Recommendations:

Start with Generation Parameters: First adjust temperature or top_p to achieve satisfactory output quality.
Set Deployment Parameters as Needed: When deploying, first set max_model_len to a reasonable minimum value based on your application scenario.
Monitor and Iterate: Start with the default gpu_memory_utilization=0.9 and a moderate max_num_seqs. Observe memory usage and preemption situations through monitoring tools (such as nvidia-smi and vLLM logs), then gradually adjust these values to find the optimal balance for your specific hardware and workload.

vLLM Technical Guide: High-Performance LLM Inference Engine

Thu, 26 Jun 2025 01:05:00 +0000

1. Introduction to vLLM

vLLM is an open-source inference and serving engine designed for large language models (LLMs), renowned for its high throughput and memory efficiency. In the field of LLM serving, vLLM addresses a core pain point: traditional inference systems are inefficient when handling the key-value cache (KV Cache) in Transformer models’ attention mechanism, resulting in significant memory waste and limited inference speed.

The memory bottleneck in LLM inference primarily stems from the KV Cache. This cache stores attention keys and values for each previous token in a sequence to accelerate the generation of subsequent tokens. However, the size of the KV Cache is dynamic and difficult to predict, creating enormous challenges for memory management. Traditional systems (like HuggingFace Transformers) typically pre-allocate a large continuous memory space to store the KV Cache, leading to severe memory fragmentation and waste.

vLLM fundamentally solves this problem by introducing its core innovation: the PagedAttention mechanism.

2. Core Features and Advantages

vLLM stands out among numerous LLM inference frameworks thanks to several key features:

Extremely High Throughput: Through PagedAttention and Continuous Batching, vLLM significantly improves GPU utilization. Its throughput is several times higher than HuggingFace Transformers and outperforms other mainstream inference libraries.
Efficient Memory Management: The PagedAttention mechanism divides the KV Cache into non-continuous memory blocks, greatly reducing internal and external memory fragmentation. According to official data, it can save up to 55% of memory, meaning you can load larger models or serve more concurrent requests with the same hardware.
Flexible Decoding Strategies: vLLM supports various complex decoding algorithms, including Parallel Sampling, Beam Search, and Top-K/Top-P sampling, meeting the needs of different application scenarios.
OpenAI API Compatibility: vLLM provides a service endpoint that is fully compatible with the OpenAI API. This means you can seamlessly integrate vLLM into existing application ecosystems built on the OpenAI API with just a few configuration changes.
Distributed Inference: For ultra-large models that cannot fit on a single GPU, vLLM supports Tensor Parallelism, distributing model weights and computational load across multiple GPUs for efficient distributed inference.
Streaming and Structured Output: Supports streaming of generated tokens and can produce structured outputs in specific formats (such as JSON Schema or regular expressions) through Guided Generation.

3. Core Architecture: Deep Dive into PagedAttention

PagedAttention is the soul of vLLM, with its design inspiration coming from the paging technique used in modern operating systems to manage virtual memory.

3.1 Working Principle

In traditional methods, the KV Cache for each sequence is stored in continuous memory space. While this approach seems simple, it leads to severe memory fragmentation due to the vast differences in sequence lengths.

PagedAttention divides each sequence's KV Cache into fixed-size blocks. Each block can store keys and values for a fixed number of tokens. During inference, vLLM's core scheduler dynamically allocates these blocks to sequences as needed.

The advantages of this design include:

Eliminating Internal Fragmentation: Since blocks are of fixed size, a sequence's last block may have some unused space, but this waste is far less than that caused by reserving continuous memory for the entire sequence.
Flexible Memory Allocation: Blocks are stored in non-continuous memory space, making memory management more flexible, similar to how operating systems manage physical memory pages.
Efficient Memory Sharing: PagedAttention makes sharing KV Cache between different sequences exceptionally simple and efficient. For example, in parallel sampling or beam search, multiple candidate sequences originate from the same prompt. vLLM allows these sequences to share KV blocks storing the prompt portion, only needing to allocate new, independent blocks for each sequence when generating new tokens. This “Copy-on-Write” mechanism greatly reduces the memory overhead of complex decoding algorithms.

Below is a Mermaid diagram that more intuitively illustrates PagedAttention's memory management approach:

graph TD
subgraph Physical_Memory [KV Cache Physical Memory]
direction LR
B1(Block 1)
B2(Block 2)
B3(Block 3)
B4(Block 4)
B5(Block 5)
B6(Block 6)
B7(Block 7)
B8(Block 8)
end
subgraph Logical_View [Sequence Logical View]
direction TB
subgraph Seq1 [Sequence 1]
P1(Prompt) --> T1(Token 1)
end
subgraph Seq2 [Sequence 2]
P2(Prompt) --> T2(Token 1) --> T3(Token 2)
end
subgraph Seq3 [Parallel Sampling]
P3(Prompt) --> T4(Token 1a)
P3 --> T5(Token 1b)
end
end
subgraph Block_Table [Block Table]
direction TB
Map1["Seq 1: [B1, B5]"]
Map2["Seq 2: [B2, B6, B8]"]
Map3["Seq 3a: [B3, B7]"]
Map4["Seq 3b: [B3, B4]"]
end
Seq1 --> Map1
Seq2 --> Map2
Seq3 --> Map3
Seq3 --> Map4
Map1 --> B1
Map1 --> B5
Map2 --> B2
Map2 --> B6
Map2 --> B8
Map3 --> B3
Map3 --> B7
Map4 --> B3
Map4 --> B4
style B3 fill:#f9f,stroke:#333,stroke-width:2px
linkStyle 8 stroke-width:2px,stroke:green,fill:none;
linkStyle 11 stroke-width:2px,stroke:green,fill:none;
linkStyle 12 stroke-width:2px,stroke:green,fill:none;

Diagram explanation:

KV Cache Physical Memory: Represents non-continuous physical memory blocks on the GPU.
Sequence Logical View: Represents multiple requests (sequences) being processed.
Block Table: vLLM's core component that maps logical token positions to physical memory blocks.
Memory Sharing: Note that the two branches in “Parallel Sampling” (3a and 3b) share the same Prompt block (B3), demonstrating PagedAttention's efficient memory sharing.

3.2 Continuous Batching

Based on PagedAttention, vLLM implements a more advanced batching strategy—continuous batching. Traditional static batching requires waiting for all sequences in a batch to complete generation before processing the next batch. Continuous batching, however, allows new requests to be inserted into the batch immediately after a sequence in the batch completes generation, avoiding GPU idle waiting and further improving throughput.

Below is a comparison of the two batching methods using a Mermaid sequence diagram:

sequenceDiagram
participant C as Client
participant S as Server
participant G as GPU
note over C, G: --- Static Batching ---
C->>S: Request [R1, R2, R3, R4]
S->>G: Process Batch 1 [R1, R2, R3, R4]
note right of G: All requests process in parallel
G-->>S: Batch 1 Finished
note right of S: Wait for the entire batch to complete
S-->>C: Response [O1, O2, O3, O4]
C->>S: Request [R5, R6]
S->>G: Process Batch 2 [R5, R6]
note over C, G: --- Continuous Batching ---
C->>S: Request [R1, R2, R3, R4]
S->>G: Process [R1, R2, R3, R4]
G-->>S: R2 Finished
S-->>C: Response O2
C->>S: New Request R5
S->>G: Add R5 to queue (GPU is not idle)
note right of G: R1, R3, R4, R5 are now processing
G-->>S: R4 Finished
S-->>C: Response O4

4. Quick Start Guide

Below, we'll demonstrate how to install and use vLLM through a few simple steps.

4.1 Installation

You can install vLLM using either pip or uv (a faster package installation tool). Using uv is recommended as it can automatically detect your CUDA version and install the matching PyTorch backend.

Using uv (recommended):

# Create and activate a virtual environment
uv venv
source .venv/bin/activate
# Install vLLM
uv pip install vllm --torch-backend=auto

Using pip:

pip install vllm

4.2 Offline Inference

The vllm.LLM class makes offline inference very convenient.

from vllm import LLM, SamplingParams
# Define input prompts
prompts = [
"Hello, my name is",
"The capital of France is",
"The future of AI is",
]
# Define sampling parameters
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)
# Initialize the LLM engine (model will be automatically downloaded from Hugging Face)
llm = LLM(model="facebook/opt-125m")
# Generate text
outputs = llm.generate(prompts, sampling_params)
# Print results
for output in outputs:
prompt = output.prompt
generated_text = output.outputs[0].text
print(f"Prompt: {prompt!r}, Generated text: {generated_text!r}")

4.3 Launching an OpenAI-Compatible Server

One of vLLM's most powerful features is its built-in API server. With just one command, you can start a service compatible with the OpenAI API.

vllm serve Qwen/Qwen2.5-1.5B-Instruct

By default, the server will run on http://localhost:8000.

4.4 Interacting with the Server

You can interact with the server using curl or the openai Python client.

Using curl:

curl http://localhost:8000/v1/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen/Qwen2.5-1.5B-Instruct",
"prompt": "San Francisco is a",
"max_tokens": 7,
"temperature": 0
}'

Using the OpenAI Python client:

from openai import OpenAI
client = OpenAI(
base_url="http://localhost:8000/v1",
api_key="not-used" # API key is not required
)
completion = client.chat.completions.create(
model="Qwen/Qwen2.5-1.5B-Instruct",
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Who won the world series in 2020?"}
]
)
print(completion.choices[0].message)

5. Model Serving

5.1 Distributed Serving

If a model is too large to fit on a single GPU, you can distribute it across multiple GPUs using tensor parallelism.

# Start a service on 4 GPUs
vllm serve facebook/opt-13b --tensor-parallel-size 4

5.2 Docker Deployment

vLLM provides official Docker images for convenient containerized deployment.

docker run --runtime nvidia --gpus all \
-v ~/.cache/huggingface:/root/.cache/huggingface \
--env "HUGGING_FACE_HUB_TOKEN=<your-hf-token>" \
-p 8000:8000 \
--ipc=host \
vllm/vllm-openai:latest \
--model mistralai/Mistral-7B-v0.1

6. Advanced Features

6.1 Structured Outputs

vLLM supports various ways to constrain the model's output format, which is crucial for applications requiring reliable, parsable outputs.

Generating JSON using Pydantic models:

from pydantic import BaseModel
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")
model = client.models.list().data[0].id
class People(BaseModel):
name: str
age: int
completion = client.chat.completions.create(
model=model,
messages=[
{"role": "user", "content": "Generate a JSON with the name and age of one random person."}
],
response_format={
"type": "json_schema",
"json_schema": {
"name": "people",
"schema": People.model_json_schema()
}
},
)
print(completion.choices[0].message.content)

6.2 LoRA Support

vLLM can efficiently serve multiple LoRA adapters on the same base model. This is particularly useful for scenarios requiring customized models for different customers or tasks.

Starting a server with LoRA support:

from vllm import LLM
llm = LLM(model="meta-llama/Llama-2-7b-hf", enable_lora=True)

Specifying a LoRA adapter in a request:

curl http://localhost:8000/v1/completions \
-H "Content-Type: application/json" \
-d '{
"model": "sql-lora", # Specify the LoRA model ID
"prompt": "San Francisco is a",
"max_tokens": 7
}'

6.3 Quantization

Quantization is a technique to reduce model size and memory usage by lowering the precision of model weights. vLLM supports various quantization schemes, such as AWQ and FP8 KV cache.

Enabling FP8 KV cache:

from vllm import LLM
llm = LLM(
model="meta-llama/Llama-2-7b-chat-hf",
kv_cache_dtype="fp8",
calculate_kv_scales=True # Dynamically calculate quantization scales
)

7. Framework Integration

vLLM can be easily integrated with popular LLM application frameworks like Langchain and LlamaIndex for building complex systems such as Retrieval-Augmented Generation (RAG). Typically, vLLM serves as a backend providing fast LLM inference and embedding generation services.

Installing related dependencies:

pip install -U vllm langchain_openai langchain_community

Afterward, in Langchain, you can point the base_url of ChatOpenAI or OpenAIEmbeddings to your vLLM server's address to complete the integration.

8. Conclusion

Through its innovative PagedAttention architecture, vLLM successfully addresses memory management and performance bottlenecks in LLM inference, providing developers with an extremely efficient, flexible, and easy-to-use inference serving engine. Whether conducting quick offline experiments or deploying production-grade, high-concurrency LLM services, vLLM demonstrates excellent performance and powerful functionality. As the community continues to develop, vLLM is becoming one of the standard tools in the field of LLM serving.

LoRA Technical Guide: Parameter-Efficient Fine-Tuning for Large Models

Thu, 26 Jun 2025 00:00:00 +0000

1. Introduction: Why LoRA?

In today's rapidly evolving landscape of Large Language Models (LLMs) and generative AI, we've witnessed an explosive growth in model sizes, ranging from hundreds of millions to trillions of parameters. These massive models demonstrate remarkable capabilities across various tasks. However, a significant challenge emerges: how can we fine-tune these models for specific downstream tasks?

The traditional Full Fine-Tuning approach, which updates all parameters of a model, faces severe challenges:

High computational cost: Fine-tuning a model with billions of parameters requires enormous computational resources and hundreds of GB of GPU memory, which is prohibitively expensive for most developers and small to medium-sized enterprises.
Massive storage requirements: Each fine-tuned model for a specific task requires storing a complete model copy, leading to rapidly escalating storage costs.
Deployment difficulties: Maintaining and switching between multiple massive model copies for different tasks in a production environment is a nightmare.

To address these pain points, Parameter-Efficient Fine-Tuning (PEFT) techniques have emerged. The core idea is to freeze most parameters of the pre-trained model during fine-tuning and only adjust a small portion (typically far less than 1% of the total) of new or specific parameters.

Among the various PEFT techniques, LoRA (Low-Rank Adaptation of Large Language Models) stands out for its excellent performance, efficiency, and implementation simplicity, becoming one of the most mainstream and widely applied solutions today. This document will provide an in-depth yet accessible introduction to the core principles of LoRA and offer detailed practical guidance.

2. Core Principles: The Magic of LoRA

LoRA's core assumption is that the weight changes in large language models when adapting to new tasks are low-rank. In other words, although the weight matrix W of the pre-trained model is very large (e.g., d x d dimensions), the weight change ΔW during fine-tuning has a very low “intrinsic rank.”

Based on this assumption, LoRA doesn't directly update W, but instead approximates ΔW by training two smaller, low-rank matrices B and A, such that ΔW ≈ BA.

W is the pre-trained, frozen weight matrix.
A is an r x d dimensional matrix, where r is a rank much smaller than d.
B is a d x r dimensional matrix.

During fine-tuning, only the parameters of matrices A and B are trainable. The forward propagation computation process is accordingly changed to:

h = Wx + BAx

Here's a diagram that illustrates this process more intuitively:

graph TD
A[Input x] --> B(Pre-trained weights W);
A --> C(Low-rank matrix A);
C --> D(Low-rank matrix B);
B --> E[Wx];
D --> F[BAx];
E --> G((Sum));
F --> G;
G --> H[Final output h];
style B fill:#eee,stroke:#333,stroke-width:2px,stroke-dasharray: 5, 5
style C fill:#9cf,stroke:#333,stroke-width:2px
style D fill:#9cf,stroke:#333,stroke-width:2px

Where x is the input and h is the output. This approach greatly reduces the number of parameters that need to be trained. For example, if d = 4096 and r = 8, the original matrix W has 4096 * 4096 ≈ 16.7M parameters, while A and B together have only 4096 * 8 + 8 * 4096 ≈ 65K parameters, reducing the parameter count by approximately 256 times!

Key parameter r: The rank r is the most important hyperparameter in LoRA. It controls the size of the low-rank matrices and directly determines the number of new parameters.

Smaller r: Fewer trainable parameters, faster training speed, lower memory usage, but may not fully capture complex features of the task.
Larger r: More trainable parameters, stronger model fitting capability, but increases computational cost and risk of overfitting. In practice, r is typically set to 8, 16, 32, or 64, which achieves a good balance between performance and efficiency.

3. Significant Advantages of LoRA

Compared to full fine-tuning, LoRA demonstrates overwhelming advantages in multiple aspects:

Extreme parameter efficiency: As mentioned above, LoRA only requires training a tiny fraction of parameters. We can see this intuitively through the print_trainable_parameters() function, where the proportion of trained parameters is typically less than 1%.
Faster training speed: With a significantly reduced number of parameters for gradient computation and updates, training time is also shortened, accelerating the iteration cycle.
Lower hardware requirements: LoRA significantly reduces GPU memory (VRAM) usage during training, making it possible to fine-tune models with tens of billions of parameters on consumer-grade GPUs (such as RTX 3090/4090).
Flexibility in deployment and management: This is one of LoRA's most attractive advantages. The pre-trained model remains unchanged and can be shared across all tasks. For each downstream task, we only need to save a lightweight (typically just a few MB to tens of MB) LoRA adapter (i.e., the weights of matrices A and B). During deployment, the appropriate adapter can be loaded dynamically according to needs, greatly simplifying model management and switching in multi-task scenarios.

4. Hands-on Practice: LoRA Training Methods

Below, we'll demonstrate a complete example of how to fine-tune a large model using LoRA with the transformers, peft, and trl libraries from the Hugging Face ecosystem.

Step 1: Environment Preparation

First, ensure you have installed the necessary Python libraries:

pip install transformers peft trl datasets torch

Step 2: Load Model, Tokenizer, and Dataset

We select a pre-trained model as the foundation and load the corresponding tokenizer. At the same time, we load a dataset from the Hugging Face Hub for fine-tuning.

from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments
from datasets import load_dataset
# Model ID, can be any supported Causal LM
model_id = "facebook/opt-350m"
# Load pre-trained model
model = AutoModelForCausalLM.from_pretrained(model_id)
# Load tokenizer
tokenizer = AutoTokenizer.from_pretrained(model_id)
# Load dataset (using English quotes dataset as an example)
dataset = load_dataset("Abirate/english_quotes", split="train")

Step 3: Configure LoRA (`LoraConfig`)

This is the core step of LoRA fine-tuning. We need to create a LoraConfig object to define the behavior of the LoRA adapter.

from peft import LoraConfig
lora_config = LoraConfig(
r=16, # Rank of the low-rank matrices, recommended values are 8, 16, 32
lora_alpha=32, # Scaling factor, typically set to twice the value of r
target_modules=["q_proj", "v_proj"], # Specify which model layers to apply LoRA to. For Transformer models, typically q_proj and v_proj
lora_dropout=0.05, # Dropout probability for LoRA layers
bias="none", # Whether to train bias terms, "none" means not training
task_type="CAUSAL_LM" # Task type, here it's causal language modeling
)

target_modules: This parameter is crucial. It tells the PEFT library which modules (typically nn.Linear layers) in the model should have LoRA applied. For most Transformer models, applying it to the query and value projection layers in the Attention mechanism (i.e., q_proj and v_proj) is a common practice. You can print the model object to see the names of all its modules to determine which can be targeted.

Step 4: Apply LoRA and Train with `SFTTrainer`

The SFTTrainer (Supervised Fine-tuning Trainer) provided by the trl library greatly simplifies the fine-tuning process. It has built-in support for peft, so we just need to pass the model, tokenizer, dataset, and peft_config to it.

from trl import SFTTrainer
# Define training parameters
training_args = TrainingArguments(
output_dir="./lora_finetuned_model", # Model output directory
num_train_epochs=3, # Number of training epochs
per_device_train_batch_size=4, # Training batch size per device
logging_dir='./logs', # Logging directory
logging_steps=50, # Log every this many steps
learning_rate=2e-4, # Learning rate
)
# Initialize SFTTrainer
trainer = SFTTrainer(
model=model,
tokenizer=tokenizer,
args=training_args,
train_dataset=dataset,
peft_config=lora_config, # Pass in LoRA configuration
dataset_text_field="quote", # Field name containing text in the dataset
)
# Start training
trainer.train()
# Save the trained LoRA adapter
trainer.save_model()

After training is complete, an adapter_model.bin file and an adapter_config.json file will be generated in the output_dir directory. These are the lightweight LoRA adapter we've trained.

Step 5: Inference with the Trained LoRA Adapter

For inference, we first load the original pre-trained model, then load the trained LoRA adapter weights.

from peft import PeftModel
# Load the original, non-fine-tuned model
base_model = AutoModelForCausalLM.from_pretrained(model_id)
# Load the LoRA adapter
model_with_lora = PeftModel.from_pretrained(base_model, "./lora_finetuned_model")
# Now model_with_lora is a model with LoRA weights integrated, ready for inference
prompt = "The best way to predict the future is to"
inputs = tokenizer(prompt, return_tensors="pt")
# Generate text
outputs = model_with_lora.generate(**inputs, max_new_tokens=20)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

5. LoRA Model Deployment: From Static to Dynamic

After training, efficiently deploying LoRA models into production environments is the crucial next step. LoRA deployment strategies mainly fall into two categories: Weight Merging (Static Deployment) and Dynamic Adapter Loading (Dynamic Deployment). The following flowcharts illustrate these two paths:

Option 1: Weight Merging (Static Deployment)

graph TD
A[LoRA Training Complete] --> B[Base Model + LoRA Adapter];
B --> C["Call merge_and_unload()"];
C --> D[Generate standalone full model];
D --> E[Standard deployment];
style D fill:#c9f,stroke:#333,stroke-width:2px

Option 2: Dynamic Adapter Loading (Dynamic Deployment)

graph TD
A[LoRA Training Complete] --> B[vLLM / TGI server];
B --> C[Load Base Model];
C --> D[Load multiple LoRA Adapters];
D --> E[On-demand inference combinations];
style E fill:#9cf,stroke:#333,stroke-width:2px

Option 1: Weight Merging and Standard Deployment (Static)

This is the simplest and most direct deployment approach. The core idea is to merge the lightweight LoRA adapter weights into the original base model weights, generating a new, standalone full model.

Method: Using the merge_and_unload() method from the peft library, this process can be easily completed.

from peft import PeftModel
from transformers import AutoModelForCausalLM, AutoTokenizer
# Assuming model_id and lora_path are defined
base_model = AutoModelForCausalLM.from_pretrained(model_id)
model_with_lora = PeftModel.from_pretrained(base_model, "./lora_finetuned_model")
# Merge weights
merged_model = model_with_lora.merge_and_unload()
# Now merged_model is a standard Transformers model
# You can save it like any other model
merged_model.save_pretrained("./merged_lora_model")
tokenizer.save_pretrained("./merged_lora_model")

Afterward, you can load and use this merged_lora_model just like any regular Hugging Face model.

Advantages:
- Zero inference latency: After merging, the inference process is identical to a standard model, with no additional computational overhead.
- Simple deployment: No need for any additional inference framework support, can be used directly with standard libraries like transformers.
Disadvantages:
- Loss of flexibility: For each LoRA adapter, you need to save and load a complete model copy, defeating the lightweight purpose of LoRA.
- High storage cost: If you have multiple adapters, the storage overhead is enormous.

Option 2: High-Performance Dynamic Deployment with vLLM (Recommended)

For scenarios requiring simultaneous service of multiple LoRA adapters, vLLM is currently the industry-leading high-performance inference and serving engine. Through core technologies such as PagedAttention, it achieves efficient management and dynamic loading of multiple LoRA adapters, delivering extremely high throughput without significantly sacrificing performance.

Method:

Install vLLM:
```
pip install vllm
```
Start vLLM server: Use the vllm serve command to start an OpenAI-compatible API server. The key is to enable LoRA support with --enable-lora and optionally preload adapters with --lora-modules.
```
# lora_path points to your trained adapter directory
vllm serve meta-llama/Llama-2-7b-hf \
--enable-lora \
--lora-modules my_sql_lora=/path/to/your/sql_lora_adapter
```
Here, we've preloaded an adapter named my_sql_lora.
Send inference requests: You can send requests to the vLLM server using curl or any HTTP client. Just specify the model in the request body as the name of your loaded LoRA adapter.
```
curl http://localhost:8000/v1/completions \
-H "Content-Type: application/json" \
-d '{
"model": "my_sql_lora",
"prompt": "Write a SQL query for all users.",
"max_tokens": 64
}'
```
vLLM will automatically route the request to the corresponding LoRA adapter for inference.

Using Python Client: vLLM also provides a Python API for direct calls in code.

from vllm import LLM, SamplingParams
from vllm.lora.request import LoRARequest
# Initialize LLM engine with LoRA support
llm = LLM(model="meta-llama/Llama-2-7b-hf", enable_lora=True)
sampling_params = SamplingParams(max_tokens=64)
# In the generate call, specify which adapter to use via lora_request
outputs = llm.generate(
"Write a SQL query for all users.",
sampling_params,
lora_request=LoRARequest("my_sql_lora", 1, "/path/to/your/sql_lora_adapter")
)

Advantages:
- Extremely high throughput: Designed for large-scale concurrent inference.
- Dynamic flexibility: Can simultaneously serve hundreds or thousands of LoRA adapters, loading them on demand, perfect for multi-tenant scenarios.
- Memory efficient: PagedAttention mechanism effectively manages GPU memory, avoiding waste.
Disadvantages:
- Slightly more complex deployment: Requires additional learning and configuration of vLLM service.

Option 3: Other Dynamic Deployment Options (e.g., TGI)

Hugging Face's own Text Generation Inference (TGI) is another powerful production-grade inference server. Similar to vLLM, TGI also supports loading multiple LoRA adapters at startup and dynamically applying them based on incoming request headers. It integrates best with the Hugging Face ecosystem and is a strong competitor to vLLM.

Deployment Options Comparison Summary

Feature	Weight Merging (Static)	vLLM (Dynamic)	TGI (Dynamic)
Performance/Throughput	Highest (lowest single request latency)	Very High	High
Flexibility	Low (no dynamic capability)	Very High	High
Deployment Complexity	Low	Medium	Medium
Memory Usage	Very High (N adapters = N times memory)	Low (efficient sharing)	Low (efficient sharing)
Suitable Scenarios	Single, fixed tasks	Multi-tenant, high-concurrency, multi-task scenarios	Production deployment in Hugging Face ecosystem

6. Advanced Topics

Multi-adapter Management: PEFT supports dynamically adding, switching, and disabling multiple adapters on a single model using methods like model.add_adapter() and model.set_adapter(), providing great convenience for building flexible multi-task systems.

7. Conclusion

As a revolutionary parameter-efficient fine-tuning technique, LoRA successfully addresses the high cost challenges of fine-tuning in the era of large models. Through clever low-rank decomposition ideas, it greatly reduces computational resource and storage requirements while maintaining fine-tuning effectiveness. Combined with advanced inference engines like vLLM, LoRA deployment and service have become unprecedentedly efficient and flexible, driving the application of large models in more specific scenarios.