猞猁喜欢开源日记

3090跑7B不至于OOM的，我猜你多半是没设置dtype，默认fp32加载的话光权重就要28G，直接就把24G吃满了。试试在from_pretrained里加上torch_dtype=torch.bfloat16或者float16，显存占用能掉到14G左右，推理完全没问题。4bit量化虽然加载省显存，但bitsandbytes在3090这种消费卡上反量化开销挺大的，速度掉到2秒一token也算正

量化版模型本身就会有精度损失，7B这个尺寸在本地跑，prompt稍微换点措辞结果差异大挺正常的，跟API那种大模型比确实不一样。我之前也折腾过vLLM部署，后来发现把system prompt写得更死板一点、少留模糊空间，再把repetition penalty调到1.1左右，稳定性会好不少。另外你确认下是不是并发请求时KV cache没管好，有时候是工程层面的锅不是prompt的锅。

5000条数据对7B模型来说确实少了点，loss从2.1到1.8就卡住，说明模型主要在拟合表面模式，没真正学到你的业务逻辑。rank=16不算高，问题更可能出在lr=2e-4对LoRA来说偏大，容易早期就收敛到局部最优。建议试试把lr降到5e-5左右，同时检查下数据里是不是有大量重复或矛盾的回答，客服场景里这种问题特别常见。另外验证集回答重复也可能是解码策略的问题，可以调下temperature和

这个坑我去年踩过，大概率不是你的代码逻辑问题，而是vLLM在OfflineBatch下对sequence group的回收确实有点迷。它内部有个block manager，理论上序列结束后会释放KV cache，但如果你每次都是新建LLMEngine或者重复传不同request id，有些旧block可能一直挂在cache里没被驱逐。你可以先试试在每轮循环后手动调用engine的reset或者清空

补全任务和指令微调其实差别挺大，你这种“前缀+后缀”混在一起训，模型很容易学成复制粘贴。loss降到0.8不代表生成质量好，代码补全更该看exact match或者编辑距离。LoRA r=8确实偏小，但更可能是数据里重复片段太多，模型记住了噪声。建议先拿HumanEval或者RepoBench筛一下，再考虑把r调到16或32试试。

LangChain和LlamaIndex其实不是二选一的关系，我现在的项目就是混着用的。LangChain的生态确实更全，但它的文档切分和检索那块抽象层太多了，调起来绕得头疼，LlamaIndex在索引结构和查询路由上确实更顺手，尤其是你这种几百份文档还带扫描件的场景，它的递归检索和节点关系处理能省不少事。迁移成本的话，如果只是QA链那部分，核心逻辑其实不复杂，把embedding和retriev

先看切分，合同条款按自然段切别硬凑500，bge对超长片段确实会丢语义。加个rerank基本能救大半。

我之前也纠结过这个，后来实际踩坑发现MCP对PyTorch的支持确实更丝滑一些，尤其是你想加微调那步。TensorFlow的SavedModel虽然部署省心，但一旦你要在MCP管道里插入自定义的训练逻辑，图模式那套东西改起来挺折腾的，PyTorch的动态图调试起来舒服太多。多模态这块CLIP、BLIP这些主流实现基本都是PyTorch生态，社区里遇到问题搜到的答案也更多。不过有个点要注意，MCP的

20个样本确实有点多了，意图分类这种任务5个以内通常就够了，塞太多反而容易让模型抓不住重点。例子放system还是user其实影响没那么大，关键是格式要统一、标签要清晰，别让模型猜。温度直接设0就行，分类任务不需要发挥，0.2反而会引入随机性。至于上午下午结果不一样，大概率是API版本或后端有变动，建议跑的时候固定seed并记录model版本。

这个坑挺典型的，单轮80%多其实已经说明模型学会了格式，问题大概率出在它没学会“什么时候该调用”以及“多轮上下文里怎么保持决策一致性”。你的训练数据是5k条function calling格式，如果基本都是“用户问→正确调用”的正样本，那模型学到的就是“看到类似输入就输出调用”，但真实多轮里它得先判断当前状态该不该调、调哪个，这跟单轮分类是两码事。loss降到0.3反而可能过拟合了工具名和参数的表

我一般把约束分两层：硬性规则放最前面，软性偏好加一句“尽量”，不然模型确实会顾此失彼。

LoRA掉点正常，试试混10%通用数据一起训，比换全量省事多了。

我们也是踩过这个坑，后来干脆分两层：短期用Redis存最近N轮对话，检索时只走这个；长期知识单独放一个collection，靠metadata打标签做路由。时间戳filter确实不太行，关键还是得在写入前做一轮摘要压缩，把没用的闲聊过滤掉。短期过期我倾向归档到冷存储，直接删有时候回溯问题挺麻烦的，留个快照成本也不高。

24G跑7B确实不该这么紧，但VLLM默认会按gpu-memory-utilization把KV Cache预分配到接近0.9，你5-6并发一上来就容易顶到天花板。建议先把max-model-len降到2048试试，4096的KV占用翻倍很夸张。另外Qwen2.5-7B的权重加载本身就要占十几G，你--enforce-eager还会额外吃显存，不一定划算。可以换成--max-num-batched

A100 40G跑7B确实不该这么慢，先确认下是不是用了默认的FP16加载、没开continuous batching？vLLM的话重点看gpu_memory_utilization和max_num_seqs这两个参数，调好了吞吐能翻好几倍。量化到AWQ或GPTQ基本不掉点还能再提速，生产环境强烈建议上。并发内存飙高大概率是KV cache没限制好，可以设max_model_len和swap空间来

LangGraph状态机确实能治槽位污染，但学习成本高；简单点可以先在prompt里显式清空旧槽位试试。

模板还是别往前端放，我们踩过坑。之前把few-shot和角色设定丢前端，结果不同版本一缓存，线上回答风格全乱套了。现在统一后端管理，前端只管传用户问题和会话ID，要预览就加个dry-run接口返回拼好的prompt。Token计算也只在后端做一次，不然前后端各算各的肯定对不上。

几千份文档直接靠向量检索确实容易翻车，尤其查询词和文档用词不一致的时候。我建议先别急着换embedding，把chunk按照文档结构切，比如按标题层级来分，保留一点上下文重叠，效果会好不少。reranker基本是标配了，加个bge-reranker或者cohere的，召回top20再精排top5，提升很明显。另外可以试试混合检索，BM25加向量一起用，对技术手册这种关键词密集的场景挺管用。

我觉得一次生成能跑的代码基本是奢望，尤其是Excel这种边界情况一大堆的场景。Claude不知道你的表长啥样，只能靠猜，所以默认读第一个sheet太正常了。我一般会把表头、sheet名、几个典型行的样例直接贴进提示词里，比纯文字描述管用很多。另外真别指望一步到位，把生成-报错-修正当成正常节奏，反而省心，关键是让它每次改的时候别把之前对的部分也改坏了。

别急着调模板，先看看top-5是不是塞太满了，压缩成摘要或按相关性截断可能比改prompt管用。