Líderes de opinión

Deja de diseñar la infraestructura de IA alrededor de la GPU

mm
Añade Unite.AI a tus fuentes preferidas en Google

Por qué los MSP deben comenzar con la carga de trabajo, no con el hardware

Dedica cinco minutos a una conferencia de IA y fácilmente podrías salir creyendo que todo despliegue exitoso de IA comienza comprando más GPUs. Es fácil entender por qué. El hardware domina la conversación. Los clientes escuchan sobre sistemas Blackwell, redes InfiniBand, nubes hiperescalables y clústeres de IA cada vez más masivos. Los proveedores naturalmente se inclinan hacia los aceleradores más nuevos y los sistemas más rápidos porque son emocionantes, relevantes y relativamente fáciles de posicionar en el mercado.

El problema no es que la computación no importe. Importa enormemente.

El problema es que comenzar por allí puede llevar a las organizaciones a formular la pregunta equivocada. El mercado de IA ya no está en la fase de experimentación. La IA se está poniendo en producción, las empresas están invirtiendo dinero real y esperan resultados comerciales medibles. Las decisiones de infraestructura se han vuelto mucho más trascendentales que hace dos años. Sin embargo, no suficientes decisiones se están guiando por los requisitos del negocio; las decisiones impulsadas por la tecnología siguen liderando.

La primera pregunta no debería ser “¿Qué GPU deberíamos comprar?”

“¿Qué carga de trabajo estamos tratando de soportar?” debería ser el foco.

Ese cambio aparentemente pequeño afecta casi todas las decisiones de infraestructura que siguen.

No hay una infraestructura de IA estándar

Una de las mayores ideas erróneas en el mercado es que exista un plano estándar para la infraestructura de IA. No lo hay.

Hablamos de IA como si fuera una única carga de trabajo. En realidad, la IA abarca una enorme gama de aplicaciones empresariales con requisitos muy diferentes. Una plataforma de IA de voz no tiene los mismos requisitos de infraestructura que la imaginería médica. La recuperación de conocimiento es distinta de la generación de imágenes. La detección de fraude no se parece al análisis predictivo, y ninguno se asemeja al procesamiento de video. Todas usan IA. Simplemente usan la infraestructura de manera diferente.

No estás diseñando infraestructura para “IA”. Estás diseñando infraestructura para una aplicación empresarial que, por casualidad, utiliza IA. Esa distinción importa. Cada carga de trabajo impone demandas únicas a la infraestructura que la respalda. Algunas requieren recursos computacionales sustanciales. Otras dependen en gran medida del rendimiento del almacenamiento porque están recuperando continuamente grandes conjuntos de datos. Algunas están limitadas por el ancho de banda de la red, mientras que otras pueden vivir o morir por la latencia, ya que cada milisegundo afecta la experiencia del cliente.

También hay una realidad práctica. La infraestructura para la que se diseñó un modelo no siempre es la que está disponible al momento de desplegarlo. La disponibilidad de hardware, los largos plazos de entrega o los plazos de implementación pueden obligar a las organizaciones a usar GPUs, aceleradores o configuraciones de infraestructura diferentes a las planificadas originalmente. Eso puede significar volver a optimizar el modelo. O incluso rediseñar el modelo alrededor del hardware que realmente pueden desplegar.

Los requisitos de seguridad y gobernanza son igualmente específicos de la carga de trabajo. Una aplicación que procesa información pública tiene requisitos muy diferentes a una que maneja transacciones financieras, registros de salud o propiedad intelectual. La protección de datos, la gestión de identidad y acceso, el cumplimiento, la soberanía, la copia de seguridad, la recuperación y la disponibilidad no pueden simplemente añadirse después del despliegue. Son decisiones arquitectónicas.

Los requisitos empresariales añaden otra capa. ¿Qué tan rápido necesitará escalar la aplicación? ¿Qué costos operativos son sostenibles? ¿Qué nivel de disponibilidad requiere el negocio? ¿Cuánta complejidad puede gestionar la organización de manera realista? Cada cliente responderá a esas preguntas de forma distinta. Por eso no existe una infraestructura de IA única para todos.

Las organizaciones que comienzan con una nube, plataforma de hardware o proveedor preferido no están acertando en la infraestructura de IA. Los líderes comienzan con la carga de trabajo y diseñan una arquitectura en torno al objetivo empresarial.

