作为一个已经把前面五篇都跟下来的读者，你大概率已经完成了 Mistral 系列的基础认知搭建——跑通了 API 调用、试过 Prompt 工程、折腾过 RAG 检索增强，甚至可能在本地环境里部署过量化版的模型。到了第六篇，如果还停留在“调用别人的接口”这个层面，那就有点原地踏步了。这篇指南要聊的是真正让 Mistral 系列模型“为你所用”的那个分水岭：微调。而且不是泛泛讲概念，是带着你把数据集准备、训练脚本、显存控制、评估部署这一整条链路走通，让你看完就有底气在自己的业务数据上动手。
微调这事，看起来是“用更多数据再训练一下模型”，但实际操作中到处是坑。有人用几万条数据训出了脱胎换骨的效果，也有人照搬别人的参数在自己的场景上训崩了。这里面的差别不在于你有多强的算法背景，而在于你是否理解每一步操作背后的为什么——为什么数据要整理成这个格式，为什么学习率要设置成这个量级，为什么同样的 LoRA 配置在不同基座模型上表现天差地别。这篇文章就是把这些“为什么”逐个拆开，再配上可以直接复用的代码和踩坑记录，让不管你是刚入门的小白，还是有点经验但没完整做过微调的同学，都能顺顺利利地把 Mistral 模型调成自己想要的样子。
1. 微调前的规划：先想清楚三个问题
1.1 你真的需要微调吗
我见过太多人一上来就准备数据要微调，结果训完之后效果还不如直接用 Prompt 写得好。微调不是万能的，它解决的是“模型能力不够”的问题，而不是“你不会写 Prompt”的问题。在动手之前，先用下面几条标准判断一下：
- 如果只是想让模型输出格式更规范，比如固定 JSON 结构、固定回复模板，那写一套带示例的 Prompt 往往就够用了。Mistral 7B Instruct 本身对指令的遵循能力很强，Few-shot 示例可以解决八成这类需求。
- 如果是想让模型学会某种专有知识，比如公司内部的业务规则、特定领域的术语体系，而且这些知识很难在 Prompt 里展开写清楚，这时候微调才有意义。
- 如果是要模仿某种特定的风格或语气，比如客服话术、特定的文案风格，微调整合进模型的效果远比在 Prompt 里反复强调来得稳定。
还有一个实际考量是成本。微调虽然比全量预训练便宜得多，但仍然需要 GPU 资源和时间投入。如果你用 LoRA 在单张 24G 显存的卡上微调 Mistral 7B，一次训练跑几小时到一天是常有的事，数据量大的话更久。如果只是临时试个想法，先用 Prompt 顶着，等验证了方向真的可行，再投入微调不迟。
1.2 明确微调目标与任务形态
决定了要微调之后，接下来要想清楚一个看起来简单但其实很要命的问题：你要微调后的模型帮你完成什么任务。这直接决定了数据集怎么构造、格式怎么选、训练怎么评。
常见的微调目标可以分成三类。第一类是通用指令遵循，就是让模型在各种问答场景下更听话，这类通常用通用指令数据微调，数据集里什么领域都有。第二类是垂直领域问答，比如医疗、法律、金融或者你公司的产品知识库，数据集里绝大部分是与该领域相关的问答对，这类微调效果最明显，也最好评估。第三类是任务格式转换，比如把用户问题转成 SQL、转成 API 调用参数、把口语转成书面语，这类数据集通常是“输入-输出”对，格式非常统一。
建议在实际动手写数据之前，先用文字把自己的任务定义写出来，包括输入是什么、期望输出是什么、边界在哪里。不要觉得这一步多余，它相当于你给自己的微调项目定了一个验收标准。后面选择和构造数据时，你会发现围绕任务定义去收集数据，效率和准确率都会高很多。
1.3 硬件与数据层面的硬指标
在动笔写任何代码之前，先评估一下手上有什么资源，因为这会直接限制你的技术选型。
显存是最核心的约束条件。Mistral 7B 的模型权重以 FP16 存储大约是 14G，加载到显存里做 LoRA 微调，优化器状态和梯度还需要额外空间，所以单张 16G 显存是 LoRA 微调 7B 模型的基本门槛。如果你的卡只有 8G 显存，也别急着放弃，可以考虑用 QLoRA（量化版 LoRA），把基座模型量化成 4-bit 加载，可以大幅压缩显存占用，8G 卡跑 7B 微调虽然吃力但可行。
数据层面也有硬指标，最重要的一条是数据量。对于垂直领域问答，我个人的经验是 500 条高质量数据起步，1000-3000 条能看出比较明显的能力提升，超过 5000 条边际收益就开始递减了。这不像预训练需要几十亿 token，指令微调的核心是“示范”，少量多样化的高质量示例，比海量低质量数据有用得多。下一节我会详细讲数据怎么做，这里先记住一句话：宁可只有 1000 条精心清洗过的数据，不要 10000 条从网上随便扒来的脏数据。
2. 数据集建设：决定微调上限的那一半
2.1 数据格式选型：Alpaca、ShareGPT 还是自定义
微调数据的格式选择，直接关系到后面能不能用主流框架顺利开训。目前社区里最常见的有两种格式。
第一种是 Alpaca 格式，一条数据包含 instruction、input 和 output 三个字段。其中 instruction 是指令文本，input 是额外的上下文输入（可以为空），output 是期望的标准回答。这种格式适合处理“指令到回答”的单轮对话，结构简单清晰，几乎被所有微调框架原生支持。
第二种是 ShareGPT 格式，数据是由多轮对话组成的，每一轮都标记了角色（human 或 gpt），适合微调多轮对话能力，比如做客服机器人这类场景。结构上比 Alpaca 复杂，但在 LLaMA-Factory、transformers 的 trainer 中都有对应的处理方式。
选哪种格式不是随机的，核心逻辑是看你的应用场景是否需要多轮上下文。我做垂直问答时通常用 Alpaca 格式，因为单轮问答已能满足需求；做对话式产品时则换成 ShareGPT 格式。这里还有个比较容易被忽略的点：数据格式会影响基座模型在微调时见过的上下文结构，你用 Alpaca 格式训出来的模型，天然更适应“指令-回答”的交互方式，而你用 ShareGPT 格式训练，模型才会对多轮对话的拼接方式更敏感。所以不要混用格式，一整个数据集尽量保持统一。
2.2 数据清洗的三个关键动作
数据清洗是微调里最花时间也最值得花时间的环节。再好的模型，喂进去的是垃圾，出来的也只能是垃圾。我在清洗数据时通常会做三件事。
第一件是去重。很多从网上收集的数据，经过不同来源转载，会有大量的重复内容。重复数据会在大训练中占据过多权重，让模型对某些特定的表述方式产生过拟合。去重可以用简单的文本相似度匹配，也可以用一个基于 MinHash 的去重脚本，把相似度超过 0.8 的数据剔除掉。
第二件是标记清理。从网页抓取的数据里经常混入 HTML 标签、markdown 语法残留、多余的空白符和乱码。我写过一个简单的清洗流程：先用正则去掉 HTML 标签，然后压缩多余空白，再剔除包含乱码字符的行。这个流程看似简单，但对数据质量的提升立竿见影。
第三件是质量过滤。对于垂直领域的数据，这一步尤其重要。我会对照任务定义一条条检查，把答非所问的、信息不完整的、明显过时的数据剔除掉。有些人会用规则批量过滤长度过短或过长的数据，比如把小于 20 个字的 output 丢弃，因为太短的输出往往信息量不足；把超过模型最大长度的数据截断，避免训练时被截断导致上下文不完整。
2.3 混合数据比例的经验之谈
如果你的微调数据集里只有垂直领域数据，模型很可能会出现“灾难性遗忘”——它会慢慢忘记通用对话能力和指令遵循能力，导致模型变得非常死板。为了避免这个问题，业界共识的做法是在垂直数据里掺入一部分通用数据。
我常用的比例是 7:3 或者 8:2，即七到八成的垂直领域任务数据，配两到三成的通用指令数据。通用数据可以直接从社区找到，比如 Alpaca 的清洗版、OpenOrca 的子集等。这样混着训，模型既学到了你领域的知识，又保持了对通用指令的响应能力。
还有一个容易忽略的小细节：在训练时，垂直领域数据应该在整体数据集中均匀分布，而不是全部堆在前面。如果你的训练脚本是随机打乱（shuffle）数据的，那没什么问题；但如果你的数据管线没有洗牌，就一定要手动打乱一下。否则模型在前期学了一堆垂直知识，后期又学了通用知识，参数更新的顺序偏差会对微调效果有负面影响。
3. 微调方案选型：LoRA、QLoRA 还是全参
3.1 三种方案的核心差异
微调一个 7B 级别的模型，摆在面前的无非三条路：全参微调（Full Fine-tuning）、LoRA 和 QLoRA。三者之间的差异，主要体现在显存占用、训练速度、效果上限和操作复杂度上。
全参微调就是所有模型参数都参与更新，效果上限最高，但对硬件的要求也最苛刻。7B 模型全参微调，单卡 80G 显存只能说是勉强够用，更多时候需要多卡并行。而且全参微调得到的完整模型文件是 14G 级别，存储和分发都比较麻烦。除非你有充足的多卡资源和明确的高精度追求，否则我不建议入门阶段碰全参。
LoRA 的思路可以这样理解：原始模型的参数在训练时冻结不动，在旁边额外加一小部分低秩矩阵，只训练这一小部分。7B 模型做 LoRA，可训练参数量通常只有几千万，显存占用就能从 60-80G 降到 16-24G，一张消费级显卡就能跑。最终产物是一个几百兆的 LoRA 适配器文件，可以随时加载到任何基座模型上，非常灵活。
QLoRA 是 LoRA 的一个变体，把 LoRA 和基座模型量化结合起来。基座模型以 4-bit 量化形式加载，LoRA 适配器用标准精度训练。这样显存占用可以进一步压缩到 10G 以下，8G 显存的小卡也能微调 7B 模型。代价是训练速度会慢一些，量化反量化带来的计算开销增加了。
3.2 LoRA 关键参数应该怎么设
LoRA 的配置里，最核心的几个参数是 rank（秩）、alpha 和 dropout。很多新手直接照抄别人的配置，结果在自己的任务上效果不好，核心原因就是没理解这几个参数的含义。
rank 决定了低秩矩阵的维度，你可以简单地把 rank 理解为“微调的容量”——rank 越大，可学习的参数越多，模型对新任务的适应能力越强，但相应地显存占用和过拟合风险也会增加。我常用的经验是：rank 从 8 到 64 之间选择，基准任务用 16，复杂任务用 32，超过 64 之后收益就很有限了。
alpha 是缩放系数，它控制着 LoRA 更新的权重比例。实际配置时 alpha 通常设置为 rank 的两倍，比如 rank=16 时 alpha=32。这不是拍脑袋定的，而是社区经过大量实验得出的经验值。alphalpha 过小会导致微调效果不明显，过大会让微调后的模型偏离基座模型太远，行为不可控。
dropout 则是为了防止过拟合。一般设置在 0.05 到 0.1 之间。当你的训练数据量比较小的时候，把 dropout 调高一点能起到缓释过拟合的作用。但也不要太高，太高会导致训练不稳定。
3.3 训练超参数的经验配置
训练超参数就像做菜时的火候，每个人的经验和口味不同，但总有一些公认的安全区间。结合我在 Mistral 7B 上的微调经验，推荐下面这组初始配置。
学习率是最重要的超参数，没有之一。LoRA 微调一般用 1e-4 到 2e-4 这个区间比较稳。太大了模型容易震荡发散，太小了训练半天看不清效果。如果你用的是 QLoRA，因为量化误差的存在，建议把学习率下调到 1e-4 左右，会稳定很多。
batch size 和梯度累积需要结合显存来调整。理想情况下总批次大小（global batch size）在 32 到 64 之间。如果你的显存只够 batch size=2，那就通过梯度累积把总批次补到 32，也就是累积 16 步再更新一次参数。
训练轮数（epoch）和样本数量相关。对于 1000-3000 条数据，2 到 3 个 epoch 通常足够。跑太多轮会过拟合，一个典型的判断依据是看训练损失值——如果在验证集上损失在回升而训练集损失还一直降，那基本就是过拟合了。这时候停止训练或者减小学习率都对。
序列长度（max length）也是一个值得留意的参数，它决定了模型每次能看到多少上下文。垂直领域问答如果输入比较长，设置成 2048 通常够用；对话类场景可以根据实际历史轮次长度适当调大，但代价是训练速度和显存占用都会上升。Mistral 7B 的原生上下文窗口是 8192，如果数据集里确实有超长文本要处理，5120 甚至 8192 也不是不能用，前提是你的显存扛得住。
3.4 基座模型：Base 还是 Instruct
这是很多人在微调前会忽视的一个问题。Mistral 官方提供了两类基座模型：Mistral-7B-v0.1（或者 v0.3 Base 版）和对应的 Instruct 版本。为什么选哪个重要？因为这两个模型的训练方式和能力分布差异很大。
Base 模型只做了预训练，没有经过指令微调，所以它很擅长续写文本、补全上下文，但不擅长遵循人类指令。而 Instruct 版是在 Base 基础上做了监督微调和偏好对齐，更懂“按要求回答”。如果你微调的最终目的是做问答、客服、工具调用这类指令型任务，直接基于 Instruct 版微调是默认选项——因为在已经对齐的模型上加一层领域适配，效果往往比从 Base 开始训更稳定。
那什么情况下该用 Base 呢？如果你的任务是纯文本生成、内容补全、风格模仿，而不需要模型“理解指令”，那 Base 版反而更适合，因为它的生成风格更自由，不受 Instruct 对齐的束缚。有一个技巧：在不确定选哪个的时候，可以把少量领域数据分别在这两个模型上各自快速跑一个短训练，然后用同样的验证集对比输出质量。实测下来，这个对比能帮你快速排除一个选项。
4. 训练实操与踩坑记录
4.1 环境准备与依赖安装
实际动手训练前，先把环境搭好。我建议用 conda 建一个独立的 Python 环境，Python 版本选 3.10 比 3.11 稳，某些依赖对 3.11 的兼容还有坑。
基础依赖是 PyTorch、transformers、datasets、peft、accelerate、trl 这套组合。特别注意 transformers 和 peft 的版本要配套，不然会出现一些莫名其妙的错误。我自己常用的版本组合是 transformers 4.38+，peft 0.9+，trl 0.7+。安装命令如下：
conda create -n mistral-finetune python=3.10 -y conda activate mistral-finetune pip install torch==2.1.2 --index-url https://download.pytorch.org/whl/cu121 pip install transformers==4.38.2 datasets peft==0.9.0 trl==0.7.11 accelerate如果你用的是 QLoRA，还需要安装 bitsandbytes 库，这个库负责 4-bit 量化加载。注意 bitsandbytes 在 Windows 上会有兼容性问题，Windows 用户建议直接用 WSL 环境，或者干脆上 Linux 虚拟机，省得折腾一堆编译错误。
4.2 完整训练流程代码
为了不让你停留在“看懂了但不知道怎么动手”的状态，我整理了一份可以直接跑通的 LoRA 微调脚本，基于 Hugging Face 生态的 trl 库。这份脚本面向单卡 24G 显存环境，数据是 Alpaca 格式的 JSON 文件。
import json from datasets import Dataset from transformers import ( AutoTokenizer, AutoModelForCausalLM, TrainingArguments, BitsAndBytesConfig ) from peft import LoraConfig, get_peft_model from trl import SFTTrainer # 1. 读取数据 with open("train_data.json", "r", encoding="utf-8") as f: raw_data = json.load(f) # Alpaca 格式转成模型输入 def format_alpaca(example): if example["input"]: prompt = f"### Instruction:\n{example['instruction']}\n\n### Input:\n{example['input']}\n\n### Response:\n" else: prompt = f"### Instruction:\n{example['instruction']}\n\n### Response:\n" return {"text": prompt + example["output"]} train_dataset = Dataset.from_list([format_alpaca(x) for x in raw_data]) # 2. 加载 tokenizer 和模型 model_name = "mistralai/Mistral-7B-Instruct-v0.2" tokenizer = AutoTokenizer.from_pretrained(model_name) tokenizer.pad_token = tokenizer.eos_token # Mistral 没有 pad token，需要手动指定 # LoRA 微调不需要量化，直接用 fp16 加载 model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype=torch.float16, device_map="auto", use_cache=False ) # 3. LoRA 配置 lora_config = LoraConfig( r=16, lora_alpha=32, target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM" ) model = get_peft_model(model, lora_config) # 4. 训练参数 training_args = TrainingArguments( output_dir="./mistral-lora-output", per_device_train_batch_size=4, gradient_accumulation_steps=8, # 等效 total batch = 32 learning_rate=2e-4, num_train_epochs=3, logging_steps=10, save_strategy="epoch", fp16=True, report_to="none", ) # 5. Trainer trainer = SFTTrainer( model=model, args=training_args, train_dataset=train_dataset, dataset_text_field="text", max_seq_length=2048, tokenizer=tokenizer, ) trainer.train()这份脚本可以直接复制运行。有几个地方特别容易出问题：Mistral 的 tokenizer 没有 pad_token，需要手动设置成 eos_token，否则会在 batch 拼数据时报错；target_modules 如果漏掉了 gate_proj 和 up_proj 这些 MLP 层的投影模块，LoRA 的效果会打折扣，Mistral 7B 不能只用自注意力模块，要把 MLP 也纳入 LoRA，不然训练完基本没感觉。
4.3 显存不够时的优化手段
如果你的单卡显存是 16G，跑上面这份 24G 环境的脚本可能会爆显存。这时候有几个手段可以组合使用。
首先是降 batch size，把 per_device_train_batch_size 从 4 降到 2，同时把梯度累积从 8 提高到 16，保持总批次不变。这样收敛效果几乎不受影响。
其次可以打开 gradient checkpointing。这个功能通过重新计算前向激活值来省显存，代价是训练速度变慢 20%-30%。在 TrainingArguments 里加一行gradient_checkpointing=True就行。配合model.config.use_cache=False，可以省下不少显存。
如果 16G 还是不够，就需要上 QLoRA。它和 LoRA 的区别只在于加载基座模型时用量化配置。把第 2 步改成下面的写法：
bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_compute_dtype=torch.float16, bnb_4bit_use_double_quant=True, ) model = AutoModelForCausalLM.from_pretrained( model_name, quantization_config=bnb_config, torch_dtype=torch.float16, device_map="auto", use_cache=False )注意 QLoRA 模式下学习率最好降到 1e-4，训练轮数可以适当增加到 3 到 4 轮，因为量化会损失一些表达能力，需要更多步数来拟合。
4.4 训练日志怎么看
训练跑起来之后，不能干等着看进度条。你要学会从日志里判断训练是否正常。
第一眼看 loss 曲线。正常情况是训练 loss 在前几百步内快速下降，然后趋于平缓。如果 loss 不降反升，或者出现 NaN，说明学习率太高或者数据里有异常值。第二眼看梯度范数，如果训练过程很平滑且 loss 下降正常，一般不需要过度关注；但如果你发现 loss 出现剧烈抖动，可以看看是否因为梯度累积导致更新不稳定。
另外一个实用的小技巧是中途手动做一次验证。训练完第一个 epoch 之后，暂停训练，拿几条验证集数据让模型生成，看一眼输出质量。这一步的价值在于它能尽早暴露数据问题。我踩过一次坑：训练数据里有一些 instruction 字段为空的数据，效果就是训练到第 2 轮时模型输出明显变差，后来排查才发现是空数据干扰了指令理解。中途验证能提前发现问题，避免白跑几小时。
4.5 高频报错与解决方案
整理几个我在微调 Mistral 系列时遇到过的高频报错，以及对应的解决思路。
第一类是 “RuntimeError: element 0 of tensors does not require grad and does not have a grad_fn”。这个报错在冻结基座模型参数、只训练 LoRA 适配器时会出现。解决方法是检查model是否成功包了get_peft_model，以及输入 tensor 是否被设置在需要梯度的模式下。
第二类是 “ValueError: pad_token must be set in tokenizer”。这个大都是因为 Mistral tokenizer 本身没有 padding token。解决方式就是前面代码里那句tokenizer.pad_token = tokenizer.eos_token，如果希望更安全，可以用tokenizer.add_special_tokens({'pad_token': '[PAD]'})来新增一个专用 token。
第三类是 “CUDA out of memory”。这个应该是最常见的问题。前面提到的方法都有用，先减 batch size 或打开 gradient checkpointing，再考虑上 QLoRA。如果还不行，就把 max_seq_length 从 2048 降到 1024，短文本任务足够用。
第四类是 “KeyError: 'text'” 或类似的数据字段错误。检查你的数据是否被正确映射成了包含 text 字段的格式，特别是直接拿原始 JSON 列表传给 trainer 时会默认按列名读取。
5. 评估、导出与轻量化部署
5.1 微调效果评估的实操方法
训练完不等于完事，你还得回答一个关键问题：微调后的模型到底变强了多少。评估的方法太随意，会对后续优化方向的判断产生误导。
我在项目里常用的评估方式是分三层。第一层是“定性人工抽检”，随机抽 20-50 条验证集样本，跑推理，肉眼对比微调前后的回答质量。重点看内容是否准确、格式是否符合要求、语气是否一致。这个层面的问题往往一眼就能看出来。
第二层是“定量指标计算”，根据任务类型选指标。如果是生成任务，可以用 BLEU、ROUGE 这类词汇重合度指标；如果是分类或抽取任务，可以直接算准确率和 F1。但这里要留个心眼：生成类任务的自动指标和人的主观感受相关性有限，指标只能作为参考，不能替代人工审查。
第三层是对比测试。可以用原始基座模型、微调模型、以及你可能用过的 Prompt 方案放在同一个测试集上跑一遍，输出结果放在一起横向对比。因为一个模型在同一个问题上的输出有一定的随机性，建议每个模型跑 2-3 次，看整体稳定性。这个对比表格能很直观地告诉你：微调是否真的带来提升，值得投入的进一步成本有多少。
5.2 导出、合并与模型量化
训练完成后，你的产物是一个 LoRA 适配器文件夹，里面是 adapter_config.json 和几个 .safetensors 文件。它不能独立运行，必须搭配原始基座模型使用。
如果你希望得到一个独立的模型文件，需要做一步模型合并。用 peft 库的merge_and_unload方法可以把 LoRA 适配器融合进基座模型，得到一个完整的 merged 模型。这个过程相当于把微调学到的东西写回原始模型权重，所以输出文件就是 7B 完整模型，大小在 14G 左右。
如果考虑到部署的存储和推理速度，建议把合并后的模型做一下量化。常用的量化工具包括 llama.cpp 社区提供的 GGUF 量化方案，以及 GPTQ 和 AWQ 等。以 llama.cpp 为例，通过量化脚本把模型转成 q4_k_m 或 q5_k_m 格式，文件可以压到 4-5G，推理速度也有明显提升。实测下来 q4_k_m 格式的 Mistral-7B 模型，在普通 CPU 上也能做到每秒几到十几 token 的生成速度，足以应对轻量级应用。
5.3 部署到本地推理服务
部署方案取决于你的环境和使用场景。如果你还在调试阶段，推荐直接用 transformers 的 pipeline 在 Python 里调用，方便随时改参数。
from transformers import AutoModelForCausalLM, AutoTokenizer, pipeline model_path = "./mistral-lora-merged" model = AutoModelForCausalLM.from_pretrained(model_path, torch_dtype=torch.float16, device_map="auto") tokenizer = AutoTokenizer.from_pretrained(model_path) pipe = pipeline("text-generation", model=model, tokenizer=tokenizer) result = pipe( "### Instruction:\n生成一句话介绍你的主要功能。\n\n### Response:\n", max_new_tokens=128, do_sample=True, temperature=0.7, top_p=0.9 ) print(result[0]["generated_text"])如果你需要把模型集成到对外服务里，建议用 vLLM 这类高性能推理框架。vLLM 支持 Mistral 架构，有内置的 paged attention 优化，推理吞吐量可以比原生 transformers 高一个数量级。启动方式也很简单，准备好 merged 模型目录之后，可以用命令直接起一个 OpenAI 兼容接口的服务。
python -m vllm.entrypoints.openai.api_server \ --model ./mistral-lora-merged \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --port 8000服务启动之后，就可以用标准的/v1/chat/completions接口来调用微调后的模型了。我在实际项目里通常会在 vLLM 服务前面再挂一层 API 网关，负责鉴权、限流和日志记录，这样不管模型怎么换，对上层业务完全透明。
5.4 微调项目的维护与持续改进
微调不是一次性工作，模型上线之后还需要持续迭代。有三个建议送给已经完成首个微调项目的你。
第一是保存好训练数据的版本。把每版训练数据标注好日期、数据量、来源和清洗规则，模型表现有问题时能快速回溯是哪一版数据引入的偏差。
第二是建立线上反馈闭环。比如你的模型在客服场景里上线了，把用户的投诉率、问题重问率、转人工率这些指标定期收集起来，作为下一轮微调数据的筛选依据。微调模型优化的大头，就在这份线上反馈数据里。
第三是多版本并行。不要每次都把旧模型覆盖掉，保留最近两三个版本的模型，方便做 A/B 测试。线上流量可以先切 5% 到新版本观察几天，确定没有明显问题再全量切换。我们做过一次全量切换后第二天就发现某个领域的回答质量变差，还好及时回滚，才避免了更大的影响。
6. 常见问题速查表：照表排查能省很多时间
在微调的实操中，很多问题都是反反复复出现的。我把高频问题整理成一个速查表，方便你在遇到异常时快速定位方向。
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 训练 loss 不降反升 | 学习率过高；数据中有大量矛盾样本 | 降低学习率到 5e-5 再试；清洗数据中明显的错误标注 |
| 训练 loss 下降但生成效果无提升 | LoRA rank 太低导致容量不足；数据量与任务复杂度不匹配 | 将 rank 提升到 32 或 64；补充更多样化的数据 |
| 输出内容变成乱码或重复字符 | 温度过高；生成长度限制不当；tokenizer 未设置 pad token | 降低 temperature 到 0.5-0.7；检查并合理设置 max_new_tokens |
| 训练时显存溢出 | batch size 过大；开启了 use_cache | 调小 batch size 和 max_seq_length；开启 gradient checkpointing；QLoRA 量化加载 |
| 微调后通用能力下降明显 | 数据集中通用数据占比太低 | 在垂直领域数据中掺入 20%-30% 通用指令数据重训 |
| 模型推理速度慢 | 量化精度选得过高；显存未充分利用 | 使用 q4_k_m 等更小的量化格式；用 vLLM 替代原生的 transformers 推理 |
| 多轮对话时模型不记得前文 | ShareGPT 格式数据里历史轮次太短 | 扩充多轮样本的轮数，至少保留 4-6 轮上下文 |
| 同一输入每次输出差异很大 | 采样参数设置过于随机 | 降低 temperature，选择更小的 top_p 或直接设为 greedy decoding |
| 部署后服务延迟波动大 | 并发请求过多导致排队 | 增加 vLLM 实例数或用负载均衡分发请求；调整 gpu-memory-utilization 预留缓冲 |
这份速查表是我在多个微调项目里沉淀下来的，不敢说覆盖全部情况，但足够帮你解决八成以上的日常问题。遇到新的奇怪错误时，记住先看日志第一条报错信息，然后是数据检查，最后再看训练配置，排查效率会高很多。
我在实际使用中的体会是，微调最难的从来不是训练本身，而是数据和对任务的理解。把这两件事想透了，训练过程也就是按个按钮的事。另外一个小建议：第一次跑微调的时候，不要一上来就用全部数据和复杂的参数，先用几百条数据、默认参数跑通一遍全流程，确认代码和环境都没问题，再上完整数据集。这样能让你把“训练流程出错”和“数据质量不行”这两类问题分开排查，少走很多弯路。
接下来你可以顺着这个方向继续扩展，比如在微调数据里加入更复杂的推理链，或者尝试把 Mistral 微调后接入前面讲过的 RAG 框架，让垂直知识和实时检索结合起来。那才是有意思的开始。
