๐Ÿš€ Side-Step Queue Manager

Complete training configuration with LoRA/LoKR, Preprocessing++, and job queuing

โœจ Side-Step Training Form Configure training jobs with all adapter types (LoRA, DoRA, LoKR, LoHA, OFT), preprocessing tasks, and comprehensive parameter control. Queue multiple jobs and run them overnight!

Task Type

Model & Device

Path to ACE-Step checkpoints folder
Official ACE-Step models + XL variants

Job Identification

Optional: helps you identify this job in the queue
Organizational field - include this in your output directory path if you want it in your folder names

What is Run Name?

Simple explanation: An organizational name for this training run. In the wizard, this gets incorporated into the output path and TensorBoard logs. When using this form, include it manually in your "Output Directory" path.

How to use it:

  • Wizard mode: The wizard automatically adds it to paths
  • CLI/Form mode: Include it in your "Output Directory" field

Example:

  • Run Name: FMNICKS
  • Output Directory: ./output/Lora-FMNICKS-Turbo
  • Result: Easy to identify this run later!

Naming ideas:

  • FMNICKS - Artist/project name
  • rock_music_v1 - Genre + version
  • experiment_rank128 - What you're testing
  • bass_boost_lora - Descriptive feature
  • (leave empty) - No specific run name needed

Pro tip: Use consistent naming across your training runs to stay organized when you have 10+ LoRAs!

Impact:

Organization only - doesn't affect training

Training Paths

๐Ÿ’ก Path Format: Use your platform's native format. Windows: C:\folder\subfolder or Linux/Mac: /home/user/folder. Both absolute and relative paths work.
Directory with preprocessed .pt files

What is Dataset Directory?

Simple explanation: The folder containing your preprocessed training data (.pt files and manifest.json).

Path format examples:

  • Windows:
    • E:\ace-step-dataset\FMNICKS\tensors
    • C:\Users\YourName\Documents\my_training_data
    • .\data\tensors
  • Linux/Mac:
    • /home/user/ace-step-dataset/tensors
    • /mnt/data/my_music/preprocessed
    • ./data/tensors

What should be in this folder?

  • manifest.json - Metadata file listing all samples
  • *.pt files - Preprocessed tensor files (one per song)
  • Example: track_001.pt, track_002.pt, etc.

How to get this data:

  • Run preprocessing first (using the wizard or CLI)
  • Point "Audio Directory" to your raw audio files
  • Set "Tensor Output" to where you want .pt files saved
  • After preprocessing, use that same tensor output path here
Where to save adapter weights and logs

What is Output Directory?

Simple explanation: Where your trained LoRA/LoKR weights will be saved, along with checkpoints and TensorBoard logs.

Path format examples:

  • Windows:
    • E:\ace-step-dataset\FMNICKS\Lora-FMNICKS-Turbo
    • C:\Users\YourName\loras\my_rock_lora
    • .\output\experiment_1
  • Linux/Mac:
    • /home/user/loras/my_lora
    • /mnt/training/output/rock_music_v1
    • ./output/my_lora

What gets saved here:

  • adapter_model.safetensors - Your trained LoRA weights (the final result!)
  • adapter_config.json - Configuration metadata
  • checkpoint-epoch-N/ - Checkpoint folders for resuming training
  • runs/ - TensorBoard log files
  • training_args.json - Record of all settings used

Naming tips:

  • Include run name: Lora-FMNICKS-Turbo
  • Include model variant: my_lora_base
  • Include experiment info: rank128_lr0001
  • Stay organized: ./output/artist/experiment_1

โš ๏ธ Note: This folder will be created if it doesn't exist. Make sure the parent folder has write permissions.

Adapter Type

LoRA / DoRA Configuration

๐Ÿ’ก Quick Reference โ€” Rank & Alpha by Adapter:
Adapter Rank / Dim Alpha LR
LoRA 64โ€“128 2ร— rank (128โ€“256) 3e-4
DoRA 64โ€“128 2ร— rank (128โ€“256) 3e-4
LoKR 16โ€“32 1ร— dim (16โ€“32) 5e-4 โ€“ 1e-3
LoHA 16โ€“32 1ร— dim (16โ€“32) 3e-4 โ€“ 5e-4
OFT Block size 64 n/a 1e-4 โ€“ 3e-4
LoRA/DoRA: 64โ€“128 recommended. See table above for other adapters.

What is Rank?

Simple explanation: Controls how much the adapter can learn. Higher rank = more capacity, more VRAM. The right value depends heavily on which adapter you're using โ€” don't copy LoRA values into LoKR/LoHA.

LoRA / DoRA:

  • 16 โ€” Quick experiments, very small datasets (1โ€“5 songs)
  • 64 โ€” Recommended default for most cases
  • 128 โ€” Large datasets (50+ songs), maximum quality
  • 256 โ€” Rarely needed; only with 100+ songs

LoKR / LoHA: See the LoKR/LoHA configuration sections below โ€” these adapters use much lower values (16โ€“32) due to their more efficient parameterization.

