深夜代码笔记

4090跑7B LoRA其实不算太紧张，但你batch size 4就OOM，八成是LoRA的target modules设得太宽了，比如q_proj k_proj v_proj o_proj全挂上，再加上mlp层，显存蹭蹭涨。客服情感分类这种任务，只挂q和v两个投影层试试，效果通常够用，显存能省不少。gradient checkpointing确实能降显存但会拖慢速度，配合小batch的话不如试

我之前也卡在这个阶段，检索没问题但生成拉胯，后来发现prompt里明确约束输出格式特别关键。你可以试试直接要求“用两三句话概括答案，不要罗列原文”，比笼统说“简洁”管用得多。文档来源我觉得有用，尤其是多文档场景，告诉模型片段来自哪篇能让它自己判断可信度，但别塞太多元信息进去，容易分散注意力。分点还是结论看场景，事实型问答直接给结论，对比类问题再让它分点。温度我一般调到0.1到0.3之间，RAG本来

我一般把变量名放代码块里再强调“原样保留”，比纯文字描述管用多了。

我之前也遇到过类似问题，后来换了方案。

有没有更详细的教程推荐？

有没有更详细的教程推荐？

有没有更详细的教程推荐？

我之前也遇到过类似问题，后来换了方案。

写得挺好，建议补充一些性能数据。

我们也在生产上跑Qwen2.5-7B，一开始也是单卡A10被OOM教育了。后来试过AWQ 4bit，确实能塞进去，但你说的速度变慢我也遇到过，尤其是batch size小的时候反而不如FP16快。后来发现是kernel没选对，换用vLLM自带的awq_marlin后端之后吞吐才正常，输出质量的话我们做了一轮评测，日常问答几乎无感，但代码生成和数学推理确实会掉一点，看你们场景能不能接受。如果内部工具

显存慢慢涨基本就是有变量没释放，比如loss累积或者metric里存了tensor。用torch.cuda.memory_summary()看下历史峰值，能定位到哪一步涨的。

LoRA微调本来计算量就小，编译开销根本摊不平，慢很正常。大模型全参训练才可能看到收益。

我踩过这个坑，纯哈希去重太死板了，稍微改个字就失效。后来改成入库前先跟最近几条算相似度，超过阈值就只更新时间戳和权重，不新增记录。Chroma本身没有内置这功能，得在写入前自己拦一道。另外摘要去重适合长对话，短查询反而容易丢细节，慎用。

我之前用Qwen2.5-32B也踩过这个坑，循环调用确实挺常见的，但后来发现不完全是模型能力的问题。ReAct框架本身对模型的指令遵循要求就比较高，Qwen系在工具调用上的训练数据可能没覆盖那么多“看结果决定下一步”的场景，所以它容易陷入“我还没得到满意答案就再试一次”的模式。我最后的解法是在工具返回里加一个很明确的字段，比如status: success 或者 need_more_info，然后

我之前也遇到过，Chroma里堆了一堆“订单号是多少”的重复记忆，检索时确实乱。后来我是在入库前先算个相似度，超过阈值就只更新时间戳、不新增记录，效果还行。但阈值别设太高，不然稍微换个问法就漏了，建议在0.85到0.9之间试试。哈希去重太死板了，换一个字就失效，LLM摘要成本又高，不太划算。

几万条笔记Chroma完全够用，别被“生产环境”吓到，MCP本地场景延迟真没差。

我最近也在折腾类似的东西，chunk调大确实能缓解但治标不治本。后来试了parent document retriever，子块切小点专门用来匹配，父块放完整段落给模型看，效果明显好不少。重排我觉得挺值得加的，检索回来的顺序对连贯性影响很大。二次摘要没试过，感觉多一步容易丢细节，你可以先跑个小样本对比看看。

指数退避确实比无脑重试靠谱，但得区分下超时原因。如果是工具端限流或网络抖动，重试有意义；要是工具本身挂了，退避到天荒地老也没用。我一般会在client层包一层tenacity，配max_retries加jitter，再给每个工具单独设个熔断阈值，连续失败几次就直接降级返回默认值。另外MCP本身好像没内置中间件机制，你可能得自己在调用封装那层做。

我3060 12G之前也跑过类似方案，建议别急着等50系。先把embedding单独拆出去用CPU或小显存跑，能省出1-2G给上下文，胡言乱语多半是KV cache爆了不是模型不行。14B量化在12G上勉强能跑但速度会很难受，不如把7B的上下文管理和工具调用逻辑调稳，等换卡再上大模型。

这个思路不错，收藏了。