Descargable no significa operable

A principios de agosto circulan rankings de los mejores modelos de IA de código abierto, en los que destaca un modelo que lidera la lista sin que sus pesos hayan sido publicados aún. Para los responsables de TI y los arquitectos de cloud, esto plantea una pregunta que ningún feed responde: ¿en qué criterios se basa la decisión de optar o no por una IA operada localmente?

Lo más importante en resumen

Relacionado:Soofi S: soberano no significa ganador  /  Inkling: qué puede hacer el nuevo modelo de pesos abiertos

El debate avanza antes de que llegue la disponibilidad

Alibaba presentó a principios de agosto Qwen3.8-Max: 2,4 billones de parámetros, de los cuales 95.000 millones están activos, con arquitectura Mixture-of-Experts y una ventana de contexto de hasta un millón de tokens. Junto al modelo insignia, se anunció que un segundo checkpoint, Qwen3.8-27B, estaría disponible de forma abierta. Sin embargo, en el momento del anuncio, los pesos de ambos modelos aún no se habían publicado; la empresa indicó que lo haría la semana siguiente.

Esto no impidió que los rankings ni los vídeos explicativos los trataran ya como disponibles. Expertos de la comunidad corrigieron el error, en algunos casos de manera contundente. Detrás de esto no hay un fallo puntual, sino un patrón estructural: el anuncio, las tablas de benchmarks y las valoraciones de la comunidad surgen en cuestión de horas, mientras que los pesos y, sobre todo, la experiencia operativa requieren semanas.

Quien planifique sus adquisiciones siguiendo este ritmo, terminará apostando por un modelo que aún no existe. O por uno que nunca llegue a funcionar en su propia infraestructura.

Pesos abiertos, hardware cerrado

Una frase de este debate resume perfectamente la situación y se ha convertido en un término recurrente: «Pesos abiertos, hardware cerrado». Cuando la operación requiere cientos de miles de GPUs, no estamos ante un modelo local. Se trata de un modelo en la nube con pesos descargables.

Las magnitudes lo confirman. A finales de julio, Moonshot liberó los pesos de Kimi K3, con 2,8 billones de parámetros y un contexto de un millón de tokens. En la comunidad circuló, medio en broma, una lista de preparación: primero había que conseguir un presupuesto de hardware de seis cifras altas. La objeción más sensata añadía: la mayoría de los modelos abiertos no pueden ejecutarse localmente simplemente por falta de recursos.

Existen excepciones, y son impresionantes. Con una cuantización agresiva de 1 bit, Kimi K3 se reduce de aproximadamente 1,56 terabytes a unos 594 gigabytes, una disminución de más del 60 %, manteniendo alrededor del 79 % de la precisión original. Esto puede ejecutarse en una estación de trabajo bien equipada. Sigue siendo un caso especial: la pérdida de precisión es real. El límite de memoria solo se desplaza, no desaparece.

Un cálculo aproximado ayuda a entender las dimensiones. 2,4 billones de parámetros a 4 bits equivalen a unos 1,2 terabytes solo para los pesos. Una NVIDIA H200 tiene 141 gigabytes. Eso significa, en teoría, nueve GPUs antes de que se ocupe ni un solo byte del caché KV. Con un contexto de un millón de tokens, este caché se vuelve considerable. Aquí, «local» significa centro de datos propio o cluster alquilado, no el ordenador de sobremesa del despacho de al lado.

Los parámetros activos determinan la memoria

El punto técnico donde fracasan las adquisiciones: en el caso de los modelos Mixture-of-Experts, no es el número de parámetros activos lo que determina la memoria necesaria. DeepSeek V4 Flash tiene 13.000 millones de parámetros activos, pero carga todos los 284.000 millones en la memoria. Quien lea «13B activos» y encargue una tarjeta de 16 gigabytes, se equivoca por un orden de magnitud.

Este patrón se repite en la generación actual de modelos. Qwen3.8-Max: 2,4 billones en total, 95.000 millones activos. GLM-5.2 de Zhipu: 744.000 millones en total, unos 40.000 millones activos, disponible bajo licencia MIT en Hugging Face. DeepSeek V4 Pro: 1,6 billones en total, 49.000 millones activos, también con licencia MIT. Los parámetros activos explican los costes de cálculo por token. La necesidad de memoria depende del tamaño total.

