Mostrando postagens com marcador desenvolvimento. Mostrar todas as postagens
Mostrando postagens com marcador desenvolvimento. Mostrar todas as postagens

Apple apresenta M6 de 2 nm e M5 Ultra com quatro dies: o Mac entra de vez na disputa pela IA local

A Apple apresentou dois processadores que ocupam extremos diferentes de sua linha de computadores. O M6 estreia no Mac mini com uma arquitetura de 2 nanômetros voltada ao uso cotidiano, enquanto o M5 Ultra chega ao Mac Studio tentando transformar uma estação compacta em uma máquina capaz de executar modelos massivos de inteligência artificial localmente.

Representação dos processadores Apple M6 e M5 Ultra utilizados no Mac mini e no Mac Studio
O M6 inaugura a fabricação de 2 nanômetros nos chips da Apple, enquanto o M5 Ultra reúne quatro dies e pode trabalhar com até 512 GB de memória unificada.

Os dois lançamentos têm propostas muito diferentes, mas revelam a mesma direção. A Apple não está mais tratando o processamento de inteligência artificial como um recurso complementar. CPU, GPU, Neural Engine, memória e ferramentas de desenvolvimento estão sendo reorganizados para que aplicações de IA sejam executadas diretamente no computador, sem depender o tempo todo de servidores externos.

O M6 representa uma evolução mais ampla, destinada a estudantes, desenvolvedores, usuários domésticos e profissionais que precisam de um desktop pequeno e eficiente. O M5 Ultra pertence a outra categoria. Ele foi projetado para renderização 3D, edição de vídeos pesados, simulações científicas, geração de imagens, desenvolvimento de modelos e execução de grandes modelos de linguagem.

A diferença entre eles não está apenas na quantidade de núcleos. Está na maneira como a Apple pretende dividir o futuro do Mac: computadores menores ganham aceleração neural suficiente para tarefas locais, enquanto o Mac Studio assume o papel de estação de IA, vídeo e computação intensiva.

M6 é o primeiro chip de 2 nanômetros da Apple

A mudança mais visível do M6 está no processo de fabricação. Segundo a empresa, este é o primeiro processador da Apple construído com tecnologia de 2 nanômetros.

O número não deve ser interpretado como uma medida literal de cada transistor. Nas gerações atuais de semicondutores, expressões como 5 nm, 3 nm e 2 nm representam famílias de processos de fabricação, com diferentes níveis de densidade, eficiência e características elétricas.

Na prática, uma tecnologia mais avançada permite colocar mais transistores dentro de uma área limitada. Os engenheiros podem usar esse ganho para aumentar o desempenho, reduzir o consumo, acrescentar novos blocos de processamento ou equilibrar essas três possibilidades.

A Apple afirma que o processo de 2 nm proporciona ao M6 um avanço simultâneo em desempenho e eficiência energética. É uma afirmação plausível considerando a evolução da fabricação, mas a dimensão real desse ganho dependerá de medições independentes de consumo, temperatura e desempenho sustentado.

Um chip pode ser muito rápido durante alguns segundos e reduzir sua frequência quando aquece. Também pode apresentar excelente eficiência em determinada carga e comportamento diferente em outra. Esses detalhes só ficam claros quando os computadores chegam aos usuários e passam por testes fora do ambiente controlado da fabricante.

Mesmo assim, a estreia dos 2 nm é significativa. Ela dá à Apple mais espaço para ampliar partes importantes do sistema sem transformar o Mac mini em uma máquina maior ou mais difícil de resfriar.

Uma CPU de 12 núcleos com nova divisão de tarefas

O M6 traz uma CPU com 12 núcleos, dois a mais que a geração anterior. A organização interna chama atenção: são dois “super cores”, quatro núcleos de desempenho e seis núcleos de eficiência.

Os núcleos de eficiência cuidam de operações cotidianas e tarefas em segundo plano consumindo menos energia. Os núcleos de desempenho entram quando o trabalho exige mais capacidade de processamento. Os dois super cores assumem as tarefas mais sensíveis à velocidade de execução individual.

Essa estrutura representa uma evolução da arquitetura híbrida que a Apple já utiliza há várias gerações. Em vez de tratar todos os núcleos da mesma forma, o sistema distribui o trabalho conforme a necessidade. Não faz sentido ativar uma unidade muito poderosa para verificar notificações ou sincronizar pequenos arquivos. Da mesma maneira, compilar um projeto grande ou processar uma imagem complexa exige recursos que os núcleos econômicos não entregariam na mesma velocidade.

Segundo os números divulgados no comunicado oficial do M6 e do M5 Ultra, o novo processador oferece desempenho multithread de até 1,2 vez o M5 e até 2,4 vezes o M1. A empresa também afirma possuir o núcleo de CPU mais rápido do mundo em desempenho single-thread.

Essa última frase precisa ser lida como uma alegação de fabricante. A Apple informa que realizou seus testes em agosto de 2026, utilizando sistemas comerciais concorrentes e benchmarks selecionados. Ainda não há, no momento do anúncio, uma bateria ampla de avaliações independentes que permita comparar o M6 com todas as arquiteturas atuais em diferentes sistemas, aplicações e limites de energia.

O desempenho single-thread continua importante porque muitos processos não conseguem distribuir perfeitamente o trabalho entre dezenas de núcleos. Partes de compiladores, navegadores, ferramentas de edição e interfaces dependem da velocidade de uma sequência principal de instruções. É isso que costuma produzir a sensação de resposta imediata ao abrir programas, manipular projetos ou realizar operações curtas.

Já o ganho multithread aparece com mais clareza na compilação de código, exportação de arquivos, indexação, renderização e outras tarefas capazes de utilizar vários núcleos ao mesmo tempo.

Dual Neural Engine: dois blocos dedicados à IA

O M6 também estreia o que a Apple chama de Dual 16-core Neural Engine. Em termos simples, o chip possui dois motores neurais com 16 núcleos cada, voltados à execução de operações comuns em redes neurais.

O Neural Engine surgiu nos chips da Apple inicialmente ligado a recursos como reconhecimento de imagens, fotografia computacional, processamento de voz e aprendizado de máquina. Com a expansão dos modelos generativos, esse bloco ganhou outra importância.

Agora ele precisa lidar com tarefas como:

  • execução de modelos locais;
  • análise e classificação de conteúdo;
  • transcrição;
  • geração e transformação de imagens;
  • compreensão de linguagem;
  • recursos da Apple Intelligence;
  • operações realizadas por agentes de IA;
  • inferência de redes neurais incorporadas aos aplicativos.

A Apple afirma que o novo conjunto pode entregar até duas vezes o pico de capacidade computacional das gerações anteriores. Os frameworks do sistema conseguem utilizar os dois motores ao mesmo tempo, desde que o aplicativo e a carga tenham sido preparados para isso.

Esse detalhe importa. Dobrar um bloco de hardware não significa que todo aplicativo ficará duas vezes mais rápido automaticamente. O modelo precisa utilizar operações compatíveis, a tarefa precisa ser distribuída de maneira eficiente e o software deve conseguir alimentar os dois motores sem criar gargalos em outras partes do sistema.

Em alguns trabalhos, a limitação estará na GPU. Em outros, na largura de banda da memória. Também existem modelos que executam determinadas operações na CPU porque elas não se adaptam bem ao Neural Engine.

A arquitetura de IA da Apple está se tornando heterogênea. Isso significa que uma mesma carga pode ser dividida entre CPU, GPU e Neural Engine. O macOS e os frameworks da empresa tentam decidir qual parte do processador é mais adequada para cada operação.

Para o desenvolvedor, o ganho depende menos de “programar diretamente os 32 núcleos neurais” e mais de utilizar ferramentas que saibam aproveitar a arquitetura.

A GPU do M6 também ganhou aceleradores neurais

O M6 possui uma GPU de 12 núcleos, novamente dois a mais que o M5. Cada núcleo gráfico inclui um Neural Accelerator dedicado.

Essa aproximação entre computação gráfica e inteligência artificial acompanha uma transformação vista em toda a indústria. GPUs sempre foram boas em executar grandes quantidades de operações paralelas. As redes neurais se beneficiam justamente desse tipo de cálculo, especialmente multiplicações de matrizes realizadas repetidamente.

A presença de aceleradores especializados dentro dos núcleos da GPU busca melhorar esse trabalho sem depender exclusivamente do Neural Engine. Modelos generativos, ferramentas de imagem, aplicações de vídeo e grandes modelos de linguagem podem dividir suas operações entre diferentes unidades.

