企业官网建设流程全解析

1. 两个决策模型塞进 6GB 显存，这事到底难在哪

先把背景交代清楚。Kev 和 Laya 是我给两个自研决策模型起的代号，不是什么开源大模型，也不是动辄 70B 参数的庞然大物。它们本质上是两个面向特定业务场景的轻量决策网络，一个负责意图路由和任务分发，另一个负责多轮状态跟踪和动作选择。听起来不复杂，但真要把它们同时装进一张 6GB 显存的卡里跑起来，中间踩的坑足够写一篇长文。

为什么是 6GB？因为手头能长期占用的就是一张 6GB 显存的入门级显卡。很多人第一反应是“6GB 现在还能干啥”，确实，跑个 7B 的量化模型都紧巴巴，更别说两个模型同时驻留。但现实场景就是这样，不是每个人都有 A100，大量边缘设备、老旧工作站、甚至一些工控机上的独显就是 6GB 上下。把决策模型部署到这种环境里，是有真实需求的。

这里要先区分一个概念：决策模型和生成式大模型不是一回事。Kev 和 Laya 的参数量分别在 1.2B 和 0.8B 左右，原始权重用 FP16 存储，加起来大概 4GB。理论上 6GB 显存装得下，但理论是理论。实际跑起来，激活值、KV Cache、中间张量、CUDA 上下文、框架自身的显存开销，随便一项都能把预算撑爆。我第一次跑的时候，两个模型加载完还没开始推理，显存就只剩 300MB 了，一进 forward 直接 OOM。

所以这篇记录的核心，不是“怎么训练一个大模型”，而是“怎么在极度受限的显存里，让两个决策模型稳定共存并完成推理”。涉及的关键技术点包括 LoRA 微调、显存分时复用、NaN 损失排查、量化加载、以及推理阶段的显存精细控制。适合谁看？适合手里只有小显存卡、又想把多个模型塞进同一张卡里的同学，也适合正在做 LoRA 微调、被 NaN 折磨过的朋友。

我先把结论性的东西放前面：最终方案是“LoRA 微调 + 4bit 量化加载 + 分时显存复用 + 梯度检查点”，两个模型可以同时驻留，推理峰值显存控制在 5.4GB 左右。但这个过程翻了好几次车，下面一步步拆。

2. 整体方案设计与选型思路

2.1 为什么不用全量微调，而是选 LoRA

一开始我想得很简单：两个模型加起来 2B 参数，全量微调不就行了？结果第一晚就翻车。全量微调时，优化器状态（Adam 的 m 和 v）占的显存是参数量的两倍，再加上梯度，FP16 下每个参数大约需要 6 到 8 字节的额外开销。2B 参数光优化器状态就 12GB 起步，6GB 卡连门都摸不到。

LoRA 的思路是把可训练参数降到极低。它不改原始权重，而是在注意力层的特定矩阵旁边挂两个低秩矩阵 A 和 B，只训练这两个小矩阵。秩 r 取 8 或 16 时，可训练参数量通常只有原模型的 0.1% 到 1%。对 Kev 来说，全量 1.2B 参数，LoRA 之后可训练参数大概 300 万到 800 万，优化器状态瞬间从十几 GB 降到几百 MB。

选 LoRA 还有一个原因：Kev 和 Laya 的基座权重我是要复用的，不同业务场景只需要换不同的 LoRA 适配器。这样一张卡上可以只加载一份基座，挂多个 LoRA，切换时只换适配器权重，显存占用几乎不变。这个特性在后面做分时复用时帮了大忙。

注意：LoRA 的秩不是越大越好。r=8 和 r=64 在决策类任务上的效果差异，我实测下来远没有想象中大，但显存和训练时间差了好几倍。决策模型输出的是离散动作或分类，不是开放式生成，低秩足够捕捉任务相关的偏移。

2.2 量化加载：4bit 是 6GB 卡的生死线