Las mediciones prácticas de la comunidad muestran el límite realista. Son valores individuales, no especificaciones del fabricante, pero coinciden entre sí: DeepSeek V4 Flash, con software de inferencia optimizado, puede alcanzar desde unos 3 hasta casi 26 tokens por segundo en una sola tarjeta de consumo de 24 gigabytes. Sebastian Raschka indica que, para modelos MoE de 30.000 millones, se obtienen unos 40 tokens por segundo en un ordenador de trabajo bien equipado, y señala que un modelo de 118.000 millones con 8.000 millones de parámetros activos se mantiene por debajo de los 80 gigabytes de RAM.

Como regla práctica con cuantización de 4 bits: 7.000 millones de parámetros a partir de 8 gigabytes, 14.000 millones a partir de 12, la clase entre 24.000 y 32.000 millones necesita entre 16 y 24, y un modelo de 70.000 millones requiere a partir de 40 gigabytes. Estas son las dimensiones de trabajo para el día a día, no los modelos que ocupan los titulares.

Lo que ayer era tecnología punta hoy se ejecuta en una sola tarjeta gráfica

La física de la memoria es solo una parte de la historia. La otra es el ritmo al que se desplaza el límite. Es, en realidad, la noticia más relevante para la planificación de infraestructuras.

Un ejemplo con cifras contundentes: Alibaba lanzó en abril de 2026 el modelo Qwen3.6-27B, un modelo denso con 27.000 millones de parámetros que funciona en una sola RTX 4090 o en un Mac con 24 gigabytes de memoria. En el benchmark SWE-bench Verified, uno de los estándares más exigentes para programación con agentes, alcanza un 77,2 %, superando a su propio modelo estrella anterior, con 397.000 millones de parámetros, que logró un 76,2 %. Quince veces más pequeño, ligeramente mejor y lanzado tres meses y medio después. Lo que en primavera requería un centro de datos, desde el verano cabe en un ordenador de sobremesa.

La presión llega ahora de ambos frentes. Y esto es nuevo. Los proveedores de modelos abiertos han reaccionado en cuestión de semanas: Moonshot ha liberado Kimi K3, el mayor modelo abierto hasta la fecha; DeepSeek y Zhipu han puesto sus modelos estrella bajo licencia MIT. Alibaba, por su parte, abre por primera vez su clase superior de modelos con Qwen3.8-Max. Mientras, en el otro extremo, los proveedores de modelos cerrados reducen precios y publican posturas fundamentales sobre pesos abiertos, algo que hace un año no consideraban necesario. Para un operador, esta es una situación poco común: ambos bandos avanzan en la misma dirección.

Las previsiones apuntan en el mismo sentido. Gartner estima que en 2030 la inferencia en un modelo con un billón de parámetros costará más de un 90 % menos que en 2025, impulsado por semiconductores e infraestructuras más eficientes, un mejor diseño de modelos, una mayor utilización de chips, hardware especializado para inferencia y el uso de dispositivos finales para casos de uso específicos. Comparado con modelos de tamaño similar de 2022, los analistas prevén hasta cien veces mayor eficiencia de costes. En cuanto a la proporción de procesamiento local, la expectativa es igual de clara: más de dos tercios de las empresas deberían ejecutar IA en el borde de la red para 2029, frente a alrededor del 10 % en 2025.

Hay, no obstante, un matiz. Gartner lo menciona explícitamente: el ahorro no se traslada directamente al usuario final. Las aplicaciones con agentes consumen significativamente más tokens por tarea que la generación clásica de texto, lo que puede consumir gran parte de la ventaja en costes. Que sea más barato por token no significa automáticamente que lo sea por proceso.

Para la planificación, sin embargo, la conclusión es clara. La siguiente tabla describe un estado, no una situación permanente: sus filas se desplazan hacia abajo, en meses en lugar de años. Quien hoy defina una arquitectura debería planificar la inferencia local como una parte creciente del ecosistema de procesos. Considerarla una mera opción para casos especiales es quedarse corto.

Dónde se ejecuta cada cosa

