COBOL: a linguagem de 1959 que ainda movimenta bancos, governos e grandes empresas

Quando uma transferência bancária é processada, uma folha de pagamento é calculada ou uma apólice de seguro é atualizada, existe uma possibilidade real de que alguma etapa dessa operação passe por um programa escrito em COBOL. A linguagem nasceu antes da internet, dos computadores pessoais e dos bancos de dados relacionais, mas continua presente em sistemas que não podem simplesmente parar para serem reconstruídos.

O COBOL raramente trabalha sozinho: ele faz parte de um ecossistema que reúne mainframes, bancos de dados, processamento em lote, mensageria, APIs e aplicações modernas.

Essa longevidade costuma produzir duas interpretações opostas. Para alguns, o COBOL é uma relíquia que deveria ter desaparecido há décadas. Para outros, é uma tecnologia tão confiável que não existe motivo para substituí-la. As duas visões simplificam um problema muito mais interessante.

O COBOL não continua em uso apenas porque empresas resistem à mudança. Ele permanece porque décadas de regras comerciais, cálculos financeiros, exceções operacionais e exigências regulatórias foram incorporadas aos programas. Em muitos casos, o código representa uma parte da memória institucional da organização.

O que é COBOL?

COBOL é a sigla para Common Business-Oriented Language, ou Linguagem Comum Orientada a Negócios. Trata-se de uma linguagem compilada de alto nível, criada especificamente para aplicações administrativas e processamento de dados empresariais.

Seu objetivo nunca foi controlar foguetes, desenvolver jogos ou realizar cálculos científicos avançados. O COBOL foi pensado para tarefas como:

• processar folhas de pagamento;
• calcular juros e parcelas;
• atualizar saldos;
• emitir faturas;
• consolidar movimentações financeiras;
• administrar apólices de seguro;
• controlar estoques;
• gerar relatórios;
• processar grandes arquivos de registros;
• validar operações segundo regras de negócio.

Uma de suas características mais conhecidas é a sintaxe relativamente próxima do inglês. Um programa simples pode conter instruções como MOVE, ADD, SUBTRACT, COMPUTE, READ, WRITE, PERFORM e DISPLAY.

Um exemplo básico seria:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CALCULA-SALDO.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 SALDO-ATUAL    PIC S9(9)V99 COMP-3.
       01 VALOR-DEPOSITO PIC S9(9)V99 COMP-3.

       PROCEDURE DIVISION.
           ADD VALOR-DEPOSITO TO SALDO-ATUAL
           DISPLAY "NOVO SALDO: " SALDO-ATUAL
           STOP RUN.

A aparência pode parecer incomum para quem começou a programar em Python, JavaScript ou Java. Ainda assim, o propósito do código é razoavelmente legível: adicionar o valor de um depósito ao saldo atual.

A linguagem também se destaca pelo tratamento de números decimais de ponto fixo. Isso é importante em sistemas financeiros, nos quais erros de arredondamento podem produzir diferenças contábeis. A IBM descreve o COBOL como especialmente adequado ao processamento confiável e volumoso de dados comerciais, incluindo arquivos sequenciais, indexados e relativos.

Uma linguagem criada para resolver a fragmentação

No final da década de 1950, os computadores eram equipamentos grandes, caros e profundamente incompatíveis entre si. Cada fabricante possuía arquiteturas, sistemas e linguagens próprias. Um programa desenvolvido para uma máquina geralmente precisava ser reescrito para funcionar em outra.

Essa dependência preocupava governos e grandes empresas. Trocar de fornecedor não significava apenas comprar um computador novo: podia exigir a reconstrução de todo o conjunto de programas administrativos.

Em 1959, representantes do governo dos Estados Unidos, fabricantes de computadores e grandes organizações formaram o Conference on Data Systems Languages, conhecido como CODASYL. O grupo buscava criar uma linguagem comum, voltada ao processamento de dados comerciais e menos dependente de um fabricante específico.

Grace Hopper teve influência decisiva nesse processo por meio de seu trabalho com compiladores e com o FLOW-MATIC, uma linguagem que permitia descrever operações comerciais com instruções semelhantes ao inglês. É impreciso, porém, afirmar que Hopper criou o COBOL sozinha. A linguagem foi resultado do trabalho coletivo de comitês técnicos, instituições públicas e empresas.

A primeira especificação foi apresentada em 1960. O COBOL recebeu revisões sucessivas e foi padronizado pelo ANSI em 1968. Vieram depois versões como COBOL-74, COBOL-85, COBOL 2002, COBOL 2014 e COBOL 2023. A atual norma publicada é a ISO/IEC 1989:2023, que define a sintaxe e a semântica da linguagem e busca preservar seu grau de independência entre diferentes sistemas de processamento.

O fato de existir uma especificação publicada em 2023 — e de uma nova revisão estar em desenvolvimento — mostra que o COBOL não é apenas um artefato histórico congelado em 1959.

A importância dos mainframes

Embora possa ser executado em outros ambientes, o COBOL tornou-se fortemente associado aos mainframes. Esses computadores foram construídos para processar grandes volumes de dados com disponibilidade, segurança, controle de acesso e previsibilidade operacional.

A família IBM System/360, apresentada em 1964, teve papel importante nessa expansão. A proposta de uma arquitetura compatível entre diferentes modelos permitia que empresas ampliassem sua capacidade de processamento sem abandonar todo o software já desenvolvido.

O mainframe transformou-se na base de sistemas bancários, seguradoras, empresas aéreas, governos, indústrias, redes varejistas e grandes processadores de pagamentos. O COBOL encontrou nesse ambiente um espaço ideal: processamento de arquivos extensos, cálculos comerciais, tarefas repetitivas e milhões de transações que exigiam consistência.

Ainda hoje, organizações brasileiras mantêm operações importantes em mainframes. Um caso documentado é o do Banco do Brasil, que utiliza tecnologias Db2 for z/OS e IBM Z para disponibilizar dados corporativos e sustentar consultas realizadas por milhares de painéis internos. O Banco de Brasília também mantém uma infraestrutura baseada em IBM Z, z/OS, CICS e Db2.

Esses exemplos não significam que todo o sistema esteja escrito em COBOL. Eles demonstram que a plataforma na qual muitas aplicações COBOL tradicionalmente operam continua presente em instituições brasileiras relevantes.

COBOL nunca foi uma tecnologia isolada

É comum imaginar um programador escrevendo COBOL em uma tela preta e controlando sozinho todo o sistema. Na prática, aplicações corporativas são formadas por várias tecnologias interdependentes.

Aprender a sintaxe do COBOL é apenas a primeira parte. Para compreender uma aplicação real, o profissional normalmente precisa conhecer componentes de execução, armazenamento, segurança, comunicação e automação.

JCL e o processamento em lote

O Job Control Language, ou JCL, é usado no ambiente z/OS para descrever trabalhos que serão executados pelo computador.

O JCL não substitui o COBOL. Sua função é informar ao sistema qual programa executar, quais arquivos serão utilizados, onde os resultados deverão ser gravados, quais recursos serão necessários e o que fazer em determinadas condições.

Imagine o fechamento noturno de um banco. Um conjunto de tarefas pode precisar:

1. receber os movimentos realizados durante o dia;
2. validar os registros;
3. calcular juros;
4. atualizar saldos;
5. gerar arquivos contábeis;
6. produzir relatórios;
7. arquivar os resultados;
8. liberar o próximo ciclo de processamento.

Os programas responsáveis pelos cálculos podem estar em COBOL. O JCL organiza e inicia sua execução.

Esse processamento em lote continua relevante porque permite tratar enormes quantidades de dados de maneira planejada e controlada. Para quem está acostumado apenas a APIs e aplicações web, entender uma janela de processamento noturno exige uma mudança de perspectiva.

VSAM e os arquivos corporativos

Antes de bancos de dados relacionais se tornarem comuns, muitas aplicações armazenavam informações em arquivos. No ecossistema IBM, o VSAM tornou-se uma tecnologia importante para organizar e acessar conjuntos de dados sequenciais ou indexados.

Sistemas COBOL podem ler, alterar e gravar registros VSAM. É possível localizar uma conta por uma chave, percorrer registros em sequência ou produzir um novo arquivo a partir do processamento de outro.

Mesmo quando uma organização adota bancos de dados modernos, arquivos VSAM podem continuar presentes em partes da operação. A migração exige entender formatos de registros, chaves, dependências, programas consumidores e procedimentos de recuperação.

CICS e as transações on-line

O COBOL começou muito ligado ao processamento em lote, mas as empresas também precisavam executar operações interativas. Surgiu então a necessidade de controlar milhares de transações simultâneas realizadas por terminais, caixas eletrônicos e sistemas corporativos.

O CICS tornou-se uma das principais soluções para isso. Ele funciona como um servidor de aplicações transacionais, administrando execução, segurança, comunicação e acesso a recursos.

Um programa COBOL executado sob CICS pode consultar um cliente, registrar um pagamento, autorizar uma operação ou atualizar um cadastro. O usuário não precisa saber que existe COBOL atrás da interface.

O CICS Transaction Server atual não está restrito a terminais antigos. Ele oferece integração com aplicações de diferentes linguagens, observabilidade, APIs, automação e ferramentas de desenvolvimento modernas.

IMS: banco de dados e gerenciador de transações

O IMS, sigla de Information Management System, é outra tecnologia histórica encontrada em grandes ambientes corporativos. Ele reúne um banco de dados hierárquico e um gerenciador de transações.

Aplicações COBOL podem utilizar o IMS para consultar e atualizar estruturas de dados extremamente importantes. Em algumas organizações, essas bases carregam décadas de informações e continuam atendendo operações críticas.

O IMS permanece em evolução, com integração a Java, APIs REST, automação por Ansible e ferramentas voltadas à nuvem híbrida. A tecnologia é antiga, mas seu ambiente atual não corresponde necessariamente ao que existia nas décadas de 1970 ou 1980.

Db2 e o SQL embutido

Com a expansão dos bancos de dados relacionais, o Db2 passou a complementar muitas soluções COBOL. O programa pode conter comandos SQL embutidos para consultar, incluir, alterar ou excluir registros.

Isso aproximou o COBOL de um modelo de desenvolvimento ainda familiar: a aplicação executa regras de negócio enquanto o sistema de banco de dados organiza os dados, os índices, os bloqueios e as transações.

Conhecer SQL é, assim, uma habilidade valiosa para quem deseja trabalhar com COBOL corporativo. Em determinados projetos, entender o plano de acesso de uma consulta ou o impacto de um índice pode ser mais importante do que memorizar comandos da linguagem.

Mensageria, integração e sistemas distribuídos

À medida que novas plataformas foram surgindo, as aplicações COBOL precisaram conversar com sistemas Unix, Windows, Java, aplicações móveis, sites e serviços hospedados em nuvem.

Tecnologias de mensageria, como IBM MQ, passaram a transportar eventos e solicitações entre ambientes. Uma aplicação pode publicar uma mensagem que será processada por outro sistema, sem exigir que ambos estejam disponíveis exatamente no mesmo instante.

Gateways e plataformas de integração permitem que programas existentes sejam acessados por aplicações Java, .NET e outras linguagens. O CICS Transaction Gateway, por exemplo, conecta aplicações de diferentes plataformas aos serviços executados no CICS.

