Este artículo se basa en el discurso "Kitex Thrift Streaming implementado en escenarios de IA" de Du Shaofeng, ingeniero de I+D de ByteDance-Flow, en el evento "Cloud Native✖️Arquitectura de microservicios y práctica técnica en la era de la IA" del Salón de Tecnología CloudWeGo celebrado en Beijing. en Beijing el 30 de marzo de 2024. Compilado de "Práctica".
Descripción general
La plataforma ByteDance Prompt tiene como objetivo proporcionar a los usuarios funciones integrales de desarrollo, ajuste, evaluación y ciclo de vida completo de aplicaciones de Prompt. Entre estas capacidades, la transmisión de resultados de modelos grandes para efectos de máquina de escribir es una característica crucial. Aunque la implementación basada en SSE (Server-Sent Events) es factible, requiere escritura adicional de servicios HTTP, lo que aumenta la complejidad del desarrollo. Aunque el método de encuesta es simple, la experiencia del usuario no es la ideal y parece demasiado torpe. En cuanto a gRPC, aunque su rendimiento es excelente, puede introducir problemas de compatibilidad, complicando la implementación y el mantenimiento. Por lo tanto, hemos implementado con éxito la interfaz de transmisión con la ayuda de la capacidad de transmisión Thrift de Kitex, brindando así a los usuarios una experiencia de salida de resultados de modelos grandes con efecto de máquina de escribir fluida y eficiente.
1. Antecedentes comerciales
Con el continuo desarrollo de la tecnología de IA, la vida de las personas está experimentando cambios profundos. Tomemos como ejemplo el producto de inteligencia artificial de Byte, Doubao. Los agentes que contiene han brindado muchas experiencias novedosas a las personas. Entre ellos, los robots inteligentes interesantes como AI boyfriend y AI novia son particularmente populares. No solo pueden interactuar con los usuarios de manera humorística, sino que también muestran un lado amable y considerado.
Todo esto es inseparable de un concepto estrechamente relacionado con los grandes modelos: los avisos. En pocas palabras, Prompt es la entrada de texto al modelo previamente entrenado para guiarlo a generar una salida de texto que satisfaga necesidades específicas. En sentido figurado, Prompt es como crear un sueño exclusivo para el gran modelo. A través de él, podemos guiar al gran modelo para que brinde respuestas más apropiadas y específicas en escenarios específicos.
Tomando a la novia AI como ejemplo, le diremos a la modelo grande a través de indicaciones cuidadosamente diseñadas que su papel es el de una novia virtual amable y considerada. Al mismo tiempo, también estableceremos algunas restricciones, como exigirle que se comunique con los usuarios de manera amable y considerada, y que tenga habilidades como escuchar, comprender, alentar y hacer sugerencias. Además, también describiremos su flujo de trabajo en detalle, como guiar a los usuarios para que digan sus nombres al saludar, darles un apodo adecuado y luego llevar a cabo una comunicación profunda con los usuarios y brindarles sugerencias útiles.
A través de tales indicaciones, construimos un "sueño" completo para el modelo grande, permitiéndole comprender que es una novia de IA y cómo debe interactuar con los usuarios. Cuando se activa este mensaje, cuando tengamos una sesión de preguntas y respuestas con el modelo grande, dará las respuestas correspondientes según nuestras indicaciones. Por ejemplo, cuando lo saludamos, nos guía para decir nuestro nombre, nos pone un lindo apodo y luego nos da aliento y alivio.
Como se puede ver en este ejemplo, Prompt juega un papel decisivo en la salida de modelos grandes en escenarios específicos. Además, también afectará el consumo de tokens y el tiempo de respuesta de modelos grandes durante el proceso de salida. Por lo tanto, un mensaje excelente es crucial para mejorar la salida del modelo.
2. Escenarios de demanda
El equipo de ByteDance Flow está trabajando para construir una plataforma/método integral y maduro diseñado para ayudar a los desarrolladores de mensajes a diseñar, iterar, evaluar y optimizar sus mensajes, mejorando así la expresividad de LLM (modelo de lenguaje grande). Durante la fase de desarrollo, planeamos proporcionar generación estructurada y generación guiada para ayudar a los usuarios a escribir indicaciones eficientes y precisas y a depurar en consecuencia.
A medida que avance el desarrollo, introduciremos más tecnologías de ajuste automático como COT (Cadena de pensamiento) y Few shots, así como el método APO (Optimización automática de avisos) para ayudar a Prompt a mejorar la precisión de sus respuestas. Al mismo tiempo, también brindaremos la capacidad de ampliar las indicaciones para optimizar la eficiencia de los modelos grandes en el consumo de tokens.
Además, para evaluar exhaustivamente la eficacia de Prompt, calificaremos a Prompt en función de diversos conjuntos de datos y realizaremos un análisis en profundidad de sus cuellos de botella de rendimiento para realizar mejoras específicas. Con el tiempo, proporcionaremos capacidades de implementación con un solo clic, lo que permitirá a los desarrolladores integrar fácilmente las capacidades de Prompt y los grandes modelos detrás de ellas en sus aplicaciones.
Por supuesto, la realización de estas funciones es inseparable del soporte de la tecnología
de transmisión en tiempo real
. Al igual que las capacidades de IA que ha experimentado, como GPT, Doubao y Baidu AI Search, todas utilizan respuestas estilo máquina de escribir después de que los usuarios hacen preguntas, lo que les permite sentir que los datos fluyen constantemente hacia la pantalla, mejorando así la fluidez. de chatear y velocidad de respuesta. Esta tecnología
de transmisión en tiempo real
es la capacidad más básica que nuestra plataforma Prompt debe ofrecer. Al dividir los datos en múltiples flujos de datos para la transmisión de la red, podemos reducir efectivamente la latencia de la red, mejorar el rendimiento y garantizar que los usuarios tengan una mejor experiencia al interactuar con modelos de lenguaje grandes.
3. Solución
Para implementar la función de salida de streaming, realizamos una investigación en profundidad y consideramos una variedad de opciones:
-
votación
-
HTTP SSE
-
Transmisión de Kitex gRPC (protobuf)
-
Transmisión de ahorro de Kitex
En primer lugar, el sistema de votación fue excluido debido a su naturaleza inflexible y no satisfacía nuestras necesidades. En segundo lugar, aunque el SSE basado en HTTP es una solución factible, considerando que también tenemos requisitos estrictos para RPC (llamada a procedimiento remoto), también necesitamos encontrar una solución más adecuada. Además, descubrimos que el soporte de transmisión del protocolo Protobuf no satisfacía completamente nuestras necesidades, especialmente en términos de la interfaz Thrift. Finalmente, notamos el soporte de Kitex para Thrift Streaming. En ese momento, Kitex Thrift Streaming estaba en la etapa de desarrollo y decidimos decisivamente convertirnos en sus primeros usuarios y construir el marco básico de toda la plataforma Prompt en base a él.
En términos de diseño de arquitectura, primero evaluamos LangChain y establecimos servicios de ingeniería LLM. Sobre esta base, desarrollamos aún más el servicio Prompt para proporcionar las capacidades de aplicación y administración de Prompt más básicas. Para interactuar con el front-end, proporcionamos una interfaz HTTP a través de API Gateway. En términos de comunicación entre microservicios, utilizamos el marco Kitex para brindar soporte para interfaces de transmisión e interfaces que no son de transmisión para garantizar una transmisión y procesamiento eficiente de datos.
A través de esta solución, implementamos con éxito la función de salida de streaming, brindando a los usuarios una experiencia de interacción con IA más fluida y eficiente. Al mismo tiempo, también hemos sentado una base sólida para futuras expansiones y optimizaciones.
4. Práctica y trampas
-
Proceso de llamada en streaming
El proceso de llamada en streaming comienza cuando el usuario inicia una pregunta. Esta solicitud se envía primero a la puerta de enlace, que luego establece una conexión con la interfaz Prompt RPC descendente. La interfaz Prompt RPC establece además comunicación con el servicio de ingeniería LLM, que es responsable de interactuar continuamente con el modelo y obtener los resultados del modelo. Estos resultados se transmiten hacia arriba capa por capa en forma de transmisión hasta que llegan a la capa de puerta de enlace y finalmente se muestran al usuario en forma de transmisión.
Durante este proceso, escribimos una interfaz de transmisión en el servicio Prompt para manejar llamadas de transmisión. La interfaz primero establece una conexión con el flujo descendente llamando a la interfaz descendente, y luego recibe continuamente el resultado del paquete de transmisión que nos escupe el flujo descendente a través de un bucle for. Una vez que se recibe el paquete de datos, lo transmitimos de forma transparente a la capa superior a través del método de envío hasta que se encuentra un error o se cierra la transmisión y el ciclo finaliza.
Durante el proceso de implementación, experimentamos la simplicidad de Kitex Thrift Streaming. Sin embargo, también encontramos algunos problemas. Especialmente en términos de manejo de errores, descubrimos que el código no pudo obtener los resultados esperados durante la ejecución e incluso provocó una carga excesiva de la CPU.
Después de un análisis más detallado de los registros de errores, descubrimos que había mensajes de error en solicitudes individuales, específicamente en relación con el problema del límite de QPM (consulta por segundo) para el primer paquete. De acuerdo con la lógica de nuestro código, debemos salir rápidamente del bucle for cuando encontramos tales errores, pero esta no es la situación real. Entonces, comenzamos a utilizar los métodos de solución de problemas proporcionados por Kitex para localizar el problema. Kitex proporciona puntos enterrados para RPCSart y RPCEnd, así como puntos enterrados más detallados para eventos de envío y recepción de paquetes. Al analizar estos puntos enterrados, descubrimos que Kitex reconoció toda la solicitud como una respuesta normal y se envió una gran cantidad de paquetes de datos a través del enlace de llamada. Una verificación más detallada de la información de administración de un solo paquete también muestra que Kitex lo reconoce como una respuesta normal.
Después de un juicio preliminar, creemos que es posible que se hayan ignorado los errores comerciales en el procesamiento de transmisión de Kitex, lo que resultó en que los errores no se identificaron correctamente. Después de comunicarse con el equipo de Kitex, realizaron los ajustes correspondientes, como agregar el reconocimiento de errores de estado comercial (errores de estado comercial) al código.
Con base en esta experiencia de manejo de errores, analizamos más a fondo otros escenarios anormales que pueden encontrarse en llamadas de transmisión, como errores de permiso en la fase de establecimiento de conexión, desbordamientos de TPM/QPM en la primera fase de paquete, tiempo de espera de transmisión y contenido en la fase de paquete intermedia. Errores de revisión, etc. Nos centramos en el rendimiento del manejo de errores de Kitex Thrift Streaming en estos escenarios, como si puede devolver rápidamente información de error al establecer una conexión y si puede detener rápidamente la espera de transmisión cuando el primer paquete y los paquetes intermedios devuelven errores. Después de ajustes conjuntos y pruebas con el equipo de Kitex, el manejo de errores en estos escenarios finalmente estuvo en línea con las expectativas.
-
En términos de gobernanza de servicios
En términos de gobernanza del servicio, prestamos especial atención a los dos aspectos clave: el tiempo de espera y la limitación de corriente.
Primero, la gestión del tiempo de espera es crucial. Dado que nuestros módulos interactúan con modelos grandes, esta interacción puede implicar tiempos de respuesta del orden de segundos o incluso minutos. Por lo tanto, establecemos límites de tiempo de espera a nivel de minutos para el procesamiento de transmisiones tanto en la capa HTTP como en la capa RPC. Esto puede evitar el bloqueo del servicio causado por no poder salir del bucle for y garantizar la estabilidad y disponibilidad del servicio.
En términos de limitación actual, aunque Kitex admite la limitación actual al crear una transmisión, para el escenario LLM, nuestro enfoque no está solo en la limitación actual de QPM al establecer una conexión, sino también en la limitación actual del consumo de tokens de modelos grandes. El proceso de inferencia de modelos grandes generará una gran cantidad de consumo de tokens, lo que puede provocar el agotamiento de los recursos y caídas del servicio si no se restringe. Por lo tanto, utilizamos Kitex para implementar el límite actual de Jianlian y, al mismo tiempo, utilizamos nuestros propios componentes distribuidos para calcular el consumo de tokens en diferentes modelos e implementar el límite actual a nivel de token en consecuencia. Hacerlo puede controlar eficazmente el uso de recursos y evitar la sobrecarga del servicio.
Sin embargo, también tenemos expectativas para Kitex. Esperamos que Kitex pueda proporcionar capacidades de limitación de corriente personalizadas con granularidad de paquetes en el futuro. De esta manera, podemos definir las reglas de limitación actuales de manera más flexible y controlar el uso de recursos con mayor precisión, mejorando así aún más la estabilidad y el rendimiento del servicio.
5. Expectativas futuras
Con el continuo desarrollo y aplicación de la tecnología de IA, tenemos mayores expectativas sobre las capacidades de los marcos de microservicios en escenarios de IA. Especialmente en términos de conveniencia, capacidades en escenarios de IA y adaptación de las capacidades del marco tradicional, esperamos ver más innovación y progreso.
-
Conveniencia
En primer lugar, en términos de conveniencia,
esperamos que el marco de microservicios admita el acceso a más herramientas de prueba
, especialmente para pruebas de interfaces de transmisión. Actualmente, todavía existen ciertas limitaciones al probar la interfaz de transmisión de Kitex Thrift, que se basa principalmente en escribir interfaces que no son de transmisión para empaquetar llamadas. En el futuro, esperamos hacer que la interfaz de transmisión sea más conveniente para admitir varias herramientas de prueba y mejorar la eficiencia del desarrollo mediante llamadas generalizadas y otros métodos.
-
Habilidad en escenarios de IA
Con el vigoroso desarrollo de la tecnología de IA, cada vez más productos están comenzando a incorporar capacidades de IA para optimizar la experiencia y las funciones del usuario. En el escenario de la IA, tenemos mayores expectativas para los marcos de microservicios como Kitex, con la esperanza de que pueda respaldar mejor la integración y orquestación de los componentes de la IA y adaptarse a las capacidades de los marcos tradicionales.
-
Capacidades de orquestación de componentes de IA listas para usar
En las prácticas de desarrollo actuales, cuando es necesario integrar capacidades de IA, los desarrolladores generalmente necesitan manejar ellos mismos una lógica compleja, como llamar a indicaciones, analizar resultados de modelos grandes y convertir resultados a lenguaje de máquina. Esto no solo aumenta la dificultad del desarrollo, sino que también reduce la eficiencia del desarrollo. Por lo tanto, esperamos que el marco Kitex proporcione capacidades de orquestación de componentes de IA listas para usar.
Específicamente, esperamos que el marco preinstale una serie de componentes de IA encapsulados, como componentes de avisos, componentes de modelos grandes, componentes de análisis de resultados y componentes de llamadas RPC. Estos componentes deben ser altamente configurables y extensibles para que puedan adaptarse a diferentes necesidades comerciales. Los desarrolladores solo necesitan pasar la lógica empresarial a estos componentes sin preocuparse por los detalles de implementación dentro de los componentes, para que puedan centrarse más en la implementación de la lógica empresarial.
-
Capacidades flexibles de orquestación de componentes de IA
Además de proporcionar componentes de IA preestablecidos, también esperamos que el marco Kitex admita capacidades flexibles de orquestación de componentes de IA. Esto significa que el marco debe proporcionar un lenguaje de expresión o una herramienta de visualización que permita a los desarrolladores organizar fácilmente estos componentes de IA según las necesidades comerciales. De esta manera, los desarrolladores pueden definir el orden de ejecución, métodos de comunicación, estrategias de procesamiento paralelo, etc. entre componentes sin entrar en detalles de las interacciones entre componentes. Esto mejorará en gran medida la eficiencia del desarrollo y la capacidad de mantenimiento de las aplicaciones de IA.
-
Las capacidades del marco tradicional se adaptan en enlaces LLM
En escenarios de IA, las capacidades del marco tradicional, como la gobernanza de servicios, la transmisión transparente de metadatos y la observabilidad, siguen siendo de gran importancia
. Por lo tanto, esperamos que el framework Kitex sea capaz de adaptarse y optimizar en estos aspectos.
En primer lugar, en términos de gobernanza de servicios, dado que las aplicaciones de IA pueden implicar procesos de inferencia a largo plazo, el marco debe proporcionar estrategias de limitación actual y de tiempo de espera para tiempos de respuesta del orden de segundos o incluso minutos. Al mismo tiempo, también es necesario considerar cómo manejar las excepciones relacionadas con los componentes de IA.
En segundo lugar, en términos de transmisión transparente de metadatos, esperamos que el marco admita la transmisión de metadatos entre componentes de IA para un monitoreo y depuración más refinados. Esto nos ayudará a comprender mejor el estado operativo de las aplicaciones de IA y localizar problemas rápidamente.
Finalmente, en términos de observabilidad, esperamos que el marco Kitex proporcione funciones integrales de registro, seguimiento y recopilación de indicadores para un monitoreo y análisis integrales de los enlaces de IA. Esto nos ayudará a descubrir posibles cuellos de botella en el rendimiento y puntos de optimización a tiempo, mejorando así el rendimiento y la estabilidad de las aplicaciones de IA.
En resumen, nuestras expectativas futuras para el marco Kitex en escenarios de IA se centran principalmente en
capacidades de orquestación de componentes de IA listas para usar
,
capacidades de orquestación de componentes de IA flexibles
y la adaptación de
las capacidades del marco tradicional en
enlaces
LLM
. Creemos que con el avance continuo de la tecnología y la profunda cooperación en equipo, estas expectativas se harán realidad gradualmente, aportando mayor comodidad y eficiencia al desarrollo de aplicaciones de IA.
De hecho, nuestro equipo ha llevado a cabo una cooperación profunda con el equipo de Kitex para discutir cómo respaldar mejor los escenarios de IA en el marco de microservicios. Creemos que en un futuro próximo podremos lanzar una versión MVP de la solución para proporcionar a los desarrolladores empresariales un marco que pueda integrarse fácil y perfectamente con las capacidades de IA. Va a ser un momento emocionante y lo estamos deseando.
{{o.nombre}}
{{m.nombre}}