Concorrência entre AMD e Google Cloud se intensifica à medida que Helios desafia a Nvidia

A AMD lançou sua primeira plataforma completa de IA em escala de rack, transformando a discussão sobre AMD e Google em uma disputa direta sobre quem controla a arquitetura dos data centers.

O sistema Helios combina 72 aceleradores Instinct MI455X, 18 processadores EPYC, rede Pensando e o ambiente de software ROCm da AMD. A AMD apresentou o projeto de produção em seu evento Advancing AI, em 23 de julho de 2026.

Esse lançamento muda a posição da AMD no mercado. A empresa deixou de oferecer aos hyperscalers uma coleção de componentes que os clientes precisam integrar à rede e ao software de outra companhia. O Helios entrega à AMD um rack coordenado que concorre com os sistemas NVL72 da Nvidia e com a infraestrutura verticalmente integrada por trás das unidades de processamento tensorial do Google.

As especificações de destaque são substanciais. Um rack Helios comporta aproximadamente 31 terabytes de HBM4, ou memória de alta largura de banda de quarta geração, distribuídos entre seus aceleradores. A AMD informa 2,9 exaflops de computação FP4 de pico, um formato de baixa precisão comumente usado para inferência de IA.

No entanto, esses números não resolvem a disputa. A Nvidia ainda conta com o ambiente mais robusto para desenvolvedores, uma base instalada maior e um modelo consolidado de implantação em escala de rack. O Google controla seus próprios modelos, plataforma de nuvem, rede e roteiro de TPUs personalizadas.

A virada da AMD é mais específica. A empresa passou de vender um acelerador alternativo a propor um projeto alternativo de data center. Agora, os clientes precisam decidir se um rack aberto e multiforncedor pode superar as vantagens operacionais de uma plataforma rigidamente controlada.

A concorrência entre AMD e Google Cloud vai além dos chips individuais

O lançamento do Helios torna o rack completo, e não o acelerador individual, a principal unidade de competição da AMD.

Clusters modernos de IA não conseguem obter desempenho útil apenas instalando GPUs rápidas em servidores convencionais. Centenas ou milhares de aceleradores precisam trocar parâmetros de modelos, ativações e dados em cache com baixa latência consistente.

A arquitetura em escala de rack trata um gabinete inteiro como um único sistema de computação coordenado. Bandejas de computação, processadores host, memória, refrigeração, distribuição de energia, switches e software são projetados em conjunto.

A plataforma Helios da AMD usa 72 GPUs Instinct MI455X conectadas por UALink sobre Ethernet. O UALink é uma interconexão apoiada pela indústria, projetada para oferecer comunicação de alta velocidade entre aceleradores de vários fornecedores.

Cada MI455X inclui 432 GB de HBM4 e até 23,3 terabytes por segundo de largura de banda de memória, segundo as especificações publicadas pela AMD. A HBM posiciona memória empilhada próxima ao processador, reduzindo a latência associada à movimentação dos dados do modelo.

O rack também inclui 18 CPUs EPYC “Venice” e interfaces de rede Pensando Vulcano. Sua rede externa para expansão usa Ultra Ethernet, uma especificação aberta projetada para grandes clusters de IA e computação de alto desempenho.

Esses detalhes importam porque a movimentação de dados determina cada vez mais o desempenho utilizável em IA. Um processador pode anunciar um enorme throughput de pico e, ainda assim, passar parte do tempo de operação esperando pela memória ou por outro acelerador.

Pools de memória maiores também permitem que os sistemas mantenham mais pesos de modelo e dados de cache chave-valor próximos aos processadores. Um cache chave-valor armazena informações geradas durante a inferência para que o modelo não recalcule toda a conversa a cada token.

Essa capacidade se torna importante para prompts longos, agentes de programação, sistemas de pesquisa e modelos que geram várias alternativas antes de retornar uma resposta. Essas cargas de trabalho podem consumir memória rapidamente, mesmo quando o modelo subjacente permanece inalterado.

Portanto, a comparação entre AMD e Google abrange mais do que o desempenho de GPUs. Os sistemas TPU do Google usam aceleradores personalizados, interconexões proprietárias e software otimizado para a nuvem do Google e seu ambiente de desenvolvimento de modelos.

