CXL 4.0 em 2026: como o memory pooling e os 128 GT/s estão a transformar os servidores de IA e cloud
A memória tornou-se uma das principais limitações das infraestruturas modernas de IA e cloud. Os processadores e aceleradores continuam a ficar mais rápidos, mas disponibilizar memória suficiente para os alimentar de forma eficiente é cada vez mais difícil e dispendioso. O Compute Express Link, mais conhecido como CXL, responde a este problema ao fornecer uma ligação coerente entre processadores, aceleradores e memória externa. O CXL 4.0, lançado pelo CXL Consortium em novembro de 2025, aumenta a taxa máxima de transferência de 64 GT/s para 128 GT/s, mantendo ao mesmo tempo as capacidades de memory pooling e partilha desenvolvidas nas gerações anteriores do CXL. Em 2026, esta combinação é particularmente relevante para inferência de IA, grandes servidores cloud e computação à escala de rack. Não torna a memória DDR convencional ou a memória de alta largura de banda obsoletas, nem transforma imediatamente cada rack num único sistema de memória de grandes dimensões. O que oferece é uma forma prática de tratar a memória como um recurso mais flexível, em vez de uma capacidade fixa permanentemente associada a um único processador.
Porque é que o CXL 4.0 é importante para servidores de IA e cloud em 2026
O CXL foi criado porque a relação tradicional entre processadores e memória estava a tornar-se demasiado restritiva para cargas de trabalho de centros de dados. Um servidor convencional recebe uma quantidade fixa de memória local através dos canais de memória do CPU. Esta abordagem funciona bem quando as cargas de trabalho são previsíveis, mas os sistemas cloud e de IA raramente permanecem previsíveis durante muito tempo. Uma máquina pode necessitar temporariamente de vários terabytes de memória, enquanto outra máquina no mesmo rack mantém grandes quantidades de DRAM sem utilização. Instalar memória local suficiente em todos os servidores para cobrir os possíveis picos de procura deixa capacidade cara inativa durante grande parte do tempo. O CXL altera esta relação ao permitir que dispositivos de memória compatíveis fiquem fora da organização tradicional de DIMMs do processador, mantendo o acesso através de operações de leitura e escrita próprias de memória. As versões anteriores do CXL estabeleceram a expansão, comutação, pooling e partilha. O CXL 4.0 concentra-se sobretudo em aumentar a quantidade de dados que pode circular através destas ligações.
A principal alteração é a passagem para 128 GT/s, o dobro da taxa máxima de 64 GT/s do CXL 3.x. O CXL 4.0 consegue isto ao recorrer à camada física definida para PCI Express 7.0, cuja especificação final 1.0 foi publicada em junho de 2025. GT/s significa giga-transferências por segundo e não deve ser confundido com gigabytes por segundo. Este valor descreve a taxa de sinalização de cada lane, enquanto a largura de banda realmente utilizável depende de fatores como o número de lanes, a sobrecarga do protocolo e a configuração do dispositivo. O PCI Express 7.0, por exemplo, pode disponibilizar até 512 GB/s de largura de banda bidirecional numa ligação de dezasseis lanes. O CXL utiliza a mesma base física de alta velocidade, mas acrescenta os mecanismos de coerência e o comportamento de memória necessários para que processadores, aceleradores e dispositivos de memória trabalhem em conjunto. O resultado é uma capacidade de ligação significativamente superior sem obrigar o software a tratar a memória ligada como armazenamento convencional ou como um recurso de rede tradicional.
Esta taxa de transferência superior é importante porque a expansão de memória só é útil quando o caminho até essa memória é suficientemente rápido para a carga de trabalho. A DRAM local continua a ser a localização preferencial para dados sensíveis à latência, enquanto a HBM continua a ser essencial quando GPUs e outros aceleradores precisam de largura de banda extremamente elevada junto dos seus motores de cálculo. A memória CXL ocupa uma posição diferente na hierarquia. Pode disponibilizar uma capacidade muito superior àquela que seria economicamente viável instalar junto de cada processador ou acelerador, com características de acesso melhores do que mover a mesma informação para armazenamento SSD. Para infraestruturas de IA, isto cria mais um nível de memória utilizável entre a memória local rápida e limitada e o armazenamento muito mais lento. Para operadores cloud, também oferece uma forma de ajustar a capacidade de memória às mudanças das cargas de trabalho, em vez de dimensionar cada servidor para o pior cenário possível. O valor do CXL 4.0 resulta, portanto, tanto da flexibilidade como da taxa de transferência bruta.
O que muda, na prática, com 128 GT/s
Duplicar uma ligação de 64 GT/s para 128 GT/s não significa que uma aplicação passe automaticamente a funcionar duas vezes mais depressa. Muitas aplicações são limitadas pelo desempenho do processador, capacidade do acelerador, comportamento do software ou latência da memória, e não pela própria ligação CXL. A largura de banda adicional torna-se importante quando grandes quantidades de dados precisam de circular simultaneamente entre processadores, aceleradores e memória expandida. Um servidor que execute inferência de modelos de grande dimensão, análise de dados ou bases de dados em memória pode ter vários processos a ler e escrever dados ao mesmo tempo. Nessas situações, uma interligação mais lenta pode transformar-se num estrangulamento partilhado, mesmo que exista capacidade de memória suficiente disponível. O CXL 4.0 oferece mais margem para este tipo de tráfego. O CXL Consortium também manteve a estrutura de transferências de tamanho fixo e a proteção contra erros desenvolvidas para a geração de 64 GT/s, permitindo aumentar a velocidade sem aceitar simplesmente um crescimento proporcional da latência do protocolo.
O CXL 4.0 também introduz bundled ports. De forma simples, várias ligações físicas CXL podem ser tratadas como uma única ligação lógica quando o dispositivo e o host suportam esta configuração. Isto é útil quando uma única ligação não consegue fornecer largura de banda suficiente para um acelerador de alto desempenho ou outro componente exigente. Em vez de obrigar o restante sistema a considerar cada ligação como um caminho totalmente separado, os bundled ports fornecem um método definido para as agregar. A especificação também suporta ligações nativas x2, que podem ajudar os fabricantes a ligar um número maior de dispositivos quando não é necessária largura de banda máxima em todas as ligações, e permite até quatro retimers para aumentar o alcance do canal. Estas alterações são relevantes para servidores densos e configurações em rack, onde os componentes nem sempre podem estar fisicamente junto do processador. Oferecem mais opções para equilibrar largura da ligação, número de dispositivos, distância e largura de banda.
A fiabilidade é igualmente importante quando a memória passa a estar fora da motherboard. A falha de um DIMM convencional afeta normalmente um único servidor, enquanto a memória partilhada ou em pool pode suportar várias máquinas ou cargas de trabalho importantes. Por isso, o CXL 4.0 inclui capacidades adicionais de fiabilidade, disponibilidade e manutenção da memória, destinadas a melhorar a visibilidade de erros e as operações de manutenção. Isto não elimina as falhas, e os operadores continuam a precisar de redundância, monitorização e uma distribuição adequada das cargas de trabalho. No entanto, torna a memória CXL de grande capacidade mais fácil de gerir como parte da infraestrutura, em vez de a tratar como um periférico pouco comum. A compatibilidade retroativa total é outra consideração prática. Os sistemas CXL 4.0 foram concebidos para funcionar com gerações anteriores do CXL sempre que exista suporte, pelo que as organizações não precisam de substituir toda a infraestrutura CXL de uma só vez. Isto é relevante em 2026, porque o setor está simultaneamente a implementar equipamento CXL 2.0 e 3.x e a iniciar o desenvolvimento e validação de hardware CXL 4.0 a 128 GT/s.
Memory pooling: da memória fixa do servidor à capacidade partilhada
O memory pooling é anterior ao CXL 4.0. A funcionalidade foi introduzida com o CXL 2.0, juntamente com switching e um modelo normalizado de Fabric Manager. O CXL 3.0 ampliou posteriormente este conceito através de fabrics de maiores dimensões, switching multinível e partilha coerente de memória. Esta distinção é importante. Memory pooling significa que uma determinada quantidade de memória ligada através de CXL pode ser atribuída a diferentes hosts à medida que a procura muda. Uma parte atribuída a um servidor pode posteriormente ser libertada e atribuída a outro. A partilha de memória vai mais longe, permitindo que regiões de memória compatíveis fiquem disponíveis para mais do que um host, enquanto os mecanismos de coerência mantêm uma visão consistente dos dados. O CXL 4.0 mantém estas capacidades e acrescenta uma largura de banda significativamente superior ao fabric. O resultado prático não é uma nova forma de pooling inventada em 2026, mas uma interligação mais rápida que torna os modelos existentes de pooling e partilha mais interessantes para sistemas de maiores dimensões e cargas de trabalho mais pesadas.
Um exemplo simples mostra por que motivo isto é importante. Imagine vários servidores cloud, cada um com DRAM local suficiente para a operação normal, ligados a um banco adicional de memória CXL. Um desses servidores pode subitamente precisar de várias centenas de gigabytes adicionais para análise de dados, um serviço de inferência de IA ou uma base de dados de grande dimensão. Em vez de exigir que essa capacidade esteja instalada permanentemente nessa máquina específica, uma parte do pool CXL pode ser-lhe atribuída. Quando a procura diminui, a capacidade pode regressar ao pool e tornar-se disponível para outro sistema. Um Fabric Manager coordena os recursos relevantes, enquanto o sistema operativo e o software de orquestração determinam como a memória adicional deve ser utilizada. A implementação exata varia entre fabricantes e continua a existir um custo de latência em comparação com a DRAM local, mas a lógica económica é simples: memória que, de outra forma, permaneceria sem utilização atrás de um CPU pode tornar-se capacidade disponível para outras cargas de trabalho.
Esta abordagem procura resolver o problema conhecido como stranded memory, ou memória subutilizada e presa a um determinado servidor. Os servidores cloud são frequentemente configurados para necessidades máximas e não para necessidades médias, porque ficar sem memória pode degradar significativamente uma carga de trabalho ou impedir a sua execução. Como consequência, um servidor pode ter DRAM livre exatamente no mesmo momento em que outro sistema próximo não dispõe de capacidade suficiente. O pooling reduz a necessidade de cada máquina manter a mesma grande margem de segurança. Também pode tornar as atualizações menos disruptivas, porque a memória adicional pode ser instalada num subsistema CXL partilhado em vez de ser adicionada apenas aos canais de memória locais do processador. A viabilidade económica continua a depender do comportamento das cargas de trabalho, custos dos switches, consumo energético, suporte de software e diferença de desempenho entre memória local e memória ligada através de CXL. Por isso, o CXL deve ser encarado como mais um nível na hierarquia de memória e não como prova de que a DRAM local deixou de ser necessária. Os sistemas mais eficientes utilizam geralmente vários tipos de memória para diferentes funções.
Porque é que a inferência de IA beneficia de memória em pool e em vários níveis
A inferência de IA é uma das razões mais claras para o crescente interesse pela memória CXL em 2026. Servir grandes modelos de linguagem envolve muito mais do que armazenar os pesos do modelo. Cada pedido ativo também pode exigir estado temporário, incluindo a cache key-value utilizada por modelos transformer para evitar voltar a calcular informação de atenção já processada. À medida que as janelas de contexto aumentam e os servidores passam a processar mais utilizadores ou agentes de IA em simultâneo, essa cache pode ocupar uma quantidade considerável de memória. Manter todos esses dados na HBM cara do acelerador pode limitar o número de sessões que um servidor consegue processar, mesmo quando o GPU ainda possui capacidade computacional disponível. Transferir todo o excesso de dados para SSDs, por outro lado, pode introduzir atrasos de acesso muito superiores. A memória CXL oferece um nível intermédio no qual determinada informação pode continuar a ser diretamente endereçável como memória sem ocupar a capacidade local mais valiosa do acelerador.
Isto não significa que um operador de IA deva simplesmente mover um modelo inteiro da HBM para memória CXL. Os dados utilizados com maior frequência continuam a beneficiar de estar o mais próximo possível do acelerador, e a largura de banda fornecida pela HBM é consideravelmente superior à de uma camada externa de memória CXL. Uma configuração mais realista mantém os dados do modelo sensíveis à latência na HBM, conserva dados de trabalho adequados na DRAM local do sistema e utiliza capacidade CXL para informação que precisa de permanecer rapidamente disponível, mas não necessita da máxima largura de banda local em todos os momentos. O tiering e offload da KV cache são exemplos importantes discutidos pela indústria CXL em 2026. Quando o software consegue identificar que dados devem permanecer em cada nível, o servidor pode suportar contextos maiores ou mais pedidos de inferência em simultâneo sem aumentar na mesma proporção a quantidade de memória cara do acelerador. O benefício está, portanto, na eficiência da capacidade, e não na ideia de que o CXL seja inerentemente mais rápido do que a HBM.
O mesmo princípio aplica-se para além dos grandes modelos de linguagem. Sistemas de recomendação podem manter tabelas de embeddings de enorme dimensão, tarefas de processamento de dados podem trabalhar com conjuntos de dados maiores do que a DRAM local, e a inferência baseada em CPU pode exigir mais memória do que seria economicamente viável instalar num servidor convencional. O CXL pode ampliar a memória utilizável para estas cargas de trabalho, mantendo uma forma de acesso normal à memória. O pooling acrescenta outro nível de flexibilidade, porque a capacidade pode acompanhar a procura em vez de permanecer permanentemente dedicada a uma única máquina. Isto é particularmente interessante em infraestruturas de IA partilhadas, onde diferentes serviços atingem picos de procura em momentos diferentes. Um trabalho em lote pode precisar de muita memória durante a noite, enquanto um serviço de inferência pode necessitar da mesma capacidade durante o horário laboral. A atribuição dinâmica não elimina todas as limitações operacionais, e mover capacidade entre hosts continua a exigir gestão por parte do sistema operativo e do software de infraestrutura, mas oferece aos operadores mais opções do que um servidor com memória totalmente fixa.
Como o CXL 4.0 altera o design dos servidores e a economia da cloud
A mudança de longo prazo introduzida pelo CXL é arquitetónica e não apenas numérica. Os servidores tradicionais são concebidos em torno de recursos que pertencem a uma única máquina: os seus processadores, DIMMs e aceleradores são instalados nesse servidor e permanecem associados a ele mesmo quando têm pouca utilização. O CXL permite que alguns desses recursos, sobretudo a memória, sejam tratados de forma mais independente. Um rack pode conter servidores convencionais ao lado de switches CXL, dispositivos de expansão de memória e sistemas de memória em pool, com capacidade atribuída de acordo com as necessidades de cada carga de trabalho. O CXL 3.x já disponibiliza grande parte do comportamento de fabric necessário para este modelo. O CXL 4.0 acrescenta uma largura de banda de ligação significativamente superior e novas opções de conectividade, importantes à medida que aumentam o número de dispositivos e o volume de tráfego. Isto não transforma um rack num único computador, mas reduz a dependência da ideia de que cada byte útil de memória precisa de estar fisicamente instalado junto do CPU que irá utilizá-lo.
Para fornecedores de cloud, o benefício financeiro mais evidente é a possibilidade de melhorar a utilização da memória. A DRAM representa uma parte significativa do custo e do consumo energético de servidores com grandes requisitos de memória. Se cada servidor for equipado para picos raros de procura, grande parte desse investimento pode produzir pouco trabalho útil durante o funcionamento normal. Um pool de memória partilhado pode permitir aos operadores adquirir capacidade para a procura agregada em vez de instalar em cada máquina memória suficiente para o seu máximo teórico individual. A poupança não é automática. Switches CXL, controladores, equipamentos de memória e software de gestão também têm custos e consomem energia, enquanto cargas de trabalho que exigem latência de memória consistentemente baixa podem continuar a justificar grandes quantidades de DRAM local. O melhor caso económico surge, portanto, onde a procura de memória varia bastante entre hosts, onde os limites de capacidade são mais importantes do que a latência mínima ou onde memória adicional permite manter processadores e aceleradores caros produtivos, evitando esperar que os dados sejam transferidos do armazenamento.
A flexibilidade operacional pode revelar-se tão importante como o custo do hardware. Um serviço cloud pode mudar significativamente durante a vida útil de um servidor. Os modelos de IA tornam-se maiores, as bases de dados crescem e os clientes migram entre diferentes tipos de instância. Num servidor com memória fixa, um aumento de capacidade pode obrigar a mover a carga de trabalho ou substituir o hardware. A expansão e o pooling através de CXL criam a possibilidade de alterar a memória disponível sem reconstruir o nó de computação. Também podem permitir configurações de servidor mais especializadas: algumas máquinas podem incluir grande capacidade de memória local, enquanto outras dependem mais fortemente de capacidade partilhada para cargas de trabalho que toleram latência adicional. A fiabilidade e a segurança continuam a ser essenciais neste modelo. A memória deve ser reatribuída de forma segura, as falhas devem ser isoladas e a informação pertencente a uma carga de trabalho não pode tornar-se visível para outra. À medida que o CXL evolui para utilização multi-host e à escala de rack, estes requisitos de gestão tornam-se parte integrante do design.
O que esperar das implementações CXL depois de 2026
A realidade mais importante em 2026 é que a existência de uma especificação CXL 4.0 publicada não significa que o hardware CXL a 128 GT/s já seja universal nos centros de dados em produção. Os sistemas comerciais e de demonstração atuais abrangem várias gerações. O módulo de memória CXL MD220 da Samsung, por exemplo, utiliza CXL 2.0 através de PCIe 5.0 e está disponível em capacidades de 128 GB e 256 GB, enquanto o sistema CMM-B da Samsung, destinado a memory pooling ao nível do rack, também utiliza tecnologia CXL 1.1 e 2.0. A SK hynix continuava a demonstrar soluções CMM-DDR5 de classe CXL 2.0 durante 2026, enquanto eventos do CXL Consortium realizados ao longo do ano incluíram ligações e controladores CXL 3.2 em funcionamento. Ao mesmo tempo, fornecedores de tecnologia para desenvolvimento de semicondutores já disponibilizam controladores CXL 4.0, soluções de segurança e ferramentas de verificação destinadas a chips preparados para operar a 128 GT/s. Por outras palavras, a transição está em curso, mas os produtos maduros atuais e os futuros sistemas CXL 4.0 coexistem.
Esta adoção gradual é normal para uma interligação destinada a servidores. Depois de uma especificação ser publicada, ainda são necessários controladores, switches, retimers, processadores, dispositivos de memória, firmware, suporte do sistema operativo, testes de conformidade e validação da interoperabilidade entre diferentes fabricantes antes de grandes operadores poderem utilizá-la com confiança. O CXL 4.0 tem uma vantagem porque mantém a arquitetura das versões anteriores e continua a ser retrocompatível, permitindo aos fabricantes aproveitar software e experiência de desenvolvimento já existentes. O primeiro motivo para o adotar não será necessariamente a necessidade do valor de 128 GT/s por si só. Os operadores estarão mais interessados em saber se a largura de banda adicional permite utilizar mais dispositivos de memória, processar mais tráfego simultâneo ou suportar maior atividade de aceleradores sem criar um estrangulamento. À medida que os fabrics CXL evoluem de simples expansão de memória para recursos em pool e partilhados à escala do rack, a largura de banda adicional torna-se cada vez mais útil porque mais cargas de trabalho competem pela mesma capacidade de interligação.
Para infraestruturas de IA e cloud, o CXL 4.0 deve, portanto, ser visto como parte de uma transformação mais ampla no design da memória, e não apenas como uma atualização de velocidade entre gerações. A memória DDR local continuará a disponibilizar memória relativamente rápida para CPUs, a HBM continuará a servir aceleradores que necessitam de largura de banda extrema e os SSDs continuarão a oferecer capacidade persistente com custos mais baixos. O CXL acrescenta uma camada flexível entre estes recursos, permitindo que servidores acedam a pools maiores de memória coerente e que a capacidade seja atribuída com menos limitações físicas. A geração de 128 GT/s oferece a essa camada mais espaço para crescer. A curto prazo, muitos sistemas em produção continuarão a utilizar CXL 2.0 ou 3.x enquanto os novos chips avançam para CXL 4.0. Nas gerações seguintes de servidores, a mudança mais importante deverá ser deixar de perguntar quanta memória está instalada numa única máquina e passar a perguntar quanta memória adequada pode ser disponibilizada a uma carga de trabalho exatamente quando ela necessita.
