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.

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.

Leia Mais

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

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

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

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

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

O que é COBOL?

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

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

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

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

Um exemplo básico seria:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CALCULA-SALDO.

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

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

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

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

Uma linguagem criada para resolver a fragmentação

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

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

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

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

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

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

A importância dos mainframes

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

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

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

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

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

COBOL nunca foi uma tecnologia isolada

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

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

JCL e o processamento em lote

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

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

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

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

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

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

VSAM e os arquivos corporativos

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

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

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

CICS e as transações on-line

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

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

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

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

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

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

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

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

Db2 e o SQL embutido

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

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

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

Mensageria, integração e sistemas distribuídos

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

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

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

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

O que realmente significa “tecnologia legada”?

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

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

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

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

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

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

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

Por que não reescrever tudo?

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

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

Também existem particularidades como:

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

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

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

A dificuldade de aprender COBOL no Brasil

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

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

Pouco espaço nas formações tradicionais

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

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

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

Acesso limitado ao ambiente completo

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

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

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

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

O ecossistema é maior do que a linguagem

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

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

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

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

Documentação e comunidades menores

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

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

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

Como começar a estudar COBOL hoje

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

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

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

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

Uma trilha sensata pode seguir esta ordem:

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

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

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

Como o COBOL ainda é usado

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

Entre os usos mais comuns estão:

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

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

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

Modernizar não é apenas migrar

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

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

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

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

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

Inteligência artificial e compreensão de sistemas legados

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

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

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

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

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

O futuro do COBOL

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

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

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

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

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

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

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

Leia Mais

Nokia: da fábrica de papel ao domínio dos telefones celulares

Muito antes de o nome Nokia aparecer na tela de um telefone celular, ele estava associado a papel, madeira, borracha, cabos elétricos e geração de energia. A empresa atravessou diferentes revoluções industriais até se transformar em uma das marcas tecnológicas mais reconhecidas do planeta.

Um dos primeiros emblemas associados à Nokia trazia a figura de um peixe, referência ao rio Nokianvirta e às origens industriais da empresa na Finlândia.

Para quem viveu as décadas de 1990 e 2000, a palavra Nokia quase sempre desperta a mesma lembrança: um telefone compacto, resistente, com bateria removível e um teclado físico que permitia escrever mensagens sem olhar para a tela. Em muitos lugares, a marca se tornou praticamente sinônimo de telefone celular.

Só que essa é apenas uma parte de uma história iniciada no século XIX, antes mesmo de a Finlândia existir como país independente.

A Nokia nasceu antes da própria Finlândia

A origem da Nokia remonta a 12 de maio de 1865, quando o engenheiro de minas finlandês Fredrik Idestam recebeu autorização para instalar uma fábrica de pasta de madeira às margens das corredeiras de Tammerkoski, na cidade de Tampere.

Naquele período, a região fazia parte do Grão-Ducado da Finlândia, território autônomo ligado ao Império Russo. A independência finlandesa só seria declarada em 1917. Isso significa que a empresa que viria a se tornar a Nokia é mais antiga que o próprio Estado finlandês moderno.

A primeira fábrica não ficava propriamente na cidade de Nokia, como algumas versões resumidas da história afirmam. Ela foi construída em Tampere. Em 1868, Idestam instalou uma segunda unidade perto da pequena cidade de Nokia, cerca de 15 quilômetros a oeste, onde o rio Nokianvirta oferecia melhores condições para o aproveitamento da energia hidráulica.

Em 1871, Idestam e o político e empresário Leo Mechelin organizaram formalmente o negócio como uma companhia chamada Nokia Ab — “Ab” era a abreviação sueca de Aktiebolag, equivalente a uma sociedade por ações. A empresa recebeu o nome da localidade onde estava sua segunda fábrica, cuja identidade também estava ligada ao rio Nokianvirta.

Os primeiros emblemas da Nokia não tinham as letras azuis que se tornariam famosas um século depois. Um deles mostrava um peixe, geralmente interpretado como uma referência ao salmão ou a outro peixe encontrado no rio. O desenho carregava o nome da empresa em finlandês e sueco, acompanhando a realidade linguística da região.

