Red Hat OpenShift offre inferenza LLM ad alte prestazioni per i servizi finanziari

Nell'era dell’IA, caratterizzata da carichi di lavoro ad elevato utilizzo di risorse, il settore dei servizi finanziari, come molti altri, punta a sfruttare al meglio il proprio hardware. Le società di servizi finanziari si affidano ai vantaggi di un'architettura basata sui container, ma potrebbero temere che le piattaforme di orchestrazione aggiungano cali di prestazioni in grado di esacerbare i vincoli delle risorse. 

I risultati del nuovo audit di STAC-AI™ LANG6 (Inference-Only), il benchmark standard di settore per la valutazione delle prestazioni dell'inferenza dei modelli linguistici di grandi dimensioni (LLM) nei servizi finanziari, può contribuire a placare queste preoccupazioni intorno all’utilizzo di Red Hat OpenShift. In collaborazione con NVIDIA e Supermicro, il team Red Hat Performance and Scale Engineering ha eseguito la suite di benchmark STAC-AI LANG6 completa su OpenShift, utilizzando due GPU NVIDIA RTX PRO 6000 Blackwell Server Edition in un Supermicro SuperServer SYS-222C-TN. Questi sono i primi risultati verificati di STAC-AI prodotti su una piattaforma Kubernetes containerizzata.

Red Hat dimostra da tempo che OpenShift offre prestazioni simili al bare metal per i carichi di lavoro più impegnativi e sostiene questa affermazione con risultati verificati in modo indipendente. Nel benchmark di rete STAC-N1, abbiamo dimostrato che OpenShift eguaglia (e in alcuni casi è migliore) la latenza bare metal per i dati di mercato, registrando le latenze medie e mediane più basse sia a 100.000 che a 1,4 milioni di messaggi al secondo, riducendo al contempo la latenza massima del 37%. Nel benchmark STAC-A2 per il rischio di mercato, abbiamo superato diversi record per la simulazione Monte Carlo con accelerazione GPU su OpenShift con sistemi NVIDIA DGX A100. In STAC-A2 con CPU Intel, abbiamo dimostrato che il sovraccarico di containerizzazione di OpenShift è trascurabile anche per i carichi di lavoro del settore finanziario a elevato utilizzo di CPU.

Questo nuova attribuzione di STAC-AI estende il record al dominio dell'inferenza LLM. Si tratta di un'area di importanza sempre maggiore, poiché gli istituti finanziari adottano flussi di lavoro basati sull'IA per il rilevamento delle frodi, per la sicurezza, l'analisi dell’opinione degli utenti e per la conformità normativa.

Breve introduzione a STAC-AI LANG6

Lo Strategic Technology Analysis Center (STAC) produce benchmark standardizzati che i più grandi istituti finanziari del mondo utilizzano per valutare le offerte tecnologiche. STAC-AI LANG6 misura le prestazioni dell'inferenza LLM negli scenari di utilizzo dei servizi finanziari. I suoi set di dati derivano da documenti finanziari SEC EDGAR reali, i tipi di documenti che guidano la RAG (retrieval-augmented generation) e i carichi di lavoro a contesto lungo nelle società finanziarie.

Il benchmark copre due modalità di inferenza. La modalità batch misura il throughput massimo trasmettendo l'intero set di dati al sistema sottoposto a test (SUT) con una singola chiamata API. La modalità interattiva simula l'utilizzo nel mondo reale inviando le richieste a velocità di arrivo variabili seguendo la distribuzione di Poisson, misurando inoltre il tempo di reazione (analogo al tempo per il primo token), il tempo di risposta e la velocità di output sotto carico.

Abbiamo testato due modelli (Llama-3.1-8B-Instruct e Llama-3.1-70B-Instruct) su quattro set di dati EDGAR che variano per lunghezza e complessità dei prompt. Il benchmark misura anche la fedeltà: la corrispondenza tra l'output del modello ottimizzato e lo stesso modello eseguito con precisione nativa su un SUT di riferimento di STAC. In totale, la specifica richiede sette carichi di lavoro obbligatori. 

