Operación de sistemas de inferencia distribuida a escala — Nishant Gupta y Naman Ahuja, Meta

EspañolالعربيةDeutschEnglishFrançaisBahasa Indonesia日本語PortuguêsРусский
AAI Engineer
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00Buenos días a todos. Bienvenidos a la primera charla de inferencia del último día del AI Engineering World Fair.
00:00:17Mi nombre es Nishan Gupta y hoy me acompaña mi coponente Naman Ahuja.
00:00:23Trabajamos en el desarrollo de la infraestructura de eficiencia, entrenamiento e inferencia en Meta.
00:00:27Hoy vamos a hablar sobre cómo operar sistemas de inferencia distribuidos a gran escala.
00:00:32Como todos sabemos, la inferencia ya no es solo un artefacto de investigación adaptado a un producto.
00:00:37Es una carga de trabajo fundamental de infraestructura a hiperescala que está creciendo a un ritmo enorme.
00:00:43El tráfico de inferencia ya supera al de los microservicios más grandes del mundo
00:00:47y su ritmo de crecimiento es el más rápido de cualquier carga de trabajo que hayamos visto jamás.
00:00:54Rebobinemos hasta alrededor de 2008 e intentemos comparar la era de la IA con la era de la nube.
00:01:00Hacia 2008, la nube comenzó como ofertas de máquinas virtuales.
00:01:05La ingeniería interesante radicaba en la virtualización.
00:01:07Luego, con el tiempo, el valor subió en la pila hacia los planificadores: Borg, Kubernetes, Mesos.
00:01:14Después a las mallas de servicios, a los escaladores automáticos y a varias plataformas construidas sobre ellos.
00:01:18La capa de orquestación fue la que realmente capturó el valor y la complejidad.
00:01:24La IA sigue exactamente la misma trayectoria, pero comprimida en los últimos años en lugar de una década.
00:01:30Comenzamos con modelos simples ejecutándose en GPU.
00:01:33Luego vimos la evolución de frameworks de servicio de modelos como vLLM, TorchServe, Triton, y ahora vemos surgir la capa de orquestación en tiempo real, resolviendo desafíos complejos de enrutamiento, gestión de KV cache, desagregación de pre-fill y decode, y multiplexación multimodelo.
00:01:51En esta siguiente fase de la era de la IA, no se trata solo de los mejores modelos, kernels u optimizaciones.
00:01:57Se trata de todo el ecosistema.
00:01:58Se trata del plano de control y la orquestación, y en esto nos centraremos en esta charla.
00:02:06Hablemos un poco sobre la explosión de la demanda agéntica.
00:02:09En el servicio web clásico, antes de que arrancaran las cargas de inferencia de IA, la capacidad se escalaba de forma casi lineal con los usuarios, según el tipo de carga.
00:02:17El doble de usuarios implicaba casi el doble de QPS y el doble de flota de infraestructura si no había optimizaciones; la planificación de capacidad era prácticamente un ejercicio de hoja de cálculo.
00:02:28En este nuevo servicio agéntico, la capacidad escala según el número de usuarios por el número de llamadas por usuario, por el número de tokens, lo cual varía según el modelo, las optimizaciones y el hardware.
00:02:40Un chatbot puede hacer una llamada al modelo por turno, lo que está evolucionando a 10 o 20 para copilotos, 50 para agentes de investigación, y miles de llamadas para cargas autónomas sin intervención humana.
00:02:54La conclusión clave es que no se puede planificar la capacidad para agentes igual que para microservicios.
00:03:00Debemos pensar en la elasticidad e implementar una planificación y un control de admisión conscientes de la carga de trabajo.
00:03:08Ahora profundicemos un poco en las diferencias, pros y contras entre el servicio tradicional de microservicios y la inferencia moderna en estas dimensiones clave.
00:03:19La forma de la solicitud.
00:03:20Los microservicios asumen solicitudes cortas y uniformes, mientras que las solicitudes de LLM que vemos varían de 50 a 100.000 tokens, con perfiles de cómputo muy distintos entre pre-fill y decode.
00:03:33Para el procesamiento por lotes, las pilas clásicas de microservicios lo hacían casi siempre en la capa del balanceador de carga, si es que lo hacían.
00:03:40Sin embargo, el servicio de LLM requiere un procesamiento por lotes continuo en vuelo; de lo contrario, el rendimiento cae en un orden de magnitud o más.
00:03:48Estado.
00:03:49La mayoría de los microservicios clásicos no tenían estado fuera de la capa de almacenamiento.
00:03:54Sin embargo, el servicio de LLM requiere un enorme estado por solicitud, la KV Cache, que es muy costosa de construir y aún más costosa de descartar.
00:04:02Unidades de escalado.
00:04:03Unidades de escalado.
00:04:05Al pensar en microservicios tradicionales, podíamos ejecutarlos en CPU baratas, en pods.
00:04:11Sin embargo, la inferencia moderna requiere ejecutarse en GPU, que son 100 veces más caras, 10 veces más lentas de adquirir y no podemos sobredimensionarlas a la ligera.
00:04:20De lo contrario, provocará un enorme desperdicio.
00:04:23Modo de fallo.
00:04:25Si pensamos en los microservicios tradicionales, si un host o un pod fallaba, podíamos reiniciarlo.
00:04:34Podíamos reconstruir el estado si era necesario.
00:04:36Sin embargo, en la inferencia de modelos toma mucho tiempo pasar de un inicio en frío a uno en caliente.
00:04:42Y si una GPU falla a mitad del decode, puede perder miles de tokens en vuelo y provocar una acumulación en la cola.
00:04:50La conclusión es que el cuello de botella no es solo el modelo.
00:04:53Es la orquestación misma.
00:04:58Como podemos ver en estas decisiones ocultas detrás de un prompt, cuando vamos a una aplicación agéntica, esta requiere varios pasos tras bambalinas.
00:05:06Tenemos que autenticar.
00:05:07Tenemos que elegir un modelo según el tipo de solicitud.
00:05:09Tenemos que seleccionar la región a la que va.
00:05:11Tenemos que hacer el control de admisión.
00:05:12Tenemos que consultar la caché.
00:05:14Tenemos que ejecutarlo en la GPU.
00:05:17Tenemos que agrupar por lotes.
00:05:18Y hay una serie de otros pasos involucrados.
00:05:19Y como vemos, de todos estos pasos, solo uno requiere el modelo: el pre-fill y decode.
00:05:25Ya sea inferencia desagregada o no.
00:05:29Los demás pasos requieren infraestructura.
00:05:31La inteligencia puede residir en el modelo, pero la economía, la confiabilidad y la experiencia de usuario están en la infraestructura.
00:05:38Por eso los equipos de plataforma en muchas empresas impactan la calidad y el éxito del producto mucho más que antes.
00:05:50La mayoría en esta sala tenemos amplia experiencia en una, dos o tres capas.
00:05:54Podemos gestionar kernels o sus optimizaciones.
00:05:57Podemos gestionar el enrutamiento o el producto en sí.
00:05:59O podemos estar operando la infraestructura de GPU o el clúster.
00:06:03Pero muy pocos hemos operado la pila completa o pensado en ella de extremo a extremo.
00:06:08Como pueden ver, estas capas no son nuevas.
00:06:11Llevan existiendo 20 años o más.
00:06:13Lo nuevo es la combinación y el acoplamiento entre ellas.
00:06:18Una decisión en la capa de enrutamiento puede cambiar la tasa de aciertos de caché en el modelo, lo que cambia la composición del lote, la utilización de la GPU y la decisión de autoescalado.
00:06:32Así que todo está entrelazado.
00:06:33Ante regresiones en nuestras cargas de inferencia, no basta con entender la capa de caché o el control de admisión.
00:06:41Necesitamos pensar en la pila de arriba a abajo.
00:06:43Y ante un cuello de botella, es vital entender en qué capa se encuentra para invertir adecuadamente.
00:06:54Profundizando en cómo funciona un prompt, para cualquier aplicación —ya sea generar una imagen, una tarea de investigación o una orquestación multiagente compleja— el proceso involucra varios pasos.
00:07:08El prompt va al gateway.
00:07:10Luego va al enrutador, que consulta la caché si la solicitud ya se ha visto antes.
00:07:17Pasa a los planificadores, que deciden en qué clúster de GPU y en qué hardware debe ejecutarse.
00:07:22Puede ser en NVIDIA, AMD o un chip propio, e ir al entorno de ejecución adecuado: vLLM, SGLang, etc.
00:07:30Luego enviamos la respuesta al usuario según los SLO de tiempo al primer token y tiempo entre tokens, garantizando el rendimiento deseado.
00:07:41Como vemos, esta inferencia se comporta como una transacción distribuida.
00:07:45Cada flecha de este diagrama es un salto de red.
00:07:47Cada uno de estos saltos puede reintentarse.
00:07:50Puede agotar el tiempo de espera.
00:07:51Puede aplicar una alternativa.
00:07:53Incluso puede fallar.
00:07:54Y cada uno tendrá sus SLO mientras envía la respuesta en tiempo real al usuario.
00:08:00Así que si falla, la semántica de fallos parciales es mucho más difícil de gestionar que en una llamada RPC común.
00:08:06Piensen en qué pasa si ya hemos enviado 200 tokens al usuario y de repente un host GPU es desalojado por un evento de mantenimiento
00:08:15programado o no programado.
00:08:16No podemos simplemente reintentar.
00:08:17Tenemos que pensarlo holísticamente.
00:08:19Por esto mismo no podemos construir la confiabilidad en el extremo.
00:08:23Debe ser una propiedad del plano de control, que es el que ve todo el flujo de trabajo.
00:08:31Hablemos ahora de los planificadores y algunas optimizaciones, y cómo podemos abordarlos.
00:08:37En los microservicios tradicionales solíamos pensar en su empaquetado en tres o cuatro dimensiones.
00:08:43Podía ser memoria o CPU, o en cuatro dominios según si usaban AWS o proveedores de nube propios.
00:08:52Pero en inferencia, el planificador debe considerar al menos siete ejes al programar una solicitud.
00:08:59Debe tener en cuenta el tipo de GPU.
00:09:00Puede haber N tipos de hardware heterogéneo en su clúster (H100, E100, B200) con distintas topologías de red.
00:09:09Debe conocer el margen de HBM y el estado de la KV cache.
00:09:13Los pesos del modelo: si están cargados, si están fríos o ya están calientes para no iniciar en frío.
00:09:19Debe conocer la prioridad del inquilino.
00:09:21Puede haber N inquilinos ejecutándose en ese clúster multiinquilino con diferentes perfiles de SLO.
00:09:27También debemos considerar el contexto del flujo de trabajo.
00:09:30¿Estamos en el tercer paso de un razonamiento que ya gastó X dólares, o al inicio y podemos cancelar si estamos sobreabastecidos?
00:09:39También debemos pensar en el presupuesto de latencia según el tipo de aplicación agéntica.
00:09:44Esto nos lleva a la idea de implementar una planificación consciente del ámbito agéntico.
00:09:49Debemos asegurar que asignamos la tarea para que termine en el tiempo más rápido y económico, no en una GPU al azar.
00:09:58Un ejemplo concreto es que el planificador sepa que la solicitud R está en el paso tres de un flujo de cinco pasos,
00:10:05y que en los pasos uno y dos ya ha gastado X más Y dólares.
00:10:09Si el paso tres falla, todo el flujo se cancelará y habremos desperdiciado todos esos recursos de cómputo.
00:10:14Por eso la orquestación consciente del flujo de trabajo es sumamente importante,
00:10:18porque cambiará las decisiones de admisión, la prioridad y cómo reintentamos.
00:10:25Hablemos ahora de las optimizaciones.
00:10:27No profundizaré demasiado en muchas de ellas.
00:10:29Ya existe mucha investigación al respecto, pero me gustaría compartir un marco de trabajo
00:10:34que a mí me gusta utilizar y que podemos dividir en cuatro cuadrantes.
00:10:40Primero: ¿podemos evitar el trabajo?
00:10:42Es decir, ¿podemos omitirlo por completo usando caché de prefijos, de respuestas o semántica?
00:10:48Segundo: ¿podemos compartir el trabajo?
00:10:51¿Pueden varias solicitudes compartir cómputo agrupándolas por lotes?
00:10:54Piensen en loteo continuo, prefill-decode, chunked prefill o decodificación especulativa.
00:10:59Tercero: ¿podemos trasladar el trabajo?
00:11:01¿Podemos enviarlo a otro lugar, a un modelo más barato o más cerca del usuario?
00:11:05Principalmente mediante enrutamiento, ¿podemos dirigirlo a un modelo más pequeño, a una región más económica u otras técnicas?
00:11:12Y por último, ¿podemos posponer el trabajo?
00:11:13¿Podemos esperar a un mejor momento mediante control de admisión y colas, lo que exige entender las clases de prioridad de estas solicitudes e implementar una programación consciente de los plazos?
00:11:25Este marco es muy potente porque se traslada a diversos entornos.
00:11:29Puede que usen VLM, SGLang o TensorRT, pero cada técnica encaja en uno de estos cuadrantes.
00:11:35Así que siempre que pensemos en optimizar nuestro modelo, debemos comparar y contrastar con las técnicas anteriores
00:11:41y ver cómo se combinan entre sí.
00:11:47Ahora, cuando pensamos en escala, no solo importa el rendimiento del modelo.
00:11:51También debemos considerar el coste y la parte económica.
00:11:54Aquí es clave entender qué métrica intentamos optimizar.
00:11:58Porque el coste no es solo lo que cuesta la GPU o el modelo.
00:12:02Es el coste de todos estos parámetros, reintentos, almacenamiento, fallos, red y, por supuesto, el coste operativo del desarrollo y demás.
00:12:09Lo importante es entender cuál es el indicador clave de rendimiento de su producto que aportará valor a los usuarios.
00:12:17Por lo tanto, no se trata de optimizar solo el coste por token o por solicitud.
00:12:22Debemos optimizar el coste por tarea exitosa, porque eso es lo que realmente le importa a los usuarios.
00:12:26Y si logran optimizar eso, el coste general del producto disminuye y los usuarios están mucho más satisfechos.
00:12:36Hablemos ahora de confiabilidad y de lo que implica prevenir fallos en cascada.
00:12:43El problema no es que una GPU sea desasignada o falle.
00:12:46Lo interesante es el bucle de retroalimentación que ocurre después.
00:12:49Una GPU puede degradarse, la latencia aumenta, el cliente reintenta, la cola crece, las GPU sanas se saturarán, lo que provoca más reintentos y fallos regionales completos.
00:13:02Es el clásico fallo en cascada, pero con un matiz en aplicaciones generativas: la caché KV.
00:13:09No podemos simplemente reiniciar o redirigir el tráfico a otro clúster.
00:13:13Un clúster frío debe calentarse antes de recibir tráfico, y entretanto el clúster activo debe asumir todas esas solicitudes.
00:13:20Por eso es crucial diseñar los interruptores de seguridad de forma muy deliberada.
00:13:24Interruptores en la capa de enrutamiento, control de admisión (en lugar de solo encolar) y descarte de carga vinculado al tamaño de la cola, no solo al uso de CPU o memoria.
00:13:34Y también debemos considerar los límites de reintentos, porque de lo contrario los costes pueden dispararse rápidamente.
00:13:43Le cedo la palabra a mi compañero Naman para continuar con la presentación.
00:13:50Gracias.
00:14:20Le cedo la palabra a mi compañero Naman.
00:14:22Le cedo la palabra a mi compañero Naman.
00:14:25Le cedo la palabra a mi compañero Naman.
00:14:26Le cedo la palabra a mi compañero Naman.
00:14:27Le cedo la palabra a mi compañero Naman.
00:14:28Le cedo la palabra a mi compañero Naman.
00:14:29Le cedo la palabra a mi compañero Naman.
00:14:30Le cedo la palabra a mi compañero Naman.
00:14:31Le cedo la palabra a mi compañero Naman.
00:14:32Le cedo la palabra a mi compañero Naman.
00:14:33Le cedo la palabra a mi compañero Naman.
00:14:34Le cedo la palabra a mi compañero Naman.
00:14:35Le cedo la palabra a mi compañero Naman.
00:14:36Le cedo la palabra a mi compañero Naman.
00:14:54Vale, supongo que esto funciona.
00:14:57Perdón por la interrupción.
00:14:58Una vez que la inferencia alcanza escala de producción,
00:15:00empieza a parecerse mucho más a un sistema distribuido.
00:15:03Ya no estamos simplemente llamando a un modelo.
00:15:06Es más bien un problema clásico de sistemas distribuidos.
00:15:09En sistemas distribuidos, hablamos de colas, planificación,
00:15:13escalado automático e aislamiento de fallos.
00:15:14Estas son algunas de las dimensiones.
00:15:16La inferencia tiene todos estos problemas,
00:15:18pero ahora existen nuevas restricciones.
00:15:20En lugar de solo CPU y memoria, tenemos CPU, HBM, caché KV,
00:15:25y el coste por tarea exitosa.
00:15:27Así que la pregunta operativa pasa a ser:
00:15:28¿cómo sabe la plataforma qué hacer a continuación?
00:15:31Y ahí es donde entra en juego la observabilidad.
00:15:34No se trata solo de paneles de control.
00:15:35Se trata de proporcionar señales de entrada al bucle de control.
00:15:39Telemetría, campos, análisis... los análisis impulsan las decisiones,
00:15:43los problemas y los cambios de planificación y enrutamiento,
00:15:45y finalmente, simplemente repetimos el proceso.
00:15:47Daré una visión general de las métricas más importantes.
00:15:50La primera es el tiempo hasta el primer token,
00:15:52que indica cuánto tiempo se tarda realmente
00:15:56en obtener la primera respuesta.
00:15:58Luego tenemos la tasa de utilización,
00:16:00que señala si el cuello de botella es la memoria o el cómputo.
00:16:04Tenemos el éxito por dólar, que nos indica
00:16:06si la plataforma realmente está cumpliendo
00:16:08y funcionando de manera eficiente.
00:16:10Y finalmente, la latencia de extremo a extremo,
00:16:12que nos muestra el tiempo transcurrido
00:16:15a lo largo de toda la ruta de la solicitud.
00:16:19Existe un compromiso fundamental entre latencia, coste y rendimiento.
00:16:22No se pueden obtener todos a la vez.
00:16:24Es muy similar al teorema CAP.
00:16:26Si aumento el tamaño del lote,
00:16:28mejoro el rendimiento y la eficiencia de costes,
00:16:31pero puedo perjudicar la latencia máxima.
00:16:33Si uso decodificación especulativa,
00:16:35puedo mejorar la latencia, pero a costa de cómputo extra.
00:16:38En última instancia, como saben, aumenta el coste por token.
00:16:41Y finalmente, puedo usar un modelo simple y más pequeño.
00:16:44Puedo reducir la latencia y el coste,
00:16:45pero la respuesta será de menor calidad.
00:16:48Al final, tendré que analizar fallos y reintentar,
00:16:50lo que vuelve a elevar el coste.
00:16:52Por lo tanto, cada decisión de servicio mueve
00:16:54al sistema a algún punto de este triángulo.
00:16:56Y nuestro trabajo es encontrar la configuración perfecta.
00:16:58Ahora es simplemente un problema de optimización.
00:17:03Hacia aquí se dirige la industria en este momento.
00:17:05La inferencia necesita su propio plano de control.
00:17:07Todo lo que discutimos (enrutamiento, procesamiento por lotes, caché,
00:17:10planificación y confiabilidad)
00:17:12ya no puede ser un ajuste independiente.
00:17:15Están convergiendo en una capa lógica.
00:17:17Llamémosla plano de control de inferencia.
00:17:19Antes gestionábamos máquinas virtuales en sistemas distribuidos.
00:17:21Tenemos planificadores de autoescalado.
00:17:23Y teníamos Kubernetes, que convirtió esto en un plano de control.
00:17:27La inferencia está pasando por la misma transición ahora.
00:17:30Los modelos se están convirtiendo en recursos.
00:17:32GPU, caché KV, tokens, latencia y costes ahora se planifican conjuntamente.
00:17:36El plano de control decide qué modelos atienden qué solicitud
00:17:40y cómo se agrupan en lotes.
00:17:42Así que, ya sea que construyamos esta capa internamente,
00:17:44usemos código abierto o soluciones de un proveedor,
00:17:46el diseño clave es asumir que esta capa existirá.
00:17:50Analicemos ahora si algunas lecciones operativas
00:17:53que hemos aprendido en infraestructura de IA
00:17:55son aplicables en este contexto.
00:17:57La primera lección es que los cuellos de botella de infraestructura
00:18:00suelen aparecer antes que los del modelo.
00:18:02En producción pueden surgir muchos fallos,
00:18:04pero pueden deberse simplemente a la planificación, el enrutamiento
00:18:07o a caídas de capacidad.
00:18:08Por lo tanto, no están relacionados con la inferencia.
00:18:10Son problemas de infraestructura.
00:18:12Luego está la elasticidad.
00:18:14Necesitamos elasticidad en el sistema.
00:18:15Podemos añadir más GPU, pero esto no resolverá realmente el problema.
00:18:18Solo estaríamos ocultándolo.
00:18:20Además, nuestra solución de programar las decisiones
00:18:24supera la eficiencia bruta.
00:18:26El mismo conjunto de recursos puede rendir de forma óptima
00:18:28según cómo se planifique
00:18:30o cómo se agrupen los lotes.
00:18:31Luego tenemos los bucles de control, que superan a los procesos manuales.
00:18:35La plataforma debe percibir, detectar
00:18:37y adaptarse automáticamente al sistema.
00:18:39Así que la conclusión principal es: no optimicen para tokens.
00:18:43Optimizan para tareas exitosas.
00:18:48Este es el cambio más amplio con el que quiero dejarlos.
00:18:51La primera fase de la infraestructura de IA se centró en mejores modelos.
00:18:54Invertimos mucho tiempo en mejorar nuestros modelos,
00:18:56en hacerlos más inteligentes
00:18:58y en definir mejores evaluaciones comparativas.
00:19:00La fase actual busca una inferencia más rápida,
00:19:03menor latencia, mejor procesamiento por lotes
00:19:05y un mejor aprovechamiento de la GPU.
00:19:08Pero la siguiente fase trata sobre la orquestación.
00:19:10Es decir, la GPU, la memoria, la caché y todo lo demás
00:19:13son solo recursos,
00:19:14y deben ser planificados y controlados.
00:19:17Los equipos que entiendan esto desde el principio
00:19:19construirán la infraestructura del futuro.
00:19:21Así pues, la idea final es:
00:19:23la infraestructura ya no es un problema de servicio de modelos.
00:19:25Es un problema de orquestación.
00:19:27Gracias.
00:19:29Muchas gracias.