Não era ainda uma marca de tecnologia. Era uma empresa de papel e processamento de madeira.

Papel, borracha e cabos não eram inicialmente a mesma empresa

A trajetória industrial da Nokia costuma ser resumida como se a companhia tivesse decidido, sozinha, começar a fabricar papel, depois botas de borracha, cabos, televisores e telefones. A história real foi um pouco mais complicada.

A Nokia Ab começou ligada à produção de celulose e papel. Com o tempo, também passou a atuar na geração de eletricidade. Outras duas empresas finlandesas tiveram participação decisiva na formação do grupo que conheceríamos mais tarde: a Finnish Rubber Works, fundada em 1898, e a Finnish Cable Works, criada em 1912.

A Finnish Rubber Works produzia botas, pneus, mangueiras e vários artigos de borracha. A Finnish Cable Works fabricava cabos para redes de eletricidade, telégrafo e telefone. Eram empresas juridicamente separadas, embora seus negócios e proprietários tenham se aproximado ao longo do século XX.

Depois da Primeira Guerra Mundial, a Nokia Ab enfrentou dificuldades financeiras. A Finnish Rubber Works adquiriu participação na empresa, interessada principalmente em garantir energia para suas operações. Mais tarde, também assumiu o controle da Finnish Cable Works.

As três companhias mantiveram estruturas formais distintas durante décadas. A fusão definitiva ocorreu apenas em 1967, quando Nokia Ab, Finnish Rubber Works e Finnish Cable Works deram origem à moderna Nokia Corporation.

Esse detalhe muda um pouco a narrativa. A Nokia não passou linearmente de uma fábrica de papel para uma indústria de borracha e, depois, para uma fabricante de eletrônicos. O que aconteceu foi a formação gradual de um conglomerado industrial, reunindo negócios diferentes sob uma mesma organização.

Era uma Nokia muito diferente daquela que dominaria o mercado de celulares. O grupo fabricava papel, pneus, botas, cabos, televisores, equipamentos eletrônicos, sistemas de comunicação e até produtos destinados ao setor militar. A diversidade ajudava a empresa a sobreviver às mudanças econômicas, mas também criava uma estrutura pesada e difícil de administrar.

A entrada no mundo das telecomunicações

A aproximação com as telecomunicações aconteceu principalmente por meio da Finnish Cable Works. A fabricação de cabos já colocava a empresa em contato com redes telefônicas, transmissão elétrica e infraestrutura de comunicação.

Durante a década de 1960, o grupo começou a desenvolver equipamentos eletrônicos e sistemas de radiocomunicação. Uma divisão de eletrônica havia sido criada dentro da companhia de cabos, trabalhando com transmissão de dados, radiotelefones e dispositivos destinados a instituições públicas, forças de segurança e serviços de emergência.

Algumas cronologias atribuem ao engenheiro Kurt Wikstedt e à equipe de eletrônica da Nokia a criação de um radiotelefone em 1963 e de um modem de dados por rádio em 1965. Esses aparelhos, porém, não devem ser confundidos com um celular moderno. Eram equipamentos profissionais de comunicação sem fio, normalmente grandes e destinados a veículos ou instalações especializadas.

O desenvolvimento tinha uma lógica industrial. A Finlândia possuía grandes áreas pouco povoadas, longas distâncias e condições climáticas severas. Construir comunicação confiável nesse território era uma necessidade prática, não apenas uma aposta em um futuro mercado de consumo.

Ainda não existia o conceito de carregar no bolso um aparelho conectado permanentemente a uma rede. Os radiotelefones eram caros, pesados e dependiam de infraestrutura limitada. Muitos precisavam ser instalados em automóveis porque o conjunto de transmissão e a bateria ocupava espaço demais para ser transportado confortavelmente.

Mesmo assim, foi nessa fase que a Nokia acumulou experiência em rádio, antenas, modulação, redes e miniaturização. A transformação não aconteceu de repente nos anos 1990. Ela vinha sendo preparada havia décadas.

