Fine-tuning de un modelo de 70B en una tarjeta.

Lo que realmente cabe

LoRA congela el modelo y entrena un pequeño par de matrices de bajo rango junto a cada matriz de pesos. QLoRA va más allá y mantiene los pesos congelados en 4 bits. Lo que debe mantener en memoria cambia por completo como resultado.

Por qué el fine-tuning completo no

El fine-tuning completo en BF16 necesita unos 16 bytes por parámetro: 2 para el peso, 2 para su gradiente, y 8 para los dos momentos de Adam en FP32, más la copia maestra. Es un multiplicador fijo, y es brutal.

Son cifras de orden de magnitud con un margen moderado para las activaciones: suficientes para elegir una máquina, no para prometer una ejecución concreta. La longitud de secuencia y el tamaño de lote mueven bastante la columna de QLoRA; la columna de fine-tuning completo apenas se mueve, porque está dominada por los 16 bytes fijos por parámetro.

Modelo por modelo

El nodo más barato de nuestro catálogo capaz de entrenar cada modelo con QLoRA, junto con la máquina que necesitaría para servir el resultado.

El entrenamiento necesita memoria; el servicio necesita memoria y ancho de banda. Es habitual que la tarjeta adecuada para entrenar sea una barata y con mucha memoria, y la adecuada para servir sea una cara y rápida — y, como aquí ambas son mensuales, usar dos máquinas distintas suele salir más barato que ceder en una sola.

Ejecutarlo

Axolotl viene preinstalado como una de las imágenes del configurador. Esta es una ejecución completa en una sola tarjeta, partiendo de una máquina vacía.

$ mkdir -p /scratch/ft && cd /scratch/ft
$ cat > qlora.yml <<'YAML'
base_model: meta-llama/Llama-3.3-70B-Instruct
load_in_4bit: true
adapter: qlora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
lora_target_linear: true

sequence_len: 2048
sample_packing: true
gradient_checkpointing: true
micro_batch_size: 1
gradient_accumulation_steps: 16
num_epochs: 2
learning_rate: 0.0001
optimizer: paged_adamw_8bit
bf16: true

datasets:
  - path: /scratch/ft/data.jsonl
    type: chat_template
output_dir: /scratch/ft/out
YAML

$ docker run --rm --gpus all --ipc=host --shm-size=16g \
    -v /scratch/ft:/workspace -v /scratch/models:/root/.cache/huggingface \
    -e HF_TOKEN="$HF_TOKEN" \
    axolotlai/axolotl:main-latest \
    axolotl train /workspace/qlora.yml

$ nvidia-smi dmon -s um

# If memory sits just under the card's total, you are one long batch
# away from an out-of-memory error four hours into the run.
# Lower sequence_len or micro_batch_size now, not then.

Los ajustes que importan

Lo que cuesta un mes

La razón por la que lo mensual importa más para entrenar que para servir: un proyecto de fine-tuning no es una sola ejecución. Es una primera ejecución que falla por un error en los datos, una segunda que sufre sobreajuste, una tercera que funciona, y luego cinco más con distintos rangos.

Compare eso con la facturación por horas a lo largo de un proyecto, no de una sola ejecución: la guía del punto de equilibrio hace los cálculos. Una máquina que existe durante tres semanas mientras usted itera es exactamente el caso en el que un contador cuesta más que un plazo.

Dónde deja de funcionar LoRA

Es una técnica muy buena con un límite real, y merece la pena saber de qué lado está antes de alquilar nada.

Para todo lo demás —un tono, un formato, un esquema, un dominio que el modelo base ya conoce a medias— QLoRA en una sola tarjeta alcanza la mayor parte de la calidad por una fracción de la máquina. Ese es el trato, y en los modelos a los que la mayoría de la gente realmente le hace fine-tuning, es un buen trato.