企业官网建设流程全解析

手头只有一块6GB显存的显卡，能不能跑通“微调一个大语言模型，再把它部署成服务对外提供推理”的完整链路？这个问题我过去一年里被问过很多次，每次我都直接回答：能，前提是别按数据中心那套思路来。

6GB显存这个量级，恰好卡在“玩具”和“生产”之间的尴尬地带。你说它不行吧，跑个1.5B到3B参数的模型很从容；你说它行吧，稍微有点野心的7B模型都能把显存撑爆。这篇博文，我会把从LoRA微调到vLLM部署的完整流程拆开讲清楚，包括每一步的选型原因、显存预算、参数设置，以及我实际踩过的坑，比如GPU Crash Dump、vLLM老版本chunk_size的Bug、模型合并后格式对不上这类问题。全文基于常见的消费级显卡实践，硬件就是你手头这张6GB卡，软件栈是PyTorch + PEFT/QLoRA + vLLM，模型以Qwen系列为主。

这套流程适合谁？想在小显存环境里跑通全流程的开发者，准备低成本做垂直领域小模型的技术爱好者，或者公司里只有一台普通Windows/Linux机器、想快速落地私有化小模型的人。看完你不仅能复现，还能理解每一步背后的显存计算逻辑，遇到问题自己会排查。

1. 6GB 显存能做到什么：先想清楚路线再动手

1.1 6GB显存下的现实约束与核心思路

先说结论：6GB显存，能训练的上限大约是3B参数模型（配合QLoRA），能推理的上限大约是7B参数模型（配合GPTQ/AWQ 4bit量化）。这块硬约束决定了整个技术路线的走向，也决定了你不能像云端一样直接全量微调一个大模型。

核心思路一句话总结：用4bit量化把模型压缩到能放进显存，用LoRA把训练时的可训练参数压到总量的0.5%到1%，用vLLM的PagedAttention把推理时的KV Cache管理好。这三步环环相扣。如果没有QLoRA，光是加载一个3B模型的fp16权重就要6GB显存，训练时压根没有余量；如果没有LoRA，反传梯度带来的显存开销直接翻倍；如果没有vLLM，部署时KV Cache会跟权重抢显存，并发一高就OOM。

在动手之前，我强烈建议你先做一个显存规划。公式不复杂：训练显存 ≈ 模型权重 + 优化器状态 + 梯度 + 激活值 + LoRA适配器。QLoRA的意义在于把“模型权重”这一项从fp16变成了4bit，一个3B模型从6GB直接压缩到1.5GB左右，剩下4.5GB留给梯度、激活值和KV Cache。这就是6GB卡能跑微调的根本原因。

1.2 全量微调、Freeze微调与LoRA：优劣势对比

很多人第一次接触微调，看到全量微调、Freeze微调、LoRA这三个词容易懵。我直接拿实际训练场景做个对比，帮你搞清楚为什么6GB显存下只能选LoRA。

全量微调：所有参数都参与梯度更新。一个3B模型，就算是用AdamW优化器，显存开销大概是模型权重的12到16倍（fp16权重2倍 + 梯度1倍 + Adam状态8倍 + 激活值若干）。3B模型全量微调至少需要20GB以上显存，6GB卡直接不用想。而且全量微调有个隐藏风险——灾难性遗忘，模型学了新知识，把原有的通用能力冲掉了，小数据集上尤其明显。

Freeze微调：冻结大部分层，只训练最后几层或者特定层。这个方法的好处是显存开销比全量小，但它不改变模型内部的表征，只是调整了“输出头的映射”，对领域适配的效果很有限。我试过用Freeze微调做一段风格转换，结果模型学到的只是“改措辞”，而不是真正理解新领域的表达方式。

LoRA（Low-Rank Adaptation）：冻结原始权重，只训练注入的低秩矩阵。以Qwen2.5-1.5B为例，如果设r=8，可训练参数通常只有2000万到3000万，占总参数的1%出头。这意味着什么？训练显存里，模型权重即便以4bit加载，也只占1GB左右，优化器状态和梯度的开销全部集中在LoRA参数上，小到可以忽略，剩下的显存可以大方地分配给序列长度和Batch Size。