핵심 요약

La inferencia a gran escala ha dejado de ser un problema de optimización de modelos para convertirse en un desafío de orquestación de sistemas distribuidos donde se debe optimizar el coste por tarea exitosa mediante un plano de control unificado.

하이라이트

  • La demanda agéntica cambia el escalado lineal: un chatbot realiza 1 llamada por turno, los copilotos de 10 a 20, los agentes de investigación 50, y los sistemas autónomos miles.

  • Un fallo de GPU durante la fase de decodificación provoca la pérdida de miles de tokens en vuelo y genera acumulaciones masivas en cola.

  • De todas las etapas en una solicitud agéntica, la GPU solo interviene en una: la ejecución de pre-fill y decode.

  • El planificador de inferencia debe evaluar al menos siete ejes simultáneamente: tipo de GPU, margen de HBM y caché KV, estado de los pesos del modelo, prioridad del inquilino, contexto del flujo, presupuesto de latencia y ámbito agéntico.

  • El marco de optimización de inferencia se divide en cuatro estrategias: evitar trabajo (cachés), compartir trabajo (batching continuo), trasladar trabajo (enrutamiento) y posponer trabajo (control de admisión).

  • El trilema fundamental de la inferencia exige equilibrar latencia, coste y rendimiento, donde optimizar una variable perjudica inevitablemente a las otras.

