Cuenta los parámetros de un transformer y la memoria de GPU desde su arquitectura real. Tiene en cuenta GQA, SwiGLU y mezcla de expertos.
Los valores de arquitectura se leen del archivo de configuración de cada modelo, así que el número de parámetros se deriva en lugar de consultarse.
También podrías encontrar útiles estas calculadoras
Elige tu GPU y descubre qué LLM caben de verdad
Compara GPU autoalojada frente a API de inferencia
Comprueba si tu prompt cabe en la ventana de contexto
Calcula requisitos de almacenamiento para bases de datos vectoriales
Detrás de casi toda búsqueda de una calculadora de tamaño de modelo hay dos preguntas: cuántos parámetros tiene realmente y si cabrá en el hardware disponible. Esta herramienta responde a ambas partiendo de la arquitectura real del modelo y no del número que lleva en el nombre. Si eliges un modelo, el número de capas, el tamaño oculto, el reparto de cabezas de atención y la configuración de expertos salen de su propio archivo de configuración. También puedes introducir una arquitectura y ver cómo se deduce el número de parámetros. En ambos casos obtienes la memoria de los pesos, la caché KV para tu longitud de contexto y un veredicto por tarjeta sobre si cabe.
Casi todo está en el bloque transformer que se repite. Cada bloque contiene las proyecciones de atención y una red feed-forward, y se repite una vez por capa. Encima está el embedding de tokens y, si no está atado a él, la cabeza de salida. Lo que ha cambiado desde los primeros GPT es la forma de esas piezas. La atención de consulta agrupada hace que las proyecciones de clave y valor sean mucho más estrechas que la de consulta, así que la atención pesa menos que con la vieja estimación de cuatro matrices cuadradas. Los bloques feed-forward con compuerta, como SwiGLU, usan tres matrices donde el diseño original usaba dos, así que la red feed-forward pesa más. Los embeddings de posición rotatorios sustituyeron las tablas posicionales aprendidas y eliminaron ese término por completo. Una fórmula escrita para arquitecturas de 2019 se equivoca en las tres cosas, y los errores no se cancelan.
Parámetros
El caso más común: una cantidad fija de VRAM y la duda de qué modelos y cuantizaciones caben dentro.
El estado del optimizador a 12 bytes por parámetro y los gradientes encima hacen que entrenar necesite varias veces la memoria de inferir, antes incluso de las activaciones.
Un modelo MoE con los mismos parámetros activos que uno denso necesita mucha más memoria, y aquí la diferencia se ve explícita.
Ver crecer la caché KV con la longitud de secuencia explica por qué un modelo que va bien con prompts cortos se cae con los largos.
Introduce una arquitectura y verás cada término por separado, útil cuando un recuento publicado y tus propias cuentas no coinciden.
Un modelo llamado 8B puede tener 7.600 o 8.200 millones de parámetros. Cuando decides si algo cabe en 24 GB con una caché KV encima, esa diferencia es la que separa ejecutarlo de no poder hacerlo.
Un modelo con 32 cabezas de consulta y 8 de clave/valor tiene mucho menos peso en atención que uno con 32 de cada. Tratarlos igual sobreestima la atención y sobreestima la caché KV en la proporción entre ambas.
SwiGLU añade una matriz de compuerta junto a las de subida y bajada. Como la red feed-forward suele ser la parte más grande de una capa, olvidar esa tercera matriz infravalora el modelo entero.
Un modelo MoE debe mantener todos los expertos en memoria pero solo enruta unos pocos por token. Los parámetros totales deciden si carga; los activos deciden a qué velocidad va. Un solo número no puede responder a las dos cosas.
Con contexto corto dominan los pesos. Con contexto largo la caché puede superarlos, y por eso el mismo modelo cabe con 4k y falla con 128k en el mismo hardware.
Suma la memoria de los pesos, la caché KV para tu longitud de contexto y algo de espacio de trabajo, y compáralo con tu tarjeta. Esta calculadora hace las tres cosas y marca cada acelerador como apto o no. El paso que se suele olvidar es la caché KV: con contexto largo puede pesar más que los pesos, así que un modelo que sobre el papel cabe sin problema termina sin cargar.
Normalmente no ocho mil millones exactos. Los nombres están redondeados y la cifra exacta depende del tamaño del vocabulario, de si la cabeza de salida está atada al embedding y del reparto de cabezas. Derivarla de la arquitectura da el número real, que en los modelos de esta lista queda a pocos puntos porcentuales del nombre.
Un modelo de mezcla de expertos contiene muchos bloques feed-forward expertos pero enruta cada token solo por unos pocos. Todos los expertos deben estar residentes en memoria, así que los parámetros totales deciden si el modelo carga, mientras que los activos deciden el rendimiento. Un modelo de 30B con 3B activos necesita memoria para 30B y va aproximadamente a la velocidad de uno de 3B.
En el diseño original las proyecciones de consulta, clave, valor y salida tienen el mismo ancho, lo que da cuatro matrices cuadradas por capa. La atención de consulta agrupada estrecha las de clave y valor para que varias cabezas de consulta compartan una de clave/valor. Un modelo con 32 cabezas de consulta y 8 de clave/valor tiene por tanto bastante menos peso en atención, y una caché KV cuatro veces menor, de lo que sugiere la vieja estimación.
No, y tratarla como si lo hiciera es un error frecuente. Los embeddings de posición rotatorios no añaden ningún parámetro, y los modelos que sí usan tablas posicionales aprendidas las dimensionan por la longitud con la que se entrenaron, no por la que uses al ejecutarlos. El contexto afecta a la caché KV, no a los pesos.
Aproximadamente la cuarta parte de lo que necesita el mismo modelo a 16 bits, más la caché KV, que suele mantenerse a mayor precisión. Eso es lo que pone un modelo de 32B al alcance de una sola tarjeta de consumo. Los pesos se reducen; la caché no se reduce con ellos.
Porque 4 bits es un mínimo, no un formato de archivo. Los esquemas de cuantización reales guardan escalas y puntos cero por bloque junto a los pesos, y a menudo dejan algunos tensores con más precisión, así que el archivo queda por encima de cuatro bits por peso. Esta calculadora informa del mínimo teórico y lo advierte, en lugar de inventar un multiplicador que ningún proveedor publica.
Varias veces más. AdamW mantiene una copia de 32 bits de los pesos más el momento y la varianza, lo que son doce bytes por parámetro, y los gradientes añaden más. Las activaciones escalan además con la longitud de secuencia y el tamaño de lote. En un modelo de 8B, el estado del optimizador por sí solo pesa más que los pesos a 16 bits.
Del archivo de configuración de cada modelo, con la URL y la fecha de lectura registradas junto al dato. Nada se toma de un resumen ni de una tabla comparativa. Después la derivación se contrasta con el tamaño que figura en el nombre del modelo, que es precisamente cómo se descubrió que la versión anterior de esta página se quedaba corta.
Las diferencias pequeñas vienen de los términos que esta calculadora aproxima, sobre todo los pesos de normalización y los sesgos, que están muy por debajo del uno por ciento en cualquier modelo moderno. Las diferencias grandes suelen indicar que hay una característica arquitectónica sin modelar, como la atención latente comprimida de algunos modelos de frontera. Esas se señalan en lugar de estimarse.