Red Hat OpenShift ofrece inferencia de LLM de alto rendimiento para los servicios financieros

El sector de los servicios financieros, al igual que muchos otros sectores, busca aprovechar al máximo su hardware en la era de las cargas de trabajo de inteligencia artificial que consumen muchos recursos. Las empresas de servicios financieros confían en las ventajas de la arquitectura basada en contenedores, pero es posible que les preocupe que las plataformas de orquestación de contenedores agreguen penalizaciones de rendimiento que podrían agravar las limitaciones de recursos. 

Los resultados de una nueva auditoría STAC-AI™ LANG6 (Inference-Only), el estándar del sector para evaluar el rendimiento de la inferencia de los modelos de lenguaje de gran tamaño (LLM) en los servicios financieros, pueden ayudar a disipar esas preocupaciones en relación con Red Hat OpenShift. En colaboración con NVIDIA y Supermicro, el equipo de ingeniería de rendimiento y escalabilidad de Red Hat ejecutó el conjunto completo de estándares STAC-AI LANG6 en OpenShift con 2 GPU NVIDIA RTX PRO 6000 Blackwell Server Edition en un SuperServer SYS-222C-TN de Supermicro. Estos son los primeros resultados auditados de STAC-AI generados en una plataforma de Kubernetes organizada en contenedores.

Red Hat lleva mucho tiempo demostrando que OpenShift ofrece un rendimiento similar al de los servidores dedicados (bare metal) para las cargas de trabajo más exigentes, y respaldamos esa afirmación con resultados de auditorías independientes. En el estándar de red STAC-N1, demostramos que OpenShift iguala (y en algunos casos mejora) la latencia de los servidores dedicados (bare metal) para los datos de mercado. Empatamos las latencias media y mediana más bajas con 100000 y 1,4 millones de mensajes por segundo y, al mismo tiempo, redujimos la latencia máxima en un 37 %. En el estándar de riesgo de mercado STAC-A2, establecimos varios récords en la simulación Monte Carlo acelerada por GPU en OpenShift con los sistemas NVIDIA DGX A100. En el estudio STAC-A2 with Intel CPUs, demostramos que la sobrecarga de la orquestación en contenedores de OpenShift es insignificante, incluso para las cargas de trabajo financieras que utilizan muchas CPU.

Esta nueva presentación de STAC-AI amplía ese historial al dominio de la inferencia de LLM. Se trata de un área que adquiere cada vez más importancia a medida que las instituciones financieras adoptan flujos de trabajo basados en la inteligencia artificial para la detección de fraudes, la seguridad, el análisis de opiniones y el cumplimiento normativo.

Introducción rápida a STAC-AI LANG6

El Strategic Technology Analysis Center (STAC) genera estándares que las instituciones financieras más grandes del mundo utilizan para evaluar las stacks tecnológicas. STAC-AI LANG6 mide el rendimiento de la inferencia de los LLM en casos prácticos de servicios financieros. Sus conjuntos de datos se derivan de archivos financieros reales de EDGAR ante la SEC, los tipos de documentos que impulsan la RAG (generación aumentada por recuperación) y las cargas de trabajo de contexto largo en las empresas financieras.

El estándar abarca 2 modos de inferencia. El modo por lotes mide el rendimiento máximo al pasar el conjunto de datos completo al sistema que se está probando (SUT) en una sola llamada a la API. El modo interactivo simula el uso real mediante el envío de solicitudes con diferentes tasas de llegada según una distribución de Poisson. Mide el tiempo de reacción (similar al tiempo hasta el primer token), el tiempo de respuesta y la tasa de salida bajo carga.

Probamos 2 modelos (Llama-3.1-8B-Instruct y Llama-3.1-70B-Instruct) en 4 conjuntos de datos de EDGAR que varían en longitud y complejidad de las peticiones. El estándar también mide la fidelidad: el grado de coincidencia entre el resultado del modelo optimizado y el mismo modelo que se ejecuta con precisión nativa en un SUT de referencia del STAC. En total, la especificación requiere 7 cargas de trabajo obligatorias. 

Tabla 1 Modelo, conjunto de datos y modos de ejecución del estándar STAC-AI

La stack

Hardware:

