Сеть инференса LLM нового поколения: как ZCube снимает сетевые bottleneck

Оригинал: пост Z.ai в X.

LLM-инференс меняет AI-инфраструктуру. Раньше сеть была наименее интересной частью inference-кластера. Теперь это уже не так. С long-context inference и ставшей стандартом Prefill-Decode disaggregation сеть оказывается на критическом пути throughput, tail latency и стоимости обслуживания одного токена.

Чтобы решить всё более острую проблему congestion, вызванную топологией в Prefill-Decode-disaggregated deployments, Z.ai, Harnets.AI и Tsinghua University совместно разработали и развернули сетевую архитектуру ZCube в production-среде. Развёртывание показывает: системные инновации на уровне сетевой архитектуры могут раскрывать потенциал железа очень cost-effective способом.

В production benchmark для coding workload GLM-5.1 ZCube дала значительный прирост только за счёт архитектурной оптимизации:

• Оптимизация стоимости: GPU, software stack и приложения остались неизменными, при этом CapEx на коммутаторы и optical modules сократился на 33%.
• Рост throughput: средняя производительность GPU inference выросла на 15%.
• Улучшение latency: TTFT P99 снизился на 40,6%.

Корневая причина congestion лежит в изменении traffic patterns инференса. По мере того как PD disaggregation становится mainstream, cross-node KV Cache transfers делают inference traffic крайне асимметричным: источники, назначения и объёмы трафика динамически меняются. В традиционных ROFT — Rail-Optimized Fat-Tree — архитектурах статическая топология и port mappings легко концентрируют трафик на ограниченном наборе коммутаторов и links, вызывая локальные hotspots, queue buildup и PFC backpressure. Это приводит к структурной проблеме: aggregate bandwidth выглядит достаточной, но локальные congestion происходят часто.

ZCube решает эту проблему за счёт полностью flattened network topology вместе с гибридным single-rail / multi-rail access design. На уровне сетевой архитектуры она decouples и распределяет PD traffic по более широкому пространству путей, снижая вероятность topology-induced congestion в самом источнике. Это даёт более эффективную сетевую основу для hyperscale inference-кластеров следующего поколения.

Сеть становится bottleneck для эффективного inference

Когда тысячи GPU одновременно обслуживают online inference requests, каждый KV Cache transfer и каждая операция data synchronization проходят через inter-GPU network. По мере того как long-context inference и Prefill-Decode-disaggregated inference постепенно становятся mainstream, data exchange между Prefill- и Decode-узлами продолжает расти. Network bandwidth — и, что важнее, способность эффективно её использовать — начинает напрямую влиять на cluster-level throughput и latency.

Чтобы количественно оценить влияние сети на inference performance, мы сначала провели ablation study на кластере из 512 GPU. Мы оставили GPU compute, software stack, model и application logic неизменными и меняли только доступный NIC bandwidth cap. Затем измеряли изменения overall cluster throughput и Time to First Token — TTFT.

Например, когда network bandwidth увеличили со 100 Gbps до 200 Gbps, overall inference throughput вырос примерно на 19%, а Time to First Token, или TTFT, снизился примерно на 22%. Это показывает, что в LLM inference network bandwidth стала одним из ключевых факторов, ограничивающих service performance.

1. Network congestion в inference

Сегодня AI-кластеры обычно используют Clos, или Fat-Tree, архитектуры. Базовая идея — масштабировать сеть через несколько уровней коммутаторов. Однако performance Clos-сетей сильно зависит от идеального load balancing между switches, чего трудно добиться на практике из-за routing policies и реальных traffic patterns.

Например, во многих two-tier Fat-Tree deployments, состоящих из Spine- и Leaf-уровней, трафик между Spine switches может становиться сильно несбалансированным. В результате upper-layer applications часто не получают ожидаемую network performance.

Чтобы снизить overhead cross-layer forwarding, индустрия часто применяет ROFT — Rail-Optimized Fat-Tree — архитектуры [1]. Как показано на Figure 3, ROFT группирует GPU по индексу, или «rail», и подключает GPU с одинаковым индексом к одному Leaf switch, снижая communication cost через Spine switches.

ROFT хорошо работает для некоторых training traffic patterns. Однако в Prefill-Decode-disaggregated inference мы наблюдали более заметную проблему: KV Cache transfers демонстрируют сильную source-destination asymmetry. Разные GPU и разные NIC несут крайне неравномерную communication load, как показано на Figure 4. В результате rail mapping в ROFT больше не превращается естественным образом в load balancing. Наоборот, трафик может концентрироваться на небольшом числе Leaf switches и links, приводя к link congestion и ухудшению transfer performance.

Это проявляется несколькими способами:

• Некоторые Leaf switches становятся устойчивыми load hotspots, повышая вероятность того, что несколько KV Cache transfer flows конкурируют за одни и те же links. В результате фактический transfer throughput может падать намного ниже NIC bandwidth capacity.
• Некоторые egress queues на отдельных Leaf switches долго остаются на высокой глубине и часто запускают PFC backpressure, как показано на Figure 5.
• Link congestion дополнительно усиливает tail latency, влияя и на TTFT, и на overall throughput.

