周末深度学习方法论
Lv.1主要整理深度学习相关的学习笔记与工程经验，内容覆盖智能体工作流设计、提示词与上下文工程。喜欢从问题、方案到复盘形成完整闭环，希望把复杂问题讲清楚、把实践步骤写完整。
发表的评论
梯度检查点确实省显存，但它是拿计算换的，每层前向都得重算一遍，9小时不算离谱。序列打包这块你确认下attention mask对不对，packing没配好loss震荡很常见，尤其你平均6000 token这么长。可以试试FlashAttention加上unsloth或者Liger Kernel，能省不少激活值还不太掉速度。另外2万条×6000 token其实不小了，batch size压到1梯度噪
我们也是响应慢了快一半，超时都得往上调，token烧得心疼。边缘case退化这块有同感，灰度跑了两周才敢切主链路。
同感，我后来加了个话题切换检测才好转，不然它真能跟一个问题死磕到底。
老项目上下文太杂，Copilot确实容易犯迷糊，我一般只在新建独立模块时才开它。
量化加流水线并行确实能救，但7B开TP不如直接上AWQ，显存能压到20G以内，并发也能拉起来。
试过在 tool 里包一层 torchrun，MCP 拉起的进程环境变量确实得手动透传 rank 和 world_size，不然 init 必炸。
INT4量化后权重是5-6G没错，但你漏了KV cache这块，7B模型在4k上下文、batch size稍大点就容易多占好几个G，OOM基本都出在这。vLLM的PagedAttention对KV cache管理更细，延迟敏感场景我更推荐它，TGI配bitsandbytes有时反而不够灵活。建议先用vLLM跑起来，把gpu_memory_utilization调到0.85左右试试，再根据实际显存占
这个其实挺常见的，尤其分割模型里Resize和Pad这类op确实容易拖后腿，ORT的CPU EP对动态shape的Resize支持不算特别好，经常退化成比较慢的实现。你opset 12没问题，但ONNX Runtime跑CPU本身就不是强项，拿它跟PyTorch的CPU比其实参考意义有限，PyTorch底层也是oneDNN，而且很多op是融合过的。真正该看的是转成TensorRT engine之后
这确实是个高频坑，跟提问方式关系不大，更像是Chat模式在“自由发挥”时默认丢掉了上下文里的命名约定。我自己也遇到过类似情况，明明上一段代码里已经叫df_raw了，下一段它突然改叫raw_data，改到你怀疑人生。后来我基本养成了一个习惯：每次让它继续写之前，先手动把相关的那几行已有代码复制进去，哪怕只是一小段，它看到具体变量名后基本就不会乱起了。另外我会在提示里固定加一句“沿用已有变量名，不要新
8G跑7B默认是Q4量化，速度不该这么慢，看看是不是没走GPU或者模型加载到内存了。
微调确实会强绑定prompt格式，模型学到的不只是知识，还有你给的模板分布。我试过在训练数据里混20%的多样化模板，效果比死磕一个格式好不少，但混太多反而会让模型犯迷糊。你那个降质大概率是格式没对上触发了分布外，建议先按训练格式推理验证，再逐步加模板多样性。
其实你这个担心我特别能理解，但实操下来不用太焦虑。如果你只是拿7B base模型在query改写这种窄任务上做SFT，通用能力确实会有点漂移，不过关键是别把它当万能助手用——改写模型就干改写的事，生成还交给原来的大模型或者另一个实例，职责分开就不会互相拖累。我自己试过拿Qwen2.5-7B做类似的事，学习率压到1e-5以下、epoch控制在2以内，再混一点通用指令数据进去，开放域问答掉点很轻微，基
我之前也遇到过类似问题，后来换了方案。
刚入门，这个对我帮助很大。
BLEU涨了不代表生成质量就好，它跟实际可用性经常是两码事。你这种情况我遇到过，很可能是LoRA把base的泛化能力给带偏了，模型开始死记硬背你们仓库里的模式，导致重复变量名和幻觉API。建议试试降到1个epoch、学习率调到1e-4甚至更低，rank也可以先降到8看看。另外2万条数据对代码补全来说不算多，混一点通用代码数据进去可能能缓解过拟合。
Milvus集群模式运维挺重，小团队慎入；Qdrant单机爽但分布式还嫩，看数据量选吧。
Milvus的标量过滤确实分两种模式，你这种延迟暴涨大概率是走了post-filter路径，先做ANN再过滤，候选集不够就反复回退重查。可以看下执行计划里filter是不是在search之后，是的话把标量字段建倒排索引，再调大迭代次数试试。20万数据量其实不大，换个思路用分区key或者把过滤字段做成partition，性能会好很多，没必要急着换ES。
轮询确实笨，试试用SSE推MCP的notification，客户端订阅进度比反复调tool舒服多了。
你这个情况挺典型的，我之前做类似项目也踩过一模一样的坑。问“2023年营收”召回“2022年营收”，本质上不是模型不够强，而是纯向量检索对数字、年份这类细节太不敏感了，语义空间里这俩片段几乎挨在一起。我的经验是混合检索真的是刚需，BM25这类关键词召回能把“2023”这种精确token直接命中，再和向量结果做融合，比如用RRF，提升立竿见影。query扩展也值得试，但别搞太花，简单点的同义改写或者
我之前也踩过这个坑，拼接历史消息确实不太行，模型很容易把“上季度”这种相对时间搞混，因为它根本不知道现在是什么时候。后来我在每轮对话里加了一个隐式的上下文摘要，把时间实体、指标名、筛选条件这些关键信息单独抽出来存着，而不是一股脑塞聊天记录。这样即使用户后面只说了“那同比呢”，Agent也能从记忆里捞到对应的实体。不过摘要本身也会丢细节，尤其是数值类的，我现在是摘要加原始片段双轨走，重要实体从结构化