三者对比下来，6GB显存的正确答案就是LoRA，再往前一步加上4bit量化，就是QLoRA。如果你连LoRA都不想装，那基本没有训练空间。

1.3 全链路流程：微调到部署的五个阶段

整个流程可以拆成五个阶段：环境准备、数据与训练、模型合并、量化、部署。顺序不能乱，每一步的输出是下一步的输入。

环境准备阶段要搞定的是驱动、CUDA、PyTorch GPU版，以及PEFT、Transformers、Datasets、vLLM这些依赖库。数据与训练阶段，用QLoRA跑微调，产出LoRA适配器权重。模型合并阶段，把LoRA适配器合并回原始模型，生成一个完整的Safetensors模型目录。量化阶段，用AutoGPTQ或AWQ把合并后的fp16模型压到4bit。部署阶段，用vLLM加载量化后的模型，启动OpenAI兼容服务。

这套链路里最容易翻车的是中间两个阶段，很多人合并模型时选择“先合并再量化”，但合并完不检查文件，直接丢给vLLM，结果报“tensor parallelism requires div by 3”之类的错误，其实只是模型目录缺了文件。后面我会专门讲怎么用模型检查器验证。

2. 环境准备：先让 PyTorch 和 CUDA 正常起来

2.1 显卡驱动与CUDA版本检查

环境准备是整个流程里最枯燥但最容易出问题的环节。我见过太多人栽在环境上，微调代码写得很对，结果PyTorch根本用不了GPU，白白浪费一整天。

第一步，确认显卡。NVIDIA显卡用nvidia-smi查看驱动版本和CUDA版本：

nvidia-smi

重点看右上角的“CUDA Version”，这是驱动支持的最高CUDA版本，不是当前激活的版本。以6GB卡常见的RTX 2060、RTX 3050、GTX 1660 Super为例，2024年后的驱动一般支持CUDA 12.x。

第二步，确认PyTorch需要的CUDA版本。这里有个常见的误区：PyTorch官方预编译包自带CUDA runtime，不需要你单独装完整CUDA Toolkit，只要显卡驱动足够新就行。比如你装的是pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121，这个cu121表示PyTorch内置了CUDA 12.1的runtime，你机器上驱动只要支持CUDA 12.1以上就能跑通。

提示：如果你在Linux服务器上操作，特别是CentOS 7.9，安装GPU驱动时注意内核版本和gcc版本兼容性。CentOS 7.9默认内核可能偏旧，装新版驱动会报“Unable to load the 'nvidia-drm' kernel module”。解决方案是升级内核到3.10.0-1160以上，或者用--no-opengl-files参数装驱动以避免跟系统已有的OpenGL库冲突。

第三步，验证CUDA能用。安装完驱动后，重启系统，重新执行nvidia-smi，确认能正常显示显卡信息。

2.2 PyTorch GPU版安装与验证

驱动准备好之后，创建Python环境并安装PyTorch。我推荐用conda管理环境，避免系统Python环境被搞乱。

conda create -n llm python=3.10 -y conda activate llm pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

这里有个细节：Python版本建议3.10，因为vLLM对Python 3.12的支持有过一段时间的滞后，而3.8又太低，很多新版依赖不支持。3.10是当前兼容性最好的折中选择。

安装完之后，用下面这段代码验证GPU是否可用：

import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) print(torch.cuda.get_device_capability(0)) print(torch.cuda.mem_get_info())

如果输出torch.cuda.is_available()为True，说明PyTorch已经正确识别到GPU。mem_get_info()返回的是总显存和剩余显存，单位是字节，6GB卡通常显示(6442450944, 6043721728)左右。

如果返回False，排查顺序是这样的：第一，nvidia-smi能否正常输出？不能则驱动没装好；第二，PyTorch的CUDA版本是否高于驱动支持的CUDA版本？是则需要换低版本的PyTorch或升级驱动；第三，是否用了CPU版的torch？pip list | grep torch看一下，若显示torch-cpu字样说明装错了包。

2.3 依赖库安装与数据准备