El entrenamiento acapara los titulares. La inferencia entrega el valor comercial.

La fascinación de la industria por el entrenamiento es otra razón por la que las conversaciones sobre infraestructura de IA pueden tomar la dirección equivocada.

Entrenar un modelo de lenguaje grande es un desafío de ingeniería extraordinario. Se requieren conjuntos de datos enormes, clústeres masivos de GPUs, una potencia significativa y una infraestructura capaz de operar a plena capacidad durante días, semanas o incluso meses. Es costoso, técnicamente impresionante y naturalmente atrae la atención.

Sin embargo, la mayoría de las organizaciones no están construyendo el próximo modelo de frontera. Están construyendo aplicaciones de servicio al cliente, sistemas de IA de voz, copilotos para empleados, asistentes de conocimiento, herramientas de búsqueda, plataformas de resumen de documentos, sistemas de detección de fraude y docenas de otras aplicaciones prácticas usando modelos que ya han sido entrenados.

Esas son cargas de trabajo de inferencia, y la inferencia cambia la ecuación de la infraestructura. En lugar de optimizar exclusivamente para el máximo cómputo, las organizaciones pueden necesitar optimizar para tiempos de respuesta rápidos, baja latencia, costos operativos predecibles y rendimiento constante.

A un cliente no le importa cuán poderosa sea la GPU subyacente si un chatbot tarda cinco segundos en responder. A un llamante no le importan las especificaciones del clúster de IA si un asistente de voz malinterpreta repetidamente las solicitudes o vacila durante una conversación. Simplemente saben que la aplicación no está rindiendo bien.

Diseñar cada entorno de IA como si estuvieras entrenando un modelo fundacional es, por lo tanto, generalmente el enfoque equivocado y con frecuencia innecesariamente costoso.

El objetivo de la mayoría de los clientes MSP no es construir el clúster de GPUs más grande del mundo. Poner las aplicaciones de IA en producción de forma rápida, fiable, segura y económica es la meta.

El desafío es encontrar el equilibrio correcto entre rendimiento, seguridad, escalabilidad, resiliencia y costo para las cargas de trabajo que realmente están ejecutando.

Quizá la GPU no sea tu cuello de botella

Las GPUs se han convertido en la celebridad de la infraestructura de IA. Son caras, difíciles de obtener y fáciles de comparar, lo que las convierte en el eje central de innumerables conversaciones de infraestructura. Sin embargo, la GPU puede no ser lo que está frenando una aplicación de IA una vez que llega a producción.

“¿Cuántas GPUs necesitamos?” no es la pregunta que deberíamos estar haciendo; más bien, es “¿Qué va a ralentizar esta aplicación dentro de seis meses?”

La respuesta también puede estar en otra parte de la arquitectura.

El almacenamiento es un buen ejemplo. Las cargas de trabajo de IA consumen cantidades enormes de datos, y esos conjuntos de datos crecen con el tiempo. Incluso una GPU extremadamente potente puede pasar tiempo valioso esperando en lugar de trabajando, si el almacenamiento no puede entregar la información con la rapidez necesaria. Esos datos también deben protegerse, respaldarse, conservarse, asegurarse y gestionarse a lo largo de su ciclo de vida.

En igual medida, la red importa. El ancho de banda, la latencia, el tráfico este‑oeste y la comunicación entre clústeres de IA afectan el rendimiento de la aplicación. Un entorno de cómputo bien diseñado no puede compensar indefinidamente una red mal diseñada.

Además, la seguridad debe formar parte de la arquitectura desde el principio. Preguntas que deben abordarse antes de la producción incluyen: dónde residen los datos sensibles, cómo se segmentan las redes, si las cargas de trabajo se comunican mediante conectividad privada o pública, y cómo se cumplen los requisitos de cumplimiento y soberanía.

Otro factor fácilmente pasado por alto es la conectividad. Aunque no generen titulares llamativos, la diversidad de fibra, la diversidad de rutas, las relaciones de peering y la proximidad geográfica pueden influir críticamente en la experiencia del usuario, sin mencionar la resiliencia de la plataforma.

Los clientes finales no saben ni les importa qué GPU está en la rack. Les importa si la aplicación responde de inmediato o los deja esperando.

La infraestructura física también merece atención. La disponibilidad de energía, la capacidad de refrigeración, la densidad de rack y la capacidad de expansión determinan si el despliegue exitoso de hoy puede acomodar el crecimiento de mañana.