Os sistemas nórdicos abriram o caminho

Antes do GSM, os países nórdicos desenvolveram o padrão NMT — Nordic Mobile Telephone. A proposta era criar uma rede celular analógica compatível entre Finlândia, Suécia, Noruega e Dinamarca.

Essa compatibilidade era importante. Em outros lugares, cada país ou operadora adotava soluções próprias, dificultando o uso de um aparelho fora de sua região de origem. O NMT mostrou que sistemas móveis poderiam ser planejados de maneira cooperativa e ultrapassar fronteiras nacionais.

Em 1979, Nokia e a fabricante finlandesa de eletrônicos Salora criaram uma parceria para desenvolver equipamentos de radiotelefonia. A operação daria origem à Mobira, nome que apareceria em alguns dos primeiros telefones móveis comercializados pela companhia.

O Mobira Senator, apresentado em 1982, era um telefone para automóveis que pesava aproximadamente dez quilos. Era “móvel” porque podia acompanhar o veículo, não porque alguém pudesse colocá-lo no bolso e sair caminhando.

Cinco anos depois surgiu um aparelho muito mais interessante.

Mobira Cityman: o telefone que parecia pequeno em 1987

Em 1987, a Nokia-Mobira apresentou o Mobira Cityman, produzido em versões compatíveis com diferentes redes analógicas. O Cityman 900, destinado à rede NMT de 900 MHz, tornou-se o mais conhecido.

Ele pesava cerca de 760 gramas. Para os padrões atuais, seria um telefone enorme e desconfortável. Na época, foi apresentado como um aparelho compacto, capaz de ser carregado com uma mão e usado longe de um automóvel.

As dimensões faziam sentido diante do que existia anteriormente. Um equipamento de dez quilos havia sido reduzido a menos de um quilo. A bateria oferecia por volta de 50 minutos de conversação e aproximadamente 14 horas em espera, dependendo das condições da rede e do estado da bateria.

O preço era igualmente pesado. O Cityman 900 custava cerca de 24 mil marcos finlandeses, valor equivalente a vários milhares de euros quando ajustado para períodos mais recentes. Era um símbolo de poder econômico, destinado a executivos, autoridades e pessoas que realmente precisavam estar acessíveis fora do escritório.

O aparelho ganhou projeção internacional em outubro de 1989, quando o líder soviético Mikhail Gorbachev utilizou um Cityman durante uma visita a Helsinque para fazer uma ligação a Moscou. Na Finlândia, o telefone passou a ser chamado informalmente de Gorba, apelido derivado do sobrenome de Gorbachev.

A imagem tinha força. O chefe da União Soviética usando um telefone finlandês portátil sugeria que a comunicação móvel estava deixando de ser uma experiência de laboratório.

Só ainda custava caro demais para quase todo mundo.

O GSM não foi criado por duas empresas finlandesas

Outra simplificação comum diz que o padrão GSM foi desenvolvido pela Tampere Telephone Company e pela Helsinki Telephone Company. Essas empresas tiveram participação relevante na implantação da primeira rede comercial, mas não foram responsáveis, sozinhas, pela criação do padrão.

O GSM nasceu de um esforço europeu de padronização.

Em 1982, a Conferência Europeia das Administrações de Correios e Telecomunicações, conhecida pela sigla CEPT, criou o grupo Groupe Spécial Mobile. A missão era desenvolver uma especificação digital comum para as redes celulares europeias.

Representantes de governos, operadoras, fabricantes e organizações técnicas de vários países participaram desse processo. França, Alemanha Ocidental, Reino Unido, Itália e os países nórdicos tiveram papéis importantes. Em 1987, representantes de 13 países assinaram um memorando comprometendo-se com a implantação do sistema. A responsabilidade técnica acabaria sendo transferida para o recém-criado European Telecommunications Standards Institute, o ETSI, em 1989.

