¿Sustituirán los pesos abiertos y la IA local la inferencia en centros de datos?

Los modelos de pesos abiertos están evolucionando hasta ser lo bastante pequeños y eficientes como para ejecutarse rápidamente incluso en PC personales y smartphones. Sin embargo, no puede afirmarse que, a largo plazo, la mayor parte de la inferencia de IA de alto rendimiento vaya a trasladarse de los centros de datos a los dispositivos personales. Mientras avanzan los modelos locales, también evolucionan los modelos de gama más alta, los aceleradores y el software de inferencia de los centros de datos.

La pregunta clave no es «¿podrá el portátil del futuro ejecutar el modelo más avanzado de hoy?». Hay que comparar cuál de los modelos locales y de centro de datos disponibles en ese mismo momento puede completar la tarea deseada con mayor precisión y de forma más económica.

Cuatro conceptos que primero deben distinguirse

En el debate sobre la IA local suelen confundirse el modo de publicación del modelo, su tamaño y el lugar donde se ejecuta. Los siguientes conceptos corresponden a ejes distintos.

Los modelos de pesos abiertos se ofrecen con licencias que permiten su distribución y modificación, pero el alcance de uso y las condiciones de redistribución varían según el modelo. El hecho de que los pesos sean públicos no significa que también se hayan publicado todos los datos de entrenamiento, el proceso de entrenamiento y el código fuente.

Además, la dicotomía «local frente a nube» no es suficiente. Entre los dispositivos y las grandes nubes públicas existen múltiples lugares de ejecución, como servidores GPU internos de las empresas, servidores de borde de operadores de telecomunicaciones y nubes privadas.

Los modelos locales del futuro compiten con los modelos de centro de datos del futuro

Los avances en compresión de modelos, cuantización, destilación de conocimiento y optimización de motores de inferencia pueden permitir que los dispositivos personales del futuro alcancen un rendimiento que hoy requiere equipos de nivel servidor. Sin embargo, esto no significa que los modelos locales vayan a alcanzar a los modelos más avanzados de ese momento.

En los centros de datos también evolucionan simultáneamente los siguientes elementos.

• Modelos más grandes y nuevas arquitecturas, como los modelos de mezcla de expertos
• Memoria de gran ancho de banda e interconexiones rápidas entre aceleradores
• Sistemas de inferencia que aprovechan contextos largos y herramientas externas
• Optimizaciones de servicio como procesamiento por lotes, gestión de caché, cuantización y decodificación especulativa
• Sistemas compuestos que combinan varios modelos con herramientas de búsqueda y ejecución de código

Por tanto, el criterio de comparación debe ser el rendimiento relativo, no el absoluto. Aunque dentro de unos años un portátil pueda ejecutar un modelo potente al nivel de los actuales, es probable que los sistemas de centro de datos de ese mismo momento puedan procesar tareas más largas, contextos más amplios y más llamadas a herramientas.

Por supuesto, tampoco puede garantizarse que esta brecha se mantenga para siempre. Si se ralentizan las mejoras de rendimiento de los modelos grandes o si los modelos pequeños superan el umbral de calidad en la mayoría de las tareas profesionales, la competitividad de la ejecución local podría aumentar considerablemente.

Si aumentan las expectativas de los usuarios, también cambia el criterio de «modelo suficientemente bueno»

Las tareas representativas de las primeras IA generativas eran responder preguntas breves, redactar frases, resumir y generar fragmentos de código. Ahora los usuarios exigen tareas de larga duración como las siguientes.

• Leer una base de código completa y modificar varios archivos de forma coherente
• Ejecutar pruebas, rastrear las causas de los fallos y volver a hacer correcciones
• Investigar múltiples fuentes y comparar pruebas contradictorias
• Utilizar secuencialmente varias herramientas, como navegadores, bases de datos y terminales
• Completar planes a largo plazo recordando los resultados intermedios

