Cada lanzamiento importante de un modelo open weight reactiva la misma predicción: pronto el portátil y el teléfono desplazarán a la nube, y los centros de datos de IA dejarán de ser tan importantes como ahora.

Espero un desenlace menos limpio. La IA local crecerá, pero la pantalla en la que aparece la IA y el lugar donde se realiza el cálculo son dos decisiones diferentes. Un modelo pequeño en el dispositivo puede iniciar la conversación, ocultar información sensible o resolver una orden breve; el razonamiento largo, los contextos grandes y los trabajos con muchas herramientas pueden pasar al centro de datos. El uso local y la inferencia centralizada pueden crecer a la vez.

No es un alegato contra los modelos locales ni una defensa de que la nube siempre sea más barata. La base son documentos oficiales e investigación primaria disponibles el 25 de agosto de 2026. La pregunta es en qué condiciones el centro de datos conserva una ventaja estructural y dónde la pierde. No hay mediciones propias de velocidad ni una predicción sobre cuotas de mercado dentro de cinco años.

Los open weights son un avance real, pero «local» no es una sola categoría

Open weights significa que los pesos entrenados pueden descargarse y ejecutarse en la infraestructura que el operador elija. No implica necesariamente que el código fuente y los datos de entrenamiento estén completamente abiertos. Tampoco dice por sí solo cuánto costará servir el modelo.

El anuncio de gpt-oss de OpenAI permite ver la diferencia. La empresa indica que gpt-oss-20b está diseñado para funcionar con 16GB de memoria, mientras que gpt-oss-120b cabe en 80GB. Los dos son modelos open weight. El primero puede dirigirse a un dispositivo personal de gama alta o una máquina edge; el segundo necesita una GPU de 80GB o un entorno con capacidad de memoria equivalente.

Diagrama que compara la clase de despliegue de gpt-oss-20b con 16GB y gpt-oss-120b con 80GB

Cifras: OpenAI, Introducing gpt-oss. Consultado el 25-08-2026. Que un modelo quepa en memoria no demuestra su velocidad ni su calidad.

Por eso «local frente a nube» es un punto de partida demasiado amplio. Un PC de escritorio, un clúster on-premise en la sala de servidores de una empresa, una GPU dedicada alquilada a un proveedor y la API del fabricante del modelo son cuatro opciones operativas distintas. Un servidor de ocho GPU controlado por una empresa puede considerarse local por propiedad, pero su electricidad, refrigeración y operación ya se parecen a un centro de datos pequeño. A la inversa, un modelo open weight también puede ofrecerse desde la nube de un tercero.

La capacidad tampoco tiene una meta fija. Un modelo pequeño puede alcanzar a otro grande en un benchmark concreto. Eso no demuestra que complete al mismo coste el trabajo de agente más largo que aparecerá mañana. Cuando crecen el contexto, el uso de herramientas, la recuperación de errores, las entradas multimodales y la duración de una ejecución útil, también crecen las expectativas. La pregunta práctica no es solo cuánto ha mejorado el modelo local, sino qué modelo termina el trabajo con menos reintentos.

Una primera respuesta convincente puede convertirse en la opción cara si alguien tiene que reparar varias veces el plan, reiniciar herramientas o fragmentar una tarea grande en muchos prompts. Cuando la unidad de valor es un trabajo terminado y no un token generado, la calidad del modelo y el coste de despliegue dejan de ser variables separadas.

La mayor ventaja del centro de datos es reunir solicitudes

Comprar GPU costosas es solo una parte de la ventaja estructural. También importa disponer de una cola grande y continua alimentada por muchos usuarios independientes.

La documentación de NVIDIA Triton define el batching dinámico: el servidor reúne solicitudes individuales de inferencia y las ejecuta como grupo. Formar un batch suele aumentar el rendimiento, aunque esperar a que se complete un grupo mayor puede elevar la latencia. El operador ajusta el tamaño y el tiempo de espera al presupuesto de latencia del servicio.

Diagrama que contrasta la carga local irregular de una persona con una carga de muchos usuarios que ocupa mejor el acelerador mediante batching

Base conceptual: NVIDIA Triton Dynamic Batcher. El beneficio varía con el modelo, la longitud de entrada, la concurrencia y el objetivo de latencia.

Los LLM interactivos producen tokens de salida de forma secuencial, de modo que no terminan todo el cálculo en una sola pasada. Aun así, un sistema de inferencia puede intercalar en la misma GPU los pasos de generación de usuarios diferentes y reducir los huecos. El centro de datos tiene una buena posición para hacerlo porque recibe solicitudes de clientes, aplicaciones, zonas horarias y franjas del día distintas.

Una instalación local también puede aplicar batching. Un desarrollador que ejecute varios agentes a la vez, o una empresa que comparta un servidor interno entre equipos, puede crear concurrencia útil. La diferencia no es si la técnica existe, sino la probabilidad de que siempre haya otra solicitud compatible esperando. La amortización continúa mientras el único propietario duerme. Un servicio grande llena ese intervalo con demanda de otra procedencia.

