win11下用MOSS-TTS Local Transformer v1.5 微调出现的错误

[freenewfree]

尊敬的项目组：
你们好，今天在用贵项目组的MOSS-TTS Local Transformer v1.5 在win下进行微调，运行完数据预处理，进行最终微调训练时，出现如下错误：

D:\ai\MOSS-TTS\moss_tts_local_v1.5\finetuning>"D:\ai\MOSS-TTS\py312\Scripts\accelerate.exe" launch --mixed_precision bf16 sft.py --model-path "D:\ai\MOSS-TTS\autodl-tmp\models\MOSS-TTS-Local-Transformer-v1.5" --codec-path "D:\ai\MOSS-TTS\autodl-tmp\models\MOSS-Audio-Tokenizer-v2" --codec-weight-dtype fp32 --codec-compute-dtype bf16 --train-jsonl "D:\ai\MOSS-TTS\autodl-tmp\data1.5\train_with_codes.jsonl" --output-dir "D:\ai\MOSS-TTS\autodl-tmp\output\moss_tts_local_v1_5_sft" --per-device-batch-size 1 --gradient-accumulation-steps 8 --learning-rate 1.0e-5 --warmup-ratio 0.03 --lr-scheduler-type constant --num-epochs 3 --mixed-precision bf16 --channelwise-loss-weight 1,2.6666666666666665,2.6666666666666665,2.6666666666666665,2.6666666666666665,2.6666666666666665,2.6666666666666665,2.6666666666666665,2.6666666666666665,2.6666666666666665,2.6666666666666665,2.6666666666666665,2.6666666666666665 --gradient-checkpointing --attn-implementation flash_attention_2 --skip-nonfinite-batches
The following values were not passed to accelerate launch and had defaults used instead:
--num_processes was set to a value of 1
--num_machines was set to a value of 1
--dynamo_backend was set to a value of 'no'
To avoid this warning pass in values for each of the problematic parameters or run accelerate config.
[2026-06-27 23:22:05] [sft] global_batch_size=1 x 1 x 8 = 8
[2026-06-27 23:22:05] [sft] distributed_type=DistributedType.NO num_processes=1 using_pre_sharded_files=False train_files=1 local_train_files=1 local_train_records=71
The tokenizer you are loading from 'D:\ai\MOSS-TTS\autodl-tmp\models\MOSS-TTS-Local-Transformer-v1.5' with an incorrect regex pattern: https://huggingface.co/mistralai/Mistral-Small-3.1-24B-Instruct-2503/discussions/84#69121093e8b480e709447d5e. This will lead to incorrect tokenization. You should set the fix_mistral_regex=True flag when loading this tokenizer to fix this issue.
Loading weights: 100%|████████████████| 438/438 [00:00<00:00, 4335.92it/s, Materializing param=transformer.norm.weight]
[2026-06-27 23:22:06] [sft] attn=flash_attention_2 model_dtype=torch.bfloat16 n_vq=12 channelwise_loss_weight=[1.0, 2.6666666666666665, 2.6666666666666665, 2.6666666666666665, 2.6666666666666665, 2.6666666666666665, 2.6666666666666665, 2.6666666666666665, 2.6666666666666665, 2.6666666666666665, 2.6666666666666665, 2.6666666666666665, 2.6666666666666665] gradient_checkpointing=True gradient_checkpointing_impl=module_wrapper gradient_checkpointing_scope=global gradient_checkpointing_use_reentrant=False
[2026-06-27 23:22:09] [sft] scheduler=constant warmup_steps=1 local_micro_batches_per_epoch=71 micro_batches_per_epoch=71 dropped_local_micro_batches_per_epoch=0 optimizer_steps_per_epoch=9 max_train_steps=27
[2026-06-27 23:23:14] [sft] warning: Non-finite gradient norm at epoch=0 global_step=0: nan. first_nonfinite_grad=transformer.embed_tokens.weight bad=388956160/388956160 dtype=torch.bfloat16 shape=(151936, 2560); record_ids=['29', '40', '65', '70', '1', '33', '18', '56']; skipped
[2026-06-27 23:24:20] [sft] warning: Non-finite gradient norm at epoch=0 global_step=0: nan. first_nonfinite_grad=transformer.embed_tokens.weight bad=388956160/388956160 dtype=torch.bfloat16 shape=(151936, 2560); record_ids=['67', '28', '25', '3', '23', '6', '34', '14']; skipped
[2026-06-27 23:25:27] [sft] warning: Non-finite gradient norm at epoch=0 global_step=0: nan. first_nonfinite_grad=transformer.embed_tokens.weight bad=388956160/388956160 dtype=torch.bfloat16 shape=(151936, 2560); record_ids=['32', '66', '31', '41', '8', '51', '13', '22']; skipped
[2026-06-27 23:26:24] [sft] warning: Non-finite gradient norm at epoch=0 global_step=0: nan. first_nonfinite_grad=transformer.embed_tokens.weight bad=388956160/388956160 dtype=torch.bfloat16 shape=(151936, 2560); record_ids=['44', '45', '61', '68', '4', '20', '64', '50']; skipped
[2026-06-27 23:27:22] [sft] warning: Non-finite gradient norm at epoch=0 global_step=0: nan. first_nonfinite_grad=transformer.embed_tokens.weight bad=388956160/388956160 dtype=torch.bfloat16 shape=(151936, 2560); record_ids=['57', '2', '0', '11', '15', '19', '36', '38']; skipped