• Supermicro SuperServer SYS-222C-TN, un servidor DC-MHS de 2U
• 2 CPU Intel Xeon 6730P (64 núcleos físicos en total)
• 2 TiB DDR5-5200 (32 DIMM de 64 GiB)
• 2 GPU NVIDIA RTX PRO 6000 Blackwell Server Edition (96 GiB GDDR7 cada una)

Software:

• Red Hat OpenShift 4.20 (OpenShift de un solo nodo)
• Red Hat Enterprise Linux CoreOS 9.6
• Node feature discovery operator
• NVIDIA GPU operator
• STAC-AI Operator (operador personalizado desarrollado por Red Hat)
• NVIDIA TensorRT-LLM 1.2.0rc2 (backend de PyTorch) con cuantificación de NVFP4 a través de NVIDIA Model Optimizer 0.37.0

La stack de operadores sigue el mismo patrón que establecimos en nuestro trabajo del STAC-A2. El operador de detección de funciones del nodo es el requisito previo: detecta las funciones de hardware en cada nodo y las muestra como etiquetas de Kubernetes. El operador de NVIDIA GPU utiliza esas etiquetas para determinar dónde implementar los contenedores de controladores de GPU. Así, el programador puede acceder a ellas como recursos en nvidia.com/gpu. A partir de ese momento, un pod solicita las GPU de la misma manera que solicita la CPU o la memoria.

Con estos 2 operadores instalados, las GPU se convierten en recursos de Kubernetes de primer nivel. No es necesario instalar controladores de forma manual, configurar hosts especiales ni utilizar módulos de kernel personalizados. El mismo enfoque funciona tanto si tienes un solo nodo de GPU en el extremo (edge) como un clúster de ellos en un centro de datos.

Además de esa base, agregamos el STAC-AI Operator para organizar el estándar en sí.

El operador STAC-AI

Ejecutar un estándar de STAC-AI de extremo a extremo implica muchos elementos: cuantificar el modelo con la precisión deseada, establecer los límites de energía y reloj de la GPU, realizar las pruebas en varias cargas de trabajo y tasas de llegada, recopilar los rastros de energía y temperatura de forma sincrónica con cada ejecución y, por último, realizar el análisis de fidelidad en un modelo de referencia. Hacer todo esto de forma manual lleva mucho tiempo, es propenso a errores y es difícil de reproducir. El STAC-AI Operator hace que todo el flujo de trabajo sea declarativo.

Recursos personalizados

El operador introduce 3 definiciones de recursos personalizados (CRD):

• La implementación registra un backend de LLM disponible (como TensorRT-LLM) junto con sus imágenes de contenedores y los modelos y conjuntos de datos compatibles.
• BenchmarkRun es el recurso principal. Declara una única ejecución de estándar: qué implementación usar, qué modelo y conjunto de datos probar, el método de cuantificación, la asignación de GPU y si se debe ejecutar el análisis de fidelidad posterior al procesamiento. El operador se encarga de todo desde allí.
• BenchmarkImageBuild gestiona la compilación única de la imagen de contenedor para la stack de TensorRT-LLM.

Gestión del ciclo de vida

Cuando se crea una BenchmarkRun, el operador la ejecuta a través de una máquina de estado:

Pending → Queued → Initializing → Quantizing → Building → Running → RunCompleted → PostProcessing → Completed

En cada etapa, el operador crea tareas de Kubernetes para llevar a cabo el trabajo. Detecta y aplica automáticamente las velocidades máximas de reloj de la GPU y los límites de energía con nvidia-smi. Gestiona una cola de ejecución secuencial para que solo se ejecute un estándar a la vez, lo cual evita la contención de la GPU entre las ejecuciones, y se encarga del análisis de fidelidad con vLLM como referencia. Si falla alguno de los pasos, la ejecución pasa al estado Failed con un código de motivo escrito, lo cual simplifica el diagnóstico.

Ejecución de un estándar

Esto es lo que se necesita para ejecutar una carga de trabajo auditada:

apiVersion: stac.ai/v1alpha1
kind: BenchmarkRun
metadata:
  name: stac-rtxpro6000-8b-e4a-batch
  namespace: stac-ai
