微光听风记

5-7 tokens/s 确实有点慢，4080 跑 4bit 7B 不该是这个水平。llama.cpp 的话先看看是不是没编译 CUDA 支持，或者 n_gpu_layers 没拉满，另外线程数别设太高，8 核左右就够了。想降延迟可以试试 vLLM，PagedAttention 对单卡挺友好，就是 16G 跑 4bit 7B 得把 gpu_memory_utilization 调好。这卡带 7B

top_k设10确实容易混进噪音，加个rerank基本是标配了，bge-reranker或者cohere的都不错，能砍掉一半不相关的。不过你chunk 512可能偏大，报销流程这种问题往往就藏在一两句话里，试试拆小一点再配个sentence window检索。embedding模型也得看领域，通用模型对内部术语经常抓不准，换个在业务语料上微调过的会稳不少。

14G确实偏高了，gptq权重本身占不了多少，大概率是KV cache被max_model_len和并发撑起来的。你可以试试调小gpu_memory_utilization，再拿vLLM启动日志里的显存分配报告看看，它会明确列出权重和KV cache各占多少。另外确认下是不是加载时没真正走到int4 kernel，有时候量化配置没对会退回fp16跑。

每个prompt重载模型肯定爆啊，先把模型加载挪出循环，inference_mode和no_grad都行，cache清干净再试。

两个都跑过，说点实在的。80万这个量级其实Qdrant完全够用，混合检索的延迟控制得挺好，filter走payload索引基本不会拖后腿。Milvus功能确实多，但部署那套依赖etcd、MinIO、Pulsar的组合，小项目维护起来真挺累的。至于10亿级，Qdrant单机肯定顶不住，但那时候你早该分片了，跟选哪个关系不大。K8s除非你本来就有集群，不然为了这点数据专门搭一套纯属给自己找活干。

你这个问题大概率不是检索器被带偏，而是LoRA微调让生成模型学会了“抄训练集里的答案”，反而不太依赖检索回来的内容了。3:1的配比确实容易让模型走捷径，问答对占比太高，它就会倾向于背答案而不是真正去读检索片段。可以试试把检索到的片段显式拼进训练输入里，同时加点负样本做对比，让模型学会区分哪些片段该用、哪些不该用。另外bge-m3本身没被微调的话，检索效果不会变，问题多半出在生成端怎么用这些结果。

双4090跑6B绰绰有余，vLLM配AWQ量化最稳，并发直接起飞。

我们生产环境挂了6个MCP服务器，确实会有延迟叠加的问题，尤其是串行调用多个工具的时候。建议你看看是不是每次请求都重新建连接了，FastMCP默认好像没做连接复用，我们后来改成常驻进程+内部HTTP池才降下来。另外工具描述太长也会拖慢路由，精简一下schema试试。

我现在的做法是让AI先别写代码，先让它把改动涉及的边界条件列出来，比如并发下订单状态怎么流转、异常在哪一层兜底，我确认完再让它动手。直接让它改逻辑，它确实容易挑最顺的那条路径写，边界全靠你自己补。另外重构订单这种带状态的，我一般会先写几个失败用例丢给它，让它照着用例改，比光靠注释稳不少。

10万条bge-base就跑2-3秒有点离谱，先看看是不是没上GPU或HNSW索引没建对。

我目前的做法是本地调试用stdio，但一旦涉及多客户端共享推理服务，就果断切HTTP。stdio本质是父子进程绑定，loss实时推送靠stdout轮询太别扭，不如直接起个FastAPI把训练指标挂成SSE或者WebSocket，MCP这边只做工具调用壳子。多客户端共享同一个推理服务，HTTP几乎是唯一选择，不然每个客户端都得自己拉一份模型，显存扛不住。接PyTorch的话，建议工具层只暴露推理和状

换embedding模型确实得重新调，不是玄学。ada-002和BGE的向量空间分布差挺多，chunk size和overlap的适配点也会跟着变。我之前也踩过这坑，后来发现关键在检索那一步：先别急着换混合检索，拿十几个已知答案的query手动跑一下相似度，看top10里到底有没有目标chunk。如果没有，那就是embedding本身没对齐你的语料，BGE-large-zh可以试试加个instru

Loss降到0.7不代表模型真的学到了你想要的东西，很可能它只是记住了你5000条QA的固定套路，然后把这个套路强行套到所有问题上，所以才会出现常识问题也答得乱七八糟的情况。2e-4对LoRA来说确实偏高了，我一般从1e-4甚至5e-5开始试，尤其你数据量不大，3个epoch基本就是把那点数据嚼烂了。你观察到的啰嗦和答非所问，大概率是过拟合加上格式被带偏了，内部文档风格如果本身比较冗长，模型会连这

建议先别急着调chunk，把表格单独拎出来走摘要或者key-value索引，正文再按条款粒度切。你那个问题本质是语义混淆，年假定义和请假流程在向量空间里太近了。另外bge-m3对长文档不太友好，500字可能反而稀释了关键信息，试试按条款边界切短块加索引标题。rerank可以后置，先看检索召回的前20条里有没有正确答案，有的话就是排序问题，没有才是切块问题。

22G是预先把权重和KV cache全塞进去了，TP=2要看下模型是否真的支持，速度瓶颈大概率在数据并行没生效。

bge-large-zh对数值型内容确实容易“脸盲”，但更可能是chunk切分把“Q3”和“销售数据”拆散了，试试按语义边界切分或者给数字附近加上下文。多Embedding加权融合我试过，提升不稳定，反而增加延迟，不如先检查召回结果里是不是真的缺了相关片段，还是排序阶段把对的压下去了。你查过ES或向量库的召回日志吗？看看漏掉的片段到底长啥样，比换模型更直接。

说实话你这规模几百用户，纠结Milvus和Pinecone都属于过度设计，Chroma或者Qdrant本地跑完全够用，等真到需要换库的时候，你的Agent业务逻辑早就验证完了。索引调参这事我踩过坑，Milvus默认的HNSW参数对中小数据集反而容易过拟合，别迷信调参，先看召回结果能不能满足场景。embedding维度这事，只要库支持动态维度，差异真不大，主要看你的模型输出和检索距离函数匹不匹配，比

这问题太典型了，我也踩过一样的坑。你光在system prompt里写“注意业务上下文”肯定没用，大模型对抽象指令的理解很飘，它根本不知道你业务里哪些“丑”是刻意为之。我的做法是把项目里那些“历史遗留设计”单独写成一个文档，比如“已知技术债清单”，里面列清楚哪些模块为什么这么写，然后让Agent审查时先查这个清单，命中就直接跳过。效果立竿见影，误报率至少降一半。 还有个思路是给Agent加个

说实话这问题我也折腾过一阵，最后发现跑Agent真不能光看模型尺寸，延迟崩了多轮交互直接没法用。我现在是Qwen2.5-7B配AWQ量化加SGLang，比vLLM省心不少，显存占用和速度平衡得还行，单次能压到一秒内。长上下文对规划影响挺明显的，但前提是Agent得真会用，不然白占显存，我一般设8k够写代码了。你要是主要做工具调用，不如试试降到3B模型配大点上下文，可能整体体验反而更顺。 ---

你这配置跑7B int4确实有点悬，6G显存装不下满血层，剩下的全靠内存硬扛，速度肯定崩。我同款显卡试过，把n-gpu-layers调到20左右能缓解一点，但代码补全这种高频场景还是卡。换Qwen2.5-3B-int4体感会明显流畅，日常问答够用，代码补全差点意思但能忍。要不先试下4B的Qwen或CodeLlama，或者把上下文窗口调小点，说不定有惊喜。