Llevar las pasarelas de LLM a producción: arquitectura, sacrificios y duras lecciones — Kanish Manuja, Twilio
AAI Engineer
Computing/SoftwareManagementInternet Technology
Transcript
00:00:00Soy Ganesh Manuja. Soy ingeniero principal en Twilio. Comencemos con un breve espectáculo de manos.
00:00:20¿Quién de aquí ha visto el mensaje de algo salió mal, por favor inténtalo de nuevo?
00:00:27Bueno, tenemos algunos afortunados y otros que han almorzado muy bien.
00:00:33Entonces, detrás de ese mensaje simple hay en realidad un sistema muy complejo que les muestra ese mensaje a pesar de que los proveedores de modelos estén caídos.
00:00:45Y eso es lo que vamos a llevar a producción hoy o a discutir sobre llevarlo a producción hoy.
00:00:50Entonces, ¿qué es una pasarela de LLM?
00:00:52Una pasarela de LLM es un punto de entrada o un intermediario entre sus aplicaciones y los proveedores de modelos detrás de ellas.
00:00:58Hace un montón de cosas: enrutamiento, autenticación, respaldo, límites de tasa, todo tipo de gobernanza que se puedan imaginar.
00:01:08Y justo en el corazón de la pasarela hay una lucha entre cuatro cosas.
00:01:13Son la disponibilidad, la latencia, sus protecciones y los costos.
00:01:18En caso de una degradación, no se pueden maximizar las cuatro.
00:01:22Necesitan elegir qué es lo que quieren.
00:01:25Por eso, con esta charla, si usas una pasarela de LLM, quiero ayudarte a tomar esa decisión de compromiso para tu caso de uso.
00:01:35Y si diseñan una pasarela, quiero que diseñen o proporcionen esas palancas a sus usuarios y clientes para que sus clientes estén contentos.
00:01:46Comencemos con la disponibilidad.
00:01:50Si tienen un único proveedor de modelos, el límite de ellos es el límite de ustedes.
00:01:56Su interrupción es la interrupción de ustedes.
00:02:03Entonces, en la ingeniería de software típica, la forma en que se aborda una dependencia poco fiable es reintentando.
00:02:11Reintentando con retrocesos exponenciales, con fluctuaciones.
00:02:15Y cuando todo eso falla, tienen un cortacircuitos que se activa después de haber visto suficientes fallos, y dejan de llamar a esa maldita cosa.
00:02:24Esto no es suficiente para los LLM.
00:02:26Los LLM son muy diferentes en comparación con sus API rápidas y baratas en las que se reintenta.
00:02:32Reintentar una API de LLM consume su presupuesto de latencia muy rápido.
00:02:38Y también, activar un cortacircuitos cuando se tiene otro proveedor de modelos perfectamente bueno al cual enrutar no tiene sentido.
00:02:47Deberían usar el segundo proveedor de modelos.
00:02:48Y tercero, como dije, las llamadas son lentas y caras.
00:02:53Por lo tanto, los reintentos a ciegas simplemente multiplican su costo y sus latencias de cola.
00:02:58Entonces, ¿cuál es una mejor idea aquí?
00:03:02En realidad es una alternativa por solicitud.
00:03:05Lo que eso significa es que de hecho pueden probar el proveedor de modelos A y luego, en secuencia, probar el proveedor de modelos B si su solicitud al proveedor de modelos A falla.
00:03:14Otra opción a considerar aquí es que pueden enviar solicitudes a ambos proveedores en paralelo, pero eso es solo si están alta, altamente obsesionados con las latencias, porque eso simplemente duplicará su costo.
00:03:26Algunos de los patrones similares de cortacircuitos se aplican aquí a los LLM también.
00:03:32Si saben que su primario ha estado fallando durante algún tiempo, no tiene sentido intentarlo de nuevo.
00:03:40Lo sacan del balanceador de carga o de su ruta de solicitudes y lo ponen en un período de enfriamiento y luego, después de unos minutos, intentan volver a ponerlo.
00:03:51Una elección interesante que tienen que hacer aquí es dónde viven sus conteos de fallos.
00:03:59Pueden decidir que los conteos de fallos vivan en la memoria en las instancias que atienden su tráfico, o pueden tener información compartida donde sus conteos de fallos se compartan en toda la flota.
00:04:12Hay contrapartidas.
00:04:14Si quieren conmutaciones por error rápidas, entonces el nivel de toda la flota ayuda.
00:04:19Y con la instancia, con los contadores de estado local, el problema con el que se encuentran es que cada vez que cambian el tamaño de su implementación, su configuración y sus expectativas cambian.
00:04:30Así que es algo a considerar.
00:04:34Lo que ese diagrama limpio realmente no les mostró son algunas de las otras trampas de las que voy a hablar.
00:04:39Por lo tanto, las alternativas no son transparentes.
00:04:41Si bien la industria está convergiendo en un formato compatible con la API de OpenAI, diría que todavía hay matices.
00:04:49Así que realmente necesitan probar bien sus alternativas.
00:04:52Pueden tener diferencias en sus esquemas de llamadas a herramientas, límites de tokens, razones de parada y lo que surja.
00:04:58Así que con las pasarelas de LLM, pueden tener una capa de normalización que garantice que también puedan realizar alternativas entre proveedores.
00:05:08Otra cosa es el streaming.
00:05:15Básicamente, nadie quiere esperar 30 segundos para que aparezca una pared de texto frente a ellos.
00:05:22Así que hay casos de uso donde el streaming es absolutamente necesario.
00:05:26Pero viene con un costo.
00:05:27Renuncian a sus palancas.
00:05:29No pueden -- una vez que han decidido ir con el Proveedor A, tienen que seguir yendo con el Proveedor A.
00:05:36No pueden cambiar de proveedor a mitad de transmisión.
00:05:39Todo lo que se le ha enviado al cliente, ya está hecho.
00:05:42Y ahí es donde aparece el mensaje de algo salió mal.
00:05:46Ese es el que ven.
00:05:48No es por pereza.
00:05:49Es por diseño que ven eso.
00:05:52Y es una de las contrapartidas.
00:05:54Me gustaría señalar otra cosa en la que he visto a los equipos tropezar una y otra vez.
00:06:00Realmente aprovisionan y prueban muy bien a sus proveedores principales.
00:06:05Pero el segundo proveedor, el proveedor alternativo, no recibe necesariamente el mismo nivel de cariño.
00:06:11Y yo diría que sus rendimientos, su capacidad o su margen deberían ser aún mayores para el segundo proveedor o el proveedor alternativo.
00:06:21Porque esa es su última línea de defensa.
00:06:23Si eso cae, su aplicación cae.
00:06:29Hablemos de las latencias.
00:06:31Los fallos de disponibilidad están enfrente de ustedes.
00:06:34Fallan.
00:06:36Reciben una alarma.
00:06:37Les llaman.
00:06:38Pero las latencias altas pueden ser las silenciosas.
00:06:42Y necesitan recibir más cariño que, diría yo, ajustar sus servicios solo para la disponibilidad.
00:06:49Una cosa que hay que señalar.
00:06:54Una pasarela puede ejecutar cargas de trabajo mixtas.
00:06:58Y se pueden tener solicitudes de incrustación que toman poco menos de un segundo.
00:07:04Se pueden tener solicitudes de clasificación que toman menos de un segundo.
00:07:07Tienen solicitudes de chat que toman tres segundos.
00:07:10Y solicitudes de razonamiento que toman mucho tiempo.
00:07:13Breve espectáculo de manos.
00:07:15Breve espectáculo de manos si miden su latencia agregada para todo su servicio.
00:07:20Bueno, esa fue una pregunta con trampa.
00:07:23Lo siento.
00:07:24No deberían.
00:07:25No tiene sentido.
00:07:26Es una mentira.
00:07:27Deberían estar rastreando su P99 por modelo por ruta, no un número de toda la pasarela.
00:07:32Un número de toda la pasarela no tiene sentido, especialmente si están ejecutando cargas de trabajo mixtas.
00:07:36Y espero que no lo hagan, para aquellos que levantaron la mano.
00:07:40Otra cosa que realmente -- no puedo enfatizar esto lo suficiente es que configuren tiempos de espera por clase de modelo por ruta.
00:07:49Ahí es donde -- esa es la causa principal número uno de su interrupción silenciosa.
00:07:54Si no tienen un tiempo de espera, su pasarela piensa que su solicitud está siendo atendida felizmente, cuando no es así.
00:08:00Y los dejaré con este mensaje para las latencias, específicamente.
00:08:05Lo normal de un modelo de razonamiento es en realidad la interrupción de un modelo de chat.
00:08:09Así que definitivamente necesitan rastrear la latencia por ruta.
00:08:13Bien, esta es la más dolorosa o la diapositiva que me ha causado más sustos, que trata sobre los modelos de razonamiento y enrutador.
00:08:24Así que aquí es donde realmente la latencia es impredecible.
00:08:29Y los modelos de razonamiento, no les dan -- son altamente no deterministas, más no deterministas que sus modelos normales.
00:08:40No se puede configurar la temperatura a cero en muchos casos.
00:08:43Y la misma indicación puede tomar desde dos segundos hasta 60 segundos.
00:08:48Y hemos visto eso en producción, donde el P99 de repente saltó a 60 segundos sin una buena razón.
00:08:53Así que eso -- aunque no hay una solución mágica para ello, recomendaría que al menos comiencen por arreglar el nivel de razonamiento por ruta.
00:09:03Así que con los modelos enrutadores, ocultan esa abstracción detrás de ustedes.
00:09:08Por ejemplo, eligen qué modelos ejecutar.
00:09:11Y recomendaría encarecidamente que al menos hagan tanto -- hagan que las solicitudes sean lo más deterministas posible con un sistema no determinista.
00:09:23Otra idea es cubrir la cola.
00:09:26Pueden tener un -- pueden disparar otra solicitud si su solicitud principal realmente consumió, digamos, el P90 de su presupuesto de latencia.
00:09:37Esto puede cubrir la -- esto realmente puede cubrir la cola P99 para sus servicios.
00:09:44Muy bien, esta es una de mis favoritas.
00:09:47Para mantener seguros sus modelos, necesitan tener protecciones.
00:09:53Y con eso, las protecciones son necesarias para evitar que sus servicios sufran ataques de inyección de instrucciones, mantener filtros de PII en su lugar, tener filtros de toxicidad, evitar que los LLM dejen de insultar a sus clientes.
00:10:08Todas esas cosas buenas.
00:10:11Pero al igual que un proveedor de modelos, también hay contrapartidas.
00:10:15Las protecciones son como cualquier otro servicio.
00:10:18Eso puede caerse.
00:10:19Eso puede ser poco fiable.
00:10:21Y ahí es donde necesitan elegir.
00:10:24¿Fallan abierto o fallan cerrado?
00:10:27Cuando digo fallar abierto, aún pueden atender la solicitud incluso si sus protecciones están caídas.
00:10:32Fallar cerrado, bloquean la solicitud y dicen, oigan, no estoy disponible.
00:10:36Ese es el equilibrio entre disponibilidad y seguridad hasta cierto punto.
00:10:41Aunque no hay una respuesta universal, realmente depende de tu caso de uso.
00:10:45Puedes decidir que, por ejemplo, con un filtro de toxicidad, si no está operativo, aun así puedes atender la solicitud.
00:10:53Así que la opción predeterminada debería ser el peor escenario que puedas tolerar.
00:11:02Hay algunas cosas que puedes hacer para mejorar el comportamiento de tus sistemas cuando los mecanismos de protección fallan y para gestionar su propia inestabilidad.
00:11:17La primera es el presupuesto de tiempo.
00:11:20Tus solicitudes nunca deben estar limitadas por el tiempo de tus filtros de protección.
00:11:25El modelo de lenguaje siempre debe ser el paso que determine la velocidad.
00:11:29Así que asegúrate de establecer tiempos de espera y de que esos filtros se ejecuten con un presupuesto de tiempo específico.
00:11:38Otra cosa importante son las alternativas o respaldos.
00:11:40Ya habrás oído —probablemente lo sepas y yo lo he comentado— que siempre discutimos sobre alternativas en cuanto a los proveedores de modelos.
00:11:47Pero los filtros de protección también son servicios críticos donde puedes considerar alternativas, tener proveedores secundarios, controles secundarios y almacenar decisiones en caché para mantener tu servicio disponible cuando un proveedor de filtros falle.
00:12:03Otra opción interesante que surge con respecto a los filtros de protección es su ubicación.
00:12:10Por lo general, puedes ubicar los filtros de tres maneras.
00:12:15Puedes usar una función previa que se ejecute sobre los datos de entrada.
00:12:19Probablemente sea la más segura, pero añade latencia en serie a tus solicitudes.
00:12:26Otra opción es en paralelo.
00:12:29Esta es una de mis favoritas, pero cabe destacar que el streaming no funciona muy bien aquí con el procesamiento en paralelo.
00:12:35Así que si estás produciendo resultados estructurados de manera especial, por favor no uses streaming.
00:12:40Intenta ahorrar latencias y ejecuta estos filtros de forma concurrente para tus salidas estructuradas.
00:12:46Otra opción son las funciones posteriores.
00:12:48Estas son ideales para supervisar las respuestas, auditar los resultados y demás.
00:12:58Hasta ahora, he comentado todas las cosas que pueden salir mal con respecto a nuestras dependencias.
00:13:06No hemos comentado que en realidad estamos añadiendo otra dependencia en la ruta de la solicitud, que es la pasarela central o la pasarela de modelos de lenguaje en sí.
00:13:15Hay algunas situaciones en las que hemos sufrido problemas y hemos aprendido lecciones que quiero compartir contigo si estás trabajando en una pasarela de modelos o utilizando una.
00:13:25Una de ellas son los límites compartidos.
00:13:28Asegúrate de que tus claves de API estén separadas por ruta y por caso de uso, de la forma más detallada posible que puedas imaginar.
00:13:40Tener un inquilino ruidoso puede ser uno de los mayores problemas aquí.
00:13:47Otra cuestión es la reducción de carga.
00:13:50Esta es una característica que debes asegurarte de que la pasarela que utilices soporte, como parte de tus manuales de procedimientos y simulacros.
00:13:59Porque cuando se produce una avalancha de reintentos, resulta muy difícil simplemente escalar horizontalmente.
00:14:03No puedes simplemente ampliar los servicios que están sufriendo una avalancha de reintentos.
00:14:07Y todos estos servidores web tienen una cola interna que se puede configurar.
00:14:13Asegúrate de que tengan límites y de que no acepten solicitudes ilimitadas.
00:14:19Y si quieres implementar cierta lógica personalizada, incluso puedes establecer una priorización del tráfico aquí para asegurarte de que, bajo carga, tus casos de uso más importantes se atiendan correctamente.
00:14:29Lo último que quiero comentar es toda la idea de tener una pasarela central.
00:14:38Es un punto único de fallo.
00:14:40Así que si estás pensando en tener una pasarela central para toda tu empresa para dos modelos de lenguaje, te recomendaría que lo reconsideres y analices cuáles son las razones por las que la quieres.
00:14:52Lo que he notado es que, en la mayoría de los escenarios, lo que buscan no es una pasarela central.
00:14:57Lo que quieren es una gobernanza centralizada.
00:15:00Y hay un camino a seguir mediante el cual puedes descentralizar la pasarela y aun así centralizar la gobernanza.
00:15:07Por lo tanto, no intentes centralizar tu tráfico, sino que puedes utilizar complementos o código personalizado que centralicen tu gobernanza.
00:15:17La gobernanza puede adoptar la forma de control de costos, gestión de límites de velocidad y existen otras soluciones posibles.
00:15:24Así que explora esas opciones antes de lanzarte a tener una sola pasarela central para toda tu empresa.
00:15:30Puede ser administrada por un solo equipo, pero no recomendaría desplegarla como un único despliegue para toda la empresa, aunque esté distribuida.
00:15:43Dicho esto, quiero terminar esta charla con una nota personal.
00:15:47Hoy es el cumpleaños de mi hijo y estoy aquí hablando con extraños sobre interruptores automáticos.
00:15:54Así que lo mínimo que pueden hacer por mí es ir y prevenir un incidente para mí y para sus clientes.
00:16:02Gracias.
00:16:03Si tienen alguna pregunta, adelante.
00:16:06.