O Google consegue ajustar essas camadas em conjunto porque as controla. A AMD, por sua vez, argumenta que os clientes podem obter coordenação de sistema comparável mantendo opções entre fabricantes de servidores, fornecedores de rede, plataformas de nuvem e frameworks de software.

O Google Cloud não anunciou o Helios como uma plataforma central de aceleradores. Seu roteiro de infraestrutura para 2026 enfatiza TPUs do Google, sistemas Nvidia e máquinas virtuais de uso geral com CPUs AMD e Intel.

Essa distinção deve permanecer clara. O Google participa do ecossistema mais amplo de infraestrutura da AMD, mas o Helios não é atualmente a base da estratégia de aceleradores de IA do Google Cloud.

A pressão relevante vem das expectativas dos clientes. Se a AMD comprovar que sistemas abertos em escala de rack podem operar com eficiência, os compradores poderão exigir flexibilidade semelhante de todos os provedores de nuvem.

Para desenvolvedores que buscam explicações sobre AMD Helios, a resposta mais simples é que a AMD reuniu o gabinete, a rede, os processadores e o software em um único projeto pronto para implantação. A questão mais difícil é saber se os operadores conseguirão atingir o desempenho prometido fora de demonstrações cuidadosamente selecionadas.

Helios transforma a AMD em uma concorrente de sistemas

A mudança mais importante da AMD é organizacional: a empresa agora precisa entregar um sistema operacional completo para infraestrutura de IA, não apenas silício competitivo.

A AMD construiu grande parte de sua posição em data centers com os processadores para servidores EPYC. Mais tarde, seus aceleradores Instinct ofereceram aos provedores de nuvem uma segunda fonte de computação para IA, especialmente quando a demanda superava a capacidade disponível da Nvidia.

O Helios leva a empresa mais acima na pilha tecnológica. A AMD precisa coordenar projeto de processadores, empacotamento de aceleradores, rede, firmware, compiladores, bibliotecas, gerenciamento de clusters, refrigeração e capacidade de manutenção.

Esse modelo se assemelha à abordagem usada pela Nvidia com DGX e seus sistemas de rack NVL. A Nvidia se transformou de fornecedora de chips em empresa de plataformas para data centers ao combinar GPUs com NVLink, rede, bibliotecas CUDA, sistemas de referência e orientações de implantação.

A AMD busca o mesmo resultado por meio de uma governança diferente. Ela promove o ROCm como um ambiente de software aberto e baseia o Helios em especificações de hardware do Open Compute Project.

O Open Compute Project publica projetos de data centers que fabricantes e operadores podem adaptar. Essa abordagem pode reduzir a dependência de um único fornecedor, embora “aberto” não signifique automaticamente intercambiável ou fácil de operar.

A AMD também utiliza padrões de rede apoiados por outras empresas de chips e equipamentos. Isso dá aos fabricantes de equipamentos originais espaço para incorporar switches comerciais e suas próprias ferramentas de gerenciamento.

O benefício prático é maior poder de negociação. Um provedor de nuvem pode adotar aceleradores AMD sem ceder à AMD todas as camadas ao redor.

O ônus correspondente é a integração. Quando um sistema proprietário falha, o proprietário da plataforma tem uma responsabilidade mais clara por diagnosticar o problema. Um sistema aberto pode distribuir essa responsabilidade entre o fornecedor do acelerador, o fornecedor de switches, o fabricante do servidor, a equipe de software e o operador de nuvem.

A AMD está respondendo a essa preocupação com compromissos de clientes que vão além de testes. A Meta concordou em implantar até 6 gigawatts de capacidade AMD Instinct em várias gerações de hardware.

Os envios que sustentam o primeiro gigawatt da Meta estavam programados para começar durante o segundo semestre de 2026. A implantação inicial usa um acelerador personalizado da família MI450, CPUs Venice, arquitetura Helios e software ROCm, segundo a implantação da Meta.

Separadamente, a Anthropic se comprometeu a implantar até 2 gigawatts de GPUs da série MI450 em sistemas Helios. A implantação de seu primeiro gigawatt está programada para começar no primeiro semestre de 2027.

Esse acordo com a Anthropic é especialmente significativo porque a Anthropic treina e atende modelos de fronteira. Suas cargas de trabalho devem expor fragilidades no gerenciamento de memória, na comunicação coletiva, no comportamento dos compiladores e na confiabilidade de grandes clusters.