APIs REST e ferramentas como z/OS Connect levaram essa integração adiante. Uma aplicação de celular pode chamar uma API moderna que, internamente, aciona uma transação CICS escrita em COBOL. Para o usuário, tudo parece parte de uma única experiência digital.

O que realmente significa “tecnologia legada”?

O termo “legado” é frequentemente empregado como sinônimo de velho, ruim ou ultrapassado. Essa associação nem sempre é justa.

Um sistema legado é, antes de tudo, um sistema herdado. Ele foi construído em outro contexto tecnológico, mas continua necessário para o funcionamento da organização.

Existem sistemas COBOL bem estruturados, documentados e mantidos. Também existem sistemas Java recentes repletos de dependências problemáticas e decisões difíceis de corrigir. A idade da linguagem não determina, sozinha, a qualidade do software.

O problema surge quando uma aplicação acumula características como:

• documentação incompleta;
• regras de negócio conhecidas por poucas pessoas;
• dependências que não foram mapeadas;
• bibliotecas sem código-fonte;
• compiladores muito antigos;
• rotinas duplicadas;
• ausência de testes automatizados;
• processos manuais de implantação;
• estruturas de dados difíceis de interpretar;
• integrações sem responsáveis definidos.

Um programa com milhares de linhas pode incluir regras criadas após auditorias, mudanças tributárias, incorporações empresariais e exceções negociadas com clientes. Reescrever o código sem compreender esse histórico pode eliminar comportamentos aparentemente estranhos, mas essenciais.

Por isso, o maior valor de certas aplicações não está na sintaxe do COBOL. Está no conhecimento operacional codificado ao longo de décadas.

Por que não reescrever tudo?

A ideia de substituir uma aplicação COBOL por Java, C# ou outra linguagem parece simples em uma apresentação. A execução costuma ser bem mais delicada.

Uma reescrita integral precisa reproduzir o comportamento do sistema antigo, incluindo casos raros, arredondamentos, formatos de arquivos, rotinas de fechamento, integrações e procedimentos de recuperação.

Também existem particularidades como:

• dados em EBCDIC;
• campos numéricos em formato compactado;
• copybooks compartilhados por muitos programas;
• chamadas entre módulos;
• processamento orientado a registros;
• arquivos de largura fixa;
• dependências entre tarefas em lote;
• códigos de retorno usados para controlar cadeias de execução;
• atualizações coordenadas entre COBOL, CICS, Db2, IMS e VSAM.

Converter a sintaxe não garante equivalência funcional. Uma tradução pode compilar corretamente e ainda produzir resultados diferentes em situações contábeis específicas.

A modernização responsável começa pelo inventário: quais programas existem, quem os chama, quais dados utilizam, quais regras executam e quais processos dependem deles. A própria IBM alerta que uma estratégia baseada somente na tradução do COBOL ignora a arquitetura de dados, a plataforma de execução e a integridade transacional do sistema.

A dificuldade de aprender COBOL no Brasil

A sintaxe básica do COBOL não é o maior obstáculo para novos profissionais. Com dedicação, alguém que já conhece lógica de programação pode aprender suas divisões, tipos de dados, estruturas condicionais, arquivos e subprogramas.

A dificuldade está em adquirir experiência semelhante à exigida por ambientes de produção.

Pouco espaço nas formações tradicionais

Cursos superiores e técnicos no Brasil costumam concentrar seus programas em Java, Python, JavaScript, desenvolvimento web, bancos de dados relacionais e computação em nuvem. Essa escolha é compreensível, pois essas tecnologias atendem um mercado amplo e são fáceis de praticar em computadores pessoais.

COBOL, JCL, CICS, IMS, RACF, VSAM e z/OS raramente aparecem juntos em uma graduação. Quando aparecem, muitas vezes são apresentados de maneira histórica, sem acesso a um ambiente real.

O estudante termina conhecendo a existência do COBOL, mas não necessariamente sabe compilar um programa no z/OS, submeter um job, analisar um abend, navegar por conjuntos de dados ou investigar uma transação CICS.

Acesso limitado ao ambiente completo

É possível instalar um compilador COBOL no Linux ou no Windows. Isso permite aprender a linguagem, criar programas e processar arquivos locais.

Reproduzir todo o ambiente corporativo é outra história. Um mainframe de produção envolve sistema operacional, segurança, catálogos, filas, bancos de dados, monitores transacionais, agendadores, ferramentas de desenvolvimento e padrões específicos de cada empresa.

O acesso a esses ambientes é controlado por razões óbvias. Eles armazenam informações financeiras, pessoais e comerciais. Dessa forma, boa parte do conhecimento mais valorizado é adquirida no emprego, em programas de formação interna ou em laboratórios especializados.

Forma-se um paradoxo: algumas vagas pedem experiência prática, mas o candidato só consegue essa experiência depois de entrar em uma organização que opere a plataforma.

O ecossistema é maior do que a linguagem

Uma pessoa pode escrever um programa COBOL correto e ainda não estar pronta para investigar um incidente em produção.

O trabalho pode exigir leitura de JCL, análise de códigos de retorno, conhecimento de Db2, controle de transações CICS, interpretação de arquivos VSAM, uso de TSO/ISPF, entendimento de copybooks, ferramentas de versionamento e regras internas de implantação.

Também é necessário conhecer o negócio. Um desenvolvedor que atua em sistemas bancários precisa compreender conceitos financeiros. Em seguros, precisa conhecer apólices, prêmios, sinistros e vigências. Em sistemas públicos, pode precisar interpretar normas e processos administrativos.

É justamente a combinação entre tecnologia e domínio de negócio que torna profissionais experientes difíceis de substituir.

Documentação e comunidades menores

Há muito menos conteúdo recente em português sobre COBOL e mainframe do que sobre desenvolvimento web. Vários materiais técnicos estão em inglês, e parte da documentação pressupõe acesso a produtos ou ambientes específicos.

As comunidades são menores e boa parte do código corporativo não pode ser publicada em repositórios públicos. Um desenvolvedor JavaScript encontra milhares de projetos completos para estudar. Já uma aplicação COBOL bancária real dificilmente estará disponível no GitHub, pois contém regras proprietárias e estruturas sensíveis.

Isso reduz a visibilidade do ecossistema e cria a impressão de que não existe trabalho. Na verdade, muitas oportunidades circulam em nichos formados por bancos, seguradoras, processadoras, empresas de serviços de tecnologia e consultorias.

Como começar a estudar COBOL hoje

Embora o acesso profissional continue sendo um desafio, o caminho de entrada melhorou consideravelmente.

Uma possibilidade é iniciar com GnuCOBOL em um computador pessoal. O compilador permite estudar estruturas de dados, arquivos, cálculos, subprogramas e diferentes dialetos sem depender imediatamente de um mainframe.

O Open Mainframe Project mantém um curso aberto de programação COBOL, com materiais que vão dos primeiros passos a tópicos avançados e testes. O projeto também apresenta ferramentas modernas de edição, integração com VS Code, Zowe, automação e pipelines de integração contínua.

Outra alternativa é o IBM Z Xplore, plataforma gratuita e baseada em desafios. Ela oferece contato prático com COBOL, JCL, VSAM, Db2, REXX, Linux e outros componentes do ecossistema IBM Z.

Uma trilha sensata pode seguir esta ordem:

1. lógica de programação e estruturas de dados;
2. sintaxe básica do COBOL;
3. processamento sequencial de arquivos;
4. tabelas, subprogramas e copybooks;
5. JCL e execução de tarefas em lote;
6. TSO, ISPF e organização de conjuntos de dados;
7. VSAM;
8. SQL e Db2;
9. conceitos de CICS;
10. depuração e análise de falhas;
11. controle de versão, testes e automação;
12. APIs e integração com aplicações modernas.

Projetos próprios ajudam a transformar o estudo em evidência prática. Um pequeno sistema de contas, uma folha de pagamento simulada ou um processador de arquivos de vendas pode demonstrar domínio da linguagem. O ideal é incluir testes, documentação, JCL de exemplo e uma descrição clara das regras implementadas.

Ainda assim, é preciso honestidade: um laboratório pessoal não equivale à experiência de sustentar um sistema crítico em produção. Ele serve como porta de entrada, não como substituto integral.

Como o COBOL ainda é usado

O COBOL permanece adequado a operações que reúnem grande volume, regras estáveis, cálculos comerciais e necessidade rigorosa de consistência.

Entre os usos mais comuns estão:

• sistemas bancários centrais;
• processamento de cartões;
• liquidação de pagamentos;
• folhas de pagamento;
• faturamento;
• previdência;
• seguros;
• cobrança;
• sistemas tributários;
• reservas e emissão de passagens;
• gestão de grandes cadastros;
• processamento de lotes financeiros;
• relatórios regulatórios.

Isso não significa que o cliente interaja diretamente com uma “tela COBOL”. O aplicativo móvel pode ser desenvolvido em Swift ou Kotlin, o portal pode usar React e os serviços intermediários podem estar em Java, Go ou .NET. No centro da operação, uma transação COBOL pode validar e registrar a movimentação.

A arquitetura moderna frequentemente se parece com uma composição de camadas. O COBOL preserva a lógica central, enquanto APIs, mensageria e microsserviços oferecem novas formas de acesso.

Modernizar não é apenas migrar

Existem várias estratégias possíveis para uma aplicação COBOL:

• manter o sistema e atualizar compiladores;
• melhorar documentação e cobertura de testes;
• otimizar programas sem alterar sua lógica;
• expor funções existentes por meio de APIs;
• substituir interfaces antigas;
• integrar eventos e mensageria;
• mover partes específicas para outra plataforma;
• modularizar programas monolíticos;
• converter somente serviços selecionados;
• reescrever completamente uma aplicação;
• aposentar sistemas que perderam sua função.

A melhor escolha depende do risco, do custo, da qualidade do código, da disponibilidade de profissionais e do valor comercial da aplicação.

Uma reescrita total pode ser adequada para um sistema pequeno e bem compreendido. Em uma aplicação central com milhões de transações e dependências acumuladas, a evolução incremental tende a oferecer maior controle.

Ambientes COBOL também estão incorporando Git, VS Code, pipelines de CI/CD, análise estática, testes automatizados, APIs e observabilidade. A existência de código antigo não obriga a equipe a utilizar processos antigos.

Inteligência artificial e compreensão de sistemas legados

Ferramentas de inteligência artificial começam a ser usadas para explicar programas, mapear dependências, produzir documentação, sugerir testes e auxiliar na refatoração.

O watsonx Code Assistant for Z, por exemplo, oferece recursos de descoberta de aplicações, explicação de código, geração de COBOL, refatoração modular e transformação assistida para Java.

Essas ferramentas podem reduzir o tempo necessário para navegar por grandes bases de código. Elas não eliminam a necessidade de especialistas.

Nomes de campos abreviados, regras não documentadas e comportamentos históricos exigem contexto organizacional. Uma inteligência artificial pode interpretar a estrutura do programa, mas não necessariamente sabe por que uma determinada exceção foi criada vinte anos atrás.