A Tampere Telephone Company e a Helsinki Telephone Company participaram de outro ponto decisivo. Junto de várias operadoras telefônicas locais, ajudaram a formar a Radiolinja, que pretendia construir uma rede celular digital capaz de concorrer com a operadora estatal Telecom Finland.

A Radiolinja adquiriu infraestrutura da Nokia, e a rede foi construída com tecnologia fornecida pela Nokia e pela Siemens. Era uma aposta arriscada. O GSM ainda enfrentava problemas técnicos, as especificações estavam em desenvolvimento e o mercado continuava dominado por redes analógicas.

A escolha acabou definindo o futuro da Nokia.

A primeira ligação oficial em uma rede GSM

Em 1º de julho de 1991, o então primeiro-ministro finlandês Harri Holkeri realizou aquela que ficou registrada como a primeira ligação oficial em uma rede GSM comercial. Ele estava em Helsinque e conversou com Kaarina Suonio, vice-prefeita de Tampere.

A chamada durou pouco mais de três minutos e foi realizada por meio de uma rede da Radiolinja, construída com equipamentos da Nokia e da Siemens. O telefone utilizado era um protótipo da Nokia. A própria companhia relembra o episódio em seu registro dos 30 anos da primeira ligação oficial GSM.

Há uma pequena nuance histórica: engenheiros realizaram chamadas de teste antes da cerimônia pública. A ligação de Holkeri não foi necessariamente a primeira transmissão técnica entre dois aparelhos GSM, mas foi a primeira chamada oficial associada ao lançamento comercial da rede.

Isso não diminui seu significado. Aquele momento mostrou que um sistema digital europeu havia saído dos documentos e laboratórios para funcionar em uma rede real.

O GSM oferecia melhor aproveitamento do espectro, comunicação digital, autenticação do assinante, uso de cartões SIM e capacidade de roaming entre redes compatíveis. Com a evolução das especificações, também permitiria o envio de mensagens SMS e diferentes formas de transmissão de dados.

A Europa, que possuía vários sistemas analógicos incompatíveis, passava a compartilhar uma plataforma. Para uma fabricante como a Nokia, isso representava um mercado muito maior.

O Nokia 1011 e o início do celular digital em massa

Em 10 de novembro de 1992, a Nokia lançou o Nokia 1011. O nome era uma referência à data de lançamento: 10/11 no formato utilizado em boa parte da Europa.

O aparelho é geralmente reconhecido como o primeiro telefone GSM produzido em série. O Science Museum Group registra que o modelo funcionava em 14 países quando chegou ao mercado, algo que demonstrava uma das principais vantagens do novo padrão.

O Nokia 1011 pesava aproximadamente 475 gramas. Era consideravelmente mais leve que o Cityman, mas ainda lembrava um grande bloco preto com antena externa. Sua bateria fornecia cerca de 90 minutos de conversação, dependendo das condições de uso, e a agenda armazenava aproximadamente 99 contatos — algumas fontes arredondam esse número para 90.

Ele não foi o primeiro telefone celular da Nokia nem o primeiro aparelho portátil do mundo. Sua importância estava em ser um telefone GSM fabricado comercialmente em escala, projetado para uma rede digital que poderia atravessar fronteiras.

Naquele mesmo ano, Jorma Ollila assumiu a liderança da Nokia. A empresa estava enfrentando uma crise e ainda carregava negócios muito diferentes. A nova estratégia concentrou recursos em telecomunicações e vendeu várias operações que não faziam parte desse foco.

A Nokia que fabricava papel, botas, cabos, computadores, monitores e televisores começou a desaparecer. Em seu lugar surgiu uma companhia cada vez mais especializada em redes e telefones móveis.

A decisão parecia perigosa. Acabou sendo uma das apostas industriais mais bem-sucedidas da década.

Quando a Nokia passou a caber no bolso

Durante os anos 1990, os telefones deixaram de ser símbolos exclusivos de executivos. Os aparelhos ficaram menores, as redes cresceram e os preços começaram a cair.

