Hugging Face · LLM Course · Capítulo 4

Compartir modelos y tokenizers

Cerrando el círculo del Capítulo 3: entrenaste algo, ¿ahora qué? Este capítulo es corto pero tiene el contenido que más envejeció de todo el curso — la forma de subir un modelo cambió bastante desde 2022.

0. El Hub no es solo un catálogo

El original menciona "más de 10.000 modelos públicos" — una cifra que hoy se cuenta en millones. Lo que no cambió es la idea de fondo: cada modelo es un repositorio con control de versiones (antes puro git, hoy con un backend propio de Hugging Face optimizado para archivos enormes), y subir un modelo público despliega automáticamente una forma de probarlo sin descargar nada.

1. Usar cualquier modelo público

Cualquier checkpoint del Hub se usa igual que los que ya viste, con un identificador (usuario/nombre-del-modelo) en vez de un nombre "oficial":

from transformers import pipeline

fill_mask = pipeline("fill-mask", model="camembert-base")
fill_mask("Le camembert est <mask> :)")
# → délicieux, excellent, succulent...

Lo único que hay que verificar es que el checkpoint sea compatible con la tarea: camembert-base funciona perfecto en fill-mask, pero cargarlo en text-classification daría resultados sin sentido — el head que tiene entrenado no sirve para eso. Para cargar un modelo "a mano" (sin pipeline()), preferí siempre las clases Auto* sobre la clase específica de arquitectura:

# Funciona, pero te ata a la arquitectura CamemBERT específicamente
from transformers import CamembertTokenizer, CamembertForMaskedLM

# Preferible: agnóstico a la arquitectura, cambiar de checkpoint es trivial
from transformers import AutoTokenizer, AutoModelForMaskedLM

Antes de usar cualquier checkpoint ajeno en algo real, revisá su model card (sección 3): cómo se entrenó, con qué datos, y qué límites o sesgos documenta el autor.

2. Compartir el tuyo

Si entrenaste algo con la Trainer API (Capítulo 3), subirlo es un flag:

training_args = TrainingArguments("bert-finetuned-mrpc", push_to_hub=True)
# trainer.train() sube una nueva versión cada vez que guarda un checkpoint
trainer.push_to_hub()  # subida final + genera una model card automática

O directamente desde un modelo/tokenizer ya cargado, sin pasar por Trainer:

model.push_to_hub("mi-modelo")
tokenizer.push_to_hub("mi-modelo")  # mismo repo, ambos juegos de archivos

Y para control más fino — crear el repo primero, subir archivos sueltos, manejar visibilidad — huggingface_hub expone esas operaciones directamente:

from huggingface_hub import create_repo, upload_folder

create_repo("mi-modelo", private=True)
upload_folder(repo_id="usuario/mi-modelo", folder_path="./mi_carpeta_local")

🟢 Actualización 2026

El original le dedica la mitad del capítulo a clonar el repo con git, inicializar git-lfs a mano, y a la clase Repository de huggingface_hub para manejar todo eso de forma más amigable. Esa clase está deprecada — el flujo de hoy es 100% HTTP, sin git de por medio para nada: upload_folder() (y su variante upload_large_folder() para checkpoints de decenas de GB) sube en paralelo, reanuda si se corta, y deduplica contenido repetido entre versiones a nivel de bloque, no de archivo completo. Nunca vas a necesitar tipear git lfs install a mano en 2026.

🔧 Ya hiciste exactamente esto

Los checkpoints NVFP4 de tu pipeline de cuantización están publicados así: melcheikh/gemma-4-31B-it-qat-NVFP4-mse-Blackwell y su asistente, agrupados en una collection. Y la decisión inversa importa tanto como la de publicar: el checkpoint analyst — tu fine-tune propietario — deliberadamente no se publicó. Compartir en el Hub no es todo-o-nada; es una decisión por repositorio.

3. La ficha del modelo (model card)

El README.md de un repo de modelo es la model card — tan importante como los pesos mismos, porque es lo único que le dice a alguien que no sos vos si el modelo sirve para lo que necesita. El original propone esta estructura, que sigue siendo el estándar de facto:

Sección	Qué responde
Model description	Arquitectura, versión, paper de origen, autor
Intended uses & limitations	Para qué sirve — y, más importante, para qué no
Training data / procedure	Con qué se entrenó, cuántas épocas, learning rate, hardware
Evaluation results	Métricas, en qué dataset, en qué split

Un header en YAML al principio del archivo es lo que el Hub parsea para poder filtrar por idioma, licencia o dataset:

---
language: es
license: apache-2.0
base_model: google/gemma-4-31B-it-qat
tags: [nvfp4, quantized, blackwell]
---

🟢 Actualización 2026

base_model es el campo que el original no menciona porque en 2022 casi no había derivados — hoy la mayoría de lo que se publica es un fine-tune, un adaptador LoRA o una cuantización de otro modelo, no algo entrenado desde cero. Ese campo es lo que conecta un checkpoint con su origen en el árbol de linaje que el Hub muestra en la página del modelo.

🔧 Tu propia model card ya sigue esta receta

Las model cards de tus checkpoints NVFP4 documentan exactamente lo que este capítulo pide y nada más: la receta de cuantización usada (nvfp4_mse), el hallazgo de que las escalas de KV cache calibradas rompen el modelo (una limitación real, documentada para que nadie la repita), y la matriz de compatibilidad con vLLM para el draft especulativo — pero nada sobre el uso interno del checkpoint analyst, que es justamente el que no se publicó. Transparencia sobre lo público, silencio deliberado sobre lo que no lo es.

4. Resumen

Cualquier checkpoint del Hub se usa igual que uno "oficial" — el identificador es lo único que cambia. Verificá siempre que el head del checkpoint sirva para tu tarea.
Subir un modelo son tres niveles equivalentes: el flag de Trainer, push_to_hub() en el objeto, o huggingface_hub para control fino — todos HTTP, sin git manual.
La model card es donde documentás qué es el modelo, para qué sirve, y para qué no. El header YAML es lo que hace que el Hub pueda indexarlo.
Publicar es una decisión por repositorio, no un compromiso de todo o nada — podés compartir un checkpoint y quedarte con otro, como ya hiciste vos.