msaldain f0ea6202e6 Los checkpoints se cargan siempre en CPU
Reanudar en la 2060 fallaba con 'RNG state must be a torch.ByteTensor', y
arreglarlo en un lugar lo movía al siguiente: primero el generador de torch,
después el del cargador de datos. La causa común es que cargar el checkpoint
apuntando a la placa mueve todos los tensores del payload, y los estados de
generadores exigen estar en CPU.

En vez de seguir parcheando cada consumidor, se ataca el origen: el payload se
carga siempre en CPU y desaparece el parámetro map_location. Los pesos no
pierden nada, porque load_state_dict copia dentro de los parámetros existentes,
que ya están en el dispositivo correcto, y el optimizador reubica su estado
solo. El cargador de datos además fuerza CPU por su cuenta, por si un estado
llega desde otro lado.

Es una familia de fallos invisible desde Gigastar: sin placa, map_location es
cpu y los tensores nunca se mueven.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-28 01:31:54 -03:00

ENLACE

Modelo de lenguaje propio, entrenado desde cero, para asistencia general y familiar en español. No es fine-tuning de un modelo existente: tokenizer, datos y pesos son propios.

El plan completo — etapas, presupuestos de cómputo, arquitectura de datos y criterios de verificación — está en docs/PLAN.md.

Estado

Etapa 0 (entorno y validación del stack) implementada y verificada:

  • Capa de configuración validada, con composición por capas y perfiles de hardware.
  • Arquitectura del modelo: RMSNorm, SwiGLU, RoPE, GQA, QK-norm, z-loss.
  • Entrenador con WSD, precisión mixta, acumulación de gradiente y reanudación exacta.
  • Cargadores de datos: bytes (smoke test) y shards uint16 (corpus real).

Primera tool del agente (Etapa 4), que no depende del modelo y ya funciona:

  • Búsqueda web con DuckDuckGo, sin API key ni cuenta en ningún servicio.
.venv/bin/python -m enlace.agent.tools.search "que es home assistant"

71 tests, incluido el de reanudación exacta.

Pendiente: Etapa 1 en adelante (corpus, tokenizer, pretraining, post-training, agente, bases del sistema, memoria, snapshots).

Puesta en marcha

python3 -m venv .venv
.venv/bin/pip install -e ".[dev]"

scripts/prepare_smoke_data.sh          # texto en español de dominio público
.venv/bin/python -m enlace.train.train configs/runs/smoke-cpu.yaml
scripts/test.sh

En el servidor con GPU, por SSH (ver .env.example):

scripts/remote.sh sync
scripts/remote.sh run configs/runs/smoke-2060.yaml     # smoke test, ~10 min
scripts/remote.sh run configs/runs/pretrain-2060.yaml  # pretraining, 1-2 días
scripts/remote.sh logs

Toda corrida larga arranca bajo tmux: cortar el SSH no mata el entrenamiento.

Configuración

Ningún hiperparámetro vive en el código. Las configs se componen por capas:

# configs/runs/pretrain-2060.yaml
include:
  hardware: hardware/turing-2060.yaml   # dtype, backend de atención, batch
  model:    model/tiny-50m.yaml         # capas, dimensiones, contexto
  train:    train/pretrain.yaml         # LR, schedule, intervalos
  data:     data/corpus.yaml            # de dónde salen los tokens

Overrides puntuales desde la línea de comandos, para probar variantes sin editar archivos:

.venv/bin/python -m enlace.train.train configs/runs/smoke-cpu.yaml train.seed=99

Una config inválida falla al arrancar con un mensaje concreto, no a las tres horas de entrenamiento.

Hardware

El perfil de hardware es la única capa que cambia al migrar de placa.

Perfil Placa dtype Atención Notas
turing-2060 RTX 2060 12 GB (sm_75) float16 + GradScaler mem_efficient Turing no soporta bfloat16 ni FlashAttention-2
blackwell-5090 RTX 5090 32 GB (sm_120) bfloat16 flash Requiere PyTorch ≥ 2.7 con CUDA 12.8
cpu float32 math Solo desarrollo y tests

enlace/train/backends.py es el único archivo del entrenamiento que conoce diferencias entre placas, y valida el perfil contra la GPU real antes de empezar: pedir bfloat16 en Turing falla de inmediato en vez de degradarse en silencio.

Estructura

enlace/config/    Esquemas pydantic y composición de YAML
enlace/model/     Transformer decoder-only y selección de backend de atención
enlace/train/     Bucle, schedules, checkpointing, detección de hardware
enlace/data/      Cargadores con reanudación exacta
configs/          hardware × model × train × data, compuestos en configs/runs/
scripts/          Utilidades: remote.sh, test.sh, prepare_smoke_data.sh
tests/            Suite completa; test_resume.py es el crítico
S
Description
No description provided
Readme 272 KiB
Languages
Python 96%
Shell 4%