타임라인

Evolución de la infraestructura de IA y la explosión agéntica

  • El tráfico de inferencia supera al de los microservicios tradicionales más grandes del mundo y presenta el ritmo de crecimiento más rápido registrado en infraestructura.
  • La arquitectura de IA comprime en pocos años la evolución de la nube, desplazando el valor desde la ejecución en GPU hacia la capa de orquestación en tiempo real.
  • Las cargas de trabajo agénticas rompen la planificación de capacidad lineal al multiplicar usuarios, llamadas por usuario y tokens procesados.

La infraestructura de IA replica la trayectoria histórica de la nube al mover su foco desde la virtualización inicial hacia los planos de control y orquestación. A diferencia del servicio web clásico donde el escalado guarda relación directa con los usuarios, las aplicaciones agénticas generan patrones de consumo impredecibles al realizar desde decenas hasta miles de llamadas al modelo por cada interacción.

Diferencias estructurales entre microservicios e inferencia de LLM

  • Las solicitudes de LLM varían entre 50 y 100.000 tokens con perfiles computacionales opuestos entre la fase de pre-fill y la de decode.
  • El estado de la caché KV resulta extremadamente costoso de construir y desechar, impidiendo el tratamiento sin estado de las peticiones.
  • Las GPU son 100 veces más costosas y 10 veces más lentas de adquirir que las CPU, lo que impide el sobredimensionamiento de flota.