spec:
  implementation: tensorrt-llm
  model: llama-3.1-8b
  dataset: edgar4a
  sut: RTXPRO6000-8B-E4a-Batch
  sutConfig:
    configMapName: sut-tensorrt-llm-rtxpro6000-batch
    key: RTXPRO6000-8B-E4a-Batch.yaml
  config:
    quantization: NVFP4
    gpuCount: 2
    useExecutor: false
  postProcessing:
    fidelity: true
  storage:
    workspacePVC: stac-workspace-pvc
    modelCachePVC: stac-model-cache-pvc
    logsPVC: stac-logs-pvc

Ese YAML representa toda la interacción con el usuario. Si lo aplicas, el operador se encarga de la cuantificación del modelo, el ajuste de la GPU, la ejecución de los estándares, el registro de la potencia y la temperatura, y el análisis de fidelidad. Los parámetros específicos de las cargas de trabajo (tamaño de los lotes, duración de las secuencias, tasas de llegada) se insertan a través de un ConfigMap, de modo que se pueden probar diferentes configuraciones sin tener que volver a compilar ninguna imagen de contenedor.

Para ejecutar el conjunto completo de STAC-AI LANG6, aplicamos una sola BenchmarkRun que hace referencia a una configuración de SUT que define las 7 cargas de trabajo. De esta manera, el operador inicia el aprovechamiento del estándar (tal como se define en el recurso personalizado) y este ejecuta cada carga de trabajo de forma secuencial (tal como se define en la configuración de SUT). La potencia y la temperatura del aire de entrada se registran durante cada período de medición a través de un analizador de energía de precisión Yokogawa WT1804R (consultado mediante VXI-11/SCPI desde el pod de estándar) y una sonda Dallas DS18B20 por USB serial.

Resultados

Los resultados de la auditoría que aparecen en las tablas 2 y 3 provienen del informe oficial del STAC. Todas las cargas de trabajo se cuantificaron en NVFP4 con caché de KV de FP8, y cada GPU ejecutó una instancia de modelo independiente.

Tabla 2 Resultados del modo por lotes

Tabla 3 Resultados del modo interactivo (tasa de llegada sostenida más alta)

Estos son algunos aspectos de los resultados auditados:

• Gran eficiencia de espacio gracias a un factor de forma de 2U. Según el informe de STAC, el sistema SYS-222C-TN de 2U proporcionó una mayor eficiencia de espacio por lotes que el sistema NVIDIA GH200 de mayor tamaño en todas las cargas de trabajo comparables. Logró 9501 millones frente a 6148 millones de palabras por pie³·hora en EDGAR4a, 1,428 millones frente a 799500 en EDGAR4b, y 237400 frente a 226900 en EDGAR5a, mientras completaba todo el conjunto de cargas de trabajo informado con solo 2 GPU.
• NVFP4 permite que los modelos 70B utilicen una sola GPU. La cuantificación de Llama-3.1-70B-Instruct para NVFP4 reduce el modelo en disco a aproximadamente 35 GB, lo cual se ajusta a los 96 GB de memoria en una sola RTX PRO 6000 con mucho espacio para la caché de KV. Cada GPU ejecuta una instancia de modelo independiente, y ambas GPU se utilizan a la misma vez en las cargas de trabajo interactivas y por lotes.

El STAC-AI Operator era el responsable de cada una de estas ejecuciones. Aplicamos un recurso personalizado BenchmarkRun que hacía referencia a la configuración de SUT para todo el conjunto, y el operador se encargaba de la cuantificación, el ajuste, la ejecución y el posprocesamiento sin intervención alguna.

Por qué elegir Red Hat OpenShift para la inferencia de LLM

Una de las preguntas que recibimos con frecuencia es si una plataforma en contenedores genera una sobrecarga importante para las cargas de trabajo que dependen del rendimiento. Los resultados de esta auditoría brindan una indicación sólida para la inferencia de LLM: la GPU parece ser el cuello de botella, no la plataforma. No hay señales en los datos de que el tiempo de ejecución o la programación del contenedor de OpenShift agreguen una sobrecarga significativa al proceso de inferencia. El propio comentario del STAC en el informe es coherente con esto: "En la práctica, las capas de contenedores y orquestación no parecen introducir limitaciones importantes en el rendimiento". Junto con nuestros resultados auditados anteriores de STAC-N1 (red) y STAC-A2 (computación en GPU), consideramos que este es un tercer dato que refuerza nuestra opinión. OpenShift puede ofrecer el rendimiento que las empresas esperan de los servidores dedicados (bare metal) para las cargas de trabajo financieras exigentes.

