Modular MAX e Mojo

01 · Conceito

Conceito

Você tem o Qwen3.8-27B rodando sob vLLM em hardware NVIDIA, e o seu time de infraestrutura anuncia que metade do próximo cluster será AMD. Nada muda no modelo. O que muda é que cada kernel CUDA escrito à mão no seu caminho de serving passa a ter uma contraparte que outra pessoa mantém num ritmo diferente, e o seu perfil de performance vira dois perfis. Esse é o problema que o stack da Modular ataca, e vale entendê-lo pelos seus méritos antes de decidir se a troca é a que você quer.

Recorde o formato do que você já conhece da lição 8.4. O vLLM é um engine Python: um scheduler, um alocador de KV paginado e um loop de continuous batching orquestrando operações do PyTorch e um conjunto de kernels CUDA e Triton escritos à mão para as partes que importam. Esse design tem uma força específica e uma fraqueza específica. A força é que um especialista consegue escrever um kernel de attention que extrai quase tudo que uma geração específica de GPU oferece. A fraqueza é que a força não viaja: um novo fornecedor, uma nova arquitetura ou um novo tipo de camada significam novos kernels, escritos de novo, por alguém que conhece aquele alvo.

O MAX propõe o arranjo oposto. Um modelo é expresso como um grafo de computação, e um compilador antecipado assume o que antes era território do autor de kernels — fusão de operadores, layout de memória, escalonamento do grafo no device — e emite código para qualquer acelerador suportado ao qual você apontar. Por cima fica uma camada de serving que fala uma API compatível com OpenAI, então da perspectiva de um cliente ela se encaixa no mesmo buraco que o vLLM ocupa. O discurso é que o mesmo grafo roda em NVIDIA e AMD sem reescrita específica de fornecedor, e que as decisões de fusão do compilador são sistemáticas em vez de dependentes de quais kernels um humano teve tempo de ajustar à mão.

Mojo é a camada abaixo disso, e existe porque um compilador precisa de estrutura sobre a qual raciocinar no laço mais interno. Mojo é uma linguagem de sistemas da família Python: sintaxe familiar, mas com tipos estáticos, semântica de ownership e acesso explícito a larguras SIMD, tiling e hierarquia de memória, compilada via MLIR. A intenção é que um autor de kernels escreva uma attention fundida ou um matmul quantizado uma vez, numa linguagem que um compilador consegue especializar e redirecionar, em vez de escrevê-lo três vezes em três dialetos de fornecedor. Se essa intenção se realiza para um dado operador é uma questão empírica, não uma garantia de design — mas o design é coerente, e coloca a autoria de kernels e a compilação de grafos numa única toolchain, uma linhagem que remonta a Halide, TVM, XLA e Triton.

Agora a parte honesta, porque uma lição de nível frontier que só repassa um discurso não vale a leitura. Este ecossistema é mais jovem que aqueles com que compete, e a juventude tem três consequências concretas para um modelo como o Qwen3.8-27B.

A primeira é a cobertura de modelos, e é a que decide se o resto da conversa acontece. O Qwen3.8-27B não é um transformer comum. Suas 64 camadas são 48 camadas Gated DeltaNet intercaladas com 16 camadas de full attention, e ele carrega uma vision tower. “Suporta LLMs transformer” não implica suporte a uma camada de linear attention recorrente com atualização por delta rule com gating e uma convolução curta — isso é um operador distinto que precisa existir na biblioteca de grafos, estar correto e ser rápido. Confira a lista de modelos suportados do release exato que você pretende rodar, e trate uma arquitetura ausente como bloqueio e não como exercício de portabilidade, a menos que escrever kernels em Mojo seja genuinamente o projeto ao qual você se ofereceu.

A segunda é a cobertura de quantization. Os formatos que você tem em disco — o GGUF da lição 8.7, um checkpoint AWQ ou GPTQ da lição 7.10 — não são universalmente consumíveis. Um stack que suporta um modelo em bf16 pode não suportá-lo na precisão que você de fato consegue bancar, e bf16 para este modelo significa 54 GB de pesos antes de qualquer cache.

A terceira é a maturidade da superfície. APIs, flags de CLI e formatos de configuração num stack em movimento rápido se movem. Isso é um custo operacional real, e a resposta correta é precificá-lo, não fingir que não existe.

Então avalie-o como avaliaria qualquer candidato, com o raciocínio visível. Passo um: a biblioteca de grafos implementa esta arquitetura no release que você tem? Se não, pare. Passo dois: ela suporta a precisão que você consegue caber no seu hardware? Passo três: monte um benchmark equivalente — mesma revisão de modelo, mesma precisão, mesmo preset de decoding do model card, mesmos comprimentos de entrada e saída, mesma concorrência, mesma janela de medição — e rode contra a sua linha de base em vLLM. Passo quatro: pese o resultado contra a portabilidade que você está de fato comprando. Se a sua frota é e continuará sendo uma única geração NVIDIA, portabilidade entre fornecedores vale quase nada para você e o stack maduro ganha só no custo de ops. Se você é genuinamente heterogêneo, ou espera ser, um único grafo e uma única toolchain entre fornecedores é uma vantagem estrutural que uma comparação de velocidade por kernel não captura.

A ideia durável é uma questão de fronteira: quem é dono da otimização, o humano ou o compilador? Todo stack desta track responde isso em algum ponto dessa linha, e a lição 8.12 põe todos eles lado a lado de uma vez.