A Nokia percebeu cedo que um telefone celular não deveria ser tratado apenas como equipamento de engenharia. Ele também era um objeto pessoal. Precisava ser agradável de segurar, simples de entender e reconhecível.

Os menus eram relativamente diretos. Os aparelhos compartilhavam padrões de interface. As baterias podiam ser trocadas. Capas coloridas permitiam alguma personalização. Toques musicais, jogos e mensagens de texto transformaram o telefone em algo que ia além de fazer ligações.

A empresa também introduziu elementos que se tornariam parte da cultura popular. O toque da Nokia, derivado de um trecho da composição Gran Vals, do músico espanhol Francisco Tárrega, podia ser ouvido em ônibus, escritórios, escolas e ruas de praticamente qualquer país.

O jogo Snake encontrou o ambiente perfeito. Era simples, funcionava em uma tela monocromática e podia ser jogado com poucas teclas. Não precisava de gráficos sofisticados porque o próprio limite técnico fazia parte de seu charme.

Em 1998, a Nokia superou a Motorola e tornou-se a maior fabricante de telefones celulares do mundo. Poucos anos antes, ainda era um conglomerado finlandês tentando decidir quais divisões conseguiria manter.

Nokia 3310: o telefone que virou mito

O Nokia 3310, lançado em 2000, tornou-se o modelo mais associado à fase de ouro da empresa. Ele não foi o celular mais vendido da história, mas provavelmente é o mais lembrado da Nokia.

O aparelho reunia funções que pareciam bastante completas naquele momento: chamadas, mensagens SMS, despertador, calculadora, cronômetro, lembretes e jogos como Snake II, Space Impact, Bantumi e Pairs II.

Sua bateria podia alcançar até cerca de 260 horas em espera, dependendo da versão da bateria e das condições da rede. Esse número não significava 260 horas de uso contínuo. Em conversação, a autonomia era muito menor. Mesmo assim, poder passar vários dias sem procurar um carregador era normal.

O telefone também ganhou fama por sua resistência. Parte dessa reputação veio do corpo compacto, das capas plásticas substituíveis e da ausência de uma grande tela de vidro exposta. Quando o aparelho caía, era comum a tampa e a bateria se soltarem. Bastava montar as peças novamente e ligar.

Com o passar dos anos, essa durabilidade foi transformada em meme. O 3310 passou a ser tratado como um objeto indestrutível, capaz de sobreviver a quedas absurdas ou quebrar o chão antes de sofrer qualquer dano.

A realidade era menos exagerada, claro. Mas a fama não surgiu do nada.

Foram comercializadas aproximadamente 126 milhões de unidades do Nokia 3310. Um número enorme, embora inferior ao de outros aparelhos mais baratos produzidos posteriormente.

O telefone mais vendido não foi o 3310

O líder absoluto de vendas da Nokia foi o Nokia 1100, lançado em 2003 — e não em 2002, como aparece em algumas cronologias.

Ele não impressionava pelas especificações. Tinha tela monocromática, teclado simples, lanterna integrada, bateria removível e recursos básicos de chamadas e mensagens. Era barato, resistente e fácil de usar.

O aparelho foi pensado especialmente para mercados onde eletricidade, assistência técnica e renda disponível podiam ser limitadas. Seu teclado ajudava a evitar a entrada de poeira, a carcaça oferecia boa aderência e a lanterna tinha utilidade real em regiões com fornecimento instável de energia.

A estratégia funcionou. O Nokia 1100 ultrapassou 250 milhões de unidades vendidas, tornando-se não apenas o celular mais vendido, mas um dos produtos eletrônicos de consumo mais vendidos da história.

Existe algo curioso nisso. Enquanto a indústria tecnológica costuma celebrar o aparelho mais avançado, o maior sucesso comercial da Nokia foi um telefone propositalmente básico.

Ele fazia pouco. Fazia esse pouco de forma confiável.

A Nokia dominava o mercado, mas os números precisam ser separados

Em 2007, a Nokia estava no auge. A empresa vendia centenas de milhões de aparelhos por ano e tinha uma estrutura global de fabricação, distribuição e pesquisa.

