Training finishes clean. The LoRA adapter saved. You kick off the GGUF export.
Then it dies.
No space left on device.
The frustrating part is that nothing warned you. The training job ran for hours without a single disk error. The problem only appeared at the worst possible moment the final step, after all the compute was spent.
Why export kills jobs that training survived
During fine-tuning the disk footprint stays small. You are writing a LoRA adapter and periodic checkpoints a few hundred megabytes at most. The base model weights stay in memory, not on disk.
GGUF export is different. To convert a fine-tuned model you briefly hold multiple large files simultaneously:
- The 16-bit merged model
- The f16 GGUF
- The quantised outputs
For a 12B model that peak sits at approximately 45–47GB. If your working directory only has 20GB free, the export fails partway through. The merge is incomplete. The GGUF is corrupted or missing.
A Vast.ai operator described this exactly: training ran clean, disk footprint stayed small, then GGUF export failed because the working directory had ~20GB against a ~45–47GB peak requirement. Silent end-of-pipeline failure.
Why this is hard to see before it happens
The disk check that matters for export is different from the disk check that matters for training. During training you need headroom for checkpoints a few GB. During export you need headroom for the full model merge plus conversion artifacts simultaneously.
Most pre-flight thinking is focused on training. Export is an afterthought.
There is no error before the job starts. The disk looks fine. Training looks fine. The failure only surfaces at the conversion step.
The check before you start
Before any run that ends in GGUF export, check how much space the export will actually need.
Rough estimate for a model of size N billion parameters:
- 16-bit merge: approximately 2 × N GB
- f16 GGUF: approximately 2 × N GB
- Quantised output (Q4): approximately 0.5 × N GB
- Peak simultaneous: approximately 4–4.5 × N GB
For a 12B model that is 48–54GB. For a 7B model that is 28–32GB.
If your working directory does not have that headroom before the job starts, the export will fail.
-# Check available disk on your working volume
df -h /workspace
-# Check total size of base model weights
du -sh /workspace/.cache/huggingface/
Or run a full environment check in 30 seconds:
uvx computefence doctor
Real output from a RunPod A40 pod (v0.2.11 — current version is v0.3.1):
ComputeFence v0.2.11 — Pre-flight diagnostic
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4 WARNINGS · 0 BLOCKERS · 4 PASSED
Environment
✓ Python 3.12.3
✓ PyTorch 2.8.0+cu128 detected (CUDA available — NVIDIA A40)
⚠ No Accelerate config found — skipping GPU count check
Fix: Run 'accelerate config' to create a configuration file
Storage
✓ HF_HOME is set to /workspace/.cache/huggingface/
✓ Persistent volume(s) detected: /workspace
⚠ Volume /workspace — 6.0 GB free of 9.3 GB (below 20 GB)
Fix: Free up disk space or move checkpoints to a larger volume
⚠ Root disk (/) — 16.2 GB free of 20.0 GB (below 20 GB)
Fix: Free up disk space or move checkpoints to a larger volume
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4 warning(s) found. Review before launching.
That disk warning 6GB free on a 9.3GB volume would catch you before you start a 12B export that needs 45–47GB. The job would not even begin with that headroom. That is the point.
The fix
Three options before any export job:
Option 1 — Attach a larger volume
Size it to at least 4–5× your model’s parameter count in GB. For a 12B model that means at least 60GB free before you start.
Option 2 — Export in stages
Merge first, check disk, then convert. Do not run the full pipeline in a single script if you are not certain about headroom.
Option 3 — Export locally or on cheaper compute
GGUF conversion does not need a GPU. Run it on a CPU instance with large cheap disk rather than holding a GPU pod open for the conversion step.
What ComputeFence catches today
ComputeFence checks disk headroom on both the workspace volume and the root disk before launch. It warns below 20GB and blocks below 5GB.
It does not yet estimate the full GGUF export peak requirement from your model size. That check is on the roadmap. For now the disk warning is the signal if you are below 20GB free before training starts, you will almost certainly be below what export needs at the end.
GitHub: github.com/Francisco-Booth/ComputeFence
Install: pip install computefence
Top comments (0)