🧠 Zero-GPU Training Space

Train SFT / DPO / KTO — the number of optimizer steps is derived from the trace (dynamic gradient accumulation), not chosen per request. Requests are queued so a client timeout can never lose them: Submit caches them, Train runs them in method priority (SFT → DPO → KTO) on GPU if the ZeroGPU decorator attaches one, otherwise CPU. Weights + optimizer state are checkpointed to a Hugging Face Storage Bucket; the trace itself is never stored, so you can shut the Space down and resume later without restarting the optimizer from scratch.

1 · Configuration

Deployment (set once via env, not per request)

  • Model: HuggingFaceTB/SmolLM2-135M (env MODEL_ID)
  • Bucket: flozi00/training-checkpoints (env BUCKET_ID)
  • LoRA: rank 8, alpha 16, dropout 0.0, targets q_proj, k_proj, v_proj, o_proj (env LORA_R / LORA_ALPHA / LORA_DROPOUT / LORA_TARGET_MODULES)
  • Learning rate: 0.0001 (env LEARNING_RATE) · Max length: 256 (env MAX_LENGTH)
  • Gradient accumulation: 4 (env GRAD_ACCUM) → steps = ceil(n_examples / G) The base model is loaded once and kept resident in RAM/VRAM (auto-sharded across all GPUs when more than one is available); only the LoRA adapter + optimizer state are re-applied per call. All hyper-params come from env — restart the Space to change them.
Method

2 · Upload trace

Paste JSONL (one JSON object per line) or a JSON array. The number of optimizer steps is derived from the number of rows (ceil(n / GRAD_ACCUM)) — 1 row → 1 step, 10 rows with GRAD_ACCUM=4 → 3 steps. The data is parsed in-memory and discarded after the run — never persisted.

3 · Queue & Progress