 |
| Bellacosa Mainframe e a possivel ponte em ibm z e nvidia sera???? |
☕ Um Café no Bellacosa Mainframe
Homens de Preto no Data Center — Quando o Agente J Encontrou uma GPU no LinuxONE e Perguntou: “Isso Aqui É CUDA ou o Igor Colou um RTX no PCIe?”
Ou: IBM colocou Arm dentro do futuro processador Z, NVIDIA já fala essa língua, o jovem padawan COBOL descobriu que uma placa gráfica não é um pendrive grande — e o Agente J precisou explicar DMA, IOMMU e LPAR antes que alguém chamasse o serviço de manutenção cósmica
Prólogo — uma luz estranha em Armonk
Agente J entrou na sala de máquinas com o Neuralyzer numa mão e um copo de café na outra.
— K, tem uma criatura de silício dizendo que o próximo IBM Z e LinuxONE pode executar Arm nativamente.
— Não a apague da memória, J. A IBM anunciou isso em 24 de agosto de 2026, durante o Hot Chips. É uma das notícias mais importantes para quem trabalha com mainframe desde que alguém resolveu chamar servidor de “legado” sem perceber que o legado estava pagando a conta do banco.
O anúncio descreve um futuro processador de dupla arquitetura para IBM Z e LinuxONE: em vez de haver um núcleo IBM de um lado e um núcleo Arm pendurado do outro, cada núcleo é projetado para executar instruções IBM e Arm de forma nativa. A meta é permitir ambientes Linux Arm ao lado de z/OS e do Linux que já vive em Z/LinuxONE. São planos de produto futuros, sujeitos a mudança; não existe, hoje, um menu da HMC com o botão “instalar CUDA e chamar a NVIDIA”. Mas o desenho muda a conversa inteira.
Para um programador COBOL iniciante, a notícia pode parecer distante. “Eu só quero meu READ, meu WRITE, um Db2 que não dê -911 e um CICS que não transforme a sexta-feira em incidente.” Justamente por isso ela importa. Mainframe não está virando PC gamer; está tentando deixar de ser uma ilha para uma parte maior da economia de software chegar perto daquilo que ele faz melhor: transações, dados críticos, disponibilidade e paranoia institucional bem aplicada.
Easter egg #1: o Agente J não disse “paranoia”. Ele disse “controle de acesso preventivo contra organismos com DMA”. O RACF aprovou a redação.
1. Primeiro: o que a IBM anunciou — e o que ela não anunciou
Vamos separar o café do conhaque.
A IBM anunciou uma direção arquitetural: processador futuro de 2 nm, 11 núcleos acima de 5,7 GHz, aceleradores de inferência e uma DPU de I/O no chip. O ponto realmente extraordinário é a implementação de AArch64/Arm em hardware, não por emulação. A IBM e a Arm dizem que a intenção é executar Linux Arm nativo simultaneamente com ambientes IBM tradicionais e herdar a escala, segurança e resiliência do Z/LinuxONE.
Ela não anunciou:
uma GPU NVIDIA certificada para Z ou LinuxONE;
CUDA em z/OS;
um driver NVIDIA s390x;
um DGX escondido dentro de um frame;
compatibilidade automática com qualquer placa comprada numa promoção suspeita.
Essa distinção protege você de duas doenças profissionais: o entusiasmo que vende PowerPoint como produto e o ceticismo que chama de “marketing” qualquer coisa que ainda não chegou ao rack. A posição correta é mais interessante: existe agora uma ponte arquitetural plausível; atravessá-la exige engenharia, qualificação e acordo comercial.
2. Por que Arm muda o problema da NVIDIA
Historicamente, Linux no IBM Z usa a arquitetura s390x. É excelente no seu território, mas possui um custo invisível: cada fornecedor externo precisa decidir se mantém outra compilação, outro pipeline de testes, outro driver de kernel, outra equipe de suporte e outra matriz de versões para um mercado menor que x86 e Arm.
Imagine que você escreveu um programa COBOL para ler um arquivo VSAM. Não basta entregar o fonte a alguém: é preciso compilador, copybooks, JCL, permissões RACF, dataset correto, testes e alguém responsável quando o job abendar às 02h17. Com uma GPU é igual, só que o “copybook” envolve firmware, PCIe, memória, interrupções e DMA.
NVIDIA já mantém uma pilha madura para Linux AArch64: driver, CUDA Toolkit, compiladores, bibliotecas como cuDNN e NCCL, PyTorch, TensorFlow e uma multidão de aplicações que nasceram para Arm em nuvens e servidores. Grace, Graviton, Ampere e Cobalt ajudaram a transformar Arm server em destino comercial sério.
Assim, a pergunta deixa de ser “NVIDIA, você pode criar e sustentar s390x?” e passa a ser “IBM, o seu ambiente Arm parece suficientemente um servidor Arm convencional para a pilha existente funcionar e ser suportada?”.
É uma diferença brutal:
| Problema antigo | Problema possível no novo cenário |
|---|---|
| Portar uma arquitetura inteira | Qualificar uma plataforma Arm |
| Criar cadeia de ferramentas | Reutilizar uma cadeia AArch64 |
| Testar um mercado exótico | Testar uma variante enterprise de Arm |
| Manter driver específico s390x | Adaptar/validar driver Arm já existente |
Não é garantia. É a troca de “construa uma estrada no oceano” por “a estrada chegou à fronteira; vamos inspecionar a ponte”.
3. Falar Arm não basta: o passaporte chamado SystemReady
Uma CPU saber executar instruções Arm é como o Agente J aprender um idioma alienígena. Útil, mas não informa em qual lado da rua ele deve dirigir, qual tomada existe no hotel ou se o passaporte abre a porta da alfândega.
Para Linux e drivers, o mundo abaixo da aplicação importa muito. Eles precisam reconhecer um ambiente previsível: firmware de boot, tabelas de hardware, relógios, controladores de interrupção, memória, PCIe, IOMMU, ACPI/UEFI e regras de descoberta de dispositivos. É isso que padrões como Arm SBSA, requisitos de boot e o programa Arm SystemReady tentam normalizar.
Relatos técnicos do Hot Chips indicam AArch64 v9.3, SVE/SVE2, operação little-endian do lado Arm e direção SystemReady. A consequência pretendida é preciosa: distribuições e binários Arm “de prateleira” teriam muito menos motivo para perguntar “que bicho é este?”. A própria NVIDIA construiu Grace mirando SBSA/SystemReady porque padrões reduzem o número de adaptações especiais que software precisa carregar.
Em linguagem de sala verde: SystemReady é a diferença entre receber um fonte COBOL e torcer para que compile, ou receber o fonte mais o padrão de dataset, o JCL, as PROCs, os parâmetros e a documentação de instalação. O primeiro funciona numa demo. O segundo tem chance de sobreviver à produção.
4. “Mas a GPU é PCIe; não é só encaixar?”
Não. E aqui o Agente J recolhe delicadamente a chave de fenda da mão do Igor.
PCIe é uma interconexão, não um contrato completo de convivência. A GPU precisa ser enumerada pelo sistema, expor regiões de memória mapeada (MMIO/BARs), gerar interrupções, ser reinicializada após falha, conversar com o driver e receber energia e refrigeração adequadas. O driver precisa enxergar topologia correta, páginas de memória, acesso DMA, recursos de virtualização e mecanismos de erro.
E uma GPU não fica esperando a CPU carregar cada byte como um garçom levando café de colher em colher. Ela usa DMA — Direct Memory Access. Simplificando, depois de autorizada, transfere dados diretamente entre sua memória e a memória do host. Isso é essencial para desempenho: modelos, tensores e lotes de inferência seriam ridiculamente lentos se cada movimento tivesse de passar pela CPU como um MOVE de bilhões de bytes.
No notebook de Igor, um driver malcomportado pode congelar a tela e produzir uma noite de palavrões. Em um LinuxONE, a máquina hospeda muitos clientes lógicos, com isolamento e disponibilidade que não podem depender de boa vontade de uma placa. Aí entra a IOMMU.
5. IOMMU: o segurança que não deixa a GPU passear pelo prédio
IOMMU significa, em essência, unidade que traduz e controla endereços de memória usados por dispositivos de I/O. Pense nela como o segurança de um edifício bancário. A GPU do LPAR A recebeu autorização para entrar na sala A-17; isso não lhe dá licença para testar todas as portas do corredor, muito menos alcançar a memória do LPAR B ou do ambiente de gestão.
Uma configuração segura precisa associar dispositivo, função virtual, LPAR e faixas de memória de maneira estrita. O driver pede uma operação; hardware e firmware garantem que o dispositivo veja apenas o que lhe foi atribuído. A ideia se parece com RACF: autenticar o usuário é apenas o começo; é a autorização de cada recurso que impede o desastre.
Mas atenção: “há IOMMU” não é uma frase mágica. Drivers NVIDIA têm requisitos e particularidades conforme GPU, kernel, topologia PCIe e virtualização. Há recursos de alta performance, como comunicação direta entre GPU e NIC, que podem depender de decisões de ACS, peer-to-peer e posicionamento físico. Em outras palavras: a placa pode funcionar para inferência simples e ainda não estar pronta para cada truque de HPC, NVLink ou multi-GPU.
6. LPAR, z/VM e a diferença entre dividir e bagunçar
Um LPAR é uma partição lógica: uma máquina dentro da máquina, separada por hardware e firmware. Para o iniciante, compare-o a uma região CICS muito séria, com seu próprio universo operacional — só que o isolamento não é mera convenção de software.
O caminho inicial mais sensato seria algo parecido com isto:
A IBM certifica um modelo específico de GPU e o respectivo drawer PCIe.
A HMC/firmware atribui a função física ou virtual a uma LPAR Arm Linux.
Esse Linux vê um dispositivo PCIe compatível, carrega driver NVIDIA Arm64 e o CUDA runtime.
O aplicativo usa a GPU; o IOMMU restringe o DMA à memória autorizada.
Telemetria, manutenção, falhas e troca de peça entram no modelo operacional IBM.
O primeiro alvo não precisa ser compartilhar uma placa com trinta tenants. Pass-through para uma LPAR, bem cercado, já seria uma vitória enorme. Depois vêm os chefes de fase: MIG, vGPU, SR-IOV, cobrança, reset seletivo, migração, isolamento multi-tenant e recuperação automática.
7. Spyre: o precedente que ajuda, sem virar atalho enganoso
A IBM já vende o Spyre Accelerator para z17 e LinuxONE Emperor 5. É uma placa PCIe orientada a inferência e fine-tuning, com runtime, driver, firmware e integração de software próprios. A solução suporta até 48 placas em sistemas Z/LinuxONE e foi desenhada com appliances de suporte, funções virtuais, monitoramento e redundância de caminhos.
Isso importa porque prova uma coisa concreta: IBM não está começando agora a discutir “como colocar um acelerador poderoso, que faz DMA, num mainframe particionado sem transformar o equipamento numa lan house cósmica”. Ela já tem práticas para atribuição, saúde do dispositivo, tolerância a falha e operação.
Mas Spyre não é uma GPU NVIDIA pintada de azul. Ele é uma solução vertical: IBM controla hardware, firmware, compilador, runtime e o suporte. CUDA traria outro ecossistema, outra cadência de drivers e outra responsabilidade dividida. Spyre diminui o risco de integração; não elimina a negociação com NVIDIA.
8. Telum, Spyre e CUDA não são três nomes para a mesma coisa
| Tecnologia | Onde brilha | Exemplo |
| Telum | Inferência muito próxima da transação | Pontuar fraude durante a autorização |
| Spyre | IA empresarial integrada e eficiente | Servir modelos e fine-tuning controlado |
| GPU NVIDIA/CUDA | Ecossistema amplo e computação acelerada | PyTorch, visão, LLMs, analytics e bibliotecas CUDA |
O desenho vencedor não é substituir um pelo outro. É usar cada peça onde tem vocação.
Uma transação chega pelo CICS. O programa COBOL executa regras, chama Db2 e precisa decidir agora: aprovar, bloquear ou pedir segundo fator. Telum pode atender a inferência ultrarrápida. Um serviço Arm Linux pode, assíncronamente ou numa etapa apropriada, executar análise mais pesada em CUDA: enriquecer evento, correlacionar fraude, gerar explicação para analista, fazer busca vetorial, analisar imagens de documento ou retreinar um modelo.
O COBOL não precisa aprender CUDA para participar. Ele precisa aprender a pedir serviço de forma confiável: API, MQ, eventos, timeouts, idempotência, commit e rollback. O padawan que entende isso não vira passageiro do futuro; vira o adulto na sala quando alguém propõe chamar um modelo de 70 bilhões de parâmetros no meio de uma transação de 80 milissegundos.
Easter egg #2: o Agente J proibiu
CALL 'CHATGPT'dentro do caminho crítico. Igor perguntou se ao menos poderia fazer umGOTO 9999para o modelo. O Agente K desligou o monitor.
9. O inimigo físico: potência, calor e topologia
É tentador imaginar oito B200 surgindo de um drawer como alienígenas de um ovo. Só que uma GPU de datacenter de ponta pode consumir centenas de watts; sistemas HGX/NVSwitch exigem potência, refrigeração, espaço e rede próprios. NVLink não é “PCIe com café forte”.
Portanto, mesmo que CUDA se torne viável, o primeiro produto provável seria uma GPU PCIe específica e homologada para inferência ou aceleração selecionada, entregue a uma LPAR Arm. Um superpod para treinar modelo de fronteira provavelmente continuará sendo infraestrutura dedicada, conectada ao Z/LinuxONE por rede rápida e governada como outro domínio.
Mainframe não precisa vencer um DGX no campeonato errado. O valor está em reduzir a distância entre dado crítico, transação, segurança e capacidade de IA — sem copiar meio banco para uma plataforma externa só para fazer uma pergunta ao modelo.
10. Roteiro prático para o programador COBOL iniciante
Você não precisa comprar uma GPU nem decorar registradores Arm amanhã. Faça esta trilha:
Domine transação. Entenda CICS, Db2, VSAM, unidade de trabalho, syncpoint,
COMMITeROLLBACK. IA sem integridade transacional é Igor vendendo PIX por e-mail.Aprenda a fronteira. Veja JSON, HTTP, APIs REST, MQ e eventos. Seu COBOL continuará sendo o coração de muitos processos; ele precisa conversar sem acoplamento burro.
Conheça Linux e containers. Não para abandonar Z, mas para entender onde os serviços Arm e IA vão viver. Um container não é uma LPAR; ambos isolam, mas em níveis diferentes.
Entenda os quatro D’s. Dados, DMA, dispositivos e dependências. Pergunte sempre: onde o dado nasce, quem pode movê-lo, quem o enxerga e como o processo se recupera?
Aprenda observabilidade. Latência, throughput, erro, saturação, logs e rastreamento. “A IA ficou lenta” não é diagnóstico; é o equivalente moderno a “deu ABEND”.
Pense em governança. Modelo pode errar, vazar, enviesar e mudar. Dados bancários ou pessoais não ganham permissão para viajar só porque a demo ficou bonita.
11. As perguntas que realmente importam agora
Quando surgirem detalhes, não pergunte primeiro “quantos teraflops?”. Pergunte:
Qual nível de certificação SystemReady a IBM entregará?
Quais distribuições Arm bootam sem alteração?
Como PCIe e IOMMU aparecem para a LPAR Arm?
Haverá GPU pass-through? Virtualização? MIG/vGPU?
Quais modelos, drivers e versões CUDA serão homologados?
Como são feitos reset, firmware update, diagnóstico e failover?
Qual é a latência entre o dado em z/OS/Db2 e o serviço acelerado?
O caso de uso justifica trazer a IA para perto, ou MQ/API para infraestrutura externa já resolve melhor?
Essas perguntas são mais maduras que “roda Doom?”. Embora, em nome da ciência, o Agente J tenha anotado a segunda numa planilha confidencial.
Epílogo — a ponte não é o destino
A IBM não entregou CUDA no mainframe em agosto de 2026. Entregou algo talvez mais estratégico: uma tentativa de tornar o próximo Z/LinuxONE um anfitrião Arm suficientemente padrão para que ecossistemas já existentes possam reconhecê-lo.
Para NVIDIA, isso pode converter um port caro e exclusivo para s390x em uma qualificação de plataforma Arm. Para IBM, é uma maneira ousada de reduzir o isolamento histórico de sua arquitetura. Para clientes, pode significar aproximar software moderno e aceleradores dos dados mais críticos sem abandonar as qualidades que fizeram o mainframe sobreviver a cada funeral prematuro anunciado desde os anos 1980.
E para nós, do COBOL, a lição é confortavelmente simples: o futuro não exige que você esqueça o que sabe. Exige que você entenda onde seu programa termina, onde o serviço começa, como o dado atravessa a fronteira e quem responde quando a GPU, o driver ou o universo resolve dar ABEND.
O Agente K guardou o Neuralyzer.
— Então não apagamos a memória do anúncio?
— Não, J. Só colocamos uma nota no rodapé: “promissor, tecnicamente difícil, comercialmente aberto e absolutamente incapaz de ser instalado pelo Igor numa sexta-feira às 17h58”.
E, por uma vez, até o RACF concordou.
