大模型微调sft需要多久，从零开始的完整步骤和常见问题

准备做 SFT 的人最常问的一句就是「这活儿要多久」，但真正卡人的往往不是训练本身，而是数据清洗、环境跑通和反复试跑。这篇按「先定位耗时项、再排步骤、最后对常见问题」的顺序讲，让你在动手前就能给出一份能对得上的时间表，也说明哪些情况下这套估算不成立。

准备做 SFT 的人最常问的一句就是「这活儿要多久」。说实话，这个问题没有标准答案，但也不是没法估。关键在于别一上来就盯着训练那几小时，而是先把整件事拆成几块看清楚：数据准备、环境跑通、实际训练、验证返工，哪块最吃你的时间，心里就有数了。

这篇按「先定位耗时项、再排步骤、最后对常见问题」的顺序讲。目标是让你在动手前就能给出一份能对得上的时间表，同时也会说明哪些情况下这套估法不成立——毕竟拍脑袋排期，最后加班的是自己。

先弄清 SFT 的时间到底花在哪

多数人估 SFT 工期时只算训练，觉得卡跑几个小时就完事。实际上训练往往是最短的一段。把总耗时拆成四块来看，你会发现真正的黑洞常常在别处，尤其是第一次做的时候。

估时间的顺序：从显存和样本量倒推

估时间要从约束条件出发，而不是从愿望出发。第一步先确认模型规模和微调方式能不能塞进你手里的卡，显存不够的话，讨论耗时没有意义。到 /compute/sizing 按模型算一遍，心里先有个底。

1. 确认显存与微调方式先定全参还是低秩适配，用 /compute/sizing 按模型规模核对显存需求，塞不进去就先换方案或换卡。
2. 算总步数样本量除以批大小，再乘训练轮数，得到总步数。这一步只是算术，但很多人跳过。
3. 测单步耗时跑几十条样本的试跑，实测单步时间，比查别人的经验贴靠谱得多。
4. 相乘再加返工系数单步耗时乘总步数得到训练毛时间，再乘一个返工系数，才是能拿出去对的时间区间。
5. 核对成本卡型与租用价格到 /compute/gpu-rental 看当时的数字，微调与托管的总账对照 /compute/finetune。

这套倒推法的好处是每一步都可验证：显存能测、单步能测、总步数能算。唯一估不准的就是返工系数，所以给别人的时间表最好给区间而不是给一个数。

从零走一遍的完整步骤

下面这套顺序是按依赖关系排的，前一环没确认就别急着进下一环。很多返工其实是因为跳步：验证标准没写清就先训，训完发现方向不对，前面全白做。

• 定目标与验收标准：先写清什么算成功，最好能量化，避免训完才发现方向不对
• 准备数据：统一成指令-回答格式，划分训练与验证集，留一小份不参与训练的数据做终检
• 选基座与微调方式：全参还是低秩适配，直接决定显存和耗时量级
• 小规模试跑：几十到几百条样本跑通链路，确认能保存、能加载、能推理
• 正式训练并记录曲线：盯损失和验证表现，别只看训练集指标
• 导出权重、合并、部署验证：这一步经常被漏排进工期，别忘了留时间

如果对服务商能力拿不准，可以先到 /stacks/fine-tuning 对照各家提供的微调服务范围，再决定是自己训还是用托管方案。

这些情况下上面的估法不成立

倒推法好用，但它有个前提：数据是现成的、任务形态是常规文本。下面几种情况，拿这套公式去估会错得很离谱，得换一种排期思路。

还有一种情况：任务本身不适合微调。比如你就是想让模型记住一批会经常变的事实，那检索增强更合适，硬上 SFT 既费时又不一定稳。判断标准是：知识更新频率高、答案要求可溯源，就优先考虑检索方案。

能实测的就去实测，估不准的就给区间，别给同事一个看起来精确其实拍脑袋的数字。