Lo que no aparece en ninguna especificación puede hacer que los proyectos fracasen. La potencia de conexión es el bloqueo silencioso más frecuente: un rack que dispara el interruptor de planta no es un concepto operativo. El calor y el ruido disipados son un obstáculo arquitectónico en una oficina sin sala de servidores. Y las actualizaciones de los modelos desplazan los requisitos hacia arriba, como en un caso documentado en el que se necesitaban 10 GB adicionales de memoria de vídeo respecto a la versión anterior.

Los pesos abiertos no son código abierto

Pesos abiertos significan: los pesos son descargables. Lo que está permitido con ellos viene especificado en la licencia. Los datos de entrenamiento, el código de entrenamiento y la reproducibilidad no están incluidos.

Código abierto según la definición de la OSI (OSAID 1.0) exige, además, información sobre los datos: origen, volumen, métodos de obtención y selección, etiquetado, procesamiento y filtrado. Según este criterio, prácticamente ningún modelo puntero actual es código abierto.

El punto diferenciador: GLM-5.2 y DeepSeek V4 Pro están bajo la licencia MIT, una licencia OSI auténtica. Aun así, según el OSAID no son IA de código abierto porque faltan los datos de entrenamiento. Una licencia permisiva sobre los pesos y una IA de código abierto son dos cosas distintas.

El Reglamento de IA de la UE actúa de manera diferenciada. El considerando 104 exige, para la excepción, parámetros, pesos, arquitectura e información de uso públicamente disponibles. Sin embargo, la excepción solo cubre obligaciones relacionadas con la transparencia. La síntesis de los contenidos de entrenamiento y el cumplimiento de los derechos de autor siguen vigentes.

En una frase para decisores: los pesos abiertos no eliminan el *lock-in*. Lo desplazan del proveedor del modelo a la propia empresa, incluyendo parches, cuantización, monitorización y personal.

Lo que realmente determina la decisión

No el número de empleados. Un asesor fiscal con doce personas maneja datos de clientes que no pueden salir de su sistema. Un grupo con un estándar de nube *Zero Trust* sigue siendo híbrido, incluso con diez mil empleados. El umbral está en otro lugar:

1. Clase de datos. Los datos públicos e inocuos pueden ir a la API. Los datos personales, críticos para el negocio o confidenciales exigen llevar la pila de modelos internamente.
2. Carga y planificación. El uso esporádico se calcula de otra manera que la carga continua. El punto de equilibrio para alojar en local frente a los precios de las APIs de modelos punteros está en unos 2 a 5 millones de tokens diarios durante doce meses. Frente a proveedores económicos de modelos abiertos, el umbral se desplaza a 50 millones de tokens diarios o más.
3. Clase de modelo frente a la tarea. ¿Basta con un modelo de 27.000 millones con RAG sobre documentos internos? ¿O la tarea realmente requiere calidad puntera? Muchas aplicaciones especializadas terminan en la fase de operatividad, no en el centro de datos.
4. Madurez operativa. Una pila de inferencia propia requiere entre 10 y 20 horas mensuales de mantenimiento. Sin un equipo que la soporte 24/7, en local solo es viable un piloto con fecha de caducidad.
5. Latencia y necesidad de offline. Fabricación, fuerza de ventas y redes aisladas exigen localización independientemente del precio por token.
6. Potencia de conexión, refrigeración y espacio. Los costes brutos de las GPU solo representan entre el 30 y el 40 % de la inversión real. Como regla general, el factor es de 2,5 a 3 sobre el precio del hardware. La ocupación real en producción ronda el 40-65 %, no el 80-90 % que muestran las presentaciones.
7. Regulación y condiciones contractuales. El procesamiento por encargo, el Reglamento de IA, las normas sectoriales y los contratos con clientes imponen límites que ningún benchmark sustituye.

El modelo híbrido es, en este caso, la norma: tareas sensibles en local o en la nube privada, y las generales a través de API, enrutadas según la clase de datos y no según la situación puntual.

Lo que debe llevarse de esto

Las posturas en el debate están claramente definidas. Por un lado, se argumenta con razón que los modelos abiertos garantizan la verificabilidad y permiten operar en hardware propio sin ceder datos ni propiedad intelectual a proveedores cerrados. Desde el ámbito de los capitalistas de riesgo se señala que los modelos punteros están sobredimensionados para la mayoría de los casos de uso. La otra parte sostiene que muchos de estos modelos no pueden ejecutarse localmente por falta de recursos. Ambas posturas tienen razón, pero se refieren a clases de modelos distintas.

