持续研究创新实践笔记

7B这个量级直接上FSDP吧，省显存还能提吞吐，我们实测比DDP稳不少。 FSDP调起来费点劲，但7B用DDP真容易OOM，别问我怎么知道的。

我们项目之前也踩过这坑，后来换了个思路：先粗召回，再按段落间的语义相似度做聚类，每组挑代表片段+生成摘要，最后把摘要和代表片段一起塞给模型。这样既保住关键信息，又不会爆token，实测比单纯调top_k稳很多。另外你试试用RAPTOR那种递归摘要树，对多跳问题特别管用，不过工程复杂度会高点，得看你们有没有时间折腾。

System只管定边界和引用规则，User放具体任务和格式例子，效果能稳不少。另外建议做个消融测试，一次只动一个变量，甜点都是调出来的。

大概率不是架构选错，是stdio下同步阻塞的典型问题。你工具列表能加载说明握手没问题，但执行时如果server里用了同步requests或者阻塞式DB查询，整个进程会被卡住，客户端那边等不到响应自然就超时了。建议先把server端所有IO改成异步（用asyncio + httpx），或者至少把工具调用丢到线程池里，很多这种“偶发成功”都是时序问题。SSE那边其实不用急着换，先确认下Ollama的k

本质区别在于MCP把工具调用变成了跨应用的标准协议，而Function Calling只是单机内的接口约定。 其实你纠结的点挺准的，MCP更像给工具调用加了个“通用插座”，换环境不用重写。

两张A100都OOM，多半是显存碎片化+KV cache没调好，试试开enable_prefix_caching和gpu_memory_utilization=0.9。 调完batch size响应慢是正常的，可以试试把max_model_len砍到4k，吞吐能回来不少。

大概率是模型对参数映射的理解问题，试试在tool里把参数名直接写成city并给个北京示例值，比description管用。

说实话我觉得问题可能出在7B量化版这个前提上，我自己用Ollama跑过同规格模型，量化到4bit以后逻辑连贯性掉得特别明显，尤其多步推理或者状态保持这块基本就是退化到玩具级别。你提到的索引越界和异常裸pass，我猜是模型在长序列里丢失了早先定义过的变量约束，这跟上下文窗口的有效利用关系很大。可以试试把任务拆得更碎，比如强制它先写伪代码再转实现，或者每个函数单独生成并给足类型注解，这样能稍微缓解逻辑

刚看完你的测试结果，我最近也在对比这两款模型，确实DeepSeek-V3在中文成本上优势太明显了。不过你提到多轮对话稳定性这个点我也有同感，有时候上下文一长它就开始犯迷糊，不知道后续更新会不会优化这块。 另外GSM8K成绩接近GPT-5这点挺让我心动的，毕竟我们团队预算有限，能省下不少钱。但想问问你在实际项目里，它处理那种需要深度推理的复杂问题会不会偶尔翻车？