微调阶段还需要PEFT、Transformers、Datasets、Accelerate、Bitsandbytes、HuggingFace Hub等库。这里我直接给一组经过验证的版本组合，能避免大部分兼容性问题：

pip install transformers==4.45.0 datasets==2.21.0 peft==0.12.0 accelerate==0.34.0 bitsandbytes==0.43.3

注意：bitsandbytes在Windows上一直比较折腾，0.43.3之后官方才逐步支持。如果你是Windows环境，务必确认已经安装了Microsoft C++ Build Tools，否则会出现load library error之类的报错。Linux一般没这个问题。

数据准备方面，微调需要的数据格式取决于你用的脚本。如果自己写训练循环，推荐JSONL格式，每一行一个样本，最常见的指令微调结构是：

{"instruction": "请把下面的句子翻译成英文", "input": "今天天气真好", "output": "The weather is nice today."}

数据量方面，LoRA微调不是数据越多越好。1万条以内的高质量数据，效果远好于10万条爬来的噪声数据。我做过一个实验：同一个数据集，清理前训练后模型驴唇不对马嘴，清理后训练效果直接提升了一大截。数据质量永远排在数据量前面。

3. LoRA 微调实战：6GB 显存下的参数选择与避坑

3.1 QLoRA方案与显存预算拆解

环境备好了，数据也整理好了，接下来进入核心环节：微调。我这里推荐QLoRA而不是纯LoRA，原因很直接：纯LoRA需要把模型权重以fp16形式加载，一个3B模型就吃掉6GB显存，训练时的激活值、梯度根本没地方放。QLoRA把模型权重重压到4bit，一个3B模型只占1.5GB左右，训练时才能有余量。

QLoRA的主意是Meta在2023年提出的，核心三件套：4bit NormalFloat量化、Double Quantization（双重量化，对量化常数再量化一次）、Paged Optimizer（分页优化器，把优化器状态临时换出到CPU内存）。效果上，QLoRA在保持与LoRA相当效果的同时，显存占用降低了三分之一到一半。

显存预算可以这么算。以Qwen2.5-1.5B模型在6GB显存上训练为例：

• 4bit量化后的模型权重：约1GB
• LoRA适配器参数：约0.08GB（r=8，target_modules全开）
• 梯度：约0.08GB
• 优化器状态（AdamW）：约0.2GB
• 激活值：取决于Batch Size和输入长度，约1到2GB
• 中间缓冲区、CUDA context等杂项：约0.5GB

实际看下来，Batch Size=1、序列长度512时，峰值显存大约3.5GB，还有约2.5GB的余量用于增大Batch或序列长度。如果序列长度拉到2048，激活值会暴涨到3GB以上，总显存直接逼近6GB，这时候就需要调低Batch或开启梯度累积。

3.2 关键训练参数如何定

微调效果的很大一部分取决于参数设置。以下是我多次实验后总结的实用配置，可以直接套用：

from transformers import ( AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig, TrainingArguments ) from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from datasets import load_dataset from trl import SFTTrainer import torch model_name = "Qwen/Qwen2.5-1.5B-Instruct" # 4bit量化配置 bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_use_double_quant=True, bnb_4bit_compute_dtype=torch.bfloat16, ) model = AutoModelForCausalLM.from_pretrained( model_name, quantization_config=bnb_config, device_map="auto", trust_remote_code=True, ) tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True) tokenizer.pad_token = tokenizer.eos_token model = prepare_model_for_kbit_training(model) # LoRA配置 lora_config = LoraConfig( r=8, lora_alpha=16, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_config) model.print_trainable_parameters()

先解释一下LoRA的三大参数：

r（秩）决定了低秩矩阵的维度。r=8是小型任务（风格转换、特定格式输出）的常用起点；r=16适合需要学习更多新知识的场景；r=4适合数据量小、任务简单的场景。不是r越大越好，过大的r会引入噪声，过小则容量不够。6GB卡上建议从r=8开始，跑通了再调。

lora_alpha（缩放系数）控制LoRA注入权重的缩放比例，一般设为r的1到2倍。alpha/r的值相当于学习率放大系数，设置在2到4之间比较常见。我习惯设alpha=16、r=8，对应缩放系数2。

