What a Real Fine-Tuning Job Looks Like on Heulistic: Config, Training Logs, and Results

TL;DR

Most fine-tuning platform demos show you a UI walkthrough or a code snippet. This post shows you a real training job on Heulistic from config to completed model. The Axolotl config that was submitted. The actual training logs. Real GPU memory numbers, checkpoint uploads, and what the output looks like when a job completes successfully. If you want to know what running a job on Heulistic actually feels like, this is it.

There is a version of this post that shows you a polished UI recording and calls it a demo.

This is not that post.

What follows is a real training job. Llama 3.2 1B, fine-tuned with LoRA on the alpaca dataset. The logs are real. The timestamps are real. The memory numbers are real.

Here is what fine-tuning on Heulistic actually looks like.

The Config

This is the exact Axolotl config that was submitted to start the job. No changes.

base_model: meta-llama/Llama-3.2-1B
adapter: lora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
lora_target_linear: true
val_set_size: 0.1
sequence_len: 2048
sample_packing: false
num_epochs: 3
micro_batch_size: 2
gradient_accumulation_steps: 4
learning_rate: 0.0002
lr_scheduler: cosine
bf16: auto
gradient_checkpointing: true
output_dir: ./model-out
datasets:
  - path: tatsu-lab/alpaca
    type: alpaca

A few things worth noting here before we get to the results.

base_model: meta-llama/Llama-3.2-1B. The 1B parameter Llama 3.2 model. Compact, fast to train, and a good baseline for instruction-following tasks. This is a standard starting point for anyone experimenting with fine-tuning on a budget or moving fast.

adapter: lora. Standard LoRA without 4-bit quantization. The 1B model is small enough that full 16-bit LoRA is comfortable within the GPU memory budget without needing to quantize.

lora_r: 16, lora_alpha: 32. A rank of 16 with alpha set to double the rank. This is a widely used default. It gives the LoRA adapters enough capacity to learn the task without adding unnecessary trainable parameters.

lora_target_linear: true. Applies LoRA adapters to all linear layers in the model. More coverage than targeting only attention projections, which gives the adapters more flexibility to adjust behavior across the full model.

val_set_size: 0.1. Ten percent of the alpaca dataset held out for validation. This is what powers the validation loss tracking during training.

sequence_len: 2048. The alpaca dataset examples are generally shorter than this, so there is some padding overhead. For a test run this is fine. Reducing sequence_len to match the actual data distribution would improve GPU utilization on a production job.

micro_batch_size: 2, gradient_accumulation_steps: 4. Effective batch size of 8. Conservative settings that keep memory pressure low and training stable.

learning_rate: 0.0002, lr_scheduler: cosine. 2e-4 with cosine decay. The standard starting point for LoRA fine-tuning. The learning rate drops smoothly from 2e-4 to near zero over the three epochs.

bf16: auto. Uses bfloat16 precision when available. On Ampere and newer NVIDIA GPUs this is the right choice. Faster than float32, more numerically stable than float16 for training.

gradient_checkpointing: true. Trades some compute speed for lower memory usage. On a 1B model this is not strictly necessary but it is a good habit to have in the config for when you scale to larger models.

The Results

Here are the final training metrics from the completed job:

• Total steps: 17,551
• Epochs: 3 (completed exactly)
• Total training time: 2 hours, 59 minutes, 52 seconds
• Peak GPU memory active: 3.99 GiB
• Peak GPU memory reserved: 7.65 GiB
• Average training speed: 96.29 tokens per second per GPU
• Samples per second: 13.01
• Steps per second: 1.63
• Final average train loss: 1.145

Under 3 hours. Under 4 GiB of active GPU memory at peak. Model uploaded and ready to download 52 seconds after training completed.

What the Logs Show Near the End

Here is a sample from the training output near epoch 2.98, roughly 111 steps from the end:

{'loss': '0.8487', 'grad_norm': '4.397', 'learning_rate': '2.033e-08', 'ppl': '2.337', 'memory/max_active (GiB)': '3.45', 'memory/max_allocated (GiB)': '3.45', 'memory/device_reserved (GiB)': '6.18', 'tokens/train_per_sec_per_gpu': '57.6', 'epoch': '2.981'}

Loss at 0.8487. The model has been learning consistently. By this point in epoch 3, loss has dropped well below the starting values from epoch 1.

Learning rate at 2.033e-08. The cosine scheduler is doing its job. By epoch 2.98, the learning rate has decayed from the starting 2e-4 down to near zero. The model is making tiny, careful adjustments in the final steps rather than large updates. This is exactly what you want at the end of training.

Memory active at 3.45 GiB on a 24 GiB GPU. The 1B model with LoRA leaves a lot of headroom. You could increase micro_batch_size, use a larger model, or run a longer sequence length on the same hardware.

Perplexity at 2.337. The model is generating with meaningful confidence on training examples by this point in the run.

And the very last log entry before training completed:

{'loss': '0.9309', 'grad_norm': '1.859', 'learning_rate': '6.482e-12', 'ppl': '2.537', 'epoch': '3'}

Learning rate essentially at zero. Grad norm healthy and stable. Loss holding steady. A clean end to training.

The Checkpoint and Upload Sequence

At step 17,500, with 51 steps left:

Saving model checkpoint to /tmp/training/output/checkpoint-17500 Checkpoint uploaded: s3://ftp-prod-data-82eecb52/checkpoints/.../step-17500/checkpoint.tar.gz

Heulistic automatically saves checkpoints to S3 during training. If the job had failed at step 17,500, the checkpoint would have been available. No compute lost.

The cascade of pruning messages that follows is Heulistic clearing older checkpoints to manage storage. Checkpoints from step 100 all the way through to step 17,300 are pruned automatically. The last 3 checkpoints are saved. You do not configure this. You do not monitor it.

At step 17,551, training completed:

Training completed! Saving trained model to /tmp/training/output. Model successfully saved to /tmp/training/output Archiving model from /tmp/training/output → /tmp/training/model.tar.gz Uploading model to s3://ftp-prod-data-82eecb52/models/.../model.tar.gz Job e3f3b8f4-faa7-4273-8df1-5aec11e14a8b completed successfully

52 seconds from training complete to model uploaded and job marked successful. The instance terminated automatically. The model was available for download.

What This Config Would Cost to Iterate On

A 3-hour job on a g5.xlarge at Heulistic's current rates costs a few dollars in compute. The config above is a clean baseline. If you wanted to iterate from here, the next experiments might be:

Reducing sequence_len to 512 or 1024 to match the actual alpaca data distribution. This would cut memory usage further and speed up training, letting you fit a larger batch size.

Trying lora_r: 32 to see if higher rank improves instruction following quality. The 1B model has enough headroom in memory that this would not cause issues.

Switching base_model to meta-llama/Llama-3.2-3B to see how much the extra parameters improve results on the same dataset. The 3B model would take longer and cost more per run but the config change is a single line.

Each of those experiments starts from this same config file. One line changes. Same infrastructure. Same workflow. That is what a fast iteration loop actually looks like.

What You Do Not See in These Logs

You do not see CUDA installation. Because there was none.

You do not see dependency conflicts. Because the environment was pre-configured.

You do not see an idle instance billing while someone debugged a config error. Because the instance terminates on completion.

You do not see manual checkpoint management. Because it is automatic.

What you see is training. The config went in. The model came out. Everything in between was handled.

You can run your first job at heulistic.com. The platform is in beta. Credits are available to get started.