O uso seguro exige testes de regressão, validação de resultados, revisão humana e participação das áreas de negócio. Em aplicações financeiras e governamentais, “parece equivalente” não é um critério suficiente.

O futuro do COBOL

É improvável que o COBOL volte a ocupar posição central nos cursos de programação ou se transforme em uma linguagem popular entre iniciantes. Também é improvável que desapareça rapidamente.

Seu futuro deve ser marcado por uma redução gradual de alguns sistemas, combinada à modernização e manutenção de outros. Certas aplicações serão reescritas. Outras permanecerão em COBOL, mas ganharão APIs, monitoramento, automação, interfaces modernas e integração com ambientes distribuídos.

O padrão publicado em 2023, os compiladores atualizados, os projetos de código aberto e as ferramentas contemporâneas de desenvolvimento mostram que a linguagem ainda evolui. O próprio mercado de mainframe busca renovar profissionais: a IBM anunciou em 2024 um Mainframe Skills Council e programas de formação voltados a desenvolvedores, administradores e arquitetos de modernização.

Para o profissional brasileiro, COBOL provavelmente continuará sendo uma especialização. A quantidade de vagas pode ser menor do que em Java ou JavaScript, mas o conhecimento exigido também é mais raro. O perfil mais valorizado não será o de quem conhece somente a sintaxe da linguagem, e sim o de quem consegue compreender sistemas inteiros.

Esse profissional precisará transitar entre dois mundos: COBOL e APIs, lote e tempo real, ISPF e VS Code, arquivos tradicionais e bancos relacionais, mainframe e nuvem, regras escritas há décadas e novos produtos digitais.

A linguagem criada em 1959 não sobreviveu porque o tempo parou. Ela sobreviveu porque as organizações continuaram operando, acumulando regras e construindo novas camadas ao redor de sistemas que já funcionavam.

Compreender COBOL é também compreender que a história da computação não é feita apenas de substituições. Muitas vezes, ela avança por integração, adaptação e convivência entre tecnologias de épocas diferentes.

Leia Mais

DeepSeek Harness: quando o agente de IA deixa de chamar ferramentas e começa a programar o próprio trabalho

Um modelo de linguagem pode ser excelente em raciocínio e geração de código, mas ele não abre arquivos, executa comandos ou altera um projeto sozinho. Entre o modelo e o computador existe uma camada operacional. É nessa parte menos visível que o DeepSeek Harness tenta mudar a maneira como agentes de IA realizam tarefas complexas.

O modelo funciona como o cérebro do agente. O harness organiza ferramentas, contexto, permissões, execução, memória e interação com o ambiente.

O DeepSeek Harness, também identificado pelo comando dsh, é um projeto de código aberto desenvolvido pela DeepSeek. Seu objetivo não é apresentar apenas mais um modelo de inteligência artificial, mas oferecer a infraestrutura necessária para transformar diferentes modelos em agentes capazes de trabalhar com arquivos, terminal, pesquisas, ferramentas, habilidades, fluxos e subagentes.

Essa distinção parece pequena, mas é fundamental.

O modelo produz decisões em forma de tokens. O harness transforma essas decisões em ações reais. Ele apresenta as ferramentas disponíveis, recebe as chamadas geradas pelo modelo, controla a execução, devolve resultados, administra a sessão e registra aquilo que aconteceu.

Claude e Claude Code ajudam a entender a diferença. Claude é uma família de modelos. Claude Code é um ambiente de agente que conecta esses modelos ao terminal, ao sistema de arquivos e a ferramentas de desenvolvimento.

A mesma lógica aparece no ecossistema DeepSeek. Um modelo como DeepSeek V4 pode ser o “cérebro”, enquanto o DeepSeek Harness oferece o corpo operacional. O projeto, porém, foi construído para separar essas partes e permitir que componentes sejam trocados.

A proposta mais interessante aparece no chamado Code Mode, atualmente também apresentado como PTC — Programmatic Tool Calling. Em vez de obrigar o modelo a conversar com cada ferramenta individualmente, ele pode escrever um pequeno programa que organiza várias ações e executá-las em conjunto.

Menos conversa entre modelo e ferramentas. Mais execução.

Afinal, o que é um harness de IA?

A palavra harness pode ser traduzida como arreio, estrutura de conexão ou mecanismo de controle. No campo dos agentes de inteligência artificial, ela representa a camada que envolve o modelo e permite que ele interaja com sistemas externos.

Um modelo isolado recebe uma entrada e gera uma saída. Ele não possui, por natureza, acesso ao seu projeto, aos arquivos do computador, ao Git, ao terminal ou a uma API corporativa.

O harness acrescenta essas capacidades.

Quando pedimos a um agente para corrigir um erro em um programa, várias operações podem acontecer:

1. o agente procura arquivos relevantes;
2. lê o código;
3. localiza símbolos ou referências;
4. consulta instruções do projeto;
5. elabora uma hipótese;
6. altera um ou mais arquivos;
7. executa testes;
8. analisa os resultados;
9. ajusta a implementação;
10. apresenta um resumo.

O modelo participa das decisões, mas quem oferece acesso ao sistema de arquivos, executa os comandos, controla permissões e registra a trajetória é o harness.

Essa camada também define quanto contexto será enviado ao modelo. Um resultado enorme de terminal pode ser inserido integralmente na conversa ou filtrado antes. Uma ferramenta pode aparecer como uma função direta ou como parte de um SDK. A execução pode ocorrer no sistema principal, em um processo restrito, em um contêiner ou em outro ambiente isolado.

Dois agentes utilizando o mesmo modelo podem se comportar de maneira bastante diferente porque seus harnesses organizam ferramentas, contexto e execução de formas distintas.

O modelo importa muito. A estrutura em volta dele também.

“Tudo é um plugin”

A arquitetura do DeepSeek Harness parte de uma ideia explícita: praticamente todas as capacidades devem ser tratadas como plugins.

Modelo, ferramentas, skills, sessões, armazenamento, interface, sandbox, planejamento, subagentes e fluxos podem ser adicionados por componentes separados. O projeto utiliza o sistema de plugins Cordis para fornecer serviços e permitir que módulos colaborem sem transformar toda a aplicação em uma estrutura única e rígida.

Segundo a página oficial do DeepSeek Harness, a ferramenta oferece quatro configurações principais:

• Standard Mode: agente de programação completo, com edição de arquivos, shell, busca local e na web, skills, planejamento, objetivos, subagentes e workflows;
• Code Mode ou PTC Mode: mantém as capacidades do modo padrão, mas apresenta as ferramentas por meio de um SDK para que o modelo componha operações em um programa;
• Minimal Mode: ambiente reduzido, com shell persistente e editor, pensado principalmente para testes de modelos;
• Creator Mode: configuração destinada à inspeção do runtime, experimentação com plugins e criação de novos presets de agente.

A configuração do agente deixa de ser um bloco fechado no programa principal. Ela passa a ser uma composição de peças.

Isso permite imaginar agentes especializados. Uma equipe pode criar um preset apenas para revisão de código, outro para documentação, um para análise de logs e outro para manutenção de infraestrutura. Cada um recebe somente os componentes necessários.

A promessa de flexibilidade vem acompanhada de complexidade. Quanto mais extensível é um sistema, maior a necessidade de entender quais plugins estão ativos, quais permissões possuem e como interagem.

O projeto ainda está em developer preview. O repositório oficial no GitHub avisa que a ferramenta passa por evolução rápida e que haverá mudanças capazes de quebrar compatibilidade.

Não é um detalhe escondido. É o estado atual do software.

Como agentes trabalham no modo nativo

No funcionamento tradicional, o modelo recebe uma lista de ferramentas. Cada ferramenta possui nome, descrição e esquema de argumentos.

Suponha que o agente precise encontrar todos os arquivos de log, extrair mensagens de erro, agrupá-las por categoria e produzir um relatório.

No modo nativo, o fluxo pode ser parecido com isto:

1. o modelo chama a ferramenta de listagem;
2. o harness executa a chamada;
3. o resultado volta para o contexto;
4. o modelo lê a lista e escolhe um arquivo;
5. chama a ferramenta de leitura;
6. o conteúdo retorna para o modelo;
7. o modelo decide ler o próximo arquivo;
8. outra chamada é realizada;
9. novos resultados entram no contexto;
10. o modelo finalmente organiza os dados.

Cada etapa pode exigir uma nova interação com a API do modelo. O histórico cresce porque chamadas e respostas intermediárias precisam ser preservadas para que o agente saiba o que aconteceu.

Esse funcionamento possui uma vantagem: cada passo fica bastante explícito. O usuário ou o sistema de permissões pode inspecionar uma operação antes de executá-la. Também é adequado para tarefas curtas em que o resultado de uma ferramenta modifica completamente a decisão seguinte.

O custo aparece em trabalhos mecânicos e repetitivos.

Se houver cem arquivos, o agente talvez realize muitas chamadas quase iguais. O modelo recebe informações que poderiam ser filtradas por um programa comum. Tokens são consumidos para transportar listas, trechos e respostas que servem apenas como ponte entre uma ferramenta e outra.

O modelo acaba fazendo o trabalho de um laço de programação, só que por meio de várias rodadas de inferência.

Code Mode: o modelo escreve o procedimento

O Code Mode muda a representação das ferramentas.

Em vez de expor todas elas apenas como funções que o modelo chama uma por vez, o DeepSeek Harness gera uma interface tipada. O modelo escreve um programa, normalmente em TypeScript, usando esse SDK.

O programa pode:

• listar arquivos;
• percorrer resultados com um laço;
• realizar leituras independentes em paralelo;
• filtrar linhas;
• agrupar ocorrências;
• calcular totais;
• tratar erros;
• devolver apenas um resumo.

O harness executa esse programa e apresenta ao modelo o resultado relevante. Dados intermediários não precisam atravessar repetidamente a janela de contexto.

Em um exemplo simplificado, o modelo poderia produzir uma lógica parecida com esta:

const arquivos = await tools.buscarArquivos({
  padrao: "**/*.log"
});

const conteudos = await Promise.all(
  arquivos.map((arquivo) =>
    tools.lerArquivo({ caminho: arquivo })
  )
);

const erros = conteudos
  .flatMap((conteudo) => extrairErros(conteudo))
  .reduce(agruparPorTipo, {});

return erros;

Os nomes reais das ferramentas e os tipos dependem da configuração do harness. O que importa é o fluxo: uma única produção de código descreve o procedimento completo.

A ideia de apresentar ferramentas como uma API programável não surgiu exclusivamente com o DeepSeek Harness. A própria documentação técnica do projeto menciona o trabalho anterior da Cloudflare.

Em setembro de 2025, a Cloudflare publicou a proposta Code Mode: the better way to use MCP. A empresa argumentava que modelos possuem muito mais exposição a código real durante o treinamento do que a formatos artificiais de chamadas de ferramentas.

Em vez de pedir ao modelo que emitisse dezenas de estruturas JSON especiais, as ferramentas seriam transformadas em uma API TypeScript. O modelo escreveria código para combiná-las.

O DeepSeek Harness incorporou essa lógica como parte de sua arquitetura modular.

Por que programar pode economizar tokens?

Uma chamada de ferramenta tradicional exige uma sequência de mensagens.