Algumas narrativas afirmam que sua participação no mercado de celulares era de 51%. Esse percentual se refere melhor ao segmento de smartphones em determinados levantamentos ou períodos, não ao mercado total de telefones.

No terceiro trimestre de 2007, por exemplo, estimativas da Gartner colocavam a Nokia com aproximadamente 38% do mercado mundial de celulares. No mercado de smartphones, sua participação anual ficou próxima de 49%, chegando a cerca de 50,9% no quarto trimestre.

A diferença é importante. Nem todo telefone era um smartphone.

A Nokia já produzia smartphones havia anos, principalmente com o sistema operacional Symbian. A empresa não estava simplesmente presa a telefones básicos com botões enquanto todos os concorrentes criavam aparelhos inteligentes. Modelos das linhas Communicator, Nseries e Eseries ofereciam internet, e-mail, câmeras, aplicativos e recursos de produtividade.

O problema estava mudando de lugar. Já não bastava fabricar um bom aparelho.

O iPhone alterou a definição de smartphone

Quando a Apple apresentou o primeiro iPhone em 2007, não inventou o smartphone, a tela sensível ao toque ou a internet móvel. Esses recursos já existiam.

O que a Apple fez foi reorganizar a experiência.

A tela capacitiva multitoque tornou a interação mais direta. O navegador oferecia uma experiência próxima à de um computador. O sistema, a interface e o hardware eram projetados como partes do mesmo produto. Em 2008, a App Store transformou aplicativos em um mercado centralizado, fácil de acessar e rentável para desenvolvedores.

A Nokia possuía tecnologia, patentes, engenheiros experientes e uma das marcas mais fortes do mundo. Só que sua estrutura de software havia se tornado fragmentada. Diferentes versões do Symbian, interfaces variadas, exigências das operadoras e decisões internas dificultavam a criação de uma experiência consistente.

O Symbian havia sido projetado para uma geração de aparelhos limitada por memória, processamento e bateria. Era eficiente, mas sua arquitetura ficou cada vez mais difícil de adaptar ao mundo das grandes telas sensíveis ao toque e dos aplicativos complexos.

Os engenheiros podiam acrescentar funcionalidades. O problema era transformar tudo em uma plataforma simples para usuários e desenvolvedores.

Android, Symbian e uma transição mal resolvida

Em 2008, o Android chegou comercialmente ao mercado. O sistema do Google oferecia aos fabricantes uma plataforma comum que poderia ser adaptada a aparelhos de diferentes preços.

Samsung, HTC, Motorola, LG e várias empresas chinesas passaram a produzir smartphones Android. O número de modelos cresceu rapidamente. Desenvolvedores podiam criar aplicativos para uma plataforma presente em aparelhos de várias marcas, enquanto o Google oferecia serviços, ferramentas e uma loja centralizada.

A Nokia continuou investindo no Symbian, ao mesmo tempo em que desenvolvia outras iniciativas, como Maemo e MeeGo. O Nokia N900 e, mais tarde, o N9 mostraram que a companhia era capaz de criar sistemas mais modernos. Só que esses projetos não receberam tempo, continuidade ou alinhamento interno suficientes para formar um ecossistema competitivo.

Em fevereiro de 2011, sob a direção de Stephen Elop, a Nokia anunciou uma parceria estratégica com a Microsoft. O Windows Phone passaria a ser sua principal plataforma para smartphones.

A decisão tinha uma lógica. Adotar Android colocaria a Nokia ao lado de dezenas de fabricantes usando o mesmo sistema. O Windows Phone oferecia a possibilidade de formar um terceiro ecossistema, diferente do iPhone e do Android, com apoio financeiro e tecnológico da Microsoft.

Era também uma aposta perigosa em uma plataforma pequena.

Os Lumia chegaram tarde a uma disputa acelerada

Os primeiros resultados da parceria apareceram no final de 2011 com o Nokia Lumia 800 e o Lumia 710.