En solicitudes breves y sencillas, las pequeñas diferencias de calidad pueden pasar inadvertidas. Sin embargo, en las tareas de agentes de IA con muchas etapas, los errores de cada etapa se acumulan. Un modelo relativamente débil tiene más probabilidades de perder de vista los objetivos o las restricciones, elegir una herramienta incorrecta o repetir el mismo fallo.

Por este motivo, los usuarios pueden elegir no simplemente un modelo ejecutable, sino uno con una alta probabilidad de completar la tarea dentro del presupuesto y del plazo de latencia. Incluso un modelo que antes era excelente puede resultar frustrante para tareas complejas después de haber experimentado uno más fiable.

También existe un efecto en la dirección opuesta. Si las mejoras de calidad por encima de cierto nivel apenas cambian los resultados reales del trabajo, un modelo pequeño y barato resulta razonable. En definitiva, la elección del modelo debe evaluarse en función de la tasa de finalización de las propias tareas, el número de reintentos y el tiempo de revisión, más que de las puntuaciones de referencia.

Ventajas estructurales de los centros de datos en los costes de inferencia

El procesamiento por lotes distribuye entre varias solicitudes el coste de leer los pesos del modelo

Para que un LLM genere tokens, debe acceder repetidamente a los pesos a gran escala y a los estados intermedios almacenados en la memoria de la GPU. En particular, la fase de decodificación con lotes pequeños puede verse muy limitada no solo por la capacidad de cálculo, sino también por el ancho de banda de la memoria.

Los centros de datos pueden agrupar las solicitudes de varios usuarios o ejecutarlas mediante procesamiento continuo por lotes para procesar varios tokens con un solo acceso a los pesos. Cuando siguen llegando numerosas solicitudes, pueden reducir el tiempo de inactividad de los aceleradores haciendo que una nueva solicitud ocupe el lugar de otra que ha terminado.

Como los usuarios individuales generan pocas solicitudes simultáneas, resulta difícil obtener este efecto a la misma escala. No obstante, aumentar indiscriminadamente el tamaño de los lotes incrementa la latencia del primer token y el tiempo de respuesta de cada solicitud, y también requiere más memoria para la caché KV. La ventaja de los centros de datos no reside en el procesamiento por lotes en sí, sino en la capacidad de ajustar muchas solicitudes de acuerdo con objetivos de latencia.

Los aceleradores especializados y las configuraciones de los sistemas son diferentes

Las GPU de consumo también ofrecen un rendimiento excelente para la inferencia local. Sin embargo, los grandes centros de datos suelen poder utilizar más memoria de acelerador, mayor ancho de banda de memoria, interconexiones rápidas entre aceleradores y redes de nivel servidor. Estas diferencias cobran importancia al distribuir modelos grandes entre varios equipos o al procesar contextos largos.

Esto no significa que las GPU para centros de datos sean más económicas que las GPU de consumo en todas las condiciones. Si se utiliza de forma esporádica un modelo pequeño y ya se dispone de un equipo adecuado, el desembolso en efectivo de la ejecución local puede ser bajo. Por el contrario, si se mantiene un alto rendimiento de procesamiento o si varios usuarios comparten los recursos, aumentan las ventajas de los equipos de servidor y del software de servicio especializado.

La tasa de utilización cambia el coste total

Calcular como cero el coste de inferencia por el mero hecho de haber pagado ya el precio de compra de una GPU local subestima el coste económico. El coste total incluye los siguientes conceptos.

• Coste de compra de la GPU, la memoria, el almacenamiento y la fuente de alimentación
• Depreciación o coste de oportunidad según la vida útil del equipo
• Costes de electricidad y refrigeración durante la inferencia
• Tiempo dedicado a instalación, actualizaciones, respuesta ante fallos y gestión de la seguridad
• Baja tasa de utilización mientras el equipo permanece inactivo

Los servicios de centros de datos también reflejan en sus tarifas los aceleradores, la red, la electricidad, el personal y el margen del operador. Por tanto, que la ejecución local o la API sea más barata depende del volumen de uso, el tamaño del modelo, la disponibilidad previa del equipo, el precio de la electricidad, la velocidad de respuesta y el personal de operaciones.

