小宋Lab手记

我之前也踩过类似的坑，训练时带系统提示词推理时去掉，效果确实会飘。但完全保留又容易让模型过度执着于那几个词，我后来是把提示词改短一点，比如精简成“你是客服”，推理时也带上，重复问题好了很多。 另外建议你看看LLaMA-Factory的文档，里面提到过训练和推理时格式一致性对稳定性的影响，不一定要一模一样，但角色设定那块最好保持同一种风格。 还有个思路是分开处理，微调时把系统提示词当作独立轮次，

推理阶段OOM基本跟LoRA训练配置关系不大，你加载模型就吃掉25G，那40G卡跑7B其实挺吃紧的，尤其如果max length设到2k以上，KV cache会占掉一大块。int8理论上能压到15G左右，但你没说用没用bitsandbytes，如果只是转成int8但加载方式不对，显存照样下不来。vLLM确实能省不少，但7B本身推理也要10G+，建议先查一下推理时的batch size和max_ne

老实说你这配置跑7B LoRA确实有点紧，但24G不该这么惨。试试把batch size压到1，同时开gradient accumulation到8，效果等同batch size 8，loss会稳很多。另外强烈建议上QLoRA，用bitsandbytes的4bit NF4量化，显存直接砍半，我记得装个peft库改几行配置就行。还有个野路子：把tokenizer的padding策略改成左侧填充，能减

我之前也卡在这上面好久，后来发现把任务拆成“步骤+格式”会稳很多，比如明确告诉模型“先列出模块清单，再逐条写影响范围”，比光说“按模块分组”管用。还有个坑是别让模型自己猜颗粒度，你给个示例输出结构，它往往就不跑偏了。你试过在prompt里加“如果信息不足，就明确说不知道”吗？这招对防止胡编挺有效。 --- 结构化这玩意儿确实玄学，我现在的土办法是写完prompt自己先当一回模型，顺着字面意思推

500字确实过载了，我一般把关键约束压到200字内，效果反而稳。 试试把few-shot砍到2个，格式用最简模板，模型自由度太高容易放飞。

这个loss卡在0.8其实挺典型的，LoRA微调代码补全时rank=8可能容量不够，尤其函数体这种结构化强的数据，试试把rank提到16或32，alpha跟着翻倍。另外你切“缺失行”的方式，如果上下文边界切得不准，模型根本学不到对齐关系，BLEU低也正常。我建议先拿1000条数据过拟合一下，如果loss能降下去说明数据没问题，否则就是格式或预处理有坑。还有，GitHub爬的代码重复度很高，去重没做

其实模型挺“认生”的，微调时见过啥格式，推理时用别的格式它就容易懵。我之前也踩过这坑，后来干脆把训练数据里混了三种模板，效果明显稳多了。不过也别太极端，模板太多可能让模型学得更慢，建议先固定两三种主流的，够用就行。另外你直接输问题效果差，也可能是因为模型没被引导出“客服”角色，可以试试点前缀提示，比如“你是一个客服”。

这现象太典型了，尤其Qwen系对system prompt的权重比想象中高，几个字的变化可能直接扰动它的隐空间先验分布。我试过把temperature降到0.5会稳一些，但偶尔也会抽风，感觉跟采样参数关系不大，更像模型本身对指令边界敏感。你可以试试把“严谨”这类抽象词换成具体行为描述，比如“回答需包含步骤和结论”，效果可能比调参数立竿见影。

试过按语义切分配递归字符分割器，长文档先分层再定长兜底，召回率能稳不少。

说实话我当初也卡在这一步好久，最后选了PyTorch，主要因为它的动态图机制在调试MCP这种多模态融合时太直观了，你可以随时print中间层的输出，断点打进去直接看张量怎么变的，TensorFlow的静态图虽然现在也有eager mode但总感觉隔了一层。不过你要是想快速验证想法、而且对底层原理还没那么熟，Keras的Sequential和Functional API确实能让你少写很多模板代码，尤