A Microsoft também afirmou que implantará o Helios por meio do Azure. A Cerebras planeja instalar sistemas Helios em seus data centers e combiná-los com sua tecnologia de inferência em escala de wafer.

Esses compromissos respondem a uma questão em torno de coberturas que explicam o AMD Helios. O Helios não é apenas um diagrama de referência à espera de um cliente. Vários grandes operadores já vincularam planos de implantação a ele.

Eles não respondem se essas instalações cumprirão os cronogramas previstos, as taxas de utilização ou a economia pretendida. Compromissos em gigawatts descrevem uma escala potencial de infraestrutura, não capacidade computacional entregue.

Construir um grande cluster de IA exige fornecimento elétrico, equipamento de refrigeração, construção, rede, suprimento de memória e software funcional. Um componente atrasado pode impedir que um acelerador nominalmente disponível produza tokens faturáveis.

Consequentemente, a AMD entrou em um negócio mais exigente. Seu sucesso dependerá da entrega de clusters completos e do desempenho das cargas de trabalho, não do envio de chips individuais.

AMD vs Nvidia AI agora é uma disputa em nível de rack

A Nvidia continua sendo a principal adversária porque o Helios ataca diretamente a maior vantagem da empresa: o controle sobre toda a pilha de computação acelerada.

A vantagem da Nvidia começa com CUDA, sua plataforma de programação para computação com GPUs. O CUDA inclui compiladores, bibliotecas, ferramentas de depuração e kernels otimizados que desenvolvedores usam há anos.

A base de software resultante cria custos de migração. Um modelo escrito em um framework comum pode tecnicamente rodar em aceleradores diferentes, mas suas operações personalizadas e ferramentas de implantação ainda podem depender do software da Nvidia.

O ROCm oferece suporte aos principais frameworks de IA e melhorou em lançamentos sucessivos. A AMD também publicou ferramentas de migração e bibliotecas otimizadas para treinamento, inferência, comunicação e disponibilização de modelos.

A paridade de software continua sendo específica para cada carga de trabalho. Um benchmark padrão pode funcionar bem, enquanto um modelo interno de produção encontra operações não suportadas, kernels instáveis ou compilação mais lenta.

Por isso, o debate AMD vs Nvidia AI não pode ser resolvido por um único número de desempenho de pico. Os compradores precisam de medições que cubram precisão do modelo, throughput de tokens, latência, consumo de energia, tempo dos operadores e disponibilidade do cluster.

O Helios parece competitivo em várias dimensões físicas. Seus 72 aceleradores MI455X oferecem aproximadamente 31 TB de HBM4, proporcionando ao rack um grande pool de memória local.

A AMD afirma que o MI455X entrega 40,3 petaflops de desempenho FP4 de pico por dispositivo. Multiplicar esse número pelos 72 aceleradores produz os 2,9 exaflops anunciados para o Helios.

A Nvidia publicou um número FP4 maior em nível de rack para sua configuração Vera Rubin NVL72 com 72 GPUs. Uma análise independente das alegações concluiu que a vantagem da AMD por GPU não se traduziu em um total de rack maior segundo as medições publicadas pelos fornecedores.

Essa comparação de racks ilustra um problema recorrente de benchmarking. Os fornecedores podem escolher denominadores em nível de dispositivo ou sistema, diferentes formatos numéricos e premissas favoráveis de carga de trabalho.

As operações teóricas de pico também excluem paradas de comunicação e a sobrecarga de software. Um sistema com menor capacidade nominal de computação pode concluir a execução de um modelo mais rapidamente se seu software e sua rede mantiverem mais processadores ocupados.

A vantagem da Nvidia, portanto, vai além do throughput bruto. Seus sistemas chegam com um padrão de implantação conhecido, operadores experientes e amplo suporte em softwares comerciais de IA.

O contraponto da AMD se concentra em memória, padrões e controle do cliente. O Helios oferece aos compradores um sistema integrado sem tornar cada interface dependente de um único fornecedor proprietário.

Essa é uma diferença crível, mas não é uma vantagem sem custo. Padrões abertos frequentemente exigem que vários fornecedores produzam itens compatíveis em cronogramas sincronizados.

A Nvidia pode alterar um processador, link, switch e biblioteca de software como parte de um único roadmap. A AMD precisa coordenar UALink, Ultra Ethernet, fabricantes de servidores, fornecedores de switches, fornecedores de memória e operadores de nuvem.