Tabella 1. Modello, set di dati e modalità di esecuzione del benchmark STAC-AI

La tecnologia

Hardware:

• Supermicro SuperServer SYS-222C-TN, un server DC-MHS 2U
• 2 CPU Intel Xeon 6730P (64 core fisici in totale)
• 2 TiB DDR5-5200 (32 DIMM da 64 GiB)
• 2 GPU NVIDIA RTX PRO 6000 Blackwell Server Edition (96 GiB GDDR7 ciascuna)

Software:

• Red Hat OpenShift 4.20 (OpenShift; un nodo)
• Red Hat Enterprise Linux CoreOS 9.6
• Node Feature Discovery Operator
• NVIDIA GPU Operator
• STAC-AI Operator (operatore personalizzato sviluppato da Red Hat)
• NVIDIA TensorRT-LLM 1.2.0rc2 (backend PyTorch) con quantizzazione NVFP4 tramite NVIDIA Model Optimizer 0.37.0

Lo stack di operatori segue lo stesso schema stabilito nel nostro lavoro STAC-A2. L'operatore Node Feature Discovery è il prerequisito: rileva le funzionalità hardware su ciascun nodo e le presenta come etichette Kubernetes. L'operatore NVIDIA GPU utilizza queste etichette per determinare dove distribuire i container dei driver GPU, mettendo le GPU a disposizione dello scheduler come risorse nvidia.com/gpu. Da quel momento in poi, un pod richiede le GPU nello stesso modo in cui richiede CPU o memoria.

Con l'installazione di questi due operatori, le GPU diventano risorse Kubernetes di primo piano. Non sono necessari l'installazione manuale dei driver, configurazioni host speciali o moduli del kernel personalizzati. Lo stesso approccio funziona sia con un singolo nodo GPU all'edge sia con un cluster in un datacenter.

Su questa base, abbiamo aggiunto l'operatore STAC-AI per orchestrare il benchmark stesso.

L'operatore STAC-AI

L'esecuzione di un benchmark STAC-AI end-to-end implica molte parti in movimento: quantizzazione del modello con la precisione desiderata, blocco dei clock della GPU e dei limiti di potenza, esecuzione del sistema di test del benchmark su più carichi di lavoro e velocità di arrivo, tracciamento di alimentazione e temperatura in modo sincrono con ciascuna esecuzione e, infine, analisi della fedeltà rispetto a un modello di riferimento. L'esecuzione manuale di tutte queste operazioni richiede tempo, è soggetta a errori e difficile da riprodurre. L'operatore STAC-AI rende dichiarativo l'intero flusso di lavoro.

Risorse personalizzate

L'operatore introduce tre definizioni di risorse personalizzate (CRD).

• Implementation registra un backend LLM disponibile (come TensorRT-LLM) insieme alle immagini dei container, ai modelli e ai set di dati supportati.
• BenchmarkRun è la risorsa principale. Dichiara l'esecuzione di un singolo benchmark: quale implementazione utilizzare, quale modello e set di dati testare, il metodo di quantizzazione, l'allocazione della GPU e se eseguire l'analisi della fedeltà post-elaborazione. L'operatore gestisce tutto da lì.
• BenchmarkImageBuild gestisce la creazione una tantum dell'immagine del container per lo stack TensorRT-LLM.

Gestione del ciclo di vita

Quando crei un BenchmarkRun, l'operatore lo guida attraverso una macchina a stati:

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

In ogni fase, l'operatore crea processi Kubernetes per eseguire il lavoro. Rileva e applica automaticamente la velocità di clock massima della GPU e i limiti di alimentazione tramite nvidia-smi, gestisce una coda di esecuzione sequenziale in modo che venga eseguito un solo benchmark alla volta (evitando conflitti tra GPU tra le esecuzioni) e gestisce la fase di analisi della fedeltà utilizzando vLLM come riferimento. Se un passaggio non riesce, l'esecuzione passa allo stato Failed con un codice motivo specifico, semplificando la diagnosi.

Esegui un benchmark