Es multiplexación estadística, no cálculo gratuito. La capacidad fija se reparte entre una demanda más amplia y menos correlacionada. Si una GPU local permanece ocupada con trabajo valioso, la ventaja se estrecha. Si se compra hardware caro para picos ocasionales, se amplía.

Reducir el argumento a «el centro de datos es 30 veces más eficiente» lo haría menos sólido. El estudio de PagedAttention registró entre dos y cuatro veces más rendimiento que sistemas anteriores, con una latencia parecida, en las cargas evaluadas por sus autores. Es una evidencia importante sobre la eficiencia de serving, no un multiplicador universal para cualquier modelo y GPU. La dirección es defendible; la proporción concreta debe medirse en el entorno de destino.

El coste depende de la utilización y de una calidad equivalente, no solo del precio de la GPU

Calcular el coste local únicamente con la factura eléctrica deja fuera buena parte del problema. Calcular una API solo con la suscripción mensual hace lo mismo. Como mínimo, ambos lados necesitan el mismo perímetro contable:

TCO local mensual = (precio del equipo - valor residual) / meses de uso
                    + potencia media × horas × tarifa eléctrica
                    + refrigeración, averías y operación

coste API mensual = tokens de entrada × precio de entrada
                    + tokens de salida × precio de salida
                    + herramientas, almacenamiento y red

Diagrama que combina una fórmula de coste total local con las especificaciones oficiales de memoria y ancho de banda de RTX 4090 y B200

Datos de hardware: documento de arquitectura NVIDIA Ada y especificaciones NVIDIA HGX AI Factory. Son generaciones y clases de producto diferentes, no un benchmark directo de tokens por segundo.

Las especificaciones publicadas por NVIDIA dan a la RTX 4090 24GB de GDDR6X y 1.008GB/s de ancho de banda de memoria. Una B200 tiene 180GB de HBM3e y hasta 8TB/s: unas 7,5 veces la capacidad y 7,9 veces el ancho de banda. Las cifras muestran que la pieza de centro de datos fue diseñada para alojar modelos mayores y atender más trabajo simultáneo. No prueban que sea exactamente 7,9 veces más rápida para cualquier modelo de lenguaje. La precisión numérica, el tamaño del batch, la longitud de contexto y el stack de software alteran el rendimiento real.

El punto de equilibrio cambia con cada uso. Si la GPU ya está comprada y se mantiene ocupada día y noche con tareas valiosas, el coste marginal local puede ser bajo. Si la demanda llega en ráfagas y solo a veces hace falta un modelo más potente, pagar una API puede ser mejor que comprar capacidad ociosa. Cuando una política prohíbe transferir datos al exterior, el coste quizá ni siquiera sea la primera decisión.

La guía de OpenAI sobre sus modelos open weight también contempla las dos situaciones: el autoalojamiento puede salir más barato en ciertos casos, mientras que una API puede ser más eficiente al incluir alojamiento, mantenimiento y otros servicios. La respuesta condicional es la honesta. Sin volumen de trabajo y calidad exigida, no se sostiene que local o nube sean siempre más baratos.

La equivalencia entre modelos suele faltar en las hojas de cálculo. Comparar un modelo local pequeño con otro superior en la nube no es justo si el pequeño obliga a reintentar más, revisar más o reduce la tasa de tareas completadas. La unidad útil es una tarea que supera el mismo umbral de calidad. Los tokens baratos no producen trabajo barato si no terminan la tarea.

Hay fronteras donde la inferencia local gana con claridad

Los casos más fuertes para ejecutar en local nacen de restricciones concretas, no de preferencias.

Diagrama de cuatro ventajas estructurales de la inferencia local: privacidad, funcionamiento sin conexión, baja latencia y control de infraestructura

  • Los datos no pueden salir del entorno. En ámbitos jurídicos, médicos o corporativos confidenciales donde no se permite una API externa, la infraestructura propia es un requisito.
  • El producto debe seguir funcionando sin conexión fiable. Equipos de campo, movilidad y respuesta ante emergencias necesitan una ruta on-device que sobreviva a la caída de la red.
  • El tiempo de respuesta debe ser corto y predecible. Las sugerencias de teclado, interfaces de voz o asistencia de cámara sufren si el viaje de ida y vuelta por la red está en la ruta crítica.
  • El modelo y los registros deben quedar bajo control directo. Autoalojar open weights encaja cuando hay que fijar una versión, personalizarla o auditar toda la ruta de conservación de datos.

Bajo esas condiciones, la máxima capacidad general importa menos que ejecutar de forma fiable en el momento necesario. Un modelo especialista pequeño que completa una operación repetitiva con estabilidad puede aportar más que un modelo general mejor puntuado.

