d-Matrix Raptor e NVIDIA NVLink Fusion: um mapa de posicionamento das fases de inferência para racks heterogêneos

Por que este anúncio importa, e o que ele ainda não prova

Em 10 de setembro, a d-Matrix e a NVIDIA descreveram uma colaboração para levar a XPU Raptor planejada da d-Matrix à infraestrutura de IA em escala de rack da NVIDIA por meio do NVLink Fusion, com referências a MGX, CPUs Vera, Spectrum-X e conectividade da Astera Labs. Isso é um sinal real de arquitetura para equipes de inferência. Não é um benchmark disponível.

Essa distinção importa mais do que o título do comunicado à imprensa. A d-Matrix afirma que o tape-out do Raptor é esperado antes do fim de 2026, com as XPUs Raptor iniciais em MGX esperadas em Q4 2027. Corsair é a plataforma da d-Matrix descrita como em produção hoje. Portanto, a pergunta de curto prazo não é: "Isso deve substituir uma pilha de inferência implantável agora?" A pergunta melhor é: "O que teria de ser medido antes que um rack heterogêneo mereça confiança em produção?"

Na minha visão: o interessante não é que outro acelerador possa se conectar a uma narrativa de rack centrada na NVIDIA. O interessante é saber se o pré-preenchimento e a decodificação podem ser separados sem pagar um custo de coordenação tão alto que a separação vire teatro. O pré-preenchimento e a decodificação pressionam os sistemas de formas diferentes. O pré-preenchimento tende a recompensar computação paralela sobre a sequência de entrada. A decodificação muitas vezes fica complicada em torno de latência entre tokens, movimentação de memória, concorrência e comportamento do agendador. Se um rack futuro combinar GPUs NVIDIA, CPUs hospedeiras Vera e XPUs Raptor por meio de malhas definidas de escala vertical e escala horizontal, o vencedor não será o fornecedor com o gráfico de largura de banda mais bonito. O vencedor será a topologia que melhora o tempo até o primeiro token, a latência entre tokens, o custo de transferência de estado, as filas e a vazão útil sob o mesmo alvo de qualidade do modelo.

Para uma mentalidade mais ampla de posicionamento, a discussão anterior da Optijara sobre testes de posicionamento de modelo em hardware é uma companhia útil. A mesma regra se aplica aqui: o acelerador é apenas uma parte do caminho de serviço. Para controles de benchmark, a escada de fidelidade Qdrant Supernova FineWeb 10B também é relevante porque trata a medição como uma cadeia de comparações controladas, e não como uma única pontuação de destaque.

A arquitetura de rack anunciada em termos simples

O material público aponta para várias camadas que não devem ser misturadas em uma alegação vaga sobre um rack mais rápido. O NVLink Fusion é o caminho da NVIDIA para conectar silício personalizado à sua malha de alta velocidade em escala vertical. Neste anúncio, essa é a camada de malha que torna o roteiro do Raptor digno de acompanhamento, porque sugere um futuro em que aceleradores que não são GPU podem ficar mais próximos de sistemas acelerados da NVIDIA do que ficariam por um caminho convencional de dispositivo separado.

O Spectrum-X é uma camada diferente. Ele é posicionado em torno de redes de escala horizontal baseadas em Ethernet, o que importa quando racks e clusters se comunicam além de um único domínio de escala vertical. Misturar os dois termos embaralha a pergunta de engenharia. O NVLink Fusion fala do acoplamento em escala vertical ao redor de sistemas acelerados. O Spectrum-X fala de redes em escala horizontal. Ambos podem importar na inferência, mas pressionam fronteiras diferentes.

O MGX é o ambiente de integração para projeto mecânico, energia e refrigeração. Ele não deve ser lido como promessa de que todo acelerador se torna intercambiável, de que qualquer região de memória é automaticamente compartilhada, ou de que o software de serviço pode mover estado sem trabalho operacional. As CPUs Vera são citadas como processadores hospedeiros no contexto da arquitetura anunciada. O Raptor é o papel de XPU planejado. A Astera Labs é nomeada como parceira de conectividade, mas os comunicados públicos não sustentam alegações adicionais sobre detalhes de silício não divulgados.

O contexto do 3DIMC da d-Matrix é relevante porque explica a linguagem de arquitetura centrada em memória do fornecedor, incluindo um encapsulamento de dois níveis que combina DRAM e SRAM na descrição do fornecedor. Ele não deve ser tratado como HBM, como Pavehawk, ou como evidência de produção para racks Raptor.

O Mapa de Posicionamento das Fases de Inferência

O Mapa de Posicionamento das Fases de Inferência da Optijara é uma forma prática de avaliar esse tipo de roteiro de rack heterogêneo. Ele é uma estrutura de medição, não uma alegação de que o Raptor atualmente implementa toda a topologia abaixo.

Fase 1: ingestão de instrução de entrada e agrupamento

A primeira decisão não é hardware. É o formato do tráfego. A distribuição de comprimento das instruções de entrada, os padrões de rajada, a reutilização de contexto e a política de admissão determinam se o pré-preenchimento pode ser agrupado com eficiência. Uma malha de rack não consegue resgatar um agendador que mistura classes de solicitações incompatíveis.

Fase 2: pré-preenchimento intensivo em GPU