LoRA 解决了训练时的显存问题，但推理时基座权重还是要占显存。FP16 下 Kev 加 Laya 大约 4GB，加上推理时的激活和 KV Cache，6GB 根本不够。所以必须量化。

量化的选择有几个档：8bit、4bit、3bit。8bit 下两个模型约 2GB，听起来够，但推理峰值一上来还是紧张。4bit 下两个模型约 1GB，留出 5GB 给激活和缓存，这才有操作空间。3bit 我试过，精度掉得厉害，决策模型的输出分布直接崩了，动作选择开始出现明显的系统性偏差，所以放弃。

4bit 量化我用的是 NF4（Normal Float 4）格式，配合双重量化。NF4 的核心假设是权重近似正态分布，把量化区间按分位数切分，比均匀量化更能保留信息。双重量化则是把量化常数再量化一次，进一步省显存。实测下来，4bit NF4 的 Kev 在验证集上的准确率比 FP16 只掉了 0.8 个百分点，完全可以接受。

2.3 分时复用：两个模型不能同时 forward

即便量化到 4bit，两个模型同时做 forward 还是会爆。原因是推理时的中间激活值在 batch size 稍大时会迅速膨胀。我的做法是分时复用：Kev 和 Laya 的权重常驻显存，但同一时刻只有一个模型在做 forward，另一个处于“休眠”状态，它的 KV Cache 被换出到内存，需要时再换回来。

这里有个关键点：决策模型和生成模型不同，它的 KV Cache 通常不大，因为决策序列短。Kev 处理的是意图序列，长度一般不超过 64；Laya 处理的是状态序列，长度不超过 128。所以 KV Cache 换入换出的开销可控，用 pinned memory 做异步传输，延迟增加在 15ms 以内，对决策任务来说完全可接受。

2.4 梯度检查点：用时间换空间

训练阶段还开了梯度检查点。原理是不保存所有中间激活，只保存部分检查点，反向传播时重新计算被丢弃的激活。代价是训练速度慢 20% 到 30%，但显存占用能降 40% 以上。对 6GB 卡来说，这个交换是值得的，因为不开启根本训不起来。

3. 核心细节解析与实操要点

3.1 LoRA 配置参数怎么定

LoRA 的几个核心参数：秩 r、alpha、dropout、target_modules。我踩过的坑主要在这几个地方。

秩 r 我最终定的是 16。试过 r=8，Kev 在意图路由上的 F1 掉了 2 个点；r=32 时效果提升不到 0.5 个点，但显存多了 200MB。16 是性价比拐点。

alpha 一般设成 r 的两倍，也就是 32。alpha 控制 LoRA 权重的缩放，太小了适配器学不动，太大了训练不稳定。我试过 alpha=16，loss 下降很慢；alpha=64，前期 loss 震荡明显。

dropout 设 0.05。决策模型容易过拟合，尤其是样本量不大的场景，一点 dropout 能明显改善泛化。

target_modules 是最容易出错的地方。不同模型架构的注意力层命名不一样。Kev 用的是类似 LLaMA 的结构，注意力层叫 q_proj、k_proj、v_proj、o_proj；Laya 用的是另一套命名。我一开始照搬了网上的配置，结果 LoRA 挂到了错误的层上，训练 loss 几乎不降。后来打印了模型的所有模块名，才找到正确的 target。

# Kev 的 LoRA 配置示例 from peft import LoraConfig, get_peft_model kev_lora_config = LoraConfig( r=16, lora_alpha=32, lora_dropout=0.05, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], bias="none", task_type="CAUSAL_LM" ) kev_model = get_peft_model(kev_base_model, kev_lora_config) kev_model.print_trainable_parameters() # 输出类似：trainable params: 4,194,304 || all params: 1,200,000,000 || trainable%: 0.35

提示：target_modules 一定要用model.named_modules()打印出来确认，不要凭记忆或照搬。我在这上面浪费了整整两个小时，loss 不降的时候还以为是学习率的问题。

3.2 4bit 量化加载的正确姿势

