Por qué descargar un modelo de 17 GB no significa que se necesiten 17 GB de memoria para ejecutarlo

Se anuncia un nuevo modelo de código abierto; el titular afirma que compite con sistemas mucho más grandes, y hay una cifra que llama la atención de todos: su tamaño de descarga es solo de 17 GB. Eso parece poner una asistencia seria para la programación al alcance de una estación de trabajo común, hasta que se carga un código real o una conversación larga y el proceso se queda sin memoria. El tamaño del archivo, la cantidad de parámetros activos y la memoria que realmente necesita un modelo en ejecución son tres cantidades diferentes. Este artículo explica cómo se relacionan, para que pueda estimar cuánto costará realmente ejecutar un modelo antes de planificar el hardware basándose únicamente en un titular.

La cantidad de parámetros es una señal menos fiable que antes

Al comparar modelos de lenguaje, la mayoría de las personas primero observan el número de parámetros. Es un instinto razonable: los parámetros son las ponderaciones aprendidas por la red, y parece lógico que cuantos más haya, mayor, más inteligente y más costoso será el modelo.

Las arquitecturas modernas han suavizado mucho esa relación. Un punto de inflexión importante fue la investigación de DeepMind sobre Chinchilla, centrada en el entrenamiento óptimo desde el punto de vista computacional. Demostró que un modelo con 70 mil millones de parámetros, entrenado con mucha más información, podía superar a modelos mucho más grandes, incluido Gopher con 280 mil millones de parámetros, siempre que ambos utilizaran una cantidad comparable de recursos computacionales para entrenarse.

La conclusión no fue que los modelos pequeños ganan. Fue más sutil y útil: la forma en que un modelo utiliza sus parámetros puede ser tan importante como su cantidad. Esa idea se convirtió en el núcleo de otra arquitectura que hoy domina las discusiones sobre modelos eficientes: la Mixture of Experts.

Parámetros activos versus parámetros totales

Un modelo de Mezcla de Expertos (MoE) contiene muchas subredes especializadas. En lugar de hacer pasar cada token por toda la red, un pequeño router elige a unos pocos expertos para cada token, y solo esos expertos realizan el trabajo.

Una analogía útil es una empresa con 100 empleados. Cada solicitud de un cliente podría requerir solo a cinco de ellos, por lo que se podría decir que cinco personas están “activas” para esa solicitud. La empresa aún debe emplear, asignar un puesto y pagar a los 100, ya que la siguiente solicitud podría necesitar a otros cinco diferentes.

Los modelos MoE se comportan de la misma manera:

• El número de parámetros activos indica aproximadamente cuántos parámetros participan en la generación de un token.
• El número total de parámetros refleja cuánto del modelo existe en conjunto.

La diferencia entre los dos puede ser enorme. DeepSeek-V3 es el ejemplo bien conocido: cuenta con unos 671 mil millones de parámetros en total, de los cuales aproximadamente 37 mil millones se activan por token. Por lo tanto, generar un token es mucho más económico que hacerlo con un modelo denso de 671 mil millones de parámetros. No significa que DeepSeek-V3 se comporte como un modelo de 37 mil millones de parámetros en todos los aspectos prácticos, y ahí es precisamente donde muchos errores ocurren en las comparaciones.

El costo de procesamiento y el costo de memoria son presupuestos separados

Los parámetros activos son una buena guía para el procesamiento: indican cuántas operaciones de multiplicación-acumulación requiere cada token y, por lo tanto, qué tan rápido se pueden generar los tokens en un hardware determinado.

La memoria es un presupuesto separado. El motor de inferencia no puede eliminar a los expertos que no fueron seleccionados para el token actual, ya que el enrutador puede elegir a cualquiera de ellos para el siguiente. Todos deben permanecer accesibles, normalmente en la GPU o en memoria unificada, ya que obtener los pesos del disco por cada token sería demasiado lento.