Segundo a Apple, o M6 apresenta um aumento próximo de 30% no pico de computação de IA pela GPU em comparação com o M5 e supera em mais de oito vezes a capacidade do M1 nessa métrica específica.

“Pico de computação” não é sinônimo de desempenho final do aplicativo. Trata-se de uma medida da capacidade teórica ou máxima de determinado bloco. O resultado percebido pelo usuário depende do modelo, da precisão numérica utilizada, do tamanho do contexto, do formato dos pesos, da memória disponível e da otimização do software.

Essa distinção ficou ainda mais necessária com a explosão das comparações de IA. Um computador pode ter excelente capacidade matemática e, mesmo assim, apresentar resultados medianos em um modelo mal otimizado. Outro pode ter números teóricos menores, mas contar com bibliotecas mais maduras e executar a mesma tarefa com maior eficiência.

O anúncio fornece uma direção. Os testes práticos dirão o tamanho do avanço.

Gráficos, jogos e ray tracing

O foco em IA não eliminou a função tradicional da GPU. O M6 recebe uma arquitetura atualizada de shaders, melhorias no Dynamic Caching e aceleração de ray tracing por hardware.

O Dynamic Caching é uma tecnologia utilizada para ajustar dinamicamente a quantidade de memória local destinada às tarefas da GPU. Em arquiteturas mais tradicionais, uma parte dos recursos pode acabar reservada sem ser totalmente utilizada. A proposta é realizar essa alocação de forma mais precisa, reduzindo desperdícios e aumentando o aproveitamento do chip.

A Apple também declara um aumento de 50% na taxa de processamento de geometria. Esse ganho pode ajudar em cenas tridimensionais complexas, jogos, modelagem 3D, visualização arquitetônica e aplicações que trabalham com muitos objetos.

O ray tracing simula o comportamento da luz para produzir reflexos, sombras e iluminação mais realistas. É uma técnica computacionalmente pesada, por isso a aceleração em hardware faz tanta diferença.

Ainda existe uma questão que a especificação do processador não resolve: disponibilidade de jogos. A Apple vem fortalecendo o Metal e aproximando o Mac de títulos mais exigentes, mas desempenho de GPU, por si só, não cria um catálogo. Desenvolvedores precisam portar, testar e manter seus jogos no macOS.

Para criação de conteúdo, o cenário costuma ser mais favorável. Aplicações de edição, renderização e produção audiovisual já aproveitam amplamente os recursos do Apple silicon.

Memória unificada mais rápida, mas limitada a 32 GB

O M6 alcança até 170 GB/s de largura de banda de memória, aproximadamente 10% acima do M5 e 2,5 vezes a largura de banda oferecida pelo M1, segundo a Apple. A capacidade máxima, porém, permanece em 32 GB no Mac mini equipado com esse chip.

Na arquitetura de memória unificada, CPU, GPU e Neural Engine acessam o mesmo conjunto de memória. Isso reduz a necessidade de copiar dados entre a memória principal e uma memória gráfica separada.

A ideia é especialmente útil em inteligência artificial. Os pesos de um modelo podem ser acessados pelos diferentes componentes do chip sem tantas movimentações intermediárias. O resultado potencial é menor latência, melhor eficiência e aproveitamento mais flexível da capacidade instalada.

Só que 32 GB ainda impõem limites claros.

Essa quantidade é confortável para atividades domésticas, desenvolvimento de software, edição de imagens, alguns projetos de vídeo e modelos locais menores. Já modelos de linguagem maiores, contextos muito extensos e geração avançada podem consumir rapidamente toda a memória disponível.

O M6 não tenta resolver o segmento extremo. Ele oferece uma base eficiente para IA local de uso cotidiano. Quem precisa carregar centenas de gigabytes de pesos entra no território do M5 Ultra.

M5 Ultra estreia uma arquitetura com quatro dies

O M5 Ultra é descrito pela Apple como o processador mais poderoso já criado pela empresa. Seu principal diferencial é a arquitetura de quatro dies, a primeira desse tipo em um chip da série M.

Um die é a parte física de silício que contém os componentes do processador. Fabricar um único chip gigantesco pode ser caro e difícil, pois qualquer defeito na produção compromete uma área maior. Uma alternativa é combinar vários dies menores por meio de conexões de alta velocidade.

No M5 Ultra, a Apple utiliza a tecnologia UltraFusion para conectar dois conjuntos M5 Max, cada um já formado por dois dies. O resultado é um sistema com quatro partes físicas trabalhando como um único processador lógico.

A comunicação entre os dies é decisiva. Se a conexão for lenta, o processador pode perder desempenho enquanto uma parte espera dados da outra. A Apple afirma ter elevado a largura de banda entre os dies para mais de 4,4 TB/s e aumentado a densidade das conexões em mais de seis vezes.

Esses números buscam permitir que os quatro dies compartilhem informações com baixa latência. Para o software, a intenção é que a estrutura se comporte como um grande sistema integrado, sem exigir que cada aplicativo seja refeito para gerenciar manualmente quatro chips separados.

É uma solução tecnicamente ambiciosa. Também será uma das partes mais interessantes dos futuros testes do Mac Studio: cargas reais mostrarão até que ponto o sistema consegue escalar entre todos os dies sem sofrer com sincronização, temperatura ou distribuição desigual do trabalho.

Até 36 núcleos de CPU no Mac Studio

O M5 Ultra pode ser configurado com uma CPU de até 36 núcleos, divididos entre 12 super cores e 24 núcleos de desempenho. Diferentemente do M6, não há núcleos de eficiência nessa configuração máxima divulgada.

Isso deixa evidente a prioridade. O M5 Ultra não foi construído para economizar cada pequena parcela de energia durante tarefas leves. Ele foi pensado para permanecer sob carga intensa, lidando com projetos nos quais terminar o trabalho mais cedo pode ser mais importante do que reduzir o consumo instantâneo.

A Apple aponta desempenho single-thread até 1,25 vez superior ao M3 Ultra e desempenho multithread até 1,3 vez maior. As comparações foram realizadas pela própria empresa com unidades de pré-produção do novo Mac Studio.

Um avanço de 30% em cargas multithread pode parecer menos dramático do que os números de IA apresentados no mesmo anúncio. A razão é que o foco desta geração está espalhado por várias áreas: interconexão dos dies, GPU, aceleradores neurais, memória, mecanismos de vídeo e execução local de modelos.

O M5 Ultra não é apenas uma CPU maior. Ele é uma plataforma de computação heterogênea.

GPU de até 80 núcleos e aceleração neural

A GPU do M5 Ultra chega a 80 núcleos, cada um equipado com um Neural Accelerator. Segundo o comunicado, a capacidade máxima de computação da GPU para IA pode ser até 4,5 vezes a do M3 Ultra e mais de seis vezes a do M1 Ultra.

Em uma comparação distinta de desempenho no Mac Studio, a empresa fala em ganhos de até 4,3 vezes sobre o M3 Ultra em determinados trabalhos de IA. A diferença entre os números ocorre porque “pico de computação” e “desempenho medido em uma aplicação” não são a mesma coisa.

A GPU incorpora shaders atualizados, Dynamic Caching de segunda geração, mesh shading acelerado e ray tracing de terceira geração. A Apple promete gráficos até 40% mais rápidos que os do M3 Ultra em sua comparação de arquitetura, enquanto a apresentação do novo Mac Studio menciona ganhos de até 1,8 vez em cargas selecionadas.

É um processador voltado a trabalhos bastante específicos:

  • renderização tridimensional;
  • efeitos visuais;
  • geração de imagens e vídeos;
  • treinamento ou ajuste de modelos;
  • simulações científicas;
  • visualização de grandes conjuntos de dados;
  • inferência de modelos generativos;
  • desenvolvimento de jogos;
  • edição de vídeo em alta resolução.

Para um usuário que navega na internet, edita documentos e ocasionalmente trabalha com imagens, grande parte dessa capacidade ficaria parada. O M5 Ultra faz sentido quando cada minuto de renderização, compilação ou processamento tem valor econômico.

Os 512 GB de memória são uma parte central do projeto

O componente mais impressionante do M5 Ultra talvez não seja a CPU nem a GPU. É a possibilidade de configurar o Mac Studio com até 512 GB de memória unificada e acessar essa memória com largura de banda de 1,2 TB/s.