Sin embargo, el valor real de la ejecución en OpenShift va mucho más allá del rendimiento puro. En los entornos de producción de servicios financieros, también se necesitan políticas de seguridad, control de acceso basado en funciones, registros de auditoría, gestión del ciclo de vida y arquitectura multiempresa. OpenShift ofrece todo eso desde el primer momento. No tienes que elegir entre un rendimiento similar al de los servidores dedicados (bare metal) y las operaciones de nivel empresarial.

Tampoco necesitas una stack paralela para ejecutar las cargas de trabajo de la GPU. El mismo clúster que ejecutó este est[andar puede ejecutar junto con él las cargas de trabajo de las aplicaciones, la virtualización, los trabajos por lotes y los canales de CI/CD. Todo se ejecuta bajo el mismo equipo de operaciones, la misma superficie de observabilidad y las mismas políticas de seguridad. Un equipo que ya utiliza OpenShift adopta una plataforma de inferencia de GPU sin tener que crear una segunda superficie operativa.

El patrón de operador que utilizamos para este estándar ilustra un punto más amplio: las cargas de trabajo complejas de GPU se pueden gestionar a través de API declarativas nativas de Kubernetes, ya sea que se trate de conjuntos de estándares o que se publiquen en LLM de producción. Los usuarios describen lo que buscan (modelo, cuantificación, conjunto de datos); el operador determina la manera de distribuirlo. Este patrón se ajusta de la misma manera desde un entorno de prueba de un solo nodo hasta un clúster de producción de varios nodos.

Así es como se diseña Red Hat OpenShift AI. Se ejecuta en el núcleo de OpenShift con los mismos operadores de NVIDIA GPU y de detección de funciones de los nodos, el mismo modelo de recursos de nvidia.com/gpu y el mismo patrón de operadores. Esto permite gestionar el desarrollo, el entrenamiento, la distribución y la supervisión de los modelos en entornos de nube, on-premise y en el extremo (edge). La infraestructura en la que se ejecuta este estándar se adapta directamente a una plataforma de producción de inteligencia artificial sin cambiar la base que la sustenta.

La gestión de las GPU también se simplifica. Los operadores de NVIDIA GPU y la detección de funciones del nodo se encargan de la detección del hardware, el ciclo de vida de los controladores y la programación de los recursos en todo el clúster. Para agregar nodos de GPU nuevos, solo hay que instalar los operadores; el resto es automático. El mismo modelo de implementación funciona sin cambios en un clúster de OpenShift de un solo nodo como el que se usa aquí, un clúster compacto de 3 nodos adecuado para una sucursal, nodos de trabajo remotos en el extremo (edge) o un clúster de varios nodos en un centro de datos regional. Ninguno de los elementos YAML de esta publicación de blog cambiaría para reorientar alguno de ellos.

Por último, cada ejecución de estándar en este proyecto se define en YAML con control de versiones. Todas las configuraciones son reproducibles. Cuando el STAC realizó su auditoría independiente, reproducimos exactamente el mismo entorno y los mismos resultados aplicando los mismos recursos. Ese nivel de capacidad de reproducción es una consecuencia natural del modelo de implementación de Kubernetes; es tan valioso para las cargas de trabajo de producción como para los envíos de estándares.

Conclusión

Estos resultados auditados muestran que Red Hat OpenShift ejecuta las cargas de trabajo de inferencia de LLM que las empresas de servicios financieros utilizan para evaluar su infraestructura de inteligencia artificial, sin indicios de que la sobrecarga de la plataforma limite las GPU. En combinación con nuestros resultados anteriores de STAC-N1 y STAC-A2, esto refuerza una imagen coherente: las empresas pueden ejecutar sus cargas de trabajo más exigentes con el rendimiento de los servidores dedicados (bare metal), todo en la misma plataforma de OpenShift.

Los resultados completos de la auditoría están disponibles en el sitio web del STAC. Para obtener más comentarios sobre la implementación de TensorRT-LLM y la plataforma de hardware SYS-222C-TN, consulte esta publicación de blog de NVIDIA.