Skip to content

Latest commit

 

History

History
18 lines (17 loc) · 1.37 KB

File metadata and controls

18 lines (17 loc) · 1.37 KB
  • MLX SFT ignored training.gradient_accumulation_steps (#684 by @AmirF194 in #696). The wrapper built mlx-lm's TrainingArgs without a grad_accumulation_steps kwarg, so mlx-lm's own dataclass default of 1 always applied regardless of the configured value, silently changing the effective batch size and optimizer-update cadence on every MLX run. The written adapter_config.json also hardcoded grad_accumulation_steps: 1, so the drift could not be detected from the output afterwards either. Both now carry the value training.gradient_accumulation_steps actually resolves to. iters is also rounded down to a whole number of accumulation groups (kept at a minimum of one group), because mlx-lm only updates the optimizer on it % accum == 0 and never flushes a trailing partial group; without this a dataset smaller than the accumulation window trained for zero optimizer updates.

    Anyone who never touched this field will see a different effective batch size after upgrading. gradient_accumulation_steps defaults to 4, so an MLX run that used to update on every micro-batch now accumulates over 4 before updating: a 4x larger effective batch size and roughly a quarter as many optimizer updates for the same iters. This is the correct value for the schema default; a differently-converging run after this upgrade is expected, not a regression.