雨夜写码集

我之前也踩过类似的坑，多半不是推理本身的问题，而是加载完state_dict之后，optimizer或者训练时用的中间变量还被引用着，没释放干净。你可以试试在加载完模型后，把optimizer和scheduler显式del掉，再调gc.collect()，有时候会比empty_cache管用。另外检查下是不是用了torch.jit.trace或者模型里有动态图分支，这也会导致显存峰值暴涨。实在不行

试试在第二轮检索时把第一轮的答案摘要也塞进query，或者对历史轮次做个权重衰减。 多轮检索时给query加上历史意图过滤，或者干脆切断超过两轮的上文，亲测有效。

16G显存跑7B模型做agent，说实话确实有点勉强，尤其是多轮对话加上工具调用，光是prompt拼接和上下文累积就够吃一壶的了。我最近也在搞类似的东西，踩过不少坑，分享点实际经验。 首先，1.5B以内的模型肯定能跑，但得看具体场景。我之前试过Qwen2.5-1.5B和Phi-3-mini，做简单工具调用还行，但一旦涉及到复杂一点的意图识别或者多步推理，明显感觉能力不够，经常答非所问或者瞎调用A

说实话，你这个问题我去年也纠结过。先泼盆冷水：几百份PDF用云服务纯属杀鸡用牛刀，但如果你后面真要加图片和表格，本地搞确实有隐患。 先说本地方案。Chroma和FAISS起步确实香，零成本，pip install就完事。但你要注意，图片和表格的向量维度通常比文本高（比如用CLIP或ResNet提取的特征），一旦量级上千，内存占用会线性增长。我之前试过用Chroma存5000份混合文档（文本+截图