O Lumia 800 tinha desenho derivado do Nokia N9, corpo em policarbonato e uma interface visual bastante diferente dos concorrentes. O Windows Phone utilizava blocos dinâmicos, os Live Tiles, em vez da grade tradicional de ícones.

Os aparelhos receberam elogios pelo acabamento, pela câmera em modelos posteriores e pela fluidez do sistema. A linha Lumia não foi um fracasso instantâneo sem qualquer venda, como certas versões da história sugerem. Ela construiu uma base de usuários e chegou a obter relevância em alguns países.

Só que nunca alcançou o volume necessário.

O Windows Phone sofria com a falta de aplicativos importantes, atualizações incompatíveis entre gerações e pouca adesão de outros fabricantes. Desenvolvedores priorizavam Android e iOS porque era onde estavam os usuários. Consumidores evitavam o Windows Phone porque faltavam aplicativos. O conhecido ciclo de um ecossistema pequeno.

Enquanto a Nokia realizava essa migração, as vendas dos aparelhos Symbian caíam rapidamente. A linha Lumia não crescia com velocidade suficiente para compensar a perda.

Em 2012, a Samsung ultrapassou a Nokia e assumiu a liderança mundial em telefones celulares. Uma posição que a companhia finlandesa mantivera por cerca de 14 anos desapareceu em pouco tempo.

A Microsoft não comprou a Nokia inteira

Em setembro de 2013, Microsoft e Nokia anunciaram uma transação envolvendo a divisão Devices & Services, responsável pelos telefones celulares. O acordo foi concluído em 25 de abril de 2014.

A Microsoft pagou 3,79 bilhões de euros pelos negócios de dispositivos e serviços e outros 1,65 bilhão de euros pelo licenciamento de patentes. O valor anunciado totalizava 5,44 bilhões de euros, equivalente a pouco mais de 7 bilhões de dólares na cotação daquele período.

Não foi uma compra completa da empresa Nokia. As patentes essenciais também não foram simplesmente vendidas em bloco. Segundo o comunicado oficial da Microsoft, a operação envolvia a aquisição de grande parte da divisão de aparelhos, o licenciamento de patentes e o uso de serviços de mapas.

A Nokia Corporation continuou existindo de forma independente, mantendo negócios de infraestrutura de redes, pesquisa tecnológica, licenciamento e outros ativos. A unidade adquirida passou a operar dentro da Microsoft, com parte da estrutura organizada sob o nome Microsoft Mobile Oy.

Durante algum tempo, a Microsoft continuou usando o nome Nokia em telefones básicos. Nos smartphones, a marca Lumia foi gradualmente modificada para Microsoft Lumia.

A compra não produziu o resultado esperado. Em 2015, a Microsoft registrou uma baixa contábil de aproximadamente 7,6 bilhões de dólares relacionada ao negócio de celulares e anunciou milhares de demissões. Na prática, reconhecia que grande parte do valor da aquisição havia sido perdida.

O retorno da marca por meio da HMD Global

Em 2016, a recém-criada empresa finlandesa HMD Global assinou um acordo de licenciamento com a Nokia Corporation para utilizar a marca Nokia em telefones e tablets.

A operação teve várias partes. A HMD adquiriu da Microsoft determinados direitos relacionados aos telefones básicos e firmou um acordo de uso da marca com a Nokia. A FIH Mobile, subsidiária da Foxconn, adquiriu ativos de fabricação, distribuição e cadeia de suprimentos que pertenciam à operação da Microsoft.

Os novos aparelhos Nokia não eram produzidos pela antiga divisão móvel da Nokia Corporation como antes. Eram desenvolvidos e comercializados pela HMD sob licença de marca, com apoio de parceiros industriais.

A HMD lançou telefones básicos e smartphones Android. Também recuperou nomes históricos, entre eles Nokia 3310 e Nokia 8110, usando a nostalgia como parte da estratégia comercial.