O modelo escolhe a ferramenta e produz os argumentos. O harness executa. O resultado volta ao contexto. O modelo processa esse conteúdo e decide a etapa seguinte.

Se a operação gerar vinte mil linhas, esse material pode ocupar uma parte significativa da janela, mesmo quando o modelo precisa apenas contar quantas vezes determinado erro aparece.

Com o Code Mode, o programa executa o processamento fora do contexto principal. Ele pode ler vinte mil linhas, descartar o conteúdo irrelevante e devolver algo pequeno:

Falhas de autenticação: 138
Erros de conexão: 42
Timeouts: 17

O modelo recebe o resultado final, não toda a matéria-prima.

Essa diferença pode reduzir:

• tokens de entrada;
• número de chamadas ao modelo;
• tempo acumulado de rede;
• pressão sobre a janela de contexto;
• repetição de instruções e esquemas;
• exposição desnecessária de resultados intermediários ao modelo.

Também permite paralelismo. Leituras independentes podem ser enviadas em conjunto com Promise.all, em vez de depender de várias decisões sequenciais.

Só que a economia não é automática.

O SDK tipado precisa ser apresentado ao modelo. Se a interface for enorme, sua descrição também consome contexto. A documentação do próprio DeepSeek Harness reconhece que as declarações TypeScript podem ficar grandes e, no modo que expõe simultaneamente ferramentas nativas e Code Mode, as duas representações ocupam espaço.

Tarefas pequenas talvez não ganhem nada. Se o agente precisa chamar uma única ferramenta, escrever, interpretar e executar um programa pode acrescentar trabalho.

O benefício tende a aparecer quando existe composição: múltiplos arquivos, várias APIs, filtragem, laços, operações independentes ou grande volume de dados intermediários.

Velocidade não serve se o resultado estiver errado

Um agente mais rápido não é automaticamente melhor.

O programa gerado pode interpretar incorretamente o formato dos logs, ignorar arquivos, usar uma expressão regular inadequada ou agrupar erros diferentes na mesma categoria. Como várias ações são executadas em uma única etapa, um erro inicial pode se propagar por todo o processamento.

No modo nativo, o modelo observa resultados intermediários e pode corrigir o caminho. No Code Mode, ele tenta antecipar a sequência.

Isso cria uma troca.

Para operações determinísticas, repetitivas e bem estruturadas, o programa pode ser muito mais eficiente. Em tarefas ambíguas, exploratórias ou dependentes de interpretação contínua, interagir passo a passo talvez seja mais confiável.

Também é necessário avaliar a qualidade final do relatório. Se uma configuração demora 36 segundos, mas perde metade dos erros, ela não venceu a comparação.

Um teste completo deveria observar:

• tempo total;
• tokens de entrada e saída;
• custo monetário;
• cobertura dos arquivos;
• precisão dos agrupamentos;
• estabilidade entre execuções;
• quantidade de intervenção humana;
• erros de ferramenta;
• facilidade de auditar a trajetória.

Agentes são sistemas, não cronômetros.

Programmatic Tool Calling não significa uma única ação interna

Dizer que o Code Mode realiza tudo “de uma vez” pode gerar uma interpretação errada.

As ferramentas continuam sendo chamadas. Arquivos continuam sendo lidos. Comandos continuam sendo executados. APIs ainda recebem requisições.

O que muda é quem organiza a sequência.

No modo nativo, o ciclo do agente alterna repetidamente entre modelo e ferramenta. No modo programático, o modelo escreve um procedimento, e o runtime organiza várias chamadas dentro daquela execução.

As operações internas podem continuar percorrendo o pipeline de ferramentas, incluindo validações, registros e políticas. O documento de implementação do Code Mode descreve subchamadas identificadas e registradas individualmente.

Isso é importante para observabilidade. Se o programa chama cinco ferramentas, a plataforma ainda precisa saber qual delas falhou, quais argumentos foram usados e o que aconteceu antes do resultado final.

Agrupar a coordenação não deveria apagar a trajetória.

Um harness que pode modificar o próprio harness

O Creator Mode representa a parte mais experimental da proposta.

Nesse modo, o agente pode inspecionar os serviços, plugins, eventos e ferramentas disponíveis no runtime. Também consegue montar plugins temporários e testar novas composições em memória.

A intenção é permitir que o desenvolvedor descreva uma capacidade e utilize a própria IA para ajudar a construir o módulo correspondente.

Podemos imaginar um pedido como:

Crie uma ferramenta que leia arquivos CSV do projeto, valide colunas obrigatórias e devolva um resumo dos registros inconsistentes.

O agente inspeciona as interfaces disponíveis, escreve o código do plugin, monta o componente temporariamente e testa seu comportamento.

Há um limite importante. Os plugins criados dinamicamente em memória não são necessariamente persistidos como parte definitiva da instalação. Para transformar um experimento em componente mantido, o código precisa ser revisado, salvo, testado e incorporado de maneira controlada.

A possibilidade de um agente modificar sua própria composição é poderosa. Também amplia o risco de uma configuração incorreta introduzir ferramentas excessivamente permissivas.

Extensibilidade sem governança vira superfície de ataque.

Compatibilidade com outros modelos

A separação entre modelo e harness permite trabalhar com provedores diferentes. A arquitetura atual transporta a seleção como uma combinação de provedor e modelo, em vez de presumir que toda sessão utilizará obrigatoriamente um único serviço.

Isso não significa que qualquer modelo funcionará igualmente bem.

O modo nativo exige competência em tool calling. O modelo precisa selecionar ferramentas, gerar argumentos válidos, interpretar resultados e manter o estado do trabalho.

O Code Mode exige outra combinação:

• boa geração de TypeScript ou da linguagem configurada;
• capacidade de compreender tipos;
• planejamento de múltiplas etapas;
• tratamento de erros;
• respeito às instruções do SDK;
• seleção adequada do que deve retornar ao contexto.

Um modelo pode conversar muito bem e ainda falhar na composição programática. Outro pode escrever código correto, mas gerar argumentos inadequados para ferramentas específicas.

Plugins comunitários já oferecem rotas para APIs compatíveis com os formatos OpenAI, Anthropic e outros provedores. O ecossistema ainda está mudando rapidamente, e compatibilidade de protocolo não garante equivalência de comportamento.

Conectar um endpoint é a parte fácil. Fazer o modelo utilizar corretamente todas as capacidades exige testes.

O custo da API não depende apenas do preço por token

A DeepSeek cobra sua API pelo volume de tokens processados. Entrada com cache, entrada sem cache e saída podem possuir preços diferentes.

Na tabela oficial consultada em agosto de 2026, o DeepSeek V4 Flash aparece com preços de 0,02 yuan por milhão de tokens de entrada com cache, 1 yuan para entrada sem cache e 2 yuan por milhão de tokens de saída. O V4 Pro aparece com 0,025 yuan para entrada com cache, 3 yuan para entrada sem cache e 6 yuan por milhão de tokens de saída.

Esses valores podem mudar. A própria documentação de preços da API DeepSeek recomenda acompanhar a página atualizada.

O custo real de um agente não é calculado apenas multiplicando o tamanho da pergunta pelo preço do modelo.

Cada nova rodada pode reenviar partes consideráveis do histórico. Definições de ferramentas, instruções, resultados anteriores e conteúdo de arquivos ocupam tokens. Em uma tarefa com muitas chamadas, o material acumulado pode superar em muito o prompt original.

O cache do provedor ajuda quando o prefixo permanece estável. Alterações na lista de ferramentas, no prompt de sistema ou na estrutura da sessão podem diminuir esse aproveitamento.

O Code Mode tenta reduzir principalmente a quantidade de resultados intermediários que retornam ao modelo. Se o programa lê cinquenta arquivos e devolve apenas uma tabela pequena, a economia pode ser expressiva.

Mas existe um custo inicial: gerar o programa e apresentar o SDK. Se a tarefa exige apenas uma leitura simples, o modo nativo pode utilizar menos tokens.

O modo de operação, portanto, faz parte da economia da API.

O risco de executar código escrito pelo modelo

O Code Mode não oferece apenas a capacidade de escolher ferramentas. Ele executa um programa produzido pelo modelo.

Isso exige uma discussão de segurança mais séria.

A implementação atual utiliza uma nova worker thread do Node.js para cada execução. O ambiente de variáveis é esvaziado, e existem limites configuráveis de memória, tempo e saída. Um laço síncrono descontrolado pode ser interrompido sem bloquear o processo principal.

Esses controles são úteis. Não equivalem a um sandbox de segurança contra código hostil.

A própria documentação do projeto afirma que o runtime baseado em worker thread oferece contenção operacional, mas não uma fronteira forte de segurança. O código pode alcançar APIs do Node, e uma thread compartilha o mesmo usuário e o mesmo sistema operacional do processo principal.

Em agosto de 2026, uma discussão no repositório do DeepSeek Harness detalhou a preocupação de que o caminho run_code possa acessar arquivos e criar processos fora das restrições esperadas em determinadas configurações. Trata-se de uma discussão técnica no GitHub, não de uma declaração conclusiva de que toda instalação foi comprometida, mas o cenário merece atenção.

Quem pretende experimentar o Code Mode deve preferir:

• uma máquina virtual descartável;
• um contêiner bem restrito;
• workspace separado;
• credenciais de curta duração;
• ausência de chaves SSH ou tokens pessoais;
• acesso mínimo à rede;
• permissões limitadas;
• revisão das operações;
• versão fixada do software;
• acompanhamento das correções do projeto.

Um limite de tempo impede que o programa rode indefinidamente. Ele não impede, sozinho, a leitura de um arquivo sensível durante o primeiro segundo.

Não confunda contenção de recursos com isolamento de segurança.

Code Mode não substitui o modo nativo

A arquitetura mais interessante provavelmente não será aquela que obriga todas as tarefas a usar um único modo.

Chamadas diretas continuam adequadas quando:

• existe apenas uma ferramenta;
• o usuário precisa aprovar cada ação;
• a próxima decisão depende de uma interpretação cuidadosa;
• os resultados intermediários são pequenos;
• a transparência passo a passo é prioridade.

A execução programática tende a funcionar melhor quando:

• há muitos arquivos;
• várias ferramentas precisam ser combinadas;
• resultados devem ser filtrados;
• existem laços ou condições;
• chamadas independentes podem ocorrer em paralelo;
• dados intermediários são grandes;
• a tarefa possui um procedimento relativamente claro.

O próprio DeepSeek Harness aceita configurações nativa, programática ou combinada. Isso sugere que a escolha pode ser tratada como decisão de engenharia, não como disputa ideológica.

Em uma tarefa real, o agente talvez investigue inicialmente no modo nativo, compreenda o problema e depois escreva um programa para processar o restante em escala.

Pensar primeiro. Automatizar depois.

O que o DeepSeek Harness realmente está propondo

O aspecto mais relevante do projeto não é apenas ser uma alternativa ao Claude Code.

O DeepSeek Harness apresenta uma visão na qual o agente não é um produto indivisível. Modelo, ferramentas, sessões, armazenamento, interface, execução e políticas são componentes que podem ser inspecionados e recombinados.

Essa abertura pode ajudar pesquisadores, desenvolvedores de ferramentas e equipes que desejam experimentar diferentes modelos sem reconstruir toda a infraestrutura de agente.