target_modules（目标模块）指定哪些模块注入LoRA适配器。对Qwen系列，q_proj、k_proj、v_proj、o_proj这四个注意力头投影层是标配。加不加gate_proj、up_proj、down_proj（FFN层）取决于你想改动模型的程度。加全了可训练参数会变多，效果不一定更好，但显存占用会涨。我自己的经验：做指令微调只用注意力层就够，做领域适配（比如让它学会特定文章风格）可以试试把FFN层也加上。

训练超参数我用TRL的SFTTrainer管理：

training_args = TrainingArguments( output_dir="./qwen-lora", num_train_epochs=3, per_device_train_batch_size=1, gradient_accumulation_steps=8, gradient_checkpointing=True, logging_steps=10, save_steps=100, learning_rate=2e-4, lr_scheduler_type="cosine", warmup_ratio=0.03, bf16=True, max_seq_length=512, packing=False, )

重点说几个关键的：per_device_train_batch_size=1是我在6GB卡上测试过的安全值，想调大就先观察显存占用；gradient_accumulation_steps=8是等效Batch Size为8的关键，实际Batch=1乘以累加步数8；gradient_checkpointing=True会牺牲约30%训练速度换取60%以上激活值显存下降，6GB卡上必须开；max_seq_length=512是初次跑的安全长度，等稳定后再拉长。

3.3 训练过程实录与显存监控

启动训练之后，你以为就完事了？远没有。训练过程要盯着显存和Loss曲线看。

建议开一个单独的终端，用watch命令持续观察显存占用：

watch -n 1 nvidia-smi

正常情况下你会看到显存占用在3000MB到5000MB之间波动。如果接近6000MB，说明要OOM了，需要立刻采取措施。

我遇到过最典型的OOM表现不是直接报错，而是训练好几个step之后突然崩溃，这种最让人崩溃。原因通常是激活值在长序列下突然暴涨，或者梯度累积到某一轮触发了更大的中间张量。解决思路是按顺序尝试：把max_seq_length从512降到256，或把per_device_train_batch_size锁定为1，或把gradient_accumulation_steps从8降到4。

训练过程中的Loss曲线怎么看？初次跑的时候，Loss不减甚至上升是正常的，因为学习率还在warmup阶段。warmup结束后，Loss应该缓慢下降。如果跑了200步Loss纹丝不动，先检查数据有没有问题，比如是不是所有label都是padding token，或者instruction和output拼错了。

一个容易忽视的点：LoRA训练时务必要冻结所有非目标层，LoraConfig里bias="none"就是干这个的。如果设成bias="all"，所有bias参数都会参与训练，显存和可训练参数都会增加，效果提升有限，属于不划算的买卖。

3.4 模型合并与检查

训练结束，你得到的是LoRA适配器权重，存放在output_dir里的adapter_config.json和adapter_model.safetensors。这两个文件不能直接用于vLLM部署，需要把它合并回原模型。

合并代码：

from transformers import AutoModelForCausalLM, AutoTokenizer from peft import PeftModel import torch base_model_name = "Qwen/Qwen2.5-1.5B-Instruct" lora_model_path = "./qwen-lora/checkpoint-500" model = AutoModelForCausalLM.from_pretrained( base_model_name, torch_dtype=torch.bfloat16, device_map="auto", ) model = PeftModel.from_pretrained(model, lora_model_path) merged_model = model.merge_and_unload() merged_model.save_pretrained("./qwen-merged") tokenizer = AutoTokenizer.from_pretrained(base_model_name) tokenizer.save_pretrained("./qwen-merged")

这里有个关键点：merge_and_unload()执行的是把低秩矩阵乘积B * A融合进原始权重，然后卸载LoRA结构。合并完成后，必须用model_checkpoint或者HuggingFace的from_pretrained重新加载验证一次，确保模型文件没有损坏。

我一般会跑一个简单的“模型检查器”流程：

from transformers import AutoModelForCausalLM, AutoTokenizer model = AutoModelForCausalLM.from_pretrained("./qwen-merged", trust_remote_code=True) tokenizer = AutoTokenizer.from_pretrained("./qwen-merged") inputs = tokenizer("你好，请自我介绍一下", return_tensors="pt") outputs = model.generate(**inputs, max_new_tokens=50) print(tokenizer.decode(outputs[0], skip_special_tokens=True))

