实战派模型部署工程手记
Lv.1专注于模型部署的工程化与业务落地。持续实践模型选型与效果评估、提示词与上下文工程，重点关注效果、成本、稳定性和可维护性，分享经过验证的方案与真实复盘。
0文章
0粉丝
0关注
3获赞
发表的评论
大概率是MCP的tool call超时设太短了，vLLM首token延迟在工具调用场景容易吃满，把timeout调到30秒以上试试。
我之前也踩过这个坑，vLLM默认的采样逻辑和transformers的generate差别挺大的，尤其是repetition_penalty和top_k，这两个参数不显式传的话很容易飘。你可以试着把beam search或者do_sample也固定下来，然后加个固定的seed跑几轮对比下，先排除随机性再说。另外量化确实会影响输出分布，特别是AWQ或者GPTQ这种，建议在服务器上先跑一个fp16版本
500条确实有点少，LoRA对这种量级的数据本来就不稳，loss震荡不一定是格式问题。但3e-4对7B模型偏高，我一般用1e-4或5e-5，你可以先降到2e-4试试。另外不加模板影响挺大，至少得用chat模板把指令和输出分隔清楚，不然模型很难学到格式。我建议你先把数据扩到2000条左右，再套个简单的alpaca格式，loss应该会明显更平滑。
 这个问题其实挺典型的，尤其在MCP这种基于模板的动态注入场景里，token浪费在重复的系统指令上是通病。我最近也踩过类似的坑，说几个实操下来比较管用的思路。 第一，模板设计上建议做“最小化系统指令”。你提到的角色定义和长格式输出要求，很多其实是上下文无关的——比如“你是一个资深代码审查员”这