Por lo tanto, un modelo puede ser económico de calcular y aún así requerir mucha memoria. Una regla concisa lo resume así:

Los parámetros activos indican cuánto cálculo necesita cada token. El tamaño total del modelo indica cuanta memoria debe estar disponible.

Estas dos mediciones están relacionadas, pero responden a preguntas diferentes y no pueden intercambiarse.

Qué contiene realmente una descarga de 17 GB

Por esta razón, la descripción “un modelo de IA de 17 GB” es engañosa. Un archivo de pesos cuantizados puede realmente tener ese tamaño. La cuantización almacena cada peso con menos bits, por ejemplo 4 bits en lugar de 16, lo que reduce el tamaño del archivo varias veces a un costo modesto en calidad.

Pero el archivo en su SSD es solo un componente de lo que necesita el proceso en ejecución. Además de él, se necesita memoria para:

• los pesos una vez que se cargan en la memoria,
• el propio overhead del tiempo de ejecución de las inferencias,
• búferes temporales utilizados durante el cálculo,
• el contexto, almacenado en la caché KV,
• y todo lo que ya utilizan el sistema operativo y otros programas.

Por lo tanto, un archivo de 17 GB no significa que una máquina con 17 GB libres pueda ejecutar el modelo cómodamente, ni siquiera una vez que crece el contexto.

Las mediciones realizadas por la comunidad sobre Qwen3.8-27B ilustran este punto con claridad. Una versión cuantizada de aproximadamente 17 GB puede necesitar mucha más memoria una vez que se carga un contexto largo, y con la longitud de contexto nativa del modelo de 262,144 tokens, solo la caché KV se vuelve muy grande. Para entender por qué, es necesario analizar cómo el modelo recuerda una conversación.

La propia conversación ocupa memoria

Un modelo transformer no lee tu prompt una sola vez y lo descarta. Al generar cada nuevo token, consulta todos los tokens anteriores del contexto. Volver a calcular la representación interna de todo el contexto para cada nuevo token sería excesivamente lento, por lo que los motores de inferencia almacenan en su lugar los resultados intermedios.

Esa memoria es el KV cache, abreviatura de caché clave/valor. Para cada token del contexto, cada capa de atención almacena un vector de clave y un vector de valor. Por lo tanto, el caché crece de forma aproximadamente lineal con la longitud del contexto: un modelo que funciona sin problemas con una conversación corta puede volverse mucho más pesado si se le proporcionan decenas o cientos de miles de tokens, como por ejemplo todo un repositorio.

Según la ficha del modelo Qwen3.8-27B en Hugging Face, el modelo soporta un contexto nativo de 262,144 tokens. Utiliza un diseño híbrido en el que solo algunas capas emplean atención convencional, lo cual es lo que hace posible utilizar una ventana tan larga en la práctica.

Un análisis comunitario de la arquitectura estima unos 64 KB de datos en caché KV de tipo FP16 por token para las capas que aún conservan una caché tradicional. Si se multiplica esa cantidad por 262,144 tokens, se obtienen aproximadamente 16.8 GB de caché KV, sin contar nada más. Un presupuesto aproximado de memoria para una sesión con contexto completo sería el siguiente:

• Pesos del modelo: unos 17 GB
• Caché KV con contexto completo: unos 17 GB
• Costos adicionales durante el funcionamiento y buffers: cantidad extra

El modelo nunca se reduce a un programa de 17 GB. Descargaste 17 GB de pesos cuantizados, pero la carga real puede ser aproximadamente el doble o incluso más. También puedes entender por qué la longitud del contexto es el factor clave cuando hay poca memoria: al reducirla a la mitad, se reduce aproximadamente a la mitad el caché, y muchos entornos de ejecución pueden cuantizar el propio caché KV para reducirlo aún más, aunque a un costo en precisión. Estas cifras de la comunidad son estimaciones; compáralas con el uso de memoria reportado por tu propio entorno de ejecución.