A largura de banda é 50% superior à do M3 Ultra, de acordo com a Apple. Ela representa a quantidade de dados que o sistema consegue movimentar por segundo entre a memória e as unidades de processamento.

Grandes modelos de linguagem são particularmente sensíveis a esse fator. Durante a inferência, o computador precisa acessar repetidamente os pesos do modelo. Quando a largura de banda não acompanha a capacidade da GPU, os núcleos ficam esperando pelos dados.

Os 512 GB também permitem manter modelos muito grandes inteiramente na memória. A Apple afirma que o sistema pode executar localmente LLMs com centenas de bilhões de parâmetros, desde que sejam utilizados formatos e níveis de quantização compatíveis com a capacidade disponível.

Isso não significa que qualquer modelo desse tamanho será executado em sua precisão original ou terá o mesmo desempenho de um grande data center. Modelos podem exigir quantização para reduzir o consumo de memória. O tamanho do contexto também ocupa espaço, assim como o próprio sistema operacional e os aplicativos.

Mesmo com essas ressalvas, trata-se de uma capacidade incomum em um computador de mesa compacto. Muitas GPUs dedicadas de alto desempenho oferecem memória muito mais limitada. Servidores conseguem superar essa quantidade combinando várias placas, mas o custo, o consumo e a complexidade aumentam rapidamente.

A memória unificada cria uma característica interessante: os 512 GB não estão presos exclusivamente à CPU ou à GPU. O sistema pode distribuir seu uso conforme a carga. Para pesquisa local, prototipagem e trabalho com modelos privados, isso pode ser mais valioso do que uma simples comparação de núcleos.

Inteligência artificial local não é apenas uma questão de velocidade

A Apple associa os novos processadores à possibilidade de executar modelos de IA sem enviar dados continuamente para a nuvem.

Essa abordagem oferece algumas vantagens. Informações sensíveis podem permanecer no computador. A aplicação continua funcionando mesmo com conectividade limitada. O usuário não precisa pagar por cada token processado por um serviço remoto. A latência também pode diminuir, especialmente em tarefas interativas.

Existem limitações.

Modelos em nuvem podem utilizar grandes agrupamentos de GPUs, receber atualizações frequentes e atender cargas que seriam inviáveis em um computador pessoal. Executar tudo localmente exige armazenamento, memória, energia e capacidade de manutenção. Alguns modelos sequer possuem pesos abertos para instalação.

A tendência mais provável é híbrida. Tarefas privadas, rápidas ou repetitivas serão processadas no próprio Mac. Operações muito grandes ou dependentes de modelos fechados continuarão utilizando servidores.

O M6 e o M5 Ultra cobrem dois pontos dessa arquitetura. O M6 oferece IA local integrada ao computador cotidiano. O M5 Ultra tenta colocar uma parcela da computação antes restrita a servidores dentro de um desktop profissional.

Um mecanismo de mídia construído para produção audiovisual

O M5 Ultra também recebe um Media Engine mais poderoso, com aceleração dedicada para H.264, HEVC, ProRes, ProRes RAW e decodificação AV1.

Na configuração divulgada pela Apple, o chip possui dois mecanismos de decodificação de vídeo, quatro mecanismos de codificação e quatro unidades ProRes de codificação e decodificação. A empresa diz que o Mac Studio consegue reproduzir simultaneamente até 33 fluxos de vídeo ProRes 422 em resolução 8K e 30 quadros por segundo.

Esse tipo de aceleração é diferente de executar toda a operação na CPU. Blocos especializados conseguem processar codecs com mais eficiência, liberando CPU e GPU para efeitos, composição, correção de cor e outras partes do projeto.

Para editores de vídeo, estúdios e profissionais de efeitos visuais, o Media Engine pode ter impacto mais concreto do que o discurso sobre IA. Um projeto com várias câmeras, arquivos de alta resolução e camadas de efeitos coloca pressão sobre memória, armazenamento, decodificação e renderização ao mesmo tempo.

A página de especificações do Mac Studio confirma opções com CPU de 30 ou 36 núcleos, GPU de 64 ou 80 núcleos, Neural Engine de 32 núcleos e configurações de memória que chegam a 512 GB.

Desenvolvedores terão que aproveitar CPU, GPU e Neural Engine

Hardware especializado só apresenta bons resultados quando existem ferramentas capazes de utilizá-lo.

A Apple está concentrando esse trabalho em tecnologias como Core AI, Core ML, Metal, MLX e Xcode. Cada uma atua em uma parte diferente do processo de criação e execução de aplicações inteligentes.

O Core ML permite integrar modelos de aprendizado de máquina aos aplicativos. O Metal oferece acesso à computação da GPU. O MLX é um framework aberto e otimizado para Apple silicon, usado em experimentação, treinamento e inferência. Já o novo Core AI procura organizar a execução de modelos entre memória unificada, CPU, GPU e Neural Engine.

A proposta é evitar que o desenvolvedor precise administrar manualmente cada unidade de processamento. Os frameworks analisam as operações e tentam utilizar o componente mais adequado.

A Apple também permite que aplicativos acessem seus Foundation Models e recursos da Apple Intelligence por meio de ferramentas como App Intents. Desenvolvedores continuam podendo incorporar modelos próprios, o que é indispensável para empresas que trabalham com informações privadas ou sistemas especializados.

O benefício será maior nos aplicativos que adotarem essas APIs. Softwares antigos ou desenvolvidos sem otimização específica podem utilizar apenas uma pequena parte do novo hardware.

E existe a questão da compatibilidade. Nem todo modelo criado para CUDA ou preparado para GPUs de outros fabricantes será transportado imediatamente para o ecossistema da Apple. Ferramentas como MLX reduzem essa barreira, mas o ecossistema de software ainda pesa tanto quanto o silício.

Mac mini e Mac Studio deixam de disputar exatamente o mesmo usuário

O novo Mac mini com M6 procura oferecer desempenho elevado em uma máquina compacta, com 16 GB de memória na configuração inicial e possibilidade de chegar a 32 GB. Ele atende programação, produtividade, edição, desenvolvimento e experimentação com IA local.

A Apple também o posiciona como um dispositivo que pode permanecer ligado executando agentes de inteligência artificial. Esse é um uso relativamente novo para um computador doméstico: uma pequena máquina dedicada a automações, análise de documentos, geração de conteúdo, monitoramento ou serviços locais.

Já o Mac Studio com M5 Ultra funciona como estação profissional. Seu público não está apenas procurando um computador rápido. Está procurando capacidade para manter conjuntos enormes de dados na memória, processar vídeo de alta resolução ou executar modelos que não cabem em equipamentos convencionais.

A diferença aparece até na escala da conectividade. O novo Mac Studio adota Thunderbolt 5 e pode utilizar RDMA para formar grupos de várias máquinas. A Apple afirma que um cluster de quatro Mac Studio pode alcançar até três vezes o desempenho de inferência de uma única unidade em cargas selecionadas.

Isso não transforma o Mac Studio em substituto universal de um data center. Cria, porém, uma opção intermediária interessante entre um computador pessoal e uma infraestrutura especializada de servidores.

Os números são grandes, mas ainda são números da Apple

Quase todas as comparações apresentadas até agora foram produzidas pela própria fabricante em computadores de pré-produção, utilizando sistemas e cargas selecionadas.

Isso não invalida os resultados. A Apple informa a configuração das máquinas comparadas e descreve que utilizou benchmarks e aplicações específicas. O cuidado necessário está na interpretação.

“Até 4,5 vezes mais computação de IA” não significa que qualquer modelo ficará 4,5 vezes mais rápido. “Até 40% mais desempenho gráfico” não garante a mesma diferença em todos os jogos. “O núcleo mais rápido do mundo” depende do conjunto de sistemas, do benchmark e dos limites energéticos usados na comparação.

Também será necessário observar:

  • desempenho após vários minutos de carga;
  • temperatura e ruído;
  • consumo na tomada;
  • escalabilidade entre os quatro dies;
  • eficiência do Dual Neural Engine;
  • compatibilidade dos modelos;
  • desempenho com diferentes quantizações;
  • velocidade real de geração de tokens;
  • comportamento com toda a memória ocupada;
  • suporte dos aplicativos profissionais.

Os lançamentos foram anunciados em 25 de agosto de 2026, e a disponibilidade dos novos Mac mini e Mac Studio está prevista para 22 de setembro. Até que as unidades comerciais sejam analisadas por veículos e laboratórios independentes, o material oficial deve ser entendido como uma apresentação técnica acompanhada de marketing.