ient_checkpointing=True gradient_checkpointing_impl=module_wrapper gradient_checkpointing_scope=global gradient_checkpointing_use_reentrant=False
[2026-06-27 23:32:45] [sft] scheduler=constant warmup_steps=0 local_micro_batches_per_epoch=71 micro_batches_per_epoch=71 dropped_local_micro_batches_per_epoch=0 optimizer_steps_per_epoch=9 max_train_steps=27
Traceback (most recent call last):
File "D:\ai\MOSS-TTS\moss_tts_local_v1.5\finetuning\sft.py", line 1173, in
main()
File "D:\ai\MOSS-TTS\moss_tts_local_v1.5\finetuning\sft.py", line 1107, in main
raise FloatingPointError(message)
FloatingPointError: Non-finite gradient norm at epoch=0 global_step=0: nan. first_nonfinite_grad=transformer.embed_tokens.weight bad=388956160/388956160 dtype=torch.bfloat16 shape=(151936, 2560); record_ids=['29', '40', '65', '70', '1', '33', '18', '56']
Traceback (most recent call last):
File "", line 198, in _run_module_as_main
File "", line 88, in run_code
File "D:\ai\MOSS-TTS\py312\Scripts\accelerate.exe_main.py", line 5, in
File "D:\ai\MOSS-TTS\py312\Lib\site-packages\accelerate\commands\accelerate_cli.py", line 50, in main
args.func(args)
File "D:\ai\MOSS-TTS\py312\Lib\site-packages\accelerate\commands\launch.py", line 1407, in launch_command
simple_launcher(args)
File "D:\ai\MOSS-TTS\py312\Lib\site-packages\accelerate\commands\launch.py", line 993, in simple_launcher
raise subprocess.CalledProcessError(returncode=process.returncode, cmd=cmd)
subprocess.CalledProcessError: Command '['D:\ai\MOSS-TTS\py312\python.exe', 'sft.py', '--model-path', 'D:\ai\MOSS-TTS\autodl-tmp\models\MOSS-TTS-Local-Transformer-v1.5', '--codec-path', 'D:\ai\MOSS-TTS\autodl-tmp\models\MOSS-Audio-Tokenizer-v2', '--codec-weight-dtype', 'fp32', '--codec-compute-dtype', 'bf16', '--train-jsonl', 'D:\ai\MOSS-TTS\autodl-tmp\data1.5\train_with_codes.jsonl', '--output-dir', 'D:\ai\MOSS-TTS\autodl-tmp\output\moss_tts_local_v1_5_sft', '--per-device-batch-size', '1', '--gradient-accumulation-steps', '8', '--learning-rate', '2.0e-5', '--warmup-ratio', '0', '--lr-scheduler-type', 'constant', '--num-epochs', '3', '--mixed-precision', 'bf16', '--channelwise-loss-weight', '1,32', '--gradient-checkpointing', '--attn-implementation', 'flash_attention_2']' returned non-zero exit status 1.