Cómo la atención híbrida hace que los contextos largos sean manejables

Aquí es donde la arquitectura se vuelve interesante. En un transformador convencional, cada capa de atención mantiene sus propias entradas KV, por lo que el caché crece tanto con la cantidad de capas como con la cantidad de tokens.

Según los análisis publicados sobre su diseño, Qwen3.8-27B adopta un enfoque híbrido. De sus 64 capas, solo un número relativamente pequeño utiliza atención completa, mientras que la mayoría emplea atención lineal. Las capas de atención lineal resumen el pasado en un estado de tamaño fijo en lugar de almacenar claves y valores para cada token, por lo que no aumentan el caché en crecimiento. Solo las capas de atención completa generan un costo por token, y esa es la razón por la cual el valor por token mencionado anteriormente es tan bajo.

Son trucos como este los que hacen viables las ventanas de contexto muy largas. Sin ellos, la memoria necesaria para un cuarto de millón de tokens se volvería rápidamente impráctica en cualquier hardware que no sea de centro de datos.

Por lo tanto, cada vez que un modelo anuncie una ventana de contexto enorme, haga una pregunta adicional: ¿qué hace la arquitectura para que ese contexto sea manejable? La longitud del contexto por sí sola no le da la respuesta.

Una victoria en pruebas de rendimiento no equivale a una victoria general

Los titulares tienen otra costumbre: un modelo “superó a Claude” o “superó a GPT” en una prueba de rendimiento, y la conclusión que se saca es que es mejor en general. Las pruebas de rendimiento miden tareas específicas bajo condiciones concretas, y una sola puntuación dice muy poco sobre cualquier otra cosa.

Qwen3.8-27B ilustra esto perfectamente. Sus resultados publicados muestran números sólidos en tareas de programación:

• Terminal-Bench 2.1, que evalúa el trabajo de agente en una terminal: 73.0
• SWE-bench Pro, que prueba la corrección de problemas reales en repositorios: 61.7
• GPQA Diamond, un conjunto de preguntas científicas de nivel universitario: 89.2

Al comparar los resultados del Opus 4.6 Max con los de otros modelos en la misma tabla, las opiniones son mixtas. En Terminal-Bench 2.1, Qwen obtiene un puntaje de 78.2, por debajo del de Opus 4.6 Max. En SWE-bench Pro, su puntaje de 61.7 es superior al de Opus, que registra 53.4. En GPQA Diamond, su valor de 89.2 es inferior al de 91.3.

¿Cuál modelo es mejor? Depende de la tarea. El trabajo con terminales agentes, la corrección de errores a nivel de repositorios y las preguntas científicas de nivel universitario requieren habilidades diferentes, al igual que las tareas a largo plazo para agentes. Cada prueba de rendimiento refleja una capacidad específica, no un ranking universal de inteligencia.

También es importante la metodología. El conjunto de herramientas de evaluación, la estrategia de estímulo, las herramientas disponibles, el método de calificación y la configuración del modelo pueden influir en las puntuaciones, y los proveedores no siempre ejecutan a los competidores en condiciones idénticas. Una afirmación como “El Modelo X supera al Modelo Y” omite la parte importante. La versión precisa suena más o menos así:

Bajo estas condiciones, el Modelo X obtuvo una puntuación más alta que el Modelo Y en esta evaluación.

Es menos emocionante, pero mucho más útil.

El esfuerzo de razonamiento es un multiplicador oculto de costos

Incluso una vez que se comprenden los parámetros y la memoria, otra variable puede cambiar silenciosamente el costo de ejecución de un modelo: cuánto razona antes de responder.

Los modelos orientados al razonamiento exponen cada vez más una configuración para ello. Qwen3.8 admite un parámetro reasoning_effort con niveles como low, medium y xhigh, siendo xhigh el valor predeterminado; su documentación describe explícitamente que estos niveles controlan la profundidad y el costo del razonamiento.

