Hidden Assumptions in kohya_ss

The TOML config file contains only valid parameter keys that match the expected schema — any typos or deprecated keys are ignored silently

If this fails: Invalid config keys get silently dropped, causing user settings to revert to defaults without warning — user thinks their custom settings are applied but training uses different values

Default learning rate of '1e-6' is appropriate for all model types (SD 1.5, SDXL, SD3, Flux.1) and training approaches (LoRA, Dreambooth, fine-tuning)

If this fails: Training converges extremely slowly or fails to learn with inappropriate learning rates — SDXL may need 1e-5, LoRA may need 1e-4, but system uses same default for all

Only one training process should run at a time, but process state tracking relies on a single instance variable that could become stale if the process crashes or is killed externally

If this fails: If training process dies unexpectedly, GUI still thinks it's running and prevents new training starts — user must restart entire GUI to recover

The user running the GUI has write permissions to create directories in scriptdir/outputs, scriptdir/logs, and scriptdir/reg paths

If this fails: Directory creation fails silently or with permission denied errors, but training continues and then fails when trying to write outputs — confusing delayed failure mode

The selected GPU architecture supports the chosen mixed precision mode — fp16 requires compute capability 7.0+, bf16 requires Ampere+, fp8 requires Hopper+

If this fails: Training fails with cryptic CUDA errors or falls back to slower fp32 without notification — user expects performance benefits but gets degraded training speed

Sample prompts are written to the prompt file before training starts, but the training script may read this file at initialization — race condition if file is created after script launch

If this fails: Sample image generation uses empty or default prompts instead of user-specified ones if timing is wrong — validation images don't match user expectations

SDXL parameters like cache_text_encoder_outputs and no_half_vae are only relevant when SDXL mode is enabled, but parameter validation doesn't enforce this constraint

If this fails: Non-SDXL training may receive SDXL-specific flags that are ignored or cause errors — confusing parameter interaction without clear error messages

Gradient accumulation steps and batch size are configured independently, but effective batch size = batch_size * gradient_accumulation_steps must fit within GPU memory constraints

If this fails: User can configure valid individual values that combine to exceed VRAM limits — training crashes with memory errors despite valid individual parameters

Config file writes are atomic and won't be interrupted — partial writes could corrupt the TOML file if system crashes during save

If this fails: Corrupted config files cause startup failures or silent loss of user settings — no backup or recovery mechanism for configuration data

The output directory has sufficient disk space for model checkpoints, logs, and sample images — typical LoRA training can generate several GB of data

If this fails: Training fails mid-process when disk fills up, potentially corrupting checkpoint files — no pre-flight disk space validation

The subprocess environment inherits all necessary environment variables (CUDA_VISIBLE_DEVICES, LD_LIBRARY_PATH) required by the training scripts

If this fails: Training script can't access GPUs or required libraries despite them being available to the GUI process — mysterious 'no GPU found' errors

Sample prompts are plain text strings that can be written to a file with UTF-8 encoding, but prompts containing special characters or null bytes could corrupt the file

If this fails: Training script fails to parse malformed prompt file or generates unexpected results — sample images don't match intended prompts