7 TB de pesos: cómo saber si valen algo

Un modelo es, sobre todo, una montaña de números

Un modelo de lenguaje no guarda frases, ni reglas, ni una base de datos de respuestas. Guarda números: millones en uno pequeño y billones en los más grandes. Cada vez que escribe una palabra hace con ellos una larga cadena de multiplicaciones y sumas, y de ahí sale la siguiente.

Esos números se llaman parámetros, y a los que se aprenden se les llama pesos. Al descargar un modelo se bajan, sobre todo, esos números, más dos ficheros pequeños: la configuración, que dice cómo van ordenados, y el tokenizador, que trocea el texto en las piezas con las que trabaja el modelo.

Que sean «solo números» no es un detalle técnico. De eso depende cuánto ocupa un modelo, en qué ordenador cabe, cómo se puede comprobar sin ejecutarlo y qué puede salir mal al abrir el fichero. Todo se ve mejor con un ejemplo real y pequeño, medido por nosotros.

Un parámetro es un número que se puede ajustar

Un parámetro es como uno de los miles de mandos de una mesa de mezclas: por sí solo no significa nada, pero entre todos deciden lo que suena. Entrenar un modelo es mover todos esos mandos a la vez, un poquito en cada paso, hasta que lo que sale se parece a lo que tiene que salir.

El número de parámetros es la cifra que acompaña al nombre de casi cualquier modelo, y hay que leerla con cuidado. El 135M de SmolLM2-135M son unos 135 millones. Un modelo «de 14T» presume de unos 14 billones, un millón de millones cada uno.

No es una cifra opaca: con la configuración del modelo se puede calcular a mano. Lo hicimos el 2 de noviembre de 2026 con SmolLM2-135M.

SmolLM2: 134.515.008 números contados a mano

SmolLM2-135M es un modelo de lenguaje pequeño publicado por HuggingFaceTB, un equipo de Hugging Face, la empresa estadounidense de origen francés en cuya plataforma se publican la mayoría de los modelos abiertos. Su repositorio se creó el 31 de octubre de 2024, tiene licencia Apache 2.0 y se ha descargado 2.392.045 veces en los últimos 30 días. Son 10 ficheros, y el de los pesos, model.safetensors, ocupa 269.060.552 bytes.

Su config.json da las medidas: un vocabulario de 49.152 piezas, 576 números para describir cada una, 30 capas y un tamaño intermedio de 1.536. Con eso sale la cuenta. La tabla de palabras tiene 49.152 × 576 = 28.311.552 números. Cada capa suma 884.736 en su primera pieza principal, 2.654.208 en la segunda y 1.152 en dos normalizaciones: 3.540.096, que por 30 capas dan 106.202.880. Queda una normalización final de 576.

Total: 134.515.008 parámetros. La tabla de palabras se cuenta una sola vez porque el modelo la usa tanto para leer como para escribir, y así lo declara su configuración con tie_word_embeddings. El nombre redondea: 135M.

Por qué un modelo ocupa lo que ocupa

Si un modelo es una lista de números, su tamaño es casi una multiplicación: número de parámetros por bytes por número. En SmolLM2, 134.515.008 × 2 = 269.030.016 bytes. El fichero real pesa 269.060.552. Sobran 30.536 bytes, y no son un error: son la cabecera, 8 bytes que dicen cuánto mide y 30.528 de texto con el índice de lo que viene detrás.

La regla escala sin sorpresas. Un modelo de un billón de parámetros a 2 bytes por número son 2 billones de bytes, 2 TB, antes de contar nada más. Por eso los modelos grandes se reparten en cientos de ficheros y se miden en terabytes. Y por eso, para un mismo modelo, la forma de que ocupe menos es guardar cada número en menos bytes.

Los pesos van ordenados en tensores

Los 134.515.008 números de SmolLM2 no van sueltos: están repartidos en 272 tensores. El más grande, model.embed_tokens.weight, es la tabla de palabras: 49.152 filas, una por cada pieza del vocabulario, y 576 columnas. Otros son diminutos: model.layers.0.input_layernorm.weight es un vector de 576 números.

El nombre dice dónde va cada uno: layers.0 es la primera capa, y mlp, self_attn o layernorm, la pieza de esa capa. La forma dice cuántos números tiene: basta multiplicar sus dimensiones. Sumando las formas de los 272 tensores sale otra vez 134.515.008, lo mismo que la cuenta hecha con la configuración.

