AI И НЕЙРОСЕТИ

ИИ-обучение выходит за пределы одного дата-центра

Крупные ИИ-кластеры упираются в дефицит электроэнергии: обучение моделей приходится распределять между несколькими дата-центрами.

✍️ Редакция iTech News | 08.10.2026 | ⏱ 4 мин | Источник: The Register
🎓

Крупные ИИ-кластеры упираются не только в количество доступных GPU, но и в электрическую мощность площадки. Поэтому распределённое обучение ИИ начинает выходить за пределы одного дата-центра — а сеть из вспомогательной инфраструктуры превращается в часть вычислительной системы. Для российских команд, строящих или арендующих GPU-мощности, это означает неприятную, но полезную мысль: второй ЦОД не решает проблему сам по себе, если между площадками нет предсказуемой сети.

Об этом в спонсорском интервью Cisco сообщает The Register. Собеседником издания стал Ракеш Чопра, старший вице-президент по архитектуре кремния и систем Cisco и Cisco Fellow. Он называет новую задачу Scale-Across: не просто расширять кластер внутри одной площадки, а заставлять географически разнесённые мощности работать как единая машина.

Причина довольно приземлённая. Обучение больших моделей требует всё больше ускорителей, а вместе с ними — питания, охлаждения и свободного места в дата-центре. Даже компания, способная купить нужное число GPU, может не получить необходимую электрическую мощность в конкретной локации. Распределить серверы по нескольким ЦОД кажется очевидным выходом. Но для синхронного обучения это не похоже на обычное резервирование сервисов между площадками.

Традиционный межцентровый канал рассчитан на передачу трафика между сайтами: репликацию данных, резервное копирование, связь приложений и пользователей. В обучающем кластере GPU регулярно обмениваются большими объёмами данных и ждут друг друга на этапах вычислений. Если один сегмент сети задержался, потерял пакеты или оказался перегружен, простаивать может не отдельный сервер, а вся задача. Дорогие ускорители в этот момент превращаются в очень горячий и очень дорогой способ ждать сеть.

Чопра акцентирует внимание на синхронных всплесках трафика от GPU. Они отличаются от более привычных корпоративных нагрузок тем, что множество узлов одновременно начинают обмен данными. Для такой среды важны минимальные потери пакетов, контролируемая задержка и буферизация, способная сгладить кратковременные пики. Когда узлы разнесены по разным площадкам и соединены протяжёнными оптическими линиями, цена ошибок в проектировании только растёт.

Cisco в интервью продвигает собственные подходы Silicon One и Intelligent Collective Networking. Компания связывает их с управлением коллективными сетевыми операциями, снижением узких мест и сокращением времени выполнения обучающих задач. Это заявления поставщика инфраструктуры, а не опубликованные независимые тесты, поэтому воспринимать их стоит как описание направления, а не как готовый рецепт с гарантированным результатом. Но сама постановка проблемы вполне реальна: сеть для ИИ-кластера всё чаще оценивают не по средней загрузке канала, а по тому, как она ведёт себя во время массового синхронного обмена.

В такой архитектуре возрастает роль высокоскоростной когерентной оптики и маршрутизации, учитывающей особенности нагрузки. Между ЦОД важны не только пропускная способность в гигабитах или терабитах, но и стабильность маршрута, реакция на сбои, очереди и задержки на длинном волокне. Нельзя просто соединить две серверные площадки широким каналом и считать, что получился один кластер: физика расстояния и поведение распределённых алгоритмов быстро испортят эту иллюзию.

Распределённое обучение ИИ меняет и разговор об энергоэффективности. Сеть тоже потребляет электричество, а каждый ватт, потраченный на передачу данных и охлаждение оборудования, конкурирует с ваттами для GPU. При дефиците мощности это уже не второстепенная статья. Инфраструктурным командам придётся считать систему целиком: где находятся ускорители, какой объём межплощадочного обмена создаёт конкретный стек обучения, сколько энергии нужно сети и насколько дешевле масштабировать существующую площадку, чем строить связку из нескольких.

Для разработчиков вывод менее романтичный, но практичный: архитектура модели и стратегия параллелизма оказываются связаны с топологией ЦОД. Чем чаще части задачи должны синхронизироваться, тем болезненнее расстояние между ними. Командам платформенной инженерии и MLOps придётся обсуждать с сетевиками не только доступ к GPU и квоты, но и характеристики межплощадочных соединений, сценарии деградации и правила размещения задач. Для бизнеса это аргумент раньше подключать к планированию ИИ-проектов специалистов по питанию, охлаждению и сети, а не вспоминать о них после закупки ускорителей.

Отдельный слой — безопасность. Cisco упоминает аппаратное ускорение MACsec и IPsec для защиты трафика. В распределённой схеме данные обучения и служебный обмен чаще покидают пределы одного объекта, поэтому шифрование становится частью производственного контура. Однако и здесь есть компромисс: защиту нужно внедрять так, чтобы она не добавляла непредсказуемость и не съедала заметную долю полезной производительности.

Главный вопрос ближайших лет — смогут ли операторы и корпоративные ЦОД сделать несколько площадок достаточно похожими на единый вычислительный комплекс, чтобы выигрыш от дополнительных мощности и энергии не был съеден задержками и сложностью эксплуатации. Пока распределённое обучение ИИ выглядит не заменой локальным сверхкластерам, а вынужденным следующим уровнем инженерии для тех, кому одного дата-центра уже физически мало.

Поделиться: Telegram X LinkedIn