Can rank be any integer? Yes โ€” any positive integer works. Powers of 2 (16, 32, 64, 128) are conventional but 48, 96, or 100 would also work.

VRAM: Higher = More Quality: Higher = More capacity (needs matching data)
LoRA/DoRA: 2ร— rank (rank 64 โ†’ alpha 128)

What is Alpha?

Simple explanation: Alpha scales the strength of the adapter's updates. The ratio of alpha to rank is what matters โ€” not the absolute value.

LoRA / DoRA rule: Alpha = 2 ร— rank

  • Rank 16 โ†’ Alpha 32
  • Rank 64 โ†’ Alpha 128
  • Rank 128 โ†’ Alpha 256

LoKR / LoHA rule: Alpha = 1 ร— dim (equal, not 2ร—). This is configured in their own sections below.

What happens if you change the ratio?

  • Alpha > 2ร— rank โ€” stronger updates, can overfit faster
  • Alpha = rank (1:1) โ€” conservative, more stable
  • Alpha < rank โ€” very weak updates, underfitting risk
Quality: Affects update strength VRAM: No impact
0.1 default, increase for small datasets (0.2-0.3)

What is Dropout?

Simple explanation: Dropout randomly "turns off" some learning during training. This prevents the AI from memorizing your specific songs instead of learning the general style.

Think of it like: Studying with occasional distractions. It forces your brain to really understand the material, not just memorize answers.