Las estimaciones que indican diferencias de eficiencia de decenas de veces en entornos específicos no deben utilizarse como proporciones universales aplicables a todos los entornos. Los resultados también varían considerablemente si cambian el tamaño del lote, la longitud de entrada y salida, la arquitectura del modelo, el nivel de cuantización, el hardware y los objetivos de latencia.

Los modelos pequeños y la ejecución local no son la misma elección

Los modelos pequeños pueden ser suficientes para tareas sencillas de clasificación, extracción estructurada de información, resúmenes breves, enrutamiento de órdenes y correcciones básicas. Sin embargo, elegir un modelo pequeño no significa que necesariamente deba ejecutarse en el dispositivo del usuario.

Los modelos pequeños también pueden alcanzar una alta tasa de utilización si las solicitudes masivas se procesan por lotes en un centro de datos. Por el contrario, un modelo grande de pesos abiertos que una organización deba controlar puede ejecutarse en servidores propios. Resulta más preciso dividir la toma de decisiones en dos etapas.

1. Elegir el tamaño y el tipo de modelo que satisfagan la calidad y las funciones necesarias para la tarea.
2. Elegir el lugar de ejecución adecuado para la latencia, el coste, la seguridad y las condiciones operativas.

Mezclar estas dos etapas puede llevar a conclusiones erróneas como «los modelos pequeños son eficientes, por lo que la ejecución local es eficiente» o «se necesita un modelo grande, por lo que hay que usar una nube pública».

Condiciones en las que la IA local presenta ventajas claras

Interfaces en las que una latencia corta es fundamental

En las conversaciones de voz, la corrección de teclado, el procesamiento de cámara y el control en tiempo real, el tiempo de ida y vuelta de la red y las variaciones de conectividad cambian considerablemente la experiencia del usuario. Un modelo local pequeño puede encargarse de detectar palabras de activación, preprocesar la voz, gestionar órdenes sencillas y ofrecer una respuesta inmediata.

Entornos sin Internet o con una conexión inestable

En aeronaves, barcos, zonas de catástrofe, regiones remotas y equipos en movimiento, el propio funcionamiento sin conexión es una función esencial. Aunque la calidad de un modelo de centro de datos sea superior, no constituye una opción si no es posible conectarse.

Entornos en los que la información personal y confidencial no puede enviarse al exterior

Los datos médicos, financieros, militares, de investigación y desarrollo, jurídicos o internos de empresas pueden estar sujetos a normativas y contratos que restringen su transmisión a API externas. Los modelos locales o con alojamiento propio ofrecen el valor de permitir un control directo de los límites de los datos.

Sin embargo, no puede asumirse que «por ser local es automáticamente seguro». Siguen siendo necesarios controles ante el robo de dispositivos, el malware, los errores de permisos de acceso, los registros y archivos temporales y los problemas de la cadena de suministro de modelos. El nivel de seguridad de la nube pública también varía según el cifrado, el periodo de conservación, la elección de la región y las condiciones contractuales.

Cuando es necesario controlar y experimentar directamente con el modelo

Los modelos de pesos abiertos son útiles para que los investigadores analicen su funcionamiento interno y para que los desarrolladores modifiquen la cuantización, el ajuste fino y los motores de inferencia. La ejecución propia también adquiere más valor cuando se necesitan versiones fijas de modelos, registros detallados, reproducibilidad o despliegues personalizados que no ofrece una API.

Condiciones en las que la inferencia en centros de datos es sólida

Por lo general, existen motivos importantes para utilizar recursos de centros de datos en las siguientes tareas.