Para la propia infraestructura, esto implica tres pasos:

En primer lugar: inventariar los casos de uso según la clase de datos y la carga. ¿Qué consultas pueden salir de la empresa y cuáles requieren capacidad offline o latencia fija? Sin esta lista, cualquier discusión sobre hardware será pura especulación.

En segundo lugar: vincular la clase de modelo a la tarea, no al titular. Para búsqueda interna, resúmenes y preguntas y respuestas sobre documentos, con RAG basta con una clase entre 24 y 32 mil millones de parámetros en una sola GPU. La clase de billones sigue siendo, en la práctica, terreno de las APIs, a menos que alguien presupuesté y opere un clúster con ocho o más GPUs por nodo.

En tercer lugar: calcular con factores realistas. Hardware multiplicado por 2,5 a 3, ocupación entre el 40 % y el 65 %, entre 10 y 20 horas de funcionamiento al mes, punto de equilibrio frente a la clase de precios realmente utilizada. Quien solo compare el precio de lista de la GPU con el precio por token está haciendo una estimación que no se sostendrá en la operación.

Y, en cuarto lugar, el punto con mayor impacto a largo plazo: diseñar la arquitectura pensando en la movilidad. Si un modelo que cabe en una sola tarjeta gráfica alcanza en un trimestre el rendimiento de su predecesor quince veces mayor, cualquier decisión a favor exclusiva del uso de APIs será una apuesta en contra de la propia curva de costes. Eso no significa traer hoy todo hacia dentro, sino construir la abstracción de manera que el cambio sea posible: puntos finales de inferencia intercambiables en lugar de SDKs de proveedores fijos, casos de evaluación propios en lugar de benchmarks ajenos, y una clasificación de datos que ya sepa qué procesos migrarían primero hacia el interior.

La comunidad seguirá evaluando modelos antes de que estén disponibles los pesos. Eso es ruido. La señal subyacente es la velocidad: la distancia entre la clase puntera y la operable localmente se reduce en meses. Descargable sigue siendo una cuestión de licencia, operable una de infraestructura. Solo que la respuesta a la segunda pregunta se está desplazando más rápido de lo que duran los ciclos de adquisición de la mayoría.

Preguntas frecuentes

¿Basta con un modelo de 27 mil millones de parámetros para tareas empresariales?

Para búsqueda interna, resúmenes, preguntas y respuestas sobre documentos y asistencia de codificación con RAG sobre documentos propios, esta clase suele ser suficiente. Se ejecuta en una sola GPU con 16 a 32 gigabytes. Lo decisivo sigue siendo medir con casos propios: lo que lidera en un ranking no tiene por qué ser lo mejor en el contexto profesional propio.

¿Por qué los planes de hardware suelen fallar con los modelos Mixture-of-Experts?

La cifra de parámetros activos describe los costes de cálculo por token, pero la necesidad de memoria sigue la dimensión total. Un modelo con 13 mil millones de parámetros activos puede cargar 284 mil millones en la RAM. Quien tome la primera cifra para la adquisición, estará equivocado en un orden de magnitud.

¿A partir de qué volumen compensa el alojamiento propio frente a una API?

Frente a los precios de los modelos punteros, el punto de equilibrio se sitúa en unos 2 a 5 millones de tokens diarios durante doce meses. Frente a proveedores económicos de modelos abiertos, este umbral se desplaza a 50 millones o más, ya que estos operan el mismo hardware con mejor ocupación y márgenes más ajustados. Ambos valores solo son válidos con una ocupación realista.

¿Qué significa el ritmo de desarrollo para las adquisiciones en curso?

La clase de modelos operable en hardware propio alcanza a la clase puntera en meses. Una decisión a favor exclusiva del uso de APIs con compromisos plurianuales y interfaces fijas de proveedores reduce así su posición negociadora. Es sensato una arquitectura con puntos finales de inferencia intercambiables que mantenga abierta la posibilidad de cambio.

Más del grupo MBF Media

Fuente de la imagen: Generada por IA (agosto 2026)