Red Hat OpenShift: inferência de LLM de alto desempenho

O setor de serviços financeiros, assim como muitos outros, visa fazer o melhor uso do hardware na era das cargas de trabalho de IA com uso intensivo de recursos. As empresas de serviços financeiros passaram a contar com as vantagens de uma arquitetura baseada em containers, mas podem se preocupar com o fato de que as plataformas de orquestração de containers adicionem penalidades de desempenho que podem agravar as restrições de recursos. 

Os resultados da nova auditoria STAC-AI™ LANG6 (somente para inferência), o benchmark padrão do setor para avaliar o desempenho de inferência de Large Language Model (LLM) em serviços financeiros, podem ajudar a diminuir essas preocupações quando se trata do Red Hat OpenShift. Em colaboração com a NVIDIA e a Supermicro, a equipe de engenharia de desempenho e escala da Red Hat executou o conjunto de benchmark STAC-AI LANG6 completo no OpenShift, usando dois GPUs NVIDIA RTX PRO 6000 Blackwell Server Edition em um Supermicro SuperServer SYS-222C-TN. Estes são os primeiros resultados auditados do STAC-AI produzidos em uma plataforma Kubernetes em containers.

A Red Hat tem um longo histórico em demonstrar que o OpenShift oferece desempenho semelhante ao do bare-metal para as cargas de trabalho mais exigentes, e comprovamos essa afirmação com resultados auditados de forma independente. No benchmark de rede STAC-N1, mostramos que o OpenShift iguala (e, em alguns casos, melhora) a latência bare-metal para dados de mercado, empatando as latências médias e medianas mais baixas em 100.000 e 1.4 milhão de mensagens por segundo, além de reduzir a latência máxima em 37%. No benchmark de risco de mercado STAC-A2 que quebrou recordes, batemos vários recordes na simulação de Monte Carlo acelerada por GPU no OpenShift com sistemas NVIDIA DGX A100. E em STAC-A2 com CPUs Intel, mostramos que a sobrecarga do uso de containers do OpenShift é insignificante, mesmo para cargas de trabalho financeiras com uso intensivo de CPU.

Essa nova submissão do STAC-AI estende esse histórico para o domínio da inferência de LLM. Essa é uma área de importância crescente à medida que as instituições financeiras adotam fluxos de trabalho orientados por IA para detecção de fraudes, segurança, análise de sentimento e conformidade regulatória.

Guia rápido sobre o STAC-AI LANG6

O Strategic Technology Analysis Center (STAC) produz benchmarks padronizados que as principais instituições financeiras do mundo utilizam para avaliar stacks de tecnologia. O STAC-AI LANG6 mede o desempenho de inferência de LLM em casos de uso de serviços financeiros. Seus conjuntos de dados são derivados de registros financeiros reais da SEC EDGAR, os tipos de documentos que impulsionam a RAG (geração aumentada por recuperação) e cargas de trabalho de longo contexto em empresas financeiras.

O benchmark abrange dois modos de inferência. O modo em lote mede a taxa de transferência máxima, entregando o conjunto de dados completo ao sistema em teste (SUT) em uma única chamada de API. O modo interativo simula o uso no mundo real enviando solicitações em taxas de chegada variadas, seguindo uma distribuição de Poisson, enquanto mede o tempo de reação (análogo ao tempo para o primeiro token), o tempo de resposta e a taxa de saída sob carga.

Testamos dois modelos (Llama-3.1-8B-Instruct e Llama-3.1-70B-Instruct) em quatro conjuntos de dados EDGAR que variam em tamanho e complexidade. O benchmark também mede a fidelidade: o quanto a saída do modelo otimizado corresponde ao mesmo modelo em execução com precisão nativa em uma SUT de referência STAC. No total, a especificação exige sete cargas de trabalho obrigatórias. 

Tabela 1. Modelo, conjunto de dados e modos de execução do benchmark STAC-AI

O stack

Hardware:

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

Software:

• Red Hat OpenShift 4.20 (single-node OpenShift)
• Red Hat Enterprise Linux CoreOS 9.6
• Operador de descoberta de recursos de nó
• Operador NVIDIA GPU
• Operator STAC-AI (operador personalizado desenvolvido pela Red Hat)
• NVIDIA TensorRT-LLM 1.2.0rc2 (back-end do PyTorch) com quantização do NVFP4 via NVIDIA Model Optimizer 0.37.0

O stack de operadores segue o mesmo padrão que estabelecemos no trabalho STAC-A2. O operador de descoberta de recursos de nó é pré-requisito: ele descobre recursos de hardware em cada nó e os exibe como rótulos do Kubernetes. O operador NVIDIA GPU utiliza esses rótulos para determinar onde implantar os containers do driver da GPU, disponibilizando as GPUs para o scheduler como recursos nvidia.com/gpu. A partir desse ponto, um pod solicita GPUs da mesma forma que solicita CPU ou memória.