Qué hay dentro de un fichero safetensors

Un safetensors tiene tres partes y ninguna sorpresa. Los primeros 8 bytes son un número: la longitud de la cabecera. Después va la cabecera, un texto en formato JSON con una entrada por tensor: su nombre, su tipo de número, su forma y en qué byte empieza y termina. Y detrás, todos los números seguidos, sin nada más.

En SmolLM2 la cabecera mide 30.528 bytes, así que los números empiezan en el byte 30.536. Su primera entrada dice que model.embed_tokens.weight es BF16, tiene forma 49.152 × 576 y ocupa de la posición 0 a la 56.623.104 de la zona de datos. Y 8 + 30.528 + 269.030.016 da el tamaño exacto del fichero: no queda un solo byte sin explicar.

Que no haya código es la gracia del formato. La documentación de Transformers, la biblioteca de Hugging Face para usar modelos, lo resume así: los pesos de PyTorch se han guardado tradicionalmente con pickle, «que se sabe que es inseguro», y los ficheros safetensors «son más seguros y más rápidos de cargar».

El mismo modelo en GGUF

Hay una versión de SmolLM2 en GGUF: la Instruct, la variante preparada para conversar, que bartowski, un usuario de Hugging Face, ha convertido y publicado con la misma licencia. El fichero en Q4_K_M ocupa 105 MB, frente a los 269 del original.

Su cabecera también se lee sin bajar el fichero entero: pedimos los primeros 4 MB y bastaron 1.785.944 bytes. Dice: magic GGUF, que es la firma del formato; versión 3; 272 tensores, los mismos que el safetensors; 37 claves de metadatos; arquitectura llama, y file_type 15, que según la especificación significa Q4_K_M.

105 MB en vez de 269: menos bits por número

La diferencia entre 269 y 105 MB es la cuantización, y Q4_K_M es el nombre de una de sus recetas en GGUF. El nombre engaña un poco: la cabecera muestra que no todo va al mismo número de bits. La receta mezcla varios tipos, y deja sin comprimir, en F32, los vectores pequeños, como los de normalización.

El principio no cambia: tamaño, más o menos, igual a número de parámetros por lo que ocupa cada uno. La cuantización solo toca el segundo factor.

Aprendido o al azar: se nota en la forma de los números

Un modelo empieza con números al azar y el entrenamiento les da estructura. ¿Se nota mirando solo los números? Lo comprobamos con SmolLM2: a cada tensor real le pusimos al lado ruido generado con NumPy, la biblioteca de cálculo numérico de Python, con la misma forma y la misma desviación típica. Mismo tamaño, misma dispersión; solo cambia si hay aprendizaje detrás.

La primera diferencia está en los extremos. El ruido es una campana bien redonda. Una matriz real de la capa 15 (q_proj) también concentra sus valores cerca del cero, pero tiene muchos más muy alejados: sus extremos llegan más del doble de lejos que los del ruido. Son colas pesadas, y la tabla de la sección siguiente las mide.

La segunda está en las normalizaciones, las piezas que reajustan la escala de los números entre un paso y el siguiente con un vector de pesos propio. En ellas, 1 es el valor neutro, el que deja la escala como está. En SmolLM2 medimos los de las capas 0, 7, 15, 22 y 29, y ninguno tiene todos sus valores a 1. Los de las capas 7, 15, 22 y 29 tienen medias de entre 0,31 y 0,42; el de la 15, 0,34. La excepción es la capa 0: su vector sale con media 0,001, centrado en el cero como el ruido.

El significado también deja huella

La prueba más intuitiva está en la tabla de palabras. Con el tokenizador de SmolLM2 buscamos qué fila corresponde a cada palabra y medimos el parecido entre pares, en el modelo real y en su copia de ruido. En el real, los pares con relación, como king y queen o Paris y France, salen por encima de los que no la tienen, como king y banana. En el de ruido, todos rondan el cero.

Un aviso honesto: en SmolLM2, dos tokens cualesquiera ya se parecen un +0,45 de media, porque todos comparten una dirección común. Los pares sin relación que elegimos, de +0,18 a +0,22, quedan por debajo de esa media, y por eso el +0,62 de king y queen no puede leerse por sí solo. Lo que cuenta es que en la copia de ruido todos los pares, relacionados o no, dan prácticamente cero.

Con un modelo de 269 MB todo esto tarda 3,2 segundos. Uno de 7,72 TB no se puede bajar entero para probar, pero sí se pueden mirar trozos.