• Tareas que requieren modelos muy grandes o contextos largos
• Tareas que analizan simultáneamente grandes repositorios de código y conjuntos de documentos
• Tareas de agentes de IA de larga duración que utilizan varias herramientas
• Servicios que procesan continuamente solicitudes de numerosos usuarios
• Organizaciones que deben confiar a un equipo profesional de operaciones la respuesta ante fallos, el escalado y las actualizaciones de modelos
• Procesamiento multimodal que requiere varios aceleradores y grandes cantidades de memoria

El valor de los centros de datos no se limita al rendimiento de generación de tokens de un único modelo. También es importante la posibilidad de gestionar como un solo sistema índices de búsqueda, bases de datos, ejecución de código en entornos aislados, herramientas de observación y políticas de seguridad.

Por qué la IA híbrida es una opción probable

Un diseño realista divide las tareas en lugar de elegir de forma fija entre la ejecución local y el centro de datos.

Por ejemplo, un modelo local de un smartphone puede procesar la voz y eliminar la información sensible antes de enviar únicamente las partes complejas a un modelo de centro de datos. También es posible seguir ofreciendo funciones limitadas de forma local cuando se pierde la conexión y transferir las tareas difíciles cuando esta se restablece.

En esta arquitectura, aunque el usuario sienta que interactúa con una IA local, los cálculos más difíciles pueden realizarse en un centro de datos. Al mismo tiempo, como solo se transmite la información necesaria en lugar de enviar todos los datos originales al servidor, puede reducirse el alcance de la exposición de información personal.

Una variable fácil de pasar por alto: fiabilidad operativa y coste del enrutamiento

Las comparaciones de modelos suelen limitarse a la precisión, la velocidad de los tokens y el precio de la API. En los sistemas reales, la fiabilidad operativa y los fallos de enrutamiento determinan la eficiencia general.

Un sistema híbrido debe decidir qué solicitudes completar localmente y cuáles enviar al servidor. Si un modelo débil asume por error una tarea difícil, puede fracasar varias veces y acabar llamando de todos modos al modelo de centro de datos. En ese caso se pagan tanto el cálculo local y la latencia como el coste del servidor.

Por el contrario, enviar siempre incluso las solicitudes sencillas al modelo más avanzado aumenta los costes innecesarios y la transmisión de datos. Por tanto, un buen enrutador necesita las siguientes funciones.

• Criterios para estimar la dificultad de la tarea y el contexto necesario
• Métodos para detectar la incertidumbre de los resultados locales
• Políticas para cambiar a un modelo superior cuando se supere un número de fallos o un límite de tiempo
• Procedimientos para eliminar la información sensible o solicitar autorización antes de transmitirla al servidor
• Un sistema de evaluación para gestionar las diferencias de versión entre los modelos locales y de servidor

Este es un factor fácil de pasar por alto en una simple comparación de hardware. La competitividad futura puede depender menos de poseer el modelo más grande que de la precisión con la que las tareas se asignen al modelo y al lugar de ejecución adecuados.

Cómo comparar directamente costes y rendimiento

Para elegir entre la ejecución local y los centros de datos, deben compararse como mínimo los siguientes conceptos durante el mismo periodo y con la misma unidad de trabajo.

Coste mensual equivalente de la ejecución local

Coste mensual equivalente del equipo + coste de electricidad y refrigeración + valor del tiempo de operación + coste de fallos y sustituciones

Dividirlo por el número de tareas completadas con éxito durante un mes permite estimar el coste por tarea. Para reflejar los costes de los reintentos y de la revisión humana, debe utilizarse como referencia el número de tareas completadas con éxito, no simplemente el número de tokens.

Coste mensual del centro de datos

Tarifas de entrada y salida + tarifas de almacenamiento, búsqueda y uso de herramientas + costes de red + costes de gestión

Si se utilizan instancias reservadas o dedicadas, también debe incluirse en el coste el tiempo durante el que no se hayan utilizado.

Indicadores de calidad que deben medirse conjuntamente

• Proporción de tareas completadas sin modificaciones
• Número medio de reintentos
• Tiempo transcurrido hasta la primera respuesta y hasta la finalización completa
• Tiempo dedicado por las personas a revisar y corregir
• Interrupciones del servicio y tasa de fallos de red
• Alcance de la información sensible transmitida al exterior