A mudança mais importante não está na litografia

Os 2 nanômetros do M6 são importantes. A arquitetura com quatro dies do M5 Ultra também. Mesmo assim, o aspecto mais revelador do anúncio é a distribuição do processamento neural por todo o chip.

A Apple não depende apenas de um Neural Engine maior. Ela adiciona Neural Accelerators aos núcleos da GPU, amplia a memória, aumenta a largura de banda, desenvolve novos frameworks e prepara o sistema para movimentar trabalhos entre diferentes unidades.

O computador deixa de ter “um componente de IA” isolado. A inteligência artificial passa a influenciar o desenho completo do processador.

Esse movimento também aparece na quantidade de memória do M5 Ultra. Durante anos, a discussão sobre computadores pessoais ficou concentrada em CPU e GPU. Modelos generativos trouxeram a memória novamente para o centro do projeto, pois não adianta possuir dezenas de núcleos se os pesos do modelo não cabem no sistema ou chegam lentamente às unidades de cálculo.

O M6 procura tornar a IA local uma função normal de um Mac compacto. O M5 Ultra leva a mesma ideia ao limite, com quatro dies, GPU de 80 núcleos, 512 GB de memória e largura de banda de 1,2 TB/s.

Ainda não sabemos se a geração cumprirá todas as promessas de desempenho. Isso depende de testes, aplicativos e de como os desenvolvedores responderão às novas ferramentas. O rumo, porém, ficou claro: para a Apple, o próximo ciclo dos computadores não será definido apenas por máquinas mais rápidas, mas por quanto processamento inteligente elas conseguem realizar sem sair da mesa do usuário.

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.

Representação da hierarquia de memória de um computador, dos registradores ao armazenamento em HDD
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.

Meta e Google desafiando o ecossistema da Nvidia

Nvidia

A Nvidia não ficou gigante só porque fez uma GPU rápida e mandou uma nota fiscal junto. Ela ficou gigante porque transformou um detalhe técnico em hábito cultural: a ideia de que “fazer IA de verdade” é, por definição, fazer IA em CUDA.

Isso é mais poderoso do que um chip. Um chip você troca quando aparece outro melhor. Um hábito você troca quando a dor de mudar fica menor do que a dor de continuar do mesmo jeito.

Durante anos, o mercado contou uma história confortável para explicar o domínio da Nvidia: “as GPUs são as mais avançadas”. Essa frase tem um pedaço de verdade, só que ela serve melhor como marketing do que como explicação. Se desempenho bruto fosse o único juiz, a coroa teria mudado de cabeça várias vezes. Houve gerações em que concorrentes ficaram perto, houve soluções mais baratas, houve momentos em que o custo por desempenho parecia tentador. Mesmo assim, quase ninguém fez a troca em massa.

Porque o trono da Nvidia não fica só no silício. O trono fica na camada onde as equipes gastam anos da vida: ferramentas, bibliotecas, kernels, rotinas de treino distribuído, perfiladores, receitas de otimização, tutoriais, exemplos, bugs conhecidos, jeitos de debugar, jeitos de contratar. Um ecossistema que vira padrão não precisa obrigar ninguém. Ele só precisa fazer o resto parecer trabalhoso.

E aí entra o que mudou, com o peso de um “clique” que desencaixa um império: Google e Meta estão mirando exatamente a peça que sustenta esse aprisionamento invisível, o software. Em dezembro de 2025, a Reuters noticiou que o Google está trabalhando num projeto interno chamado TorchTPU, com o objetivo de tornar as TPUs mais naturais para quem desenvolve em PyTorch, com colaboração próxima da Meta, grande apoiadora do PyTorch, e com possibilidade de abrir partes do software para acelerar adoção.

A ambição é simples de dizer e brutal de executar: permitir que empresas mudem de Nvidia para TPU sem precisar reescrever as partes críticas do código, sem desmontar o stack inteiro, sem abandonar PyTorch. Se essa fricção cair, a conversa deixa de ser “Nvidia ou caos” e vira “Nvidia ou concorrência”. A Nvidia pode continuar excelente e ainda assim perder a coisa que mais importa em mercados maduros: poder de barganha.

O lock-in que ninguém assina, mas todo mundo sente

Quando se fala em lock-in, muitos imaginam contrato, cláusula, exclusividade. No caso da Nvidia, a amarra é mais elegante, e por isso mais perigosa: ela se esconde no custo prático da mudança.

Uma equipe que diz “nosso modelo roda em PyTorch” geralmente quer dizer algo mais específico, mesmo que não verbalize: “nosso modelo foi escrito, treinado, ajustado, validado e colocado em produção num mundo em que CUDA era o chão”.

CUDA, na prática, virou o sistema nervoso periférico do stack de IA. Não é só “um jeito de rodar na GPU”. É um conjunto de escolhas acumuladas:

  • bibliotecas de alto desempenho para operações essenciais,
  • caminhos de precisão mista e quantização que foram refinados por anos,
  • comunicação entre GPUs e entre nós de cluster, com soluções já testadas no inferno do tráfego real,
  • profilers, ferramentas de debug, mecanismos de compilação, kernels otimizados e, talvez o mais importante, a “memória muscular” dos times.

Mudar isso não é trocar uma peça. É mexer na base do prédio enquanto tem gente morando dentro.

Por isso o lock-in da Nvidia sempre foi mais psicológico e operacional do que técnico. Em empresas, risco é uma moeda cruel. Risco de regressão, risco de instabilidade, risco de atraso, risco de gastar meses para descobrir que um detalhe do pipeline não tem equivalente. A conclusão prática era automática: ficar na Nvidia parecia racional, mesmo quando era caro.

E aqui tem um ponto curioso, quase irônico: a Nvidia nunca controlou o PyTorch. O PyTorch nasceu dentro da Meta e cresceu como projeto aberto, virando o framework dominante por mérito próprio, do laboratório à produção. O que a Nvidia fez, com genialidade de quem entende o jogo, foi se integrar tão bem que parecia dona.

Integração não é posse. Se o PyTorch ganhar um caminho “sem drama” para rodar bem fora de CUDA, a maior barreira de saída começa a virar poeira.

Por que “existem alternativas” nunca foi suficiente

“Mas já existem alternativas”, alguém sempre diz, e tecnicamente isso é verdade. AMD tem ROCm, Intel tem seus esforços, há aceleradores específicos, há chips especializados em inferência. Só que o mercado de IA em escala não premia apenas a existência de uma alternativa, ele premia uma alternativa que tenha três coisas ao mesmo tempo:

  1. performance competitiva em cargas relevantes,
  2. maturidade operacional, aquela sensação de “isso não vai me trair em produção”,
  3. compatibilidade com o jeito que o mundo já trabalha.

A maioria falha na terceira. Algumas falham na segunda. Várias falham nas duas.

A Nvidia virou o “default” porque fez o caminho parecer inevitável. Não por decreto, por conforto. Quando tudo funciona, quando os tutoriais batem com a realidade, quando a equipe encontra respostas, quando dá para contratar gente que já sabe o stack, a escolha vira hábito. E hábito é um tipo de monopólio emocional.

É por isso que a movimentação do Google assusta: ela não tenta vencer a Nvidia “na pancada” só com hardware. Ela tenta vencer no ponto onde o hábito se forma, a experiência do desenvolvedor.

TPUs: o problema nunca foi músculo, foi idioma

As TPUs do Google sempre carregaram um ar de “poder oculto”, aquele tipo de hardware que a gente ouve falar como se fosse uma arma interna, restrita, feita para as necessidades do próprio Google. A leitura confortável para a Nvidia era: “isso não importa para o mercado, porque ninguém fora do Google usa”.

Só que essa leitura era superficial. O próprio Google Cloud descreve TPUs como aceleradores desenhados para treinamento e inferência de modelos de IA, e elas já sustentam cargas gigantes dentro do ecossistema do Google. O que travava a adoção ampla não era falta de desempenho. Era o idioma de software.

Por muito tempo, o Google apostou com força em JAX e no universo de compilação ligado ao XLA. De novo, tecnicamente faz sentido. Só que o mercado não funciona como seminário de compiladores. Enquanto o Google empurrava um caminho mais “puro”, o resto do planeta consolidava outro caminho: PyTorch.

Para a maioria das empresas, adotar TPU significava adotar um jeito diferente de pensar, adaptar pipelines, revalidar tudo, treinar equipe, e no final ainda ficar com a sensação de estar fora do fluxo principal da indústria. Empresas não migram frameworks por hobby. Elas migram quando são empurradas por dor extrema ou quando a migração é suave.