Em 2024, a HMD começou a destacar sua própria marca em smartphones, reduzindo a dependência do nome Nokia em parte do catálogo. Isso gerou a impressão de que a parceria havia acabado completamente. Até 2026, porém, o site da empresa ainda apresenta aparelhos HMD e telefones Nokia e identifica a HMD Global como licenciada da marca Nokia para telefones.

A situação atual é bem diferente daquela vivida no começo dos anos 2000. Nokia Corporation e HMD Global são empresas separadas. Uma é proprietária da marca e de tecnologias licenciadas; a outra desenvolve e comercializa determinados aparelhos usando esse nome.

A Nokia ainda tem relação com telefones, só não os fabrica como antes

Dizer que a Nokia atualmente “não tem nada a ver com telefones celulares” é um exagero.

A Nokia Corporation não opera mais a antiga divisão de celulares de consumo que produziu aparelhos como o 3310, o N95 ou o Lumia 920. Também não concorre diretamente com Apple e Samsung fabricando smartphones sob a mesma estrutura do passado.

A companhia continua profundamente ligada às telecomunicações. Ela desenvolve equipamentos e software para redes móveis, infraestrutura de operadoras, sistemas ópticos, redes IP, soluções para empresas, tecnologias relacionadas ao 5G e pesquisa para futuras gerações de comunicação.

Também administra um portfólio relevante de patentes. Fabricantes de celulares utilizam tecnologias desenvolvidas ou licenciadas pela Nokia, mesmo quando o nome da empresa não aparece no aparelho.

A incorporação da Alcatel-Lucent, concluída em 2016, trouxe para o grupo os Bell Labs, um dos centros de pesquisa mais importantes da história das telecomunicações. O transistor, o Unix, a linguagem C e várias tecnologias de comunicação possuem ligações históricas com esse laboratório.

A Nokia deixou de fabricar o objeto pelo qual ficou conhecida, mas permaneceu na infraestrutura invisível que permite a esses objetos se comunicarem.

Uma empresa que sobreviveu a várias versões de si mesma

A história da Nokia costuma ser contada como uma ascensão seguida por uma queda: uma fábrica de papel se transforma na maior fabricante de celulares do mundo, ignora o iPhone, escolhe o Windows Phone e desaparece.

Essa narrativa é atraente porque é simples. A realidade não é.

A Nokia não ignorou os smartphones. Ela já os fabricava antes da Apple entrar nesse mercado. Também pesquisou telas sensíveis ao toque, tablets, sistemas baseados em Linux, lojas de aplicativos e serviços de internet. O problema foi converter todo esse conhecimento em uma estratégia coerente no momento em que o mercado deixou de ser definido pelo aparelho e passou a ser organizado pelo ecossistema de software.

A empresa sabia fabricar telefones excelentes. Não conseguiu controlar a transição na qual o valor principal migrou para sistemas operacionais, aplicativos, serviços em nuvem e comunidades de desenvolvedores.

Seu tamanho, que havia sido uma vantagem na produção e distribuição global, também dificultou mudanças rápidas. Divisões disputavam recursos. Projetos concorrentes avançavam ao mesmo tempo. Decisões técnicas se misturavam com compromissos assumidos com operadoras e mercados diferentes.

O iPhone não destruiu a Nokia sozinho. O Android também não. Eles expuseram problemas que já existiam e mudaram o mercado numa velocidade que a organização não conseguiu acompanhar.

Mesmo assim, a Nokia não desapareceu.

A empresa que começou processando madeira em 1865, participou da produção de eletricidade, atravessou o setor de borracha e cabos, construiu equipamentos de rádio, liderou a telefonia móvel e perdeu sua divisão de aparelhos ainda existe. Agora trabalha principalmente nos bastidores das redes.

Talvez essa seja a parte mais interessante de sua história. O Nokia 3310 parecia indestrutível, mas a companhia foi ainda mais resistente que o próprio telefone. Não permaneceu igual. Sobreviveu justamente porque, em diferentes momentos, conseguiu deixar para trás aquilo que um dia definiu sua identidade.

Leia Mais

Meta e Google desafiando o ecossistema da 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

Leia Mais