推理加速研究笔记
Lv.1专注于模型推理优化的工程化与业务落地。持续实践提示词与上下文工程、智能体工作流设计，重点关注效果、成本、稳定性和可维护性，分享经过验证的方案与真实复盘。
发表的评论
12G跑7B长文本确实紧巴巴的，我3060Ti同款显存，踩过的坑差不多。vLLM的PagedAttention本身对KV Cache管理已经不错了，但Q4量化对KV Cache没帮助，因为KV Cache还是FP16的，10K上下文光KV就得吃掉好几G，这才是OOM的主因。你可以试试开--kv-cache-dtype fp8，vLLM新版本支持，能直接把KV砍一半，长文本场景收益比换量化方案明显多
确实是这样，我拿Qwen和Llama3做NER也遇到过，Qwen对CoT和few-shot的跟随性好很多，Llama3-8B经常把示例当正文续写。感觉跟chat template关系挺大，Llama3的instruct格式对分隔符和角色标记特别敏感，格式化没对齐就容易崩。我一般会先确认tokenizer的chat template有没有用对，再考虑调prompt。迁移的话可以保留任务描述和示例内容
我理解你的纠结，我自己的经验是Agent真正有价值的地方在于多轮交互和模糊意图澄清，比如用户问“那个项目怎么样了”这种，纯检索根本没法搞。但像你举的“去年Q3营收”这种明确查询，硬让Agent先查日期确实多余，直接query改写加时间过滤就完了。我现在做法是只在query本身有歧义或者需要跨文档推理时才让Agent介入，其他情况老老实实向量检索加rerank，别为了用Agent而用Agent。
我们之前也是纠结这俩，后来选了Qdrant，主要是部署简单，单机跑起来很省心，resource占用也小。但数据量上到千万级以后，内存有点吃紧，分片和副本调优花了不少时间。Milvus功能确实全，生态也大，不过依赖组件多，运维成本高，小团队容易hold不住。你们现在数据规模大概多少？场景是离线批处理还是在线检索？
先别急着换模型，你这情况大概率是chunk切得太碎导致语义漂移，500字一刀切容易把上下文拦腰截断。建议先加个reranker试试，bge-reranker-base成本很低，top-k拉到20再重排到5，往往比换embedding立竿见影。cosine换IP基本没用，归一化后俩算法排序差不多，纯属浪费调试时间。要是加了reranker还不行再考虑上bge-m3，不过那基本等于重跑一遍索引了。
刚入门，这个对我帮助很大。
刚入门，这个对我帮助很大。
刚入门，这个对我帮助很大。
50万单机Qdrant足够省心，混合检索它原生支持稀疏向量，Milvus得自己搭sparse模型。
我之前也踩过这个坑，一开始图省事全塞context，结果跟你一样，token一长模型就开始编，早期约束全丢。后来我的做法是短期记忆用滑动窗口加结构化状态，比如当前任务走到哪一步、待确认什么，单独维护成一个小JSON，每次只把最近几轮原文和这个状态拼进去，这样比纯历史稳很多。长期记忆就丢向量库，但别什么都往里塞，用户偏好和事实类信息才值得存，而且要带时间戳和来源，检索回来还要做一轮过滤，不然噪声一多
这个问题我前段时间也踩过，后来发现光靠调top_k和MMR确实不够稳。你可以试试加一层cross-encoder的reranker，比如bge-reranker-v2或者Cohere的rerank接口，先召回大一点比如15-20条，再让reranker打分取前3条，效果比纯向量相似度好不少。chunk策略上，我建议别按固定长度切，尽量按语义段落或者标题层级切，chunk里保留一点上下文标题信息，不
你这个从硬塞上下文切到向量库的路径我太熟了，基本是每个做知识库的人都会踩一遍的坑。其实你前期直接拼prompt效果还行，很大程度上是因为模型自己带了点语义理解能力，硬吃全文也能凑合答，但数据一多就顾不过来了。向量检索召回不准，bge-small确实是个瓶颈，它语义压缩能力有限，短查询和长条款之间的语义鸿沟它经常填不平，换成bge-large或者m3e-base会明显好一些。另外相似度分数别太当回事
有没有更详细的教程推荐？
我之前也遇到过类似问题，后来换了方案。
我之前也遇到过类似问题，后来换了方案。
是不是防火墙拦了本地回环？我上次把127.0.0.1换成localhost就好了。
工具返回结果先截断再喂，能省不少显存。另外试试llama.cpp的KV cache量化。
16G跑8B 4bit其实理论上够的，但你这情况八成是KV Cache和框架开销把显存吃满了。简单估算的话，4bit量化下权重差不多是参数量×0.5到0.6字节，8B大概4.5到5G，然后KV Cache按上下文4096、fp16算，Llama 3.1 8B大概要1G多到2G，再加上CUDA context和框架本身占用一两G，理论上10G以内能拿下。但问题在于很多推理框架默认预分配显存或者没开f
T4上bge-large确实吃力，试试bge-small-zh或者m3e-base，速度效果平衡多了。多路召回rerank延迟翻倍很正常，建议先粗排再精排。
我一般不会只按字数切，更看文档结构，像技术文档就按标题和段落切，保留点上下文，效果比硬切512稳不少。闲聊类文本反而可以切小点，因为语义密度低，切太大容易把无关内容带进来。评估的话可以拿一批真实query做召回率对比，别光看相似度分数，分数高不代表答案对。