Antes de descargar: ficha, tamaño y cabecera

Antes de bajar un modelo grande hay comprobaciones que cuestan segundos y no exigen descargar los pesos. La primera es la ficha y la API pública del Hub de Hugging Face: quién lo publica, cuándo se creó, con qué licencia, cuántas descargas tiene y la lista de ficheros con su tamaño. Ahí se ve si hay ficheros .py, que son código, y si hay ficheros pickle (.bin, .pt, .pkl). En SmolLM2: 10 ficheros, ni código ni pickle, en medio segundo.

La segunda es la cuenta del tamaño: parámetros por bytes por número tiene que dar, casi exactamente, lo que ocupan los pesos. Si un repositorio promete una cifra de parámetros y sus ficheros no cuadran, hay algo que explicar.

La tercera es leer solo la cabecera del safetensors con una petición HTTP de rango, la que pide un trozo concreto de un fichero en vez del fichero entero. La documentación de Hugging Face lo propone: es «muy sencillo y eficiente» obtener la lista de tensores, sus tipos y sus formas «con pequeñas peticiones HTTP de rango». Se piden los bytes 0 a 7, se leen como un entero de 64 bits sin signo en orden little-endian, que da la longitud de la cabecera, y se pide el tramo siguiente hasta completarla. En SmolLM2 fueron unos 30 KB y 1,2 segundos, en vez de 269 MB.

Quedan dos comprobaciones sobre lo que puede ejecutarse al cargar el modelo —el código y el formato pickle— y una última sobre los números: medir si parecen aprendidos, como en las dos secciones anteriores, y, si alguien publica una receta para generarlos, reproducirla.

Si pide trust_remote_code, ejecutará código del autor

La documentación de Transformers lo dice sin rodeos: hay que tener «precaución extra» al cargar un modelo personalizado, porque, aunque el Hub analiza cada repositorio en busca de malware, conviene tener cuidado para «evitar ejecutar sin querer código malicioso». Y propone una capa más de seguridad: cargarlo «desde una revisión concreta», para no recibir código que haya cambiado.

En la práctica son dos gestos. Leer los .py como texto antes de cargar nada, buscando si abren conexiones, lanzan procesos o ejecutan texto como si fuera código. Y fijar la revisión: el identificador de la versión exacta del repositorio que se ha leído, para cargar esa y no la que haya mañana.

Pickle, el formato que puede ejecutar código al abrirse

La documentación del Hub lo advierte: «hay ataques peligrosos de ejecución arbitraria de código que se pueden perpetrar al cargar un fichero pickle». Hugging Face analiza los pickles que se suben y lo que importan, pero reconoce que eso «no es infalible al cien por cien» y que comprobar si algo es seguro «es responsabilidad del usuario». La salida es preferir safetensors.

Su escáner de malware tiene además un límite escrito: «pasamos por un escáner de malware cada fichero de tus repositorios de menos de 2 GB». Es un dato que conviene tener a mano al mirar el caso siguiente.

numbat: 7,72 TB que dicen ser de Anthropic

burner22/numbat es un repositorio de Hugging Face que, según su README —el texto de presentación del repositorio—, contiene un punto de control filtrado de un modelo de Anthropic —la empresa que desarrolla Claude— de unos 14 billones de parámetros y con «numbat» como nombre en clave. No consta ningún pronunciamiento de Anthropic. Su fichero de metadatos declara el paso de entrenamiento 1.830.000 y unas puntuaciones que no hemos verificado.

La API, consultada el 2 de noviembre a las 10:31, da el retrato: autor burner22; creado el 23 de octubre de 2026 y modificado por última vez el 24; 5.846 descargas y 248 «me gusta»; 784 ficheros, de los que 772 son trozos .safetensors que suman 7,72 TB, cada uno de entre 5,8 y 10,4 GB. Hay 2 ficheros .py, ningún pickle, y el README propone, como alternativa de carga, trust_remote_code=True.

¿Cuadran los 14 billones? Los metadatos del Hub cuentan 6,83 billones de números de 8 bits (U8) y 16.900 millones en BF16. El repositorio declara el formato NVFP4, de 4 bits: si cada U8 empaqueta dos números de 4 bits, salen unos 13,7 billones. Es una interpretación nuestra, no verificada.

