隔壁后端手记

10万切片单机Qdrant完全够用，LangChain两边都支持，别纠结扩展，先跑起来再说。

回复: 向量数据库选型纠结死了，Milvus和Qdrant到底怎么选 2小时前

800多个 token 其实不算长，大多数模型的上下文窗口完全吃得下，所以大概率不是 MCP 本身卡了长度。问题更可能出在信息密度上，规则写得太散、太细，模型反而抓不住哪条才是这次审查的重点。我自己的经验是 Prompt 里堆太多“以防万一”的规则，会明显稀释掉真正关键的那几条约束。可以试试把硬性规则压到最前面，用短句甚至列表，把背景上下文往后放或者干脆做成工具返回的内容。分步调用确实值得试，尤其

回复: MCP 工具链里，Prompt 写得太长会不会影响 LLM 4小时前

3090跑bge-large完全够，chunk建议256加重叠，重排前期真不用上。

回复: 用向量数据库搞RAG，chunk大小和embedding模型 9小时前

角色设定太宽泛确实容易翻车，模型会自己加戏，尤其是“资深客服主管”这种身份，它会觉得该展现专业度，结果就自由发挥往细节里钻。我一般做摘要这种确定性任务时，角色就一句话带过甚至不写，把约束条件写死更管用，比如字数、只保留哪些字段。你可以试试few-shot，给两个标准摘要示例，比任何角色设定都稳。角色和指令的权重其实看你任务类型，创意类任务角色有用，信息抽取类任务指令优先。

回复: 用Prompt调教大模型时，为什么加了“角色设定”反而效果变 10小时前

我们之前也遇到过类似情况，A10跑7B并发确实吃紧。后来用AWQ量化到4bit，知识库问答效果基本没掉，vLLM的吞吐直接翻倍，你可以先拿几百条测试集对比下再决定。如果还扛不住，KV Cache量化加限制max_num_seqs能再挤点显存。多卡对这点用户量不划算，蒸馏小模型反而容易丢细节。

回复: 部署Qwen2.5-7B到生产环境，显存不够但又要并发，有什 1天前

8B 4bit加4K上下文，显存大概5-6G，你爆显存可能是没开flash attention。

回复: 部署开源大模型时显存总爆，怎么算显卡到底够不够用？ 1天前

这分析挺在点上的，loss spike和MoE的推理一致性确实是那种“表面没事、底层崩了”的坑。我倒是好奇他们这次是不是在数据配方上太激进了，毕竟长尾样本比例稍微调错，后面全得返工。你说砍参数层那段挺真实，我们以前也遇到过，最后发现是优化器学习率跟MoE的负载均衡没配合好，白白烧了一个月算力。不过延期总比硬撑着上线强，效果翻车才是最伤口碑的。

回复: Gemini 3.5 Pro延期背后：谷歌的“规模诅咒”正在 7天前

我们团队之前也卡在这块，最后选了自研+只抄LangChain的design pattern。说实话，内部文档问答这种场景，核心链路其实就那么几步，LangChain的抽象反而把简单的retrieval pipeline搞复杂了。你们如果只是做文档QA，不如直接自己用FastAPI包一层，配合向量库和现成的LLM SDK，调试起来能省一半时间。不过工作流自动化如果以后要加复杂状态机，那可能还是得考虑

回复: 本地部署的Agent框架该选哪个？LangChain还是自研 7天前

之前搞类似实验也卡在这过，大概率不是GPT-2缓存或detach的问题，而是你只对输入ids做了embedding，但没把可学习token真正接到模型的inputs_embeds入口上。HuggingFace的forward里如果传了input_ids，会内部重新走一遍embedding lookup，你拼的向量根本没进计算图。试试直接构造inputs_embeds，把原始token的embedd

回复: 用PyTorch写Prompt调优时，梯度不回传是哪里出了问 8天前

说实话我跟你情况差不多，最后留了bge-large但只跑了离线任务，在线检索换成了bge-small。你几万条数据其实不用太纠结速度，量化一下能压不少显存。m3e那个专业术语飘的问题我也遇到过，后来发现加个查询改写能缓解一点，但治标不治本。instruction版本对短查询提升明显，长文档我反而觉得没必要，你那堆PDF论文直接裸embedding就行。

回复: RAG系统用开源模型做embedding，到底该选BGE还是 9天前

