Requisitos de Implementación: 4GB VRAM

Entiendo el desafío. Intentar entrenar un LLM en una GPU de consumo con solo 4GB de VRAM es un acto de ingeniería rigurosa, no un ejercicio teórico. La realidad es que el entrenamiento completo está fuera de la mesa. Nuestra única solución viable y robusta es QLoRA (Quantized Low-Rank Adaptation) combinada con el ecosistema de bitsandbytes para la cuantificación a 4 bits, permitiendo cargar el modelo base en la memoria extremadamente limitada. Es un proceso desafiante que requiere coraje técnico y ajustes quirúrgicos en la configuración.

Requisitos Previos (Stack Técnico)

Antes de intentar cualquier cosa, asegúrate de tener el stack base listo. Estamos trabajando con PyTorch y el pipeline de Hugging Face. El sistema operativo debe ser Linux (Ubuntu/Debian) para la mejor compatibilidad con los drivers de NVIDIA y CUDA. Necesitarás una versión de CUDA que soporte tu GPU y PyTorch. Asumo que ya tienes `nvidia-smi` funcionando.

# 1. Verificar drivers NVIDIA y CUDA nvidia-smi  # 2. Instalación de dependencias críticas (dentro de un entorno virtual) python3 -m venv qlora_env source qlora_env/bin/activate pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 pip install transformers peft bitsandbytes accelerate datasets trl

Paso 1: Configuración QLoRA y Cuantificación a 4 Bits

El cuello de botella es la VRAM. El truco de QLoRA es cargar los pesos del modelo base en 4 bits (cuantización) y solo entrenar una fracción mínima de parámetros (matrices LoRA) en 16 bits o bfloat16. Esto reduce la huella de memoria en un factor de 4. Si fallas aquí, el kernel de CUDA fallará con un error de memoria (OOM).

El siguiente script en Python es el núcleo de la operación. Presta atención a los parámetros `bnb_4bit_quant_type` y `load_in_4bit`.

import torch from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig from peft import LoraConfig, get_peft_model  # Configuración de Cuantización a 4 bits bnb_config = BitsAndBytesConfig(     load_in_4bit=True,     bnb_4bit_quant_type="nf4", # Normal Float 4: más estable para Fine-Tuning     bnb_4bit_use_double_quant=True,     bnb_4bit_compute_dtype=torch.bfloat16 # Tipo de cómputo )  # Carga del modelo (ejemplo con un modelo pequeño, 'TinyLlama/TinyLlama-1.1B-Chat-v1.0') model_id = "TinyLlama/TinyLlama-1.1B-Chat-v1.0" model = AutoModelForCausalLM.from_pretrained(     model_id,     quantization_config=bnb_config,     device_map="auto" # Mapeo automático de dispositivos )  # Configuración LoRA lora_config = LoraConfig(     r=8, # Rango LoRA bajo, crucial para 4GB     lora_alpha=16,     target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],     lora_dropout=0.05,     bias="none",     task_type="CAUSAL_LM" )  # Aplicación de PEFT model = get_peft_model(model, lora_config) model.print_trainable_parameters()

Este bloque de código es la única forma de que un modelo de más de 1.000 millones de parámetros respire en 4GB de VRAM. El parámetro clave aquí es el rango `r=8`, que define la complejidad de las matrices LoRA que estamos entrenando. Un `r` más bajo minimiza la sobrecarga de VRAM de los adaptadores, lo cual es vital. Además, la carga con `device_map=”auto”` nos permite optimizar automáticamente el uso de memoria.

Paso 2: Optimización del Entrenamiento y Métricas Críticas

Una vez que el modelo está cargado, el siguiente escollo es el proceso de entrenamiento real. En 4GB de VRAM, es físicamente imposible usar un `batch_size` mayor a 1. Para compensar esto y simular un tamaño de lote efectivo mayor, tenemos que utilizar la acumulación de gradientes. También debemos activar el `gradient_checkpointing` para liberar más memoria en el forward pass, a costa de un tiempo de backward pass ligeramente mayor.

# TRL SFTTrainer arguments para optimización de recursos training_arguments = TrainingArguments(     output_dir="./qlora_results",     num_train_epochs=3,     per_device_train_batch_size=1,        # OBLIGATORIO en 4GB VRAM     gradient_accumulation_steps=8,       # Simula un batch de 8     optim="paged_adamw_8bit",            # Optimización de RAM/VRAM     learning_rate=2e-4,     fp16=False,                           # Usamos bfloat16 por BitsAndBytes     max_grad_norm=0.3,     logging_steps=10,     save_steps=100,     report_to="none",     gradient_checkpointing=True,         # Esencial para ahorrar VRAM )

Monitoreo de Uso de VRAM

El monitoreo es fundamental. Durante la fase de carga del modelo, el uso de VRAM debería estabilizarse cerca de 3.5GB a 3.8GB. Si excede los 3.9GB, tu sistema colapsará. Ejecuta un script de prueba corto con `per_device_train_batch_size=1` y monitoriza el consumo de VRAM y el tiempo por paso.

Para verificar que no estás excediendo los límites mientras se ejecuta el entrenamiento (usando `accelerate launch` o directamente con el script):

# Comando de monitoreo en tiempo real watch -n 0.5 nvidia-smi

Paso 3: Análisis de Métricas de Rendimiento

La métrica de rendimiento que realmente importa aquí no es solo la pérdida, sino el Tiempo por Paso (T/step). En una configuración de 4GB VRAM, con un modelo de 1B de parámetros y la configuración QLoRA optimizada (`r=8`, `batch_size=1`, `gradient_accumulation_steps=8`), deberías esperar un rendimiento en el rango de 2.5 a 4.0 segundos por paso de entrenamiento. Cualquier tiempo significativamente superior indica un swap de datos excesivo hacia la RAM del sistema (Host Memory), lo cual ralentiza todo.

Las siguientes métricas simuladas reflejan un resultado aceptable en hardware limitado, donde se prioriza la finalización del proceso sobre la velocidad bruta.

Epoch | Step | Train Loss | VRAM Usage (GB) | Time/Step (s) -------------------------------------------------------------- 1/3   | 10   | 1.85       | 3.75            | 3.2s 1/3   | 50   | 1.52       | 3.76            | 3.1s 2/3   | 10   | 1.30       | 3.75            | 3.0s

La estabilidad en el uso de VRAM alrededor de 3.75GB es la señal de que los ajustes de QLoRA y el gradient checkpointing están funcionando como un protocolo eficiente. Si este número sube o fluctúa demasiado, la configuración debe ser reevaluada, posiblemente bajando aún más el rango LoRA o reduciendo el tamaño del contexto de secuencia si el modelo lo permite.

El batch size de 1 y la acumulación de gradientes es un compromiso. Se requiere mucha más paciencia, pero es el único camino pragmático para ejecutar esto fuera de una infraestructura de nube o una GPU de alta gama. Lo lograste. Ahora, a esperar.