如果输出正常，说明合并成功。如果报错，最常见的原因是save_pretrained时目录里缺少config.json，导致重新加载时找不到模型结构。另一个坑是tokenizer文件缺失，加载后生成会崩溃。

提示：6GB卡上加载合并后的fp16模型（1.5B约3GB）进行验证是可行的，但如果你微调的是3B模型，fp16权重约6GB，很可能在验证时就OOM。这种情况建议直接用vLLM加载原模型加LoRA，或者先量化再验证。

4. vLLM 部署：把微调好的模型变成可用服务

4.1 vLLM 安装与部署启动

微调完成、模型合并通过验证，接下来进入部署环节。这里我用的方案是vLLM，而不是FastAPI + Transformers裸写，原因只有一个：vLLM的PagedAttention能把显存利用率提升好几倍，尤其是在并发请求场景下。

安装vLLM：

pip install vllm

vLLM依赖特定版本的PyTorch和CUDA，所以建议在干净的虚拟环境里安装，避免跟训练环境冲突。若遇到版本冲突，可以用pip install vllm --upgrade先解决依赖。Windows环境vLLM支持度稍差，建议用WSL2或者直接上Linux。

启动服务：

python -m vllm.entrypoints.openai.api_server \ --model ./qwen-merged \ --served-model-name qwen-local \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.92 \ --max-model-len 2048

解释一下关键参数：--model直接指定本地模型目录，vLLM会自动加载；--tensor-parallel-size 1表示单卡部署，6GB卡只能设置为1；--gpu-memory-utilization 0.92是vLLM允许使用的显存比例，设置为0.92意味着给KV Cache留出最大空间，同时保留约8%的显存用于模型权重和活跃请求；--max-model-len 2048限制最大上下文长度，这个值直接影响KV Cache的预分配大小。

启动成功后，服务默认监听8000端口，访问http://localhost:8000/v1/models能看到模型信息。用curl测一下对话接口：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen-local", "messages": [{"role": "user", "content": "你好，请介绍一下你自己"}], "max_tokens": 200, "temperature": 0.7 }'

如果返回JSON格式的响应，说明部署成功。

4.2 量化：从fp16到GPTQ/AWQ

部署1.5B模型不需要量化，但如果你的目标是3B、7B模型，或者想让1.5B模型的KV Cache能开得更大，那量化就是必经之路。

vLLM支持GPTQ和AWQ两种主流量化格式。两者的核心区别：GPTQ是一次性校准量化，基于误差最小化做逐层量化；AWQ则基于激活值的重要性分析，保留对模型输出影响大的权重通道的精度。实测下来，AWQ在同等bit数下质量略好，但GPTQ的生态兼容性更强。

用AutoAWQ把合并后的模型转成AWQ格式：

pip install autoawq

from awq import AutoAWQForCausalLM model_path = "./qwen-merged" quant_path = "./qwen-awq" quant_config = {"zero_point": True, "q_group_size": 128, "w_bit": 4} model = AutoAWQForCausalLM.from_pretrained(model_path) model.quantize(tokenizer=None, quant_config=quant_config) model.save_quantized(quant_path)

量化后模型体积从约3GB降到约1GB。然后vLLM直接加载：

python -m vllm.entrypoints.openai.api_server \ --model ./qwen-awq \ --served-model-name qwen-local \ --quantization awq \ --gpu-memory-utilization 0.92

注意：vLLM加载AWQ模型时，--quantization awq参数可以省略，vLLM会自动从config.json中识别量化方式；但如果识别失败，手动指定是有效的排查手段。

4.3 显存利用率与缓存优化

vLLM的显存管理核心是PagedAttention，它把KV Cache分成固定大小的块，像操作系统分页一样按需分配。这个机制的最大好处是：传统方案中KV Cache是连续分配的，预分配过大浪费显存，过小则并发上限低；PagedAttention按块分配后，KV Cache的碎片化问题得到很大缓解。