这是在AI的帮助下，进行的微调参数训练的，训练音频数据（AU转为标准的48KHZ 2声道，16bit，1536kbps）从中文改为纯数字，文本内容也把阿拉伯数字都改为一、二、三之类的，包括特殊符号都去除，只留下，。？、等常用标点符号，但都是出现上面的错误，请问是1.5不支持在win下微调吗？还是代码刚发布，还有bug需要调整呢，望回复为盼！感激🙏

[YWMditto]

@codex Try to provide an answer.

[chatgpt-codex-connector]

答复

我看了一下你贴出的日志和仓库里的 v1.5 微调代码，这个报错不像是“v1.5 完全不支持 Windows 微调”导致的，更像是训练一开始就发生了 BF16 数值不稳定 / 梯度溢出，所以 sft.py 主动中止训练。

关键日志是：

Non-finite gradient norm at epoch=0 global_step=0: nan
first_nonfinite_grad=transformer.embed_tokens.weight
dtype=torch.bfloat16

仓库代码里也能对应上：sft.py 在 loss 或 grad norm 变成非有限值时会报错；如果传了 --skip-nonfinite-batches，则会跳过该 batch，否则直接抛出 FloatingPointError。这正是你日志里的行为。代码中还明确提示 non-finite loss 通常表示 BF16 训练不稳定或 batch 异常。

建议按下面顺序排查/尝试：

1. 先把训练精度从 BF16 改成 FP32 验证稳定性
   你的命令用了 --mixed_precision bf16 和 --mixed-precision bf16，而代码在 CUDA 可用时会把模型 dtype 解析为 torch.bfloat16。
   建议先改成：

   accelerate launch --mixed_precision no sft.py ... --mixed-precision no ...

   如果 FP32 能正常开始训练，基本可以确认是 BF16 数值稳定性/显卡 BF16 支持/算子兼容问题。

2. 不要强制 flash_attention_2，先用 sdpa 或 eager
   你命令里强制了：

   --attn-implementation flash_attention_2

   代码里如果 --attn-implementation auto，会根据 CUDA、flash_attn 是否安装、显卡能力和 dtype 自动选择；不满足条件时会回退到 sdpa 或 eager。
   Windows 下 FlashAttention 2 兼容性通常更容易出问题，建议先改为：

   --attn-implementation sdpa

   或者直接：

   --attn-implementation auto

3. 降低学习率和 loss 权重
   你第一次用了 1.0e-5，第二段日志里命令显示用了 2.0e-5，而且 --channelwise-loss-weight 1,32 会把总音频 loss 权重设为 32 并平均分到 12 个 RVQ head。
   对只有 71 条样本的小数据集来说，建议先保守一点，例如：

   --learning-rate 1.0e-6
   --channelwise-loss-weight 1,12

   或先使用默认/较小权重验证能否稳定跑起来。

4. 先去掉 --gradient-checkpointing 做一次小步验证
   文档里的单卡基线确实包含 --gradient-checkpointing，但这属于节省显存的稳定性相关可调项。
   如果显存允许，建议先去掉它，确认不是 checkpointing + BF16 + Windows/CUDA 组合引起的问题。