O pré-preenchimento é um candidato natural para GPU porque pode se beneficiar de computação paralela densa sobre a sequência de entrada. Em um rack heterogêneo futuro, o caminho de pré-preenchimento deve ser comparado com uma linha de base na mesma GPU, não com uma ficha abstrata de especificações de acelerador. A métrica aqui é o tempo até o primeiro token sob misturas realistas de instruções de entrada.

Fase 3: transferência de estado pela malha do rack

Esta é a fronteira que muitos anúncios subestimam. Mover o estado necessário de uma fase para outra pode introduzir serialização, atraso de transporte, filas e atrito de formato de memória. Alta largura de banda da malha não significa automaticamente baixa latência visível ao usuário.

Fase 4: candidatos a decodificação orientada a XPU

A decodificação é sensível ao comprimento da saída, à concorrência, ao comportamento de cache, à precisão suportada e à latência entre tokens. Um caminho de decodificação em XPU poderia ser atraente se melhorasse a geração sustentada sob o mesmo alvo de qualidade e objetivo de serviço. Isso precisa ser medido. O suporte ao NVLink Fusion por si só não é prova.

Fase 5: conclusão, destokenização e feedback do agendador

O laço de serviço termina com destokenização, transmissão da resposta e feedback para o controle de admissão. Se a fila de decodificação estiver congestionada, os ganhos de pré-preenchimento podem desaparecer. Se a reutilização de cache for alta, uma topologia diferente pode vencer. O mapa força as equipes a observar cada fronteira em vez de celebrar um componente.

{
  "framework": "Mapa de Posicionamento das Fases de Inferência",
  "status": "estrutura de avaliação conceitual, não um benchmark do Raptor",
  "phases": ["ingestão", "pré-preenchimento", "transferência_de_estado", "decodificação", "feedback_do_agendador"],
  "decision_rule": "comparar vazão útil sob qualidade de modelo, mistura de tráfego e objetivos de serviço iguais"
}

O que medir antes de acreditar que a arquitetura vence

O plano de medição deve separar a capacidade por estágio do comportamento no nível do serviço. TTFT não é latência de decodificação. Latência de decodificação não é tempo total de conclusão. Tokens por segundo sem um limiar de qualidade não são vazão útil.

O benchmarking deve usar a mesma família de modelos, o mesmo limiar de qualidade, a mesma distribuição de instruções de entrada, a mesma distribuição de saída e o mesmo objetivo de serviço. Isso parece meticuloso, mas é a única forma de manter a comparação honesta. Mude duas variáveis ao mesmo tempo e o resultado vira uma história sobre a configuração do teste, não sobre o rack.

Integração anunciada versus artefato disponível versus experimento exigido

Nenhum benchmark de hardware da Optijara foi realizado para o Raptor. Cada teste específico do Raptor acima é uma etapa proposta de avaliação futura para quando artefatos públicos e sistemas implantáveis existirem.

Erros comuns ao ler anúncios de inferência heterogênea

Erro 1: tratar largura de banda como latência

Um link rápido pode reduzir um gargalo enquanto filas, serialização, layout de estado e decisões do agendador ainda dominam a experiência do usuário. A latência de serviço é o resultado do caminho completo.

Erro 2: presumir que rack compartilhado significa memória compartilhada

A integração em rack compartilhado não significa automaticamente memória compartilhada arbitrária, transferência KV sem cópia, compatibilidade com CUDA ou serviço de modelos intercambiável. Essas são alegações de software e sistema que precisam de evidência explícita.

Erro 3: presumir que a separação de fases é sempre melhor

A separação entre pré-preenchimento e decodificação pode ter desempenho inferior quando as instruções de entrada são curtas, as saídas são breves, a movimentação de estado é cara, as filas estão desequilibradas ou o suporte de precisão difere entre dispositivos.

Erro 4: ignorar o formato da fila e o comprimento da saída

Cargas de trabalho pesadas em decodificação com saídas longas criam pressão diferente de respostas curtas de assistente ou de instruções de entrada aumentadas por recuperação. Uma única média de tokens por segundo pode esconder comportamento de cauda ruim.

Erro 5: tratar datas de roteiro como evidência de produção

Tape-out esperado antes do fim de 2026 e XPUs Raptor iniciais em MGX esperadas em Q4 2027 são sinais úteis de planejamento. Não são prova de disponibilidade atual, preço, latência de produção ou compatibilidade.

Uma lista prática de avaliação para futuros racks da classe Raptor

O caminho prático é construir a bancada de testes antes de comprar a narrativa da arquitetura. Comece pela caracterização da carga de trabalho. Adicione uma linha de base no mesmo dispositivo. Adicione um caminho candidato dividido somente quando os artefatos existirem. Meça TTFT, latência entre tokens, latência de cauda, profundidade da fila, pressão de memória, saturação de transporte, recuperação de falhas e vazão útil. Mantenha constantes o modelo, a barra de qualidade e o objetivo de serviço.

As ressalvas não são glamorosas: custo de implementação, variância de provedor e modelo, controles de privacidade, desatualização de cache, restrições de formato de memória, complexidade de agendamento e maturidade de integração. Para equipes que planejam infraestrutura futura, a Optijara pode ajudar a desenhar o método de avaliação e os testes de posicionamento de fases para que decisões de arquitetura sejam submetidas a pressão antes de virarem compromissos de serviço.