O que o TorchTPU tenta fazer é inverter a lógica: em vez de pedir que o desenvolvedor se adapte ao hardware, o hardware passa a “se adaptar” ao desenvolvedor.

“Mas já existe PyTorch em TPU”, então qual é o drama?

Aqui entra uma camada importante, que separa “dá para rodar” de “dá para viver”.

O mundo já tem, faz tempo, o PyTorch/XLA, que conecta PyTorch a dispositivos XLA como TPUs. Isso está documentado oficialmente e existe como projeto público. E até em notas antigas do próprio Google Cloud aparece a ideia de suporte via integração PyTorch/XLA.

Então por que ainda existe espaço para um TorchTPU “novo”?

Porque “rodar” não significa “rodar do jeito que o desenvolvedor espera”. Na prática, muitas integrações desse tipo carregam pequenas fricções que, somadas, viram um pedágio enorme: diferenças de cobertura de operadores, comportamentos inesperados, caminhos mais frágeis para debug, diferenças no desempenho por tipo de modelo, desafios de distribuição, tooling menos maduro, e um detalhe que virou central no PyTorch moderno: a experiência eager, aquela sensação de que você escreve o código e ele responde na hora, com o mesmo modelo mental em todo lugar.

Em outubro de 2025, surgiu no próprio repositório do PyTorch/XLA uma proposta explícita para evoluir a experiência e chegar mais perto de algo “nativo”, com a ambição de fazer tensor.to('tpu') parecer tão natural quanto tensor.to('cuda'). Esse é o tipo de frase que parece pequena, até você perceber o que ela realmente significa: transformar TPU de “backend especial” em “cidadão de primeira classe” dentro do PyTorch.

E isso muda o jogo porque reduz a parte mais cara da migração, a parte humana: reaprender o mundo.

O que o TorchTPU realmente ameaça na Nvidia

O mercado gosta de imaginar batalhas de hardware como corrida de cavalos: quem tem mais FLOPS, quem tem mais memória, quem tem mais largura de banda. Só que a Nvidia construiu uma fortaleza onde o hardware é apenas a muralha visível. O fosso está no software, e o fosso é feito de custo de troca.

O TorchTPU, pelo que foi reportado, mira exatamente isso: tornar TPUs amigáveis para o maior framework do planeta, sem exigir que times mudem seu código nem abandonem PyTorch, com colaboração da Meta, e com possibilidade de abrir partes do stack para ganhar tração mais rápido. Essa ameaça não é “as GPUs vão morrer”. Essa ameaça é “as GPUs deixam de ser a única resposta sensata”.

Em mercados de infraestrutura, “única resposta sensata” é como se fabrica margem alta. Quando o cliente não tem alternativa viável, ele aceita preço, prazo, pacote completo, aceitação resignada. Quando aparece uma alternativa boa o suficiente, o cliente não precisa nem migrar para já mudar a conversa. Ele só precisa conseguir dizer, com credibilidade: “eu posso ir embora”.

A Nvidia, por anos, vendeu previsibilidade. “Seu código roda aqui, seu time sabe mexer aqui, seu risco é menor aqui.” Isso sustenta múltiplos altos porque vira uma espécie de seguro embutido. Só que seguro perde valor quando a apólice concorrente fica boa.

Por que a Meta muda o peso específico dessa história

Se esse movimento viesse só do Google, parte do mercado trataria como mais um capítulo do “Google tentando competir com Nvidia”. O Google tem histórico de projetos tecnicamente brilhantes que demoram a virar hábito fora da própria casa.

A Meta muda isso por três motivos. Primeiro, porque a Meta tem interesse econômico brutal em diversificar. O custo de treinamento e inferência em escala de rede social global é um monstro que nunca dorme. Depender de um único fornecedor, num mercado com filas, prazos e preços agressivos, é aceitar fragilidade estratégica. Segundo, porque a Meta é o berço do PyTorch e continua sendo uma força determinante na sua evolução. Quando a empresa que ajudou a criar o framework participa da portabilidade de forma ativa, a chance de isso virar padrão aumenta, porque não é um “plugin lateral”, é o coração do ecossistema se mexendo. Terceiro, porque isso cria efeito cascata. Quando o criador do framework dá sinais de que múltiplos backends importam, ferramentas ao redor se adaptam, bibliotecas seguem, integradores entram, provedores oferecem suporte, e a profecia começa a se autorrealizar.

Esse ponto conversa com outra peça do tabuleiro: não é só software. O Google também tem buscado expandir o negócio de TPUs para fora do seu “jardim murado”, com reportagens indicando oferta de TPUs para uso em data centers de clientes e interesse de grandes compradores. Quando você junta “hardware disponível” com “experiência de PyTorch mais nativa”, o obstáculo deixa de ser filosófico e vira operacional, e isso é o tipo de coisa que compras e infraestrutura entendem muito bem.

O que muda quando “sair” deixa de ser impensável

Aqui é onde o mercado às vezes erra o foco. O preço da ação pode reagir pouco no começo porque o mundo ama narrativas simples, e a narrativa simples é: “Nvidia continua líder, ponto”. Só que a ameaça verdadeira costuma ser lenta, silenciosa e burocrática. Ela nasce em comitê de arquitetura, em prova de conceito, em planilha de custo por inferência.

Quando existe alternativa real, acontecem mudanças bem específicas:

  • Negociação: o cliente passa a negociar preço e condições com mais força, mesmo sem trocar nada no curto prazo.
  • Planejamento: times começam a desenhar pipelines com portabilidade em mente, para não serem reféns.
  • Padronização: ferramentas passam a assumir múltiplos backends como normal, e isso reduz a vantagem do “default histórico”.
  • Margem: margens caem antes da participação de mercado cair, porque o poder de precificação é o primeiro a sofrer.

A Nvidia não precisa perder o trono para perder poder. Ela só precisa deixar de ser inevitável.

A parte difícil que quase todo mundo subestima

A história seria fácil se bastasse “rodar PyTorch na TPU” e pronto. Não é assim. Construir paridade prática com CUDA em ambientes corporativos é o tipo de trabalho ingrato que exige anos de engenharia, testes e acertos finos. A própria existência de discussões públicas sobre tornar o backend mais “nativo” mostra que ainda há estrada pela frente.

Alguns desafios que costumam aparecer nesse tipo de migração, mesmo quando o código do modelo não muda:

  • cobertura completa de operadores e casos de borda,
  • estabilidade e previsibilidade em produção, com observabilidade madura,
  • desempenho consistente em modelos variados, não só em benchmarks “favoráveis”,
  • suporte a treinamento distribuído e inferência em escala com ergonomia de engenharia,
  • ecossistema ao redor, como quantização, kernels customizados, serving, compilação, profiling.

O detalhe é que essa lista não precisa ficar perfeita para ameaçar o lock-in. Ela precisa ficar boa o suficiente em um subconjunto valioso, por exemplo, inferência massiva de modelos populares, ou treinamento de certas famílias de arquitetura. Em infraestrutura, atacar um pedaço muito caro do custo já é suficiente para criar “saídas” na fortaleza.

E a Nvidia, fica parada?

Seria estranho imaginar a Nvidia olhando isso de braços cruzados. Ela tem recursos, talento e uma vantagem real: maturidade de ecossistema, ferramental e rede de parceiros.

O que tende a acontecer, como dinâmica de mercado, é uma corrida em duas frentes:

  1. A Nvidia reforça o valor do seu ecossistema, com melhores ferramentas, melhor performance, melhores bibliotecas, mais integração com frameworks, mais facilidades que façam o custo de ficar parecer ainda menor.
  2. O resto do mercado tenta reduzir o custo de sair, criando caminhos compatíveis, “nativos”, que façam a troca parecer só uma decisão de infraestrutura.

O segundo ponto é exatamente o que torna TorchTPU interessante, e por que a participação da Meta é um multiplicador, não um detalhe.

O cenário mais plausível, se essa peça encaixar

Em vez de imaginar um “colapso” da Nvidia, a visão mais realista é um deslocamento gradual do centro de gravidade:

  • no começo, TPUs viram alternativa crível para alguns workloads, principalmente onde custo por inferência pesa mais que qualquer outra coisa,
  • depois, empresas começam a adotar postura multi fornecedor, mesmo mantendo Nvidia como base,
  • com o tempo, a pressão competitiva aparece em preços, prazos e contratos, antes de aparecer em manchetes dramáticas.