El servicio de modelos de lenguaje exige procesamiento por lotes continuo en vuelo para evitar caídas de rendimiento de un orden de magnitud. Ante fallos de hardware, los arranques en frío prolongados y la pérdida de tokens en proceso impiden aplicar estrategias convencionales de reinicio de contenedores, trasladando el cuello de botella desde el modelo hacia la orquestación.

Anatomía de la solicitud y planificación multidimensional

  • El procesamiento de un prompt funciona como una transacción distribuida donde solo un paso requiere la ejecución directa del modelo.
  • Los cambios en la capa de enrutamiento alteran la tasa de aciertos de la caché, la composición del lote, la utilización de la GPU y las decisiones de autoescalado.
  • La planificación agéntica debe priorizar la finalización de flujos de múltiples pasos para evitar el desperdicio de recursos invertidos en etapas previas.

Casi la totalidad del recorrido de una solicitud —autenticación, selección de región, control de admisión, consulta de caché y agrupación— corresponde a tareas de infraestructura. Dado que cada salto de red puede fallar o agotar el tiempo de espera, la confiabilidad debe programarse como una propiedad central del plano de control y no como una solución periférica.

Estrategias de optimización y prevención de fallos en cascada

  • Las optimizaciones de inferencia se agrupan en evitar, compartir, trasladar o posponer el trabajo computacional.
  • La métrica de negocio relevante para la eficiencia económica es el coste por tarea exitosa y no el coste por token.
  • Los fallos en cascada en LLM se amplifican debido a la necesidad de calentar la caché KV en clústeres secundarios antes de recibir tráfico.

El control de fallos en sistemas de generación exige implementar interruptores de seguridad conscientes del tamaño de la cola y no solo de la CPU o memoria. Cuando una GPU se degrada, el aumento de latencia desencadena reintentos masivos que pueden colapsar regiones enteras si el control de admisión no descarta carga de forma deliberada.

Observabilidad, compromisos de diseño y el plano de control de inferencia

  • El trilema operativo de la inferencia obliga a negociar constantemente entre latencia, coste y rendimiento.
  • Las capas de enrutamiento, batching, caché, planificación y confiabilidad están convergiendo en un plano de control lógico unificado.
  • La toma de decisiones de planificación automatizada mediante bucles de control supera la eficiencia computacional bruta del hardware.

La inferencia moderna opera bajo restricciones compuestas de CPU, memoria HBM, caché KV y límites presupuestarios. Las métricas clave como el tiempo al primer token, la utilización de memoria frente a cómputo y el éxito por dólar alimentan bucles de control automáticos que adaptan el sistema dinámicamente, consolidando a los modelos como meros recursos programables.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기