A disputa de IA entre AMD e Nvidia será decidida, em parte, pela disciplina de execução. A AMD precisa que seus parceiros transformem especificações em instalações repetíveis, enquanto a Nvidia precisa demonstrar que sua abordagem integrada justifica um controle mais rígido da plataforma.

O Google acrescenta outra rota competitiva. Sua infraestrutura de TPU não tenta criar uma plataforma de GPU comercial que todas as nuvens possam implantar. O Google desenvolve sistemas personalizados principalmente para seus próprios serviços de nuvem e cargas de trabalho internas de IA.

Isso dá ao Google um ciclo de feedback incomumente direto entre pesquisadores de modelos, equipes de compiladores, projetistas de chips e engenheiros de data center. Ele pode otimizar o hardware em torno dos padrões de carga de trabalho que espera atender.

No entanto, os clientes que escolhem TPUs aceitam uma relação mais próxima com o Google Cloud. Mover a mesma carga de trabalho para outro lugar pode exigir diferentes premissas de hardware, ajustes de software e práticas operacionais.

A questão AMD-Google, portanto, não é simplesmente qual processador é mais rápido. Ela pergunta se os compradores preferem uma pilha vertical específica de nuvem ou uma infraestrutura portátil montada em torno de interfaces abertas.

A Nvidia ocupa uma terceira posição. Ela vende uma plataforma altamente integrada em múltiplas nuvens, tornando CUDA portátil entre provedores, ao mesmo tempo que mantém o ambiente de aceleradores estreitamente ligado à Nvidia.

A AMD precisa resolver esse problema de três vias. Deve oferecer integração suficiente para operar como a Nvidia, abertura suficiente para se diferenciar da Nvidia e disponibilidade em nuvem suficiente para competir com o alcance de infraestrutura do Google.

As Especificações Ainda Precisam de Comprovação em Produção

O Helios é o mais forte projeto de data center da AMD até hoje, mas a maioria de suas alegações decisivas ainda são projeções de engenharia, e não resultados sustentados em produção.

As páginas de produtos da AMD descrevem o MI455X usando throughput teórico de pico e estimativas internas de engenharia. Esses números fornecem um limite superior útil, mas os clientes raramente operam modelos grandes nesse limite.

Um sistema em produção enfrenta restrições de energia, congestionamento de rede, componentes com falha, checkpointing, atualizações de software e padrões desiguais de solicitações. Esses fatores determinam quanto da computação adquirida se transforma em trabalho útil.

O Helios também depende de refrigeração líquida direta. A refrigeração líquida remove calor com mais eficiência do que os sistemas convencionais de ar, mas exige instalações compatíveis, unidades de distribuição, monitoramento e procedimentos de manutenção.

Muitos grandes operadores já utilizam refrigeração líquida para clusters de IA de alta densidade. Empresas com salas de servidores convencionais podem enfrentar mudanças de infraestrutura mais extensas.

A facilidade de manutenção apresenta outro teste. O projeto Helios distribui 72 aceleradores em bandejas repetíveis de quatro GPUs, o que deve permitir que técnicos substituam componentes sem reconstruir um rack inteiro.

O tempo real de reparo depende do isolamento de falhas e da disponibilidade de peças sobressalentes. Os operadores precisam de telemetria capaz de identificar se uma desaceleração se origina em uma GPU, cabo, switch, camada de firmware ou biblioteca de comunicação coletiva.

O fornecimento de memória acrescenta incerteza. Cada rack Helios contém 31 TB de HBM4, e os compromissos de hyperscalers implicam demanda por grandes quantidades de memória avançada e encapsulamento.

A AMD depende de parceiros externos de fabricação e memória. Um projeto de acelerador robusto não pode cumprir metas de implantação se os rendimentos de encapsulamento ou as entregas de HBM limitarem os sistemas concluídos.

Os principais acordos com clientes da empresa também incluem cronogramas prospectivos. A primeira implantação da Meta começa no segundo semestre de 2026, enquanto a da Anthropic começa durante o primeiro semestre de 2027.

Esses cronogramas deixam hoje poucas evidências públicas de produção. Os clientes devem distinguir entre capacidade anunciada, capacidade instalada, sistemas aceitos e aceleradores atendendo tráfego real.