结构切分比固定长度靠谱得多，尤其你这种混合文档，先按标题拆再递归降级，overlap 10%-20%就够。想省事直接上语义切分器，topk先给10，rerank后基本能救回来。

说实话3090跑8B还得看你的max sequence length，kv cache是跟这个挂钩的。我实测vLLM在24G下，max_len设4096、batch size到4没问题，但TGI的显存控制略好一点，能到5-6，不过吞吐量vLLM更高。int4量化建议用AWQ，对话摘要影响不大，长文本确实会偶尔出现重复或逻辑跳跃，但你要是不追求极致效果完全能接受。另外可以试试把max_model_l

1.8的loss对LoRA来说其实不算离谱，但回答重复更像解码参数问题，试试把temperature调高到0.8，top_p降到0.9，有时候比死磕loss管用。另外你只跑十几轮，LoRA一般要25轮以上才稳定，可以再加点epochs看看曲线是不是还在缓慢下降。 中文法律语料跟Llama 3原生分布差挺远，建议先拿通用中文指令数据做一轮sft，再叠你的法律数据，效果会比直接上LoRA好。全量微调

我之前也踩过类似的坑，512的chunk确实太碎了，尤其技术文档里术语经常跨段落出现。你可以试试先用1000-1500的chunk做召回，然后再用256的小chunk做精排，效果会好不少。另外reranker强烈建议加，bge-reranker-base跑本地就够用，成本低提升很明显。还有就是embedding模型可以换bge-m3或者text-embedding-3-large，对专业术语的理解

多步推理里我试过拆分子Prompt，效果反而更稳，因为每步都能强制绑定检索结果再进下一步，模型不容易“自由发挥”。不过拆太细会损失上下文连贯性，建议关键节点才拆。“必须基于检索结果”我一般会在工具返回后加一句“只允许使用上面的内容，禁止推测”，配合few-shot举一个错误例子，比单纯强调管用。你现在的system prompt里工具描述和推理规则是分开写的吗？我猜混在一起可能干扰了模型对约束的注

试试把需求拆成小任务，每次只给一个文件路径，明确说“其他文件别动”，能好不少。

你方向感其实挺对的，MCP在深度学习里确实不是指那个Model Context Protocol，更像是一个社区里对“模型通信/控制平面”的模糊叫法，跟PyTorch的Hook压根不是一个层面的东西。Hook是框架内部给你在张量流动时塞回调的机制，而MCP更像跨框架的通信约定，比如多机多卡时交换梯度或控制信号用的。想提取中间层特征的话，直接注册forward hook就好，别被那个缩写带偏了。我也

0.8卡住挺正常的，LoRA微调7B这个loss水平不算离谱，别太迷信别人报的数。你可以看看验证集上的生成效果，如果回答质量还行，就别死磕loss数值。格式不统一和padding确实会影响收敛，试着把指令模板完全固定下来，答案截断到统一长度再试试。另外，训练轮数可以拉到3-5个epoch看看，有时loss震荡是数据量太小导致的过拟合信号。

500条数据确实有点少，复杂场景下参数混淆大概率是样本覆盖不够，尤其是工具多、参数重叠时模型容易学混。建议你按MCP的tool schema把每个参数的取值范围和边界条件写清楚，再针对容易混淆的字段（比如city和temperature）专门造一批对比负例。我之前用类似方法调LLaMA时，加了20%的随机负例后准确率提升明显，你可以试试。另外Qwen2.5-7B对function calling的

说实话我也踩过类似的坑，vLLM默认的显存预留机制有时候挺激进的，尤其并发上来之后KV cache占用会超预期。你试试开--gpu-memory-utilization调到0.85，再配合--enable-prefix-caching，应该能缓解不少。量化的话我建议先试AWQ，4bit精度下7B的显存能压到6G左右，但得注意vLLM对量化模型的支持版本，太旧了会有兼容问题。流水线并行在这个规模下收