Ecco cosa serve per eseguire un carico di lavoro controllato:

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

Questo YAML rappresenta l'intera interazione dell'utente. Applica la risorsa e l'operatore gestirà la quantizzazione del modello, l'ottimizzazione della GPU, l'esecuzione del benchmark, l'acquisizione di potenza e temperatura e l'analisi della fedeltà. I parametri specifici del carico di lavoro (dimensioni dei batch, lunghezze delle sequenze, velocità di arrivo) vengono inseriti tramite una ConfigMap, in modo da poter testare diverse configurazioni senza dover ricreare le immagini dei container.

Per eseguire la suite STAC-AI LANG6 completa, abbiamo applicato un singolo BenchmarkRun, il quale fa riferimento a una configurazione SUT che definisce tutti e sette i carichi di lavoro. In questo modo, l'operatore avvia il sistema di test del benchmark (come definito dalla risorsa personalizzata) e il sistema esegue ciascun carico di lavoro in sequenza (come definito dalla configurazione SUT). La potenza e la temperatura dell'aria in ingresso vengono acquisite durante ogni periodo di misurazione tramite un analizzatore di potenza di precisione Yokogawa WT1804R (interrogato tramite VXI-11/SCPI dal pod del benchmark) e una sonda Dallas DS18B20 tramite seriale USB.

Risultati

I risultati verificati nelle tabelle 2 e 3 sono tratti dal report STAC ufficiale. Tutti i carichi di lavoro sono stati quantizzati in NVFP4 con cache KV FP8, e ogni GPU esegue un'istanza del modello indipendente.

Tabella 2. Risultati della modalità batch

Tabella 3. Risultati della modalità interattiva (frequenza di arrivo sostenuta più elevata)

Ecco alcune osservazioni dai risultati verificati.

• Elevata efficienza spaziale da un fattore di forma 2U. Secondo il report STAC, il sistema SYS-222C-TN 2U ha offerto un'efficienza spaziale batch superiore rispetto al sistema NVIDIA GH200 più grande, in ogni carico di lavoro paragonabile (9,501 milioni contro 6,148 milioni di parole per ft³·ora su EDGAR4a, 1,428 milioni contro 799.500 su EDGAR4b e 237.400 contro 226.900 su EDGAR5a), completando l'intero set di carichi di lavoro riportati con solo due GPU.
• NVFP4 permette ai modelli da 70 miliardi di parametri di funzionare agevolmente su una singola GPU. La quantizzazione di Llama-3.1-70B-Instruct in NVFP4 riduce le dimensioni del modello su disco a circa 35 GB, valore che rientra ampiamente nei 96 GB di memoria di una singola RTX PRO 6000, con ampio margine per la cache KV. Ogni GPU esegue un'istanza del modello indipendente ed entrambe vengono utilizzate contemporaneamente nei carichi di lavoro batch e interattivi.

L'operatore STAC-AI è stato responsabile di ognuna di queste esecuzioni. Abbiamo applicato una risorsa personalizzata BenchmarkRun che faceva riferimento alla configurazione SUT per l'intera suite e l'operatore ha gestito quantizzazione, ottimizzazione, esecuzione e post-elaborazione senza ulteriori interventi.

Perché scegliere Red Hat OpenShift per l'inferenza LLM

Spesso ci viene chiesto se una piattaforma containerizzata introduca un sovraccarico tale da influire sui carichi di lavoro sensibili alle prestazioni. I risultati di questo audit forniscono un'indicazione chiara per l'inferenza LLM: sembra che sia la GPU a rallentare le attività, non la piattaforma, e i dati non indicano che il runtime o la pianificazione dei container di OpenShift aggiungano un sovraccarico significativo alla pipeline di inferenza. Il commento di STAC nel report è coerente con questa l’osservazione seguente. "I livelli di container e di orchestrazione non sembrano introdurre, nella pratica, limitazioni significative alle prestazioni". Insieme ai nostri precedenti risultati verificati STAC-N1 (rete) e STAC-A2 (elaborazione GPU), questo rappresenta un terzo punto dati che rafforza la nostra opinione: OpenShift può offrire le prestazioni che le organizzazioni si aspettano dal bare metal per i carichi di lavoro finanziari più impegnativi.