Também transfere mais responsabilidade para quem monta o ambiente. Em uma solução fechada, parte da complexidade é decidida pelo fornecedor. Em uma plataforma modular, o operador precisa entender plugins, permissões, compatibilidade, persistência e limites de segurança.

O Code Mode reforça essa mudança. Ele trata o modelo não apenas como um decisor que chama funções, mas como um gerador de pequenos programas operacionais.

É uma ideia coerente com aquilo que os modelos aprenderam a fazer bem: escrever código, compor APIs e transformar procedimentos em estruturas executáveis.

Talvez a próxima geração de agentes não seja definida somente por modelos maiores. Pode ser definida por harnesses capazes de decidir quando conversar, quando chamar uma ferramenta e quando escrever um programa para terminar o trabalho.

O cérebro continua importante. Só que um cérebro sem uma boa estrutura operacional passa boa parte do tempo esperando, repetindo e movimentando informações que nem precisaria ler.

Leia Mais

Hierarquia de memória: por que o computador precisa de registradores, cache, RAM, SSD e HDD?

Um computador não possui vários tipos de memória apenas porque a indústria criou tecnologias diferentes ao longo do tempo. Essa diversidade existe porque nenhum dispositivo consegue ser, ao mesmo tempo, extremamente rápido, barato, durável, energeticamente eficiente e capaz de armazenar grandes quantidades de dados.

A hierarquia de memória organiza diferentes tecnologias conforme velocidade, capacidade, custo, consumo de energia e distância física até o processador.

Quanto mais próxima uma memória está das unidades de execução do processador, mais rapidamente seus dados podem ser acessados. Só que essa proximidade tem preço. Registradores e caches ocupam uma área valiosa dentro do chip, consomem energia e são caros por byte. Discos rígidos ficam muito mais distantes do processador e trabalham em outra escala de tempo, mas conseguem guardar terabytes por um custo relativamente baixo.

A hierarquia nasce dessa incompatibilidade.

No topo estão os registradores, pequenos e extremamente rápidos. Logo abaixo aparecem os diferentes níveis de cache. Depois vem a memória principal, normalmente baseada em DRAM. Mais distante encontramos os SSDs, seguidos pelos discos rígidos e por sistemas de armazenamento ainda maiores, como bibliotecas de fitas, armazenamento distribuído e serviços de nuvem.

Não se trata apenas de uma lista organizada do componente mais rápido para o mais lento. Cada nível tenta esconder as limitações do nível seguinte.

Uma biblioteca para entender a hierarquia

Imagine uma pessoa trabalhando em uma grande biblioteca.

Em cima de sua mesa estão algumas folhas com as informações utilizadas naquele exato momento. Elas podem ser alcançadas sem levantar da cadeira. Esse espaço é pequeno, mas o acesso é quase imediato. Na analogia, seriam os registradores do processador.

Ao lado da mesa existe uma estante com os livros consultados com maior frequência. Ainda é um espaço limitado, porém guarda mais informações que a mesa. A pessoa precisa esticar o braço ou levantar rapidamente para alcançar um volume. Essa estante representa a memória cache.

Os demais livros ficam organizados na sala principal da biblioteca. Há milhares deles. Para buscar um título, a pessoa precisa caminhar até a estante correta, localizar a prateleira e retornar. A biblioteca principal corresponde à memória RAM.

Existe também um arquivo no subsolo, onde são guardados documentos que não precisam permanecer disponíveis na sala. O acesso demora mais, mas o arquivo possui espaço muito maior. Podemos associá-lo a um SSD.

Documentos antigos, grandes coleções e materiais raramente consultados talvez fiquem em outro prédio. Um funcionário precisa solicitar o item, esperar sua localização e aguardar o transporte. Esse depósito representa o HDD, os sistemas de fita ou outras camadas de armazenamento de grande capacidade.

Se a pessoa precisasse ir ao outro prédio a cada frase lida, o trabalho seria insuportavelmente lento. Por isso, materiais relevantes são antecipadamente levados para a sala, depois para a estante próxima e finalmente colocados sobre a mesa.

O computador tenta fazer algo semelhante. Dados que provavelmente serão usados em breve são movidos para níveis mais próximos do processador. Quando essa previsão funciona, a CPU continua trabalhando. Quando falha, ela precisa esperar.

E processadores atuais são rápidos demais para esperar sem que isso represente desperdício.

Velocidade não é uma única medida

Quando falamos que uma memória é rápida, podemos estar tratando de duas características diferentes: latência e largura de banda.

Latência é o tempo necessário para iniciar e concluir determinado acesso. É quanto o processador espera até receber a informação solicitada.

Largura de banda representa a quantidade de dados que pode ser transferida durante certo período. Uma memória pode demorar para iniciar uma operação e, depois disso, transferir um grande volume de dados por segundo.

Uma rodovia ajuda a visualizar a diferença. A latência é o tempo que um veículo leva para chegar ao destino. A largura de banda está relacionada ao número de veículos que a estrada consegue transportar simultaneamente.

Discos rígidos ilustram bem essa separação. A leitura aleatória de um pequeno arquivo pode ser lenta porque a cabeça precisa se deslocar e esperar o setor correto passar sob ela. Quando o disco começa a ler um arquivo grande e contínuo, consegue manter uma taxa de transferência razoável.

Em sistemas de inteligência artificial, a largura de banda ganha um peso enorme. Não basta a GPU executar trilhões de operações matemáticas se os dados necessários não chegam às unidades de processamento com velocidade suficiente.

A localidade faz a hierarquia funcionar

A hierarquia depende de um comportamento comum dos programas chamado localidade.

A localidade temporal indica que, se um dado foi usado recentemente, existe uma boa chance de ele ser usado novamente em pouco tempo. Uma variável dentro de um laço, por exemplo, pode ser lida milhões de vezes.

A localidade espacial sugere que, quando um endereço é acessado, os endereços próximos também podem ser necessários. Um programa que percorre um vetor tende a ler seus elementos em sequência.

As caches exploram os dois padrões. Em vez de buscar apenas um byte isolado, o processador normalmente transfere um bloco maior, chamado linha de cache. Se o programa continuar acessando dados próximos, eles já estarão disponíveis.

Isso também explica por que dois programas que realizam a mesma quantidade de operações podem apresentar desempenhos muito diferentes. O primeiro organiza seus dados de maneira previsível e aproveita a cache. O segundo pula entre regiões distantes da memória, provocando falhas de cache e esperas constantes.

O algoritmo continua correto. O processador continua sendo o mesmo. Só mudou a maneira como os dados atravessam a hierarquia.

HDD: bits gravados em uma superfície magnética

O disco rígido é uma mistura impressionante de mecânica de precisão, magnetismo e eletrônica.

Dentro de um HDD existem um ou mais pratos circulares revestidos por material magnético. Esses pratos giram em alta velocidade, normalmente a milhares de rotações por minuto. Pequenas cabeças de leitura e gravação se movem sobre suas superfícies.

A cabeça não encosta normalmente no prato durante a operação. Ela flutua sobre uma camada de ar extremamente fina criada pela própria rotação. Quanto menor a distância segura entre a cabeça e a superfície, maior pode ser a densidade de gravação. A Seagate explica que essas cabeças ficam suspensas sobre essa fina almofada de ar enquanto leem ou alteram regiões magnéticas.

Os dados são representados por propriedades magnéticas de áreas microscópicas do prato. Na escrita, o campo produzido pela cabeça modifica o estado magnético da região. Na leitura, alterações nesse campo são detectadas e convertidas em sinais elétricos.

A mecânica introduz atrasos inevitáveis.

Primeiro, o braço precisa posicionar a cabeça sobre a trilha adequada. Esse movimento produz o tempo de busca. Depois, é necessário esperar que o setor desejado gire até passar sob a cabeça, criando a latência rotacional.

Milissegundos parecem pouco na experiência humana. Para um processador trabalhando em nanossegundos, representam uma eternidade.

O HDD continua relevante porque oferece enorme capacidade por um custo baixo. Data centers, sistemas de backup, servidores de arquivos, vigilância, armazenamento científico e grandes repositórios ainda podem se beneficiar dessa relação entre preço e volume.

Tecnologias como gravação magnética assistida por calor, conhecida como HAMR, permitem aumentar a densidade dos pratos. Nessa técnica, um pequeno laser aquece temporariamente uma área minúscula para facilitar a alteração de sua polaridade magnética, conforme descreve a documentação da Seagate sobre HAMR.

O disco rígido é lento para acessos aleatórios, mas continua difícil de substituir quando a prioridade é guardar muitos terabytes sem transformar cada servidor em um objeto absurdamente caro.

SSD: elétrons presos em células NAND

O SSD elimina pratos, motores e cabeças móveis. Seus dados são armazenados em memória flash NAND, uma tecnologia não volátil capaz de manter informações mesmo sem fornecimento de energia.

Na escala microscópica, a célula NAND utiliza um transistor modificado para reter carga elétrica. Dependendo da arquitetura, essa carga fica armazenada em uma porta flutuante ou em uma estrutura de aprisionamento de carga.

A presença e a quantidade de elétrons modificam a tensão necessária para ativar o transistor. Durante a leitura, o controlador aplica tensões e interpreta em qual faixa o comportamento da célula se encontra.

Uma célula SLC armazena um bit, permitindo dois estados lógicos. MLC, TLC e QLC registram mais bits por célula por meio de vários níveis de tensão. Isso aumenta a capacidade e reduz o custo por gigabyte, mas exige distinguir margens elétricas menores.

Quanto mais estados uma célula precisa representar, mais delicadas ficam a programação, a leitura e a correção de erros. Também tende a existir maior desgaste e menor velocidade de gravação direta quando comparada a células que armazenam menos bits.

Nos SSDs modernos, as células não ficam apenas lado a lado sobre uma superfície plana. A 3D NAND empilha camadas verticalmente, aumentando a densidade sem depender exclusivamente da redução horizontal dos componentes. Existem produtos com centenas de camadas.

A memória NAND trabalha com páginas e blocos. Dados podem ser lidos e programados em páginas, mas o apagamento normalmente acontece em blocos maiores. Isso cria uma complicação: para atualizar determinada informação, o controlador nem sempre pode sobrescrever diretamente a mesma célula.

Ele grava a nova versão em outro local, marca a anterior como inválida e reorganiza blocos posteriormente. Esse processo está ligado à coleta de lixo, ou garbage collection.

O controlador do SSD mantém uma camada de tradução entre os endereços lógicos vistos pelo sistema operacional e as posições físicas da memória. Também executa nivelamento de desgaste, correção de erros, gerenciamento de blocos defeituosos e outras tarefas internas.

Um SSD, então, não é apenas um conjunto de chips NAND. O controlador e seu firmware têm papel decisivo no desempenho e na durabilidade.

Há ainda caches baseadas em DRAM ou em uma região NAND operando temporariamente como SLC. Por isso, certos SSDs gravam rapidamente no início de uma transferência e reduzem a velocidade quando a cache se esgota.

Mesmo com essas limitações, o SSD é muito mais rápido que o HDD em acessos aleatórios porque não precisa movimentar partes mecânicas. Isso muda completamente a inicialização do sistema, a abertura de programas, a instalação de pacotes e a manipulação de milhares de arquivos pequenos.