El equilibrio es sencillo: más razonamiento puede ser útil en problemas difíciles, pero cada paso de razonamiento genera tokens, lo que implica más cálculos, mayor latencia y, en cadenas de razonamiento largas, también más uso del caché KV. Por lo tanto, dos personas que ejecuten el mismo modelo pueden tener costos muy diferentes únicamente debido a este parámetro.

Esto es especialmente relevante para los agentes de programación, que manejan tareas de dificultad muy diferente. Compare una solicitud para renombrar una variable con una solicitud para explorar un repositorio desconocido, encontrar un defecto arquitectónico, modificar seis archivos, ejecutar las pruebas, diagnosticar los fallos y crear un parche. La primera no necesita ni de cerca el mismo nivel de razonamiento que la segunda. Ejecutar un razonamiento máximo en cada solicitud es como involucrar a un ingeniero senior en una reunión sobre la etiqueta de un botón: funciona, pero es un uso ineficiente del recurso.

Existe una advertencia, y la propia documentación de Qwen la menciona. Disminuir el esfuerzo puede acelerar cada turno individual, pero también provocar más intentos fallidos en tareas de agente con múltiples pasos, lo que puede anular los ahorros obtenidos. El enfoque práctico es medir el costo total de la tarea, no la latencia por turno, y dirigir las tareas fáciles y difíciles a configuraciones diferentes si la herramienta lo permite. No existe una única configuración adecuada para todo.

Por qué la computación activa eficiente sigue siendo muy importante

A pesar de todas estas advertencias, sería fácil concluir que la historia de los modelos locales pequeños y capaces no es más que publicidad exagerada. Pero no lo es. El progreso es real: ahora los modelos con un presupuesto de computación activa modesto pueden manejar trabajos serios de ingeniería de software que hace solo unos años habría sido muy difícil ejecutar localmente.

La única corrección necesaria es que el cálculo eficiente no implica automáticamente un bajo consumo de memoria.

Esa distinción es aún más importante a escala de centro de datos. Un proveedor que atiende a miles de usuarios carga los pesos una sola vez y los comparte en todas las solicitudes. En contraste, la caché KV pertenece a cada conversación individual. Al reducir la memoria que necesita cada conversación activa, se pueden admitir más usuarios simultáneos en el mismo hardware, lo que disminuye directamente el costo de ofrecer el modelo.

Visto de esta manera, los detalles arquitectónicos que parecen trucos de investigación poco conocidos, como la atención híbrida o la compresión de la caché KV, se convierten en factores económicos importantes. Un modelo no necesita ser pequeño en todas partes; basta con que sea eficiente donde la infraestructura está bajo mayor presión.

Cuando un modelo de 17 GB realmente representa una gran oferta

También existe un aspecto muy positivo. Muchas tareas reales utilizan un contexto breve:

• un único archivo,
• un problema de programación concreto,
• un proyecto pequeño,
• una conversación ordinaria.

En esos casos, un modelo bien cuantizado de esta categoría puede ser realmente impresionante. No se necesita un servidor en la nube grande para probarlo. Se puede ejecutar un modelo eficaz en hardware de consumo, mantener los datos en la propia máquina y evitar costos por API por cada token en cada experimento. Para un ejemplo práctico de ese flujo de trabajo, consulte cómo crear un clon local de Angry Birds con Qwen3.8-27B y Pi.

Eso amplía el grupo de personas que pueden experimentar con inteligencia artificial avanzada, lo cual es probablemente más importante que el hecho de que una puntuación en pruebas sea tres puntos superior a otra.

Cuatro preguntas que hacer en lugar de “¿cuántos parámetros?”

La próxima vez que un titular destaque un bajo número de parámetros o una pequeña cantidad de descarga, analice estas cuatro preguntas.

¿Cuántos parámetros están activos?

Eso le indica el cálculo por token y, por lo tanto, aproximadamente qué tan rápido puede generar el modelo en su hardware.