量化加载用 bitsandbytes 的BitsAndBytesConfig。关键参数是load_in_4bit=True、bnb_4bit_quant_type="nf4"、bnb_4bit_use_double_quant=True、bnb_4bit_compute_dtype=torch.float16。

compute_dtype 设成 float16 而不是 bfloat16，是因为 6GB 卡对应的 GPU 架构对 bfloat16 的支持不一定完整，float16 更稳。但 float16 有个隐患：数值范围小，容易溢出成 inf 或 NaN。这就是后面 NaN 翻车的伏笔之一。

import torch from transformers import BitsAndBytesConfig bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_use_double_quant=True, bnb_4bit_compute_dtype=torch.float16 ) kev_model = AutoModelForCausalLM.from_pretrained( "kev_base_path", quantization_config=bnb_config, device_map={"": 0}, trust_remote_code=True )

device_map 这里我指定了{"": 0}，强制全部放在 GPU 0 上。不要用auto，因为 auto 在多模型场景下可能把部分层放到 CPU，推理时来回拷贝反而更慢，而且显存计算会变得不可预测。

3.3 分时复用的实现细节

分时复用的核心是控制两个模型的 forward 不同时发生。我用了一个简单的调度器，维护一个显存锁。Kev 推理时，Laya 的 KV Cache 被移到 CPU 的 pinned memory；Laya 推理时反过来。

class ModelScheduler: def __init__(self, model_a, model_b): self.model_a = model_a self.model_b = model_b self.active = None self.cache_a = None self.cache_b = None def switch_to(self, target): if self.active == target: return if self.active == "a": self.cache_a = self.model_a.move_cache_to_cpu() elif self.active == "b": self.cache_b = self.model_b.move_cache_to_cpu() if target == "a": self.model_a.move_cache_to_gpu(self.cache_a) else: self.model_b.move_cache_to_gpu(self.cache_b) self.active = target torch.cuda.empty_cache()

torch.cuda.empty_cache()这行很关键。PyTorch 的缓存分配器不会主动把不用的显存还给系统，换出 KV Cache 后如果不手动清缓存，显存碎片会越积越多，跑一段时间后还是会 OOM。

注意：empty_cache 有开销，不要每次 forward 都调。我的做法是只在模型切换时调一次，同一个模型连续推理时不调。

3.4 NaN 问题的排查路径

NaN 是这次翻车最狠的一次。训练到第 300 步左右，loss 突然变成 nan，之后所有参数都变成 nan，模型彻底废掉。排查花了整整一个晚上。

第一步，确认 NaN 出现的位置。我在 loss 计算前加了 hook，打印每一层输出的 min、max、mean。发现 NaN 最早出现在 LoRA 的 B 矩阵输出上，说明是梯度爆炸导致的。

第二步，查梯度。开了torch.autograd.set_detect_anomaly(True)，定位到某一步的梯度范数超过了 1e4。正常梯度范数应该在 1 以下。

第三步，找原因。最终定位到两个问题叠加：一是学习率设成了 2e-4，对 LoRA 来说偏大；二是 float16 的 compute_dtype 在累加时溢出。LoRA 的 B 矩阵初始化为零，A 矩阵随机初始化，前期输出很小，但梯度更新后 B 快速增长，float16 下很容易溢出。

解决方案是三条一起上：学习率降到 5e-5，加梯度裁剪max_grad_norm=0.3，compute_dtype 改成 bfloat16（如果硬件支持）或者保持 float16 但在 loss 计算时用 float32 累加。

# 训练参数修正 training_args = TrainingArguments( learning_rate=5e-5, max_grad_norm=0.3, fp16=True, fp16_opt_level="O2", per_device_train_batch_size=2, gradient_accumulation_steps=8, gradient_checkpointing=True, logging_steps=10, save_steps=200, warmup_ratio=0.03, )

fp16_opt_level="O2"是 Apex 的混合精度优化级别，它会把部分运算保持在 float32，减少溢出风险。如果不用 Apex，用 PyTorch 原生的torch.cuda.amp，则要确保 loss 在 float32 下计算。