Esse é o tipo de mudança que, vista de perto, parece lenta. Vista de longe, parece inevitável.

Uma última observação, que vale ouro para não cair em torcida: nada disso é destino. É uma hipótese de engenharia e mercado. Se o TorchTPU virar uma integração meia boca, se a experiência continuar “especial”, se o desempenho for inconsistente, se o suporte corporativo for frágil, a Nvidia segue com o fosso cheio de crocodilos. Se o TorchTPU entregar uma experiência realmente banal, previsível e eficiente, aquela palavra que sustenta impérios, inevitável, começa a perder o sentido.


Referências

Exclusive: Google works to erode Nvidia's software advantage with Meta's help https://www.reuters.com/business/google-works-erode-nvidias-software-advantage-with-metas-help-2025-12-17/

Cloud Tensor Processing Units (Cloud TPUs) https://cloud.google.com/tpu

PyTorch/XLA https://github.com/pytorch/xla

Evolving PyTorch/XLA for a more native experience on TPU https://github.com/pytorch/xla/issues/9684

Cloud TPU release notes https://docs.cloud.google.com/tpu/docs/release-notes

Meta and Google could be about to sign a mega AI chip deal - and it could change everything in the tech space https://www.techradar.com/pro/meta-and-google-could-be-about-to-sign-a-mega-ai-chip-deal-and-it-could-change-everything-in-the-tech-space

O desenvolvimento da tecnologia e economia

Economia e Tecnologia

Um jeito para começar é admitir o óbvio que esquecemos: a economia global é, em grande parte, um gigantesco sistema de informação disfarçado de “mercado”. Dinheiro é informação. Preço é informação. Juros são informação. Estoque parado em um galpão é informação atrasada, quase sempre cara. Quando você olha por esse ângulo, tecnologia deixa de ser “um setor” e vira um tipo de infraestrutura cognitiva que permite que bilhões de decisões descentralizadas aconteçam com menos atrito.

E é aqui que a conversa fica interessante: o que chamamos de “desenvolvimento tecnológico” não é só a invenção de novas possibilidades, é a criação de meios para reduzir incerteza, coordenar ações e automatizar confiança. Parece abstrato? Vamos entender melhor isso.

Pensa num produtor de café no interior de Minas Gerais no Brasil, negociando com uma torrefadora na Europa. Décadas atrás, esse contrato dependia de telefonemas, intermediários, papelada, bancos correspondentes, prazos longos, taxas gordas e uma boa dose de fé. Hoje, ele pode acompanhar preço em tempo real, travar parte do risco com instrumentos financeiros acessíveis, emitir nota, rastrear logística e receber em prazos menores. A colheita é a mesma, o que mudou foi o “sistema nervoso” que conecta oferta e demanda.

Esse sistema nervoso é feito de tecnologias atuais que costumamos tratar como coisas separadas: computação em nuvem (infraestrutura sob demanda, paga conforme uso), redes móveis, plataformas, APIs (interfaces de programação de aplicações, “tomadas” digitais que conectam sistemas), aprendizado de máquina (modelos estatísticos que aprendem padrões a partir de dados), criptografia (técnicas matemáticas para proteger e validar informação). Só que o efeito econômico aparece quando elas se combinam e viram capacidade de coordenação.

Coordenação é uma palavra que soa burocrática, só que ela é uma das forças mais caras do mundo. Em economia, existe um conceito útil chamado custo de transação (o custo de buscar informação, negociar, fiscalizar, garantir cumprimento). Se um país inteiro consegue reduzir custos de transação, ele “ganha produtividade” mesmo sem descobrir um novo mineral, mesmo sem aumentar a área plantada, mesmo sem achar um motor mágico. Ele passa a fazer mais com o que já tem. Isso ajuda a explicar por que softwares e sistemas, que parecem etéreos, conseguem mexer em coisas tão materiais quanto inflação, emprego e crescimento.

Aí aparece uma pergunta que incomoda: se tecnologia melhora produtividade, por que tantos sente a vida mais cara e mais instável? A resposta é bem mais complexa, é um conjunto de camadas. Ganhos de produtividade nem sempre viram salário, nem sempre viram preço mais baixo, às vezes viram concentração de mercado, às vezes viram novos custos (assinaturas, taxas, dependência), às vezes viram velocidade demais para instituições lentas. Tecnologia resolve problemas e cria outros, e os novos problemas costumam ser mais sutis.

Vamos falar de desenvolvimento de sistemas, porque é ali que a economia vira prática. “Sistema”, no mundo real, é uma rede de decisões automatizadas. Um ERP (Enterprise Resource Planning, software que integra finanças, estoque, compras e produção) não é só um programa, é um jeito de impor uma gramática à empresa: como se compra, como se registra, como se mede, como se audita. Quando uma empresa adota um ERP, ela está escolhendo um modelo de mundo. Essa escolha pode aumentar eficiência, mas também pode engessar processos ou esconder vieses, dependendo de como foi configurado.

Quem nunca ouviu alguém dizer “o sistema não deixa”? Esse “não deixa” é economia em ação. É governança (conjunto de regras e mecanismos de controle) codificada. E governança codificada pode ser maravilhosa quando reduz fraude e desperdício, pode ser péssima quando impede exceções humanas necessárias. Um hospital, por exemplo, precisa de protocolos; um protocolo rígido demais pode virar crueldade logística.

Essa ambivalência fica ainda mais forte quando sobemos para o nível global. Cadeias de suprimento modernas são sistemas distribuídos (partes independentes que cooperam por meio de comunicação e padrões). Distribuído aqui não é só “espalhado”, é um desenho em que cada nó toma decisões localmente, seguindo regras comuns. Isso dá resiliência, mas também abre portas para falhas sistêmicas: um porto congestionado, uma falta de semicondutores, um ataque cibernético, uma pandemia. O mundo fica eficiente e frágil ao mesmo tempo. Eficiência não é sinônimo de robustez; às vezes é o contrário.

A economia global vem buscando soluções justamente nesse dilema: como manter a produtividade sem aumentar a fragilidade? Uma resposta forte é observabilidade (capacidade de medir o que está acontecendo dentro de sistemas complexos a partir de dados e sinais). Observabilidade começou como um tema de engenharia de software, com logs, métricas e rastreamento. Hoje, ela virou peça econômica. Empresas querem enxergar seus fluxos quase como um organismo enxerga seus próprios batimentos.

E aqui aparece um ponto-chave: tecnologia não “cria riqueza” do nada; ela reorganiza informação, tempo e confiança. Quando você reorganiza esses três elementos, você altera o custo de coordenação e, por extensão, altera a produtividade. Esse é um dos motores discretos da economia digital.

Repara como esse ponto é menos glamouroso do que dizer “IA vai revolucionar tudo”. Só que ele explica mais. E por explicar mais, ele incomoda mais.

Falando em IA, o aprendizado de máquina não é “inteligência” no sentido humano; é uma coleção de técnicas para estimar funções a partir de dados, encontrando padrões úteis para previsão ou classificação. Um modelo pode prever inadimplência com boa precisão e ainda assim ser injusto, porque aprende padrões do passado, e o passado tem desigualdades. Se bancos automatizam crédito usando esses modelos, a economia ganha eficiência operacional, só que pode ampliar exclusão financeira se não houver governança e auditoria.

Auditoria algorítmica (processos para avaliar desempenho, vieses e impactos de modelos) vira um tema econômico porque crédito é energia do capitalismo. Crédito define quem investe, quem cresce, quem quebra. Um erro em escala não é um bug simpático, é uma força social.

Em desenvolvimento de sistemas, isso se traduz em uma mudança de mentalidade: não basta “funcionar”, precisa ser confiável, explicável em certo grau, seguro, compatível com leis, compatível com valores sociais. “Compatível com valores” pode soar moralista, só que é só realismo: sistemas moldam comportamento. Um aplicativo de transporte redefine como a cidade se move. Um marketplace redefine como pequenos vendedores competem. Uma plataforma de pagamentos redefine como informalidade vira formalidade, ou como novas taxas corroem margens.

Plataformas são outro conceito que merece definição, no sentido econômico, é uma estrutura que conecta grupos diferentes (por exemplo, compradores e vendedores) e cria efeitos de rede (quanto mais gente usa, mais valioso fica). Efeito de rede é poderoso porque gera concentração natural: as pessoas preferem onde já tem gente. Isso pode aumentar eficiência e reduzir custo de busca, mas também pode criar dependência e poder de mercado.