在6GB卡上部署，显存调配的优先级是：模型的权重占用是固定的，KV Cache的可调整上限由--gpu-memory-utilization决定，而--max-model-len则限制了每个请求能占用的KV Cache上限。

我实测过一个场景：6GB卡上部署Qwen2.5-1.5B-AWQ（约1GB权重），设--gpu-memory-utilization 0.92后，实际可用KV Cache约4.5GB，--max-model-len 2048时，理论并发可以从个位数涨到几十甚至上百（取决于每个请求的实际长度）。这就是vLLM相比原生Transformers推理性能提升数十倍的来源。

关于缓存命中率，vLLM引入了Prefix Cache机制，对相同前缀的请求复用KV Cache。这对“多轮对话，前几轮内容相同”的场景效果显著。实测下来，如果请求的前128个token相同，TTFT（首token生成时间）可以降低50%以上。若你想进一步优化，可以关注vLLM的自动前缀缓存实现：它默认是开启的，通过计算哈希来匹配前缀。聊天机器人、客服这类高频重复前缀的场景，收益尤其大。

4.4 高并发与OpenAPI兼容验证

部署完成后，要验证服务在高并发下是否稳定。这里用Python的openai库做并发测试：

from openai import OpenAI import concurrent.futures client = OpenAI( base_url="http://localhost:8000/v1", api_key="EMPTY", ) def test_call(i): response = client.chat.completions.create( model="qwen-local", messages=[ {"role": "user", "content": f"你好，请用一句话介绍你自己，这是第{i}次请求"}, ], max_tokens=100, ) return response.choices[0].message.content with concurrent.futures.ThreadPoolExecutor(max_workers=20) as executor: futures = [executor.submit(test_call, i) for i in range(100)] for future in concurrent.futures.as_completed(futures): print(future.result()[:30])

如果100个并发请求全部返回且没有超时，说明部署配置基本合理。如果出现显存溢出（vLLM报GPU OOM），优先调低--gpu-memory-utilization到0.85，或者降低--max-model-len。注意，vLLM的OOM报错样式跟原生PyTorch不太一样，它会直接说Error in model.execute: CUDA out of memory，但服务进程不一定退出，有可能卡在假死状态，这时候需要重启服务进程。

提示：vLLM服务对输入长度非常敏感。如果你收到Prompt length exceeds max model length之类的错误，是因为请求的prompt token数超过了--max-model-len的设置。解决办法是把--max-model-len调大，但代价是KV Cache预分配也会变大。小显存场景下，建议在客户端层面做长度截断，而不是无限调大max-model-len。

5. 常见问题与排错实录

5.1 GPU Crash Dump Triggered 与 CUDA 报错

训练或者部署过程中，最让人绝望的错误之一就是“GPU Crash Dump Triggered”。出现这个提示，说明CUDA内核在执行过程中触发了硬件级别的异常，通常是非法内存访问或驱动级错误。

我遇到过几次，场景各不同，但排查思路是一致的：

第一，先用dmesg看系统日志：

sudo dmesg | tail -30

如果有NVRM: GPU at 0000:01:00.0 has fallen off the bus之类的信息，多半是显卡供电或散热问题。6GB卡大多是老旧二手卡，比如P106、GTX 1660 Super矿卡，长时间高负载跑到快满载，供电跟不上就会出现这种问题。解决思路：降低功耗墙，用nvidia-smi -pl 150把功耗限制到150W（具体数值取决于显卡型号）；清理机箱积灰，确保散热正常。

第二，检查显存是否确实超了。训练时如果设置不当，激活值会在某个瞬间冲破6GB，GPU直接Crash。正常OOM还好，如果Crash说明是内核直接访问了非法显存地址，多见于bitsandbytes的4bit反传和某些CUDA算子在低显存边缘的不稳定。

第三，升级或降级驱动。我实测过，某些版本的NVIDIA驱动在Linux下跟CUDA 12.1的兼容性有坑，会导致偶发性Crash。换一个认证驱动版本（比如535系列）能解决大部分问题。

