前端学习簿

我也有过这个阶段，后来发现锅主要在用法上。Composer模式特别容易“过度发挥”，你让它改个小bug，它觉得整个文件都有优化空间，diff自然就炸了。我的习惯是改bug时切回普通Chat或者Inline模式，只框选要改的那几行，别给它全局上下文，它就老实多了。至于类型体操和helper函数泛滥，其实是模型在“炫技”，你可以在rules或者prompt里明确写一句“保持最小改动，不新增抽象，除非我

两个都用过一段时间，Milvus功能确实全但部署运维偏重，跑个单机版资源占用就挺吓人，小团队容易劝退。Qdrant倒是轻量好上手，Rust写的性能也不错，不过生态和文档相比还是薄一些，遇到偏门问题查资料费劲。我们后来是按数据规模和团队运维能力来选，中小项目直接上Qdrant省心。你们场景大概多大数据量、对过滤查询要求高不高？这块差别挺影响选型的。

JSON传tensor确实坑，先换二进制流试试，顺便看下tool call是不是串行卡住了。

学到了，感谢分享！

VLLM那套显存管理跟Transformers完全不是一个思路，它默认会把gpu-memory-utilization乘出来的显存拿去做KV cache池，权重加载完剩下的全预分配掉了，所以你看日志会觉得“怎么全塞进去了”。4090跑7B其实够，但Qwen2.5默认max-model-len可能是32768，KV cache按这个长度预分配就很吓人，你试试显式加max-model-len=8192

远程工具参数格式差异大，建议微调数据直接采真实MCP请求日志，别用样例凑。

学到了，感谢分享！

写得挺好，建议补充一些性能数据。

写得挺好，建议补充一些性能数据。

这个思路不错，收藏了。

有没有更详细的教程推荐？

LangChain确实重，我后来直接拿它的core模块加自己写的状态机，清爽多了。

5000条数据做LoRA其实够了，问题可能出在lr太高，2e-4对7B来说容易把预训练能力冲掉，试试降到5e-5或者1e-4。错别字被学进去基本就是数据没清干净，这个锅数据得背，业务对话里那些口语化噪声最好过滤一遍。另外LoRA本身不用冻embedding，它只更新低秩矩阵，但如果你还加了embedding的adapter那另说。垂直任务不一定非要先SFT，但指令数据格式得对齐，不然模型不知道你要

Q4_K_M量化对7B模型的影响其实挺明显的，尤其是指令遵循这块会打折扣。你试试把prompt写得更具体点，比如直接说“只要代码不要注释，不需要错误处理”，比泛泛地让它写函数效果好很多。另外Ollama默认的temperature和top_p可能不太适合代码任务，调低一点会稳不少。官方演示大概率用的是FP16或者Q8，本地量化版有差距也正常。

我之前也踩过这个坑，全局dict绝对不能用，并发下必炸。后来我是把状态抽到一个带TTL的session store里，用session_id关联，MCP这边只传id不传状态，推理层自己去取。MCP的Resource其实挺适合挂这种状态快照的，但别指望它帮你做生命周期管理。纯函数化最干净，代价是每次要序列化反序列化，延迟会上去一点，看你能不能接受。

几十万切片其实不算大，Chroma 和 Milvus 都不是唯一解，你可以看看 Qdrant 或者 LanceDB，前者单机部署比 Milvus 轻不少，后者直接嵌进应用里连服务都不用起。查得不准大概率不是向量库的锅，Chroma 默认的 HNSW 参数和距离度量你得确认下，cosine 和 l2 选错结果会差挺多。另外 embedding 模型对中文知识库影响真的很大，bge-m3 或者 gte

我现在的做法是折中，全局system prompt只管角色设定和整体输出风格，每个步骤的prompt只写这个步骤独有的约束和增量信息，那些跨步骤共享的格式定义抽出来做成模板变量注入进去，这样就不会每个步骤都重复解释一遍。你提到的规划输出格式到选工具又得重新说，本质上是没有把中间数据结构定死，我一般会先定义好一个类似JSON schema的中间表示，规划步骤只负责填这个结构，后面步骤直接消费，不用再

应用开发直接上vLLM就行，torch.compile坑多收益不稳，别折腾。

24G卡跑7B的LoRA，batch size开到2就爆其实挺常见的，尤其你序列长度要是拉到512甚至1024，激活值占的显存比想象中猛。我一般会把per device batch size压到1，然后靠gradient accumulation把等效batch凑到16或32，这样显存稳很多。不过gradient accumulation steps调大本身不会直接拖慢收敛，真正的问题是你等效ba

V100不支持AWQ，换GGUF跑llama.cpp吧，16G稳得很，就是慢点。