A aposta da AMD nos padrões do Google enfrenta a Nvidia no teste de rede de IA da Vulcano
A AMD apresentou sua NIC de IA Pensando Vulcano de 800 Gbps, apesar da liderança da Nvidia em redes fortemente integradas para grandes clusters de GPUs. A conexão amd google é relevante porque ambas as empresas apoiam padrões abertos de interconexão destinados a oferecer mais opções de hardware aos compradores de infraestrutura. No entanto, o Google não anunciou planos de implantação da Vulcano.
A Vulcano enfrenta um problema caro dentro dos centros de dados de IA. Os aceleradores podem ficar ociosos quando congestionamento de rede, perda de pacotes ou recuperação lenta atrasam a comunicação entre servidores. A AMD afirma que três placas Vulcano podem fornecer 2,4 terabits por segundo de largura de banda scale-out para cada GPU.
Esse número dá à AMD uma manchete clara, mas não uma vitória automática. A Nvidia já vende uma combinação consolidada de GPUs, Spectrum-X Ethernet, InfiniBand, NVLink, switches e software de rede. A Vulcano precisa demonstrar que uma abordagem Ethernet aberta e programável pode oferecer consistência operacional comparável sem exigir a pilha completa de um único fornecedor.
O que mudou com a AMD Pensando Vulcano 800
A Vulcano transforma a rede em uma parte central da plataforma de IA em escala de rack da AMD, em vez de um acessório adicionado depois que as GPUs são escolhidas.
A AMD detalhou publicamente a NIC de IA Pensando Vulcano 800 em 23 de julho de 2026. O adaptador foi projetado para redes scale-out, que conectam aceleradores entre servidores e racks depois que seus links locais scale-up atingem limites práticos.
Cada placa fornece uma conexão de rede de 800 Gbps. A AMD oferece suporte a configurações com até três NICs atribuídas a uma GPU, criando a largura de banda agregada anunciada de 2,4 Tbps.
Essa configuração difere de tratar um adaptador de rede como ponto de extremidade compartilhado por vários aceleradores. Vários links independentes podem aumentar a largura de banda disponível e oferecer ao tráfego mais de uma rota pelo cluster.
A AMD chama isso de arquitetura multiplano. Um plano de rede é um caminho de dados independente com seus próprios links e recursos de comutação. Dividir o tráfego entre planos pode limitar o impacto de um link com falha ou de uma rota congestionada.
A empresa também afirma que a Vulcano pode reduzir os custos de comutação em até 33 por cento. A AMD atribui essa estimativa à redução de cabos e transceptores em sua configuração de referência, e não a uma redução universal em todas as implantações.
Sua alegação de desempenho merece a mesma ressalva. A AMD afirma que a Vulcano pode melhorar o tempo de conclusão de trabalhos de IA em até 13 por cento. Esse resultado é um benchmark da empresa vinculado a cargas de trabalho e premissas de sistema específicas.
Nenhuma das porcentagens deve ser tratada como desempenho verificado de forma independente para todos os clusters. Os compradores precisam de testes no nível da carga de trabalho que incluam switches, óptica, topologia, versões de software, comportamento diante de falhas e utilização de aceleradores.
O mecanismo subjacente continua sendo plausível. O treinamento distribuído troca repetidamente parâmetros de modelos e resultados intermediários entre aceleradores. Um único caminho atrasado pode reter uma operação coletiva, deixando GPUs caras esperando por seus pares.
A inferência distribuída cria outro padrão de tráfego. Ela pode mover solicitações, estados de modelos e dados em cache entre sistemas conforme a demanda dos usuários muda. Latência previsível pode importar tanto quanto o pico de throughput.
A Vulcano aborda esses padrões com lógica de transporte programável, controles de congestionamento, isolamento de falhas e diagnósticos em serviço. A AMD afirma que os operadores podem atualizar partes desse comportamento por software em vez de substituir o silício de rede.
A NIC utiliza motores P4 programáveis de terceira geração. P4 é uma linguagem e arquitetura para definir como dispositivos de rede processam pacotes. Ela permite que fornecedores alterem comportamentos selecionados de encaminhamento e transporte dentro dos limites suportados pelo hardware.
O design da Vulcano da AMD também inclui opções de conectividade PCIe e UALink. Essa flexibilidade permite que o adaptador se conecte a CPUs ou aceleradores em diferentes projetos de rack.
Portanto, o produto representa mais do que uma porta Ethernet mais rápida. A AMD está tentando coordenar GPUs, CPUs, silício de rede, transportes abertos e software de gerenciamento como um único sistema em escala de rack.
Por que a ligação entre AMD, Google e padrões importa
A relação amd google é uma aliança em torno de padrões, não uma evidência de que o Google Cloud selecionou a Vulcano para produção.
A AMD e o Google estavam entre as empresas originais por trás do grupo promotor Ultra Accelerator Link em 2024. Broadcom, Cisco, Hewlett Packard Enterprise, Intel, Meta e Microsoft também participaram.
O UALink visa à comunicação scale-up entre aceleradores dentro de um pod de computação. A rede scale-up cria um domínio de aceleradores fortemente conectado, enquanto a rede scale-out liga vários servidores ou domínios em uma malha maior.
Essas funções se sobrepõem na fronteira do sistema, mas não são intercambiáveis. A Vulcano lida principalmente com tráfego scale-out e scale-across. Sua interface UALink ajuda a conectá-la diretamente a aceleradores dentro de arquiteturas abertas de rack emergentes.
Portanto, a expressão amd google pode criar uma impressão enganosa. Nenhum anúncio verificado diz que o Google codesenhou a Vulcano, comprou a NIC ou comprometeu capacidade do Google Cloud para ela.
A importância do Google vem de sua posição como operador de hiperescala e participante de padrões. Seu envolvimento dá maior relevância ao trabalho de interconexão aberta porque o Google entende as exigências de tráfego, confiabilidade e gerenciamento de frota de grandes sistemas de IA.
O consórcio UALink lançou sua primeira especificação para conectar até 1.024 aceleradores em um único pod. O apoio de vários operadores de nuvem e fornecedores de chips pode reduzir o risco de que o padrão dependa de um fornecedor.
A Vulcano também oferece suporte a Ultra Ethernet para comunicação entre sistemas. A especificação UEC define uma pilha de comunicação baseada em Ethernet para IA e computação de alto desempenho.
O Ultra Ethernet altera mais do que a velocidade bruta dos links. Ele aborda entrega de pacotes, gerenciamento de congestionamento, multipath, segurança e semântica de comunicação exigidos por cargas de trabalho fortemente sincronizadas.
A AMD também está avançando o Multipath Reliable Connection, ou MRC. Esse transporte pode distribuir dados por vários caminhos, mantendo a entrega confiável e respondendo a congestionamentos ou falhas.
A AMD afirma que codesenvolveu o MRC com a OpenAI para grandes ambientes de treinamento. A empresa implementou o transporte em sua NIC Pollara 400 anterior e afirma que a Vulcano terá suporte a ele quando a plataforma mais recente se tornar amplamente disponível.
Segundo a implementação de MRC da AMD, a Pollara foi validada em laboratórios da empresa com clusters Instinct MI350 e MI355. A AMD afirma que a OpenAI participou dessa validação.
O MRC pode operar com roteamento de segmentos sobre IPv6, o que dá aos operadores controle explícito sobre os caminhos dos pacotes. Ele também pode funcionar com roteamento multipath de custo igual e balanceamento de carga dinâmico.
Essa adaptabilidade sustenta o argumento mais amplo da AMD. Os operadores devem poder adotar novos comportamentos de transporte sem substituir todos os switches, cabos e processos de gerenciamento ao redor do cluster de aceleradores.
A participação do Google em padrões reforça esse argumento, mas não valida as alegações de produto da AMD. As especificações definem comportamento comum, enquanto as implantações em produção revelam a qualidade da implementação.
Um padrão escrito não pode garantir tempos de execução estáveis durante congestionamentos. Ele não prova que ferramentas de diagnóstico identificam falhas rapidamente nem que fornecedores diferentes interpretam todos os recursos opcionais de forma idêntica.
Para os compradores, portanto, a história amd google trata de alinhamento estratégico. Ambas as empresas apoiaram alternativas a malhas fechadas de aceleradores, mas a Vulcano precisa conquistar adoção por meio de desempenho mensurável em clusters.
Essa distinção importa para as equipes de compras. Elas devem avaliar a Vulcano como um produto da AMD em um ambiente emergente de múltiplos fornecedores, e não como uma placa de rede endossada pelo Google.
O mecanismo da Vulcano combina largura de banda e programabilidade
O argumento técnico mais forte da Vulcano não é apenas 800 Gbps, mas sua combinação de vários caminhos, transporte programável e rápida recuperação de falhas.
A rede de IA envolve comunicação sincronizada entre muitos pontos de extremidade. Durante o treinamento, operações coletivas combinam ou redistribuem dados produzidos por cada acelerador participante.
Se um fluxo encontra congestionamento, uma etapa inteira de treinamento pode ficar mais lenta. As GPUs restantes podem concluir seu trabalho local, mas não conseguem avançar até que a comunicação coletiva seja concluída.
A Ethernet convencional frequentemente distribui fluxos entre caminhos por meio de hashing de suas informações de identificação. Um fluxo grande pode permanecer preso em uma rota congestionada mesmo quando outra rota tem capacidade não utilizada.
O MRC foi projetado para usar vários caminhos de forma mais deliberada. Ele pode separar o tráfego em partes, reagir às condições dos caminhos e se recuperar sem obrigar um aplicativo a reiniciar toda a comunicação.
Os motores programáveis de processamento de pacotes da Vulcano colocam parte desse controle perto da borda da rede. Essa localização importa porque a NIC observa o tráfego que entra e sai de cada servidor.
A placa também pode isolar falhas e realizar diagnósticos enquanto um cluster permanece ativo. A AMD afirma que essas funções reduzem o tempo de reparo e evitam algumas janelas de manutenção em todo o cluster.
Essas capacidades se tornam valiosas à medida que o tamanho do cluster cresce. Um sistema com milhares de componentes enfrenta falhas rotineiras de links, óptica, firmware e switches, mesmo quando cada componente tem alta confiabilidade individual.
A rede precisa degradar de forma previsível, em vez de transformar uma falha em um trabalho paralisado. Vários planos fornecem caminhos alternativos, enquanto a lógica de transporte decide como o tráfego deve se mover entre eles.
Três NICs de 800 Gbps por GPU criam capacidade física substancial. No entanto, largura de banda agregada não significa que toda carga de trabalho transferirá continuamente 2,4 Tbps de dados úteis.
A GPU, a interface de host, a biblioteca coletiva, a topologia e os pontos de extremidade remotos devem fornecer tráfego de forma eficiente. A sobrecarga de protocolo e a sincronização da carga de trabalho também reduzem o throughput no nível da aplicação.
A arquitetura da AMD oferece suporte a conexões de host PCIe e UALink. O PCIe continua sendo uma interface familiar para CPUs e periféricos. O UALink visa à conectividade direta com aceleradores, com menor dependência de um único fornecedor de GPUs.
A Vulcano também está vinculada ao AMD Helios, o projeto de rack em escala da empresa que utiliza aceleradores Instinct da série MI400 e processadores EPYC Venice. A AMD posicionou a NIC como o componente padrão de rede scale-out do Helios.
Essa integração dá à AMD mais controle sobre a validação. A empresa pode testar firmware, bibliotecas de comunicação ROCm, comportamento dos aceleradores e telemetria de rede como uma plataforma coordenada.
No entanto, a programabilidade tem custos operacionais. Um pipeline de pacotes modificável exige processos disciplinados de controle de versão, testes, observabilidade e reversão.
As equipes de rede precisam saber quais configurações de firmware e transporte estavam ativas durante um trabalho que falhou. Elas também precisam de ferramentas que correlacionem eventos de congestionamento com o desempenho da aplicação.
O rótulo P4 não elimina esses requisitos. Ele apenas dá à AMD e aos operadores aprovados mais margem para alterar o comportamento das funções compatíveis de processamento de pacotes.
Os padrões abertos criam outro desafio de implementação. Dois produtos podem alegar suporte à mesma especificação, mas diferir em recursos opcionais, limites de desempenho ou interfaces de gerenciamento.
Por isso, os testes de interoperabilidade serão decisivos. Os compradores precisam de evidências de que o Vulcano funciona de forma confiável com switches, ópticas, software de roteamento e sistemas de monitoramento de terceiros.
A página do AMD AI NIC enfatiza hyperscalers e provedores de nuvem. Esses clientes dispõem das equipes de engenharia necessárias para testar comportamentos complexos de rede em grande escala.
A adoção por empresas pode avançar mais lentamente. Muitas empresas compram sistemas completos porque não têm equipes para integrar aceleradores, NICs, switches, firmware e configurações de transporte de forma independente.
O Vulcano ainda pode ajudar essas organizações por meio de sistemas Helios validados ou serviços de nuvem. O grau de abertura dependerá de quantos fornecedores disponibilizarem configurações compatíveis.
Esse é o teste prático por trás do produto. A programabilidade precisa reduzir o custo de adaptar uma rede sem transferir trabalho excessivo de integração para o cliente.
A Pilha Integrada da Nvidia Continua Sendo a Principal Concorrente
A AMD está desafiando o controle da Nvidia sobre a arquitetura de sistemas de IA, e não apenas competindo com outro adaptador Ethernet de 800 Gbps.
A Nvidia pode conectar seus aceleradores por meio do NVLink dentro de um domínio scale-up. Em seguida, oferece Quantum InfiniBand ou Spectrum-X Ethernet para comunicação entre servidores e racks.
O Spectrum-X combina switches Nvidia, SuperNICs, controle de congestionamento, telemetria e software. A Nvidia testa esses componentes como um sistema ponta a ponta, estreitamente vinculado à sua plataforma de GPUs.
Essa integração pode simplificar a responsabilização. Quando uma tarefa de IA apresenta desempenho inferior, um cliente pode pedir a um único fornecedor que examine o acelerador, o adaptador de rede, o switch, o firmware e as bibliotecas de comunicação.
A Nvidia afirma que o Spectrum-X Ethernet pode melhorar o desempenho de rede em 1,6 vez em relação à Ethernet convencional. Assim como os números da AMD, trata-se de uma alegação do fornecedor baseada em configurações especificadas.
O Spectrum-X também oferece suporte a sistemas operacionais de rede abertos, incluindo o SONiC. Portanto, a concorrência não é uma disputa simples entre Ethernet aberta e uma alternativa totalmente fechada.
A diferença real diz respeito ao controle e à escolha de componentes. A Nvidia otimiza uma combinação definida de seu silício e software, enquanto a AMD enfatiza dispositivos programáveis e especificações do setor entre diferentes fornecedores.
A integração estreita pode produzir comportamento consistente, mas pode aumentar a dependência do cronograma de lançamentos de um único fornecedor. Um projeto multiforncedor pode oferecer mais opções, mas o trabalho de qualificação se torna mais difícil.
O Vulcano precisa provar que sua abordagem aberta não sacrifica um desempenho previsível. Apenas o throughput máximo não resolverá essa questão.
Operadores de clusters de IA analisam o tempo de conclusão das tarefas, a latência de cauda, a recuperação de falhas, a utilização efetiva de GPUs e o isolamento de desempenho entre locatários. Eles também acompanham o consumo de energia e a quantidade de ópticas necessárias.
A alegação da AMD de redução de 13% no tempo de conclusão é relevante porque mede um resultado da aplicação. Ainda assim, o material público não estabelece uma vantagem universal sobre o Spectrum-X ou o InfiniBand.
A alegação de redução de 33% no custo de switching também exige interpretação cuidadosa. Menos cabos e transceptores podem reduzir gastos com equipamentos, trabalho de instalação e pontos de falha.
No entanto, uma configuração de três NICs por GPU pode adicionar adaptadores, interfaces de host e complexidade de gerenciamento em outros pontos. O resultado total depende da topologia e da base de comparação.
A Nvidia tem outra vantagem por meio de sistemas já implantados. Seus produtos de rede já operam em grandes clusters de IA, oferecendo aos clientes referências de implementação e práticas de suporte consolidadas.
A AMD não está entrando sem experiência. A Pensando já forneceu DPUs e Pollara AI NICs, enquanto a AMD trabalhou com provedores de nuvem e fornecedores de sistemas em redes de data centers.
Ainda assim, o Vulcano chega junto com vários outros elementos em movimento. O Helios introduz novos aceleradores Instinct, processadores EPYC, conexões UALink e uma pilha de software aberta em evolução.
Um problema em qualquer camada pode atrasar a qualificação. Os clientes podem escolher uma configuração madura mesmo quando outro projeto promete maior flexibilidade de componentes.
O risco é maior para organizações que buscam capacidade de treinamento no curto prazo. Sua prioridade costuma ser colocar um cluster em operação rapidamente, e não maximizar a futura escolha de fornecedores.
Compradores de longo prazo podem valorizar mais a abordagem aberta. A infraestrutura perdura por várias gerações de aceleradores, enquanto modelos e padrões de comunicação mudam muito mais rápido.
A programabilidade P4 do Vulcano pode ajudar a AMD a responder a essas mudanças. Novos controles de congestionamento ou comportamentos de transporte podem chegar por software, dentro das capacidades do hardware.
A Nvidia também pode atualizar sua pilha. Ela também se beneficia por controlar mais componentes, o que pode acelerar mudanças coordenadas em todo o sistema.
A principal disputa é, portanto, operacional. A AMD precisa mostrar que a escolha baseada em padrões pode igualar a confiabilidade, as ferramentas e a validação da plataforma integrada da Nvidia.
A presença do Google em grupos de interconexão aberta aumenta a confiança de que a alternativa tem apoio sério da indústria. Isso não elimina a base instalada nem a vantagem de execução da Nvidia.
O Que a AMD Ainda Precisa Provar
A maior incerteza é se os ganhos publicados do Vulcano resistem a testes independentes em clusters multiforncedor realistas.
Os números públicos da AMD descrevem capacidades máximas e comparações selecionadas. Eles ainda não fornecem um amplo conjunto de resultados de terceiros em treinamento, inferência distribuída e cargas de trabalho mistas.
O número de 2,4 Tbps é a largura de banda agregada scale-out de três NICs de 800 Gbps. Não é uma garantia de que uma aplicação de GPU receberá essa taxa de dados continuamente.
Análises independentes devem medir o throughput útil sob congestionamento. Também devem relatar distribuições de latência, comportamento de recuperação de pacotes e tempo de inatividade dos aceleradores.
Os testes de falha importam tanto quanto a velocidade em estado estacionário. Os avaliadores devem desativar links, introduzir perda de pacotes, reiniciar switches e variar a latência dos caminhos enquanto uma tarefa distribuída permanece ativa.
O MRC precisa então de evidências de interoperabilidade. A AMD afirma que o transporte oferece suporte a várias abordagens de encaminhamento, mas os clientes vão querer combinações verificadas de NICs, switches, firmware e software de roteamento.
A disponibilidade geral é outro detalhe sem resposta. A AMD disse que o Vulcano está sendo qualificado para clusters Instinct da série MI400, enquanto a disponibilidade do Helios é esperada durante 2026.
Qualificação não é o mesmo que implantação ampla. Um produto pode atingir suas metas de projeto enquanto fornecedores de sistemas, provedores de nuvem e empresas ainda precisam de meses de validação.
A questão do Google continua especialmente importante porque a palavra-chave principal sugere uma relação direta. O Google apoiou o UALink, mas nenhuma evidência pública confirma que o Google Cloud oferecerá instâncias baseadas no Vulcano.
Uma implantação do Google forneceria um sinal significativo de adoção. Ela mostraria que um hyperscaler com experiência interna em redes considerou o Vulcano adequado para uso em produção.
A ausência de tal anúncio não é evidência contra o produto. Hyperscalers frequentemente avaliam várias arquiteturas e divulgam apenas implantações selecionadas.
A prontidão do software também exige análise. O ROCm precisa coordenar a comunicação coletiva com a rede, ao mesmo tempo que expõe telemetria útil aos agendadores e às equipes de operações.
Uma NIC rápida não pode compensar bibliotecas coletivas ineficientes ou um posicionamento inadequado das cargas de trabalho. A conscientização de rede precisa alcançar a camada de orquestração se os operadores quiserem tempos de tarefa consistentes.
A segurança também merece atenção. Dispositivos programáveis ampliam as possibilidades de configuração, e cada caminho de firmware exige controles em torno de assinatura, atualizações, acesso e reversão.
Especificações abertas não criam automaticamente um gerenciamento aberto. Os clientes devem examinar quais funções exigem ferramentas da AMD e se produtos de observabilidade de terceiros podem acessar a telemetria essencial.
A alegação de custo precisa de uma contabilização completa do sistema. Uma comparação justa deve incluir adaptadores, switches, cabos, ópticas, espaço em rack, energia, suporte e mão de obra de engenharia.
As equipes que avaliam o Vulcano devem preservar os registros de benchmark por meio de uma base de conhecimento de engenharia pesquisável. As versões de firmware e os detalhes da topologia podem determinar se comparações posteriores continuarão úteis.
As equipes de compras também devem separar os requisitos de scale-up dos de scale-out. UALink, Ultra Ethernet, MRC e PCIe tratam de partes diferentes do caminho de dados.
Confundir essas camadas pode produzir especificações impressionantes sem uma implantação coerente. Os compradores precisam de uma arquitetura que mostre como o tráfego se desloca de um acelerador para cada endpoint relevante.
A direção técnica da AMD é plausível. Seu desafio é converter essa direção em sistemas repetíveis que os clientes possam encomendar, implantar, monitorar e reparar.
Três Sinais Decidirão o Caso do Vulcano em Redes de IA
A posição do Vulcano ficará mais clara por meio de resultados independentes de clusters, clientes de produção identificados e interoperabilidade multifornnecedor verificada.
O primeiro sinal são testes independentes em sistemas Helios completos. Os resultados devem comparar tempos de conclusão das tarefas, utilização de GPUs, latência de cauda e recuperação em diversas condições de rede.
Um teste útil identificará todos os componentes e versões de software. Ele deve distinguir a largura de banda medida no link do throughput entregue à aplicação de IA.
Resultados sólidos em várias cargas de trabalho sustentariam a alegação da AMD de que o Vulcano elimina gargalos de comunicação. Resultados fracos ou inconsistentes reduziriam o valor de sua largura de banda divulgada em destaque.
O segundo sinal é uma implantação identificada de hyperscaler ou nuvem. A Oracle discutiu infraestrutura de escala de rack da AMD, enquanto a OpenAI trabalhou com a AMD na validação do MRC.
O Google seria especialmente significativo devido ao interesse de busca por amd google e ao seu papel nos esforços de interconexão aberta. No entanto, os leitores devem esperar por um anúncio direto de implantação.
Um cliente precisa descrever mais do que uma avaliação. Disponibilidade em produção, tamanho do cluster, cargas de trabalho compatíveis e expectativas de nível de serviço forneceriam evidências mais fortes.
O terceiro sinal é a interoperabilidade além de um projeto de referência totalmente AMD. O Vulcano deve funcionar com vários fornecedores de switches, sistemas operacionais de rede, ópticas e plataformas de gerenciamento.
Uma interoperabilidade bem-sucedida fortaleceria o argumento econômico para redes de IA abertas. Ela permitiria que os clientes alterassem componentes selecionados sem redesenhar todo o cluster.
Compatibilidade limitada enfraqueceria esse argumento, mesmo que o Helios tenha bom desempenho como uma configuração de referência fechada. Na prática, o sistema poderia se tornar integrado apesar de se basear em especificações abertas.
A Nvidia não ficará parada enquanto a AMD conclui essa validação. O Spectrum-X já combina Ethernet baseada em padrões com o controle da Nvidia sobre a plataforma ao redor.
Portanto, comparações futuras devem usar produtos atuais de ambas as empresas. Uma vitória contra Ethernet mais antiga não prova vantagem sobre a infraestrutura mais recente da Nvidia.
Para desenvolvedores, o efeito imediato continuará indireto. A maioria encontrará o Vulcano por meio de instâncias de nuvem, clusters gerenciados ou sistemas selecionados por equipes de infraestrutura.
Ainda assim, as redes influenciam o tempo de treinamento, a latência de inferência, a disponibilidade de capacidade e o custo do serviço. Melhorias na camada de infraestrutura podem mudar quais cargas de trabalho de IA permanecem economicamente viáveis.
Compradores corporativos devem pedir aos fornecedores evidências no nível da carga de trabalho, em vez de resumos de velocidade de portas. Também devem solicitar testes de falha e um limite claro de suporte entre fornecedores.
A questão essencial já não é se a Ethernet consegue transportar tráfego de IA. A questão é se um sistema Ethernet aberto pode oferecer resultados consistentes na escala em que um único caminho atrasado desperdiça milhares de aceleradores.
A AMD apresentou agora uma resposta concreta por meio de Vulcano, MRC, Ultra Ethernet e Helios. O Google e outros parceiros de padronização tornam a rota aberta mais credível, mas não garantem a execução da AMD.
Acompanhe os primeiros benchmarks independentes do Helios, a primeira implementação de cloud do Vulcano com nome divulgado e os primeiros relatórios abrangentes de interoperabilidade. Esses três sinais determinarão se a aposta da AMD em padrões se torna uma alternativa de produção ou permanece uma especificação atraente.
