Homa: Конец TCP для кластеров ИИ — Джон Оустерхаут, Стэнфорд

Джон Остерхаут, профессор Стэнфордского университета и автор книги «Философия проектирования программного обеспечения», обращает наше внимание на меняющуюся природу сетевых нагрузок ИИ и на то, почему традиционные протоколы, такие как TCP и RDMA, становятся узкими местами в современных центрах обработки данных! Сдвиг в рабочих нагрузках Исторический контекст: В трафике ИИ доминировали массивные, длительные передачи (гигабайты градиентов), где пропускная способность была основным показателем (2:19-2:42). Современный ИИ: Рабочие нагрузки, особенно приложения для вывода и агентные приложения, теперь полагаются на частые, небольшие координационные сообщения (например, поиск в кэше ключ-значение, синхронизация барьеров). Эти небольшие сообщения очень чувствительны к задержке (3:09-4:02). Узкое место: Когда небольшие синхронизационные сообщения смешиваются с большим трафиком, они застревают в очередях (вызванных incast), что значительно увеличивает задержку 99-го процентиля (хвоста). Это приводит к простою графических процессоров, что расходует дорогостоящие вычислительные ресурсы (4:24-5:34). Почему устаревшие протоколы испытывают трудности Управление перегрузкой, управляемое отправителем: TCP и RDMA полагаются на отправителя в обнаружении перегрузки, часто посредством потери пакетов или задержки сигналов от коммутаторов. Этот процесс по своей природе реактивен и колеблется, что приводит к нестабильной производительности (7:10-9:58). Модель байтового потока: Эти протоколы рассматривают данные как непрозрачный поток байтов, а не как дискретные сообщения, что затрудняет определение приоритетов для коротких, критически важных задач (10:05-11:05). Решение Homa Джон представляет Homa, протокол передачи данных с нуля, разработанный для центров обработки данных (11:15-12:15): На основе сообщений: В отличие от потоков байтов, Homa понимает границы сообщений, что позволяет ей прогнозировать трафик и расставлять приоритеты для коротких сообщений, используя кратчайшее оставшееся время обработки (SRPT) (12:22-13:28). Управление получателем: Получатель контролирует поток, выдавая разрешения отправителям, эффективно управляя перегрузкой до того, как она возникнет на коммутаторе (13:30-14:58). Приоритетные очереди: Homa использует множество аппаратных очередей, уже имеющихся в современных коммутаторах, для обхода длинного трафика в очередях с помощью коротких сообщений с низкой задержкой (14:59-15:51). Результаты производительности: Бенчмарки показывают, что Homa может уменьшить задержку в конце потока для коротких сообщений более чем в 10 раз по сравнению с TCP, одновременно повышая производительность для больших сообщений (15:52-17:27). Информация о докладчике: https://x.com/johnousterhout https://web.stanford.edu/~ouster/cgi-... Временные метки: 0:00 - Почему задержка становится важным показателем 2:19 - Старая рабочая нагрузка: гигабайты и пропускная способность 3:09 - Новая рабочая нагрузка: метаданные и координация 4:24 - Как один медленный обмен приводит к зависанию всех графических процессоров 6:07 - Incast и где фактически формируется очередь 7:10 - Почему управление перегрузкой находится не на той стороне 10:05 - Поток байтов не имеет границ сообщений 11:08 - Homa и перепроектирование с чистого листа 12:12 - Сообщения, а не потоки 13:30 - Управление перегрузкой со стороны получателя 14:59 - Использование приоритетных очередей, уже имеющихся в коммутаторе 15:52 - Бенчмарк по сравнению с TCP