另外，Windows下报“GPU Crash Dump Triggered”的另一个常见原因是显卡驱动TDR（Timeout Detection and Recovery）机制触发。Windows会默认认为GPU执行超过2秒就是卡死，自动重置驱动。这个可以改注册表解决，但不建议通过系统层面强行拉长TDR，因为治标不治本，根源还是显存或计算负载过高。

5.2 vLLM 老版本 chunk_size Bug 与升级建议

vLLM迭代非常快，但快也意味着Bug多。我印象最深的是vLLM 0.23.0版本里的chunk_size相关Bug。那个版本引入了chunked prefill机制，允许把长Prompt拆成多个chunk处理，设计目的是提高调度效率，但实际使用时，某些配置会导致空chunk被反复调度，CPU占用飙升，甚至卡死。

当时社区里的解决方案主要有两条路：一条是把vLLM升级到0.23.0之后的修复版本；另一条是显式设置--chunked-prefill-size参数，老版本默认值在某些模型上会触发Bug。

我的建议是：部署别追新。vLLM是一个快速迭代的项目，新版本虽然功能多，但稳定性不一定比老版本好。目前比较稳妥的做法是选择一个长时间没有重大Bug的版本，比如vLLM 0.10系列或更新的稳定版本。如果Pytorch环境兼容的话，装完别急着升。

如果你在启动vLLM时报了一堆看不懂的C++堆栈错，大概率是版本和模型/config不兼容。这时候别硬调参数，直接pip show vllm看版本，然后到官方Release Notes里找对应版本有没有已知问题。

5.3 加载本地模型的格式问题与兼容性

vLLM加载本地模型时最容易踩的坑是目录不完整。HuggingFace模型目录里，config.json、tokenizer.json、tokenizer_config.json、model.safetensors这四个文件缺一不可，有一点缺失，vLLM要么直接报错，要么加载后行为异常。

另一个经典问题是：你在训练环境中用AutoModelForCausalLM.from_pretrained能加载模型，但vLLM报错。这往往是因为训练时设置了trust_remote_code=True，而Qwen模型的config.json里指定了auto_map，需要远程代码。vLLM加载Qwen系列时，直接指定--trust-remote-code参数即可：

python -m vllm.entrypoints.openai.api_server \ --model ./qwen-merged \ --trust-remote-code

还有一种情况：微调后合并出的模型，vocab size跟tokenizer里实际的special_token数量对不上，导致Embedding维度错误。这种错误通常表现为embedding size mismatch。解决办法是合并前确保tokenizer的special token没有新增，或者用resize_token_embeddings手动对齐。

5.4 微调与部署问题速查表

把上面所有问题整理成一张速查表，方便实际排查时快速定位：

这些坑我都实际踩过，其中GPU Crash Dump那个排查最耗时，花了整整一个下午才发现是显卡供电不稳。所以我建议你动手之前，先确认自己显卡的供电和散热，6GB卡大多是老卡，别在高负载训练时把硬件搞挂了，那才是真正的灾难。

6. 一些小经验

这套流程走下来，我最大的体会是：6GB显存不是限制，而是帮你做减法的工具。显存小，你就不会想着全量微调，不会硬上7B模型，反而更容易产出小而美的成果。我见过很多44GB大显存卡的用户，跑了一堆实验，最后能落地的反而不多。

如果你想在这个方向上继续扩展，有几个思路可以参考。一是把LoRA微调的数据集做得再精细一些，小模型对数据质量非常敏感，一条坏数据的破坏力远超你的想象。二是试试Quantization Aware Training（QAT），先量化再微调，让模型在低bit精度下学习，通常是进一步压缩模型体积的同时保住效果的手段。三是把部署链路接到更复杂的应用里，比如用vLLM的OpenAI兼容接口配合LangChain或Dify做Agent应用，模型的“最后价值”是在实际场景里交付的。

最后再分享一个实用小技巧：训练完的LoRA适配器先别删，保留全部checkpoint。因为LoRA文件很小（几十MB），你可以随时换一组超参数重新训练，而不需要重新加载原始大模型。这在调试时能省下大量时间。我自己的流程是：基线模型固定不动，十几个LoRA适配器分别对应不同任务，按需加载或合并。这套工作流在6GB卡上很稳定，希望你也跑得顺。