Post #1924
1.01K
🌐 AI отбирает работу не только у людей, но и у TCP протокола.
Профессор Stanford John Ousterhout (уже emeritus) построил на этой мысли целый доклад: AI меняет привычные вещи даже на самом базовом уровне, и протокол, на котором держится весь интернет с 1970х, оказался просто не готов к новым нагрузкам.
Дело в том, что тренировка моделей - это гигантские передачи данных, где важна только пропускная способность, и тут TCP и RDMA справляются нормально. А вот inference и особенно agentic workloads - это постоянный обмен маленькими сообщениями: проверка KV-cache, синхронизация между GPU после раунда вычислений. И тут решает не средняя задержка, а tail latency (P99) - если хотя бы один такой обмен из тысячи затормозит, простаивают все GPU, которые ждут завершения синхронизации. Раньше вычисления занимали секунды, а синхронизация - миллисекунды, разница была не важна. Сейчас agentic workloads генерируют токены с интервалом в миллисекунды, и синхронизация той же длины съедает существенную долю GPU впустую.
TCP плохо справляется с этим по двум причинам. Первая - incast: когда несколько узлов одновременно шлют данные одному получателю, пакеты скапливаются в очереди свитча, и короткое сообщение застревает за длинными. Управлением перегрузкой в TCP занимается отправитель, хотя перегрузка возникает на стороне получателя - отправителю нужно несколько раундов через ECN-маркировку, чтобы понять, что происходит, и скорректировать скорость, и система в итоге постоянно колеблется между "слишком быстро" и "слишком медленно". Проблема известна больше 20 лет и до сих пор не решена. Вторая причина - у TCP нет понятия границ сообщений, это просто поток байт, поэтому короткое сообщение нельзя пропустить вперед длинных - оно физически стоит в очереди за ними.
Ousterhout с исследовательской группой в Stanford сделал Homa - transport протокол с нуля под эти workloads. Homa работает сообщениями, а не потоком байт, поэтому с первого пакета уже знает длину сообщения и отдает приоритет коротким через SRPT (shortest remaining processing time). Управление перегрузкой отдано получателю - именно он видит всю картину и рассылает "grant"-пакеты, разрешая отправителям слать следующий кусок данных. А поверх этого Homa использует priority-очереди в свитчах, чтобы короткие сообщения физически обгоняли длинные.
В бенчмарках на 40 узлах Homa дает tail latency (P99) для коротких сообщений в 7-83 раза ниже, чем TCP и DCTCP, и даже длинные сообщения передает почти в 2 раза быстрее. Реализация - kernel module для Linux, лежит на GitHub, и Ousterhout сейчас пытается протащить Homa в апстрим ядра.
https://youtu.be/eZ8WWZzoaR0
https://github.com/PlatformLab/HomaModule
#ai@rvnikita_blog #networking@rvnikita_blog #stanford@rvnikita_blog #john_ousterhout@rvnikita_blog
—————————
Мысли Рвачева
—————————
Профессор Stanford John Ousterhout (уже emeritus) построил на этой мысли целый доклад: AI меняет привычные вещи даже на самом базовом уровне, и протокол, на котором держится весь интернет с 1970х, оказался просто не готов к новым нагрузкам.
Дело в том, что тренировка моделей - это гигантские передачи данных, где важна только пропускная способность, и тут TCP и RDMA справляются нормально. А вот inference и особенно agentic workloads - это постоянный обмен маленькими сообщениями: проверка KV-cache, синхронизация между GPU после раунда вычислений. И тут решает не средняя задержка, а tail latency (P99) - если хотя бы один такой обмен из тысячи затормозит, простаивают все GPU, которые ждут завершения синхронизации. Раньше вычисления занимали секунды, а синхронизация - миллисекунды, разница была не важна. Сейчас agentic workloads генерируют токены с интервалом в миллисекунды, и синхронизация той же длины съедает существенную долю GPU впустую.
TCP плохо справляется с этим по двум причинам. Первая - incast: когда несколько узлов одновременно шлют данные одному получателю, пакеты скапливаются в очереди свитча, и короткое сообщение застревает за длинными. Управлением перегрузкой в TCP занимается отправитель, хотя перегрузка возникает на стороне получателя - отправителю нужно несколько раундов через ECN-маркировку, чтобы понять, что происходит, и скорректировать скорость, и система в итоге постоянно колеблется между "слишком быстро" и "слишком медленно". Проблема известна больше 20 лет и до сих пор не решена. Вторая причина - у TCP нет понятия границ сообщений, это просто поток байт, поэтому короткое сообщение нельзя пропустить вперед длинных - оно физически стоит в очереди за ними.
Ousterhout с исследовательской группой в Stanford сделал Homa - transport протокол с нуля под эти workloads. Homa работает сообщениями, а не потоком байт, поэтому с первого пакета уже знает длину сообщения и отдает приоритет коротким через SRPT (shortest remaining processing time). Управление перегрузкой отдано получателю - именно он видит всю картину и рассылает "grant"-пакеты, разрешая отправителям слать следующий кусок данных. А поверх этого Homa использует priority-очереди в свитчах, чтобы короткие сообщения физически обгоняли длинные.
В бенчмарках на 40 узлах Homa дает tail latency (P99) для коротких сообщений в 7-83 раза ниже, чем TCP и DCTCP, и даже длинные сообщения передает почти в 2 раза быстрее. Реализация - kernel module для Linux, лежит на GitHub, и Ousterhout сейчас пытается протащить Homa в апстрим ядра.
https://youtu.be/eZ8WWZzoaR0
https://github.com/PlatformLab/HomaModule
#ai@rvnikita_blog #networking@rvnikita_blog #stanford@rvnikita_blog #john_ousterhout@rvnikita_blog
—————————
Мысли Рвачева
—————————
- 👍 12
- 🔥 5
- 👏 2
- ❤ 1
