猫收集工具日记

7B这规模DDP通信开销占比太大，得用张量并行或者ZeRO stage2才行。

500条数据确实少了，工具调用顺序这种模式很难靠LoRA硬学出来，建议先扩到2000条以上再试。 rank64偏高容易过拟合，试试16到32，另外把工具描述和示例对齐到训练时的token长度看看。

重排序真的能救，尤其你这种长文档，bge对操作步骤的理解确实偏弱，试试bge-reranker吧。

试试把大任务拆成小步骤一步步喂，每步只聚焦一个点，比堆一堆要求管用。 拆成多步喂吧，目标越小模型越不容易自作主张，异常处理单独给个示例更靠谱。

说实话这问题我折腾过好久，最后发现除了clip skip，vae的dtype和upscaler算法也会影响，特别是SDXL对vae精度特别敏感。还有个坑是ComfyUI默认会跑full pipeline，而WebUI某些版本会偷偷开refiner或者面部修复，这俩对结果影响巨大。你可以把WebUI的setting里所有优化选项全关掉再试试，尤其那个taesd或者tiled vae，我上次就是这么对

4060Ti跑7B Q4这速度正常，换vLLM能提升但别指望质变，70B就别想了，试试把历史对话截断到最近几轮。

这锅得让模型背一半，Qwen2.5对参数类型约束就是弱，换GLM-4-Flash或者Functionary试试，稳很多。 要不试试把工具参数示例直接写进system prompt里，多给几个正例，比调模板管用。

A100 80G跑4bit的8B模型，batch size=4按理说不该炸，大概率是序列2048太长，加上没开gradient checkpointing，激活值占了大头。先把checkpointing打开，batch size调到8试试，显存占用能掉一大截。代码补全和对话微调确实不太一样，代码任务学习率可以稍微调低点（比如1e-4到2e-4），warmup步数也短一些，因为代码分布更结构化，收敛

500条数据做多轮工具调用确实有点紧，尤其连续调用时模型容易把工具ID和上下文搞混，我建议先试试把每条训练样本里的工具描述和调用顺序用分隔符强化一下，比如在user和assistant之间显式标注当前步骤。LoRA rank 64对8B来说偏高，降到16或32通常更稳，不然微调过头会覆盖base模型的工具选择能力。另外temperature别动，保持0.2左右，重点检查下你的system prom

完全同意高美感低可控这个结论，本质上是把2D扩散的空间先验强行外推到时间轴，没引入物理引擎做约束。现在跑出来的片段，单帧截图能当壁纸，但连续播放时重力感和碰撞反馈基本是薛定谔状态。我的疑虑在于：他们V2如果继续走美学优先路线，大概率会在时序一致性上继续妥协，毕竟蒸馏审美数据和构建运动物理模型是两条互斥的技术路径。好奇你有没有测试过特定动作指令（比如投掷、跳跃）的失败率分布？