model.push_to_hub(nombre_repo)
tokenizer.push_to_hub(nombre_repo)
El modelo lleva los pesos y su config.json; el tokenizador lleva el
vocabulario, las reglas de segmentación y —si es de chat— la plantilla. Un repositorio con
pesos y sin tokenizador no es un modelo a medias: es un modelo inservible, porque nadie
puede reconstruir los ids que esos pesos esperan.
Falta una tercera cosa que no sube ninguna llamada: la model card, el
README.md del repositorio. Con qué datos se entrenó, qué métricas dio, en qué
falla, bajo qué licencia. Sin ella has publicado un binario.
No es una metáfora: hay commits, ramas y tags. De ahí sale el revision que
fijabas al cargar un modelo — es el mismo mecanismo, ahora visto desde el lado de quien
publica.
create_repo(nombre, private=True) para datos de empresa. Pero el riesgo real
no es que se vea el nombre del repositorio:
Un modelo ajustado con tus datos puede memorizar fragmentos de ellos. Los pesos son un derivado del dataset, y de algunos derivados se puede extraer información.
Un modelo base que subes bajo tu nombre arrastra la licencia del original. Republicar los pesos de otro sin su ficha ni su licencia no los convierte en tuyos.
La pregunta antes de pulsar subir es la misma que antes de descargar, invertida: ¿de quién es esto y qué me deja hacer con ello?
| Inferencia bajo demanda | Endpoint dedicado | |
|---|---|---|
| El modelo está cargado | Solo cuando hay tráfico | Siempre |
| Primera petición tras un rato | Lenta: hay que cargarlo | Rápida |
| Coste | Por uso, con límites de tasa | Por tiempo de servidor reservado |
| Aislamiento de red | Compartido | Propio |
| Bueno para | Demos, prototipos, tráfico esporádico | Producción con compromiso de latencia |
El cold boot —esa primera petición lenta, o un 503 mientras
el modelo carga— no es un fallo: es la contrapartida de no tener un servidor reservado. Si
tu producto no puede tolerarlo, el problema no es el error, es la elección de modalidad.
import requests
def query(payload):
r = requests.post(API_URL,
headers={"Authorization": f"Bearer {TOKEN}"},
json=payload)
return r.json()Del lado del consumidor no hay PyTorch, ni pesos, ni GPU. Ese es todo el punto: quien integra no necesita saber nada de ML.
La misma guía que en su primera lección escribe «NUNCA pongas tokens
directamente en el código», en ésta escribe
TOKEN = "hf_TU_TOKEN_DE_ESCRITURA" seguido de
login(token=TOKEN). Y su ejemplo de cURL pone el token en la línea de
comandos, donde acaba en el historial del shell. Es la regla y su incumplimiento en el
mismo documento, con veinte páginas de separación.
El ejercicio propone descargar un modelo ajeno y volver a subirlo «con nuestro nombre para simular el proceso». Eso es republicar los pesos de otro sin arrastrar su ficha ni su licencia — exactamente lo que la propia guía advierte que hay que revisar antes de usar un modelo. Como práctica de mecánica de Git está bien; como hábito, no. Si lo haces, marca el repositorio como privado y di en el README de dónde salen los pesos.
Y tres datos que hay que verificar antes de repetirlos, porque salen de un PDF sin fecha y la superficie de inferencia de HuggingFace se ha reorganizado más de una vez: el host concreto de la API que aparece en el código, que la inferencia bajo demanda sea gratuita, y los «20-30 s» de cold boot. Los tres se comprueban en la documentación oficial en dos minutos. Ninguno se comprueba leyendo el PDF.
Crea un repositorio privado, sube un modelo pequeño con sus dos llamadas
(model y tokenizer) y mira la lista de ficheros en la web.
Comprueba que están el config.json y los del tokenizador, no solo los pesos.
Después haz la prueba que de verdad valida el despliegue: desde otro directorio y con la caché limpia, carga el modelo por su identificador de repositorio y ejecuta una inferencia. Si funciona sin copiar nada a mano, el pack está completo.
Y escribe el README antes de cerrar: tres líneas diciendo de dónde salen los pesos, con qué datos se tocaron y qué licencia aplica. Es el único fichero del repositorio que dentro de tres meses vas a agradecer.