Local no significa seguro por defecto. Los modelos y runtimes descargados plantean preguntas sobre la cadena de suministro. El malware del PC, los registros y copias locales, y los permisos de usuario siguen siendo riesgos. No enviar datos a la nube es una capa de privacidad, no un programa de seguridad completo.

La forma de la carga también mueve la frontera. Una estación de vídeo que ejecuta inferencias útiles todas las noches no se parece a un portátil que carga un modelo dos veces a la semana. Una fábrica con suficiente demanda interna puede capturar en su servidor buena parte de la ventaja de utilización asociada a la nube. «Local» debe describir las condiciones operativas, no utilizarse como sinónimo de pequeño o ineficiente.

El futuro más probable es el ruteo híbrido, no un único ganador

Los productos ya mezclan ejecución local y en la nube. La documentación de Apple Private Cloud Compute describe una estructura donde las solicitudes adecuadas se procesan en el dispositivo y las que necesitan un modelo fundacional más capaz pasan a infraestructura cloud. La API experimental de inferencia híbrida de Android puede preferir Gemini Nano en el dispositivo y recurrir a la nube si no está disponible, o priorizar la nube y volver al dispositivo cuando no hay conexión.

Diagrama de ruteo híbrido que mantiene en local el trabajo privado, offline e inmediato y envía el trabajo profundo, largo e intensivo a modelos en la nube

Ejemplos de implementación: Apple Private Cloud Compute y Android experimental hybrid inference. La función de Android era experimental el 25-08-2026.

El ensayo Interaction Models de Thinking Machines aporta otra separación útil. Un modelo de interacción en tiempo real mantiene la respuesta al usuario, mientras que el razonamiento profundo y las herramientas pueden asignarse a un modelo asíncrono en segundo plano. Es evidencia de una división entre un modelo rápido y otro profundo, no prueba de que el primero sea local y el segundo esté en la nube. Mezclar ambas afirmaciones ampliaría indebidamente la fuente.

La configuración que espero se parece a esta: el modelo del dispositivo limpia entradas, oculta información privada, devuelve respuestas cortas al instante y mantiene funciones básicas sin red. Los modelos de servidor asumen documentos largos, repositorios de código grandes, llamadas complejas a herramientas y decisiones con un umbral de calidad alto. El usuario ve un solo producto, aunque varios modelos y lugares de ejecución se repartan el trabajo por dentro.

Cinco preguntas cubren casi todo el ruteo:

Pregunta Inclina hacia local Inclina hacia centro de datos
¿Pueden salir los datos del dispositivo o recinto? Transferencia prohibida o sensible Transferencia permitida por política
¿Siempre hay internet? Trabajo offline obligatorio Conexión estable disponible
¿Cuánto puede esperar el usuario? Respuesta inmediata Procesamiento largo aceptable
¿Qué profundidad y duración tiene la tarea? Corta y repetitiva Contexto largo y herramientas complejas
¿Con qué constancia se llena la capacidad? Utilización fija alta Demanda variable o gran concurrencia

Varias cosas podrían invalidar esta perspectiva. La calidad de los modelos pequeños puede crecer mucho más rápido que las expectativas. La eficiencia de memoria y energía puede dar un salto. La regulación puede dificultar el uso de centros de datos externos. En sentido contrario, trabajos de IA cada vez más largos y complejos reforzarían la centralización. Ninguna trayectoria está cerrada hoy.

La estructura actual sí permite una conclusión clara: los open weights amplían la elección del lugar de ejecución, pero no eliminan la economía de agrupar solicitudes y compartir grandes memorias y aceleradores. Mi expectativa estructural es que la IA local crecerá mientras una parte sustancial del cómputo agregado permanece en centros de datos y el dispositivo del usuario se convierte en la primera capa que decide cuándo llamarlos.

Qué anotar antes de elegir dónde desplegar

  • Comprueba que los modelos comparados entregan una calidad equivalente para la tarea.
  • Mide tokens mensuales de entrada y salida, además de solicitudes concurrentes.
  • Incluye amortización, electricidad, refrigeración y tiempo operativo en el coste local.
  • Resuelve privacidad y residencia de datos antes de optimizar la hoja de costes.
  • Define un fallback tanto para un fallo local como para uno en la nube.
  • Revisa el ruteo por tarea en lugar de convertir una ubicación en permanente.

Este análisis estructural se apoya en documentación oficial e investigación primaria. No sustituye una medición de velocidad de un modelo concreto ni la contabilidad de cada organización. Antes de decidir, conviene comparar durante un periodo corto el rendimiento local y el de la API con los mismos prompts, el mismo objetivo de calidad y la misma carga.

Fuentes y referencias

Páginas públicas usadas para contrastar hechos reportados, documentación oficial, contexto de política, información de producto y afirmaciones que pueden cambiar.