屏幕前煮茶

说实话你这个问题我太有同感了，之前我在单张A6000上跑13B也遇到过类似情况，后来排查了半天发现是vLLM的默认page大小和显存碎片在作祟。你双路3090虽然显存够，但PCIe带宽和NVLink的利用率可能根本没跑满，tensor_parallel设成2反而会让通信开销抵消掉计算加速，试试把TP关掉单卡跑，或者换成张量并行但把gpu_memory_utilization调低点给KV cache

这精度掉的幅度确实有点大，不太像是单纯量化或算子转换的正常损耗。我之前也踩过类似的坑，最后发现是torch.onnx.export里没把training参数设为False，导致BatchNorm层带着训练时的统计量一起导出，你可以先检查下这个。另外AdaptiveAvgPool在某些opset版本下会展开成多个slice+reduce，数值上会有微小误差，但一般不至于掉4个点。建议你导出后先用on

这问题我踩过坑，建议embedding单独起服务，别塞MCP Tool里。不然每次调工具还得等模型加载，延迟直接翻倍，尤其个人知识库文档多了之后特别明显。Qdrant那个插件方案我也试过，配置起来有点麻烦，而且它主要是做过滤用的，跟你本地切片后的语义搜索场景不太匹配。我是用FastAPI包了个embedding接口，MCP Server启动时连一次，后面查询直接复用，延迟能控制在几十毫秒。不过你文

我们之前也纠结过这个问题，最后折中做了：一个主Agent做意图识别，底下挂了几个轻量级子Agent，每个只负责带检索策略和输出模板，不搞复杂推理。成本没加多少，但准确率确实上去了，尤其是HR制度那种结构化问答，子Agent直接走字段匹配比通用RAG稳得多。不过路由别写太死，留个兜底给主Agent，不然新文档进来容易漏。

3090也就24G显存，跑7B全精度本来就很吃紧，max_num_seqs别拉那么高，10并发的话调到32-64试试，prefill和decode阶段显存占用差很多。另外建议直接上AWQ或GPTQ量化，4bit下显存能省一半，vllm对量化支持也成熟，基本无损。还有你gpu_memory_utilization=0.8是不是给KV cache留的空间不够，可以试着降到0.75给模型腾点余量，别让v