Com esses dois operadores instalados, as GPUs se tornam recursos de primeira classe do Kubernetes. Nenhuma instalação manual de driver, configuração especial de host ou módulos personalizados do kernel são necessários. A mesma abordagem funciona independentemente de você ter um único nó de GPU na edge ou um cluster deles em um datacenter.

Além disso, adicionamos o STAC-AI Operator para orquestrar o benchmark.

Operator STAC-AI

A execução de um benchmark STAC-AI de ponta a ponta envolve muitas partes móveis: quantização do modelo para a precisão desejada, bloqueio de relógios de GPU e limites de energia, execução do benchmark em várias cargas de trabalho e taxas de chegada, coleta de rastreamentos de energia e temperatura de forma síncrona com cada execução e, por fim, execução da análise de fidelidade em um modelo de referência. Fazer tudo isso manualmente é demorado, suscetível a erros e difícil de reproduzir. O operator torna todo o fluxo de trabalho declarativo.

Recursos personalizados

O operador apresenta três definições de recursos personalizados (CRDs):

• Implementation registra um back-end de LLM disponível (como TensorRT-LLM) com suas imagens de container e modelos e conjuntos de dados compatíveis.
• BenchmarkRun é o recurso primário. Ele declara uma única execução de benchmark: qual implementação usar, qual modelo e conjunto de dados testar, o método de quantização, alocação de GPU e se a análise de fidelidade de pós-processamento deve ser executada. O operador STAC-AI cuida de tudo a partir daí.
• BenchmarkImageBuild gerencia a build única de imagem de container para o stack TensorRT-LLM.

Gerenciamento do ciclo de vida

Quando um BenchmarkRun é criado, o operador o conduz por uma máquina de estado:

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

Em cada fase, o operador cria jobs do Kubernetes para realizar o trabalho. Ele detecta e aplica automaticamente velocidades máximas de relógio de GPU e limites de energia usando nvidia-smi, gerencia uma fila de execução sequencial para que apenas um benchmark seja executado por vez (evitando a contenção de GPU entre execuções) e lida com a análise de fidelidade usando vLLM como referência. Se qualquer etapa falhar, a execução passará para um estado Failed com um código de motivo tipado, simplificando o diagnóstico.

Execute um benchmark

Confira o que é necessário para executar uma carga de trabalho 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

Esse YAML é toda a interação do usuário. Aplique-o e o operador lidará com a quantização do modelo, ajuste de GPU, execução de benchmark, captura de energia e temperatura e análise de fidelidade. Parâmetros específicos da carga de trabalho (tamanhos de lote, comprimentos de sequência, taxas de chegada) são injetados por meio de um ConfigMap. Assim, diferentes configurações podem ser testadas sem recompilar imagens de container.

Para executar o conjunto STAC-AI LANG6 completo, aplicamos um único BenchmarkRun que se refere a uma configuração do SUT que define todas as sete cargas de trabalho. Dessa forma, o operador inicia o benchmark harness (conforme definido pelo recurso personalizado) e o harness executa cada carga de trabalho sequencialmente (conforme definido pela configuração do SUT). A energia e a temperatura do ar de entrada são coletadas ao longo de cada período de medição por um analisador de energia de precisão Yokogawa WT1804R (consultado por VXI-11/SCPI do pod de benchmark) e uma sonda Dallas DS18B20 por USB serial.

Resultados

Os resultados auditados nas Tabelas 2 e 3 foram retirados do relatório oficial do STAC. Todas as cargas de trabalho foram quantizadas para NVFP4 com cache FP8 KV, com cada GPU executando uma instância de modelo independente.

Tabela 2. Resultados do modo de lote

Tabela 3. Resultados no modo interativo (maior taxa de chegada contínua)

Algumas observações dos resultados auditados:

• Alta eficiência de espaço em um formato de 2U. De acordo com o relatório STAC, o SYS-222C-TN 2U apresentou maior eficiência de espaço em lote do que o sistema NVIDIA GH200 maior em todas as cargas de trabalho comparáveis (9.501 milhões vs. 6.148 milhões de palavras por pé³·hora no EDGAR4a, 1.428 milhão vs. 799.500 no EDGAR4b e 237.400 vs. 226.900 no EDGAR5a) ao concluir o conjunto completo de cargas de trabalho relatado com apenas 2 GPUs.
• O NVFP4 permite que modelos 70B rodem confortavelmente em uma única GPU. Quantizar o Llama-3.1-70B-Instruct para NVFP4 reduz o modelo em disco para aproximadamente 35 GB, o que se encaixa bem nos 96 GB de memória em um único RTX PRO 6000 com bastante espaço para KV cache. Cada GPU executa uma instância de modelo independente, e ambas as GPUs são usadas simultaneamente em cargas de trabalho em lote e interativas.

