阿前端日常

loss降到0.3不代表模型学会了，很可能只是记住了训练集里的表面模式。你用的格式是“问题描述+代码段”，但推理时有没有把同样的prompt模板拼进去？模板不一致的话模型直接懵掉。另外LoRA rank别设太低，代码任务对容量要求比闲聊高不少，试试调大rank或者多训几轮看验证集表现。全是括号和缩进的话，也可能是max_length截断把代码切碎了，检查下样本有没有被腰斩。

回复: 微调Llama3.2-3B做代码生成，loss降到0.3但输 1天前

我前段时间也踩过这个坑，最后选的是容器里直接跑Python脚本走HTTP，没硬上ONNX。原因是我的模型里有自定义算子，导出ONNX时各种不支持，折腾两天不如直接FastAPI包一层省事。MCP那边其实不关心你后端是什么，它只要一个能被调用的tool接口，schema对得上就行，所以你完全可以把PyTorch推理服务单独跑，MCP server只做转发和参数校验。TorchServe我也试过，它的

回复: MCP服务器用PyTorch还是TF后端？搞深度学习的MCP 2天前

我之前也卡在这好久，后来发现是Python环境的问题，Cursor那边默认用的python可能不是你装了mcp库的那个。你试试在配置里写全绝对路径，比如`/usr/bin/python3 /path/to/server.py`，或者直接用`which python`查一下路径填进去。另外stdio模式下建议把server里的print都去掉，或者重定向到stderr，不然输出混进协议流里工具列

回复: MCP服务器接入Cursor后工具列表是空的，有人遇到过吗？ 26天前

说实话我跟你情况差不多，最后选了Chroma，主要是MCP Server本身定位就是轻量工具，再扛个Milvus运维成本直接翻倍。不过你说的并发问题确实存在，我压测过，Chroma在50路并发写入时延迟会飙到2秒以上，但单机场景下日常用其实感知不强。Milvus我也试过，性能确实稳，但光是起Docker Compose那一堆依赖就够劝退的，而且对内存要求不低，小机器跑起来有点吃力。如果你只是单用户

回复: MCP Server里用向量数据库存记忆，Milvus和Ch 26天前

发表的评论