北岸读书集

7B模型开compile确实容易炸，我这边dynamic shape直接关掉才勉强跑通，但加速基本没感觉。

试试vLLM加GPTQ-Int8，比4bit稳不少，显存也够用。

我一般用tenacity包一层，配个指数退避，超时和网络错误自动重试，省心不少。

5k条垂直数据全量跑3个epoch，灾难性遗忘基本是必然的，跟rank关系不大。LoRA再轻量也是在改权重，领域数据太单一模型就只顾着学新东西了。建议掺10%-20%的通用指令数据进去，或者把epoch降到1-2，学习率也稍微调低点。我上次做法律领域微调也是这毛病，混了通用数据后通用能力就稳多了。

MCP现在确实不支持tool流式返回，我之前也卡在这。要不试试把长查询拆成几个小tool分批调？

500的固定切块容易把配置步骤拦腰截断，试试按标题切，再拿几个已知答案的问题测hit rate。

门票炒到多少其实跟干活的人关系不大，展台上那些流畅的demo我基本都持保留态度。你说的光照变化导致SLAM丢帧太真实了，我们做移动抓取时也发现，实验室里调好的参数换个仓库灯光就全废，最后不得不加主动光源和冗余传感器，成本直接翻倍。力控延迟50ms碎货这个我深有体会，夹爪闭环里通信和滤波随便省一步就等着捡碎片。通用性和专用性我觉得现阶段别硬追通用，先把一个场景的鲁棒性做到99%再谈泛化，否则就是到处

十几万条768维够用了，降维丢信息得不偿失，增量更新直接上Milvus省心。

同感，我后来用promptfoo跑批量测试才稍微靠谱点，不然真靠玄学。

2k序列长度在8B模型上确实挺吃显存的，LoRA虽然省了优化器状态，但激活值还是按全模型算。我3090上跑类似配置时把max_length砍到1024，再开Flash Attention 2，显存直接从22G掉到14G左右。ZeRO-3单卡收益不大，反而通信开销拖速度，不如先试试gradient accumulation配合更小的micro-batch。torch.compile在2.1上对LLM

我之前也踩过这坑，后来发现光靠prompt约束根本压不住模型乱编。我的做法是加一层轻量校验，把工具返回的JSON字段解析出来，生成后再拿关键数值去比对，比如温度、天气状态这些，不一致就直接用模板回填而不是让模型自由发挥。另外可以试试把工具结果放在tool角色消息里而不是硬塞system，Qwen对tool message的遵循度会好一些。

几十万数据单机跑的话Qdrant确实够用了，我去年一个项目就是768维五十万条，写入和过滤都挺顺的，payload过滤比Milvus写表达式舒服些。Milvus功能更全但单机跑那套依赖真挺劝退的，etcd加minio一套下来运维成本不低。不过你要是后面可能扩到千万级或者要多租户，那还是Milvus生态更稳一点。

这个问题其实挺典型的，我自己的经验是GPT在增量修改时特别容易“顺手”重构它觉得不够优雅的地方，哪怕你根本没让它动那块。它不像人类程序员会克制在最小改动范围内，而是每次都在重新理解整个代码意图，所以历史上下文一长，它就容易把之前的约束给稀释掉。我的做法是每次只贴需要改的那个函数，然后把其他不相关函数的完整代码用注释或者伪代码一笔带过，明确告诉它“以下代码块禁止修改”，这样它乱动的概率会低很多。另外

你这配置有个坑，awq是4bit量化，不是int8，vLLM加载awq权重时不会额外压缩，显存该占还是占。另外A100 40G跑7B的int8或awq，权重本身才7G左右，峰值冲到38G大概率是KV cache按默认max_model_len全预分配了，试试加上`--max-model-len 4096`和`--gpu-memory-utilization 0.85`限制一下。我之前也遇到过类似情

我也遇到过这个问题，Cursor默认就爱往“可扩展”方向写，哪怕你只想搞个简单表格。后来我发现在项目根目录放个.cursorrules文件，把“禁止新增抽象层、优先复用现有组件、单文件不超过100行”这些硬性规则写进去，比在prompt里反复强调管用多了。另外它确实对已有代码库的适配偏弱，如果项目结构复杂，最好在对话里直接@相关文件当上下文，不然它容易按自己的套路来。

这个现象其实挺常见的，不一定是代码写错了。你前两个epoch显存稳定，到第三个突然涨，很可能是PyTorch的缓存分配器在碎片化之后行为变了。BERT这种变长输入如果没做padding到固定长度，每个batch的实际序列长度不同，caching allocator会保留不同大小的block，时间一长碎片多了，它就会申请新的显存段而不是复用旧的。你可以试试torch.cuda.memory_summ

我一般只让它写单测和工具类，业务逻辑这块真得自己来。状态机这种建议先画清楚再拆成小函数让AI逐个实现，别指望它一口气写完整流程。另外把领域模型和关键约束写进prompt里比堆注释管用，比如明确告诉它时间比较的方向和边界条件。

这个场景我太熟了，表格和条款混排的文档，纯按字符数切基本就是灾难。建议先按标题层级切，再在叶子节点里做二次切分，表格单独抽出来走结构化解析。语义切分可以试，但别指望它解决层级断裂的问题，得配合metadata过滤才能精准召回。检索那块也可以考虑混合检索加rerank，光靠调chunk_size是绕不出去的。

loss降到1.2还输出“嗯嗯嗯”，大概率不是学习率的事，更像是数据格式或者chat template没对齐。你检查下训练时的prompt是不是用了Llama-3的special token，推理时又忘了加同样的模板，这种错位很容易让模型只会续写乱码。另外几千条法律问答对LoRA来说偏少，rank=8可能也压不住，建议先把训练集里的回答单独抽出来做一次base model推理，看它本身会不会重复，

这个现象其实挺常见的，7B级别的模型在few-shot上确实容易“抄答案”而不是“学规律”。你观察到它把示例话术当标准答案匹配，本质上是小模型在上下文里做模式复制，而不是抽象出分类边界。Qwen2.5-7B本身指令跟随还行，但量化之后注意力分布会更集中，示例里的具体词汇很容易变成强信号。我之前做类似任务时也踩过，后来把示例改成“输入-意图标签”的极简形式，不带任何多余话术，反而稳住了。另外温度0.