5. 检查数据 batch，不要只依赖 --skip-nonfinite-batches
   你第一次加了 --skip-nonfinite-batches，日志显示连续跳过多个 batch；这说明不是单条脏数据那么简单，可能是整体配置/精度不稳定。--skip-nonfinite-batches 只是避免立即退出，不是根治方法。

可以先试一个更保守的命令骨架：

accelerate launch --mixed_precision no sft.py ^
  --model-path "D:\ai\MOSS-TTS\autodl-tmp\models\MOSS-TTS-Local-Transformer-v1.5" ^
  --codec-path "D:\ai\MOSS-TTS\autodl-tmp\models\MOSS-Audio-Tokenizer-v2" ^
  --codec-weight-dtype fp32 ^
  --codec-compute-dtype fp32 ^
  --train-jsonl "D:\ai\MOSS-TTS\autodl-tmp\data1.5\train_with_codes.jsonl" ^
  --output-dir "D:\ai\MOSS-TTS\autodl-tmp\output\moss_tts_local_v1_5_sft" ^
  --per-device-batch-size 1 ^
  --gradient-accumulation-steps 8 ^
  --learning-rate 1.0e-6 ^
  --warmup-ratio 0.03 ^
  --lr-scheduler-type constant ^
  --num-epochs 3 ^
  --mixed-precision no ^
  --channelwise-loss-weight 1,12 ^
  --attn-implementation sdpa

如果这样能跑，再逐步打开：

1. --mixed-precision bf16
2. --codec-compute-dtype bf16
3. --gradient-checkpointing
4. --attn-implementation flash_attention_2

这样可以定位到底是哪一项触发了 NaN。

结论：当前信息更像是 BF16/FlashAttention/超参数组合导致的训练数值不稳定，不足以判断为 Windows 不支持或代码必然有 bug。 建议先用 FP32 + SDPA + 低学习率验证一轮；如果 FP32 仍然在第一个 step 就 NaN，再重点检查预处理后的 train_with_codes.jsonl 中对应 record_ids 的音频码、文本长度、空文本、异常 token 或过长样本。

Testing

• ✅ pwd && rg --files -g 'AGENTS.md' -g 'sft.py' -g 'README*' -g '*.md' | head -100
• ✅ find .. -name AGENTS.md -print
• ✅ rg -n "mixed|bf16|fp32|flash_attention|gradient|Non-finite|skip|Windows|win|accelerate|fix_mistral" moss_tts_local_v1.5/finetuning/README_zh.md moss_tts_local_v1.5/finetuning/sft.py moss_tts_local_v1.5/README.md README_zh.md
• ✅ nl -ba moss_tts_local_v1.5/finetuning/README_zh.md | sed -n '130,230p'; nl -ba moss_tts_local_v1.5/finetuning/sft.py | sed -n '120,205p'; nl -ba moss_tts_local_v1.5/finetuning/sft.py | sed -n '1070,1110p'; git status --short
• ✅ nl -ba moss_tts_local_v1.5/finetuning/sft.py | sed -n '248,296p'; nl -ba moss_tts_local_v1.5/finetuning/README_zh.md | sed -n '221,227p'

View task →

[freenewfree]

答复

我看了一下你贴出的日志和仓库里的 v1.5 微调代码，这个报错不像是“v1.5 完全不支持 Windows 微调”导致的，更像是训练一开始就发生了 BF16 数值不稳定 / 梯度溢出，所以 sft.py 主动中止训练。

关键日志是：

Non-finite gradient norm at epoch=0 global_step=0: nan
first_nonfinite_grad=transformer.embed_tokens.weight
dtype=torch.bfloat16

仓库代码里也能对应上：sft.py 在 loss 或 grad norm 变成非有限值时会报错；如果传了 --skip-nonfinite-batches，则会跳过该 batch，否则直接抛出 FloatingPointError。这正是你日志里的行为。代码中还明确提示 non-finite loss 通常表示 BF16 训练不稳定或 batch 异常。

建议按下面顺序排查/尝试：

