Meta unveils liquid cooled AI switches and open networking plans
A network switch in a photo published in 2018, shown as an illustration of networking infrastructure. Photo by Jonathan on Unsplash. Unsplash License.
Meta introduced new AI networking hardware and outlined open switch infrastructure at the Open Compute Project summit on October 12. Its announcement combines higher bandwidth equipment with changes to how large accelerator clusters connect.
IcePack is the company’s first liquid cooled network rack. Its IceCube switch blades provide 102.4 terabits per second of capacity through 128 connections rated at 800 gigabits per second. Two variants use Broadcom and NVIDIA chips and run FBOSS, Meta’s network operating software.
Meta also describes Flattened Planar Fabric, which spreads each GPU’s connections across eight independent network planes. Its next generation design for 72 accelerators per rack remains a preview.
The less visible work beneath a switch
The Open Switch Platform Architecture effort addresses a different problem. Manufacturers can use similar networking chips while exposing different ways to manage the surrounding hardware. OCP says the initiative, started by Meta, Microsoft and Alibaba, aims to reduce duplicated engineering when operators bring new switches into service.
OCP describes revision 1.0.0 as a candidate under Foundation review. Its scope covers power, sensors, inventory, firmware and diagnostics. Routing protocols and packet forwarding sit outside that scope, so this is a proposed common management foundation rather than a replacement for the entire networking stack.
The architecture concentrates routine management on the main host processor. A separate baseboard management controller retains essential supervisory and recovery responsibilities. Standardized hardware discovery and peripheral access are intended to make that division usable across equipment from different suppliers.
What the specification still leaves unfinished
The actual specification also clarifies the timeline. Its version history dates the initial draft to August 6 and revision 1.0.0 to September 13. The October announcement therefore brings earlier design work to the summit, rather than establishing when that work first began.
Its operational detail is concrete. Leak detection should keep working if either management processor stops responding. A major leak should shut down the host hardware automatically while leaving the supervisory controller powered to record the incident. The document also calls for ways to simulate leaks and test the response.
For critical firmware, the design requires redundant images and alternative recovery paths. A controller should still be able to recover a host that cannot boot. Those provisions address failures that a switch bandwidth specification alone cannot describe.
There is an important unfinished section. Comprehensive security requirements are deferred to subsequent revisions. That limits how far readers should treat the current document as a complete production blueprint.
Transport plans build on earlier work
The transport discussion also has a history. In its August 24 explanation of MetaRoCE, Meta described moving traffic management toward network endpoints, allowing packets to travel over multiple paths and arrive out of order. The intended result is a transport that can adapt to congestion and packet loss while serving distributed AI workloads.
That earlier publication already set out plans to release a specification, reference implementation and compliance framework at the October summit. The transport research should therefore be understood as background to this week’s announcement, rather than a protocol first revealed now.
What this means for operators
Our assessment is that the useful change spans two different buying decisions. Network capacity determines how much communication equipment can carry. A common management design determines how much custom integration an operator may need to keep that equipment healthy. Progress on either can matter, but a faster switch does not automatically make the surrounding software easier to maintain.
Teams evaluating the announcement should ask suppliers which interfaces they implement, how failure recovery is tested and which requirements remain unsettled. They should also distinguish a submitted specification from an approved standard and a future rack preview from deployable equipment. The material provides an engineering direction, not a measured improvement for every AI training job.
