清晨煮茶记

4张A100 80G跑70B推理确实够了，量化到int8或者fp8的话显存压力不大，但你要是想全精度+长上下文那就另说。微调是真得8张起步，光权重+优化器状态+梯度就能把4张的显存吃干净，更别提还要留batch的余量。3090组集群看着便宜，实际卡在卡间通信和显存带宽上，跑推理凑合，训练基本别想。建议先想清楚是只做推理还是后续要微调，路线不一样配置差挺多的。

3090跑7B用AWQ其实挺稳的，代码场景建议别死磕INT8，试试GPTQ的4bit 128g，质量比默认配置好不少。13B换7B我觉得不一定划算，小模型代码能力掉得更明显，还不如7B量化后多留点显存开长上下文。vLLM主要省的是并发和调度，单次生成对显存帮助有限，可以试试exllama2，速度和质量平衡得还行。

几千条数据走MCP调外部API确实得掂量隐私，不如本地脚本微调完再挂个推理工具进MCP。

口语化问题建议在User Message里做二次意图识别，System Message管不住追问跑偏。

我踩过这坑，后来改成每个Agent独立Memory，协调者只转发消息和版本号，嵌套状态再也没乱过。

先看看验证集是不是也在降，如果验证loss不降反升，那基本就是过拟合了，跟学习率关系不大。

长文档切分确实容易踩坑，光调chunk_size可能治标不治本。你可以先拿几个badcase把召回片段和原文对齐看下，大概率是切碎了语义单元，比如表格或跨段逻辑被硬拆开。我遇到过类似情况，换成按标题层级递归切分+给chunk加一点上下文摘要，召回质量明显稳了。混合检索和rerank值得加，但建议先把切分这层排查清楚，不然换retriever也是白搭。

提取任务不稳定太正常了，温度先调到0，再把输出格式用JSON schema卡死，能稳住一大半。然后别光加例子，试试把用户反馈先做一轮清洗和分类，输入质量差prompt再牛也白搭。至于微调，如果你标注数据能搞到几百条以上，小模型确实更稳更便宜，但前期还是先用prompt把流程跑通验证需求吧。

我一般会先把真实列名和几行样例数据贴进提示里，再让它写，不然它真会自己脑补字段。另外别指望一次生成就能用，拆成小函数、边跑边让它改，成功率会高很多。还有个坑是它经常忽略空值和类型转换，写完最好自己扫一遍。

我也用bge-m3搭过内部文档检索，300字带重叠这个粒度对技术文档来说有点尴尬，容易把一段完整逻辑切散。你这个问题更像是分块时没保住语义边界，比如把“参数说明”和“报错示例”混在同一块里，向量自然偏向噪声。可以试试按标题层级切，再给每块补一句上下文摘要，top-20里真正相关的排名会明显往前挪。

用checkpointer存下每步状态，并发写最好加reducer合并，不然肯定覆盖。

我也踩过这坑，LangGraph里工具节点的输入默认会吃到整段state，前一个工具的输出没清理干净就容易被下一个工具误用。我一般是在每个工具外面包一层参数提取节点，让它只从用户原始query里抽自己需要的字段，而不是直接读全局messages。另外工具返回结果最好用结构化字段存，别一股脑塞回对话历史，不然模型很容易把会议室地址当成天气的城市。

MCP主要给LLM接工具用的，跟PyTorch训练基本不搭边，别指望它替代Dataloader。

我之前也踩过类似的坑，参数串位大概率是训练数据里工具调用的样本太单一了，模型没学到参数名和值之间的强绑定关系。试试在数据里混一些参数填错的负例，让它学会区分不同字段的语义，光靠500条正例确实容易过拟合到表面模式。另外Qwen2.5对tool schema的解析可能跟MCP的定义有细微出入，你检查下传进去的json schema字段名和实际调用时是不是完全对齐了。

polars和duckdb其实都挺靠谱的，性能比pandas强不少，但小脚本确实没必要。提示词里直接写“只用pandas和标准库”就行。

我RAG和记忆也是分两个collection，RAG存知识，记忆存对话摘要加元数据，召回准多了。

8G跑7B量化确实能跑，但瓶颈不只在显存，更多是显存带宽和量化内核的效率问题，3070的带宽摆在那，4-bit下token速度上不去很正常。你试试llama.cpp的Q4_K_M配cuBLAS后端，或者换vLLM的AWQ，速度会比GPTQ好不少。质量下降可能是量化粒度太粗，可以试Q5_K_M或Q6，8G勉强够跑但上下文得压到2K以内。轻量的话Qwen2.5-3B或Phi-3-mini效果挺能打，速

官方那个Postgres MCP Server确实有点坑，客户端默认超时好像就30秒左右，复杂查询基本没跑完就被掐了。我后来换成自己写的轻量MCP server，用stdio方式，超时问题反而少了，SSE偶尔会断流。建议先查下Claude Desktop的mcp配置里能不能加timeout参数，不行就换个实现试试。

85%这个数其实不算差了，但确实卡在这儿挺难受的。你用bge-m3的话，我猜大概率问题不在向量化本身，而是chunk切分那块儿——切太碎或者跨语义边界，embedding再强也救不回来。我之前也遇到过类似情况，换了半天距离函数，最后发现是分块策略把一句话从中间劈开了。另外Milvus那边索引参数对召回的影响其实没想象中那么大，efSearch往上拉一般也就多几个点，真要往上走还得看数据本身。你测试

出海这事真不是把机器挂到速卖通上就完事了，我去年接触过一家做服务机器人的团队，光是欧洲GDPR对数据回传的限制就让他们把整个云端架构推倒重来了一遍。魔法原子这次签速卖通，渠道声量确实有了，但跨境OTA要同时满足不同国家的无线电认证和固件加密标准，这个工程量比想象中大得多。我比较好奇的是他们的动作库是怎么做本地化适配的，日本那边确实对关节柔顺度特别敏感，之前有朋友在东京做测试，同样的抓取动作在欧洲跑