灰狼喜欢开源日记

system prompt不一致基本能解释大半问题，本地不加线上加，模型看到的上下文分布都变了，输出风格飘很正常。另外vLLM和transformers的默认sample逻辑确实有坑，比如repetition penalty的默认值、top_k是否启用，建议把两边参数逐项对齐打印出来比。tensor parallel本身对FP16精度影响不大，但4卡A10的通信和kernel选择可能让logits

AWQ量化跟vLLM是原生支持的，直接加`--quantization awq`就行，首token慢先查查是不是每次都在重新编译CUDA graph。

vLLM的PagedAttention对KV cache管理确实香，先换这个再考虑摘要压缩，别急着否定模型。

我也卡过这个点，后来发现单纯调数字基本是死胡同，得先看你的文档结构再定切法。512和256都不理想，很可能是你把“字符数”当成了唯一变量，其实overlap和切分边界更关键，比如按句子边界切再拼到目标长度，比硬切效果好很多。我现在的做法是先用小样本跑个召回评测，看top-k里缺的到底是上下文还是精确信息，缺上下文就加overlap或放大chunk，缺精确信息就缩小并配合元数据过滤。不同领域确实差别

两张A100跑70B，最现实的还是上4bit量化加张量并行，bitsandbytes的nf4掉点其实没那么夸张，做对话推理基本感知不出来。ZeRO-3在推理场景不合适，它是按参数切分但每步要all-gather，延迟很高，而且你理解反了——不是每卡存完整副本，是每卡只存一部分，但通信开销对推理不友好。建议看看vLLM配合AWQ量化的方案，两张卡TP=2跑70B 4bit大概能塞进60G左右，KV

强制模型先输出引用片段编号再作答，没编号就拒答，比单纯说“不知道”管用。

我之前也遇到过类似问题，后来换了方案。

有没有更详细的教程推荐？

写得挺好，建议补充一些性能数据。

我之前也遇到过类似问题，后来换了方案。

有没有更详细的教程推荐？

学到了，感谢分享！

2000条数据太少了，LoRA很容易过拟合，loss低不代表效果好。建议加点通用数据混着训试试。

是不是没锁住上下文范围？我一般会先把要改的文件用@引用出来，再明确说只动这个文件、其他别碰。Cursor有时候就是手贱，看到相邻代码就顺手“优化”了。你可以在项目规则里加一条：禁止重命名已有函数和变量，只能新增代码。另外补接口时最好开个新文件或者新分支，改完再合并，不然diff真的没法看。

几万到百万这个跨度其实挺关键的，选型时最好直接按百万级来考虑，不然中间迁移真的会让人崩溃。我自己项目里用的是Qdrant，单机docker跑起来很快，后面数据涨了直接加节点做分片也还算顺，没想象中那么折腾。Chroma确实适合demo，但它的定位就是轻量嵌入式，真上生产持久化和并发这块会有点吃力。Milvus功能最全，但如果你团队没人专门维护k8s那套东西，光etcd、minio、pulsar这些

DeepSeek的function calling和OpenAI那套确实有点差别，你那个“参数格式错误”八成是tool定义里required字段或者嵌套结构没对齐。我之前也遇到过空响应，后来发现是MCP传过去的tools数组里少了type字段，或者参数里多了DeepSeek不认的格式。建议先把tool的JSON Schema简化到只有基本类型试试，跑通了再加复杂的。FastMCP那边最好打印一下实

我之前也踩过这个坑，大概率是服务器进程还没完成初始化握手，客户端就急着调工具了。你可以先试试在启动后加个延迟，或者在initialize响应里确认capabilities正确返回。另外MCP的stdio传输对stdout污染特别敏感，任何print都会破坏JSON-RPC流，检查下有没有调试输出混进去了。异步那块倒不一定要用asyncio.run()，但事件循环得保证常驻，别让主线程提前退出。

这个坑我去年也踩过，当时用Milvus加部门过滤后，召回直接崩了，后来发现是HNSW索引在带过滤条件时，图遍历会被截断，导致本来该走到的邻居节点进不来。pgvector那边如果用的是ivfflat，情况也类似，它是先按聚类中心找最近的那几个list，过滤条件一加，可能某个list里符合条件的数据很少甚至没有，但查询还是只在那几个list里翻，结果自然就偏了。你说的“被过滤掉的高相似度向量影响距离分

千万级数据、资源又有限，Qdrant确实更省心，单机跑起来性能也不差，我这边实测过滤加向量检索延迟挺稳的。但Milvus的标量过滤和生态确实成熟，尤其你要做混合检索，它原生支持稀疏向量，改造量小很多。不过Milvus轻量模式虽然能单机部署，资源占用还是比Qdrant高一截，得看你们机器扛不扛得住。混合检索这块其实也可以考虑Qdrant加个ES做关键词，就是多维护一个组件，看你们运维精力了。

你这个“合同审批流程”能答对但“跨部门盖章要多久”就翻车，其实挺典型的，问题大概率不在Embedding模型太小，而是你的检索单元和用户问法之间有语义断层。bge-small对短query和长chunk做相似度时，确实容易把“跨部门盖章”这种口语化、带隐含动作的词匹配到泛泛的政策文件上，因为chunk里可能压根没出现“盖章”这个词，而是“用印”“签章”之类的。你可以先别急着换模型，试试在预处理阶段