全栈档案馆

7B微调单卡40G确实紧，我一般会先把bf16和gradient checkpointing叠上，但checkpointing跟ZeRO-3容易掐架，可以试试换成ZeRO-2或者把checkpointing的interval调大点。不过说实话，如果只是做领域适配，LoRA或QLoRA才是真香，显存直接砍到十几G，速度也快，全参微调除非数据量特别大不然没必要硬扛。

看到你这个情况我太有共鸣了，之前调Agent的时候也被显存折磨过一阵。你提到每次推理都涨几百MB，大概率不是计算图的问题，因为torch.no_grad()已经切断梯度了，真正的问题在于你每次把完整历史对话拼起来喂给模型，而transformers库默认会为整个输入序列重新计算KV cache，旧的那份并没有被释放，只是被新的大序列覆盖了，所以峰值会一直往上走。我当时的做法是手动维护一个定长的对话

上下文质量比prompt格式重要多了，先检查检索出来的片段是不是本来就答非所问。 大概率是retrieval的锅，GPT-4对混乱上下文照样一本正经瞎编。

几百条数据对微调来说确实偏少了，尤其是MCP这种对上下文敏感的任务，模型容易过拟合到你的小样本上，反而丢失泛化能力。我试过类似情况，把学习率调低一个量级、轮数控制在3-5轮，效果会比默认参数稳不少。可视化的话可以看看weights & biases或者tensorboard，但更直接的还是拿一批你标注之外的真实场景问题去对比测试，光看loss曲线容易误导。你方便说说你用的基础模型是哪个吗？不同底座

解析层加个容错正则，把空格换行和常见拼写错误自动纠正掉，比死磕模型输出靠谱。 训练数据里多塞点带干扰格式的负样本，让模型见过乱格式，生成时自然就规矩了。

这问题我踩过类似的坑。7B模型对prompt的结构敏感度很高，官方Demo里那个模板可能不只是角色名字，连标点符号、换行格式和上下文长度都是调试过的。建议你把官方模板和你的模板逐行对比，特别是系统提示里的角色定义部分，有时候多一个句号或少一个示例对话，输出就差很多。另外Ollama和vLLM的默认参数不一样，vLLM的top_p和温度最好调低到0.6以下试试。