Важно различать два типа network congestion, как показано на Figure 6:

• Неизбежный congestion: например, когда несколько GPU одновременно отправляют данные в одно и то же назначение, contention на final-hop link неизбежен.
• Избежный congestion: он вызван topology design, traffic mapping или несбалансированным multipath utilization. По сути, это architecture-level design problem.

Для первого типа congestion обычно используют congestion control, traffic shaping и связанные механизмы, чтобы снизить impact. Для второго типа могут помочь новые network transport mechanisms, такие как adaptive routing [2], packet spraying [3,4] и MRC [5]. Однако более эффективный подход — предотвращать сетевые конфликты, которых вообще не должно возникать, через инновации на уровне сетевой архитектуры.

Prefill-Decode-disaggregated inference — типичный пример. Если network topology не соответствует traffic pattern, система будет снова и снова порождать load hotspots и link conflicts. Чтобы решить это, нужно переосмыслить саму inference network architecture.

2. Сетевая архитектура ZCube

Чтобы решить описанные выше проблемы, мы развернули новую сетевую архитектуру ZCube [6]. ZCube отходит от традиционной Clos-философии hierarchical switch stacking и вместо этого вводит fully flattened GPU server interconnect.

ZCube routing strategy, разработанная специально для архитектуры ZCube, полностью использует структурные свойства flattened topology. Она может достигать почти идеального load balancing между всеми switches в сети, тем самым значительно повышая overall cluster network bandwidth.

По сравнению с Clos, ZCube имеет естественное преимущество в load balancing. Это преимущество полезно и для training clusters, и для inference clusters. Важно, что ZCube достигает этих performance gains, одновременно снижая cost switches и optical modules примерно на треть по сравнению с Clos. На базе современных mainstream switch и NIC configurations ZCube может поддерживать flattened networking для десятков тысяч и даже сотен тысяч GPU.

2.1 Core architecture ZCube

Как показано на Figure 7, основные идеи ZCube:

1. Удалить Spine switch layer.
2. Разделить Leaf switches на две группы одинакового размера — обычно odd-numbered и even-numbered switches.
3. Создать complete bipartite interconnect между двумя группами switches.
4. Подключить два порта каждого GPU NIC к соответствующим switches в двух группах, используя single-rail и multi-rail access patterns.

Предположим, что у каждого GPU есть соответствующий NIC с двумя портами, то есть p = 2. Всего есть n GPU, и GPU и NIC имеют одинаковые индексы: 1, 2, …, n. Пусть k обозначает число GPU, подключённых к каждому switch. Общее число switches равно 2n/k, они пронумерованы 1, 2, …, 2n/k. Для GPU i, где 1 ≤ i ≤ n:

• Первый порт подключается к odd-numbered switch:
  ((i−1) mod (n/k)) × 2 + 1
• Второй порт подключается к even-numbered switch:
  ⌈i/k⌉ × 2

Две группы switches соединены как complete bipartite graph: каждый odd-numbered switch соединяется с каждым even-numbered switch.

ZCube topology при dual-port NIC configuration, с p = 2, n = 32 и k = 8, показана на Figure 7.

2.2 Ключевые свойства ZCube

Network Diameter

ZCube имеет network diameter в два switch hops, то есть любая пара GPU может достичь друг друга через два коммутатора. Это находится между one-layer switch network, где один switch hop, но ограниченный scale, и традиционной two-layer switch network, которая поддерживает больший scale, но обычно требует три switch hops и создаёт большую latency.

Load Balancing

Во-первых, ZCube routing strategy гарантирует, что у каждой пары GPU есть unique optimal path, избегая traffic conflicts, вызванных multipath route selection.

Во-вторых, ZCube использует два complementary GPU-to-switch connection patterns. Одна группа switches подключается к GPU по single-rail pattern, где каждый switch подключается к непрерывному диапазону GPU IDs. Другая группа switches подключается к GPU по multi-rail pattern, где каждый switch подключается к GPU с одинаковым relative index across groups.

Этот дизайн позволяет ZCube достигать очень эффективного load balancing по всей switch fabric как при типичных AI training traffic patterns, таких как AllReduce и All-to-All, так и при типичных AI inference traffic patterns, где source-destination relationships неопределённы, а NIC loads могут быть крайне несбалансированными.

В результате ZCube может предотвращать второй тип network congestion, описанный выше, на уровне архитектуры. Как показано на Figure 8, traffic flows, которые конфликтовали бы при ROFT, получают dedicated network paths в ZCube и тем самым избегают congestion.

Scalability

ZCube обеспечивает сильную scalability, сохраняя благоприятные performance characteristics. Например, используя один слой 51.2T switches, каждый с 128 × 400 Gbps ports, ZCube может построить сеть, соединяющую 16 384 NIC по 400 Gbps. Если использовать switches большей ёмкости или разделить ZCube network на большее число planes, архитектура может масштабироваться дальше — до десятков тысяч и даже сотен тысяч GPU.

Cost

