Inferencia de la inteligencia artificial distribuida: Lo que deben saber los líderes de los proveedores de servicios de telecomunicaciones

En la actualidad, todos los proveedores de servicios de telecomunicaciones implementan la inteligencia artificial. Los casos prácticos incluyen bots de atención al cliente, copilotos de operaciones de red e inteligencia artificial como servicio (AIaaS) gestionada para clientes empresariales externos, entre otros. 

La parte difícil es la correlación del caso práctico con el caso empresarial, donde el factor clave es el costo del acelerador de inteligencia artificial, ya sea una unidad de procesamiento gráfico (GPU), una unidad de procesamiento tensorial (TPU) o una unidad de procesamiento neuronal (NPU). El costo por inferencia determina si estos aceleradores de inteligencia artificial mejoran los márgenes de ganancias o los reducen. Para mantener los costos bajos, el modelo de inteligencia artificial que selecciones es tan importante como la forma en que lo implementes y utilices en una escala geográfica distribuida.

En un artículo reciente, el equipo de Red Hat trabajó en los desafíos de la implementación de inferencias como un problema de arquitectura determinado por el tráfico y la escala, y no solo por el tamaño del modelo. Esta publicación de blog resume sus hallazgos.

Cómo afecta el costo por inferencia a las pérdidas y ganancias

Cada solicitud de inteligencia artificial tiene dos tareas distintas en el mismo hardware: 

• Primero, lee la petición o la entrada, ya sea un historial de facturación, un ticket de soporte, un registro de red u otro elemento que deba procesarse. 
• Luego, genera la respuesta a esa entrada, un token a la vez.

La fase de lectura determina cuánto tiempo espera el usuario para ver la primera palabra; la fase de escritura determina si la conversación es fluida o si tiene interrupciones constantes. Las dos fases necesitan diferentes perfiles de recursos y distintas optimizaciones; cuando comparten los recursos del acelerador de inteligencia artificial, compiten entre sí.

Esta tensión afecta las ganancias y las pérdidas de manera distinta en los diversos casos prácticos de inteligencia artificial y tipos de cargas de trabajo. Por ejemplo, con los chatbots de atención al cliente, el costo por contacto aumenta cuando los bots se detienen y las sesiones se derivan a los agentes. Las ofertas de inteligencia artificial para empresas incurren en penalizaciones en los acuerdos de nivel de servicio (SLA) cuando no cumplen con los compromisos de latencia. Además, el margen de los productos de inteligencia artificial business-to-business (B2B) se reduce cuando el costo por consulta supera el precio establecido en el contrato. 

La mayoría de los errores de implementación son errores de compensación y surgen cuando un equipo optimiza una métrica que su producto no vende. El análisis de algunas formas específicas en las que la inteligencia artificial genera ingresos puede ilustrar la implementación adecuada para cada tipo de carga de trabajo.

Atención al cliente

La atención al cliente es el caso más claro. El tráfico de atención consiste en miles de sesiones de chat cortas y simultáneas que reutilizan la misma tarifa y el preámbulo de la política en cada llamada. El equipo de Red Hat pudo identificar lo siguiente a partir de los puntos de referencia de vLLM de Red Hat:

• La división y el ajuste adecuado de los grupos de lectura y escritura redujeron los costos entre un 25 % y un 40 % en este tipo de tráfico.
• El enrutamiento con reconocimiento de caché, el enfoque de programación que implementó el proyecto open source llm-d, generó de 2 a 3 veces más tokens por GPU y un costo por token de 3 a 5 veces menor cuando la reutilización de peticiones es alta.

Los sistemas de producción no verán este nivel de mejora, pero la tendencia se mantuvo en todas las cargas de trabajo que medimos. Con decenas de millones de interacciones de atención al mes, reducir los costos de inferencia incluso unos pocos puntos puede ahorrar suficiente dinero para pagar el siguiente ciclo del producto sin nuevos gastos de capital (CapEx) en aceleradores.

Operaciones de red

Las operaciones de red tienen la forma opuesta: hay pocos usuarios y los documentos que se procesan son muy largos. El análisis de incidentes vuelve a leer los mismos runbooks, registros de topología y manuales de proveedores constantemente, por lo que el principal factor de costo es almacenar en caché lo que ya se procesó. El resultado es un menor tiempo de diagnóstico y menos derivaciones a los ingenieros sénior.

Inteligencia artificial gestionada para empresas

La venta de inteligencia artificial a clientes empresariales agrega un tercer perfil: muchos tenants, SLA en niveles y picos de demanda. Dos mecanismos pueden proteger el margen en estos escenarios:

• El encadenamiento de modelos envía consultas de rutina a un modelo pequeño y deriva solo las difíciles, lo cual reduce los costos del clúster entre un 40 % y un 60 % cuando predominan las consultas sencillas.
• El control de admisión vinculado a los objetivos de nivel de servicio (SLO) rechaza las solicitudes que infringirían un SLA en lugar de ponerlas en cola para que fallen, lo cual protege la credibilidad del contrato bajo carga.