Armazenamento não é memória principal

SSD e HDD guardam o sistema operacional, os programas e os arquivos quando o computador está desligado. Para executar um programa, seus dados precisam ser carregados para a memória principal.

A diferença não é apenas terminológica.

O armazenamento é persistente e possui grande capacidade, mas sua latência é alta demais para alimentar diretamente o processador em operações comuns. A memória RAM é volátil, mais cara por byte e perde seus dados sem energia, porém oferece acesso muito mais rápido.

Quando abrimos um programa, partes do executável são lidas do SSD e colocadas na RAM. O sistema operacional pode carregar apenas as páginas necessárias, em vez de copiar imediatamente o programa inteiro.

Se a quantidade de memória física se torna insuficiente, o sistema pode mover páginas menos usadas para uma área de troca no armazenamento. No Linux, isso aparece na forma de partição ou arquivo de swap. O mecanismo permite continuar funcionando, mas trocar constantemente páginas entre RAM e SSD causa uma queda perceptível de desempenho.

É outra demonstração da hierarquia. O armazenamento consegue atuar como extensão da memória, só que não adquire a mesma velocidade por receber outro nome.

DRAM: um transistor, um capacitor e uma carga que desaparece

A memória principal de computadores costuma utilizar DRAM, sigla para memória dinâmica de acesso aleatório.

Uma célula DRAM clássica é formada por um transistor e um capacitor. O capacitor guarda uma pequena carga elétrica, enquanto o transistor controla o acesso à célula.

O estado da carga representa a informação. O problema é que capacitores não mantêm essa carga indefinidamente. Pequenas correntes de fuga fazem o valor desaparecer.

Por isso ela é chamada de dinâmica.

O controlador precisa atualizar periodicamente as células, processo conhecido como refresh. Mesmo quando o computador não está alterando determinados dados, a DRAM precisa gastar tempo e energia preservando-os.

A leitura também é delicada. A carga armazenada é minúscula e precisa ser detectada por circuitos chamados amplificadores de sentido. Em muitas implementações, a leitura perturba o estado da célula, exigindo que o valor seja restaurado depois.

Os bits são organizados em matrizes, linhas, colunas, bancos, grupos de bancos, chips, canais e módulos. Antes de acessar uma coluna, o sistema ativa determinada linha e a transfere para os amplificadores de sentido. Se o próximo acesso ocorrer na mesma linha aberta, ele pode ser atendido com menor atraso. Se exigir outra linha, a anterior precisa ser fechada e a nova deve ser ativada.

Essa estrutura ajuda a entender por que a latência da memória não depende apenas da frequência anunciada na embalagem. Temporizações, número de canais, padrão de acesso, controlador, organização dos bancos e concorrência entre núcleos também influenciam o resultado.

DDR significa Double Data Rate. A tecnologia transfere dados em mais de uma transição do sinal de clock, ampliando a taxa efetiva. Gerações como DDR4 e DDR5 aumentaram capacidade, paralelismo e largura de banda, mas a distância de desempenho entre a CPU e a memória principal continua existindo.

A Micron resume a célula DRAM como a combinação de um transistor e um capacitor destinada ao acesso rápido enquanto o sistema está em funcionamento.

Cache: pequena demais para guardar tudo, rápida o suficiente para evitar esperas

Entre a CPU e a DRAM existem as caches.

Elas costumam ser baseadas em SRAM, ou memória estática de acesso aleatório. Diferentemente da DRAM, uma célula SRAM não depende de um capacitor que precisa ser atualizado periodicamente. Uma implementação clássica pode utilizar seis transistores para manter um bit.

Essa estrutura ocupa muito mais área no silício que a célula DRAM de um transistor e um capacitor. Construir gigabytes de SRAM dentro de uma CPU seria caro, grande e energeticamente problemático.

Mas ela é rápida. Então usamos pequenas quantidades.

A cache L1 fica muito próxima das unidades de execução e normalmente é dividida entre instruções e dados. Cada núcleo costuma possuir suas próprias caches L1. Elas têm pouca capacidade, mas oferecem baixa latência e alta largura de banda.

A L2 é maior e um pouco mais lenta. Dependendo da arquitetura, pode ser privada para cada núcleo ou organizada de outra forma.

A L3, também chamada em muitos projetos de cache de último nível, costuma ser compartilhada entre vários núcleos. Possui capacidade maior, mas sua latência é superior à da L1 e da L2.

Os detalhes variam entre processadores. Nem toda arquitetura usa exatamente a mesma organização, e “L3 compartilhada” não significa que todos os núcleos acessem qualquer região com custo idêntico.

Quando a CPU procura um dado, verifica primeiro os níveis mais próximos. Se ele estiver presente, ocorre um cache hit. Se não estiver, temos um cache miss, e a busca continua no próximo nível.

Uma falha em L1 pode ser atendida pela L2. Uma falha em L2 pode encontrar o dado na L3. Se nenhum nível possuir a linha necessária, o controlador precisa buscá-la na DRAM.

A diferença é suficiente para interromper o fluxo eficiente de instruções. Processadores tentam esconder parte desse atraso executando outras operações, prevendo acessos e trazendo dados antecipadamente por meio de mecanismos de prefetch. Nem sempre conseguem.

Sistemas com vários núcleos também precisam manter coerência. Se um núcleo modifica uma informação que outro núcleo possui em sua cache, o hardware precisa impedir que versões incompatíveis sejam usadas como se ambas fossem atuais.

É muita lógica para fazer o acesso à memória parecer simples.

Registradores: onde a operação realmente acontece

No topo estão os registradores.

Eles ficam dentro do núcleo do processador e armazenam operandos, endereços, resultados intermediários, ponteiros e estados usados diretamente pelas instruções.

Quando uma CPU soma dois valores, esses valores normalmente precisam estar em registradores ou ser entregues às unidades de execução por mecanismos internos equivalentes. O resultado também é colocado em um registrador antes de seguir para outro destino.

Registradores são extremamente rápidos, mas existem em quantidade muito limitada. A arquitetura expõe determinados registradores ao conjunto de instruções, enquanto a microarquitetura pode possuir um número físico maior para técnicas como renomeação e execução fora de ordem.

Compiladores trabalham para manter valores importantes nos registradores sempre que possível. Quando faltam registradores, alguns valores precisam ser temporariamente enviados à pilha na memória, operação chamada spill. Isso adiciona acessos e pode reduzir o desempenho.

A Intel descreve a hierarquia começando pelos registradores, passando pela cache L1 e seguindo para níveis progressivamente mais distantes.

Quanto mais perto das unidades de execução, menor a capacidade. Não é coincidência. A área física do chip e o tempo de propagação dos sinais também participam dessa história.

Um dado atravessa várias camadas antes de ser processado

Imagine uma fotografia armazenada em um SSD.

Quando um programa abre o arquivo, o controlador do SSD localiza as páginas NAND correspondentes. Os dados passam pela interface de armazenamento e são colocados em regiões da RAM administradas pelo sistema operacional.

Ao processar a imagem, a CPU solicita blocos dessa memória. Linhas são copiadas para a cache L3, L2 e L1 conforme o padrão de acesso. Valores específicos chegam aos registradores e entram nas unidades vetoriais ou aritméticas.

O resultado segue o caminho inverso. Pode permanecer temporariamente nas caches, voltar à RAM e, quando o programa salva o arquivo, ser enviado ao SSD.

Nem toda etapa acontece de maneira rigidamente sequencial. Existem acesso direto à memória, buffers, filas, caches do sistema operacional, controladores inteligentes e operações assíncronas. O modelo simplificado, porém, revela uma coisa importante: processar dados significa também movimentá-los.

Em muitos programas, a matemática não é a parte mais cara. Levar os operandos até o lugar certo custa tempo e energia.

O problema da “parede da memória”

A capacidade computacional dos processadores cresceu mais rapidamente que a redução da latência da memória principal. Essa diferença é conhecida como memory wall, a parede da memória.

Podemos construir mais unidades de execução, aumentar o paralelismo e realizar mais operações por ciclo. Só que essas unidades precisam receber dados.

Se a memória não fornece informações com largura de banda suficiente, parte do processador fica ociosa. É como construir mais caixas em um supermercado sem ampliar os corredores, o estoque e as esteiras que levam produtos até eles.

Caches maiores ajudam. Prefetch ajuda. Compressão, reorganização de dados, execução fora de ordem e novas interconexões também ajudam.

Nenhuma dessas técnicas elimina o problema. Elas tentam administrá-lo.

A inteligência artificial tornou essa limitação muito mais visível porque modelos atuais trabalham com enormes matrizes de pesos, ativações e estados intermediários. Uma GPU pode possuir uma capacidade matemática extraordinária e continuar limitada pela velocidade com que lê e movimenta esses dados.

Por que a IA precisa de tanta memória?

Um modelo de linguagem contém parâmetros numéricos aprendidos durante o treinamento. Se um modelo possui 70 bilhões de parâmetros e cada parâmetro é armazenado em formato de 16 bits, apenas os pesos ocupam aproximadamente 140 bilhões de bytes, ou cerca de 140 GB na contagem decimal.

Isso é apenas uma aproximação dos pesos.

Durante o treinamento, o sistema também pode precisar guardar gradientes, ativações, estados do otimizador, buffers temporários e cópias dos parâmetros em outras precisões. O consumo total pode ser várias vezes maior que o tamanho bruto do modelo.

Técnicas como paralelismo, checkpointing de ativações, precisão reduzida, particionamento de estados e LoRA tentam reduzir ou distribuir esse custo. O FSDP do PyTorch, por exemplo, divide entre GPUs não apenas parâmetros, mas também gradientes e estados do otimizador, conforme explica a documentação sobre treinamento distribuído.

Na inferência, não precisamos armazenar gradientes de treinamento, mas surge outro consumidor importante: o KV cache.

Transformers produzem chaves e valores usados pelo mecanismo de atenção. Durante a geração, esses resultados são preservados para evitar que todo o contexto anterior seja recalculado a cada novo token.

Quanto maior o contexto, maior tende a ser esse cache. Quanto mais usuários simultâneos e mais sequências em andamento, maior a pressão sobre a memória da GPU.

A documentação da NVIDIA observa que sequências de entrada mais longas aumentam os requisitos de memória da fase de prefill, enquanto saídas longas aumentam os requisitos durante a geração. Em sistemas de larga escala, o KV cache pode ocupar uma parte relevante da memória disponível.

É por isso que aumentar apenas o número de operações por segundo não resolve tudo.

HBM: pilhas de DRAM ao lado do acelerador

GPUs e aceleradores de IA utilizam cada vez mais HBM, sigla para High Bandwidth Memory.

HBM continua sendo DRAM, mas organizada de uma maneira diferente dos módulos DDR instalados em placas-mãe convencionais. Diversos dies de memória são empilhados verticalmente e conectados por vias que atravessam o silício, conhecidas como TSVs.

Essas pilhas são colocadas muito perto do processador, normalmente no mesmo encapsulamento avançado, ligadas por uma interface extremamente larga. Em vez de depender apenas de frequências altíssimas sobre um barramento estreito e relativamente longo, a HBM movimenta muitos bits em paralelo por uma distância curta.

