Пять вопросов, которые стоит задать вендору о сетевой архитектуре

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

Так вот, в первой части мы рассказали, как спроектировали архитектуру нашего ПАК «Скала^р МИИ» и почему не стали использовать InfiniBand. Но это, само собой, не все — во второй части вас ждут подробности про разделение трафика, отказоустойчивость в разрезе сетевой архитектуры и небольшой список нюансов, о которые можно споткнуться в процессе. А пока — тизер в формате тех самых пяти вопросов.

1. Как физически разделен ИИ-трафик от других типов трафика? Если ответ «через VLAN на одних коммутаторах» — уточните, как исключено влияние backup или storage-трафика на RoCEv2 при одновременной работе.
2. Что гарантирует отсутствие потерь (lossless): PFC, ECN, DCQCN? Если один из трех компонентов отсутствует или «будет настроен позже» — это красный флаг для производительности обучения.
3. Какие сетевые карты используются и поддерживают ли они аппаратный RDMA? Программная эмуляция RoCEv2 дает задержки, сопоставимые с TCP, и теряет весь смысл технологии.
4. Как настроен MTU end-to-end? Jumbo frames 9000 байт должны работать на всем пути: узел → NIC → коммутатор → NIC → узел. Несоответствие в одном месте незаметно убивает производительность.
5. Как мониторятся PFC-события и задержки NCCL? Если ответ «мониторим утилизацию интерфейсов» — этого недостаточно. Проблемы в RoCEv2-фабрике обнаруживаются не через загрузку портов, а через специфические счетчики.

Остальное — во второй части статьи, coming soon. Не переключайтесь.