O STAC-AI Operator foi responsável por cada uma dessas execuções. Aplicamos um recurso personalizado⁣BenchmarkRun que referenciava a configuração do SUT para o conjunto completo, e o operador tratou da quantização, ajuste, execução e pós-processamento sem mais intervenção.

Por que usar o Red Hat OpenShift para inferência de LLM?

Uma pergunta que ouvimos com frequência é se uma plataforma em containers apresenta sobrecarga que afete o desempenho de cargas de trabalho sensíveis. Os resultados dessa auditoria oferecem uma forte indicação para a inferência do LLM: a GPU parece ser o gargalo, não a plataforma, e não há nenhum sinal nos dados de que o runtime de container ou o agendamento do OpenShift adicionem sobrecarga significativa ao pipeline de inferência. O próprio comentário do STAC no relatório é consistente com isso: "As camadas de container e orquestração não pareceram introduzir limitações de desempenho materiais na prática." Considerando nossos resultados anteriores e auditados de STAC-N1 (rede) e STAC-A2 (computação de GPU), vemos isso como um terceiro ponto de dados que reforça nossa visão de que o OpenShift pode oferecer o tipo de desempenho que as organizações esperam do bare metal para cargas de trabalho financeiras exigentes.

Mas o valor real da execução no OpenShift vai muito além do desempenho bruto. Nos ambientes de serviços financeiros de produção, você também precisa de políticas de segurança, controle de acesso baseado em função, geração de logs de auditoria, gerenciamento do ciclo de vida e arquitetura multitenancy. O OpenShift oferece tudo isso pronto para uso. Você não precisa escolher entre o desempenho do bare-metal e operações de nível empresarial.

Você também não precisa de um stack paralelo para executar cargas de trabalho de GPU. O mesmo cluster que executou esse benchmark pode executar simultaneamente cargas de trabalho de aplicações, virtualização, tarefas em lote e pipelines de CI/CD. Tudo é executado sob a mesma equipe de operações, a mesma superfície de observabilidade e as mesmas políticas de segurança. Uma equipe que já opera o OpenShift adota uma plataforma de inferência de GPU sem precisar de uma segunda superfície operacional.

O padrão de operador que usamos para este benchmark ilustra um ponto mais amplo: cargas de trabalho complexas de GPU podem ser gerenciadas por meio de APIs nativas em Kubernetes declarativas, sejam conjuntos de benchmark ou disponibilização de LLM de produção. Os usuários descrevem o que querem (modelo, quantização, conjunto de dados); o operador descobre como entregá-lo. Esse padrão é dimensionado da mesma forma que um ambiente de teste de nó único para um cluster de produção de vários nós.

É assim que o Red Hat OpenShift AI é criado. Ele é executado no OpenShift principal com a mesma descoberta de recursos de nó e operadores de GPU NVIDIA, o mesmo modelo de recurso nvidia.com/gpu e o mesmo padrão de operador para gerenciar o desenvolvimento, treinamento, disponibilização e monitoramento de modelos na nuvem, on-premise e edge. A infraestrutura que executou esse benchmark escala diretamente para uma plataforma de IA de produção sem alterar a base subjacente a ela.

O gerenciamento de GPU também é simplificado. Os operadores para descoberta de características de nós e o NVIDIA GPU lidam com a descoberta de hardware, o ciclo de vida do driver e o agendamento de recursos no cluster. Para adicionar novos nós de GPU, basta instalar os operadores; o restante é automático. O mesmo modelo de implantação é executado sem alterações em um cluster do OpenShift de nó único, como o usado aqui, em um cluster compacto de três nós adequado para uma filial, em nós de trabalho remotos na edge ou em um cluster de vários nós em um datacenter regional. Nenhum dos arquivos YAML deste post mudaria para redirecionar para qualquer um deles.

Por fim, todos os benchmarks executados neste projeto são definidos em YAML com controle de versão. Toda configuração é reproduzível. Quando o STAC realizou sua auditoria independente, reproduzimos exatamente o mesmo ambiente e resultados aplicando os mesmos recursos. Esse nível de reprodutibilidade é uma consequência natural do modelo de implantação do Kubernetes; ele é tão valioso para cargas de trabalho de produção quanto para envios de benchmark.

Conclusão

Esses resultados auditados mostram o Red Hat OpenShift executando os tipos de cargas de trabalho de inferência de LLM que as empresas de serviços financeiros usam para avaliar sua infraestrutura de IA, sem nenhuma indicação de sobrecarga da plataforma que limite as GPUs. Combinado com nossos resultados anteriores do STAC-N1 e STAC-A2, isso reforça uma imagem consistente: as organizações podem executar suas cargas de trabalho mais exigentes com desempenho bare-metal, tudo na mesma plataforma OpenShift.

Os resultados auditados completos estão disponíveis no site do STAC. Para ver mais comentários sobre a implementação do TensorRT-LLM e a plataforma de hardware SYS-222C-TN, confira este post do blog da NVIDIA.