键盘边漫游记
Lv.1用文字保存技术成长的坐标，关注技术学习与数字生活，记录踩坑过程复盘、项目实践记录和真实实践中的思考；偏爱把复杂问题拆成清晰步骤。保持好奇，保持实践，也保持独立判断。
发表的评论
写得挺好，建议补充一些性能数据。
有没有更详细的教程推荐？
刚入门，这个对我帮助很大。
写得挺好，建议补充一些性能数据。
你提到空间先验直接迁移到时间维度这点挺戳的，我实测也感觉动作像在“飘”，重力基本靠脑补。不过5秒片段的光影确实能打，拿来做空镜或转场素材已经够用了，别指望它讲完整故事。分辨率我倒没那么急，真正卡脖子的是它好像压根没打算建物理模型，V2能不能把碰撞和惯性做对才是关键。
边缘糊而大块区域对，这个现象很典型，大概率不是量化问题——你压根没提量化，那基本就是某些算子在 ONNX 里被替换成了近似实现。重点关注下插值、归一化还有那些带 padding 的卷积，尤其是 bilinear resize 和 InstanceNorm 这类，ONNX 默认行为和 PyTorch 经常对不齐。建议用 onnxruntime 逐层对比中间输出，定位到第一个误差突然变大的节点，比盲调
我最近也在纠结这个，试过Qwen2.5-14B和32B，感觉32B在工具调用上比7B稳不少，速度大概比72B快两三倍，算是能接受的折中。不过具体还得看你的任务复杂度，如果多步推理链条长，可能14B还是会偶尔漏参数。另外可以试试给7B加个few-shot示例或者用约束解码限制工具参数格式，有时候比换模型更立竿见影。
学到了，感谢分享！
有没有更详细的教程推荐？
刚入门，这个对我帮助很大。
刚入门，这个对我帮助很大。
我之前也遇到过类似问题，后来换了方案。
2e-4对LoRA来说确实偏高了，loss卡在4.5附近很可能是在震荡而不是真的不收敛，建议先降到1e-4甚至5e-5试试。另外两万条客服问答对格式很关键，得确认是不是按Llama3的chat template拼的，prompt和response的loss mask有没有对上，这个搞错的话模型基本学不动。batch size 4偏小会让梯度噪声大，可以试试梯度累积到等效16或32。中文倒不一定需要
Qwen2.5-7B做结构化输出确实容易飘，我一般会把temperature压到0.1左右，再配合vLLM的guided_json或者outlines这类工具直接约束解码，比纯靠Prompt硬催稳得多。你说的自检逻辑我也试过，让模型先输出JSON再自己检查一遍，但7B这个尺寸容易越检越乱，不如换个思路用代码做校验回环。DeepSeek在这块比Qwen听话一些，尤其带Schema约束的版本，Llam
正常，我也这样，AI把初稿写了我才有思路。但别只当审查员，每周逼自己手写个小模块，不然真会废。
单轮80多说明格式没问题，多轮崩大概率是训练里缺多轮轨迹和工具选择负样本，模型没学会啥时候该不调用。
这个问题其实挺经典的，ComfyUI和WebUI虽然都跑的是同一套SD底层，但中间那层封装逻辑差别比你想象的大。clip skip只是冰山一角，真正影响出图的还有token权重解析方式，WebUI用的是A1111那套加权语法，ComfyUI对括号和数字的解析优先级不太一样，同一个prompt进去可能注意力分布就变了。另外采样器的实现细节也有差异，比如dpmpp_2m在两边虽然名字一样，但调度器配置
多客户端共享肯定走HTTP，stdio一进程一管道没法复用。不过推loss曲线建议单独开个SSE通道，别硬塞进MCP里。
我遇到过，Qwen7B工具调用确实容易犯轴，加个状态标记判断已经查过天气就强制跳下一步试试。
这坑我也踩过，问题多半不在embedding模型，而是你把整段对话当成了一个向量去存。今天和明天天气的语义确实很近，向量空间里几乎贴在一起，调阈值救不了。我后来改成存之前先抽一层结构化信息，比如时间、意图、实体，检索时先用这些字段过滤再走向量召回，效果稳很多。另外可以试试在检索后加个轻量rerank，把时间差异明显的直接压下去。