A proximidade e a largura da interface permitem alcançar uma enorme largura de banda. Também ajudam a reduzir a energia consumida por bit transferido quando comparadas a certas abordagens convencionais.

A HBM3e representa uma evolução dessa família. Produtos da geração Hopper e Blackwell utilizaram a tecnologia para ampliar capacidade e vazão de dados.

A NVIDIA informa que a GPU H200 possui 141 GB de HBM3e com largura de banda de até 4,8 TB/s. Em plataformas Blackwell Ultra, determinadas configurações chegam a 288 GB por GPU e até 8 TB/s, segundo as especificações divulgadas pela fabricante.

São números máximos de produtos específicos, não uma característica universal de toda memória HBM3e. O desempenho real de uma aplicação também depende do padrão de acesso, do software, da interconexão, da ocupação do acelerador e de vários outros fatores.

Mesmo assim, a escala é reveladora. Um único acelerador pode movimentar terabytes por segundo porque alimentar suas unidades matemáticas exige uma espécie de sistema circulatório de dados.

A memória de uma GPU ainda pode ser pequena demais

Centenas de gigabytes parecem muito até um modelo grande, seus caches e diversos usuários disputarem o mesmo espaço.

Quando o modelo não cabe em uma GPU, ele pode ser dividido entre várias. Camadas, tensores ou partes dos parâmetros são distribuídos, e os aceleradores precisam trocar resultados durante o processamento.

Agora surge outro nível da hierarquia: a interconexão entre GPUs.

Dentro de um servidor, tecnologias como NVLink oferecem uma comunicação mais rápida que interfaces genéricas. Entre servidores, redes de alta velocidade, como InfiniBand ou Ethernet especializada, transportam dados através do cluster.

A memória deixou de ser apenas aquilo que existe dentro de um chip. Passamos a lidar com uma hierarquia distribuída:

• registradores e memórias internas das unidades de execução;
• caches do acelerador;
• HBM local;
• memória de outras GPUs;
• DRAM do host;
• expansão de memória;
• SSDs NVMe;
• armazenamento de rede;
• grandes repositórios de dados.

Cada salto adiciona latência, consome energia e ocupa a interconexão.

Uma plataforma GB200 NVL72, por exemplo, reúne dezenas de GPUs e oferece vários terabytes de HBM3e, acompanhados por uma malha de comunicação de alta velocidade. Isso não transforma o conjunto em uma única memória perfeita. O software precisa distribuir o modelo e coordenar a movimentação dos dados.

Quanto maior o sistema, mais importante se torna saber onde cada informação está.

O caminho de um modelo de linguagem

Quando um modelo é iniciado, seus pesos podem estar armazenados em SSDs locais ou em um sistema distribuído. Eles precisam ser lidos e carregados para a memória do servidor. Depois, são transferidos para a HBM das GPUs.

Durante a fase de prefill, o prompt do usuário é processado em paralelo para construir as representações internas e o KV cache. Essa etapa costuma utilizar bastante capacidade computacional.

Na geração, o modelo produz tokens progressivamente. Para cada novo token, os pesos precisam participar dos cálculos e o sistema consulta o histórico armazenado no KV cache. Dependendo da configuração, essa fase pode ficar bastante limitada pela largura de banda da memória.

Os dados circulam o tempo inteiro.

Pesos são lidos. Ativações são geradas. Partes do KV cache são consultadas. Resultados atravessam unidades de processamento e, em modelos distribuídos, seguem para outros aceleradores.

Essa movimentação consome energia. Em certas cargas, transportar dados entre memória e processador pode custar mais que a própria operação aritmética.

A discussão sobre eficiência de IA não pode ficar restrita ao número de FLOPS. Também precisamos observar bytes movimentados, largura de banda utilizada, capacidade ocupada, padrões de acesso e energia por transferência.

Uma multiplicação executada rapidamente não ajuda se os operandos chegam atrasados.

O armazenamento continua abaixo da inteligência artificial

HBM recebe atenção porque está diretamente associada aos aceleradores, mas a cadeia não começa nela.

Modelos precisam ser treinados com grandes conjuntos de dados. Esses conjuntos vivem em repositórios compostos por SSDs, HDDs, armazenamento de objetos e sistemas distribuídos. Checkpoints de treinamento também precisam ser gravados periodicamente.

Se milhares de GPUs esperarem os dados de treinamento chegarem, equipamentos caríssimos ficam ociosos.

Data centers utilizam caches em SSD, pré-carregamento, formatos otimizados, particionamento e pipelines paralelos para manter os aceleradores ocupados. Dados podem passar do armazenamento distribuído para SSDs locais, depois para a DRAM do servidor e finalmente para a HBM.

Durante a gravação de checkpoints, o caminho se inverte. O sistema precisa retirar grandes volumes de dados dos aceleradores sem interromper o treinamento por tempo demais.

O HDD continua presente em camadas de grande capacidade. SSDs aparecem onde latência e taxa de acesso importam mais. DRAM funciona como área de trabalho. HBM alimenta diretamente o acelerador.

A antiga pirâmide de memória não desapareceu na era da inteligência artificial. Ela ficou maior.

Não existe memória perfeita, apenas escolhas menos ruins

Poderíamos perguntar por que não fabricar um computador usando apenas a tecnologia mais rápida disponível.

Porque a máquina ficaria cara, quente e pequena em capacidade.

Também poderíamos usar apenas a memória mais barata. Nesse caso, o processador passaria a maior parte do tempo esperando.

A engenharia procura um equilíbrio. Pequenas quantidades de memória muito rápida ficam perto do processamento. Grandes quantidades de armazenamento mais lento ocupam os níveis inferiores. Hardware, sistema operacional, compiladores e aplicações trabalham juntos para manter os dados certos no lugar certo.

Essa organização funciona tão bem que normalmente não percebemos sua existência. Abrimos um programa e vemos uma janela. Carregamos um jogo e observamos uma tela. Enviamos um prompt e recebemos uma resposta.

Por trás desse gesto simples, bytes podem ter saído de um SSD, atravessado a RAM, entrado em diferentes níveis de cache, chegado aos registradores e retornado. Em um data center de IA, talvez tenham circulado entre dezenas de aceleradores antes de produzir uma única palavra.

A computação moderna não depende apenas de realizar cálculos. Depende de alimentar esses cálculos sem deixar a máquina esperando.

O processador pode ser o componente que executa as instruções, mas a hierarquia de memória decide com que frequência ele realmente terá algo para fazer.

Leia Mais

Data center e problemas hídricos

Hoje em dia os data center demanda muita energia, o que está dando um problema grave hídrico. A maioria dos data center de treinamento de Inteligência Artificial funciona assim: você junta milhares de servidores, cada um lotado de GPUs, liga tudo com uma rede absurdamente rápida, alimenta o conjunto com dados em velocidade industrial, e transforma eletricidade em cálculos, cálculos em calor, calor em água evaporada ou em sistemas de refrigeração cada vez mais complexos.

Parece simples na frase, só que por dentro é uma fábrica de termodinâmica. O treinamento de modelos grandes é um processo distribuído, o modelo “mora” em pedaços espalhados por centenas ou milhares de GPUs, cada pedaço calculando gradientes e sincronizando resultados o tempo todo. Isso exige não só GPU, exige memória, armazenamento, rede, orquestração, redundância, e um prédio inteiro feito para não derreter.

O data center de IA por dentro, o caminho da energia até virar resposta

A primeira é a camada de computação, onde ficam as GPUs e CPUs. Em IA moderna, as GPUs viraram o motor principal porque conseguem fazer muitas multiplicações e somas em paralelo, que é justamente a moeda do treinamento. A densidade de potência por rack disparou, um rack que antes era “pesado” com alguns quilowatts hoje pode virar dezenas de quilowatts, e em projetos de IA isso sobe ainda mais. Isso muda tudo, muda a forma de distribuir energia no piso, muda o tipo de cabo, muda a arquitetura de refrigeração, muda até o quanto um prédio aguenta sem virar um forno.

A segunda camada é a rede. Treinar um modelo grande não é um monte de computadores independentes, é um “cérebro coletivo” que precisa conversar o tempo inteiro. A rede vira parte do computador. Por isso entram tecnologias de interconexão de altíssima banda e baixa latência, e por isso, quando alguém fala que “é só comprar mais GPU”, está ignorando que sem rede decente você compra gargalos caros.

A terceira camada é armazenamento e dados. O treinamento é uma esteira, dados chegam, são pré-processados, entram em lotes, geram atualizações. Só que dados grandes não são arquivos bonitinhos, são petabytes, e petabyte não gosta de improviso. Quando o armazenamento engasga, as GPUs ficam ociosas, e GPU ociosa é dinheiro queimando e energia desperdiçada.

A quarta camada é a infraestrutura predial, energia e refrigeração. E aqui aparece o truque que pouca gente vê: muitas vezes a “TI” é a menor parte do problema físico. O resto é entregar energia com estabilidade e tirar calor sem depender de milagres.

É por isso que existem métricas como PUE, Power Usage Effectiveness, que mede a razão entre a energia total do data center e a energia que chega de fato nos equipamentos de TI, quanto mais perto de 1, melhor. PUE virou padrão internacional formalizado em norma ISO.

Só que, quando a conversa é IA, entra um segundo fantasma, a água. Aí aparece outra métrica, WUE, Water Usage Effectiveness, litros de água por kWh gasto pela TI. Essa conta expõe um detalhe desconfortável: dá para ser “eficiente em energia” e ainda assim ser um monstro hídrico, depende do tipo de resfriamento e do clima.

Por que IA puxa a tomada com tanta força

Data center sempre gastou energia, a nuvem já era uma indústria gigantesca. O salto recente tem uma assinatura clara, a aceleração por IA. A Agência Internacional de Energia projeta que o consumo elétrico global de data centers pode mais que dobrar e chegar perto de 945 TWh em 2030, com crescimento anual na casa de ~15% no período 2024–2030, e a própria IEA coloca IA como o principal motor dessa alta, com demanda de data centers otimizados para IA crescendo várias vezes até 2030.

Isso não é só “mais servidores”. IA empurra o limite físico do rack, e quando a densidade sobe, o que antes era “ar condicionado de sala grande” vira um projeto térmico quase de indústria pesada.

A consequência direta é que energia deixa de ser um item de custo e vira gargalo estratégico. Não basta ter dinheiro, tem que ter conexão com a rede elétrica, tem que ter subestação, tem que ter transformador, tem que ter licença, tem que ter contrato, tem que ter previsibilidade. Em muitos lugares, o tempo para conseguir a interligação com a rede vira o cronograma real do projeto, não a obra do prédio.

E existe um efeito colateral bem humano nisso: quando um data center entra numa região, ele compete com todo mundo por infraestrutura. A conversa vira política local. Quem recebe a energia? Quem paga pela expansão da rede? Quem absorve o risco quando dá pico? Quem segura a bronca quando falta água?

A água, o recurso que some “sem barulho”

O problema hídrico não é um acidente, ele é uma escolha técnica que, durante décadas, foi razoável. Muitos data centers usam resfriamento evaporativo ou torres de resfriamento porque água evaporando é um jeito eficiente de remover calor. Funciona muito bem, especialmente em climas secos. Só que eficiência física não é sinônimo de sustentabilidade social.

