我先把结论扔给各位：在6GB显存的消费级显卡上，跑通"LoRA微调 + vLLM部署"的模型全生命周期，不仅能实现，而且能稳定落地。我这张卡是RTX 3060 Laptop 6GB，白天当办公机，晚上当训练推理服务器，整个流程来回折腾了两个多月，中间踩了无数坑。今天这篇东西，就是把这条完整链路从零到一拆开讲清楚。
先说清楚这套方案适合谁：手头只有一块6GB显卡、想真正上手大模型微调和部署的同学，或者想在本地私有化跑一个垂直领域小模型的工程师。10GB以上显存的可以绕道去看更大模型的内容，但很多细节（比如显存计算、参数取舍、服务化技巧）仍然是通用的。如果你已经知道什么叫LoRA，也听说过vLLM，但始终没把整个流程串起来，那这篇正好是你要的。
整个链路由四步组成：数据准备与LoRA微调、模型权重合并导出、vLLM服务化部署、线上验证与迭代。每一步都有对应的显存瓶颈和解决方案。而6GB这个数字，恰好是"低配高用"的最典型样本——它逼着你在模型规模、量化精度、并发策略上做出合理取舍，所有经验都能平移到更大的卡上。
1. 整体设计与方案选型：为什么是LoRA加vLLM
1.1 微调方式对比：全量、Freeze与LoRA
在动手之前，先想清楚用哪种微调方式。很多人一上来就问"LoRA怎么调"，其实是被题目推着走。模型的参数更新方式大体分三种：全量微调、冻结部分层微调、LoRA这种低秩适配微调。三者的区别用一张生活化的比喻解释：全量微调像是重新装修整房子，所有墙体、水电、地板全换；Freeze微调相当于只重刷客厅，卧室厨房保留原样；LoRA则是给现有房间额外接一套可拆卸的智能家居，只在原有结构旁边加一圈旁路，不破坏原来的东西。
对于6GB显卡，全量微调基本是禁区。哪怕是最小的1.5B模型，全量训练时优化器状态、梯度、激活值叠加起来，轻松干掉6GB显存。我曾经试着在32GB内存+6GB显存的机器上跑Qwen2.5-1.5B的全量微调，batch size降到1，序列长度砍到512，仍然OOM。Freeze微调比全量好一些，但依然要保存全部可训练参数的梯度，显存开销还是偏高，适合某些特定场景，比如只训练模型的一部分层来做领域适配，但通用性不如LoRA。
LoRA的原理其实不复杂：在原始权重矩阵旁边插入两个低秩矩阵（A和B），训练时只更新这两个小矩阵，原来的权重保持冻结。这样做的好处有两个：一是显存占用大幅下降，因为可训练参数的数量能降到原来的0.1%到1%；二是训练产物很小，一个LoRA权重文件通常只有几十MB到几百MB，方便分发和迭代。动手之前请记住：LoRA是"旁路适配"，不是在原模型上打补丁。所以训练结束后，要么将LoRA权重与原模型合并，要么在推理框架中同时加载原模型和LoRA权重。
1.2 部署框架对比：vLLM、llama.cpp与Ollama
部署环节的选择同样重要。目前主流的本地推理框架有三个：vLLM、llama.cpp（及其封装Ollama）、还有SGLang。我的建议是：如果要自己用命令行跑、或者是折腾自定义API，优先vLLM；如果要快速给同事演示、不想写太多代码，Ollama更友好；如果极在意内存占用或者说需要在纯CPU环境运行，llama.cpp是不二选择。
vLLM的核心优势是高性能服务化。它通过PagedAttention机制管理KV Cache，显存利用率比传统方式高很多，而且内置了continuous batching，多个请求可以在一个batch里动态调整，吞吐量明显优于逐个推理。6GB显存虽然不大，但vLLM依然能跑1.5B模型，并能同时处理少量并发请求。llama.cpp走的是GGUF量化路线，它的CUDA支持其实也不错，但线程模型和批处理策略没有vLLM那么激进，更适合本地单机轻量推理。
我在选型时最终敲定"LoRA微调 + vLLM部署"，是因为这个组合覆盖了从训练到服务的完整闭环。LoRA解决"显卡小也能训练"的问题，vLLM解决"训练完怎么高效跑起来"的问题。两者都吃显存，但只要控制好模型规模和量化精度，6GB完全够用。
2. 环境准备：先把地基打牢
2.1 驱动、CUDA与PyTorch版本匹配
在6GB显卡上做微调和部署，最大的风险不是算力不足，而是环境混乱。先聊聊驱动和CUDA。以RTX 3060为例，NVIDIA驱动建议装到535版本以上，CUDA Toolkit不必全局安装，因为PyTorch和vLLM大多会自带运行时的CUDA依赖。你需要确认的核心点是：显卡驱动支持的最新的CUDA版本，要高于你安装的PyTorch所依赖的CUDA版本。
我踩过一个大坑：系统里装了CUDA 12.1，PyTorch却用了cu118编译版本，结果就是选GPU设备时能识别到显卡，但一跑tensor操作就报错，提示CUDA driver版本不匹配。后来统一思路：全部基于conda环境安装，PyTorch用官方源的cu118或cu121版本，vLLM用对应的预编译wheel，驱动保持系统级更新，不要轻易动系统级CUDA。
这里给出一套经过验证的组合（截至文章撰写时为稳定方案）：
- Python 3.10
- CUDA 12.1驱动（系统级）+ CUDA 11.8或12.1运行时（容器/虚拟环境内）
- PyTorch 2.1.2+cu118
- vLLM 0.4.x或更高（需匹配pytorch版本）
- transformers 4.42+，datasets，peft，accelerate
注意，vLLM对PyTorch版本很挑剔，安装前一定到它的官方文档看支持矩阵。我曾经为了图新装了PyTorch 2.4，结果vLLM装完后直接提示找不到对应算子，白白折腾了一个晚上。
2.2 用Docker还是裸环境
在Linux上，我强烈推荐用Docker。6GB显存的机器通常内存也不大，Docker隔离好环境，不污染系统，可以随便折腾。一条命令就能把vLLM官方镜像拉下来跑服务，也能在容器里装LlamaFactory做训练，非常干净。但在Windows上，Docker的GPU透传需要WSL2配套，NVIDIA Container Toolkit的兼容性有时候会出问题。如果你不想折腾，Windows下直接用conda建虚拟环境也行，只是vLLM在Windows上的支持一直不太完美，早期版本甚至无法在Windows原生运行，后来才通过WSL2曲线救国。
我个人在裸环境里的做法是：一个conda环境专门放训练相关（PyTorch、peft、transformers、LlamaFactory），另一个conda环境专门跑vLLM和API服务。两个环境分开可以避免版本冲突。磁盘上预留至少50GB空间，因为原始模型、LoRA中间权重、合并后的模型、日志文件加在一起很快就满了。
2.3 显存、内存与Swap的协同规划
6GB显存不是孤立存在的，系统内存和Swap的质量直接影响稳定性。大模型加载到显存时，会先经过内存缓冲；训练时的数据集加载和预处理也占用内存。建议内存至少16GB，低于这个数值建议加一条内存条，便宜有效。
Swap也要配好。Linux下设置一个至少32GB的swap文件，虽然性能不如内存，但能防止OOM killer把进程杀掉。我遇到过一种情况：vLLM启动时显存够、内存不够，结果加载到一半进程直接消失，系统日志里全是Out of memory。后来把swap从8GB加到32GB，问题彻底解决。Windows下的虚拟内存同理，建议让系统自动管理，或者手动设置不低于32GB的初始值和最大值。
还有一个容易忽略的点：主板BIOS里的Above 4G Decoding和Resizable BAR选项。如果不开启，某些显卡通过PCIe DMA分配显存时会出现地址空间受限问题，特别是Linux下启动vLLM时报"CUDA error: out of memory"但其实显存并没有占满。我为此重装过系统，最后发现是BIOS设置问题，打开这两个选项后一切正常。
3. LoRA微调实战：用Qwen2.5-1.5B跑通全流程
3.1 模型选型与前置评估
6GB显存能跑的模型范围很小。经验值是：1.5B模型在FP16/BF16下微调，大约需要4-5GB显存；3B模型在AWQ或GPTQ 4bit量化下训练勉强够，但部署时又捉襟见肘。所以我的首选是Qwen2.5-1.5B-Instruct，它的中文能力强、上下文长度可达32K（实际微调时我会截断），模型体积小，非常适合用来跑通流程。如果你有崇拜的7B或8B模型，很遗憾，这个卡跑训练很难，8B模型用4bit量化做推理勉强能挤进6GB，但LoRA微调几乎不可能。
在选最终微调模型之前，先用原始模型做一次推理测试。拿几条你要微调的领域样本喂给它，看看原始输出是什么风格。这一步帮你判断：模型的能力基线如何、需要微调的幅度多大、数据标注的难度是高是低。比如我想让模型学会电商客服口吻，原始Qwen2.5的回答比较正式，客服场景需要更口语化、更多礼貌话术，那微调的目标就很明确。
3.2 数据集整理与格式转换
微调成功的关键百分之六十在数据，而不是参数。6GB小卡上跑不了那么多数据，反而更考验数据质量。推荐准备500到2000条高质量样本，不要贪多。以对话模型为例，一种常用格式是ShareGPT风格：
[ { "conversations": [ { "from": "human", "value": "你好，我想退掉昨天买的外套，可以吗？" }, { "from": "gpt", "value": "您好，当然可以。请问您方便提供订单号吗？我马上帮您查询退换货政策。" } ] } ]如果你用LlamaFactory，它支持alpaca、sharegpt、openchat等格式，在数据集文件里配置好路径就行。数据清洗时注意几个点：去除包含个人信息的内容；保证回答部分真实可靠；每条数据的长度不要超过模型最大序列长度（比如512或1024），长度太长会把显存直接拉爆。我习惯先把所有样本统计一遍长度，超过1024的直接过滤或用脚本截断。
数据质量检查还有一个技巧：抽样20条让原模型跑一遍，观察原模型哪里错了，你标注的数据"纠正"了这个错误没有。如果答案是已经能答对的，那这组数据对训练没有增量。为了省显存和时间，不要喂太多模型已经会的东西。
3.3 LlamaFactory训练的关键参数
直接推荐工具：LlamaFactory。它把LoRA训练封装成了可视化界面，同时也支持命令行和API方式。6GB显存下，我用它的界面版，选择模型路径、数据集、微调方法LoRA，然后进入参数设置。下面是一组我用下来稳定不OOM的参数：
- 模型: Qwen2.5-1.5B-Instruct
- 微调方法: LoRA
- LoRA秩 r: 16
- LoRA缩放系数 alpha: 32
- LoRA作用模块: q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj
- 学习率: 2e-4
- 训练轮数: 3
- 批次大小: 2
- 梯度累积步数: 4
- 序列长度: 512
- 优化器: adamw_torch
- 学习率调度: cosine
- 量化方式: 4bit（如果只够训练，用NF4量化）
为什么是r=16、alpha=32？默认值建议是8和16，但领域任务比较复杂时稍微调大一点有助于拟合。r不能太大，否则LoRA退化成近似全量微调，显存和训练时间都会涨。alpha是缩放系数，一般设为r的两倍，作用是在进行残差连接时平衡原模型和LoRA的权重。我试过r=32、alpha=64，效果提升不明显，显存涨了大概200MB，果断退回16。
批次大小为什么是2而不是4？因为6GB显存如果用4会爆内存。梯度累积4步，相当于实际批次大小为2x4=8，保证了训练的稳定性。千万不要为了追求batch size而让显存爆炸，那样训练中断的损失远远大于参数增益。
3.4 训练过程中的观察点
LoRA训练不是启动之后就等结果，而是要在训练过程中盯住几个数值。第一个是loss曲线，用tensorboard或LlamaFactory自带的图表都行。正常情况下loss应该逐步下降，到第2轮以后趋于平缓。如果loss骤降后马上震荡，说明学习率太高；如果loss下降太慢，可能是数据量不够或r太小。第二个是显存监控，命令行用nvidia-smi -l 1每秒钟刷新一次，观察训练峰值显存占用，如果接近5.8GB就要小心，随时可能OOM。第三个是训练速度，1.5B模型在3060 Laptop上大概每步0.5到0.8秒，不慢，但风扇会拉满，注意散热。
我在一次训练中遇到过loss正常下降，但推理时模型反而变蠢的情况。排查后发现是数据集里混入了大量错误标注，模型学会了一些错误的说话方式。所以建议在训练几个epoch后，临时暂停，保存checkpoint，用那个checkpoint跑几条测试样本，快速目测效果。不要等全部训练完才看结果。
另外，LoRA训练结束后保存的文件包括adapter_config.json和adapter_model.safetensors。前者是LoRA配置，后者是权重文件。这两个文件是"增量补丁"，单独用是没法推理的。接下来要准备合并或转换。
4. 导出与合并：从LoRA训练产物到可用模型
4.1 LoRA文件格式到底是什么
很多新手在这里会卡住。训练完拿到一个几百MB的adapter_model.safetensors，直接载入transformers的AutoModelForCausalLM却报错，因为那不是完整模型。LoRA文件本质是低秩矩阵A和B的权重，每分量的shape都很小，必须与原模型的结构配合才能用。adapter_config.json里记录了基础模型路径、r、alpha、目标模块、甚至保存时的transformers版本，这些信息用于加载时重建LoRA层。
在6GB显卡上做合并时要注意，你不需要重新加载全量模型到显存里跑训练，只需要在合并阶段用CPU也能完成。我的做法是写一个脚本，用transformers库的PeftModel加载基础模型和LoRA权重，然后调用merge_and_unload()得到完整权重，再保存到新目录。合并过程主要吃内存，1.5B模型在FP16下需要3GB左右内存，毫无压力。
4.2 合并后如何选择推理格式
合并后的模型可以直接用FP16的PyTorch格式，用transformers加载。但是6GB显存如果直接用FP16 FP16跑1.5B，模型本身占用3GB，KV Cache还要再占1GB多，剩下留给服务的余量不多。如果想提高并发或降低显存占用，可以转成AWQ或GPTQ量化模型，或者转成GGUF格式用llama.cpp/Ollama跑。但既然我们要上vLLM，最舒服的方式是直接让vLLM加载FP16模型，通过参数限制KV Cache的上限。
不过更推荐的做法是使用AutoAWQ做4bit量化。1.5B模型4bit量化后只有不到1GB，部署时预留显存非常充裕。vLLM原生支持AWQ格式，启动时直接指定模型路径即可。如果你不想额外做量化，也可以用vLLM自带的bitsandbytes或FP8支持，但6GB卡还是AWQ最稳。关于AWQ量化数据，用几百条干净样本做校准，量化后效果通常不会和FP16差太多。
如果你未来要在Ollama或llama.cpp上跑，那就导出成GGUF格式。转换工具是llama.cpp里的convert_hf_to_gguf.py，或者直接用LlamaFactory的导出选项。我一般同时保存FP16和GGUF两个版本，FP16给vLLM，GGUF给Ollama备用，这样同一套微调成果能在不同框架间切换。
5. vLLM部署：把模型跑成API服务
5.1 vLLM安装与基础用法
vLLM的安装要严格对齐版本。官方推荐的安装方式是用pip安装vllm，它会自动拉取triton、flash-attn等依赖。但6GB显卡建议装轻量版，或者使用官方Docker镜像。我在Linux下直接用pip装，命令很简单：
pip install vllm安装完成后，最小启动命令是：
python -m vllm.entrypoints.openai.api_server \ --model /path/to/merged_or_awq_model \ --served-model-name my-loRA-model \ --max-model-len 2048 \ --gpu-memory-utilization 0.85 \ --tensor-parallel-size 1解释一下这几个参数。--model是模型路径，--served-model-name是给API的模型名字，--max-model-len是最大上下文长度，这里设成2048是因为6GB卡跑1.5B模型时，如果长度太大，KV Cache会吃掉全部剩余显存。--gpu-memory-utilization表示vLLM最多使用可用显存的85%，剩下的留给CUDA context和临时tensor。--tensor-parallel-size必须是1，因为只有单卡。
5.2 在6GB显存上如何优化缓存命中率
很多人在用vLLM时会关注缓存命中率，因为当请求的prompt前缀相同时，vLLM可以复用KV Cache，大幅降低延迟。6GB显卡上缓存空间有限，所以命中率优化比大卡更重要。实测下来，有几个参数影响很大：
第一是--block-size，默认是16。这个参数决定KV Cache以多大粒度分配。如果你发现显存碎片化严重，可以试着调成32，有时能提升连续分配效率。第二是--max-num-seqs，即一个batch内最多处理多少个序列。6GB卡建议设成16到32，太小会浪费continuous batching能力，太大容易OOM。第三是--swap-space，默认4GB，这是CPU内存和GPU显存之间的交换空间，如果显存KV Cache不够，vLLM会把旧的KV块换到内存。6GB显存下可以设成2GB。
命中率优化的终极技巧是"前缀稳定"。如果你有固定system prompt，把它放在每条请求的最前面，vLLM的prefix caching就能基于这块公共前缀做缓存。我自己的场景里，固定system prompt占30%的输入，缓存命中率从20%提升到60%以上，响应速度明显变快。这比调任何参数都有效。
5.3 vLLM与Ollama、llama.cpp的事实对比
有的同学一看这么多参数就头大，觉得用Ollama一步到位不好吗？好，但Ollama的灵活度不够。Ollama底层调用llama.cpp，它更倾向于单机单路低延迟推理，在高并发多用户场景下，vLLM的continuous batching优势很明显。你可以想象：Ollama像是私房菜馆，一桌一桌慢慢做；vLLM像是中央厨房，多桌订单合并出餐，总吞吐高，但单桌等待时间不一定更短。
还有SGLang，最近很火，它的RadixAttention甚至能把前缀缓存做到更精细的树状结构，但SGLang对某些模型的支持短期不如vLLM成熟。如果你只是想在6GB卡上跑一个中等并发API服务，vLLM是最均衡的选择。
5.4 调用API与集成测试
vLLM启动后，默认监听8000端口，暴露的是OpenAI兼容API。这意味着你可以直接用openai的Python包来调用：
from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY") resp = client.chat.completions.create( model="my-loRA-model", messages=[{"role": "user", "content": "你好，请用客服语气回答：我想退货"}], temperature=0.3, max_tokens=256 ) print(resp.choices[0].message.content)用API做测试非常快捷。把微调前的模型和微调后的模型都部署一遍，用同一组测试问题做对比，能直观看到效果的改善。我在这一步还会做一次稳定性压测，用curl连续发几十个请求，观察显存变化和响应时间。此时主要盯两个指标：单请求延迟和整体吞吐。1.5B模型在6GB卡上，单请求延迟一般在100ms左右，并发8路时吞吐能达到几十到上百tokens/s，完全够内部使用。
6. 常见问题与排查记录
6.1 显存不足与OOM
6GB显存上运行，OOM是最常见的故障，没有之一。报错通常分为两类：一类是CUDA out of memory，发生在模型加载或训练的前向传播阶段；另一类是vLLM报"GPU block manager"或"could not allocate memory"。
排查思路先看是训练还是推理阶段。训练阶段OOM，优先调小batch_size、梯度累积不变，或者把序列长度降低。推理阶段OOM，优先调低--gpu-memory-utilization，比如从0.85降到0.70，再不行就换量化模型。还有一个容易被忽略的点：加载模型时vLLM会额外分配一些临时空间，如果你用FP16加载1.5B模型，实际占用可能达到3.5GB到4GB，而不是理论上的3GB，这是CUDA context和模型并行配置的开销。
如果做了什么操作都无法消除OOM，建议直接把模型量化到AWQ 4bit。1.5B AWQ模型仅约1GB，加载后显存占用不到1.5GB，这时KV Cache能分到3GB以上，应付一百个普通长度的对话都够。
6.2 vLLM启动慢、加载模型卡住
vLLM的启动过程会做图编译和算子检查，第一次启动可能需要几十秒。如果你看到日志卡在"Capturing the model"这一行不动，属于正常现象，它正在做CUDA graph capture。但在6GB小显存上，有时候会卡很久甚至报错，原因通常是显存被CUDA context占用太多。解决方法是把--gpu-memory-utilization调低一点，或者设置环境变量VLLM_GRAPH_MEMORY_FRACTION=0.3。
另一个启动慢的原因是模型路径不对。如果给了一个不存在的目录或包含中文路径的空格目录，vLLM会反复扫描失败，表现为长时间无响应。建议模型路径用绝对路径，目录中不要有空格。
6.3 Windows下部署的特殊情况
F历了无数坑。Windows原生环境安装vLLM的兼容性问题不少，建议使用WSL2。在WSL2中安装NVIDIA驱动需要Windows侧安装最新的Game Ready或Studio驱动，WSL2会自动透传CUDA。然后在WSL2里面创建conda环境，正常pip安装vllm即可。需要注意，WSL2默认内存不是全部可用的，需要在.wslconfig里设置memory=32GB，否则vLLM可能在加载大模型时因为内存不足被终止。
如果实在不想用WSL2，也可以直接上Llama.cpp的Ollama，Windows下Ollama的支持很完善，但这就不是vLLM的主体环境了。从实用角度，Windows上开发调试用WSL2跑vLLM，生产环境下还是建议装个Ubuntu更好，省掉一层抽象。
6.4 模型效果不好：是微调问题还是部署问题
很多人在微调完成后觉得效果提升不明显，就开始怀疑部署问题。实际上部署环节一般不会改变模型权重，只是加载方式不同。排查的正确顺序是：用Transformers直接加载合并后的模型做一次推理，对比vLLM的输出。如果两者一致，说明部署没问题；如果差别明显，检查是否加载了错误的量化版本或LoRA叠加重复。
如果微调后的模型在部分问题上回答怪异，更可能是LoRA的泛化问题。你可以减少r值、增加数据量、调整学习率。我自己的经验是：训练数据在500条以下时，r=8或16更稳；数据在1000条以上时，r=16到32可以提升表达多样性。另外，数据中如果全是正面样例会模型回答过热，适当混合一些负面样本或通用回复能提升稳定度。
6.5 vLLM的日志分析和性能监控
运行中建议开一个终端持续观察nvidia-smi、vllm的日志输出。vLLM每个请求都会打印token数量和延迟数据。如果发现平均延迟突然升高，可能是KV Cache开始换入换出内存，观察日志中是否有"swap"相关计数，此时调大--swap-space或优化前缀缓存可以改善。
还有一个值得提的是温度参数。部署API时temperature的默认值是1.0，这跟微调时的温度不一致会导致效果"看着不对"，建议在API请求时固定temperature=0.2或0.3。这不算bug，但很多人在集成时踩过这个坑。
最后分享一个小教训：我一开始在6GB卡上同时跑训练和vLLM服务，结果是两个进程抢显存，训练时不时崩溃，服务也卡死。后来强制规定：训练时停掉服务，服务时停掉训练。6GB卡没资格并行多个大任务，老老实实做串行。别看这个道理简单，实际操作中你会发现这比任何优化都见效。
这套流程跑通之后，迭代速度极快。白天微调一个新版本，晚上自动导出并部署，第二天就能在群里发链接让大家试。LoRA带来的副作用是显存友好，vLLM让你把模型变成真正的服务，两者配合下来，一块千元级显卡就能完成以前需要A100才能完成的演示闭环。如果你也想在资源受限的设备上搞点AI应用，别犹豫，照着这条路走下去就行。