Valid values: 0.0 to 0.5 (it's a percentage, so 0.1 = 10%)

  • 0.05 - Large datasets (50+ songs), very diverse styles
  • 0.1 - Default, works for most cases
  • 0.2-0.3 - Small datasets (1-10 songs), similar songs

Problem it solves: "Overfitting" - when the AI memorizes your training songs instead of learning the style. Signs: perfect on training data, bad on new generations.

Impact:

VRAM: None Quality: Prevents overfitting Speed: None

What is Attention Type?

Simple explanation: The AI has two types of "learning modules" - one that learns about the music itself (self-attention), and one that learns how text prompts connect to music (cross-attention).

Your options:

  • Both (default) - Train everything. The AI learns both the music style AND how to follow your text prompts better.
  • Self-attention only - Only train music patterns (rhythm, instruments, mixing). Text prompts won't improve. Use if: training on instrumental music only.
  • Cross-attention only - Only train prompt understanding. Music style stays the same, but AI gets better at following specific words. Rare use case.

When to change: Stick with "Both" unless you're doing something very specific. Self-only makes sense for instrumental-only training.

Impact:

VRAM: Both=most, Self/Cross=half Quality: Both gives best results
Space-separated projection names

What are Target Modules?

Simple explanation: Inside each attention layer, there are 4 sub-parts (like 4 sub-workers). This setting chooses which sub-parts to train.

The four parts:

  • q_proj - "Query" - asks "what should I pay attention to?"
  • k_proj - "Key" - provides "here's what's important"
  • v_proj - "Value" - holds the actual information
  • o_proj - "Output" - combines everything together

How to write it: List the parts you want to train, separated by spaces:

  • q_proj k_proj v_proj o_proj - Train all 4 (recommended)
  • q_proj v_proj - Train only query and value (uses less VRAM)
  • q_proj k_proj - Just query and key (lightweight)

When to change: Only if you're low on VRAM or doing advanced experiments. Training all 4 gives best results.

Advanced: You can use the "estimate" mode to analyze which modules matter most for YOUR specific music, then train only those.

Impact:

VRAM: More modules = More VRAM Quality: All 4 = Best quality

What is Bias?

Simple explanation: Bias is like a "starting point" in the math that makes the AI work. This setting decides if we should also train those starting points or leave them alone.

Your options:

  • none - Don't train bias values (default, recommended)
  • lora_only - Train bias in your LoRA adapter only (slight quality improvement)
  • all - Train ALL bias values in the model (rarely needed)

When to change: Stick with "none" for 99% of use cases. Try "lora_only" if you're experimenting and want a tiny potential quality boost.

Impact:

VRAM: Minimal increase Quality: Minimal improvement
Custom projections for self-attention (when attention-type=both)

Advanced: Separate Targets for Self-Attention

What this does: Normally, the same target modules (q_proj, k_proj, etc.) are used for both self-attention and cross-attention. This lets you specify DIFFERENT targets for just the self-attention part.

When to use: Only if you've run gradient estimation and discovered that self-attention benefits from different modules than cross-attention. This is an advanced optimization.

Example: q_proj v_proj for self-attention, while cross-attention uses all 4.

Leave empty unless: You're an advanced user doing targeted optimization based on estimation results.

Custom projections for cross-attention (when attention-type=both)

Advanced: Separate Targets for Cross-Attention

What this does: Lets you specify different target modules for just the cross-attention layers (the part that learns about text prompts).

When to use: Only if estimation shows cross-attention benefits from different modules. Advanced optimization only.

Leave empty unless: You're doing targeted optimization based on gradient estimation.

Training Hyperparameters

Default: 3e-4. LoKR users: try 5e-4 to 1e-3

What is Learning Rate?

Simple explanation: How big of a "step" the AI takes when learning. Too big = unstable. Too small = takes forever.

By adapter type:

  • LoRA / DoRA: 3e-4 (0.0003) โ€” default, works well
  • LoKR: 5e-4 to 1e-3 โ€” LoKR benefits from a higher LR due to its more efficient parameterization
  • LoHA: 3e-4 to 5e-4 โ€” similar to LoRA
  • OFT: 1e-4 to 3e-4 โ€” start conservative
  • Prodigy optimizer: 1.0 โ€” always use 1.0, it auto-adjusts

Signs you need to adjust:

  • Loss jumping wildly โ†’ Lower LR (halve it)
  • Loss barely moving after 100 epochs โ†’ Higher LR (double it)
  • Loss decreases then suddenly spikes โ†’ LR too high, reduce by 30%
VRAM: None Quality: Critical tuning parameter
Usually 1 for music (large tensors)

What is Batch Size?

Simple explanation: How many songs the AI looks at before updating what it learned. Batch size 1 = look at 1 song, update. Batch size 4 = look at 4 songs, then update.

Think of it like: Studying flashcards. Batch 1 = adjust after each card. Batch 10 = see 10 cards, then adjust your strategy.

Why it's usually 1 for music: Music files are HUGE (30-240 seconds of audio). Each song takes a lot of GPU memory. Batch size 2 would need double the memory.

When to change:

  • Keep at 1 - If you're using default settings
  • Try 2 - Only if you have 24GB+ VRAM and want slightly smoother training
  • Never go higher - Unless you have 80GB+ VRAM

Pro tip: Use "Gradient Accumulation" instead! It gives you the benefits of larger batch sizes without using more VRAM.

Impact:

VRAM: Higher = MUCH more VRAM Quality: Minimal impact Speed: Higher = slightly faster per epoch
Effective batch = batch ร— accumulation

What is Gradient Accumulation?

Simple explanation: A clever trick to get the benefits of large batch sizes WITHOUT using more GPU memory. It "accumulates" learning from multiple songs before updating.

Think of it like: Taking notes while studying 4 flashcards, THEN updating your strategy once. Same learning benefit as batch size 4, but you only hold 1 card at a time.

How it works:

  • Batch size 1, Grad accumulation 4 = "Effective batch of 4"
  • Look at song 1, take notes
  • Look at song 2, add to notes
  • Look at song 3, add to notes
  • Look at song 4, add to notes
  • NOW update the model with all 4 songs' worth of info

Common values:

  • 4 - Good default (effective batch of 4)
  • 8 - Smoother learning, slower updates
  • 2 - Faster updates, less smooth
  • 1 - No accumulation (update after every song)

Impact:

VRAM: ZERO impact (that's the magic!) Quality: Higher = smoother, more stable learning Speed: Higher = fewer updates per epoch (slightly slower)
1-10 songs: 200-500, 10-50: 100-200, 50+: 50-100

What are Epochs?

Simple explanation: How many times the AI goes through your entire dataset. 1 epoch = seeing every song once. 100 epochs = seeing every song 100 times.

Think of it like: How many times you review your study materials. 1 pass = skim once. 100 passes = really know it well.

How many should you use? Depends on dataset size:

  • 1-10 songs: 200-500 epochs (small dataset needs lots of repetition)
  • 10-50 songs: 100-200 epochs
  • 50+ songs: 50-100 epochs (large dataset needs fewer passes)

How do you know when to stop?

  • Watch the loss curve in TensorBoard
  • If loss stops decreasing = you can probably stop
  • If loss starts INCREASING = you've overtrained (stop earlier next time)

Can you stop early? YES! If you're watching TensorBoard and loss plateaus at epoch 60, you can stop. No need to waste time on 40 more epochs.

Impact:

VRAM: None Quality: More = better (until overfitting) Speed: More = longer training time
LR ramps from 10% to 100%

What are Warmup Steps?

Simple explanation: Instead of starting at full learning rate immediately, we gradually increase it over the first N steps. Like warming up before exercise.

Why? Starting at full learning rate can sometimes cause the AI to "freak out" and learn bad patterns in the first few steps. Warmup prevents this.

How it works:

  • Step 1-10: Learning rate at 10%
  • Step 11-50: Gradually increase to 50%
  • Step 51-100: Gradually increase to 100%
  • Step 101+: Stay at 100% (or follow scheduler)

Common values:

  • 100 - Good default
  • 200-500 - Use if training is unstable at the start
  • 0 - No warmup (riskier)

Impact:

VRAM: None Quality: Prevents early instability Speed: Negligible
Default 0.01 works for all adapters. LoKR: try 0.001โ€“0.01
Gradient clipping threshold
Random latent window per iteration (0=disabled, 60-90=recommended). Saves VRAM + data augmentation.

What is Latent Chunking?

Simple explanation: Instead of training on the entire song every time, randomly pick a shorter section (e.g., 60-90 seconds). This provides two major benefits: saves VRAM and acts as data augmentation.

How it works:

  • Each training iteration, a random window is extracted from each song
  • The model sees different parts of the same song every epoch
  • Like practicing random 60-second clips instead of the full 3-minute song

Benefits:

  • Saves VRAM: Shorter audio = much less memory needed
  • Data augmentation: Same song becomes multiple training samples (different random chunks each iteration)
  • Prevents overfitting: AI can't memorize full songs when it only sees random parts
  • Enables longer songs: Train on 5-minute songs even with limited VRAM

โš ๏ธ CRITICAL WARNING:

Chunks shorter than 60 seconds can HURT training quality instead of enriching it. Use shorter chunks only if you need to reduce VRAM and understand the trade-off. The AI needs enough context to learn musical structure.

Recommended values:

  • 0 - Disabled (use full songs)
  • 60 - Minimum recommended for quality (1 minute chunks)
  • 90 - Sweet spot - good quality + VRAM savings (1.5 minute chunks)
  • 120 - Conservative option (2 minute chunks)

When to use:

  • Enable (60-90): Training on songs longer than 2 minutes
  • Enable (60-90): Running out of VRAM with full-length songs
  • Enable (90-120): Want extra data augmentation on long songs
  • Disable (0): Your songs are already short (under 2 minutes)
  • Disable (0): You have plenty of VRAM (24GB+) and want to train on full songs

Example scenarios:

  • 3-minute songs, 16GB VRAM: Use 90 seconds
  • 5-minute songs, 12GB VRAM: Use 60 seconds
  • 1-minute songs, any VRAM: Disable (use 0)
  • 4-minute songs, 24GB VRAM: Optional - use 90-120 for augmentation or 0 for full songs

Technical note: This slices the preprocessed latent tensors (not raw audio), so chunks are calculated in latent space. The number you enter is approximate seconds of the original audio.

Impact:

VRAM: Significant savings (proportional to chunk size) Quality: 60+ = safe, <60=risky Speed: Faster per step (smaller chunks) Data Aug: More variety in training
Auto-set: turbo=3.0, base/sft=1.0. Stored for inference, doesn't affect training
Auto-set: turbo=8, base/sft=50. Stored for inference

CFG & Loss Settings

By model: Auto-disabled for turbo and xl-turbo. Active for base, sft, xl-base, xl-sft.
By adapter: Same settings apply to LoRA, LoKR, LoHA and OFT โ€” no adapter-specific changes needed here.
Match the value the model was trained with. Base/SFT/XL-base/XL-sft: 0.15
flow_snr is the new recommended default for ACE-Step
Gamma clamp for flow_snr/min_snr weighting (default: 5.0)

Optimizer & Scheduler

What is an Optimizer?

Simple explanation: The optimizer is the "brain" that decides HOW to update the AI based on what it learned. Different optimizers have different strategies and memory requirements.

Your choices:

  • AdamW (default) - Industry standard. Reliable, well-tested, works for 99% of cases. Needs moderate VRAM for its "memory" of past training.
  • AdamW8bit - Same as AdamW but uses compressed memory. Saves ~30% of optimizer VRAM with virtually no quality loss. USE THIS if you're running out of VRAM!
  • AdaFactor - Uses minimal memory by being "forgetful" about past training. Only for extreme VRAM constraints (<8GB). Slightly worse quality.
  • Prodigy - Experimental "autopilot" that figures out the best learning rate automatically. Set LR to 1.0 and let it tune itself. Can be unstable.

Recommendation:

  • Have 16GB+ VRAM? Use AdamW
  • Have 10-16GB VRAM? Use AdamW8bit
  • Have <10GB VRAM? Use AdamW8bit or AdaFactor
  • Want to experiment? Try Prodigy (but set LR to 1.0!)

Impact:

VRAM: 8bit saves 30%, AdaFactor saves 50% Quality: AdamW=AdamW8bit > AdaFactor, Prodigy varies Speed: All roughly similar
Prodigy auto-forces 'constant'

What is a Scheduler?

Simple explanation: Controls how the learning rate changes over time. Think of it like adjusting your study intensity as the semester progresses.

Visual analogy:

  • Constant: Study at same intensity every day โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”
  • Linear: Gradually study less and less โ€”โ€”โ€”โ€”\
  • Cosine: Study hard, then taper off smoothly โ€”โ€”โ€”โ€”\___
  • Cosine with Restarts: Periodic "sprints" โ€”โ€”\__/โ€”โ€”\__/

Your choices:

  • Cosine (default) - Smooth curve down. Starts strong, ends gentle. Best for most cases.
  • Linear - Straight line down. Predictable, but less commonly used.
  • Constant - Never change LR. Required for Prodigy optimizer. Rarely used otherwise.
  • Constant with Warmup - Warm up at start, then stay flat. Simple and effective.
  • Cosine with Restarts - Periodic "bounces" back to higher LR. Advanced, can help escape plateaus.

Which to choose:

  • Default case: Use Cosine
  • Using Prodigy: It forces Constant automatically
  • Want simplicity: Constant with Warmup
  • Experimenting: Try Cosine with Restarts

Impact:

VRAM: None Quality: Cosine generally best Speed: None

Memory Optimization

What is Gradient Checkpointing?

Simple explanation: A memory-saving trick where we throw away some intermediate calculations and recalculate them later when needed. Uses less VRAM but takes a bit more time.

Think of it like: Instead of keeping all your scratch paper (uses desk space), you erase it and redo the math later when grading (takes more time but less space).

The trade-off:

  • Saves: 40-60% of VRAM (HUGE savings!)
  • Costs: 10-30% slower training (you're doing some calculations twice)

Should you use it?

  • YES - If you have <24GB VRAM (almost everyone)
  • YES - If you're running out of memory
  • MAYBE NO - If you have 80GB+ VRAM and want max speed

Default: ON (matches original Side-Step trainer behavior). Unless you have massive VRAM and want maximum speed, keep this ON.

Impact:

VRAM: Saves 40-60% (CRITICAL for most users) Speed: 10-30% slower training Quality: No impact
Fraction of decoder layers to checkpoint (0.0=none, 1.0=all). Default: 0.6 for optimal VRAM savings

What is Gradient Checkpointing Ratio?

Simple explanation: Controls what fraction of the model's decoder layers use gradient checkpointing. A ratio of 0.6 means 60% of layers are checkpointed.

Think of it like: Instead of checkpointing ALL layers (which saves maximum VRAM but is slowest), you can checkpoint only 60% of them for a good balance.

Valid values:

  • 0.0 - No checkpointing (fastest, most VRAM)
  • 0.6 - Checkpoint 60% of layers (recommended balance)
  • 1.0 - Checkpoint all layers (maximum VRAM savings, slowest)

Recommended settings:

  • 0.6 - Best balance for most users (default)
  • 0.8-1.0 - If very low on VRAM (8-12GB)
  • 0.4-0.5 - If you have more VRAM and want speed
  • 0.0 - If you have 24GB+ VRAM and disabled gradient checkpointing

Note: Only applies when "Gradient Checkpointing" is enabled.

Impact:

VRAM: Higher ratio = more savings Speed: Higher ratio = slightly slower Quality: No impact

What is Encoder Offloading?

Simple explanation: Some parts of the AI (VAE and text encoders) are only needed at the start. After setup, we move them to regular RAM instead of keeping them on the GPU. This frees up GPU memory for training.

Think of it like: Moving reference books from your desk to a bookshelf after you've taken notes. You already have what you need, so free up the desk space.

How much does it save? About 2-4GB of VRAM (exact amount depends on the model).

Does it slow things down? NO! These components aren't used during training anyway, so moving them to CPU has zero speed impact.

Should you use it?

  • YES - If you have 10-16GB VRAM
  • YES - If you're getting out-of-memory errors
  • MAYBE - If you have <10GB VRAM (enable it!)
  • NO - If you have 24GB+ VRAM (not needed)

Fun fact: This is a "free lunch" optimization - saves memory with no downsides!

Impact:

VRAM: Frees 2-4GB Speed: Zero impact Quality: Zero impact

What is Weight Quantization?

Simple explanation: Compresses the frozen (non-training) parts of the model from 32/16-bit to 8-bit numbers. This dramatically reduces the VRAM needed to hold the backbone model.

Think of it like: Using shorthand notation instead of full words โ€” the meaning is preserved but takes up less space.

VRAM savings: Can save 4-8GB depending on model size. Very significant for XL models.

Quality impact: Minimal โ€” the frozen backbone isn't being trained, just loaded.

Requires installation: Run this once from your Side-Step folder:

cd C:\path\to\Side-Step
uv pip install optimum-quanto

โš ๏ธ Do NOT use plain pip install โ€” that installs into your system Python, not the Side-Step UV environment. Must be uv pip install from the Side-Step directory.

VRAM: Saves 4-8GB Quality: Minimal impact

Data Loading

Default: 2 (Linux), 0 (Windows). Set to 0 if low on RAM

What are Data Loading Workers?

Simple explanation: "Workers" are separate helper processes that load your training data from disk while the GPU is busy training. More workers = faster data loading, but uses more RAM.

Think of it like: A restaurant kitchen with multiple prep cooks (workers). While the head chef (GPU) is cooking, prep cooks are chopping ingredients (loading data) so the chef never has to wait.

How it works:

  • 0 workers: Main process does everything. GPU waits while data loads from disk.
  • 1 worker: One helper process loads next batch while GPU trains on current batch.
  • 4 workers: Four helpers load data in parallel. GPU almost never waits.
  • 8+ workers: Even more parallel loading, but diminishing returns.

Platform defaults:

  • Linux/Mac: Default 4 workers (multiprocessing works well)
  • Windows: Default 0 workers (Windows multiprocessing has issues)

Recommended values:

  • 0 - Windows (default), or very low RAM (<8GB)< /li>
  • 2 - Dual-core CPU, moderate RAM (8-16GB)
  • 4 - Quad-core+ CPU, good RAM (16GB+) - recommended for Linux
  • 6-8 - High-end CPU, lots of RAM (32GB+)

When to increase:

  • You have a fast GPU but slow disk (SSD helps too!)
  • TensorBoard shows GPU utilization dropping between batches
  • You have lots of CPU cores and RAM to spare

When to decrease (or use 0):

  • On Windows: Multiprocessing can cause crashes/hangs
  • Low RAM: Each worker loads data into memory
  • Memory leaks: If RAM usage grows over time
  • Crashes during data loading: Try 0 to debug

โš ๏ธ Windows Warning: Windows has known issues with PyTorch multiprocessing. If training hangs at data loading or you get errors, set this to 0.

Impact:

GPU VRAM: No impact CPU RAM: Each worker uses ~2-4GB Speed: More workers = faster (if you have RAM)
Default: 2 (Linux), 0 (Windows)

What is Prefetch Factor?

Simple explanation: How many batches AHEAD each worker loads into memory. Higher = smoother training but uses more RAM.

Think of it like: A buffer at a streaming video service. Prefetch factor 2 = load 2 batches ahead. If GPU suddenly speeds up, you have data ready immediately.

How it works:

  • Prefetch 0: Workers only load when GPU asks. Can cause waiting.
  • Prefetch 2: Each worker keeps 2 batches loaded ahead. Smooth flow.
  • Prefetch 4+: Even more buffer, but uses lots of RAM.

Math: Total memory used = num_workers ร— prefetch_factor ร— batch_size ร— data_size

  • 4 workers ร— 2 prefetch ร— 1 batch ร— 500MB per song = 4GB RAM used for prefetching

Recommended values:

  • 0 - Windows (default, since num_workers is 0)
  • 2 - Good default for Linux/Mac (balances speed and RAM)
  • 4 - If you have lots of RAM (32GB+)
  • 1 - If running out of RAM

When to increase:

  • GPU utilization is inconsistent (drops between batches)
  • You have RAM to spare
  • Data loading is still a bottleneck despite workers

When to decrease:

  • Running out of RAM (system memory, not VRAM)
  • Getting "out of memory" errors during data loading
  • Training on a system with <16GB RAM

โš ๏ธ Important: This only matters when num_workers > 0. If workers = 0, prefetch factor is ignored.

Platform notes:

  • Windows: Usually 0 (since num_workers = 0)
  • Linux/Mac: Usually 2 (with 4 workers)

Impact:

GPU VRAM: No impact CPU RAM: Higher = more RAM per worker Speed: Smoother training flow, fewer GPU stalls

What is Pin Memory?

Simple explanation: "Pinning" memory locks loaded data in a special area of RAM that can transfer to GPU faster. It's like keeping ingredients on the counter instead of in the pantry.

Technical explanation:

  • Unpinned (normal) memory: OS can move data around. GPU transfer needs an extra copy step. Slower but flexible.
  • Pinned memory: Data is locked in place. GPU can grab it directly via DMA (Direct Memory Access). Faster but uses more RAM.

The trade-off:

  • Speed benefit: 10-30% faster data transfer from RAM โ†’ GPU
  • RAM cost: Pinned memory can't be swapped to disk, so it "uses" more RAM

Should you enable it?

  • YES (default): If you have 16GB+ system RAM
  • YES: If using CUDA (NVIDIA GPUs)
  • MAYBE NO: If you have <16GB RAM and seeing memory pressure
  • NO: If getting RAM-related crashes

When to disable:

  • Training on a system with very limited RAM (<8GB)< /li>
  • Running multiple programs while training
  • Getting "out of memory" errors (RAM, not VRAM)
  • System becomes unresponsive during training

Platform compatibility:

  • CUDA (NVIDIA): Works great, recommended
  • MPS (Apple Silicon): Less benefit but still works
  • CPU: No benefit (disabled automatically)

Impact:

GPU VRAM: No impact CPU RAM: Uses more (data can't be swapped) Speed: 10-30% faster RAMโ†’GPU transfer

What are Persistent Workers?

Simple explanation: Keep the data loading workers alive between epochs instead of killing and restarting them every epoch.

Think of it like: A restaurant with shift workers:

  • Non-persistent: Fire all prep cooks at end of each lunch service, hire new ones for dinner. Lots of setup time.
  • Persistent: Keep the same prep cooks all day. They know the kitchen and work efficiently.

How it works:

  • Persistent OFF: At the end of each epoch:
    • Kill all worker processes
    • Free their memory
    • At start of next epoch: spawn new workers
    • Workers reload dataset metadata
  • Persistent ON: Workers stay alive between epochs:
    • No respawning overhead
    • Dataset stays loaded in worker memory
    • Faster transition between epochs

Benefits of enabling:

  • โšก Faster epoch transitions (no worker spawn time)
  • โšก No dataset reloading between epochs
  • โšก More efficient when training many epochs

Drawbacks of enabling:

  • ๐Ÿ’พ Workers keep RAM allocated between epochs
  • ๐Ÿ› If workers have memory leaks, they accumulate
  • ๐Ÿ› Harder to recover from worker crashes

Should you enable it?

  • YES (default on Linux): If training many epochs (50+)
  • YES: If you have stable RAM usage (no leaks)
  • NO (default on Windows): Windows multiprocessing issues
  • NO: If RAM usage grows over time (memory leak)
  • NO: If num_workers = 0 (nothing to persist)

When to disable:

  • RAM usage steadily increases during training (leak)
  • Workers crash or hang between epochs
  • Training on Windows (often problematic)
  • You're doing quick experiments (few epochs)

Platform defaults:

  • Linux: ON by default (works reliably)
  • Windows: OFF by default (multiprocessing issues)
  • Mac: ON by default

โš ๏ธ Note: This setting only matters when num_workers > 0. With 0 workers, there's nothing to keep persistent.

Impact:

GPU VRAM: No impact CPU RAM: Workers stay in memory (but not loading more) Speed: Faster epoch transitions, no spawn overhead

Checkpointing & Logging

TensorBoard basic metrics (loss, LR)
Per-layer gradient norms (expensive)
Leave blank to use default ({output-dir}/runs). For Modal: set to /output/my-lora/runs so logs go to the persistent volume.
Enter epoch number โ€” full path is built automatically from Output Directory. e.g. epoch 500 โ†’ {output-dir}/checkpoints/epoch_500

EMA & Validation

0 = off. Use 0.9999 to enable. Smooths adapter updates for potentially better quality.

What is EMA Decay?

Simple explanation: EMA (Exponential Moving Average) keeps a smoothed "shadow" copy of your adapter weights. Instead of saving the raw trained weights, it saves a running average that changes more slowly โ€” like smoothing a noisy signal.

Think of it like: Instead of using today's temperature as the forecast, you average the last 10,000 days. More stable, less affected by single bad training steps.

Use: 0.0 = off (default). 0.9999 = typical. Higher = smoother but slower to update.

When to use: If your training is noisy or you want more stable results. Small compute overhead.

Quality: May improve stability VRAM: Tiny overhead
Step at which EMA tracking begins. Default: 2000 (avoids early unstable steps)
0 = off. Use 0.1 to hold out 10% for validation. Helps spot overfitting.

What is Validation Split?

Simple explanation: Reserves a portion of your dataset that the model never trains on. After each epoch, the trainer checks how well it performs on these held-out samples. If training loss keeps falling but validation loss rises, you're overfitting.

Use: 0.0 = off (default). 0.1 = hold out 10% for validation.

When to use: Larger datasets (50+ tracks) where you can afford to hold some back. Not ideal for tiny datasets.

Quality: Helps prevent overfitting Speed: Tiny overhead per epoch
0 = off. Stop training if no loss improvement for N epochs. Saves GPU time.

What is Early Stop Patience?

Simple explanation: Automatically stops training if the loss hasn't improved for N epochs. Prevents wasting GPU time once training has plateaued.

Use: 0 = disabled (default). 50 = stop after 50 epochs with no improvement.

When to use: When you set a high epoch count but don't want to overshoot. Good for overnight runs.

Speed: Saves GPU time Quality: Prevents overtraining
Don't track best model until after this epoch (default: 200). Avoids saving unstable early checkpoints.

Per-Layer Learning Rate Scaling

Advanced: Apply different learning rate multipliers to different parts of the adapter. Default is 1.0 for all (uniform LR). Useful for fine-tuning which layers learn faster.
LR multiplier for self-attention layers (default: 1.0)

Per-Layer LR Scaling

Simple explanation: Multiplies the base learning rate separately for self-attention, cross-attention, and MLP layers. 1.0 = same as base LR. 0.5 = half the LR. 2.0 = double the LR.

Self-attention: Controls how the model attends to itself (musical structure, patterns)

Cross-attention: Controls how the model responds to text prompts (genre, mood, style)

MLP: The feedforward layers (transforms and processes features)

When to use: If you notice certain aspects aren't being captured well. E.g. lower cross-attn scale if style is drifting too much.

Quality: Advanced tuning
LR multiplier for cross-attention layers (default: 1.0)
LR multiplier for MLP/FFN layers (default: 1.0)

Target Loss Cruise Control

Auto LR Adjustment: Automatically damps the learning rate as training approaches a target loss value, preventing overfitting and holding training steady at a chosen quality level. Set Target Loss to 0 to disable.
0 = disabled. Set a value like 0.05 to hold training steady when loss reaches it.

What is Target Loss Cruise Control?

Simple explanation: Like cruise control in a car โ€” instead of flooring the accelerator all the way to the end, the trainer automatically eases off the LR as you approach your target loss. This prevents blowing past the ideal stopping point.

How it works: As the smoothed loss gets close to your target value, the LR is progressively reduced (damped). At exactly the target, LR drops to the floor multiplier.

Use: Set to a loss value you observed in previous runs as a good quality checkpoint. e.g. 0.04 or 0.05.

Leave at 0 if you're unsure โ€” it's safe to ignore.

Quality: Prevents overfitting at target Speed: May extend training slightly
Minimum LR multiplier at target loss (default: 0.01 = 1% of scheduled LR)
Minimum steps before cruise control engages (default: 50)
EMA beta for loss smoothing (default: 0.98 โ€” higher = smoother)

Advanced Options

These fields are omitted from the CLI command unless you change them from their defaults. Leave blank or at default to have Side-Step use its own defaults.
Default: mse. Huber variants are more robust to noisy/outlier samples.

Loss Function

Controls how training error is calculated at each step.

  • mse โ€” Standard mean squared error. Default and well-tested.
  • huber โ€” Like MSE but less sensitive to outlier samples. Useful if your dataset has some unusual/noisy tracks.
  • pseudo_huber โ€” Smooth version of Huber, differentiable everywhere.
  • x0_mse / x0_pseudo_huber โ€” Compute loss on the reconstructed clean signal rather than the noise prediction. Applies tยฒ weighting. More experimental.
Quality: Minor effect in most cases
Threshold between MSE and linear regions in Huber loss (default: 1.0). Only used with huber/pseudo_huber.
How timesteps are sampled during training. Continuous is correct for base/XL models.

Timestep Mode

Continuous โ€” Samples timesteps from a logit-normal distribution. Correct for base, sft, xl-base, xl-sft models.

Discrete โ€” Uses the fixed 8-step turbo schedule. Only appropriate for turbo/xl-turbo models. Auto-selected when using a turbo model.

Quality: Must match model type
Repeat the whole dataset N times per epoch (default: 1). Useful for very small datasets.

Dataset Repeats

Loops through your dataset N times within each epoch. For a 5-song dataset, setting this to 4 makes each epoch see 20 samples instead of 5 โ€” effectively the same as having a larger dataset without duplicating files on disk.

When to use: Very small datasets (under 10 songs). More than 4-5ร— repetition risks overfitting.

Speed: Longer epochs Quality: Helps tiny datasets
Check for best model every N steps within an epoch (0 = epoch-level only, default). Use for very long epochs.
Whether to abort if resumed checkpoint config doesn't match current settings. Only relevant when using Resume From.

Strict Resume

When resuming from a checkpoint, Side-Step checks if the current settings match the original training config. If they differ:

  • True (default) โ€” Abort with an error. Safer โ€” prevents accidentally training with wrong settings.
  • False โ€” Continue anyway. Useful if you intentionally changed a setting (e.g. LR) mid-training.

Scheduler Fine-tuning

LR starts at base_lr ร— this during warmup (default: 0.1 = 10% of LR).

Warmup Start Factor

During the warmup phase, the LR ramps from base_lr ร— warmup_start_factor up to base_lr. A lower value = gentler start.

Default 0.1: LR starts at 10% and ramps up over warmup_steps. This prevents early training instability.

Quality: Gentler start = more stable early training
Cosine scheduler decays LR to base_lr ร— this (default: 0.01 = 1% of LR at end).

Cosine Min LR Ratio

The cosine scheduler decays the LR smoothly from base_lr down to base_lr ร— cosine_eta_min_ratio.

Default 0.01: LR ends at 1% of starting value โ€” a very gentle final phase.

Higher value (e.g. 0.1): LR doesn't decay as aggressively โ€” keeps learning at 10% rate at the end.

Quality: Controls final training intensity
Number of cosine restart cycles when using Cosine with Restarts scheduler (default: 4).

Global Options

What is UV?

Simple explanation: UV is a fast Python package manager that Side-Step uses. It's like pip but much faster (10-100x).

Why it's checked by default:

  • Side-Step documentation recommends using UV
  • Ensures packages are in sync with project requirements
  • Much faster than standard pip

Command difference:

  • With UV (checked): uv run python train.py ...
  • Without UV: python train.py ...

When to disable:

  • You don't have UV installed
  • You're using standard pip/virtualenv
  • You know you don't need it

To install UV:

pip install uv

Impact:

Just changes the command prefix

Queue Execution Options

๐Ÿ“ญ No jobs in queue. Configure a job and click "Add to Queue"

Generated Queue Script

Import Config JSONs

Side-Step saves two config files per training run. Load either or both โ€” they'll be merged to populate the form.

training_config.json โ€” found in your output folder. Contains all training hyperparameters (LR, batch size, epochs, optimizer, paths, etc.) but not adapter details.
sidestep_adapter_config.json โ€” found inside each saved checkpoint subfolder. Contains adapter-specific settings (rank/dim, alpha, target modules, etc.)