深夜机器学习备忘录

V100 16G跑GPTQ-4bit的7B确实挺紧的，我这边用AWQ量化加vLLM的paged attention能稳定不少，显存大概占12G左右。你多轮对话崩主要是KV cache没管好，vLLM的prefix caching和自动回收能帮上忙。如果还不行可以考虑GGUF的Q4_K_M配llama.cpp，CPU offload一部分虽然慢但基本不OOM。双卡没必要，先换框架和量化格式试试，性价

8G显存跑7B的Q4其实挺勉强的，光模型权重就快4G了，加上KV cache和Ollama的上下文开销，爆掉很正常。你可以试试把上下文长度从默认的4096压到2048，再开q8_0的KV量化，能省不少。真不够用的话换成1.5B或者3B的Coder版本，补全场景其实够使了，速度还快得多。

几十万条数据其实不算大，HNSW的M和efConstruction确实会影响召回，但它们更多是召回率和查询速度之间的权衡，不会让语义完全不搭的结果混进top10，所以大概率不是索引参数的锅。你说换了bge-m3和3-small都没改善，我比较怀疑是chunk切分的问题，比如切片太长导致一个向量里塞了好几个主题，或者切片之间overlap没做好，语义被稀释了。另外你top10里混进不相关的结果，不妨

动态shape这块建议直接用trt的optimization profile，别在onnx里死磕，导出时把dynamic axes标清楚就行。interpolate那个警告基本可以无视，但转trt报错通常是opset版本或者align_corners的问题，换成opset11以上再试试。int8掉5个点挺正常的，校准集一定要覆盖你实际部署场景的分布，最好多跑几百张，不然量化参数偏得离谱。算子融合不

200万向量就上3节点Milvus集群有点奢侈了，瓶颈大概率在段合并策略，先调参数别急着换库。

同感，Copilot用久了确实容易变懒，关键逻辑还是得自己捋一遍才踏实。

试试用LLM先把“那利润呢”改写成完整query再检索，别直接拼历史，容易带偏。

这个问题我也踩过坑，感觉模型确实容易把“完整的错误处理”理解成有个大概意思就行，不会真的逐行去检查每个I/O。我后来改成让它先列出所有可能抛异常的点，再逐个补try/except，比直接说“加错误处理”管用多了。还有个歪招是让它写完先自己review一遍，专门挑哪里没做异常捕获，输出成清单再改。你也可以试试把要求拆成具体的函数名和异常类型，越具体它越不容易糊弄过去。

512确实太碎，我一般按段落切再留点overlap，效果稳不少。

这个问题我太有同感了，之前做客服Agent的时候也踩过一模一样的坑。后来发现关键不是背景给得不够多，而是LLM天然会把“背景描述”和“硬性约束”当成同一类东西，然后按概率去压缩，那些出现频率低的规则就最先被丢掉。我的做法是把退款窗口这种必须保留的点单独拎出来，做成一个结构化的checklist，在生成完之后再让另一个小模型专门去核对，缺了就重写对应段落。另外你可以试试把约束条件写成带优先级的指令，

这个坑我也踩过，Cursor默认的训练数据里老项目占比太高，光在prompt里喊用hooks确实不太稳。你可以在项目根目录加一个.cursorrules文件，明确写死“只用函数组件和hooks，禁用class组件和ReactDOM.render”，再带上React 18的API示例，基本就能压住了。另外tsconfig里把jsx设成react-jsx也能帮它少走弯路。

我踩过同样的坑，后来发现核心问题是模型对“明天几点开会”这种没显式提到日历的句子，根本不知道要调工具。你可以在Function Description里把日历API的描述改成“查询、创建或修改用户的日程安排，包括会议、提醒、预约时间等”，比加例子管用。另外别指望纯Prompt解决所有歧义，我现在的做法是加一层轻量规则兜底，比如句子里出现“几点、开会、日程、安排”就直接走日历，命中率能到九成以上。真

两个都用过，Milvus 功能全但部署确实重，etcd、minio、pulsar 一套下来运维成本不低，小团队容易吃不消。Qdrant 单机跑起来很轻快，Rust 写的性能也不错，但分布式这块成熟度还是差点意思，集群踩过几次坑。我们后来选了 Qdrant，主要是数据量没到亿级，够用还省心。你们大概什么量级？量小其实可以优先考虑 Qdrant。

我之前也踩过分段的坑，后来发现纯按512切真的不行，经常把一句话拦腰截断。现在用的是先按标题和段落粗分，超过阈值再滑动窗口切，重叠个10%到15%效果会好不少。bge-large-zh对通用语料还行，但你们要是金融医疗这种专业领域，建议拿业务数据微调一下，或者试试bge-m3，检索和长文本表现会更稳。

8G显存跑Qwen2.5-Coder的7B量化版其实还行，我用过一阵子，补全够快但别指望它跨文件重构有多聪明。Continue那套跨文件确实容易乱，它主要靠你手动@文件给上下文，你得自己喂准了才靠谱。真要理解项目结构，目前开源里我没遇到特别省心的，基本都得配合RAG或者自己写点索引脚本。个人建议补全用小的本地模型，重构这种重活偶尔切个云端大模型，别硬扛。

我也遇到过，感觉不是bug，是模型在长上下文里容易“过度解读”。你把JSON结构一贴，它就觉得得帮你做数据缓存、状态同步，反而堆了一堆没用的抽象。我现在的做法是分两步：先让它出最简结构，跑通后再单独提需求加逻辑，比一口气喂一堆细节靠谱多了。

Python SDK就够用了，十个人并发几千条数据根本压不垮，别纠结性能，先跑通再说。

中文别按字数切，试试按标点和段落递归分，separators把句号、分号、逗号排前面。

我也这样过，FastAPI那块尤其明显，AI生成的依赖注入和中间件链我当时压根没细看。后来我逼自己一个笨办法：每次让Cursor生成完，挑最看不懂的那段让它逐行解释，然后自己用注释重写一遍，跑通再删掉AI的版本。效率是慢了点，但三个月下来至少交接时我不心虚了。你那个async上下文管理器嵌套，大概率是它为了处理异常和资源释放硬凑的，拆开看其实没那么玄。

中文分块确实挺头疼的，我最近也在折腾类似的东西。你试的256和512对中文来说其实偏小了，中文一个字的信息密度比英文单词高不少，512 token对中文可能就三四百字，长一点的条款肯定被腰斩。我后来换成按标点做递归分割，separators设成["\n\n", "\n", "。", "！", "？", "；", "，"]这种顺序，优先在段落和句号处切，效果比纯按长度好很多。不过说实话，光调sepa