Astera Labs Releases Leo 2 CXL Memory Controllers and Leo X Controller for Rackscale Fabric-Attached Memory

Skyler: Welcome to Line Rate — the show about datacenter fabric and A I high-speed interconnect. I'm Skyler Monroe, and if it moves bits between accelerators, across racks, or between datacenters at ludicrous speed, this is where we talk about it. Huge thanks to our sponsors Ada, who helps clients integrate A I into their workflows, and Zen Semiconductor, an umbrella company with a portfolio of companies across the silicon industry. Alright — today we've got Astera Labs dropping a next-gen CXL memory controller that wants to plug memory directly into your A I fabric, Nvidia quietly stacking up Spectrum Ethernet wins at Oracle and Meta, Arista making a big modular switch play, and we'll break down co-packaged optics and why the market around it is absolutely exploding. Let's get into it. Skyler: First up — Astera Labs. If you've been watching the CXL space, you know Astera has been one of the more interesting companies to track. They're not building CPUs or GPUs — they're building the smart glue between memory and compute, and this week they dropped two new products that push that strategy significantly further. We've got Leo 2 and Leo X. Skyler: Let's start with Leo 2, because it's the more immediately deployable of the two. Leo 2 is their next-generation smart memory controller with support for CXL 3.2 and PCIe Gen 6. If you're thinking "wasn't CXL 3.1 just getting traction?" — yeah, you're not wrong. The spec versions have been moving fast. But CXL 3.2 is important because it brings tighter memory pooling and sharing semantics, better coherency across more endpoints, and when you pair that with PCIe Gen 6 bandwidth — we're talking up to 128 gigatransfers per second per lane direction — the memory expansion use case starts to feel a lot less like a workaround and a lot more like a real system architecture. Skyler: The key thing Leo 2 enables is fabric-attached memory pooling. You can attach DDR5 DIMMs behind a Leo 2 controller, and hosts — whether that's CPUs or eventually other agents — can address that memory over CXL as if it's local. That's the pitch. The latency isn't as low as local DRAM, obviously, but for workloads that are bandwidth-hungry rather than latency-critical, or for cases where you're capacity-constrained and need to burst into pooled memory, this is genuinely useful. Think inference serving, large model parameter storage, that kind of thing. Skyler: Now Leo X is where things get really interesting, and honestly a little ambitious. Leo X is designed to connect memory expanders directly to the fabric networks used by A I accelerators. Not just CXL over PCIe to a host CPU — we're talking about attaching memory into the broader rack-scale fabric topology that your GPUs or other accelerators are actually using for their high-bandwidth, low-latency communication. Skyler: The implication here is significant. Right now, if a GPU needs memory it doesn't have locally, it either goes off-chip to HBM, or it goes back through the host CPU's memory subsystem, or it does expensive all-to-all transfers across NVLink or Ethernet to pull data from another GPU's memory space. None of those are great. What Leo X is pitching is a path where memory is a first-class citizen on the A I fabric — directly addressable, directly accessible, not mediated by a CPU hop. Skyler: That positions Astera in a really interesting spot competitively. They're not competing with Nvidia on the GPU side, they're not competing with Broadcom on the switch side — they're trying to become the memory fabric layer that everyone needs regardless of which accelerator wins. It's a smart lane to be in, though the success of Leo X specifically will depend heavily on which fabric interconnects it actually integrates with and gets validated on. Watch for ecosystem announcements — that's the tell. Skyler: CXL 3.2 and PCIe Gen 6 aren't widely deployed yet, so Leo 2 is somewhat ahead of the curve. But that's intentional — system builders need controller silicon ready before they can validate platforms, and Astera is positioning itself to be designed into the next wave of memory-expanded servers before the volume ramp hits. Skyler: Alright, next — Nvidia and Spectrum Ethernet. So this is interesting because it touches on one of the ongoing narratives in A I networking: can standard Ethernet really hold its own as the preferred scale-out fabric for large A I clusters, or does proprietary always win? Skyler: The news is that Nvidia has landed significant Spectrum Ethernet wins at both Oracle and Meta. Spectrum-X is Nvidia's Ethernet-based networking platform — it's not InfiniBand, but it's also not vanilla Ethernet. It's Ethernet with a bunch of Nvidia-specific sauce on top, including their RoCE optimizations, congestion control, and end-to-end telemetry built around what works well for GPU-to-GPU A I traffic patterns. Skyler: Oracle and Meta are not small wins. Oracle Cloud is building out serious A I infrastructure — their H100 and H200 GPU clusters are becoming a meaningful part of the market, and the choice of networking fabric at that scale matters a lot. Meta, meanwhile, has been one of the most vocal and sophisticated builders of custom A I infrastructure on the planet. They've invested heavily in open ecosystems — they're a founding member of the Ultra Ethernet Consortium — so seeing them adopt Spectrum-X alongside their other work is a nuanced signal. Skyler: What does this mean competitively? Well, the obvious comparison is InfiniBand versus Ethernet for A I clusters. Nvidia has been quietly trying to de-emphasize that binary choice, because they sell both. Spectrum-X lets them offer Ethernet to customers who have Ethernet operations teams, Ethernet automation tooling, and Ethernet vendor relationships — while still delivering A I-optimized performance. It's a smart play. Skyler: The Ultra Ethernet Consortium — U E C — is the industry's attempt to bake A I traffic optimizations into standard Ethernet specifications without locking anyone to Nvidia's stack. It includes AMD, Intel, Broadcom, Arista, Microsoft, Meta, and others. U E C specs are still evolving — the working groups are active but we're not seeing broad silicon at scale yet. So in the interim, Spectrum-X is able to land deals because it exists now, it works now, and it's validated on Nvidia GPUs, which are what most people are actually buying. Skyler: The risk for Nvidia is that U E C matures and customers who care about vendor independence migrate toward compliant solutions. The risk for U E C is that by the time it's fully baked, Spectrum-X has enough installed base and operational familiarity that switching costs are real. This is a classic standards race dynamic, and we're right in the middle of it. Skyler: For architects building or planning large A I clusters today — if you're going Ethernet and you're on Nvidia GPUs, Spectrum-X is the pragmatic near-term answer. If you're planning for a two to three year horizon and you want optionality, watch U E C very closely. The gap is closing. Skyler: Okay, moving on — Arista. The Next Platform had a piece on Arista's new modular switch approach, and there's a lot to unpack here. Arista has historically been the networking vendor that data center teams genuinely like — good software, solid operations, real automation. But the A I era is putting pressure on everyone to go bigger, faster, and more flexible. Skyler: The modular switch play here is about both scale-up and scale-out. Scale-up is your classic chassis world — you want a big, dense, high-radix switch where you can slot in line cards and grow capacity in a single box. Scale-out is your spine-leaf, fat-tree fabric world — lots of fixed-form switches interconnected into a larger topology. Arista is pitching that their new modular platform spans both needs, which is not a trivial engineering claim. Skyler: For A I fabric specifically, the requirements are demanding. You need massive port density — we're talking 400 gig, 800 gig, and increasingly 1.6 terabit interfaces. You need very low and consistent latency because GPU collective operations — your all-reduces, your all-to-alls — are extremely sensitive to tail latency and jitter. And you need rich telemetry and congestion management because A I traffic patterns are bursty in ways that traditional web traffic isn't. Skyler: Arista has been evolving their EOS operating system to handle these A I-specific requirements, and their modular chassis gives them a path to very high port counts in a single logical switch. In a large-scale GPU cluster, reducing the number of tiers in your network — going from a three-tier topology to effectively a two-tier one — cuts latency and simplifies operations. A very high-radix modular switch is one way to get there. Skyler: The competitive landscape here includes Nvidia Spectrum on one side, Broadcom-based merchant silicon switches from various vendors, Juniper, Cisco, and increasingly custom silicon plays from the hyperscalers themselves. Arista's differentiation is software and operational maturity — they're betting that operators who already know EOS, already have automation built around Arista APIs, will prefer to extend that investment into A I networking rather than start fresh with a new vendor. Skyler: It's a credible bet. Not every A I cluster is being built by a team that wants to manage custom silicon and bespoke software stacks. There's a large market of enterprises and cloud providers who want proven, operable networking — and Arista is well positioned to serve that. Skyler: Alright, let's talk optics — specifically co-packaged optics, because we've got two items here and they're worth spending time on together. There was a market size report on optical interconnect in A I datacenters, and Network World did an explainer on what co-packaged optics actually is. Let me give you the version that's worth your time. Skyler: The fundamental problem driving this technology is bandwidth density and power. As we move to 800 gig and 1.6 terabit per second per port speeds — which the A I era demands — pluggable optical transceivers start running into walls. Getting high-speed electrical signals from a switch ASIC out to a pluggable module at the faceplate of the switch requires driving signals across traces on a PCB, through connectors, and into the transceiver. At 112 gigabaud and beyond, the signal integrity challenges on that path are severe. The insertion loss eats your power budget. You need re-timers and DSPs that themselves consume power and add latency. Skyler: Co-packaged optics — CPO — solves this by moving the optical engines physically close to the switch ASIC. Instead of driving electrical signals across a PCB to a faceplate, the optics are co-packaged with the switch die — either in the same package, on the same substrate, or mounted directly adjacent. The electrical path from ASIC to optical engine is millimeters instead of tens of centimeters. That dramatically reduces signal integrity loss, cuts power consumption, and enables higher aggregate bandwidth per switch. Skyler: The numbers being thrown around in the market reports are significant. We're talking about the optical interconnect market in A I datacenters growing to multiple tens of billions of dollars over the next five to seven years. The A I buildout is the forcing function — when you're connecting hundreds of thousands of GPUs, the aggregate bandwidth requirements are staggering, and optics is the only technology that can deliver that bandwidth at scale across rack boundaries. Skyler: The key players in CPO are a mix of switch ASIC vendors and optical component companies. Broadcom has been working on CPO integration with their Tomahawk and Bailly series chips. Intel has Bare Metal optics efforts. Companies like Marvell are deeply involved on both the silicon and optical DSP side. And then there's a whole ecosystem of optical component suppliers — Coherent, II-VI, Lumentum — who make the actual photonic components that go into these packages. Skyler: The standards side is worth mentioning too. The Co-Packaged Optics Alliance and the Optical Internetworking Forum have been working on interoperability specs, because one of the fears with CPO is vendor lock-in. If your optics are literally co-packaged with your switch ASIC, you can't just swap in a different transceiver from a different vendor the way you could with pluggables. Getting to open, interoperable CPO interfaces is critical for the ecosystem to mature. Skyler: We're still early. Most production deployments today are still using pluggable optics — QSFP-DD, OSFP, and similar form factors. But the trajectory is clear. As port speeds hit 1.6 terabit and beyond, CPO becomes increasingly necessary rather than optional. The question is timeline and ecosystem maturity — which is the same question it's been for a few years, but the A I buildout is compressing that timeline fast. Skyler: If you're a datacenter architect planning infrastructure for 2026 and beyond, CPO needs to be in your technology roadmap conversations now. Not necessarily deployed now — but understood and planned for. Skyler: Alright, that's the rundown for today. CXL memory moving into the A I fabric itself with Astera's Leo X, Nvidia stacking Spectrum Ethernet wins while U E C continues to mature, Arista betting on modular scale for the operators who want proven software, and co-packaged optics on a trajectory to become unavoidable as port speeds keep climbing. A lot moving at once — which honestly is just Tuesday in this industry. Skyler: Thanks for listening to Line Rate, brought to you by Ada and Zen Semiconductor. Ada helps clients integrate A I into their workflows — if that's relevant to your team, they're worth a conversation. And Zen Semiconductor is an umbrella company with a portfolio of companies across the silicon industry, including Ada. If you got value from today's episode, please subscribe wherever you get your podcasts, leave a review if you have a minute, and share it with a colleague who's trying to keep up with this space. Full show notes with sources and links are at the Line Rate website. I'll see you next time.