移动开发学习簿

之前也踩过这个坑，MCP拉起进程时环境变量确实不会自动带上。我后来是在tool里直接拼好torchrun命令，把rank和world_size显式传进去，再用env参数手动set MASTER_ADDR和MASTER_PORT，基本能跑通。不过FSDP的话最好还是走它自己的launcher，别硬塞进MCP里，不然调试起来很痛苦。 另外可以试试在MCP server端把启动逻辑封装成一个脚本，里面

试试让模型先引用原文再回答，强制它基于检索片段输出，比单纯说“基于文档”有用多了。

说实话你这个体感挺准的，七八个MCP全挂上确实会拖慢响应。我自己试过，问题主要出在每次对话时客户端都要把所有server的tools定义拉一遍，而且模型在推理时得从一大堆工具里挑，token开销和决策时间都是实打实的增加。不过影响大小确实跟server质量关系很大，有的server响应快但工具定义写得冗长，有的server本身网络延迟就高，一次工具调用卡两秒，累计起来就很明显。 我现在的做法是给

我之前在MCP上跑DDP也踩过一模一样的坑，最后发现是环境变量里少了MASTER_ADDR和MASTER_PORT，MCP的容器默认不帮你设这些，torchrun虽然会自动生成但和mp.spawn的初始化逻辑对不上，所以两个都卡住。你那个“rank不匹配”八成是你在代码里手动设了rank，但MCP的调度器又传了一套自己的RANK变量进来，两边冲突了。我后来干脆在init_process_group

显存碎片化也会导致OOM，试试把pytorch的缓存清一下或者换旧版vLLM看看。 清完显存只撑半分钟大概率是KV Cache预分配爆了，设个max_model_len限制下序列长度试试。

14B int8的KV Cache确实是个大头，十几个并发带长上下文的话单卡A100很吃力，建议直接上两张卡张量并行，比强行量化到AWQ对效果影响小得多，毕竟员工问知识库要的是准确率。RAG拼接这块可以试试把检索片段和最近几轮对话放一起，历史太远的部分单独缓存成摘要，别全塞进上下文里，能省不少显存。另外vLLM的max_num_seqs别只调数值，配合gpu_memory_utilization和

本地7B做agent确实难受，速度和function calling都不靠谱，我们试过也就跑跑demo图个乐。 真上生产还是得API，本地那套适合对隐私特别敏感的场景，但调参调得人想砸电脑。

试试把checkpointer的配置改成每次节点执行完强制快照，或者直接用MemorySaver，死锁多半是边逻辑有环，加个超时中断能救急。

同感，信息过载会让模型注意力分散，它会把模板里的内容当成“权威背景”去迎合，反而忽略了用户当下的真实意图。我之前也试过把仓库状态全塞进去，结果它连我让改个变量名都要按模板格式输出，后来只保留跟当前任务最相关的几条动态信息，效果立刻正常了。现在我会把模板拆成静态规则和动态槽位，动态部分只放跟任务强相关的字段，并且每次调用前明确标注哪些是示例、哪些是必须执行的指令。

召回率卡在60%多半不是索引的锅，IVF_FLAT参数看着没啥大问题，建议先拿欧氏距离直接暴力检索对比一下，如果暴力检索也这样那就是特征本身的问题了。ResNet50提特征时注意一下是否用了倒数第二层输出，并且图片resize和归一化要一致，不然特征分布会很散。数据增强个人感觉对检索任务影响不大，但可以试试对特征做PCA降维或白化，有时候能明显提升召回。另外20万量级换HNSW收益不大，还是先查查

这问题太真实了，Cursor有时候确实爱“自作主张”加戏，尤其是泛型那块，明明JS项目它非要整TS那套。我后来直接在项目根目录放了个`.cursorrules`文件，把“禁止使用TypeScript、只用函数组件、不要加未要求的props”写进去，情况好多了。另外prompt里强调“严格按需求实现，不要额外功能”，它基本就收敛了。你试试，比改需求省心。

我之前也踩过这个坑，bge系列微调对负样本特别敏感，随机采样基本等于让模型学了个寂寞。你试试把hard negatives加上，比如从相似法条里找那些案由相近但判决结果不同的样本，效果会明显不一样。另外温度和in-batch negative的规模也很关键，我当时把温度从默认的0.2调到0.05，检索精度直接涨了三个点。 还有个容易被忽略的点是训练数据的构造粒度，法律问答对如果只抽“问题-答案”

我之前也踩过DDP卡初始化的坑，多半不是MCP的锅，而是glibc或者NCCL的通信超时设置问题。你可以试试在启动命令前加export NCCL_DEBUG=INFO，这样能看到具体卡在哪个rank的socket连接上。另外如果用的是torchrun，记得检查一下env://这个默认初始化方式跟你的MASTER_ADDR是不是匹配，有时候手动设了环境变量反而会让它冲突。还有个容易忽略的点，单机多卡

我用3060跑8B也踩过同样的坑，fp16基本别想，4-bit能动但慢得怀疑人生。后来试了vLLM确实有改善，不过它主要优化的是吞吐量，单条生成的延迟反而可能更高，你这情况不如直接上Ollama，它对显存和内存的调度更灵活，还支持offload到CPU，虽然慢点但至少不崩。量化级别建议别死磕4-bit，可以试试Q5_K_M或Q6_K，中文效果会比Q4好不少，尤其涉及成语或专业术语时，掉点能感觉到。

说实话这问题我太有同感了，GPT写脚本就是“看起来对，跑起来崩”的典型。我后来学乖了，直接在prompt里要求它把边界情况列成清单写进注释，比如“明确拒绝处理子目录”和“特殊字符用ascii编码兜底”，比单纯强调“不递归”管用得多。另外建议你让它先输出伪代码逻辑，确认没坑了再要完整实现，能省不少改bug的时间。

我之前也卡在这块好久，后来发现chunk size真得看文档结构，比如合同条款那种逻辑块就适合大chunk，但问答型文档小chunk反而准。overlap我一般设10%-15%，主要为了保住边界语义，但别超过20%，不然检索时重复内容太多会干扰相关性排序。另外你top-k=5的话，试试把chunk调回700左右，再配合rerank，比死磕size管用。 --- 我自己的经验是别指望一个固定值通

这问题我太熟了，之前也是把history全塞system prompt，聊到后面token爆了不说，模型还分不清哪句是当前问题。现在我是用滑动窗口+摘要双轨，最近3轮对话原文留着，更早的让模型定期总结成要点。另外LangGraph的checkpoint确实省事，配合Redis存状态，跑个20轮基本没问题，你可以试试把记忆拆成短期buffer和长期向量库分开管理。

试试把记忆和检索结果做个滑动窗口截断，只留最近几轮和top-k片段，16G跑7B量化版能稳不少。

试试在对话里直接说“只输出核心代码，不写注释”，然后让它先跑通再精简，不行就换Claude模型试试。

我之前也踩过类似的坑，LoRA微调后指令跟随能力反而退化挺常见的，尤其学习率2e-4对7B来说偏高了，容易破坏基座原有的对齐能力。你可以先降到5e-5左右，用更少步数试试，另外微调数据如果风格和你的prompt模板差异太大，模型会“学歪”掉。建议先保留原版Instruct模型，单独用few-shot调优prompt，微调模型专门跑你数据里的任务格式，别混着用一套模板。重训之前，不如先检查下微调数据