Em 5 de novembro de 2026, a Supermicro anunciou uma solução de armazenamento compartilhado de cache KV para inferência de IA, desenvolvida com IBM e NVIDIA. A IBM Redbooks já descrevia a arquitetura e os testes em um documento cuja página indica publicação em 5 de junho e atualização em 20 de agosto de 2026, antes do anúncio de novembro. Comunicado da Supermicro e documento técnico da IBM.
A solução combina servidores all-flash Supermicro Petascale, IBM Storage Scale, NVIDIA Dynamo e rede NVIDIA Spectrum-X Ethernet. Os resultados divulgados pela IBM vêm de uma configuração específica de hardware e software, não de uma medição aplicável automaticamente a qualquer modelo ou carga de trabalho.
O papel do cache KV compartilhado
O cache KV guarda estados de chave e valor já calculados pelo modelo, para que possam ser reutilizados em vez de recalculados quando o contexto se repete. Na arquitetura descrita pela IBM, o armazenamento compartilhado é a camada G4. No ensaio que usou essa camada, o NVIDIA Dynamo buscava os dados no armazenamento remoto, transferia-os para a memória do servidor e, depois, para a memória da GPU em blocos.
A arquitetura também organiza a memória da GPU como G1, a memória RAM do sistema como G2 e o armazenamento NVMe local como G3. No teste G4 descrito pela IBM, as camadas G1 e G2 de cache foram desativadas. Assim, os dados reutilizados precisavam percorrer o caminho entre o armazenamento compartilhado, a memória do servidor e a GPU.
A configuração por trás dos testes
O ensaio documentado usou IBM Storage Scale Erasure Code Edition (ECE) v6.0.0.1, NVIDIA Dynamo v0.9.0+ e vLLM v0.14.1, com o modelo openai/gpt-oss-120b pré-quantizado para MXFP4. O cache KV foi configurado em FP16.
O armazenamento era formado por oito servidores Supermicro Petascale ASG-1115S-NE316R. Cada nó tinha um processador AMD EPYC 9535 e 16 unidades Micron E3 de 7,68 TB. O cliente de GPU era um Supermicro SYS-212GB-FNR com quatro GPUs NVIDIA RTX PRO 6000 instaladas; o documento descreve o teste do modelo em uma única GPU.
O resultado só ganha significado junto do modelo, do software e da carga de trabalho usados para medi-lo.
O que os resultados divulgados medem
TTFT é o tempo até a geração do primeiro token. Já RPS indica quantas solicitações o sistema processa por segundo. A IBM apresenta os dois tipos de medição em ensaios separados:
| Ensaio | Carga e condição | Resultado divulgado pela IBM |
| TTFT, uma solicitação | Prompt de até 130.000 tokens; modelo de 120 bilhões de parâmetros | Até 56× de aceleração aos 130.000 tokens. Com cache, o TTFT ficou entre 0,193 e 0,57 s no intervalo de prompts testado; sem cache, chegou a 32,14 s aos 130.000 tokens. |
| Vazão com cache G4 | 200 solicitações, 28 conexões simultâneas e 100 prompts; o cache começou vazio | 0,19 RPS com recomputação na GPU e 4,26 RPS com IBM Storage Scale ECE. Os tempos totais informados foram 1.048 s e 46,94 s, respectivamente. |
| Teste com tráfego concorrente | Quatro clientes geraram 200 GB/s de tráfego de rede concorrente; 200 solicitações com cache | 3,6 RPS e 55,56 s para concluir as solicitações, contra 4,26 RPS no teste sem esse tráfego. |
No teste de vazão, os 200 pedidos foram selecionados entre 100 prompts, que representavam 24 milhões de tokens e 825 GB de dados de cache KV. Como o cache começou vazio, a média da execução incluiu o período inicial de preenchimento.
Nos valores arredondados divulgados pela IBM, a queda de 4,26 para 3,6 RPS corresponde a aproximadamente 15,5%. O documento chama a redução de 18%, mas esse percentual não resulta dos valores exibidos.
A IBM também informa até 315 GB/s de leitura para o conjunto de oito nós de armazenamento. A configuração de rede dos clientes podia usar até 80 GB/s, e os clientes não chegaram a exercitar por completo a capacidade de leitura informada para o armazenamento.
