Надёжность линков и мониторинг в AI-фабриках
Задача обучения — синхронное вычисление на тысячах GPU: каждая коллективная операция ждёт самый медленный линк. Один флапающий трансивер не замедляет один сервер на долю — он останавливает всю задачу, а если отказывает окончательно, задача перезапускается с последней контрольной точки. Поэтому оптика перестаёт быть компонентом и становится бюджетом надёжности. Здесь — арифметика отказов, метрики, предсказывающие проблемы, как фабрики мониторят и изолируют плохие линки, и практики, снижающие частоту отказов.
Почему важен один линк
| Событие | Эффект на задачу обучения |
|---|---|
| Флап линка (секунды) | коллективы истекают по таймауту или повторяются; время шага скачет; достаточно долгая остановка NCCL/RCCL прерывает задачу |
| Линк на пониженной скорости/ширине | каждый all-reduce задаётся им; пропускная способность всего кластера падает до доли этого линка |
| Повышенный BER до FEC без неисправимых | пока ничего — но запас исчез; в следующий тёплый день флап |
| Неисправимые ошибки FEC | потери пакетов → штормы повторов RDMA → остановка |
| Полный отказ | перезапуск задачи с контрольной точки: минуты — час потерянных вычислений по всему кластеру |
Цена перезапуска с контрольной точки для задачи на тысячу GPU измеряется в GPU-часах; именно это число сравнивают с ценой лучшей оптики и лучшей приёмки.
Арифметика отказов
Надёжность трансиверов задаётся в FIT (отказов на 10⁹ приборо-часов) или MTBF.
| Допущение | Значение |
|---|---|
| Оптических концов в фабрике | 4 000 (двухярусный кластер на 1 024 GPU) |
| FIT на конец (зрелая оптика 400G, хорошо охлаждаемая) | 200–500 |
| Ожидаемых полных отказов в месяц | 4 000 × 350 × 10⁻⁹ × 720 ч ≈ 1 |
| Наблюдаемая частота флапов на практике | в 5–20 раз выше полных отказов — грязь, маргинальный запас, тепло, прошивки |
Итак, полные отказы редки и предсказуемы; флапы и деградировавшие линки доминируют и в основном предотвратимы — поэтому мониторинг и приёмка окупаются.
Метрики, предсказывающие проблемы
| Метрика | Источник | Здорово | Действовать |
|---|---|---|---|
| BER до FEC по каналам | VDM CMIS; счётчики FEC хоста | < 10⁻⁷ | > 10⁻⁶ и растёт; > 10⁻⁵ — планировать замену |
| Неисправимые кодовые слова FEC | хост | 0 | любой прирост = инцидент |
| Символьные ошибки по каналам | хост (Ethernet) / perfquery (IB) | сбалансированы, около нуля | один канал доминирует |
| Rx по каналам относительно базы | DDM | в пределах 1 дБ от первого дня, каналы в пределах 2 дБ друг от друга | −2 дБ от базы |
| Тренд тока Tx | DDM | ровный | +15–20 % от базы (Ток смещения и старение) |
| Температура модуля | DDM | < 60 °C | > 65 °C или +10 °C к соседям |
| eSNR (CMIS) | VDM | > 18–20 дБ | падает на одном канале |
| Флапы линка на порт | логи коммутатора, менеджер фабрики | 0 | любые |
| Согласованная скорость/ширина | коммутатор / ibstat | полная | ниже номинала |
Определения и форматы: VDM и метрики FEC, Мониторинг.
Архитектура мониторинга
| Фабрика | Сбор | Инструменты |
|---|---|---|
| InfiniBand | менеджер подсети/фабрики опрашивает счётчики каждого порта и EEPROM/DDM кабелей | менеджеры класса UFM, ibdiagnet, mlxlink -m |
| Ethernet (RoCE) | потоковая передача состояния трансиверов и FEC по gNMI/OpenConfig с шагом 10–60 с; SNMP как запасной | gnmic → Prometheus/Grafana, вендорская телеметрия (Снятие DDM инструментами) |
| Сторона хоста | счётчики NIC: повторы, CNP, нарушения порядка; логи NCCL/RCCL на таймауты | экспортеры узлов |
| Сторона задачи | разброс времени шага, обнаружение отстающих | метрики фреймворка обучения |
Сопоставляйте три источника: скачок времени шага в 14:05, выброс BER до FEC на leaf 7 канал 3 в 14:04 и пик температуры модуля в стойке 12 — законченный диагноз.
Изоляция и устранение
- Автоматическое отключение порта / обход при превышении порога неисправимых ошибок или флапов — менеджеры фабрик и NOS поддерживают политики по ошибкам линков; адаптивная маршрутизация тем временем уводит потоки от деградировавшего линка.
- Вывести узел из работы, если виноват порт его NIC; спланировать задачу в обход.
- Модуль на стол: идентификация, поканальный DDM относительно базы первого дня, суммы, версия прошивки (Check transceiver, DDM).
- Почистить и переосмотреть MPO с обеих сторон, прежде чем винить модуль — грязь самая частая причина (Несовпадения физического уровня).
- Поменять и наблюдать: если ошибки идут за модулем — RMA; если остаются на порту — смотреть клетку, волокно и дальний конец.
Практики, снижающие частоту отказов
| Практика | Эффект |
|---|---|
| Входной контроль и прогон (24–72 ч под нагрузкой и температурой) | убирает ранние отказы до того, как они дойдут до задачи |
| База поканального DDM в первый день | превращает абсолютную точность (±3 дБ) в точные дельты |
| Держать модули < 60 °C — обдув, правильные OSFP с рёбрами/плоские, незакрытые заборы | срок жизни удваивается на каждые −10 °C |
| Чистить каждый разъём при каждой стыковке; колпачки на неиспользуемых портах | большинство флапов — грязь |
| Актуальность прошивок модулей и хостов | исправления совместимости CMIS (Проблемы CMIS) |
| Однородная валидированная оптика на ярус | меньше сюрпризов совместимости DSP хоста/модуля |
| Запас прогнан и с базой, 3–5 % | замена без второго инцидента |
| Еженедельный разбор трендов | менять стареющие лазеры по плану, а не по отказу |
Куда идёт технология
Более высокие скорости каналов (200G/канал, 1.6T) ещё сильнее сжимают запасы; линейная (LPO) и co-packaged оптика убирают DSP и его мониторинг — перенося видимость BER на хост, — обещая меньше компонентов и тепла (Модуляция и DSP, Оптика в AI). Каким бы ни был модуль, дисциплина та же: база, мониторинг дельт, действия по трендам.
В CodingBox
CodingBox — столовый конец этой петли: чтения входного контроля и прогона, базы первого дня по каналам, сохранённые по серийнику в базе кодов, и посмертные чтения снятых модулей — идентификация, прошивка, суммы и DDM в сравнении с их собственной историей, — чтобы решения об RMA опирались на данные, а не на последнюю строку лога порта.