Y el dato de antes, puesto al lado: según su documentación, el Hub pasa por el escáner de malware los ficheros de menos de 2 GB, y los de numbat pesan entre 5,8 y 10,4 GB. Qué supone eso para este repositorio no lo hemos comprobado.

Una receta reproduce parte de sus números

El 1 de noviembre, el usuario FloxUnder abrió en el repositorio la discusión «43 complete tensors exactly match name-seeded NumPy RNG output»: 43 tensores completos coinciden exactamente con lo que da el generador aleatorio de NumPy sembrado con su nombre. La receta que publica es esta: se calcula la huella SHA-256 del nombre del tensor, sus 8 primeros bytes se leen como un entero big-endian sin signo y ese número es la semilla del generador PCG64 de NumPy; se sacan números de una normal en float32, se aplica exp(0,06·z) a las normalizaciones y z/6 a las convoluciones, y se pasa a BF16.

Según su autor, 43 tensores completos, 730.368 valores, salen idénticos bit a bit, y otros 21 los predijo antes de leerlos. Él mismo pone el límite: «Estas coincidencias por sí solas no pueden excluir lógicamente un entrenamiento que hubiera mantenido congelados a propósito todos estos parámetros. Tampoco autentican el supuesto origen en Anthropic».

Nuestra reproducción usó la revisión fijada 6b7f8fc y bajó 295 KB por rango en 6,9 segundos. La receta, aplicada a 5 tensores completos del primer fichero —tres normalizaciones de 12.288 valores y dos filtros de convolución de 24.576 y 49.152—, coincide byte a byte en los 5, y las huellas de dos de ellos son las que publica la discusión. Como control, la misma receta con la semilla de otro nombre no coincide. Y el vector de normalización sale con media 1,003; el de SmolLM2 tenía 0,34.

Las matrices grandes y los dos ficheros de código

La receta no lo explica todo. En los primeros 4.096 valores de cuatro matrices grandes (embed_tokens, down_proj, q_proj y o_proj), el parecido con la serie sembrada por su nombre es el mismo que con la de otro nombre: prácticamente nulo. Tres de ellas tienen colas pesadas, como una matriz entrenada; la tabla de palabras sale con forma de campana en ese trozo.

Eso no demuestra ni que sean auténticas ni que sean falsas. Miramos los primeros 4.096 valores de matrices de entre 75,5 y 1.610 millones de valores y no comprobamos los tensores de 4 bits, que son casi todo el modelo. Lo que sí queda probado es más modesto: al menos una parte de los tensores de numbat sale de un generador de números aleatorios sembrado con su propio nombre.

Los dos .py, leídos solo como texto, definen la configuración y la arquitectura del modelo. Importan math, typing, torch y transformers, y no aparecen os.system, subprocess, requests, eval, exec, open ni pickle. Que hoy sean inocuos no cambia la regla: lo examinado es una revisión concreta, el repositorio puede cambiar y trust_remote_code=True ejecuta lo que haya en la revisión que se cargue.

Los pasos de la prueba

Todo se hizo el 2 de noviembre entre las 10:29 y las 10:33, con Python 3.12 y NumPy, sin PyTorch ni Transformers. No se cargó ningún modelo ni se ejecutó ningún código descargado, y de numbat no se bajó ningún fichero de pesos entero. Coste: 0 euros.

Cada paso usa un script propio y pequeño que consulta la API pública del Hub o pide por rango un trozo de fichero, y calcula con NumPy; las descargas se hacen con curl. Los scripts de Python se lanzan con python -I, el modo aislado, que impide que Python importe por sorpresa ficheros de la carpeta de trabajo; la búsqueda de texto, con sh.

Lo que esta prueba no dice

No dice de dónde sale numbat. Su README afirma que es de Anthropic, no consta ningún pronunciamiento de la empresa, y la discusión 13, que hemos reproducido en parte, apunta a ruido sintético en al menos las normalizaciones y las convoluciones. Nada de eso determina su origen.

Tampoco dice si el modelo funciona ni cómo: no se cargó ni se ejecutó, y las puntuaciones de su fichero de metadatos siguen siendo las que declara el repositorio. Reprodujimos 5 de los 43 tensores de la discusión y ninguno de los 21 predichos, y de cada matriz grande miramos un trozo. La lectura de los .py vale para la revisión 6b7f8fc, no para la que haya mañana.

Y no es una invitación a descargarlo. Quien lo haga, como mínimo, debería leer antes su código, fijar la revisión y tener presente que son 7,72 TB.