При том же cluster scale ZCube может снизить cost switches и optical modules примерно на треть по сравнению с традиционными Clos / ROFT architectures. Например, в AI-кластере на 10 000 GPU ZCube может сэкономить примерно от 210 млн до 640 млн RMB на network hardware investment. Эти свойства показывают, что ZCube может давать лучший load balancing и performance при меньшей стоимости сетевого железа.

2.3 Тестирование реального кластера: больше inference performance при меньших network costs

Мы обновили сетевую архитектуру thousand-GPU cluster, обслуживающего GLM-5.1 coding inference services, с исходной ROFT до ZCube. Поскольку ZCube architecture устраняет Spine-layer switches, присутствующие в традиционных Clos architectures, legacy cabling patterns, IP addressing schemes, routing policies и switch configuration methods, сформированные в рамках Clos, нельзя было напрямую переиспользовать. Потребовался полный redesign под ZCube.

Чтобы справиться с этими вызовами, Harnets.AI Network Team разработала комплексное network solution вокруг ZCube architecture. Они создали suite automation tools, включая ZCube Controller, data center layout design tool и cabling correctness verification program. Это дало возможности data center deployment planning, cabling validation, automated configuration generation и batch deployment, фактически решив множество сложностей ZCube deployment. Этот набор инструментов стал критическим фактором, позволившим успешно трансформировать large-scale production cluster в исключительно сжатые сроки.

После seamless network architecture migration мы провели real-world testing архитектуры ZCube, запустив GLM-5.1 coding inference services на этом кластере. Сравнив inference performance кластера до и после upgrade, мы обнаружили, что ZCube повысила average GPU inference throughput более чем на 15% по сравнению с ROFT architecture, как показано на Figure 9, одновременно снизив P99 tail latency TTFT на 40,6%.

Итого: при GPU и server hardware того же масштаба и конфигурации, без изменений в приложениях, upgrade сетевой архитектуры до ZCube позволил не только сэкономить 1/3 optical modules и switch hardware, но и дать кластеру возможность обслуживать на 15% больше inference requests в секунду. На фоне взрывного роста inference workloads и серьёзного дефицита compute resources такой подход оказывается крайне практичным и ценным. Сейчас этот ZCube cluster стабильно работает уже более двух недель, играя важную роль в powering GLM-5.1 coding inference services.

3. Заключение

LLM inference движется от point-wise optimization к system-level co-design. Связь между сетью и inference engine становится всё теснее, превращая networking в критический компонент inference system. Production deployment ZCube показывает, что innovation в network architecture может напрямую раскрывать effective capacity inference systems. Лучше согласуя network architecture с KV Cache transfers и PD traffic patterns, ZCube снижает вероятность topology-induced congestion в источнике, улучшая throughput и latency и одновременно повышая cost efficiency кластера.

Если смотреть на next-generation LLM infrastructure, network design будет эволюционировать от general-purpose interconnects к model-traffic-driven system co-design. Long-context inference, PD disaggregation, MoE и integrated training-inference workloads меняют intra-cluster communication patterns, требуя совместной оптимизации network topology, communication libraries и scheduling policies вокруг реального model traffic. В дальнейшем мы продолжим развивать новые AI network architectures для более крупных inference и training clusters — превращая сеть из базового слоя соединения GPU в ключевой драйвер token generation efficiency, system resilience и cost-effectiveness.

Acknowledgements

ZCube была опубликована на ACM SIGCOMM 2025 и получила оценку как работа, которая «significantly change the way we think about and understand networking». Это первое large-scale deployment технологии в production inference cluster. Мы благодарим команду Harnets.AI за профессиональную поддержку и тесное сотрудничество на протяжении всего network architecture upgrade and optimization effort.

References

1. NVIDIA. 2023. SuperPOD: Next Generation Scalable Infrastructure for AI Leadership. https://docs.nvidia.com/https:/docs.nvidia.com/dgx-superpod-reference-architecture-dgx-h100.pdf
2. NVIDIA. 2025. https://developer.nvidia.com/blog/accelerating-ai-storage-by-up-to-48-with-nvidia-spectrum-x-networking-platform-and-partners/
3. Ultra Ethernet Consortium. Ultra Ethernet specification v1.0.1, 2025.
4. Tommaso Bonato, Abdul Kabbani, Ahmad Ghalayini, Michael Papamichael, Mohammad Dohadwala, Lukas Gianinazzi, Mikhail Khalilov, Elias Achermann, Daniele De Sensi, and Torsten Hoefler. REPS: Recycled entropy packet spraying for adaptive load balancing and failure mitigation, 2026.
5. Araujo, J., Chow, A., Handley, M., Lewis, R., Paasch, C., Padhye, J., … & Sur, S. (2026). Resilient AI Supercomputer Networking using MRC and SRv6. arXiv preprint arXiv:2605.04333.
6. Yan, Z., Li, D., Chen, L., Xiong, D., Gao, K., Zhang, Y., … & Lin, H. (2025, September). From ATOP to ZCube: Automated topology optimization pipeline and a highly cost-effective network topology for large model training. In Proceedings of the ACM SIGCOMM 2025 Conference (pp. 861-881).