Você sente isso quando um pequeno negócio se torna refém de um app de entrega. O app resolve logística e acesso a clientes, só que cobra taxas, define regras, pode mudar o algoritmo de exposição. A empresa “ganha” mercado e “perde” autonomia. Economia digital é cheia dessas trocas: eficiência por controle.

E por falar em controle, a infraestrutura invisível do mundo atual é a nuvem. Nuvem não é “um lugar”; é um modelo de computação em que recursos são provisionados sob demanda, em data centers gigantes, com contratos e camadas de serviço. Isso permite que uma startup tenha poder computacional de corporação sem comprar servidores. É um choque de democratização produtiva. Só que também cria concentração: poucos provedores controlam a infraestrutura central de milhares de empresas. Um apagão na nuvem vira um mini-terremoto econômico.

Quando o tema é economia global, tecnologias que reduzem barreiras de entrada importam muito. Barreira de entrada é tudo aquilo que impede alguém de competir: capital inicial alto, necessidade de escala, regulação difícil, acesso a distribuição. Nuvem, ferramentas open source, pagamentos digitais e logística integrada baixam algumas barreiras. Isso explica por que tantos microempreendedores surgem e também explica por que a competição fica brutal. Se é mais fácil entrar, é mais fácil ser esmagado. O mercado vira um estádio com mais jogadores e regras mais rápidas.

Vamos dar um salto para um assunto que costuma passar: padrões. Padrão é chato, e exatamente por isso ele é revolucionário. Um padrão de dados (por exemplo, um formato de nota fiscal eletrônica, um protocolo de pagamento, um esquema de interoperabilidade) permite que sistemas “conversem” sem negociação individual. Interoperabilidade (capacidade de sistemas diferentes trocarem informação e operarem juntos) é uma forma de infraestrutura pública, mesmo quando é feita por consórcios privados.

Quando um país cria um sistema de pagamentos instantâneos, o efeito econômico não é só conveniência. Pagamentos instantâneos reduzem capital de giro necessário (dinheiro parado para cobrir prazo), reduzem risco de liquidação, permitem novos modelos de negócio e também aumentam rastreabilidade, o que muda a dinâmica de informalidade e arrecadação. A solução parece “tecnológica”, mas a consequência é macroeconômica.

Macroeconomia, aliás, vive sendo tratada como um bicho separado. Só que desenvolvimento de sistemas mexe com macroeconomia porque mexe com a velocidade do dinheiro, com a competição, com a formação de preços. Quando marketplaces comparam preços em milissegundos, o varejo muda. Quando algoritmos otimizam rotas, o custo logístico muda. Quando fintechs usam dados alternativos para crédito, o spread (diferença entre custo de captação e taxa cobrada) pode cair para alguns e subir para outros. Tudo depende de desenho, regulação e poder de mercado.

Regulação é outra palavra que costuma ser pintada como vilã ou heroína, quando ela é, na prática, um mecanismo de sincronização entre tecnologia e sociedade. Sem regulação, incentivos podem premiar o atalho perigoso: coletar dados demais, explorar trabalho, externalizar risco. Com regulação mal desenhada, você mata inovação e cria cartéis involuntários. O ponto difícil é calibrar.

E calibrar exige entender como inovação acontece. Existe uma visão ingênua de que inovação é um gênio inventando algo e pronto. No mundo real, inovação é uma cadeia: ciência básica, engenharia, produto, mercado, feedback, iteração, padronização, escala. Desenvolvimento de sistemas é o motor dessa iteração porque transforma hipótese em serviço operável. Operável significa rodar com milhões de usuários, com falhas previstas, com segurança, com monitoramento. Isso é uma ciência aplicada de altíssimo nível, mesmo quando é vendida como “um app”.

Segurança merece um parágrafo inteiro, porque ela é uma variável econômica. Cibersegurança (proteção de sistemas contra acesso indevido e ataques) custa dinheiro, e ataques também custam dinheiro, só que o custo aparece em lugares diferentes. Quando uma empresa economiza em segurança, ela reduz despesa hoje e aumenta risco sistêmico amanhã. Em escala global, isso é parecido com poluição: o incentivo individual pode produzir dano coletivo. A diferença é que o dano pode ser instantâneo e invisível. Um ransomware em hospital não é um incidente “digital”, é um incidente humano.

Aí volta a pergunta: tecnologia está “dando soluções” para a economia global? Sim, em vários sentidos mensuráveis: reduz custos de coordenação, amplia acesso, acelera inovação, melhora eficiência energética em alguns setores, otimiza recursos escassos. Só que ela também cria dilemas novos: concentração, precarização em alguns modelos, dependência de infraestrutura, assimetrias de informação ainda mais sofisticadas, e uma espécie de ansiedade sistêmica, porque o mundo fica mais rápido do que nossa capacidade de deliberar.

Talvez a parte mais delicada seja a assimetria de informação. Assimetria de informação é quando uma parte sabe muito mais do que a outra numa transação. A economia clássica já sabia que isso gera problemas: seleção adversa, moral hazard. No mundo digital, assimetria de informação vira uma arte. Plataformas sabem padrões de consumo, elasticidade de preço (o quanto a demanda muda quando o preço muda), propensão a compra, horários, renda provável. Isso permite personalização, o que pode ser ótimo, e também permite discriminação de preços, o que pode ser abusivo se não houver transparência.

E é aqui que dá para reforçar aquele ponto-chave: o eixo oculto dessa história é confiança automatizada. Quando sistemas conseguem registrar, validar e prever, eles substituem partes do tecido social que antes dependiam de instituições lentas ou relações pessoais. Essa substituição reduz fricção e aumenta produtividade, só que muda o poder de quem controla os mecanismos de validação. Quem decide o que conta como “verdade” no sistema? Quem tem o botão de desligar? Quem audita o auditor?

A economia global, hoje, é uma disputa por governança de infraestrutura digital. Não é só sobre gadgets. É sobre camadas: camada de dados, camada de computação, camada de pagamento, camada de identidade, camada de logística, camada de reputação. Reputação é especialmente interessante. Sistemas de reputação (notas, avaliações, histórico) resolvem um problema antigo: como confiar em estranhos. Eles fazem isso transformando comportamento em números. Só que números viram incentivos, e incentivos mudam comportamento. O motorista corre para manter nota, o vendedor implora avaliação, o consumidor usa a avaliação como arma.

Esse detalhe puxa outro: inovação técnica frequentemente resolve um gargalo e empurra o gargalo para outro lugar. Se você otimiza logística, o gargalo pode virar embalagem. Se você otimiza crédito, o gargalo pode virar inadimplência em crise. Se você otimiza produção, o gargalo pode virar descarte e sustentabilidade. Solução local, problema global. Um olhar científico pede que a gente trate isso como sistema dinâmico (sistema que muda no tempo com feedbacks). Feedback é quando uma saída do sistema volta como entrada e altera o comportamento. Mercados estão cheios de feedbacks: preço sobe, demanda cai, produção ajusta, preço cai. Tecnologia acelera esses loops.

A aceleração pode ser saudável ou caótica. Em mercados financeiros, por exemplo, automação e alta frequência tornaram o sistema mais eficiente em condições normais e mais propenso a eventos rápidos em condições extremas. Eficiência média e risco de cauda (eventos raros, muito danosos) podem andar juntos. Economia global vive tentando colher eficiência sem pagar a conta das caudas.

E o que isso tem a ver com desenvolvimento de sistemas? Tudo, porque sistemas são a forma concreta como esses loops são implementados. Um bug num sistema de precificação pode gerar uma cascata. Um erro num sistema de estoque pode causar desperdício em massa. Um erro num modelo de previsão pode gerar falta de produto, inflação localizada, perda de confiança. Quando tudo é conectado, pequenos erros ganham alavanca.

É por isso que engenharia de software moderna fala tanto de capacidade de continuar operando sob falhas e de testes intencionais de falhas para entender comportamento. Parece papo de dev, só que é economia aplicada. Uma empresa aguenta choques sem quebrar, uma cadeia resiliente reduz risco de desabastecimento; um setor resiliente evita que um incidente local vire crise macro.

O desafio prático, para quem constrói sistemas e para quem pensa economia, é reconhecer que “solução” raramente é um objeto, solução é um arranjo. Arranjo de incentivos, de padrões, de governança, de auditoria, de infraestrutura e de cultura. Quando esse arranjo é bem desenhado, tecnologias atuais viram ferramentas de prosperidade distribuída. Quando é mal desenhado, viram amplificadores de desigualdade e fragilidade.