Es preferible crear un conjunto fijo de evaluación que represente el trabajo real y usarlo para la comparación, en lugar de extraer conclusiones a partir de unas pocas solicitudes de prueba breves.

La energía y el impacto medioambiental tampoco pueden juzgarse únicamente por el lugar de ejecución

El procesamiento local no siempre consume menos energía solo porque reduzca la transmisión por red. Los centros de datos pueden aprovechar altas tasas de utilización de los equipos y sistemas eficientes de refrigeración, pero también generan las cargas propias de operar instalaciones a gran escala y de utilizar la red eléctrica.

Para comparar el impacto medioambiental deben considerarse conjuntamente los siguientes factores.

• Consumo eléctrico real por tarea
• Tasa media de utilización de los equipos
• Pérdidas de refrigeración y electricidad de los centros de datos
• Intensidad de carbono de las fuentes de electricidad de cada región
• Emisiones incorporadas en la fabricación de GPU y dispositivos
• Capacidad de cálculo desperdiciada por fallos y reintentos del modelo

Incluso con el mismo modelo, la energía consumida por tarea puede diferir entre una GPU personal con largos periodos de inactividad y un servidor operado con lotes grandes. Por el contrario, ejecutar brevemente un modelo pequeño en un dispositivo de bajo consumo ya disponible puede ser más eficiente que llamar a un servidor. Debe desconfiarse de las afirmaciones universales sobre sostenibilidad que no especifiquen el alcance de la medición ni las condiciones de las tareas.

Tres cambios que podrían situar a la IA local en el centro

También es posible que cambie la perspectiva centrada en los centros de datos.

1. Cuando el suministro de los centros de datos esté limitado por condiciones externas: las redes eléctricas, el suministro de semiconductores, las normativas o los problemas de soberanía de los datos pueden dificultar la expansión de la inferencia centralizada a gran escala.
2. Cuando la eficiencia de los modelos pequeños mejore mucho más rápido que la de los modelos grandes: si los modelos ejecutables en dispositivos personales se aproximan a los modelos grandes en calidad de trabajo real, habrá menos motivos para pagar por un rendimiento adicional.
3. Cuando la mayoría de las tareas alcance un punto de saturación de calidad: si los modelos más grandes apenas aportan mejoras perceptibles en la tasa de éxito de las tareas, pueden imponerse las ventajas de coste, latencia y seguridad de la ejecución local.

Sin embargo, tampoco hay razones suficientes para asumir que solo dejarán de evolucionar los modelos grandes o que el nivel de exigencia de los usuarios permanecerá fijo. A medida que los modelos se vuelven más potentes, los usuarios tienden a encomendarles tareas más largas y problemas más difíciles.

Conclusión

La IA local no desaparecerá. Es muy probable que gane importancia en ámbitos que requieren interfaces de voz, respuestas inmediatas, funciones sin conexión, protección de la información personal, redes cerradas y control de modelos.

Sin embargo, el mero hecho de que los modelos locales evolucionen no permite concluir que sustituirán a la inferencia de alto rendimiento de los centros de datos. Los centros de datos también evolucionan mediante modelos más potentes, equipos especializados, procesamiento por lotes y altas tasas de utilización. En la inferencia compleja y las tareas de agentes de IA de larga duración, pequeñas diferencias de rendimiento pueden generar grandes diferencias en la tasa final de éxito de las tareas y en los costes de revisión.

Por tanto, a largo plazo importa más la distribución de funciones que determinar si ganan los sistemas locales o los centros de datos. La dirección más realista es una arquitectura híbrida en la que los modelos locales se encarguen del procesamiento de entrada, la respuesta inmediata, la protección de la información sensible y el enrutamiento de solicitudes, mientras que los modelos de centro de datos asuman las tareas que requieren recursos a gran escala y una alta capacidad de inferencia.