4. 完整实操流程与关键环节

4.1 环境准备与依赖版本锁定

环境这块我踩的坑是版本不兼容。bitsandbytes、peft、transformers、torch 这四个库的版本必须匹配，否则量化加载会报奇怪的错，或者 LoRA 挂载后 forward 结果不对。

我最终锁定的版本组合：

安装顺序也有讲究：先装 torch，再装 bitsandbytes，最后装 transformers 和 peft。反过来装有时候 bitsandbytes 会找不到 CUDA 运行时。

pip install torch==2.1.2+cu118 --index-url https://download.pytorch.org/whl/cu118 pip install bitsandbytes==0.41.3 pip install transformers==4.36.2 peft==0.7.1 accelerate==0.25.0

提示：如果你的卡比较老，CUDA 版本要对应调整。6GB 卡常见的是 GTX 1060、RTX 2060、RTX 3060 笔记本版等，这些卡对 CUDA 11.8 的支持都没问题。

4.2 数据准备与格式对齐

Kev 和 Laya 的训练数据格式不同。Kev 是意图分类加槽位填充，输入是用户 query，输出是意图标签和槽位序列。Laya 是状态跟踪，输入是对话历史和当前状态，输出是更新后的状态。

数据格式我统一成了 JSONL，每行一个样本。Kev 的样本长这样：

{"query": "帮我查一下明天北京的天气", "intent": "weather_query", "slots": {"city": "北京", "date": "明天"}}

Laya 的样本长这样：

{"history": ["我想订机票", "去哪里", "北京"], "state": {"intent": "book_flight", "destination": "北京", "departure": null}}

数据量方面，Kev 用了 8000 条，Laya 用了 5000 条。决策模型不需要海量数据，但需要覆盖足够多的边界情况。我特意构造了 15% 的负样本和困难样本，比如意图模糊的 query、状态冲突的对话，这些样本对模型鲁棒性提升很明显。

4.3 训练过程与显存监控

训练时我开了一个显存监控脚本，每 10 步记录一次torch.cuda.memory_allocated()和torch.cuda.max_memory_allocated()。这样能清楚看到显存峰值出现在哪个阶段。

实测下来，Kev 训练时峰值显存 4.8GB，Laya 训练时峰值 4.2GB。两个模型不能同时训练，必须串行。我先训 Kev，训完保存 LoRA 适配器，释放模型，再训 Laya。

训练超参：

Laya 的学习率更低，因为状态跟踪任务对参数扰动更敏感，学习率大了容易震荡。epochs 更多是因为 Laya 的数据量少，需要多训几轮。

训练日志里我重点关注三个指标：loss 是否平稳下降、梯度范数是否在合理范围、验证集准确率是否提升。如果 loss 出现尖刺但没到 nan，先别慌，看看梯度范数，如果梯度范数正常，可能只是某个困难样本导致的，继续观察。如果梯度范数突然飙升，立刻暂停，检查数据里有没有异常样本。

4.4 推理部署与显存实测

推理部署是最终考验。两个模型都加载 4bit 量化权重，LoRA 适配器单独加载。加载顺序是先 Kev 后 Laya，每加载一个就torch.cuda.empty_cache()一次。

实测显存占用：

5.4GB 是最终稳定运行的峰值，留了 0.6GB 余量。这个余量不能省，因为 CUDA 内核启动、内存碎片、以及偶尔的临时张量都需要空间。我试过把余量压到 0.2GB，跑一段时间后必 OOM。

推理延迟方面，Kev 单次 forward 约 18ms，Laya 约 22ms，模型切换开销约 15ms。对于决策任务来说，这个延迟完全够用，因为决策本身不是高频操作，通常几百毫秒一次。

5. 常见问题与排查技巧实录

5.1 训练 loss 不下降的排查顺序

loss 不降是最常见的问题，排查要按顺序来，不要跳步。

第一，确认 LoRA 挂载的层对不对。打印model.named_modules()，看 target_modules 里的名字是否真的存在。如果名字不存在，peft 会静默跳过，不报错，但 LoRA 根本没挂上。