O que torna a computação quântica tão diferente da computação clássica?

Computador Quântico
Ouça o artigo:

Quem nunca ouviu falar das promessas quase míticas de computadores quânticos? Dizem que computadores quânticos vão resolver de tudo, da crise ambiental ao seu problema no relacionamento (confesso que sobre esse último sou cético). Mas afinal, o que é computação quântica? Por que tanto entusiasmo? E como ela realmente difere da computação tradicional que já virou parte do nosso cotidiano?

Essa conversa vai direto ao ponto: as diferenças centrais entre a computação clássica e a quântica, onde cada uma se destaca, e o motivo desse futuro tão esperado, e temido, às vezes, estar ganhando corpo diante dos nossos olhos. E, não se preocupe: não é preciso ser físico para compreender!

Computação Clássica

Vamos pelo começo, que é sempre um bom lugar para quem quer entender qualquer transformação: a computação clássica. Sem ela, nada do que você está usando agora existiria. Smartphones, laptops, datacenters, servidores de nuvem, até mesmo as centrais que processam pagamentos digitais e armazenam suas fotos.

Imagine um interruptor de luz: ligado ou desligado. Esse é o espírito de um bit na computação clássica, um “0” ou um “1”, nada de meio-termo. Tudo que o seu computador faz, do vídeo engraçado do gato ao cálculo de uma planilha, pode ser decomposto em milhares ou milhões desses 0s e 1s. Esses bits passam por portas lógicas (componentes eletrônicos que tomam decisões simples baseadas nos valores de entrada) e, assim, toda operação é possível.

É como se você tivesse um robô para resolver labirintos, mas ele percorresse cada caminho, um por vez, até encontrar a saída. Por mais rápido que ele seja, o método segue linear: tentativa e erro, uma direção de cada vez. Ah, e se você já se pegou se perguntando se existe magia nos computadores tradicionais, está aí a “mágica”: pura velocidade de repetição.

Os exemplos da computação clássica estão em todo lugar, praticamente tudo: navegar na internet, assistir a filmes, editar vídeos, rodar games, jogar xadrez com a máquina, organizar bancos de dados, criar projetos de engenharia, automatizar planilhas, e por aí vai. E com certeza até o seu leitor de e-books entra nessa conta.

Computação Quântica

Aí a conversa muda de figura. Computadores quânticos não trabalham com bits, mas sim com qubits. Agora, a brincadeira do interruptor não é só “aceso” ou “apagado”. O qubit pode ser 0, 1 ou... ambos ao mesmo tempo. Essa capacidade se chama superposição. Em outras palavras, o qubit é uma entidade que desafia a lógica clássica: até você o medir, ele está nos dois estados simultaneamente.

Outro conceito, e talvez o mais instigante, é o emaranhamento quântico. Quando dois qubits ficam emaranhados, o estado de um interfere imediatamente no estado do outro, mesmo separados por grandes distâncias. Imagine duas moedas ligadas: se uma cair cara, a outra inevitavelmente cai coroa, mesmo que uma esteja em Tóquio e a outra no Rio. Einstein achava isso esquisito e batizou de “ação fantasmagórica à distância”.

Se voltarmos ao labirinto: o computador quântico não vai testando um caminho após o outro. Ele explora todos os caminhos de uma só vez, graças à superposição. E, usando o emaranhamento, pode conectar pontos do labirinto, “puxando” informações de partes diferentes ao mesmo tempo, acelerando absurdamente certas buscas.

Aí você pensa: onde usar isso tudo? Modelagem molecular (essencial em busca de medicamentos), otimização de rotas logísticas, quebra de códigos criptográficos, simulação de materiais para energia renovável, previsão de mercados financeiros, machine learning. A lista é promissora, e até um pouco assustadora para alguns setores.

O que muda de verdade?

Se olharmos para o quadro geral, computadores clássicos seguem um caminho lógico linear: cada operação é processada etapa por etapa, sequência por sequência. O computador quântico, em contrapartida, pode analisar muitos caminhos ao mesmo tempo. Você já folheou um livro página por página? O clássico lê uma página de cada vez, o quântico tenta ler todas juntas.

Isso não significa que computadores quânticos sejam apenas “versões mais rápidas” dos clássicos. Eles são instrumentos completamente diferentes, projetados para desafios completamente novos. Ninguém vai precisar de um computador quântico para responder e-mails ou organizar a agenda, mas problemas “intransponíveis” para o método tradicional, como simular moléculas complexas, podem se tornar viáveis.

O Impacto da Computação Quântica

Empresas como IBM, Google e D-Wave não estão apenas “sonhando alto”. Elas já testam algoritmos quânticos para otimizar modelos de aprendizado de máquina, resolver problemas de tráfego urbano, criar simulações para novos materiais e acelerar descobertas em química. Bancos e gestoras financeiras experimentam modelagens de risco com protótipos quânticos. E, sim, a pesquisa em criptografia já se movimenta para enfrentar um mundo “pós-quântico”.

O engraçado é que seu celular, tablet ou notebook ainda não tem um chip quântico, mas, indiretamente, pode estar se beneficiando de avanços produzidos por essa tecnologia em setores invisíveis do cotidiano, da logística ao design de medicamentos. É curioso pensar que, num futuro próximo, resultados dessas pesquisas podem, sem alarde, estar embutidos em processos e produtos que usamos sem perceber.

Por que tanta euforia?

Não é exagero dizer que a computação quântica pode abrir portas para avanços que pareciam inatingíveis. Computadores clássicos vão continuar reinando absolutos em quase todas as tarefas, mas certas perguntas, aquelas com milhões ou bilhões de variáveis interligadas, só podem ser endereçadas com qubits.

Mas calma, não se trata de substituir o clássico pelo quântico. Eles vão trabalhar juntos. O futuro é híbrido: novas descobertas de materiais, soluções matemáticas, simulações de processos complexos, tudo isso vai ganhar um “atalho” com a computação quântica. É como comparar a luz de velas com a eletricidade: o objetivo é iluminar, mas o impacto muda completamente.

Repare que, no fundo, a computação quântica não significa apenas “ser mais rápido”. Ela viabiliza capacidades inéditas, abrindo espaço para que ideias e soluções emergentes tenham onde florescer.

Reflexão sobre Qubits

O que mais me fascina na computação quântica nem sempre é a tecnologia em si, mas a filosofia que vem embutida no pacote. Não se trata só de construir máquinas, mas de repensar o que é informação, como ela circula, como a natureza manipula dados e até mesmo o que chamamos de “realidade”.

É um campo onde física, ciência da computação se entrelaçam. O resultado é uma fronteira que mistura ficção científica com engenharia de ponta. Isso mexe com nosso imaginário: se a computação clássica nos trouxe a internet, o que a quântica poderá criar?

Uma vez, lendo artigos sobre algoritmos quânticos, me peguei pensando no seguinte: enquanto programadores clássicos brigam com bugs de lógica, quem lida com qubits está literalmente negociando com as incertezas fundamentais do universo. Acho que isso é, ao mesmo tempo, assustador e sensacional.

Essa sensação de “mexer com o tecido da realidade” é mais comum entre pesquisadores do que parece. Eles tropeçam entre matemática pura e experimentos que desafiam a intuição. Um ou outro até esquece o almoço, mergulhado nesse universo de probabilidades.

O grande motivo

Ficou a dúvida: qual é, de fato, a grande questão? Por que a computação quântica é tratada como um divisor de águas? Porque ela muda, de maneira profunda, o que entendemos por computação. Acrescenta uma camada de complexidade e, ao mesmo tempo, de possibilidades. É uma ferramenta nova, com potencial para transformar medicina, finanças, engenharia e, com sorte, ampliar nosso entendimento do cosmos.

Não espere ver a tecnologia fazendo café ou resolvendo todos os dilemas existenciais do mundo. Mas não se iluda: quando um qubit entra na equação, as regras do jogo mudam. O verdadeiro “bicho de sete cabeças” não é a velocidade, mas o tipo de problemas que, pela primeira vez, teremos condição de atacar.

E, quando ouvir falar em computação quântica, lembre-se: não é só moda passageira. É um vislumbre de um futuro onde explorar o desconhecido será rotina, e quem se preparar agora vai aproveitar cada passo desse novo caminho. Porque, quando a era quântica chegar de verdade, não vai dar tempo de correr atrás.