1. 先把训练精度从 BF16 改成 FP32 验证稳定性
   你的命令用了 --mixed_precision bf16 和 --mixed-precision bf16，而代码在 CUDA 可用时会把模型 dtype 解析为 torch.bfloat16。
   建议先改成：
   accelerate launch --mixed_precision no sft.py ... --mixed-precision no ...

   如果 FP32 能正常开始训练，基本可以确认是 BF16 数值稳定性/显卡 BF16 支持/算子兼容问题。

2. 不要强制 flash_attention_2，先用 sdpa 或 eager
   你命令里强制了：
   --attn-implementation flash_attention_2

   代码里如果 --attn-implementation auto，会根据 CUDA、flash_attn 是否安装、显卡能力和 dtype 自动选择；不满足条件时会回退到 sdpa 或 eager。
   Windows 下 FlashAttention 2 兼容性通常更容易出问题，建议先改为：
   --attn-implementation sdpa

   或者直接：
   --attn-implementation auto

3. 降低学习率和 loss 权重
   你第一次用了 1.0e-5，第二段日志里命令显示用了 2.0e-5，而且 --channelwise-loss-weight 1,32 会把总音频 loss 权重设为 32 并平均分到 12 个 RVQ head。
   对只有 71 条样本的小数据集来说，建议先保守一点，例如：
   --learning-rate 1.0e-6
   --channelwise-loss-weight 1,12

   或先使用默认/较小权重验证能否稳定跑起来。

4. 先去掉 --gradient-checkpointing 做一次小步验证
   文档里的单卡基线确实包含 --gradient-checkpointing，但这属于节省显存的稳定性相关可调项。
   如果显存允许，建议先去掉它，确认不是 checkpointing + BF16 + Windows/CUDA 组合引起的问题。

5. 检查数据 batch，不要只依赖 --skip-nonfinite-batches
   你第一次加了 --skip-nonfinite-batches，日志显示连续跳过多个 batch；这说明不是单条脏数据那么简单，可能是整体配置/精度不稳定。--skip-nonfinite-batches 只是避免立即退出，不是根治方法。

可以先试一个更保守的命令骨架：

accelerate launch --mixed_precision no sft.py ^
--model-path "D:\ai\MOSS-TTS\autodl-tmp\models\MOSS-TTS-Local-Transformer-v1.5" ^
--codec-path "D:\ai\MOSS-TTS\autodl-tmp\models\MOSS-Audio-Tokenizer-v2" ^
--codec-weight-dtype fp32 ^
--codec-compute-dtype fp32 ^
--train-jsonl "D:\ai\MOSS-TTS\autodl-tmp\data1.5\train_with_codes.jsonl" ^
--output-dir "D:\ai\MOSS-TTS\autodl-tmp\output\moss_tts_local_v1_5_sft" ^
--per-device-batch-size 1 ^
--gradient-accumulation-steps 8 ^
--learning-rate 1.0e-6 ^
--warmup-ratio 0.03 ^
--lr-scheduler-type constant ^
--num-epochs 3 ^
--mixed-precision no ^
--channelwise-loss-weight 1,12 ^
--attn-implementation sdpa
如果这样能跑，再逐步打开：

1. --mixed-precision bf16
2. --codec-compute-dtype bf16
3. --gradient-checkpointing
4. --attn-implementation flash_attention_2

这样可以定位到底是哪一项触发了 NaN。

结论：当前信息更像是 BF16/FlashAttention/超参数组合导致的训练数值不稳定，不足以判断为 Windows 不支持或代码必然有 bug。 建议先用 FP32 + SDPA + 低学习率验证一轮；如果 FP32 仍然在第一个 step 就 NaN，再重点检查预处理后的 train_with_codes.jsonl 中对应 record_ids 的音频码、文本长度、空文本、异常 token 或过长样本。

Testing

