Homa: почему GPU ждут сеть (Рубрика #AI)

Посмотрел свежий доклад Джона Оустерхаута из Stanford про Homa (Джон - соавтор протокола консенсуса Raft, а также автор крутой книги "A Philosophy of Software Design", о которой я уже рассказывал). В заголовке доклада заявлен тизис «конец TCP для AI-кластеров», а внутри интересный инженерный вопрос: сколько времени дорогие GPU простаивают, пока маленькое сообщение ждёт за большой передачей? По мысли Оустерхаута, в инференсе и агентных системах растёт роль коротких обменов: проверить запись в распределённом KV-кэше, согласовать следующий шаг вычислений. Здесь важна хвостовая задержка: один запоздавший ответ может задержать всех участников синхронизации.

Проблема хорошо известна распределённым системам (она буквально продолжает историю "The Tail at Scale", что я разбирал вчера). Когда несколько серверов одновременно отправляют данные одному получателю, перед его сетевым портом растёт очередь — incast. Короткому сообщению тоже приходится ждать.

Homa предлагает перестроить транспорт вокруг сообщений:
— Знать длину сообщения и давать преимущество тем, которым осталось передать меньше байтов.
— Управлять потоком со стороны получателя: отправитель передаёт начальную порцию, а дальше получает разрешения — grants.
— Использовать приоритетные очереди коммутаторов, чтобы короткие сообщения обходили большие передачи.

В показанном бенчмарке, по данным автора, p99 задержки коротких сообщений у Homa примерно в 13 раз ниже, чем у TCP. Большие сообщения при этом тоже выигрывают. Уже есть Linux-модуль, тесты и утилиты измерений. Но с заголовком и широтой выводов я бы поспорил.

1️⃣ На слайде презентации сетевой бенчмарк, который демонстрирует эффект использования протокола
Ускорения LLM в 13 раз из него не следует: нужно измерять время ответа приложения, tokens/s и загрузку GPU. Выигрыш зависит от того, какая доля ожидания действительно приходится на транспорт.
2️⃣ Отрасль давно работает над этой проблемой
Google описал промышленное применение Swift, а SIRD исследует, как согласовывать решения получателей, когда узким местом становится общий канал. Сравнение с TCP ещё не закрывает спор о лучшем транспорте.
3️⃣ Границы применимости существенны: Homa рассчитан на сеть внутри дата-центра. Нужны интеграция с приложением и настройка сети; разработка grpc_homa приостановлена. Для внедрения работы хватает.

Почитать подробнее — научные статьи и техническое обоснование:
— Homa, SIGCOMM 2018 — устройство протокола.
— Linux-реализация, USENIX ATC 2021 — измерения на 40 узлах; на странице есть PDF.
— It’s Time to Replace TCP in the Datacenter — аргументы Оустерхаута против архитектуры TCP в ЦОД.

Кстати, в конце доклада автор приглашает экспериментировать с Homa и обещает помощь: ouster@cs.stanford.edu. Хорошая задача для входа — проверить, сколько сетевого выигрыша сохраняется в реальной AI-нагрузке. Вот такой результат мне было бы интересно увидеть.

#AI #Architecture #Engineering #Research #PlatformEngineering