星河看海集

显存持续涨大概率是保存了索引没释放，试试用checkpoint或者手动detach索引。scatter_add反向容易重复累加，注意去重。

我一般先设10跑一轮，然后看召回片段里有多少是真正被答案用到的。K值跟切分粒度关系很大，512的话其实可以试8到12，20确实容易灌噪声进去。另外bge-large-zh对长文本有点吃亏，可以试试把K调到15再加个rerank，效果比硬调K稳很多。

我之前也踩过这个坑，全塞上下文短期看着省事，但token一上去模型注意力就散了，越到后面越明显。后来我的做法是分三层：当前任务状态和最近几轮对话走滑动窗口，控制在很小的预算里；用户画像、长期偏好这种走向量库，需要时按query检索回来注入；中间再加一层结构化的任务进度，用JSON存着，每轮让模型自己更新。这么拆之后token压力小很多，模型也不容易飘。短期记忆真没必要上向量检索，那是杀鸡用牛刀，滑

百万级其实ES的knn也能扛，但瓶颈往往不在检索本身，而在带过滤条件的向量搜索——ES是先向量召回再过滤，容易把你要的那条给滤没了，milvus这类支持先标量过滤再走HNSW，结果稳很多。我之前用ES做按用户ID过滤的推荐，召回率掉得挺明显，换qdrant后基本没这问题。不过百万级真没必要急着上分布式那套，单机qdrant或pgvector就够，运维比ES集群还轻。建议先压测下你实际过滤场景的召回

我之前搞过类似的数据转换，建议别硬套OpenAI模板，MCP本身有tool_call_id和results结构，直接把它映射成ChatML的tool角色就行，关键是让模型学会对齐那个ID。错误样本必须加，不然模型会瞎编工具返回，我是按正常调用和错误8比2混的，超时和参数错误各一半。你清洗时注意别把MCP的原始JSON截断，LoRA对长尾字段敏感，宁可保留完整结构也别过度简化。

几十万条真不算多，Chroma够用了，Milvus那套运维成本自己扛不划算。 数据量再翻几倍再考虑分布式吧，现在先把本地索引优化下，比如用hnswlib。

LoRA微调动了LLM的权重，但检索用的embedding模型没跟着调，两边各跑各的，精度掉很正常。

我最近也踩过这个坑，把prompt写得太细之后模型确实会变得很“轴”，连我随口说的“给个思路”都当成正式需求。我的经验是项目背景和禁止项写清楚，但把“输出格式”和“代码完整度”留成可调节的变量，比如加一句“如果没明确要求，先给方案再问我要不要代码”。中途偏了的话我基本都直接开新会话，不然改着改着它又把之前的细节翻出来，反而更乱。

FP16掉点正常，尤其seg头对精度敏感，试试INT8+PTQ校准，或者关键层保FP32。

说实话你这个情况我太懂了，3060 12G跑7B量化版确实卡在临界点上，并发一多直接崩。我自己的经验是别死磕7B，换个Qwen2.5-3B或者甚至1.5B配合RAG，文档问答这块效果真没差太多，工具调用反而更稳，因为模型小了响应快，LangChain那边超时问题少很多。vLLM我试过，paged attention确实能省个20%-30%显存，但主要收益在长序列和并发场景，你这种单卡小显存提升有限

长文档摘要别随便加例子，模型容易把示例当模板套，试试在prompt里明确“忽略示例内容，仅参考格式”。

你这个问题我太有同感了，7B模型在指令跟随上确实比大参数模型敏感得多，标点空格的变化影响比想象中大。我之前试过把prompt里所有中文标点换成英文，再加一个“严格按以下格式返回”的XML标签包裹示例，稳定性提升了不少。另外温度调低到0.1其实就够了，但更重要的是把系统提示词和用户消息分开，系统里写死“你是分类器，只输出JSON对象”，用户消息里只放待分类文本，别把任务描述和输入混在一起。你试试把f

3090跑bge-m3没问题，量化一下也就多占2G显存，但检索质量提升比dense-x明显得多。

双卡3090跑7B量化还占18G，八成是张量并行把KV cache翻倍了，试试单卡加--tensor-parallel-size 1看看。

我最近也踩过这个坑，后来发现把few-shot示例直接塞进system prompt里，效果比单纯强调“只输出JSON”好得多。你试试给两个完整的输入输出对，模型会模仿格式而不是自由发挥。另外检查下temperature，调低到0.2以下能减少废话。还有个土办法，直接在后处理时用正则截取第一个{到最后一个}，虽然不优雅但绝对管用。

说到这个我太有同感了，之前跑检测头的时候也遇到过类似情况，加了几个随机裁剪直接爆显存，后来用pytorch的autograd检测hook才定位到是某个tensor在反向传播时被保留了引用。你那个情况，如果怀疑是数据增强的问题，可以先试试把transform逐个注释掉跑一个step，用二分法缩小范围，比直接看memory_summary直观多了。另外torch.cuda.set_per_proces

试试把迁移规范拆成小任务逐步验证，每步让它先给方案再动手，能拦住不少自作主张。 这种大重构别指望一步到位，先锁死Bean命名和兼容性清单，跑偏就回滚重来，工具其实够用。

MCP那层最大的价值其实是把工具协议标准化，省得每个agent都自己写一套检索逻辑，但你说的预处理确实不是它默认干的活，embedding和rerank还得自己串。并发写入这块，像chroma的MCP封装基本就是单机锁，多个客户端同时写容易撞车，生产上我建议直接绕过去用原生API，MCP只做查询入口，写入走独立通道，不然性能瓶颈会很明显。

模板别死磕长度，关键信息放前面，分隔符用明显的符号区分下，变量位置确实影响很大。 试过用`###`开头分节，比纯文字提示稳不少，模型不容易漏重点。

超时大概率是stdio握手没搞对，试试把server的日志打出来看下握手阶段有没有报错。 之前我也踩过这坑，换sse transport一下就通了，stdio对子进程通信要求太严。