• ✅ pwd && rg --files -g 'AGENTS.md' -g 'sft.py' -g 'README*' -g '*.md' | head -100
• ✅ find .. -name AGENTS.md -print
• ✅ rg -n "mixed|bf16|fp32|flash_attention|gradient|Non-finite|skip|Windows|win|accelerate|fix_mistral" moss_tts_local_v1.5/finetuning/README_zh.md moss_tts_local_v1.5/finetuning/sft.py moss_tts_local_v1.5/README.md README_zh.md
• ✅ nl -ba moss_tts_local_v1.5/finetuning/README_zh.md | sed -n '130,230p'; nl -ba moss_tts_local_v1.5/finetuning/sft.py | sed -n '120,205p'; nl -ba moss_tts_local_v1.5/finetuning/sft.py | sed -n '1070,1110p'; git status --short
• ✅ nl -ba moss_tts_local_v1.5/finetuning/sft.py | sed -n '248,296p'; nl -ba moss_tts_local_v1.5/finetuning/README_zh.md | sed -n '221,227p'

View task →

非常感谢您的详细回复，我抽空就按照您的回复，仔细测试一下，感激不尽🙏

[freenewfree]

官方团队你们好，已经按照你们提供的参数规范，对清洗对齐后的数据集（data1.5 严格切出 12 层 RVQ 维度，已剔除长音频，仅保留 3-10 秒短音频）进行了多次严格验证。

无论使用标准 BF16 还是官方纯 FP32 验证模式，均在启动微调、反向传播结束后的第一步优化器更新（optimizer.step()）时刻精准报 OOM 强退。以下是客观测试现象与核心日志：

1. 纯 FP32 验证模式（未开启梯度检查点）
   运行指令：
   accelerate launch --mixed-precision no sft.py --model-path ... --codec-path ... --codec-weight-dtype fp32 --codec-compute-dtype fp32 --train-jsonl ... --per-device-batch-size 1 --gradient-accumulation-steps 8 --channelwise-loss-weight 1,12 --attn-implementation sdpa
   核心报错日志：
   [2026-07-09 17:12:05] [sft] global_batch_size=1 x 1 x 8 = 8
   [2026-07-09 17:12:05] [sft] local_train_records=52
   [2026-07-09 17:12:06] [sft] attn=sdpa model_dtype=torch.bfloat16
   ...
   File "D:\ai\MOSS-TTS\py312\Lib\site-packages\torch\optim\adam.py", line 181, in _init_group
   state["exp_avg_sq"] = torch.zeros_like(...)
   torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 48.00 MiB. GPU 0 has a total capacity of 15.93 GiB of which 0 bytes is free. Of the allocated memory 29.97 GiB is allocated by PyTorch

2. 定位死因分析（物理死锁）数据已洗净：当前 local_train_records=52 且音频截断在 3-10 秒，数据路径和 12 层维度完全无冲突。

崩溃临界点：在 BF16/FP32 状态下，前向和反向传播计算均成功通过，但在 sft.py 的第 1109 行执行 optimizer.step() 时，原生 AdamW 优化器在为模型参数分配二阶动量状态（exp_avg_sq）时，由于硬性分配 48.00 MiB 的刚性显存需求，精准顶爆了 16G 显存的上限。

平台局限性：在 Windows 宿主机环境下，PyTorch 抛出警告 UserWarning: expandable_segments not supported on this platform，导致无法通过 PYTORCH_CUDA_ALLOC_CONF 环境变量回收中间显存碎片。

3. 希望官方协助支持：
   鉴于目前本地 16G 显存卡死在 AdamW 初始化的最后 48MB 分配上，请问官方：

sft.py 后续是否可以开放 --optimizer 传参接口，允许用户从外部传入类似 adamw_bnb_8bit 或 Adafactor 等轻量化优化器？

如果不修改源码，在本地 Windows 单卡 16G 环境下，官方是否有其他不依赖 Linux (WSL2) 的显存优化或超参数推荐？

期待你们的回复，谢谢！