Categoría: Nube e Infraestructura como Servicio

La mayoría de las computadoras se basan en la arquitectura de von Neumann, que separa el cómputo de la memoria. Esta disposición ha sido perfecta para la computación convencional, pero crea un atasco de tráfico de datos en la computación de IA. La computación con inteligencia artificial tiene fama de consumir enormes cantidades de energía. Esto se debe, en parte, al gran volumen de datos que se manejan. El entrenamiento suele requerir miles de millones o billones de datos para crear un modelo con miles de millones de parámetros. Pero esa no es la única razón: también se debe a cómo se construyen la mayoría de los chips informáticos. Los procesadores de las computadoras modernas son bastante eficientes a la hora de realizar los cálculos discretos que suelen tener encomendados. Aunque su eficiencia cae en picado cuando deben esperar a que los datos se muevan de un lado a otro entre la memoria y el cómputo, están diseñados para cambiar rápidamente a trabajar en alguna tarea no relacionada. Pero en el caso de la computación con IA, casi todas las tareas están interrelacionadas, por lo que a menudo no hay mucho más trabajo que se pueda hacer cuando el procesador se queda atascado esperando, dijo el científico de IBM Research Geoffrey Burr. En ese escenario, los procesadores se encuentran con lo que se denomina el cuello de botella de von Neumann, el retraso que se produce cuando los datos se mueven más lento que el cómputo. Es el resultado de la arquitectura de von Neumann, presente en casi todos los procesadores de las últimas seis décadas, en la que la memoria y las unidades de cómputo de un procesador están separadas, conectadas por un bus. Esta configuración tiene ventajas, entre ellas la flexibilidad, la adaptabilidad a cargas de trabajo variables y la capacidad de escalar sistemas y actualizar componentes fácilmente. Eso hace que esta arquitectura sea ideal para la informática convencional y no desaparecerá en un futuro próximo. Pero en el caso de la computación con inteligencia artificial, cuyas operaciones son simples, numerosas y altamente predecibles, un procesador convencional termina trabajando por debajo de su capacidad máxima mientras espera que los pesos de los modelos se transfieran de un lado a otro desde la memoria. Los científicos e ingenieros de IBM Research están trabajando en nuevos procesadores, como la familia AIU , que utilizan diversas estrategias para superar el cuello de botella de von Neumann y potenciar la computación con inteligencia artificial. ¿Por qué existe el cuello de botella de von Neumann? El cuello de botella de von Neumann recibe su nombre del matemático y físico John von Neumann, que en 1945 hizo circular por primera vez un borrador de su idea de un ordenador con programa almacenado. En ese artículo, describía un ordenador con una unidad de procesamiento, una unidad de control, una memoria que almacenaba datos e instrucciones, almacenamiento externo y mecanismos de entrada/salida. Su descripción no mencionaba ningún hardware específico, probablemente para evitar problemas de seguridad con el ejército de los EE. UU., para el que trabajaba como consultor. Sin embargo, casi ningún descubrimiento científico es realizado por una sola persona, y la arquitectura de von Neumann no es una excepción. El trabajo de von Neumann se basó en el trabajo de J. Presper Eckert y John Mauchly, que inventaron el Integrador Numérico Electrónico y el Ordenador (ENIAC), el primer ordenador digital del mundo. Desde que se escribió ese artículo, la arquitectura de von Neumann se ha convertido en la norma. “La arquitectura de von Neumann es bastante flexible, esa es la principal ventaja”, afirmó el científico de IBM Research Manuel Le Gallo-Bourdeau. “Es por eso que se adoptó por primera vez y por eso sigue siendo la arquitectura predominante en la actualidad”. Las unidades de memoria y computación discretas permiten diseñarlas por separado y configurarlas más o menos como se desee. Históricamente, esto ha facilitado el diseño de sistemas informáticos porque se pueden seleccionar y combinar los mejores componentes en función de la aplicación. Incluso la memoria caché, que está integrada en un único chip junto con el procesador, se puede actualizar de forma individual. “Estoy seguro de que el diseño de una nueva memoria caché tiene consecuencias para el procesador, pero no es tan difícil como si estuvieran acopladas”, afirma Le Gallo-Bourdeau. “Siguen estando separadas. Esto permite cierta libertad a la hora de diseñar la caché por separado del procesador”. Cómo el cuello de botella de von Neumann reduce la eficiencia Para la computación de IA, el cuello de botella de von Neumann crea un doble problema de eficiencia: la cantidad de parámetros de modelo (o pesos) que se deben mover y la distancia a la que deben moverse. Más pesos de modelo significan mayor almacenamiento, lo que generalmente significa almacenamiento más distante, dijo la científica de IBM Research Hsinyu (Sidney) Tsai. «Dado que la cantidad de pesos de modelo es muy grande, no se puede permitir el lujo de mantenerlos durante mucho tiempo, por lo que es necesario descartarlos y recargarlos constantemente», dijo. El principal gasto de energía durante el tiempo de ejecución de la IA se destina a transferencias de datos, es decir, a trasladar los pesos de los modelos de la memoria a los cálculos. En comparación, la energía que se gasta en realizar cálculos es baja. En los modelos de aprendizaje profundo, por ejemplo, las operaciones son casi todas problemas de multiplicación de matrices y vectores relativamente simples. La energía de cálculo sigue representando alrededor del 10 % de las cargas de trabajo de la IA moderna, por lo que no es despreciable, dijo Tsai. «Simplemente se ha descubierto que ya no domina el consumo de energía y la latencia, a diferencia de las cargas de trabajo convencionales», agregó. Hace aproximadamente una década, el cuello de botella de von Neumann no era un problema importante porque los procesadores y la memoria no eran tan eficientes, al menos en comparación con la energía que se gastaba en transferir datos, dijo Le Gallo-Bourdeau. Pero la eficiencia

