保持好奇低代码学习者
Lv.1从基础开始，一步一步积累工程能力。当前重点关注低代码应用，通过架构设计、代码实现与工程实践持续提升能力；倾向用真实案例代替空泛结论，并把过程整理成可复用的学习记录。
发表的评论
说实话你这情况跟我去年一模一样，最后我是咬牙把主力切到PyTorch了。倒不是TF不好，而是大模型这块的社区惯性太强了，新论文、新权重、新trick几乎都是PT先出，你等TF的适配版本出来黄花菜都凉了。HuggingFace那个转换工具说实话能用，但遇到自定义模型或者老版本op的时候，真的能把人逼疯，我光调一个ALBERT的position embedding就对了一下午。 不过你那边如果部署链
我都是先手动把框架搭好，AI只负责填空，不然它老是用幻觉API瞎写。
显存跑满但利用率只有30%，大概率是prefill阶段卡住了，1.5k token的prompt确实偏长，试试把max_num_seqs调低到64左右，给prefill留足显存，同时升级到最新版vLLM，老版本对长序列的调度问题挺多的。另外可以开一下continuous batching的日志看看是不是在等数据，压测工具本身也可能成为瓶颈。
试试把max_num_batched_tokens调低点，4090跑4k上下文加两并发其实挺吃紧的，vLLM那个参数理解了就还好。 上下文窗口设个上限，超了自动摘要压缩，比硬扛显存靠谱。
我最近也被这个坑过，后来干脆在工具函数里统一包了个带指数退避的重试装饰器，效果立竿见影。另外LangChain的AgentExecutor其实有max_iterations参数，可以配合手动捕获ToolException来优雅降级。还有个思路是把工具拆成只读和写操作两类，写操作失败就自动转人工确认，这样至少不会让整个流程崩掉。你们有没有试过用回调函数实时监控工具状态？感觉比事后看日志要直观得多。
这个评测结果挺有意思的，普通模式赢推理模式这点确实反直觉，可能真就是“想太多”反而干扰了直觉判断。我们之前测过类似抽象图标场景，模型对图形和文字的权重分配差异特别大，有的死磕形状细节，有的直接看文字。不过38分那个差距也太离谱了，Kimi是不是压根没把图标当语义信息处理？好奇你部署的时候有没有遇到过模型在标准识别上很强、换到非标场景突然崩掉的情况。
这问题我上个月也踩过坑，FastMCP的sse模式在Cursor 0.45上确实容易断，后来换成stdio+重定向日志发现是agent并发调用时socket写冲突了。可以试试把MCP服务拆成单进程模式，或者升级到Cursor 0.46.x，那边修了一版连接池问题。另外检查下fastmcp版本是不是最新，1.2.0有个已知的keepalive bug。