灰狼研究AI日记

你del loss和output其实没啥用，Python的引用计数在循环里只要变量被重新赋值，旧的计算图该释放就释放了，问题大概率不在这。我比较怀疑你自定义Dataset里是不是把整个数据集的tensor或者numpy数组缓存在了__init__里，或者__getitem__返回的东西被某个全局list悄悄存下来了，这种才是真正的泄漏点。另外可以试试torch.cuda.memory_summar

你lr 2e-4对LoRA来说偏高了，7B模型我一般从1e-4甚至5e-5起步，loss来回跳八成是学习率太激进。长文本超1500token建议先做长度分桶，别一股脑pad到最长，显存和稳定性都会好很多。还有你batch size开2的话梯度累积可以顶上去，等效batch大一点loss曲线会平滑不少。

我也踩过这个坑，后来发现是工具描述写得太“技术流”了，模型根本get不到什么时候该用。把description改成“当用户问及具体事实、数字、文档细节时必须先调用”这种大白话，调用率立马上去。另外检索回来的内容最好加个简短摘要或重排，直接甩原始chunk它确实容易当没看见。你可以试试在系统提示里明确写“不确定的先查再答”，比单纯给工具管用。

温度调到0.1试试，7B确实容易自作主张，我一般还得加个后处理比对签名。

先别急着上GraphRAG，你这问题八成出在query和文档的语义gap上，加个rerank试试，比换框架管用。

实际跑下来Kimi长文本确实香，但便宜这么多，稳定性真能长期扛住吗？

20并发就OOM确实不太像显存分配的问题，更像是vLLM的KV cache预留机制在跟你抢空间。你设了0.9的利用率，但Qwen2.5-7B的KV cache是按最大序列长度动态扩容的，8192长度下每个请求的KV cache峰值会远高于你单请求测试时的实际占用，20个并发瞬间就把剩余显存吃满了。我之前用A6000 48G跑类似模型也踩过坑，后来把max-model-len降到4096，同时给gp

大概率不是缓存问题，ReAct拆查询时子问题太碎，容易检索不到新chunk，建议把overlap调大点试试。

我之前搞过类似的事，也是Qwen系列，后来发现关键不在prompt措辞，而是让它先输出一个“空字段模板”，再填值，抽风概率会低不少。另外你试过把输出格式定义成XML而不是JSON吗？对7B来说XML的括号约束反而更稳定。微调的话，如果你能攒几百条真实合同样本，lora跑一下效果会质变，但要是字段总变，那还是写死模板加正则兜底更省心。

别纠结，先把手上的活干完再说。真要部署了，转成ONNX啥框架都能跑。

说实话你这用户量和数据规模，Chroma或者qdrant本地跑完全够了，别在Milvus上死磕索引参数，那玩意是为亿级数据设计的，小数据量默认配置反而容易过拟合。Pinecone确实省心，但几百个用户每月账单可能比服务器还贵，不值当。embedding维度差异主要看你用的模型，各库对cosine和点积支持都差不多，但要注意Milvus老版本对某些距离计算有精度坑。我建议你先用Chroma把Agen

4090跑70B其实挺吃力的，我试过Q4_K_M的GGUF，速度大概就5-8 token/s，代码补全凑合能用，但长上下文确实容易慢到怀疑人生。量化到4bit对代码类任务影响不大，反而文档总结偶尔会丢细节，建议拿7B或14B专门跑总结。vLLM对显存管理更高效，但24G上70B还是得配合量化，而且主要吃内存带宽，体验未必比llama.cpp好。我最后是双开：7B跑对话，14B跑总结，省心不少。

这问题我也踩过坑，其实跟模型关系不大，主要是Cursor的默认指令里带了“详细解释”的倾向。你在设置里搜一下“Extra Instructions”，直接写“只输出代码，不要注释和多余逻辑”，效果立竿见影。另外温度调低确实能压住它的“创作欲”，但0.1有点太低，反而容易让它死板地套模板。错误处理这个我试过在prompt里加“按最简方案实现”，无效的话就手动把那段删了，多删几次它就会学乖，毕竟它也会

我最近也踩过这个坑，后来发现光贴一段示例不够，得把风格拆成几个具体的点写进规则里，比如“只用函数组件+useState”这种明确指令，比笼统说“模仿风格”好使。另外把示例放Prompt最后面，紧跟任务描述，模型可能更容易注意到。你试试把代码风格示例的注释也保留下来，有时候模型会根据注释推断你的偏好，比纯代码管用。不过说实话，它还是会偶尔抽风，生成完自己扫一眼改改也正常。

试过给chunk加文件路径和调用关系的元数据再喂给rerank，确实比纯文本效果好一些，但cross-encoder对代码这种结构化文本真的容易误判。代码专用embedding（比如CodeBERT或GraphCodeBERT）在函数级粒度上会保留更多语义，不过如果你不想换模型，可以试试把函数签名、类名、依赖注入这些信息拼到chunk开头，让检索阶段就更聚焦。另外你那个登录接口的query，要不要

同款配置，bge-large换过m3也试过，瓶颈大概率不在向量库，在切块策略。512/128对长文档太粗糙，试试按语义段落切或者加个小标题识别，召回能涨3-5个点。 另外Recall@10这个指标本身有点虚，你确认下gold标准里是不是有很多语义相近但字面不重叠的case？如果是，那embedding的区分度才是真问题，建议看下难例的embedding距离分布，而不是只看整体相似度。 还有个思

这情况我遇到过，2万条客服数据做LoRA确实有点悬，单轮问答格式太单一了，模型学到的更多是“话术匹配”而不是“对话能力”。你可以先拿原始模型跑一遍测试集，看看是不是LoRA把原本的基座能力带偏了，我猜答非所问多半是rank和lr配得不够稳。混合通用语料的说法有道理，我一般按5:1到10:1的比例混，但更建议你先把客服数据做一下清洗，很多口语化重复和上下文缺失，可能比调参影响更大。

说实话我刚用LangGraph那会儿也栽在状态管理上，后来发现关键是把State定义成TypedDict然后每个节点只声明自己需要的字段，别图省事把整个state传来传去。你那个工具结果被冲掉的问题，大概率是节点里直接改了state而没有走return，或者用了相同的key覆盖了。我现在的做法是给每个工具调用单独开一个命名空间，比如tool_result_{tool_name}，然后汇总节点再统一

说实话你这个问题我上个月刚踩完坑，14B int8单卡80G跑十几个并发确实紧，尤其你们还带长上下文，KV Cache那部分才是真正的无底洞。我建议先别急着双卡，AWQ量化到4bit之后显存占用直接砍半，配合max_model_len限制在8k左右，A100单卡撑二十个并发问题不大，但前提是得把系统提示词和固定知识前缀做成静态块，别每次都重新编码。关于RAG拼接，我试过把历史对话压缩成摘要再和检索

这场景我太熟了，A10跑7B单卡确实有点尴尬。建议先试试AWQ 4bit配vLLM，我这边实测代码生成任务掉点能控制在2%以内，知识库问答影响更小。另外可以开vLLM的continuous batching，5、6并发其实用不到多卡，显存瓶颈主要在KV cache，把max-num-seqs调小点、加上--kv-cache-dtype fp8能省不少。蒸馏暂时别碰，小模型在知识库这种场景容易瞎编。