AMD, ROCm e a linha MI3xx

01 · Conceito

Conceito

A lição 9.3 terminou com um resultado desconfortável: num acelerador de 80 GB, o Qwen3.8-27B em seu contexto nativo completo de 262.144 tokens cabe exatamente uma vez. Uma conversa, uma placa, nenhum segundo usuário. Servir mesmo um punhado de sessões de contexto longo nesse hardware significa dividir o modelo entre dispositivos, o que significa um all-reduce em cada uma das 64 camadas e um orçamento de interconnect que ninguém planejou. A linha Instinct da AMD responde a esse problema específico com um número específico, e vale percorrê-lo honestamente, incluindo o que ele não resolve.

A peça classe MI300X carrega 192 GB de HBM3 informados pelo fabricante com pico informado pelo fabricante perto de 5,3 TB/s, construída sobre um design de chiplets com várias centenas de compute units, em agosto de 2026 e sujeita à cautela usual de que SKUs dentro de uma família diferem. Programá-la passa por ROCm em vez de CUDA, com HIP como dialeto de nível de kernel, e as principais stacks de serving mantêm caminhos de build para AMD documentados ao lado dos de CUDA.

Rode primeiro a linha de capacidade, usando o método da lição 9.3 sem alterações. O runtime da MI300X reporta cerca de 192 GiB. Os pesos em bf16 são os mesmos 50,3 GiB fixos que são em toda parte, e uma reserva de runtime de cerca de 8 GiB cobre contexto, ativações e fragmentação, deixando

No contexto nativo completo, cada sequência custa 16 GiB de keys e values mais os 144 MiB constantes de estado float32 de referência do Gated DeltaNet, 16.528 MiB no total, então um dispositivo comporta

contra exatamente uma na peça de 80 GB. Numa janela de 8.192 tokens, 656 MiB por sequência, o mesmo pool serve cerca de 208 conversas concorrentes contra cerca de 36. Essa é a proposta inteira, e ela é forte: uma carga que exigia tensor parallelism, uma decisão de topologia, uma biblioteca de comunicação coletiva e uma história de depuração agora roda como um único processo num único dispositivo. Simplicidade operacional é um ativo real de engenharia e raramente aparece numa ficha técnica.

Agora o desvio errado, que é quase universal. Capacidade é lida como velocidade, e alguém conclui que, como o modelo inteiro cabe confortavelmente, os usuários verão respostas mais rápidas. Aplique a heurística pelo tamanho do checkpoint da lição 9.1. O decode textual em batch 1 transmite os tensors ativos do modelo de linguagem, enquanto o quociente do checkpoint completo dá uma comparação de ordem de grandeza:

uma heurística pelo tamanho do checkpoint derivada de uma alegação de bandwidth do fabricante, não uma medição nem um limite rígido. Melhor que os aproximadamente 62 de uma peça Hopper de 80 GB, pior que os aproximadamente 148 de uma peça classe Blackwell de 192 GB. Capacidade e bandwidth são compras independentes, como a lição 9.4 insistiu, e esta peça compra bastante da primeira.

A correção vai além, e inverte o enquadramento usual do sharding. Dividir o Qwen3.8-27B entre duas peças de 80 GB em tensor parallel significa que cada dispositivo guarda, e portanto lê, apenas cerca de 27 GB de pesos por passo de decode, um quociente pelo tamanho do checkpoint perto de 8,1 milissegundos a 3,35 TB/s, ou cerca de 124 tokens por segundo como heurística antes das coletivas — a lição 9.9 cobra os all-reduces por token que isso ignora e aterrissa mais perto de 107. Sharding não é meramente um jeito de fazer caber um modelo que não cabe; é um jeito de comprar bandwidth agregada para um único fluxo. O que ele custa é um all-reduce sobre o residual stream de dimensão 5.120 depois de cada bloco de attention e de feed-forward, duas vezes por camada ao longo de 64 camadas, o que a lição 9.9 precifica direito e o que corrói o ganho teórico. Então o resumo honesto é que um único dispositivo de memória grande vence em concorrência, simplicidade de implantação e custo por token servido, enquanto um par bem interconectado pode vencer na latência que um único usuário impaciente percebe. Qual dessas o seu produto vende decide a compra.

Na prática, essa verificação é barata e deve acontecer antes da conversa comercial: construa a stack de serving pelo caminho de instalação para AMD documentado, carregue o modelo primeiro em bf16 porque isso exercita o menor número de kernels opcionais, confirme que a memória livre reportada bate com o orçamento acima, e então refaça o teste com a quantização que você de fato planeja rodar. Falhas nesse estágio costumam ser regressões silenciosas de desempenho, e não crashes — um kernel de fallback discretamente substituindo um fundido —, então compare a taxa de decode atingida com a heurística de checkpoint acima como um diagnóstico; uma lacuna sozinha não prova kernel faltante.

A ideia transferível é que o segundo fabricante não é uma cópia mais barata do primeiro; ele compete num eixo diferente. Leia qualquer acelerador pela sua linha de capacidade e pela sua linha de bandwidth, e então pergunte o que o ecossistema de software de fato vai rodar nele neste trimestre. A lição 9.9 retoma o caso que esta lição vinha adiando: o que custa quando um dispositivo genuinamente não basta.