Como se muestra en la Tabla 1, estos 3 casos prácticos en conjunto pueden servir como modelo para los niveles de precios Gold, Silver y Bronze, en lugar de obligar a los clientes a apostar por un solo grupo compartido de aceleradores de inteligencia artificial. Sin embargo, 2 limitaciones más completan el panorama para los proveedores de servicios e ilustran cómo se pueden personalizar los servicios de inteligencia artificial para clientes específicos. 

Inteligencia artificial soberana con capacidad de cloudbursting

Las normas de soberanía exigen que los datos de los suscriptores permanezcan en su país de origen. El patrón que mejor se adapta a esa necesidad es una base local regulada con cloudbursting que se mantiene inactiva entre picos. Un único plano de control como Red Hat OpenShift AI mantiene los dos entornos alineados para que el cumplimiento no dependa solo de la disciplina de configuración.

Edge computing

Al considerar el extremo de la red, con aproximadamente 100 sesiones simultáneas o menos, la respuesta correcta es un modelo por acelerador sin una agrupación compleja.  Las consultas difíciles deben derivarse a través de la red de retorno (backhaul) para que el gasto en transporte siga la complejidad en lugar del volumen.

Tabla 1 Cómo los tipos de cargas de trabajo generan resultados empresariales tangibles

Estas son las preguntas que los proveedores deben hacerse al considerar cada uno de estos casos prácticos:

• Atención al cliente: ¿Cuánto cuesta hoy una conversación de atención totalmente automatizada y qué cambio individual afecta más a esa cifra? Una buena respuesta cita el costo por contacto contenido medido en el tráfico real, con un factor probado y sus cifras de antes y después.
• Operaciones de red: ¿Cuánto tiempo espera un ingeniero para obtener una respuesta útil de los registros de incidentes? ¿Se vuelven a procesar los mismos documentos cada vez? Una buena respuesta muestra la frecuencia con la que los runbooks y los registros del sitio se sirven desde la caché frente a la relectura, y la tendencia del tiempo hasta la primera respuesta.
• Servicios B2B: ¿Qué SLA empresarial se incumple primero bajo carga máxima? ¿La solución es más hardware o un mejor enrutamiento? Una buena respuesta identifica el nivel que falla en una prueba de carga y muestra que se intentó una corrección de enrutamiento o admisión antes de una solicitud de compra.
• Soberanía y picos: ¿Cuánta capacidad permanece inactiva entre picos de actividad solo para cumplir con las normas de residencia de datos? Una buena respuesta informa sobre el uso de la base y un diseño de ráfaga que no tiene costo mientras espera.
• Edge y campo: ¿Qué proporción de las consultas de campo se envía de vuelta a un clúster central y cuánto cuesta ese transporte? Una buena respuesta indica la tasa de resolución local por sitio, con el escalamiento reservado para las consultas que el modelo local no puede manejar.

Plan de inversión

Una vez establecido un caso práctico de inteligencia artificial, el siguiente paso es desarrollarlo de manera eficiente y rentable. La secuencia importa más que el destino. Cada etapa se activa mediante una medición, no por una fecha del cronograma, y cada una se amortiza antes de que comience la siguiente:

1. Comienza con 1 nodo: Ejecuta una sola instancia de servicio en tráfico real de red o de atención al cliente durante una semana. Esa base es la medida para cada decisión posterior; el tráfico de laboratorio sintético será engañoso.
2. Agrega enrutamiento inteligente: Una segunda réplica ofrece menos de 1,8 veces el rendimiento de una sola. Esa brecha significa que las solicitudes llegan a servidores que deben volver a leer un contexto que otro servidor ya tiene. Es un desperdicio de enrutamiento, no falta de capacidad, así que corrígelo antes de comprar hardware.
3. Separa los grupos de lectura y escritura: Haz esto solo cuando las mediciones muestren que una fase está limitando a la otra lo suficiente como para justificar la complejidad operativa adicional.
4. Adopta el grid multitenant: Cuando varios productos y clientes B2B comparten la plataforma, los mecanismos que protegen los SLA en niveles justifican su complejidad. Por debajo de esa escala, son un esfuerzo desperdiciado.

Cada paso restablece la base; la estrategia de inferencia de inteligencia artificial es una serie de apuestas medidas, no una aprobación única de la arquitectura. Los proveedores de servicios ya aplican este manual con el espectro inalámbrico: asignar capacidad a los productos que tienen un retorno de la inversión (ROI), medir continuamente y recuperar lo que esté inactivo. Los aceleradores de inteligencia artificial merecen la misma disciplina.

Conclusión

La inferencia de inteligencia artificial distribuida determina si los productos de inteligencia artificial de los proveedores de servicios mantienen su margen. Nada de lo planteado en esta publicación de blog requiere comprometer todo el presupuesto: cada mecanismo es un paso medido que se prueba en el tráfico del proveedor antes de que comience el siguiente. La Tabla 1 indica por dónde empezar.

Cuando estés listo para trabajar en esto para tu cartera de red, atención al cliente o B2B, presenta tus datos de tráfico a tu equipo de cuenta de Red Hat. vLLM, llm-d y Red Hat OpenShift AI son la forma en que implementamos este patrón con los proveedores de servicios hoy en día, y la conversación avanza más rápido cuando parte de tus necesidades, no de un plan genérico.