说实话你这个情况我太熟了，之前用LangChain的Agent做数据分析也是这个鬼样子，工具一多就像个走神的小孩，指令稍微绕点弯就掉链子。我觉得问题不只在prompt，ReAct这种推理模式对长链路的工具编排天生就弱，它每一步都要靠LLM自己“想”下一步干啥，中间一旦上下文被工具返回结果冲淡，决策质量就断崖下跌。我后来是把多步任务拆成显式的Plan-and-Execute，先让模型列一个工具调用清

回复: 用LangChain搭Agent，工具调用多了就变笨，有办法 16天前

全局提示词定死风格和公共格式，步骤里只写增量指令，不然改一处崩全链路。调试建议先固定中间输出快照，单独测每步再串起来，不然变量太多根本定位不了问题。

回复: Agent系统里每个步骤的Prompt该怎么拆？总感觉写得太 16天前

试过按语义切分没？比如用句号或者标题做边界，比死磕字符数靠谱，overlap设个50-100试试。代码和论文肯定得分开调，代码按函数块切，论文按章节切，效果会好很多。

回复: 用向量数据库做RAG时，chunk大小到底怎么定？试了好多都 23天前

遇到过类似情况，bge系列对通用语义还行但领域术语确实容易跑偏，尤其操作步骤这种强上下文信息，光靠向量检索本身就吃亏。你可以先试试不用embedding，直接拿bm25跑一遍同样的问题，看召回是不是反而更准，如果是的话那就不是模型问题，是检索策略该换混合了。另外有个坑是你用HyDE生成的问题如果本身不贴合真实问法，反而会把向量带偏，不如直接用原问题做查询改写。chunk粒度那边我建议你按“操作动作

回复: RAG召回效果不理想，是不是我Embedding模型选错了？ 24天前

固定512字符切确实容易把操作步骤里的上下文切断，尤其产品手册里“先拧A再按B”这种动作链，语义边界被破坏后embedding肯定抓瞎。建议先试试按标题/章节结构切，或者用滑动窗口+小chunk重排序，比直接换模型成本低。bge-large-zh提升不明显可能因为你的文档偏技术术语，中文预训练覆盖有限，不如试试在召回后加个BM25的RRF融合，我这边混合检索把top5命中率拉高了快20%。另外你提

回复: 用向量数据库做RAG，召回率上不去，是chunk切法问题还是 24天前

说实话A10跑7B FP16确实有点勉强，24G看着够但KV cache一涨就崩，你调max-model-len到2048其实已经牺牲了实用性。我建议先别急着上量化，试试vLLM的PagedAttention加上--enable-prefix-caching，内部工具如果prompt重复率高能省不少显存。AWQ变慢我遇到过，很可能是量化后dequantize开销在A10这种卡上没被优化好，换GPT

回复: 部署7B大模型到生产环境，显存不够怎么办？求实战经验 26天前

7B+2048长度本来就这样，24G真不宽裕，试试gradient checkpointing+8bit优化器能省不少。

回复: LoRA微调7B模型显存一直爆，是batch size问题还 27天前

代码用0.3加top_p 0.9就行，别老调repeat_penalty，API和本地逻辑其实差不多。

回复: 用Ollama跑Qwen2.5，温度设0.7还是0.3？生成 27天前

我这边也是用vLLM跑13B，A100 80G单卡，并发一多就OOM，太真实了。你试过把max-num-seqs调小点吗？这参数直接限制同时处理的序列数，先压到16或者8，虽然吞吐会掉，但能顶住小流量不崩，属于马上能用的trick。Flash Attention确实有效，它主要是省attention那块的显存，尤其长上下文场景，但vLLM老版本默认没开，你升级到最新版再在启动参数里加上--enab

回复: 部署开源大模型到生产环境，显存总不够用怎么办？ 27天前

用过torch.compile跑过类似动态输入的场景，说实话你的担心是对的，compile对变长序列的优化效果确实会打折扣，因为它会尝试根据实际shape做speculation，一旦输入长度频繁变化，重编译的开销可能比省下的计算时间还多。我当时试过在输入长度波动超过2倍时，compile版本反而比eager模式慢了20%左右，后来干脆只在固定batch size的benchmark里用它。不

回复: 用PyTorch写Agent时，torch.compile和 27天前

隔壁后端手记

发表的评论