A divulgação de benchmarks será igualmente importante. A AMD participou do MLPerf, uma suíte de benchmarks do setor que mede treinamento e inferência sob condições definidas.

Os futuros resultados do MI455X devem incluir configurações de servidores, versões de software, configurações de energia, metas de precisão e classes de disponibilidade. Submissões comparáveis importam mais do que gráficos isolados da empresa.

Mesmo benchmarks padronizados não conseguem reproduzir todas as cargas de trabalho de produção. Inferência de contexto longo, modelos esparsos de mixture-of-experts, aprendizado por reforço e sistemas agênticos criam diferentes padrões de comunicação e memória.

Um modelo mixture-of-experts ativa grupos selecionados de parâmetros para cada entrada, em vez de usar todos os parâmetros. Isso pode reduzir os requisitos de computação ao mesmo tempo que aumenta a complexidade de roteamento e comunicação.

A AMD projetou anteriormente grandes ganhos para sistemas da família MI400 nesses modelos. Os compradores devem tratar esses ganhos como dependentes da carga de trabalho até que testes independentes os reproduzam.

ROCm representa a outra incerteza central. A maturidade do software não pode ser resumida pelo número de frameworks compatíveis, porque as empresas frequentemente mantêm kernels personalizados e sistemas internos de implantação.

Os custos de migração incluem alterações de código, validação, atualizações de monitoramento, treinamento de equipe e capacidade paralela durante a transição. Um menor custo de hardware pode desaparecer se as equipes de engenharia passarem meses reparando pipelines de produção.

Os desenvolvedores que avaliam materiais explicativos sobre o AMD Helios devem, portanto, inspecionar a lista de materiais de software, não apenas a especificação do acelerador. Eles precisam de versões de frameworks compatíveis, cobertura de kernels, bibliotecas de comunicação, ferramentas de observabilidade e procedimentos de escalonamento.

Google e Nvidia se beneficiam de ciclos operacionais maduros. O Google ajusta sua infraestrutura em relação a serviços internos, enquanto a Nvidia recebe feedback de uma grande base de desenvolvedores e parceiros de nuvem.

A AMD agora tem os clientes necessários para construir um ciclo semelhante. Meta, Microsoft, Anthropic, Oracle e Cerebras representam cargas de trabalho distintas que podem revelar diferentes fragilidades da plataforma.

O sinal mais forte não será outro anúncio de parceria. Será a evidência de que esses clientes expandiram as implantações depois de operar os primeiros sistemas.

Essa distinção mantém a análise fundamentada. O Helios demonstra que a AMD consegue projetar um concorrente sério em escala de rack. Ainda não demonstra que a empresa consegue entregar e dar suporte a esses racks com eficiência de produção comparável.

O Que a Disputa AMD-Google Revelará a Seguir

Três sinais de curto prazo determinarão se o Helios se tornará uma plataforma duradoura ou continuará sendo uma fonte alternativa útil para clientes selecionados.

O primeiro sinal é a rampa inicial de produção durante o segundo semestre de 2026. A AMD e seus parceiros precisam enviar sistemas completos, instalá-los em instalações preparadas e levar as cargas de trabalho dos clientes além dos testes.

O volume importa, mas a aceitação importa mais. Um rack em um ambiente de preparação não valida desempenho, confiabilidade ou prontidão operacional.

Evidências de que Meta e Microsoft executam cargas de trabalho sustentadas em produção fortaleceriam o argumento da AMD. Atrasos entre a entrega do hardware e a implantação útil exporiam restrições de integração ou das instalações.

Investidores e compradores devem observar cuidadosamente a linguagem usada pela AMD em seus relatórios. Referências a remessas de produtos, aceitação pelo cliente, reconhecimento de receita, capacidade instalada e cargas de trabalho ativas descrevem estágios diferentes.

O segundo sinal é o desempenho do MI455X comparável de forma independente. Os resultados públicos devem testar tanto treinamento quanto inferência em diversos tipos de modelos.

Comparações úteis informarão throughput, latência, consumo de energia e comportamento de memória no nível do sistema. Alegações por dispositivo não devem substituir uma medição de rack com 72 aceleradores.

Esse sinal pode fortalecer ou enfraquecer rapidamente o argumento de IA da AMD contra a Nvidia. Resultados competitivos em cargas de trabalho mostrariam que o Helios traduz seu projeto de memória e interconexão em desempenho utilizável.

