网络保持在线求生记

我也是从玄学走过来的，现在固定用一套带断言脚本的测试集跑回归，改prompt至少心里有底。 结构化模板确实能救急，但领域一变还是得重调，不如把few-shot例子也纳入版本管理，每次改动都记录差异。

我之前也踩过这个坑，折腾了快一晚上，最后发现是FastMCP的SSE模式和Cursor的兼容性问题。你用的SDK 1.2.0，Cursor 0.45.x这个组合我印象里确实有bug，尤其是SSE那边，Cursor自己实现的客户端对事件流的解析有点严格，稍微慢一点就报connection closed。建议你试试两个方向：一是把FastMCP的日志级别调到DEBUG，看看服务端是不是在等什么请求头，

我一般把细节写到能约束输出格式就停，再多就容易绑定思路，改起来头大。中途跑偏直接开新会话，省得连带旧上下文一起带偏。

3060的6G显存跑7B int4确实很勉强，我自己的2060s 8G跑qwen2.5-7b-q4都要开15层gpu，剩下全塞内存，速度和你差不多。关键点是ollama默认只分4g显存，你得用OLLAMA_MAX_LOADED_MODELS或者环境变量把显存给满，llama.cpp那边建议试下-q4_k_m加--cache-type-k q8_0，能省不少内存带宽。不过说实话，就算调好了，这个规模

我之前也踩过类似的坑，核心问题是你把微调和RAG的职责搞混了。RAG里检索是给你提供事实锚点，而微调应该重点训练模型怎么去判断、取舍和重组这些片段，而不是让它背新知识。我试过用纯“问题+片段+答案”构造数据，结果模型确实容易把片段里的噪声也学进去，尤其当检索结果里混着相似但不相关的产品FAQ时，幻觉特别明显。 后来我改成在训练数据里故意加入“错误检索”或“无关片段”，并让标准答案明确标注“不采用

试试把需求拆成小函数让AI单独补，圈中代码用// TODO标记，我这么干后成功率明显高了。

试下llama.cpp的Q5_K_M量化吧，4bit确实掉点明显但5bit会好很多，配合mmap把模型映射到内存，13B大概需要16G内存，速度虽然比不上纯显存但比offload流畅。另外vLLM对显存要求其实更高，还不如直接上AWQ或GPTQ量化版模型，很多社区已经调好的权重直接下载就行。预算有限的话最近二手3090价格降了不少，两张24G拼起来跑13B很舒服，比单卡4090体验好太多。

这速度确实不太正常，我怀疑瓶颈不在vLLM本身而在数据预处理或模型配置上。你试试把--max-num-seqs调低点，比如32，有时候并发太高反而会拖慢单请求延迟。另外Qwen2.5的7B本身对A100来说应该很轻松，20t/s更像是被CPU喂数据卡住了，检查下dataloader是不是单进程。docker的话确实会有轻微损耗，但一般不到5%，不太可能是主因。你量化是用的AWQ还是GPTQ？如果只

这问题太典型了，我上周刚踩过同样的坑。核心在于MCP的输入得是“对齐后”的字典，而不是手动拼tensor，建议在自定义Dataset的__getitem__里分别处理好图像和文本，最后统一返回{'image':..., 'input_ids':..., 'attention_mask':...}，这样collate_fn用默认的就行。另外爆内存八成是你把整个数据集都load进来了，试试用Image