Il valore reale dell'esecuzione su OpenShift va ben oltre le pure prestazioni. Negli ambienti di produzione dei servizi finanziari, sono necessari anche criteri di sicurezza, controllo degli accessi basato sui ruoli, registrazione degli audit, gestione del ciclo di vita e multitenancy. OpenShift offre tutto questo in modo nativo. Non devi scegliere tra prestazioni simili al bare metal e operazioni di livello enterprise.

Inoltre, non serve uno stack parallelo per eseguire i carichi di lavoro GPU. Lo stesso cluster che ha eseguito questo benchmark può gestire contemporaneamente carichi di lavoro applicativi, virtualizzazione, processi batch e pipeline CI/CD. Tutto viene gestito dallo stesso team operativo, con la stessa superficie di osservabilità e gli stessi criteri di sicurezza. Un team che già utilizza OpenShift può adottare una piattaforma di inferenza GPU senza dover gestire una seconda superficie operativa.

Il modello di operatore usato per questo benchmark illustra un concetto più ampio: i carichi di lavoro GPU complessi possono essere gestiti tramite API Kubernetes native dichiarative, che si tratti di set di benchmark o di servizi LLM in produzione. Gli utenti descrivono ciò che desiderano (modello, quantizzazione, set di dati) e l'operatore determina come realizzarlo. Questo modello è scalabile allo stesso modo da un ambiente di test a nodo singolo a un cluster di produzione multinodo.

Questo è anche il modo in cui è progettato Red Hat OpenShift AI. Viene eseguito su OpenShift core con gli stessi operatori Node Feature Discovery e NVIDIA GPU, lo stesso modello di risorse nvidia.com/gpu e lo stesso modello di operatore per gestire sviluppo, addestramento, distribuzione e monitoraggio dei modelli tra ambenti cloud, on premise ed edge. L'infrastruttura che ha eseguito questo benchmark è scalabile direttamente in una piattaforma IA di produzione, senza modificare la base.

La gestione delle GPU è semplificata in modo analogo. Gli operatori Node Feature Discovery e NVIDIA GPU gestiscono il rilevamento dell'hardware, il ciclo di vita dei driver e la pianificazione delle risorse in tutto il cluster. L'aggiunta di nuovi nodi GPU richiede solo l'installazione degli operatori; il resto è automatico. Lo stesso modello di deployment viene eseguito invariato su un cluster OpenShift a nodo singolo come quello qui utilizzato, un cluster compatto a tre nodi adatto a una filiale, nodi worker remoti all'edge o un cluster multinodo in un datacenter regionale. Nessuno degli elementi YAML in questo post cambierebbe per adattarsi a queste diverse configurazioni.

Infine, ogni benchmark eseguito in questo progetto è definito in YAML con controllo delle versioni. Ogni configurazione è riproducibile. Quando STAC ha eseguito l'audit indipendente, abbiamo riprodotto lo stesso ambiente e gli stessi risultati applicando le medesime risorse. Questo livello di riproducibilità è una conseguenza naturale del modello di deployment di Kubernetes ed è prezioso per i carichi di lavoro di produzione tanto quanto per i benchmark.

Conclusione

Questi risultati verificati mostrano Red Hat OpenShift mentre esegue i carichi di lavoro di inferenza LLM utilizzati dalle società di servizi finanziari per valutare le proprie infrastrutture IA, senza alcun segno di sovraccarico della piattaforma che limiti le GPU. Insieme ai precedenti risultati STAC-N1 e STAC-A2, questo conferma un quadro coerente: le organizzazioni possono eseguire i carichi di lavoro più esigenti con prestazioni bare metal, tutto sulla stessa piattaforma OpenShift.

I risultati completi dell'audit sono disponibili sul sito web di STAC. Per ulteriori commenti sull'implementazione di TensorRT-LLM e sulla piattaforma hardware SYS-222C-TN, consulta questo post di NVIDIA.