Para dar escala mental, relatórios e levantamentos recentes usam números que assustam quando saem do abstrato. Um relatório do governo do Reino Unido sobre uso de água em data centers e IA cita que um data center de 100 MW pode consumir em torno de 2,5 bilhões de litros por ano, algo comparável às necessidades de dezenas de milhares de pessoas, e traz a ideia de competição direta com água potável em períodos de seca, com risco de conflito social em áreas de estresse hídrico.

Esse mesmo relatório cita estimativas globais em que o setor de data centers consome centenas de bilhões de litros de água por ano, com projeções que podem subir de forma relevante até 2030.

A parte mais irritante é que, em muitos casos, o cidadão não “vê” essa água indo embora. Não é uma indústria com chaminé óbvia. É um galpão limpinho, com cerca, com logo moderno, e o consumo aparece na conta municipal como uma curva subindo.

WUE ajuda a tirar o véu. Há fontes que colocam médias de WUE por volta de ~1,8 a 1,9 L/kWh em data centers, com variação grande por clima e tecnologia, e com metas de projetos bons tentando ficar bem abaixo disso.

Só que WUE também tem pegadinha: ele costuma medir a água “no site” e relacionar com a energia de TI. A água escondida na geração de energia pode ser enorme. Dependendo de como a eletricidade é produzida, existe água usada na cadeia inteira, resfriamento de termelétricas, perdas, reservatórios, mineração, e isso vira uma espécie de “água virtual” do modelo. O relatório do Reino Unido bate nessa tecla, falando do elo água-energia e do quanto o impacto vai além do perímetro do data center.

Tem mais um capítulo que quase ninguém lembra, fabricação de chips. Os aceleradores de IA são semicondutores avançados, fabricados com processos que usam água ultra pura em volumes grandes para limpeza e enxágue de wafers. Mesmo que o operador do data center não controle isso diretamente, faz parte da pegada hídrica total.

Por que a crise hídrica aparece agora, a mistura de densidade e geografia

Se você coloca uma fazenda de GPUs num lugar frio, com água abundante e energia limpa, a história fica menos dramática. Só que o mundo real adora ironia: muita capacidade de data center cresce perto de grandes centros econômicos, onde a terra é cara, a água é disputada, e a energia já vive no limite. Em regiões quentes, o resfriamento exige mais trabalho, e em regiões secas, evaporar água parece uma tentação técnica, só que é justamente onde a água já é um tema delicado.

Reportagens recentes vêm explorando exatamente esse choque, data centers crescendo em regiões com estresse hídrico, com iniciativas tentando reduzir consumo de água e, ao mesmo tempo, esbarrando no trade-off clássico, reduzir água costuma aumentar energia, porque sistemas “waterless” frequentemente precisam de mais ventilação, mais compressão, mais refrigeração mecânica.

Esse trade-off é a essência do problema. A física não dá desconto. Você tira calor do chip e joga em algum lugar, ar, água, líquido dielétrico, circuito fechado, e cada escolha cobra um preço diferente.

As soluções técnicas mais citadas, e por que nenhuma é mágica

1) Resfriamento líquido direto no chip (direct-to-chip).
Em vez de soprar ar gelado e esperar que o calor saia do dissipador, você coloca líquido circulando em placas frias próximas ao chip. Isso permite densidades maiores com menos consumo de água no site, dependendo do sistema. É um caminho natural quando racks viram “mini-usinas”.

2) Imersão (immersion cooling).
Os servidores ficam mergulhados em um fluido especial, que remove calor de forma eficiente. Pode reduzir espaço e facilitar densidade, só que muda manutenção, muda fornecedores, muda tudo, e ainda precisa rejeitar calor para o ambiente em algum ponto.

3) Sistemas de circuito fechado e reaproveitamento.
Em vez de usar água potável e evaporar, dá para recircular e usar trocadores de calor mais inteligentes. Só que a conta de energia pode subir, e a complexidade operacional aumenta.

4) Migração geográfica e design orientado a clima.
Construir onde o clima ajuda é uma solução elegante no papel. Na prática, esbarra em latência, em disponibilidade de rede, em regulação, em impostos, em mão de obra, em incentivos locais.

5) Reuso de calor.
O calor de data center pode aquecer prédios, água de distrito, processos industriais. Em alguns países isso faz sentido econômico. Em muitos lugares, falta infraestrutura para capturar e distribuir esse calor, e o calor vira desperdício.

O ponto importante é que eficiência não é uma chavinha, é um ecossistema de decisões. PUE é útil, WUE é útil, só que a métrica sozinha vira maquiagem se você otimiza um lado e explode o outro.

Os potenciais, o lado em que isso pode valer a pena como sociedade

Até aqui parece que data center é um vilão de ficção científica que bebe rios. Só que o lado útil é real, e dá para falar dele sem romantizar.

A capacidade de computação concentrada permite avanços em áreas onde simulação e modelagem são vitais, descoberta de fármacos, previsão meteorológica, otimização de redes elétricas, engenharia de materiais, tradução e acessibilidade, automação de tarefas repetitivas em saúde e serviços, educação personalizada quando feita com responsabilidade. A própria IEA discute o potencial de IA para transformar como o setor de energia opera, com ganhos de eficiência, previsão e integração de renováveis, desde que seja aplicada com objetivo e governança.

Existe um uso interessante e meio subestimado: IA para operar o próprio data center. Prever carga, deslocar workloads, ajustar resfriamento em tempo real, reduzir desperdício, detectar falhas antes de virar pane. É a versão moderna de “o monstro ajuda a domar o monstro”.

E tem um argumento econômico que, goste ou não, pesa. Data centers são infraestrutura estratégica. Eles atraem investimento, empregos indiretos, arrecadação, e funcionam como base para empresas locais consumirem computação sem depender de continentes de distância. Países e estados tratam isso como corrida industrial.

Os problemas, onde a conta chega sem pedir licença

1) Emissões e o risco de empurrar a rede para fontes fósseis.
Quando a demanda cresce mais rápido que a capacidade limpa, a energia marginal pode vir de térmicas, e isso piora emissões. Matérias recentes chamam atenção para o crescimento acelerado e para casos em que expansão de capacidade e uso de combustíveis fósseis entram na mesma frase, justamente porque a velocidade do “boom de IA” pressiona sistemas elétricos que já estão no limite.

2) Falta de transparência.
Sem dados claros, a sociedade fica discutindo no escuro. Há pressão para exigir divulgação de consumo de energia, água e emissões, porque hoje muita informação é voluntária e fragmentada, e isso impede planejamento público e fiscalização séria.

3) Competição por água potável em períodos críticos.
O relatório do Reino Unido explicita esse ponto, a dependência de água potável para resfriamento pode competir com abastecimento humano, e em secas pode gerar restrições e conflitos.

4) Concentração do impacto.
Uma cidade pode sentir muito mais que a média global. Estudos e revisões citam exemplos em que instalações representam fatia relevante do consumo municipal, como o caso citado para The Dalles, nos EUA, em que o consumo de um data center aparece como parcela grande do uso da cidade em certos anos.

5) Pegada material e cadeia de suprimentos.
A conversa não termina na conta de luz e água. GPU e infraestrutura têm carbono incorporado, mineração, refino, fabricação, transporte, descarte. A cada ciclo de upgrade, uma montanha de hardware muda de lugar. Esse lado é menos visível, e por isso é fácil ignorar.

6) O risco do “rebound effect”, eficiência que vira expansão.
Você melhora eficiência do modelo, reduz custo por inferência, e de repente surgem dez novos produtos, todos rodando IA o dia inteiro. O consumo total sobe mesmo com eficiência melhorando. Esse efeito aparece em várias áreas da economia, IA não é exceção.

Onde dá para atacar o problema de forma prática, sem virar teatro

Tem um caminho que envolve engenharia e governança ao mesmo tempo.

Na engenharia, a redução de desperdício computacional é ouro. Técnicas como quantização, distilação, sparsity, treinamento mais inteligente, fine-tuning em vez de treinar do zero, tudo isso reduz energia por resultado útil. Existe uma diferença brutal entre “treinar porque dá” e “treinar porque precisa”.

Na operação, dá para deslocar carga. Treinamentos longos podem ser agendados para horários de maior oferta renovável, ou para regiões com melhor perfil energético, desde que a arquitetura do sistema permita. Não resolve tudo, só que é melhor do que ignorar o relógio e a rede.

Na infraestrutura, a escolha do resfriamento deve considerar bacia hidrográfica, não só custo. WUE deveria entrar em licenciamento e contratos de forma explícita, com metas e auditoria. Se o data center promete “water positive”, a pergunta adulta é “em qual bacia, com qual metodologia, com que verificação”.

Na política pública, transparência é o primeiro passo que não depende de tecnologia futurista. Medir e reportar consumo de energia, água e emissões, com metodologia padronizada, cria base para planejamento. Relatórios como o do Reino Unido defendem exatamente a necessidade de dados confiáveis para governança, e apontam que esforços voluntários podem ser insuficientes quando a curva de crescimento é agressiva.

E existe uma conversa que pouca gente quer ter, priorização. Nem todo uso de IA é igualmente valioso. Treinar modelos gigantes para ganhar décimos de ponto em benchmark pode ser ciência, pode ser marketing, pode ser as duas coisas. Quando água e energia viram recursos em disputa, a pergunta “isso vale o custo social” para de ser filosofia e vira administração pública.

O século passado tratou eletricidade como base invisível da economia. Este século está tratando computação como base invisível da economia. A diferença é que agora a base invisível esquenta, evapora água, pressiona rede e entra na política local como um novo tipo de indústria, limpa por fora, intensa por dentro. A boa notícia é que o problema é material e mensurável, dá para modelar, dá para regular, dá para projetar melhor. A má notícia é que a curva de crescimento é rápida, e curvas rápidas punem sociedades que gostam de decidir devagar.

---

Referências

Information technology — Data centres — Key performance indicators https://www.iso.org/standard/63451.html

Data Centers and Water Consumption https://www.eesi.org/articles/view/data-centers-and-water-consumption

Energy demand from AI https://www.iea.org/reports/energy-and-ai/energy-demand-from-ai

Desert storm: Can data centres slake their insatiable thirst for water? https://www.reuters.com/sustainability/climate-energy/desert-storm-can-data-centres-slake-their-insatiable-thirst-water--ecmii-2025-12-17/

AI is set to drive surging electricity demand from data centres while offering the potential to transform how the energy sector works https://www.iea.org/news/ai-is-set-to-drive-surging-electricity-demand-from-data-centres-while-offering-the-potential-to-transform-how-the-energy-sector-works

‘Just an unbelievable amount of pollution’: how big a threat is AI to the climate? https://www.theguardian.com/technology/2026/jan/03/just-an-unbelievable-amount-of-pollution-how-big-a-threat-is-ai-to-the-climate

Call to make tech firms report data centre energy use as AI booms https://www.theguardian.com/technology/2025/feb/07/call-to-make-tech-firms-report-data-centre-energy-use-as-ai-booms

The water use of data center workloads: A review and assessment of key determinants https://escholarship.org/uc/item/1vx545q7

Leia Mais