Uma grande diferença entre alegações de pico e a produção medida reforçaria a vantagem de software e integração da Nvidia. Resultados inconsistentes entre frameworks apontariam para lacunas de otimização no ROCm.

O terceiro sinal é a recompra. Meta, Anthropic, Microsoft e outros primeiros clientes já forneceram compromissos substanciais de demanda.

Uma segunda fase de implantação indicaria que a plataforma atingiu metas operacionais e econômicas. Uma redução silenciosa na capacidade planejada teria o significado oposto.

A resposta do Google Cloud também merece atenção. O Google não precisa adotar o Helios para afetar as perspectivas da AMD.

Ele pode expandir a disponibilidade de TPU, melhorar a compatibilidade com frameworks comuns de IA ou oferecer acesso mais flexível a Nvidia e outros processadores. Essas medidas tornariam o Google Cloud uma resposta mais forte para clientes que buscam alternativas sem gerenciar infraestrutura de racks.

Por outro lado, um suporte mais amplo do Google para aceleradores AMD aumentaria a portabilidade entre nuvens e reduziria o risco de assumir um compromisso com ROCm. Nenhuma implantação do Helios deve ser presumida até que as empresas a anunciem.

A disputa AMD-Google, portanto, expõe uma mudança maior na compra de infraestrutura. Os clientes não estão mais comparando especificações isoladas de aceleradores. Eles estão escolhendo entre modelos de governança para computação.

O Google oferece uma rota de nuvem verticalmente integrada e acelerador personalizado. A Nvidia fornece uma plataforma comercial integrada disponível por meio de inúmeras nuvens e fornecedores de sistemas. A AMD propõe uma arquitetura de rack aberta que os parceiros podem adaptar.

Cada modelo troca uma forma de controle por outra. A integração vertical pode simplificar a otimização enquanto aumenta a dependência da plataforma. Interfaces abertas podem preservar a escolha enquanto aumentam os custos de coordenação.

Para desenvolvedores, a implicação imediata é prática. A diversidade de hardware tornará mais valiosas a portabilidade, a criação de perfis e os benchmarks específicos por carga de trabalho.

As equipes devem separar a lógica do modelo dos kernels específicos de fornecedores sempre que possível. Também devem preservar conjuntos de avaliação reproduzíveis para que as migrações possam ser medidas em relação à precisão e aos requisitos de nível de serviço.

Compradores de infraestrutura devem solicitar evidências de produção no nível do cluster completo. Benchmarks de processadores não conseguem revelar sobreassinatura de rede, limites de refrigeração, comportamento de recuperação ou esforço operacional.

Eles também devem identificar qual parte é responsável por um problema no nível do sistema. Uma arquitetura aberta só ajuda quando os contratos de suporte e as responsabilidades de diagnóstico permanecem claros.

Os trabalhadores do conhecimento sentirão essa competição indiretamente. Mais opções de infraestrutura podem ampliar a disponibilidade de modelos e reduzir a dependência de um único fornecedor de capacidade.

No entanto, o resultado não será automaticamente menor latência ou acesso mais amplo. Os provedores precisam transformar a capacidade de hardware em serviços confiáveis, e as aplicações precisam usar essa capacidade de forma eficiente.

Acompanhar o fluxo crescente de especificações, qualificações de benchmarks e anúncios de implantação pode se tornar difícil. Uma base de conhecimento técnica pesquisável pode ajudar equipes de engenharia a preservar as evidências por trás das decisões de infraestrutura.

Helios já mudou o cenário competitivo. A AMD agora pode apresentar uma solução de rack coesa diante dos sistemas de rack da Nvidia e da infraestrutura de IA verticalmente integrada do Google.

A próxima fase é menos teatral. Os clientes precisam instalar os equipamentos, migrar softwares, executar modelos, corrigir falhas e decidir se farão novos pedidos.

Esse é o teste que os leitores devem acompanhar. Observe a capacidade de produção aceita, benchmarks de sistema comparáveis e implantações repetidas. Juntos, esses sinais mostrarão se a AMD criou mais uma opção de acelerador ou uma plataforma de data center alternativa duradoura.

À medida que a competição entre AMD e Google evolui, faça uma pergunta simples sempre que surgir uma nova alegação: ela descreve uma especificação, uma remessa ou uma carga de trabalho em produção? A distinção revelará quem realmente está ganhando terreno.