Para promover el desarrollo de LLM de código abierto, el equipo de Qwen lanzó recientemente Qwen2.5-Coder, una familia de LLM avanzados para la generación, el razonamiento y la corrección de código en lenguajes de programación populares. Los modelos de lenguaje grande (LLM) que se especializan en codificación se han adoptado de manera constante en los flujos de trabajo de los desarrolladores. Desde la programación en pareja hasta los agentes de IA que se mejoran a sí mismos , estos modelos ayudan a los desarrolladores con diversas tareas, como mejorar el código, corregir errores, generar pruebas y escribir documentación. Para promover el desarrollo de LLM de código abierto, el equipo de Qwen lanzó recientemente Qwen2.5-Coder, una familia de LLM avanzados para la generación, el razonamiento y la corrección de código en lenguajes de programación populares. Esta publicación explora los beneficios de las optimizaciones de inferencia para los modelos Qwen2.5-Coder compatibles con NVIDIA TensorRT-LLM y la facilidad de implementación con NVIDIA NIM para lograr potencial transformador y eficiencia de codificación. Modelos de codificadores Qwen2.5 Los modelos Qwen2.5-Coder han logrado un rendimiento de vanguardia en los puntos de referencia académicos más populares. NVIDIA TensorRT-LLM ha optimizado tres modelos populares de la familia Qwen2.5-Coder (las versiones 1.5B, 7B y 32B) para lograr un alto rendimiento y una baja latencia. TensorRT-LLM es una biblioteca para una inferencia LLM rápida y eficiente e incluye optimizaciones como procesamiento por lotes dinámico en vuelo , almacenamiento en caché KV , reutilización de caché KV y varias técnicas de decodificación especulativa, entre otras.  Estas optimizaciones ayudan a ofrecer mejoras de rendimiento para los modelos Qwen2.5-Coder en lenguajes de programación populares como Python, C++, Java, Bash, Javascript, TypeScript y Go, llegando a una gama más amplia de desarrolladores. Esta publicación explora la optimización de la decodificación anticipada y el aumento de rendimiento que ayuda a lograr. Sin ninguna capacitación adicional ni necesidad de modelos de borrador adicionales, los desarrolladores pueden aprovechar la API de alto nivel TensorRT-LLM para acelerar la inferencia de Qwen2.5-Coder para generar la finalización automática de código de varias líneas. Descodificación anticipada La decodificación anticipada es una técnica de decodificación especulativa que aborda la naturaleza autorregresiva lenta de los LLM. Cada paso de decodificación autorregresiva solo genera un token a la vez, sin aprovechar la enorme potencia de procesamiento en paralelo de las GPU NVIDIA, lo que genera una baja utilización de la GPU y un menor rendimiento. Anteriormente, analizamos el aumento del rendimiento que se puede lograr con la decodificación especulativa de destino preliminar y aquí analizamos los beneficios de aprovechar la implementación de la decodificación anticipada TensorRT-LLM utilizando los modelos Qwen2.5-Coder como ejemplo. A diferencia de la generación de un solo token en la decodificación autorregresiva, la decodificación anticipada genera múltiples tokens simultáneamente, utilizando adecuadamente las capacidades de procesamiento paralelo de la GPU y aprovechando los cálculos (FLOP) para reducir la latencia. Además, la decodificación anticipada no requiere un modelo de borrador independiente que se necesita para la decodificación especulativa de destino de borrador.  Cada paso de decodificación se divide en dos ramas paralelas, la rama de anticipación y la rama de verificación. Utilizando el método de iteración de Jacobi , un solucionador de sistemas no lineales clásico, la rama de anticipación realiza una decodificación paralela para tokens futuros mediante la generación de n-gramas. La rama de verificación selecciona y verifica los candidatos de n-gramas prometedores generados por la rama de anticipación. El algoritmo de anticipación se configura utilizando tres parámetros clave: tamaño de ventana (W), tamaño de n-gramas (N) y tamaño del conjunto de verificación (G).  El rendimiento de la búsqueda anticipada depende en gran medida del modelo base, el hardware, el tamaño del lote, la longitud de la secuencia y el conjunto de datos. Se recomienda crear perfiles de varias configuraciones para encontrar la mejor configuración (W, N, G) dada la configuración. La configuración óptima de tuplas (W, N, G) permite que la decodificación anticipada brinde un rendimiento mejorado sin la necesidad de capacitación adicional, ajustes finos o modelos preliminares.  A través de nuestros experimentos sobre el barrido de valores de configuración (W, N, G), logramos aumentos de velocidad de 3,6x y 1,6x en el rendimiento para los modelos Qwen2.5-Coder 7B Instruct y Qwen2.5-Coder 32B Instruct, respectivamente. Estos aumentos de velocidad se miden en rendimiento (tokens/segundo) en comparación con la línea base (sin decodificación especulativa de anticipación) en GPU NVIDIA H100 Tensor Core , como se muestra en la Figura 2.  Datos medidos el 30/01/2025. Aceleraciones del rendimiento de inferencia (tokens de salida/segundo) de los modelos Qwen2.5-Coder 7B Instruct y Qwen2.5-Coder 32B Instruct. DGX H100, TP=1 | (W, N, G) = (8, 8, 8) | Qwen2.5-Coder 7B Instruct, TP=2 | (W, N, G) = (15, 15, 15) | Qwen2.5-Coder-32B-Instruct, tamaño de lote=1, TensorRT-LLM versión 0.15.0.  Se logran aceleraciones de rendimiento similares en las GPU NVIDIA H200 Tensor Core . Con su mayor ancho de banda de memoria, también ayudan a aumentar el rendimiento de rendimiento de referencia, lo que genera aceleraciones ligeramente inferiores en comparación con las GPU H100 (Figura 3). Datos medidos el 30/01/2025. Aceleraciones del rendimiento de inferencia (tokens de salida/segundo) de los modelos Qwen2.5-Coder 7B Instruct y Qwen2.5-Coder 32B Instruct. DGX H200, TP=1 | (W, N, G) = (8, 8, 8) | Qwen2.5-Coder 7B Instruct, TP=2 | (W, N, G) = (15, 15, 15) | Qwen2.5-Coder 32B Instruct, tamaño de lote=1, TensorRT-LLM versión 0.15.0. Pasos para ejecutar la decodificación anticipada con TensorRT-LLM Para reproducir estas mejoras de rendimiento mediante la decodificación especulativa anticipada dentro de TensorRT-LLM, siga los pasos a continuación. # Install TensorRT-LLM. (Commands below are for Linux. Refer to TensorRT-LLM docs for Windows)sudoapt-get -y installlibopenmpi-dev && pip3 install–upgrade setuptools && pip3 installtensorrt_llm –extra-index-url https://pypi.nvidia.com Luego, ejecute la decodificación anticipada en TensorRT-LLM utilizando la API de alto nivel.  # Command for Qwen2.5-Coder-7B-Instructfromtensorrt_llm importLLM, SamplingParamsfromtensorrt_llm.llmapi import(LLM, BuildConfig, KvCacheConfig, LookaheadDecodingConfig, SamplingParams)defmain():    «»»The end user can customize the build configuration with the build_config class. # Max draft length is based on (W,N,G) values and calculated as: (W + G -1) * (N-1) + ( N<=1 ? 0: N-2)»»»    build_config =BuildConfig(max_batch_size =128,max_input_len =2048, max_seq_len =4096,max_num_tokens =16384, max_draft_len =111)    build_config.plugin_config.reduce_fusion =True    build_config.plugin_config.use_paged_context_fmha =True    build_config.plugin_config.multiple_profiles =True        # The configuration for lookahead decoding    lookahead_config =LookaheadDecodingConfig(max_window_size=8,                                               max_ngram_size=8,                                              max_verification_set_size=8)        kv_cache_config =KvCacheConfig(free_gpu_memory_fraction=0.4)    llm =LLM(model=»Qwen/Qwen2.5-Coder-7B-Instruct»,              kv_cache_config=kv_cache_config,              build_config=build_config,              speculative_config=lookahead_config)        prompt =»»»Write