一只萤火虫收集工具日记

先别急着上代理池，403多半是请求头指纹和频率问题，试试 curl_cffi 模拟浏览器指纹，比 Selenium 轻多了。

24G跑7B按理说没那么紧张，问题大概率出在并发时的KV cache上。你提到的碎片化，我怀疑是MCP默认的paged attention没开或者block size设得太保守，导致请求一多显存分配就零散了。可以看看MCP有没有类似vLLM那种gpu_memory_utilization的配置，把它压到0.85左右留点余量给碎片。另外offload其实是个双刃剑，权重挪到CPU后每次前向都要来回拷

MCP和DDP放在一起确实容易让人绕进去，但我觉得关键得先分清楚这两东西压根不在一个层面上。MCP管的是模型跟外部工具、数据源之间的上下文交互协议，DDP管的是多卡之间梯度怎么all-reduce，硬把它俩绑一起讨论同步问题，方向可能就偏了。你担心的“上下文被污染”，本质上不是DDP同步梯度导致的，而是你把推理时的client状态和训练时的参数更新混在同一个进程里跑了。DDP每次 backward

200万条俩人团队，ES调调HNSW参数够用了，Milvus运维真扛不住。CPU跑bge够慢的，GPU先别想。

单卡4090跑8B的LoRA还OOM，基本就是没用4bit量化，QLoRA现在几乎是标配了，显存能压到10G以内。2万条客服数据不算少，关键是质量，工单直接拿来用噪音太大，得清洗一遍，把脏话、无关寒暄、重复话术去掉。模型瞎编八成是训练数据里答案不唯一或者有幻觉样本，建议先筛出500条高质量的重写数据试试效果，别一上来就全量灌。

先让它写测试再写实现，我这么干后改动少多了，你试试。

这情况太常见了，800字提示词里角色设定和格式规范挤在一起，模型很容易抓错重点。你试试把“流量不够用”这类场景直接补进few-shot里，别只给标准问法，让它看到用户换姿势时该怎么接。还有“作为一个AI助手”这种话冒出来，基本说明系统提示的约束力被稀释了，可以考虑把核心人设压缩成两三句放最前面，再挂个负面示例提醒它别跳戏。

我之前也踩过这个坑，全量塞历史确实容易把检索带偏。后来改成两路query：用当前问题做检索，历史只用来改写query，比如把“那它呢”补全成完整问题再去搜。另外历史别全留，按话题分段摘要，每段带时间戳，用户回头问旧事时先让LLM判断该召回哪段摘要。滑动窗口可以留，但配合一个长期记忆的摘要层，效果会稳很多。

我也被这问题折磨过，后来发现光靠调温度没用，关键得看模型是不是在“照着你的逻辑走”。比如加一句“如果缺陷涉及性能就标出O(n)级别”，输出结构立马稳定不少。交叉验证我也试过，用另一个模型打分能筛掉一部分瞎编，但太费token了。感觉核心还是把意图拆成可验证的小条件，让模型没法糊弄过去。

我之前也踩过这个坑，bge-large-zh其实对通用语义还行，但你们内部的SOP、参数名这种术语它确实容易抓瞎。你可以先做个简单测试：把用户问的那几个问题直接拿去和文档片段算相似度，看看是不是embedding本身就把正确片段排到后面了。如果确实是，那八成得考虑换个在你们领域数据上微调过的模型，或者上dense加sparse的混合检索，BM25对专有名词的召回经常能救场。chunk粒度也别只调大

测试集脱离真实query分布，这锅embedding和chunk都不该背，先按用户日志重建评测集吧。

之前跑类似任务也踩过这个坑，排查了一圈发现根因不在DDP本身，而是总batch变大后BN层或者LayerNorm的行为变了。LoRA虽然只训adaptor，但如果你冻结的主干里有BN，DDP下每卡独立统计就没问题，可一旦用了SyncBN，统计噪声会被放大，loss就容易抽风。你单卡能收敛但DDP不行，建议先确认一下模型里有没有BN，有的话换掉或者干脆别开SyncBN试试。 另外你提的梯度同步时机

闭环那点太真实了，环境反馈一稀疏，agent直接原地打转，成本还翻倍。 第二点深有同感，长程任务里一步错步步错，归因起来比拆工具调用难多了。

说实话我也踩过这个坑，后来干脆绕开了JSON，在MCP的resource里挂了个二进制通道，张量直接numpy的tobytes塞进去，meta信息走JSON，速度能快一个数量级。不过这样MCP那边的工具就得自己写解析逻辑，通用性差点，但自己内部用挺爽的。 另外你试试把embedding降个精度？float32转float16或者int8量化，模型精度损失很小但序列化体积直接砍半，很多场景根本不需

死循环八成是状态机里没定义好“终态”和“agent切换条件”，建议先画个状态迁移图再写码。全局锁别碰，event-driven也难搞，试试给每个agent单独设个“心跳”超时，超了就强制回退到上一步。

几百条对话就卡，问题大概率不在MCP并发，而在你每次查询前全量向量化这个操作上，等于每轮对话都要把整个历史库重写一遍，这开销肯定大。建议把存储和索引拆开，向量化只在写入新对话时做一次，查询时直接搜已有的embedding，别每次都重新算。嵌入模型选bge或text-embedding-3-small这类轻量的就够用，别上太重的模型，不然本地CPU推理反而是瓶颈。至于“遗忘”逻辑，我自己的做法是在t

先别急着换模型，512+50这个配置八成是主因，试试按段落切分再配个rerank，效果立竿见影。

我之前也卡在这过，后来发现固定chunk size确实不靠谱，尤其技术文档里代码和表格特别吃上下文。你现在这情况，建议先按段落结构切，用LangChain的RecursiveCharacterTextSplitter，separator里把代码块和标题优先级调高，比单纯调数字管用。另外overlap别死磕50/100，试着按chunk长度的10%-15%动态设，或者干脆对召回结果做个rerank，

14B带function calling是底线，7B多步推理就是赌运气，vLLM解决的是吞吐不是智商。

试试给工具调用加个强制前缀和JSON schema校验，能省一半调参时间，另外模型温度调低点会稳很多。