第二，确认可训练参数数量。print_trainable_parameters()如果显示 trainable% 是 0，说明 LoRA 没生效。

第三，确认数据格式。输入和标签是否对齐，padding 是否正确，attention_mask 有没有传。我有一次忘了传 attention_mask，模型把 padding 也当成有效 token，loss 一直很高。

第四，确认学习率。LoRA 的学习率通常比全量微调大，但也不能太大。1e-4 到 5e-5 是常见范围。太小了 loss 下降极慢，看起来像不降。

第五，确认 loss 计算方式。决策模型的 loss 和生成模型不同，如果是分类任务，要用交叉熵；如果是序列标注，要注意 ignore_index 的设置。

5.2 NaN 问题的速查表

我遇到的是第一种和第二种叠加。梯度裁剪加到 0.3 之后，梯度范数稳定在 0.5 以下，再没出现过 nan。

提示：torch.autograd.set_detect_anomaly(True)会显著拖慢训练速度，只在排查时开，定位到问题后立刻关掉。

5.3 显存 OOM 的应急处理

OOM 的时候不要急着重启，先看报错信息里的显存分配情况。PyTorch 的 OOM 报错会告诉你当前分配了多少、峰值多少、还有多少可用。

应急处理有几个手段：一是减小 batch size，这是最直接的；二是开梯度检查点；三是清理缓存torch.cuda.empty_cache()；四是把部分层放到 CPU，用device_map控制。

但这些都是治标。治本的方法是算清楚显存预算：模型权重 + 优化器状态 + 梯度 + 激活 + KV Cache + 框架开销。每一项都要留余量，不能卡着上限算。

5.4 LoRA 适配器切换的坑

多 LoRA 切换时，peft 的set_adapter方法有时候不会自动清理旧的适配器权重，导致显存缓慢增长。我的做法是切换前先model.disable_adapter()，再model.set_adapter(new_adapter)，最后model.enable_adapter()。这样能确保旧适配器的计算图被释放。

另外，LoRA 适配器保存时只保存适配器权重，不保存基座。加载时先加载基座，再用PeftModel.from_pretrained加载适配器。这个顺序不能反。

6. 几个容易被忽略的实操心得

第一个心得：量化加载后不要直接model.half()。4bit 量化的模型权重已经是特殊格式，再调 half 会破坏量化结构，导致输出乱码。compute_dtype 在 BitsAndBytesConfig 里设好就行。

第二个心得：决策模型的评估不能只看 loss。loss 低不代表决策对。我加了混淆矩阵和每个类别的 F1，发现某个意图类别的召回率特别低，回头查数据才发现那个类别的样本只有 30 条，严重不足。补了 500 条之后，召回率从 0.6 涨到 0.89。

第三个心得：6GB 卡上跑两个模型，散热是个问题。连续跑几个小时之后，显卡降频，推理延迟从 18ms 涨到 35ms。后来加了个小风扇对着吹，延迟稳定在 20ms 左右。这个不是软件问题，但确实影响体验。

第四个心得：保存训练 checkpoint 时，只保存 LoRA 适配器，不要保存整个模型。整个模型 4bit 也有 1GB 多，保存慢还占磁盘。LoRA 适配器通常只有几十 MB，保存快，加载也快。

第五个心得：推理时用torch.inference_mode()而不是torch.no_grad()。inference_mode 更彻底，会禁用版本计数和自动微分相关的所有开销，显存占用和速度都更好。实测下来，inference_mode 比 no_grad 省大约 5% 的显存，速度快 3% 到 5%。

这套方案跑通之后，Kev 和 Laya 在 6GB 卡上稳定运行了两个月，每天处理几千次决策请求，没再出现过 OOM 或 NaN。中间唯一一次异常是显卡驱动升级后 bitsandbytes 找不到 CUDA，回滚驱动就好了。如果你也在小显存卡上折腾多模型部署，希望这些翻车记录能帮你少走点弯路。