解决方案增长记

16G显存跑14B的int4量化基本能稳住，我之前用4090锁16G试过Qwen-14B的AWQ，推理速度大概20 token/s左右，文档问答完全够用。gguf对新手更友好，llama.cpp直接拉起来就行，不用折腾环境，awq部署稍微麻烦点但速度快一些。4060Ti的话建议先试Qwen-14B的Q4_K_M，爆了就降到7B，别一上来就冲32B。另外上下文长度也吃显存，文档问答记得控制下chun

握手失败大概率不是协议版本的问题，MCP这块兼容性其实没那么脆。你Docker里跑的server连宿主机vllm的时候，容器内localhost是回环到容器自己的，得换成host.docker.internal或者宿主机实际IP，这个坑我踩过。另外看下vllm启动时有没有加--enable-auto-tool-choice和对应的tool-call-parser，Qwen2.5的工具调用得显式开，

我现在的做法是把Claude Code严格限制在“看不懂的脏活”上，比如跨十几个文件追一个bug、或者把一坨意大利面逻辑整个重写。改样式、加个按钮、调个接口字段这种，老老实实退回Cursor的Tab补全，豆包或者Haiku也能顶一顶。真让Claude Code全程跑，它每次都会把整个仓库结构重新嚼一遍，那个上下文重复读取代价太大了。 任务拆碎确实有用，但关键是拆的时候得让它一次性只盯住两三个文件

gpu-memory-utilization默认0.9，你拉到0.95试试，KV cache能多分点。

我之前也踩过这个坑，后来发现多半是工具返回结果太长把上下文撑爆了，模型就开始胡言乱语。你可以试试在每个工具返回后做一层摘要压缩，别把原始JSON直接塞回去。另外LangChain的AgentExecutor确实有点黑盒，换成LangGraph自己画状态机后可控多了，卡死的情况基本没再出现。

你这个情况我去年做内部wiki问答时也踩过，几乎一模一样的坑。后来发现核心问题可能不在rerank，而是召回阶段的向量空间被“历史版本”“制度附件”这类高相似低信息量的chunk污染了，bge-m3对长文本里这种近义噪声本身就比较敏感。我试过换gte-large，确实能压掉一部分，但代价是推理慢了不少，而且对内部术语的适配未必比bge好多少。混合检索提升不明显，很可能是因为BM25的权重没调好，或

小项目直接Chroma，并发高就换Milvus，别纠结。

我也碰到过这情况，后来发现光靠prompt真的不太够。模型天然有“把话说圆”的倾向，你越强调不知道，它反而可能更想证明自己知道。我的经验是检索后加一步相关性过滤，比如算个相似度阈值，低于阈值就直接短路返回不知道，别给LLM发挥的机会。另外prompt里最好把“不知道”的判定标准写具体点，比如“只有当文档明确提到X时才能回答”，不然模型对“没相关信息”的理解跟你差很远。

先加个rerank试试，比换embedding便宜多了，你这情况八成是召回太粗。

16G的话可以试试把KV cache量化，上下文别拉太长，记忆用摘要压缩，别全塞进去。

思维链这东西确实挺玄学的，我自己的经验是zero-shot CoT对复杂推理任务才比较稳，像摘要这种偏抽取型的任务，模型很容易觉得没必要绕弯子。你可以试试在指令里强制它先输出步骤再给结论，比如加个格式约束“第一步…第二步…最后总结”，不按格式就重试。另外few-shot确实管用，给两三个带推理过程的例子，比光说“step by step”强多了。还有个可能是你代码段落太短，信息量不够，模型直接概括

1000条可能不够，而且微调LLM改不了检索本身，得看rerank那块。

16G显存跑7B模型做Agent确实挺吃紧的，尤其是你还想留出空间给多轮对话的上下文和工具调用的中间结果。我之前也踩过类似的坑，后来发现把模型换成Qwen2.5-1.5B或者Phi-3-mini这种小模型，配合vLLM或者llama.cpp的量化推理，显存占用能压到4G以内，速度也还能接受。不过小模型在工具调用的格式遵循上确实容易翻车，得靠few-shot示例或者更严格的输出解析来兜底。另外你Ag

3080 10G跑7B的Q4_K_M按理说不至于这么惨，2-3 token/s明显不对劲。先确认下是不是没开flash attention，还有gpu layers是不是只offload了一部分到显卡上，剩下全压CPU了，那速度肯定崩。Q4到Q8主要是显存和精度的权衡，Q5、Q8速度未必更快，反而可能因为权重更大导致带宽吃紧。另外你context砍到1024还OOM，建议看看是不是KV cache

loss降不代表生成对，LoRA很容易过拟合到短回复模式，重复“嗯嗯嗯”就是典型退化。先别急着调rank，重点查数据格式和chat template有没有对齐，Llama3的special token用错了推理肯定崩。学习率2e-4对LoRA偏高了，试试1e-4或5e-5，再跑一个epoch看看。冻结embedding影响不大，但中文医疗词表覆盖本来就弱，可以考虑扩词表或者换Qwen试试。

合并权重理论上不该多占6G，除非你vLLM的max_model_len或者gpu_memory_utilization没调。我之前也碰到过，最后发现是vLLM默认按最大长度预分配KV cache，跟LoRA没关系。你可以试试把max_model_len设小一点，或者gpu_memory_utilization降到0.85看看还OOM不。

你这个情况挺典型的，AWQ 4bit权重确实只有6G左右，但Agent场景下KV Cache才是吃显存的大头。多工具调用意味着system prompt巨长，再加上每轮工具返回结果都往context里塞，KV Cache涨得比你想象快得多。可以试试限制max_model_len、开enable_prefix_caching，或者用vLLM的gpu_memory_utilization留点余量。碎片

表格数据确实容易被忽略，尤其是PDF解析后行列结构丢失，模型就很难对应上。建议先检查chunk切分有没有把表格拦腰截断，可以按标题或段落做语义切分，别单纯按字符数切。另外试试让模型先输出原文中的表格片段再提取指标，或者用结构化输出约束字段，能减少指标串行的问题。

我一开始也这样，后来发现光说“健壮”太虚了，模型根本不知道你指什么。你得把需求拆开，比如“用os.rename前先判断文件是否存在、遇到同名文件自动加后缀、用try except包住每个重命名操作”。写清楚边界条件和期望行为，代码质量立马不一样。你可以把自己当产品经理，别当许愿池。

我微调的时候也踩过这坑，后来干脆在训练数据里随机丢掉模板前缀，让模型见过各种“裸问”和带语气词的版本，鲁棒性确实好不少。但模板也不能完全扔掉，推理时最好保留一个轻量系统提示兜底，不然输出容易飘。多轮上下文一定要拼进去训，单轮训出来的模型到对话里真的会断片，我一般会把最近2-3轮拼成一条样本，效果比纯单轮稳很多。