Luego está la gravedad de los datos. A medida que los conjuntos de datos se expanden, mover petabytes de información entre ubicaciones, simplemente porque el cómputo está en otro sitio, se vuelve cada vez más ineficiente. En muchas situaciones, acercar el cómputo a los datos puede ser tanto más práctico como menos costoso.

Por eso la arquitectura importa.

Piense en un coche de carreras: el hecho de que tenga el mejor motor no garantiza la victoria. La transmisión, los neumáticos, la suspensión, la pista y, sobre todo, el piloto también son esenciales. La infraestructura de IA funciona de manera muy similar.

Las organizaciones que generan el mayor valor de la IA no serán necesariamente las que tengan los clústeres de GPUs más grandes. Serán las que comprendan cómo cada capa de la infraestructura trabaja en conjunto.

Esa es la diferencia entre comprar infraestructura y diseñarla.

Un marco de planificación centrado en la carga de trabajo

Los MSP tienen la oportunidad de cambiar la conversación sobre infraestructura.

En lugar de comenzar con:

  • ¿Qué GPU?
  • ¿Qué nube?
  • ¿Qué proveedor?

Comienza con la carga de trabajo:

  • ¿Qué problema empresarial estamos resolviendo?
  • ¿Es una carga de entrenamiento o de inferencia?
  • ¿Cuánta latencia puede tolerar la aplicación?
  • ¿Dónde viven los datos y qué tan rápido crecerán?
  • ¿Qué requisitos de seguridad, cumplimiento y soberanía se aplican?
  • ¿Cómo escalará la carga de trabajo?
  • ¿Qué nivel de disponibilidad requiere el negocio?
  • ¿Qué nivel de riesgo operativo es aceptable?
  • ¿Cuál será el costo de operar este entorno a medida que aumente el uso?

Las respuestas deben determinar la arquitectura. No al revés.

La oportunidad para los MSP

Este cambio altera el papel del MSP.

Los clientes no necesitan otro socio capaz de venderles infraestructura. Necesitan un socio que pueda ayudarles a tomar mejores decisiones de infraestructura.

Un enfoque centrado en la carga de trabajo es imprescindible, ya que brinda a los MSP la oportunidad de evaluar cómputo, almacenamiento, redes, conectividad, seguridad, ubicación de datos, disponibilidad y costo como partes de una única arquitectura, en lugar de decisiones de compra separadas.

De esta manera, puedes controlar los costos, mejorar el rendimiento e identificar riesgos operacionales y de seguridad antes de que las aplicaciones lleguen a producción.

También se crea un modelo de negocio mejor para el MSP.

Los MSP pueden construir servicios recurrentes de mayor valor alrededor de la arquitectura, el despliegue, la optimización, la seguridad, la gestión del ciclo de vida, la planificación de capacidad y la mejora continua, en lugar de competir principalmente en la reducción de márgenes de hardware.

El valor no está en recomendar la GPU más reciente o la plataforma de nube más nueva. Está en saber cuándo un cliente las necesita, cuándo no, y qué más debe diseñarse en torno a ellas.

La infraestructura de IA, en última instancia, no es una decisión de hardware. Es una decisión de arquitectura impulsada por la carga de trabajo, los datos y el resultado comercial que el cliente intenta lograr.

Los MSP que comprendan esa distinción estarán posicionados para convertirse en algo mucho más valioso que los proveedores de infraestructura.

Se convertirán en las personas en las que los clientes confían para ayudar a decidir qué infraestructura necesitan realmente.

Richard Copeland es el Director Ejecutivo de Leaseweb USA. Es responsable de gestionar el negocio de la empresa en nueve ubicaciones de centros de datos en todo Estados Unidos, mientras ejecuta y desarrolla la visión y la estrategia de la compañía en la región. Durante más de 20 años, Richard ha desempeñado funciones clave de liderazgo en ventas y gestión de cuentas dentro de Leaseweb USA y Verizon Business. Richard posee una Licenciatura en Ciencias de la Virginia Commonwealth University. Le apasiona trabajar con su equipo para alcanzar los objetivos de la empresa, mantener el equilibrio entre la vida laboral y personal de los empleados y garantizar la satisfacción del cliente. En su tiempo libre, a Richard le gusta hacer ejercicio, ver películas y deportes, y pasar tiempo con su familia y amigos