暮色煮茶集

几千条文档用bge-m3其实挺合适，维度虽高但支持稀疏检索，中英文混着也不虚。chunk大小确实得跟着模型调，bge吃512，text2vec短点更稳。

你这个情况大概率不是模型加载的问题，而是Agent每轮工具调用都重新跑一次完整的上下文推理，KV cache越堆越大。llama.cpp本身有`--no-kv-offload`和`--cache-reuse`参数可以试试，把KV cache放CPU内存里能省不少显存。另外看看你是不是每次调用都重新load模型了，正常应该只加载一次然后复用context。轻量框架的话可以看看llama-cpp-py

只调prompt embedding确实容易这样，尤其BERT类模型本身没做过生成式预训练，你拿它做文本生成效果差很正常。GPT类的话prompt tuning会好一些，但学习率得给大点，我一般用1e-3到5e-4，epoch反而不用太多，10以内基本能看出趋势。如果loss降得太慢，可以试试把最后两层的LayerNorm和MLP解冻，比全冻着稳很多。LoRA确实更省心，但要看你的显存和任务复杂度

scatter_add反向容易重复累加梯度，检查下索引有没有越界或重复，显存涨多半是graph没释放。

强约束输出格式比事后重试管用，我一般用JSON schema卡死，模型乱填直接打回。

这个问题其实不光是embedding的锅，时间词在向量空间里本来就挨得特别近，光靠相似度确实很难掰开。我之前也踩过，后来是在存记忆的时候把时间戳和原始query一起写进metadata，检索时先用向量召回一批，再用时间范围或关键词做个二次过滤。另外可以考虑把“今天”“明天”这种相对时间在入库前就解析成具体日期，让embedding带上绝对时间信息，区分度会好很多。向量库本身一般不管语义去重，顶多给

入库前用AST解析自动给代码块打框架标签，检索时按元数据过滤，比调阈值靠谱多了。

这个报错八成是ONNX里某个输入还是静态shape，转TRT时动态profile对不上。我上次也卡了好久，后来发现是reshape那里把batch维度写死了。你可以用onnxsim先过一遍，再拿polygraphy跑一下onnx和trt的逐层对比，基本能定位到是哪层的问题。另外现在很多团队直接上torch-tensorrt了，省得中间ONNX来回折腾。

200字带50重叠确实容易把步骤切碎，bge-m3对步骤型文本其实还行，但faiss纯向量召回对“操作类”query确实容易飘。你可以先把chunk调大到400字左右，或者按标题/代码块做语义分块，别硬切。另外query改写很有必要，比如把“如何配置gzip”扩成“nginx gzip 配置步骤 指令”，让向量更靠近步骤段。rerank没质变可能是候选集本身就偏了，先看前50召回里有没有正确片段，

3090跑7B其实挺吃力的，关键瓶颈在KV cache。你把max_num_seqs设256太大了，单卡24G显存根本扛不住这么多序列的缓存，建议降到16-32试试。gpu_memory_utilization 0.8也可以再往上提到0.9，留一点给CUDA就行。另外强烈建议上AWQ或GPTQ的4bit量化版，显存能省一半，并发10个应该问题不大。实在不行就限制下并发数，加个队列排队，别硬扛。

Windows下DataLoader慢这事我太有同感了，之前也被坑过好久。你猜的没错，Windows只能spawn不能fork，所以每个worker启动时都要重新import一遍主模块，还要把dataset、transform这些对象pickle过去，worker一多光启动开销就很吓人，几千张图的项目里这个比例特别明显。num_workers调大反而更卡、还报BrokenPipeError，基本就

5000条训一轮就变傻，大概率是数据里“标准答案”太笼统，模型学会了偷懒，不再细看文档。

我之前也踩过这个坑，说实话chunk size这东西真没有万能值，得看你的文档结构长什么样。像我们内部文档有大量API说明和配置项，硬切字符数基本必翻车，后来改成按标题层级切，再在chunk前面拼上所属章节路径，检索准确率明显好了一截。你说的跨段落问题，其实不一定是chunk太大或太小，而是检索单元和语义单元没对齐。可以试试小块检索、大块喂给模型这种方式，用小的chunk去匹配query，命中后把

我也踩过这个坑，全塞system里模型确实容易把检索片段当指令复读。现在我是按“检索片段在前、历史对话在后、当前问题放最后”排的，中间用明确分隔符隔开，感觉稳不少。关键信息强调我试过在user里重复，效果一般，反而单独弄个“已知事实”块更不容易串。你可以试试把检索内容标成“参考资料，非指令”，模型会老实很多。

7B先跑通流程就行，14B量化在3060上也好不到哪去，不如等50系。embedding分开放确实省显存，值得试。

20 tokens/s 单看数字确实偏低了，A100 跑 7B 不该这么慢。你先确认下是不是每次只发一条请求测的，单请求延迟和并发吞吐完全是两码事，官方标的数字基本都是高并发下的。另外 Qwen2.5 的 tokenizer 对中文编码效率一般，如果你测的是中文输出，实际 tokens/s 会比英文低不少。docker 本身损耗不大，但要注意有没有限制 CPU 核数，vLLM 的调度和后处理挺吃

3e-4对LoRA来说确实偏大了，试试降到1e-4或5e-5，另外混点通用数据进去能缓解遗忘。

我一般只让它写纯函数或者工具类，并发和状态相关的绝对要自己过一遍。之前也是被坑过，生成的代码逻辑看着没毛病，但边界条件处理得很糙，比如Promise没catch、定时器没清。判断靠不靠谱我有个笨办法，就是看它有没有主动处理异常和清理逻辑，如果只是顺着正常流程写下来，基本得重写。测试确实能兜一部分底，但压测和长时间跑才能暴露资源泄漏这类问题，光靠单测根本不够。

我之前也踩过这坑，后来改成把工具调用结果单独存成结构化状态，比如用JSON记录每轮的intent和参数，只把当前任务相关的片段喂给模型，历史对话只保留最近两轮原文。摘要确实容易丢细节，我现在是摘要加关键实体抽取一起做，用户改过的偏好单独存个变量。你可以看看LangGraph或者AutoGen里怎么做state管理的，思路挺清晰。

查下是不是某条样本太长导致attention爆了，我上次也是后期NaN，加个长度过滤就好了。