¿Cuántos parámetros existen en total?

Eso le da información sobre el tamaño general del modelo, y es el factor principal que determina cuanta memoria necesitan sus pesos.

¿Qué tan grande es la caché KV?

Esto depende de la arquitectura y de la longitud de contexto que realmente planea utilizar; se convierte en el factor dominante con contextos largos.

¿Cuánto razona el modelo antes de responder?

Eso afecta la latencia, el consumo de tokens y el costo, y se puede ajustar según cada tarea.

Juntos, estas cuatro respuestas le brindan mucha más información de la que nunca podrá darle el tamaño de una descarga.

Los modelos se han vuelto más eficientes, no necesariamente más pequeños

La tendencia general es una mejora real en la eficiencia en todo el conjunto de componentes: mejores estrategias de entrenamiento y escalado de datos, mejor enrutamiento por expertos, mejor cuantización, mejores arquitecturas de atención, y un razonamiento que puede configurarse en el momento de la inferencia.

Nada de esto hace que el cálculo eficiente sea lo mismo que un pequeño consumo de memoria:

• Un modelo MoE puede activar solo una fracción de sus parámetros por token, aunque siga conteniendo una red muy grande.
• Un modelo cuantizado puede ocupar una cantidad modesta de espacio en disco, pero necesitar mucho más memoria en el momento de la inferencia.
• Una ventana de contexto larga puede hacer que la propia conversación consuma gigabytes.
• Una configuración de razonamiento más avanzada puede hacer que la misma solicitud sea mucho más costosa desde el punto de vista computacional.

Por lo tanto, la mejor pregunta no es cuántos parámetros tiene un modelo. Es más bien esta:

¿Cuánta memoria y capacidad de cálculo necesita esta tarea específica, desde cargar el modelo hasta generar el token final?

Puntos clave

• El tamaño del modelo para descargar abarca solo sus pesos; la caché KV, la sobrecarga en tiempo de ejecución y los buffers se suman encima y pueden duplicar la necesidad real en contextos largos.
• Los parámetros activos describen el cálculo por token, mientras que los parámetros totales determinan cuanta memoria debe permanecer disponible.
• El tamaño de la caché KV aumenta con la longitud del contexto y depende en gran medida de la arquitectura, por lo que los diseños híbridos de atención son importantes para ventanas largas.
• Las victorias en pruebas de rendimiento son específicas para cada tarea y dependen de la metodología; hay que interpretarlas como “mejores en esta evaluación”, no como “mejores en general”.

El esfuerzo de razonamiento es un verdadero factor que influye en los costos, pero hay que medir el costo total de la tarea, ya que un menor esfuerzo puede provocar intentos repetidos que anulen los ahorros obtenidos.

Cuando un titular promete un modelo pequeño que supera a uno grande, revise las pruebas de rendimiento, la configuración, los parámetros activos y totales, la cuantización, la longitud del contexto y el presupuesto de razonamiento antes de creerlo o descartarlo.

Lecturas relacionadas

• Comprendiendo la memoria de IA: Contexto, embeddings, RAG y pesos del modelo explicados — Este artículo explica cómo los sistemas de IA realmente almacenan información, abordando ventanas de contexto, embeddings, bases de datos vectoriales, RAG y parámetros del modelo.
• Cuando la cuantización supera la perplexidad y rompe en silencio la seguridad del modelo — La cuantización de caché KV de bajo bit puede eliminar las capacidades de rechazo de un modelo mientras la perplexidad apenas cambia; aquí se explica por qué las métricas estándar no lo detectan y qué añadir a su sistema de control.
• Explicación de la profundidad recurrente: Transformadores en bucle y razonamiento oculto — Cómo razonan los transformadores de profundidad recurrente (en bucle) en su estado oculto, por qué los laboratorios los desean, lo que demuestran ocho años de artículos académicos y qué implica esto para la IA local y la supervisión.