CXL está reescrevendo a arquitetura de memória de servidores — e as cargas de trabalho de IA são o motivo
Durante a maior parte da história da computação, a memória esteve fisicamente ligada ao processador que a utiliza. CPUs têm seus DIMMs, GPUs têm seus stacks de HBM, e os dois pools não se comunicam de forma eficiente. Essa arquitetura funcionava bem quando as cargas de trabalho cabiam confortavelmente dentro do orçamento de memória de um único servidor. A IA mudou isso. A inferência de modelos de linguagem grandes requer terabytes de memória apenas para a KV cache, e a DRAM ligada a um único servidor não é nem de perto suficiente. Compute Express Link (CXL) é a resposta da indústria para essa incompatibilidade — e sua adoção está se acelerando rápido o suficiente para ser importante para qualquer pessoa que esteja construindo ou comprando infraestrutura de data center nos próximos dois anos.
CXL não é um produto. É um protocolo — especificamente, um padrão de interconexão aberto construído sobre a camada física PCIe 5.0 que permite que processadores acessem memória em dispositivos externos com a mesma baixa latência e coerência de cache que eles esperam de DRAM diretamente ligada. A implicação prática é grande: a memória pode ser instalada em um módulo de memória CXL do outro lado de um slot PCIe, ou agrupada em um rack inteiro através de um switch CXL, e a CPU a trata como se fosse memória local.
Três subprotocolos, um caso de uso impulsionando a adoção
CXL define três subprotocolos que servem a funções diferentes. CXL.io lida com E/S básica de dispositivos — aproximadamente equivalente a PCIe. CXL.cache permite que um dispositivo armazene em cache partes da memória do host, permitindo que aceleradores como GPUs acessem dados do lado da CPU de forma eficiente sem cópias explícitas de dados. CXL.mem é o que está recebendo mais investimento: permite que uma CPU host leia e escreva na memória instalada em um dispositivo CXL externo, expandindo a capacidade de memória efetiva disponível para qualquer processador muito além do que os slots DIMM da placa-mãe permitem.
CXL 1.0 apareceu em 2019. CXL 2.0 (2020) adicionou memory pooling — a capacidade de vários processadores host compartilharem um pool de memória CXL comum — e comutação, para que um único pool possa ser acessado por vários servidores. CXL 3.0 (2022) estendeu isso para topologias de fabric: acesso multi-host onde qualquer nó de computação em um rack pode alcançar qualquer módulo de memória, com coerência peer‑to‑peer. O teto de largura de banda atingiu 256 GB/s por porta no CXL 3.0, aproximando-se do que HBM fornece para memória ligada a GPU.
Por que a inferência de IA é a função forçadora
A inferência de LLM tem um problema de memória específico que o CXL está bem posicionado para resolver. Quando um modelo gera texto, ele mantém uma KV cache que armazena o estado de atenção para cada token na janela de contexto. Para um modelo com uma janela de contexto de 128K tokens executando em um servidor de inferência multi-inquilino, apenas a KV cache pode consumir centenas de gigabytes — dinamicamente, dependendo das sessões ativas.
Gerenciar isso com HBM de GPU é caro e com capacidade limitada. Módulos HBM4 atingem o máximo de cerca de 48 GB por stack; mesmo um servidor com 8 GPUs atinge o máximo de cerca de 384 GB de memória GPU. A expansão de memória CXL oferece um overflow econômico: dados de KV cache que não precisam da largura de banda bruta de HBM podem residir em DRAM ligada via CXL a aproximadamente 10–20% do custo por gigabyte, com latência em torno de 100–200 nanossegundos contra 20–30 ns para HBM. A penalidade de latência é real, mas aceitável para dados acessados com pouca frequência durante a inferência.
A inferência com memória desagregada (memory‑disaggregated inference) — onde um pool de memória CXL é compartilhado entre vários servidores GPU — leva isso adiante. Em vez de cada servidor GPU manter seu próprio buffer DRAM superdimensionado, um fabric CXL permite que 10 servidores de inferência compartilhem um único pool de memória de 4 TB que é alocado dinamicamente com base na carga. A utilização melhora, a capacidade ociosa diminui e o custo por inferência cai.
Quem está construindo o hardware
O Módulo de Memória CXL DRAM (CMM‑D) da Samsung oferece até 128 GB por módulo a 256 GB/s de largura de banda e já está em qualificação com hiperescaladores. A SK Hynix tem sua própria linha de DRAM CXL, com um módulo de 128 GB voltado para servidores de inferência de IA. A Micron entrou na produção de DRAM CXL em 2024. Todos os três principais fabricantes de DRAM estão agora enviando ou qualificando produtos CXL — o lado da oferta está amadurecendo.
No lado da conectividade, a Astera Labs abriu capital em 2024 especificamente com base na força de seus chips de conectividade CXL e PCIe. Seus retimers Aries estão dentro da maioria dos servidores com capacidade CXL enviados hoje, e seus CIs de Conectividade de Memória CXL Leo permitem fabrics de memory pooling em escala de rack. Marvell e Synopsys também fornecem IP de controlador CXL que vai para processadores de servidor.
Os processadores Intel Xeon Scalable suportam CXL desde a geração Sapphire Rapids. Os processadores AMD EPYC adicionaram suporte a CXL na geração Genoa. Os processadores de servidor baseados em Arm da Ampere e a CPU Grace da Nvidia incluem suporte a CXL. O ecossistema é amplo o suficiente para que CXL não seja mais uma opção exótica — é uma caixa de seleção padrão nos SKUs de servidores empresariais.
O que está disponível hoje vs. o que está por vir
A expansão de memória CXL Tipo 3 (expansão de um único host da memória de um servidor além dos limites do slot DIMM) é o caso de uso mais maduro e está disponível em produção hoje. Um servidor com 12 slots DIMM com capacidade máxima de 3 TB de DDR5 pode adicionar outros 4 TB através de uma placa de expansão de memória CXL — útil para bancos de dados in-memory, grandes cargas de trabalho analíticas e KV caches de LLM.
O memory pooling CXL (vários hosts compartilhando um recurso de memória CXL comum) está em testes com clientes em hiperescaladores a partir de 2025–2026, mas ainda não está em produção ampla. A pilha de software — suporte do sistema operacional para tiers de memória CXL, integração com hipervisor, políticas de gerenciamento de memória — ainda está amadurecendo. O suporte do kernel Linux para CXL está melhorando rapidamente (a série Linux 6.x tem suporte CXL progressivamente mais forte), mas as ferramentas de orquestração estão atrasadas.
O fabric CXL completo (desagregação de memória em escala de rack com acesso coerente multi-host) permanece em grande parte no estágio de prova de conceito de hiperescaladores. Google, Microsoft e AWS estão todos testando arquiteturas fabric CXL internamente, mas as implementações voltadas para o cliente estão a 18–24 meses de distância.
O que isso significa para compradores de infraestrutura
Para organizações que compram servidores hoje, a expansão de memória CXL Tipo 3 vale a pena ser avaliada para cargas de trabalho específicas: bancos de dados in-memory como SAP HANA ou Redis que precisam de grandes footprints de memória, cargas de trabalho analíticas que não cabem em DRAM padrão e infraestrutura de serving de LLM onde o gerenciamento de KV cache é um gargalo.
A economia só faz sentido quando o custo da DRAM ligada via CXL (aproximadamente US$ 10–20 por GB em módulos atuais, em comparação com US$ 3–5 por GB para DIMMs DDR5 padrão) é pesado contra a alternativa, que é comprar mais servidores com mais slots DIMM. Para cargas de trabalho intensivas em memória, as economias de consolidação normalmente pagam o prêmio do CXL em 12–18 meses.
Para compradores de nuvem, a pergunta mais relevante é quando os hiperescaladores exporão tiers de memória apoiados por CXL como opções de preço distintas — permitindo que os clientes especifiquem memória CXL mais barata e de maior capacidade para dados tolerantes à latência, juntamente com HBM rápida ou DDR5 para caminhos críticos de latência. AWS e Google têm programas internos de CXL, e recursos visíveis ao cliente são prováveis em 2027.
CXL não é uma tecnologia procurando um caso de uso. O caso de uso — expansão de memória de IA — chegou antes que o hardware estivesse completamente pronto. O hardware está alcançando agora, e os próximos dois anos determinarão se a memória desagregada se torna um recurso padrão da infraestrutura de IA ou permanece uma ferramenta especializada para os maiores hiperescaladores.