代码备忘录

遇到工具调用OOM挺常见的，我之前用7B也踩过这坑。你试试把llama.cpp的ctx大小调小点，比如2048，然后开--no-mmap，能把部分权重放内存里换着用。另外工具调用那段别让模型输出太长的JSON，强行限一下max_tokens到256以内，显存能松快不少。轻量框架的话可以看看rust写的llama2.rs或者candle，内存管理比python那套省心多了。

4090跑4bit的8B这速度确实不对劲，我怀疑不是量化方式的问题，GPTQ和AWQ在单卡场景下差距没这么大。你试试把max tokens降到512，关掉vLLM的continuous batching，或者直接换llama.cpp试试，我遇到过类似情况是vLLM的显存碎片导致的。另外FlashAttention一定要开，不开的话attention部分会慢一倍不止。如果还不行，看看是不是GPU没跑

说实话这俩我都折腾过，最后留了Qdrant。百万级向量的话，Qdrant单机跑起来延迟很稳，记得配好HNSW的ef参数，过滤场景用payload index也挺顺手；Milvus那个etcd和minio组合对个人项目确实太重，除非你要上分布式，否则运维成本划不来。LangChain两边官方都有集成，但Qdrant的本地模式调试起来更省心，Milvus反而容易在连接配置上卡壳。至于社区活跃度，俩都挺

我之前也卡在这块儿好久，试错试到怀疑人生。后来发现chunk size真的不能拍脑袋，核心得看你的文档结构和检索粒度。像技术PDF这种，如果段落本身就很长，500确实容易把逻辑切断，我后来改成按标题和段落边界来切，而不是死磕固定字数，效果反而稳了不少。overlap的话，我一般控制在10%-15%，主要是为了兜住那些跨块的上下文，但设太大噪音也明显，回答容易把前一块的旧信息带进来。另外一个野路子是

这情况太典型了，测试集那100条基本等于你自己给自己画了个靶子，上线后用户的问题分布跟那个根本不是一回事。我猜你召回崩大概率不是模型本身的问题，而是embedding的相似度阈值没调好，或者top-k取得太死，线上问题稍微换个说法，向量距离就全变了。我踩过类似的坑，后来把检索改成混合模式，关键词用BM25兜底，语义检索只做重排，效果稳了很多。另外你监控过用户query的embedding分布吗？如

这问题我太有同感了，之前用bge-large也翻过车。个人感觉你这个case里embedding和分段可能都有点锅，512字符对合同条款来说还是太粗了，尤其违约金比例这种关键数字，经常跟前后文混在一起被稀释掉。建议先试试把分段压到256甚至更小，或者按条款语义切分，看看召回有没有改善。另外top_k调大点也没用，因为相关片段根本不在库里排前面，所以重排模型大概率能救一手，bge-reranker对

这俩在agent场景下延迟差别真不大，主要看预算和运维精力，Pinecone省心但账单确实肉疼。 自建Milvus没那么可怕，小规模用单机docker跑也够稳，精度丢多半是faiss的index没调好。

我之前也踩过这个坑，后来发现RAG的prompt真不是堆约束就行，关键得让模型明白“哪些是证据”而不是“你要听话”。你可以试试把检索片段用明确的标记（比如XML标签）包起来，再告诉它只依据标签里的内容回答，效果比单纯说“请基于上下文”好很多。另外few-shot别放太多，两三个就够了，而且示例一定要贴合你实际的数据风格，不然模型容易被带偏。还有个小技巧，temperature调低到0.1-0.2，

我之前也遇到过一模一样的情况，当时用7B模型做垂直领域客服，幻觉问题比你这还严重。后来我排查了一圈，发现数据质量比数据量重要得多，你那2万条对话里如果存在大量重复表述或者上下文不完整的样本，模型很容易学到“编造”的坏习惯。我建议你先做一轮数据清洗，特别检查一下用户名字、商品名这些实体是不是在上下文里都出现过，LoRA对这类细节特别敏感。另外8B模型本身容量有限，2万条数据其实偏多了，容易让低秩适配

int8掉点5个确实偏多，校准集建议直接抽训练集的子集，别用验证集，而且每类像素占比要均衡，不然小目标全废。动态shape这块我建议固定到2的幂次，比如416/832这种，Jetson上内存带宽有限，省下来的时间够你喝杯咖啡。F.interpolate可以先转成ONNX的Resize节点再看情况替换成TRT的插件，我试过用nearest+align_corners=False能绕开不少坑。层融合别

同感，我拿中文数据集微调llama也踩过这坑，后来发现chinese-llama的增量词表很关键，直接拿原版跑中文等于让模型硬猜字。另外你这r=8可能太小了，我试过r=32效果明显好一些，但数据量2万条对7B来说确实有点少。其实客服场景如果prompt能解决，真没必要硬上微调，老板那边可以拿对比结果说服他，省下来的A100时间干点别的更香。

这问题太典型了，多半是prompt里工具描述和调用规则没写清楚，建议把每个工具的边界和触发条件写死试试。

几百条就卡大概率不是MCP的锅，Chroma全量扫描加每次重新向量化才是真凶。建议把embedding结果持久化存下来，别每次现算，查询前先做一次粗筛（比如按时间窗口或关键词预过滤）再向量检索，能快不少。遗忘逻辑其实不用搞太复杂，写个tool定期按时间戳删掉超过N天的记录就行，或者用集合分片，比如按月份建不同collection，查的时候路由一下。另外你试试把查询和插入拆成两个独立tool，避免互

这问题我太有同感了，之前用7B模型做agent的时候也踩过这个坑，显存曲线跟心电图似的只涨不降。你那个torch.no_grad()方向是对的，但光靠它不够，因为推理时即使不反传，中间激活值还是会占显存，而且多轮对话的history拼接后，每次前向都会重新算一遍所有token的KV，这才是显存涨的元凶。我后来是用transformers的past_key_values接口，手动把每一轮的KV ca

百万级其实Qdrant够用了，Chroma索引一上来内存确实扛不住。别上云，自己机器跑省钱还灵活。

我之前也遇到过一模一样的情况，Top5召回看着挺像那么回事，结果生成出来跟复读机似的。后来我发现问题不光是Prompt，还得看你怎么把检索片段喂进去——我试过按相关性重新排序，再在每段前面加个来源标签，效果比单纯堆原文好不少。你提到的先列证据再回答，我试过让模型“先引用原文关键句，再用自己的话总结”，确实能减少缝合感，但得注意别让它变成纯粹摘抄。还有个土办法，就是Prompt里明确告诉它“如果多个

20的吞吐确实不太对劲，我拿A100跑Qwen2.5-7B不量化，max_model_len设4096，开flash_attn，单卡能稳在45-55之间。你试试把gpu_memory_utilization调到0.9以上，然后确认下是不是微调后tokenizer加了特殊token导致序列变长，这会影响实际生成速度。docker基本没损耗，除非你网络模式或者共享内存配得有问题。另外建议用vllm的b

试试用Qwen2.5-1.5B加vLLM做流式推理，16G跑起来很轻松，agent逻辑可以精简到单轮工具调用，别太依赖长上下文。

你这几个坑基本都踩过一遍了。动态shape建议直接用onnx的dynamic_axes，但batch维度固定成1省很多事，TensorRT对静态shape优化更狠。F.interpolate那个警告我后来用torch.nn.functional.upsample替代，虽然不能完全消除，但trt里至少能跑起来。int8掉点大概率是校准集太单一，试试用验证集随机抽500张，配合entropy校准，能拉

建议先按文档标题层级切块，再配合100-200的overlap，光靠固定长度确实容易漏关键信息。