O fim do TCP para clusters de IA — John Ousterhout, Stanford

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: The End of TCP for AI Clusters — John Ousterhout, Stanford · Canal: AI Engineer · 18:26 · Assistir no YouTube

Tópicos: Inferência e otimização de modelos, Infraestrutura e hardware de IA

Resumo

John Ousterhout argumenta que workloads de inferência e de agentes de IA estão usando cada vez mais mensagens pequenas, para as quais a latência de cauda importa mais do que a vazão. TCP e RDMA, projetados para transferências grandes, podem sofrer com congestionamento, filas e bloqueio de mensagens curtas por mensagens longas. Ele apresenta Homa, um protocolo de transporte baseado em mensagens que controla o congestionamento no receptor e prioriza mensagens menores. Em um benchmark mostrado na palestra, Homa reduz em cerca de 13 vezes a latência de cauda de mensagens curtas em comparação com TCP e também melhora o desempenho de mensagens longas.

Pontos-chave

Workloads de inferência e de agentes de IA estão se tornando mais granulares e dependentes de trocas de mensagens pequenas.
A latência de cauda pode deixar GPUs ociosas enquanto os nós aguardam a sincronização necessária para iniciar a próxima etapa de computação.
O congestionamento por incast acumula pacotes nas filas próximas ao destino, atrasando mensagens curtas e podendo causar perdas e retransmissões.
Em TCP e RDMA, o controle de congestionamento é feito pelo emissor, que recebe informações com atraso e pode ajustar sua taxa de forma instável.
Como TCP trata os dados como um fluxo de bytes, não preserva os limites entre mensagens nem permite priorizar mensagens curtas de forma direta.
Homa é um protocolo baseado em mensagens e em chamadas remotas de procedimento, que conhece o tamanho das mensagens.
Homa controla o congestionamento no receptor, que envia permissões graduais para o emissor transmitir os pacotes seguintes.
Homa usa filas de prioridade nos switches para permitir que mensagens curtas ultrapassem mensagens longas.
No benchmark apresentado, a latência P99 de mensagens curtas foi cerca de 13 vezes menor com Homa do que com TCP; para mensagens longas, Homa também teve desempenho quase duas vezes melhor.

Capítulos

Início	Capítulo	Resumo
00:01	Por que a latência importa para workloads de IA	John Ousterhout apresenta a mudança de transferências grandes para trocas menores e explica por que a latência de cauda se torna importante.
03:21	Mensagens pequenas, sincronização e GPUs ociosas	O palestrante descreve como trocas pequenas em workloads de inferência e de agentes podem atrasar a computação quando os nós precisam sincronizar.
06:01	Incast e limites do controle de congestionamento	A palestra explica como o incast cria filas e por que o controle de congestionamento feito pelo emissor pode ser lento e instável.
10:24	Por que TCP e RDMA têm dificuldade com mensagens curtas	O tratamento dos dados como fluxo de bytes causa bloqueio de mensagens curtas atrás de mensagens longas, motivando uma nova abordagem.
11:28	Como funciona o protocolo Homa	Ousterhout apresenta Homa, que preserva os limites das mensagens, controla o congestionamento no receptor e usa permissões e filas prioritárias.
15:44	Resultados do benchmark e conclusão	O benchmark mostra menor latência de cauda com Homa, e o palestrante incentiva o público a testá-lo se mensagens curtas limitarem o desempenho.

Citações

O que realmente importa é a latência de cauda. — 03:51

O que Homa faz particularmente bem é gerenciar uma combinação de mensagens grandes e pequenas. — 11:28

Com TCP, a latência de cauda passa de um milissegundo; com Homa, fica abaixo de 100 microssegundos. — 16:49

A participação das mensagens curtas na IA parece estar aumentando. — 17:20

Conceitos e entidades

Homa (conceito): Protocolo de transporte baseado em mensagens, desenvolvido em Stanford para reduzir o congestionamento e a latência em workloads de data center.
TCP (conceito): Protocolo de transporte baseado em fluxo de bytes que, segundo a palestra, não é adequado para priorizar mensagens curtas em workloads mistos.
RDMA (conceito): Tecnologia de acesso remoto à memória cuja implementação comum em data centers, segundo a palestra, também sofre com alta latência de cauda em workloads mistos.
incast (conceito): Situação em que vários nós enviam dados ao mesmo destino ao mesmo tempo, provocando congestionamento nas filas próximas ao destino.
SRPT (conceito): Política de escalonamento que prioriza o trabalho com menor tempo restante de processamento, usada por Homa para favorecer mensagens curtas.
ECN (conceito): Mecanismo de notificação explícita de congestionamento em que switches marcam pacotes para informar os emissores sobre filas congestionadas.
John Ousterhout (pessoa): Professor emérito de Stanford que apresenta Homa e defende a importância da latência em aplicações de IA.
Ben Moazeni (pessoa): Estudante de doutorado cujo trabalho de tese deu origem ao desenvolvimento de Homa.
Stanford University (empresa): Universidade onde Homa foi desenvolvido.

Tradução completa (pt-BR)

00:01 [música] >> Por favor, recebam no palco o Professor Emérito da Stanford University, John Ousterhout.

00:37 >> Bom dia. É muito bom estar aqui para falar sobre o lado da rede nas aplicações de IA e, em particular, defender que a latência importa e provavelmente vai importar ainda mais no futuro. Mas quero dizer que esta palestra é incomum para mim. Nunca antes dei uma palestra em um auditório com máquinas de fumaça. Acho que é uma experiência bem típica de San Francisco. Então, é bem sabido que as cargas de trabalho de IA dependem de um desempenho de rede realmente excelente para alcançar seu próprio desempenho. É claro que isso acontece porque as cargas de trabalho são tão grandes que precisam ser distribuídas entre máquinas, e então é preciso haver comunicação entre elas. Mas o que quero abordar hoje é que parece que essas cargas de trabalho estão mudando. Espero fazer três coisas nos próximos 15 ou 20 minutos. Primeiro, convencer vocês de que, de fato, as cargas de trabalho estão mudando e de que, enquanto antes eram completamente dominadas por grandes transferências, em que a métrica principal era a vazão, estamos vendo cada vez mais transferências menores, nas quais a latência é crucial. A segunda coisa que espero fazer é convencer vocês de que protocolos legados como

01:10 TCP e RDMA não são adequados para esse ambiente. Eles não foram projetados para esse ambiente e, infelizmente, sofrem de latência de cauda muito alta quando se misturam mensagens pequenas com mensagens grandes. E vou falar um pouco sobre por que isso acontece. Depois, em terceiro lugar, gostaria de apresentar o Homa, um novo protocolo que desenvolvemos em Stanford, projetado em uma reformulação do zero para lidar com cargas de trabalho de data center como essas. E, de fato, ele funciona muito bem com essas cargas de trabalho e pode reduzir a latência de cauda em uma ordem de magnitude ou mais. Então, vou contar um pouco sobre o Homa.

01:44 Então, vamos começar. Primeiro, as cargas de trabalho. Historicamente, as cargas de trabalho de IA consistiam em transferências enormes entre máquinas. E isso era tudo o que realmente importava: gigabytes de dados para coisas como gradientes de pesos e assim por diante. Nessas cargas de trabalho, o que realmente importa é a vazão: quantos gigabits por segundo você consegue fazer passar pelos canais. E essas cargas são relativamente fáceis para as redes, porque não importa se leva um tempo para estabelecer a conexão e começar a transferência. As

02:16 transferências duram tanto que a única coisa que realmente importa é a vazão. E, por isso, nesses ambientes, TCP e RDMA têm um desempenho razoavelmente bom. A propósito, quando digo RDMA, na verdade quero dizer RoCE, RDMA over Converged Ethernet, que é o transporte subjacente usado pelo RDMA para a maioria das finalidades hoje. Enfim, nas cargas de trabalho antigas, com grandes transferências, a vazão importa e os protocolos legados funcionam razoavelmente bem. No entanto, parece que as cargas de trabalho estão mudando. Estão se tornando mais granulares, com blocos menores de

02:48 computação e trocas menores de dados. E isso parece ser particularmente verdadeiro no mundo da inference e também nas cargas de trabalho agentic. Não tanto nas cargas de trabalho de treinamento, que ainda envolvem transferências enormes. O que está acontecendo é que há cada vez mais trocas de mensagens pequenas, normalmente para coisas como metadados e coordenação, por exemplo, verificar se uma determinada entrada está presente em um KV cache distribuído ou fazer sincronização de barreira no fim de períodos de computação. E, para essas cargas de trabalho,

03:21 o que realmente importa é a latência. Ou seja, qual é o tempo de ida e volta para enviar um pequeno bloco de dados pela rede, fazer um pouco de computação e receber de volta um pequeno resultado? E, na verdade, não é só a latência ou a latência média que importa. O que realmente importa é a latência de cauda. Ou seja, você gostaria de saber que, se enviarmos muitas mensagens pequenas, todas elas serão concluídas rapidamente. Por exemplo, normalmente medimos coisas como a latência do percentil 99. E, se tivermos uma latência de cauda alta, isso

03:51 pode limitar a vazão geral do sistema. Então, aqui vai um exemplo. Uma prática comum é pegar uma carga de trabalho e dividi-la entre vários nós, que fazem computação intensiva usando suas GPUs por algum período. Depois que todos terminam a computação, eles fazem uma pequena troca entre os nós para trocar dados e metadados e, então, passam para a próxima rodada de computação. Enquanto essa troca e essa sincronização estão acontecendo, as GPUs ficam ociosas. Portanto, se até mesmo uma dessas trocas levar muito

04:22 tempo, acontece que todo o processo fica parado. É preciso que todas essas trocas sejam concluídas antes de passar para a próxima etapa da computação. Agora, se a etapa de computação dura, digamos, 5 segundos, e a troca leva alguns milissegundos, não é um problema. E, historicamente, era assim. Mas agora, com as cargas de trabalho agentic, em que se tenta gerar tokens com relativa rapidez e a uma taxa regular, os períodos de computação estão diminuindo para a escala de milissegundos. E, se também leva milissegundos para fazer essa sincronização,

04:55 então vocês estão desperdiçando uma parcela significativa dos recursos da GPU esperando a sincronização acontecer. Estou curioso. Gostaria de fazer uma rápida enquete com o público. Há alguém aqui que tenha motivos para acreditar que a latência de mensagens pequenas está afetando a vazão geral das aplicações? Se sim, podem levantar a mão? Vamos ver se há alguém aqui hoje. Na verdade, mais mãos do que eu esperava. Então, várias pessoas estão levantando a mão. Acho que esse problema provavelmente vai piorar à medida que essas tendências continuarem.

05:28 Então, o que está acontecendo? Por que a latência de cauda é ruim? Bem, normalmente a causa é o congestionamento resultante de incast. Incast é quando vários nós decidem, ao mesmo tempo, transferir dados para algum nó de destino. E, se todos enviarem mensagens grandes, bem, os links são iguais em toda a rede. Então, três nós conseguem transferir dados três vezes mais rápido do que um nó consegue receber. E o que acontece é que os pacotes se acumulam no último salto até esse destino, na parte superior do seu

06:01 switch de acesso, na porta de saída que leva ao nó de destino. Então, se algum outro nó decidir enviar uma mensagem curta para esse mesmo destino, a mensagem curta fica presa atrás das mensagens longas na fila. E isso causa atraso e, no pior caso, chegam tantos pacotes que o switch fica sem espaço de buffer e precisa descartar pacotes. Depois, há timeouts e retransmissões que pioram ainda mais a situação. Então, de alguma forma, precisamos de um jeito de reduzir o congestionamento nessas filas. De alguma forma,

06:35 precisamos fazer com que os nós remetentes parem de enviar tão rápido, para que as filas não cresçam sem limite. Historicamente, em praticamente todos os protocolos de rede anteriores ao Homa, incluindo TCP e RDMA, o controle de congestionamento é responsabilidade do remetente. Então, os remetentes precisam descobrir de alguma forma que há congestionamento e, em seguida, reduzir a taxa de transmissão. Agora, vocês podem se perguntar: por que os remetentes fazem isso? O congestionamento está lá no outro lado da rede do data center. Como é que o remetente fica sabendo?

07:10 Bem, nos tempos antigos, a maneira de descobrir era as filas transbordarem e os pacotes serem descartados. O remetente detectava a perda dos pacotes porque não recebia os acknowledgements de volta e supunha que isso significava congestionamento; então, reduzia a taxa de transferência. Isso é muito caro. Hoje, há técnicas melhores, que envolvem principalmente os switches fornecendo informações. Quando um switch top-of-rack vê que o comprimento da fila de uma porta de saída atingiu algum limite, ou que está começando a encher, muito antes de a fila transbordar, ele começa a marcar todos os pacotes que passam por ali com o que se chama notificação antecipada de congestionamento, marcação ECN. Então, quando esses pacotes chegam ao receptor, ele vê a marcação nos pacotes e, na próxima vez que se comunica com o remetente — por exemplo, para enviar um acknowledgement —, inclui essa marcação na mensagem de volta ao remetente. Aí o remetente vê e percebe: “Ah, há congestionamento em algum lugar. Preciso reduzir minha taxa de transmissão.” Essa é a ideia básica. Infelizmente, acertar isso é muito difícil, muito difícil. É muito difícil

07:43 Bem, nos tempos antigos, realmente muito antigos, a maneira de descobrir era que as filas transbordavam e os pacotes eram descartados. O emissor detectava que os pacotes tinham se perdido porque não recebia confirmações de volta, e presumiria que isso significava que havia congestionamento e então diminuiria sua taxa de transferência. Isso é muito caro. Então, hoje existem técnicas melhores, que envolvem principalmente os switches fornecendo informações. Assim, um switch top-of-rack, quando vê que o comprimento da fila de uma porta de saída atingiu algum limite ou começou a se encher, muito antes de a fila transbordar, começa a marcar todos os pacotes que passam com

08:15 o que é chamado de notificação antecipada de congestionamento, marcação ECN. E então, quando esses pacotes chegam ao receptor, o receptor vê a marcação nos pacotes e, quando se comunica de volta com o emissor em seguida, por exemplo, para enviar uma confirmação, inclui essa marcação, que é enviada de volta ao emissor. E agora o emissor vê — o emissor percebe: “Ah, há congestionamento em algum lugar. Preciso diminuir minha taxa de transmissão.” Essa é a ideia básica. Infelizmente, acertar isso é muito difícil, muito difícil. É muito difícil

08:47 para a congestão descobrir exatamente como definir suas taxas, porque recebe uma única informação: há congestão em algum lugar. E há vários emissores, todos enviando para o mesmo destino. Todos tentam fazer ajustes ao mesmo tempo. Quanto você reduz o envio? E como sabe quando pode voltar a aumentar a taxa? E, pior ainda, é muito difícil fazer isso de forma estável, porque há atraso no controle. Ou seja, leva tempo até o emissor descobrir que há congestão. E, na verdade, usando esse processo, normalmente são necessárias várias viagens de ida e volta para o emissor ajustar gradualmente sua taxa

09:20 até chegar à taxa exata que corresponde à largura de banda disponível. Mas, quando isso acontece, na rede as coisas já mudaram. Novas transmissões começaram ou as antigas terminaram. E, por isso, esses sistemas tendem a nunca se estabilizar. Estão constantemente oscilando entre enviar demais e enviar de menos. Esse problema existe há muito tempo. A comunidade de pesquisa o conhece há mais de 20 anos. Foram publicados inúmeros artigos sobre ele. Houve algumas melhorias, isso é inegável, mas ainda estamos muito longe de ter algo que funcione bem.

09:50 E o problema está na natureza fundamental de fazer o controle de congestão no lado do emissor. Simplesmente não funciona muito bem. Então, acaba havendo muito acúmulo nas filas. E, na verdade, a única maneira de descobrir que há congestão é quando há filas. Portanto, nesse momento já estamos enfrentando atrasos. Esse é um problema. Opa. Há outro problema com TCP e RDMA: o modelo básico de dados deles é um fluxo de bytes. Apenas um fluxo de bytes, sem distinção entre eles. Então, se você envia uma série de mensagens, por exemplo, por um socket TCP, elas são serializadas nesse

10:24 fluxo. E, neste slide, mostrei as mensagens como se tivessem cores diferentes no fluxo. Mas, na vida real, não há cores. O TCP não sabe onde ficam os limites entre as mensagens. E isso também dificulta as coisas. Por exemplo, você não sabe quanto mais dados ainda virão. Se soubesse o tamanho da mensagem, saberia quanto ainda falta. E não é possível priorizar mensagens curtas, algo que gostaríamos muito de fazer: permitir que as mensagens curtas passem mais rápido. Também pode ocorrer o chamado bloqueio de cabeça de fila, quando alguém envia uma série de mensagens para o mesmo destino, envia duas mensagens muito grandes e depois uma pequena

10:58 e, em seguida, elas ficam presas atrás das mensagens grandes nesse fluxo. E, por isso, há atraso. Mais uma vez, surgem problemas de latência de cauda. Em suma, TCP e RDMA simplesmente não são adequados para esse ambiente. Então, o que fazemos? O que eu gostaria de fazer agora é falar sobre um novo protocolo chamado Homa, que desenvolvemos em Stanford com base em uma reformulação completa do transporte de rede, partindo do zero. Se você pudesse começar do início e repensar como fazer o transporte em data centers, como faria? E acontece que, no

11:28 Homa, praticamente todas as principais decisões de projeto são diferentes das do TCP e do RDMA. Apesar de tudo de extraordinário que o TCP realizou, ele simplesmente não combina bem com os data centers de hoje, e o RDMA também não. O que o Homa faz particularmente bem é gerenciar uma combinação de mensagens grandes e pequenas e garantir que as mensagens curtas tenham latência realmente baixa. Isso começou como a tese de doutorado de um dos meus alunos, Ben Moazeni, e os resultados foram tão bons que decidi transformá-lo no meu projeto pessoal, para ver se conseguimos tirá-lo do laboratório

12:02 e colocá-lo em produção. Como talvez saibam, não sou como a maioria dos professores: adoro programar. Então, transformei isso no meu próprio projeto de programação. Criei um módulo de kernel para Linux. Atualmente, estou trabalhando no processo de incorporá-lo ao kernel. Ele está disponível para download no GitHub. Então, vou explicar um pouco como o Homa funciona. Quero mencionar três coisas. Primeiro, ele é baseado em mensagens, não em fluxos. >> [limpa a garganta] >> Na verdade, a unidade fundamental do Homa é uma chamada de procedimento remoto, que consiste em duas coisas: uma mensagem de solicitação enviada

12:35 do cliente para um servidor e, depois, uma mensagem de resposta enviada de volta do servidor para o cliente. O ponto principal é que o Homa conhece o tamanho das mensagens. Essa informação está incorporada ao transporte, até o nível mais baixo, e isso traz várias vantagens. Primeiro, permite prever o futuro. Assim que o receptor recebe o primeiro pacote de uma mensagem, sabe exatamente quantos dados a mais o emissor quer enviar. Isso representa muito mais informação para fazer o controle de congestão.

13:05 Segundo, o Homa prioriza mensagens mais curtas. Ele usa SRPT — menor tempo de processamento restante primeiro — para tentar priorizar mensagens mais curtas. Terceiro, como as mensagens são todas independentes e não são serializadas em um fluxo, cada mensagem é independente. As mensagens mais curtas podem passar à frente das longas, sem ficarem enfileiradas atrás delas. A segunda diferença do Homa é que ele controla a congestão a partir do receptor. Agora, pensando bem, isso faz

13:36 sentido, porque a congestão ocorre principalmente naquele último enlace descendente até o receptor. E, por isso, o receptor tem muito mais informação. Na verdade, com o Homa, assim que recebe o primeiro pacote de uma mensagem, ele sabe exatamente quanto ainda está por chegar. Então, tem praticamente todas as informações sobre a congestão e, portanto, pode reagir a ela com muito mais rapidez e precisão. No Homa, as coisas funcionam assim: quando um emissor tem uma mensagem para enviar, ele a divide em pacotes, mas só

14:07 transmite os primeiros pacotes, chamados de pacotes não agendados, para o receptor. Os pacotes seguintes são chamados de pacotes agendados e só são transmitidos quando o receptor os solicita. Então, o receptor envia pacotes de concessão de volta. Ele os distribui ao longo do tempo e os envia ao emissor, dizendo: “Agora é hora de você me enviar o próximo bloco de dados.” E o receptor pode atrasar essas concessões. Por exemplo, se o receptor tem 10 mensagens chegando, não faz sentido enviar concessões para todas as 10

14:38 porque, assim, só haveria congestão nas filas do topo do rack. Então, podemos usar as concessões para reduzir a congestão, e também para dar preferência às mensagens mais favorecidas, que seriam as mais curtas. É uma maneira de implementar o SRPT, favorecendo as mensagens curtas. O terceiro aspecto do Homa é que ele aproveita as filas de prioridade dos switches modernos. Os switches modernos de data center têm mais de uma fila em cada porta de saída, normalmente oito, e elas podem ser usadas em um mecanismo de prioridade

15:10 no qual os pacotes são transmitidos com preferência a partir da fila de prioridade mais alta. Neste slide, mostrei apenas duas filas, mas normalmente há mais. É possível especificar em qual fila um pacote deve entrar usando os vários campos do pacote. E o Homa faz essas escolhas dinamicamente, de modo a dar prioridade às mensagens mais curtas. Então, se voltarmos ao exemplo de incast de alguns slides atrás, todas aquelas mensagens longas se acumularão na fila de prioridade mais baixa. Mas, se chegar uma mensagem curta, ela usará uma fila de prioridade mais alta. Assim, passará imediatamente à frente

15:44 de todos os pacotes enfileirados das mensagens curtas, das mensagens mais longas, e chegará ao destino mais rapidamente. Então, que diferença isso faz? Aqui está um benchmark de exemplo que uso para ajustar e avaliar o Homa. Ele consiste em uma carga de trabalho em que várias máquinas de uma rede trocam mensagens entre si, de diferentes tamanhos, desde muito pequenas até muito grandes. Neste gráfico, o eixo x mostra o tamanho da mensagem, de cerca de 50 bytes até um megabyte. O eixo y mostra a

16:18 tempo de ida e volta para mensagens desse tamanho. Então, esta solicitação usa mensagens de solicitação e resposta que têm o mesmo tamanho. Você pode ver o TCP em verde e o Homa em azul. O eixo y mostra o tempo de ida e volta; quanto menor, melhor. Para cada protocolo, tenho duas curvas. Uma é a curva P50, que representa a latência mediana para mensagens desse tamanho. A outra é a P99, ou seja, o percentil 99: a latência de cauda para mensagens desse tamanho. Quero destacar duas coisas. Primeiro,

16:49 a P99 para mensagens curtas é dramaticamente melhor com o Homa. Com o TCP, a latência de cauda passa de um milissegundo; com o Homa, fica abaixo de 100 microssegundos, cerca de 13 vezes mais rápido. Segundo, curiosamente, você poderia pensar que, como o Homa favorece mensagens mais curtas, as mensagens longas sofrem e têm um desempenho pior. Mas, na verdade, não é isso que acontece. Mesmo nas mensagens mais longas, o Homa é quase duas vezes melhor que o TCP. Não tenho tempo para explicar isso hoje, mas tem a ver com o fato de que o Homa

17:20 usa abordagens de execução até a conclusão, que são muito mais eficazes do que o escalonamento justo usado pelo TCP. Então, para concluir, o papel das mensagens curtas em IA parece estar aumentando. Acho que é provável que continue aumentando. Vamos ver, ao longo do próximo ano ou dos próximos dois anos, se isso acontece. E quero deixar uma pergunta para vocês: enquanto executam suas aplicações, medem o desempenho e observam quais são os gargalos, perguntem a si mesmos: a alta latência de mensagens curtas está afetando sua taxa de transferência? Se a resposta for sim, saibam

17:54 que existe uma solução disponível. Vocês deveriam experimentar o Homa. Provavelmente conseguirão reduzir a latência de cauda em uma ordem de magnitude ou mais. E, a propósito, o Homa é basicamente minha missão de vida neste momento. Estou meio que semiaposentado de Stanford, e fiz isso para poder dedicar 100% do meu tempo a programar no Homa. Ficarei muito feliz em trabalhar com vocês e ajudar caso decidam experimentar o Homa. Se precisarem de ajuda para começar, de respostas a perguntas, correções de bugs ou qualquer outra coisa, ficarei feliz em trabalhar com vocês para tentar ajudar a fazer o projeto dar certo. Então, se isso lhes interessa, fiquem à vontade para entrar em contato comigo. Meu e-mail está no slide, ou vocês podem pesquisar

18:26 meu nome no Google e me encontrar na internet. Muito obrigado por ouvirem, e espero receber notícias de alguns de vocês. >> [música]

Transcrição original

[00:01] [music] >> Please welcome to the stage the Professor Emeritus at Stanford University, John Ousterhout.

[00:37] >> Good morning. It’s really great to be here to talk about the network side of AI applications and in particular to make the case that latency matters and is probably going to be mattering more in the future. But I just want to say this is a talk is unusual for me. I’ve never before given a talk where there are fog generators in the auditorium. Just a really San Francisco experience, I guess. So it’s it’s well known that AI workloads depend on really great networking performance in order to achieve their own performance. Of course, that’s because the workloads are so large that they have to be

[01:10] distributed across machines and then you have to communicate between the machines. But what I want to talk about today is it it seems that those workloads are changing. And so I hope to do three things over the next 15 or 20 minutes. First, to convince you that in fact the workloads are changing and that whereas the workloads used to be completely dominated by large transfers where throughput is the key metric that matters, that we’re seeing more and more smaller transfers where the latency is crucial. The second thing I hope to do is to convince you that legacy protocols like

[01:44] TCP and RDMA are poorly suited to this environment. They weren’t designed for this environment and unfortunately they suffer from very high tail latency when you mix small messages with large ones. And talk a little bit about why that’s the case. Then third, I’d like to introduce Homa, which is a new protocol we’ve developed at Stanford that actually was designed in a clean slate redesign to handle data center workloads like these. And in fact, it does quite well on those workloads and can reduce tail latency by an order of magnitude or more. So, I’ll tell you a little bit about Homa.

[02:16] So, let’s dive in. First, workloads. Historically, AI workloads have consisted of enormous transfers between machines. And that’s all that really mattered. Gigabytes of data for things like weight gradients and and so on. In these workloads, what you really care about is throughput. How many gigabits per second you can pump through the pipes. And these are relatively easy workloads for networks because if it takes a while to set up the connection and start the transfer, it doesn’t matter. The

[02:48] transfers go on for so long that all that really matters is the throughput. And so, in these environments, TCP and RDMA perform pretty well. Uh by the way, when I say RDMA, what I really mean is Rocky RDMA over converged Ethernet, which is the underlying transport that’s used by RDMA for most purposes today. So, anyhow, the old workloads, big transfers, throughput matters, uh the legacy protocols work pretty well. However, it appears that the workloads are changing. They’re becoming more granular with smaller chunks of

[03:21] computation and smaller exchanges of data. And this seems to be particularly true in the world of inference and also in agentic workloads. Not so much for training workloads are still massive transfers. And so, what’s happening is that more and more there are small message exchanges, typically for things like metadata and coordination, such as checking to see if a particular entry is present in a KV cache that’s distributed, or doing barrier synchronization at the end of periods of compute. And for these workloads,

[03:51] what really matters is latency. That is, what’s the round trip time to send some small piece of data across the network, do a little bit of computation, and get a small result back again? And in fact, it isn’t just just latency or average latency that matters. What really matters is tail latency. That is, you’d like to know that if we send a whole lot of small messages, all of them will complete quickly. So, for example, we typically measure things like 99th percentile latency. And if we have high tail latency, that

[04:22] can limit the overall throughput of the system. So, here’s an example. Suppose common thing is to take a workload and split it up across several nodes, which do intensive computation using their GPUs for some period of time. And then once they’ve all finished their computation, you do some small exchange between the nodes to exchange data and metadata, and then they’ll go on to the next round of computation. And while that exchange is happening, that synchronization is happening, the GPUs are sitting idle. So, if even one of those exchanges takes a

[04:55] long time, it turns out the whole process stalls. You need all of those exchanges to complete before you can go on to the next phase of computation. Now, if the computation phase is, say, 5 seconds, and it takes a few milliseconds for the exchange, you know, not a not a problem. And that’s historically what it’s been. But now with the agentic workloads, where you’re trying to pump out tokens relatively rapidly at a regular rate, the periods of computation are getting down into sort of the millisecond time scale. And if it also takes milliseconds to do that synchronization,

[05:28] then you’re wasting a significant fraction of your GPU’s resources waiting for the the synchronization to occur. So, I’m curious. I’d like to just do a quick audience poll here. Is there anybody here where you have reason to believe that the latency of small messages is impacting the overall throughput of your applications? If so, can you just raise your hand? See if there’s anybody out there today. Actually, more hands than I expected. So, quite a few people out there are raising their hands. I think this problem is likely to get worse as the trends continue.

[06:01] So, what’s going on? Why is tail latency bad? Well, typically the cause is congestion resulting from incast. So, incast is when several nodes all decide simultaneously to transfer data to some destination node. And if they all send large messages, well, the links are the same everywhere in the network. So, three nodes can transfer three times as fast as one node can possibly receive. And so, what happens is that packets accumulate at the last hop going to that destination in the top of your

[06:35] access switch at its egress port for the destination node. Then, if some other node decides it wants to send a short message to that same destination, the short message gets stuck behind the long ones in the queue there. And actually, as that causes delay, and in the worst case, so many packets arrive that the switch runs out of buffer space that it has to drop packets, and then there are there timeouts and retransmissions that make everything even worse. So, somehow we need some way to reduce the congestion in those queues. Somehow

[07:10] we have to get the sending nodes to stop sending so fast so the queues don’t just build up without limit. So, the way this is done historically virtually all network protocols before Homa, including TCP and RDMA, congestion control is the responsibility of the sender. So, senders somehow have to figure out that congestion is happening, and then they have to slow down their rate of transmission. Now, you you might wonder, why are senders doing it? Cuz the congestion is way over at the other end of the data center network. How does the the sender find out?

[07:43] Well, in the in the old really old days, the way they would find out is the queues would overflow and packets would get dropped. The sender would detect the packets got lost cuz it wouldn’t get acknowledgements back, and it would assume that means there’s congestion and then slow down its rate of transfer. That’s really expensive. So, today there are better techniques that mostly involve the switches providing information. So, a top of rack switch, when it sees that the queue length for an egress port has reached some threshold or starting to fill long before the queue overflows, it starts marking all of the packets to

[08:15] pass through with what’s called early congestion notification, ECN marking. And so, when those packets pass through to the receiver, the receiver sees the marking in the packets, and then when it communicates back to the sender next, for example, to send an acknowledgement, then it includes that marking that goes back to the sender. And now the sender sees the sender realize, “Oh, there’s congestion someplace. I’ve got to slow down my rate of transmission.” So, that’s the basic idea. Unfortunately, getting this right is really hard, really hard. It’s very hard

[08:47] for the congestion to figure out exactly how to set its rates cuz it gets one bit of information. There’s congestion someplace. And there are multiple senders all sending to the same destination. They’re all trying to make adjustments simultaneously. How much do you cut back? And how do I know when I can ramp up again? And even worse, it’s really hard to do this in a way that’s stable because there’s control lag. That is, it takes time before the sender finds out that there’s congestion. And in fact, using this process, it typically takes several round trips for the sender to gradually adjust its rate

[09:20] to get just the right rate to match the available bandwidth. But by the time you do that, in a network that things have changed. New transmissions have started or old ones have finished. And so, these systems tend to never stabilize. They’re constantly oscillating between sending too too and and too little. And this problem’s been around for a long time. It’s been known in the research community for more than 20 years now. There’ve been tons of papers published on it. There have been some improvements made, that’s undeniable, but we’re still a long ways from anything that works well.

[09:50] And the problem is with the fundamental nature of it doing the the congestion control at the sender side. It just doesn’t work very well. So, you end up with a lot of queue build-up. And in fact, you can see the only way to find out that there’s congestion is if there’s queues. And so, by that point we’re already experiencing delays. So, that’s a problem. Oops. There’s one other problem with TCP and RDMA also is that their their basic data model is a byte stream. Just a stream of bytes with no differentiation in it. So, if you send a series of messages say through a TCP socket, they get serialized into that

[10:24] stream. And on this slide, I’ve you know, I’ve shown the messages appear like they have different colors in the stream. Well, there are no colors in real life. TCP has no idea where the message boundaries are. And that also makes life hard. For example, you don’t know how much more data is coming. If you knew how big the message was, you’d know how much more is coming. And you can’t prioritize short messages, which we’d really like to do, get the short messages through faster. And you can end up with what’s called head-of-line blocking, where somebody sends a series of messages to the same destination and they send two really large ones and then a small one

[10:58] after that, they get stuck behind them in that stream. And so, it gets delayed. And again, you have tail latency issues. So, all in all, TCP and RDMA are just not well suited to this environment. So, what do we do? Well, what I’d like to do next is tell you about a new protocol called Homa that we’ve developed at Stanford, which was based on a completely clean slate redesign for network transport. If you could start from scratch and rethink how you do transport for data centers, how would you do it? And it turns out in

[11:28] Homa, virtually every major design decision is different from TCP and RDMA. TCP for all the amazing things it’s done is just not a good match to today’s data centers, nor RDMA. So, what Homa does particularly well is to manage a combination of large and small messages and to make sure that the messages have rich short messages have really low latency. So, this started off as a PhD dissertation for one of my students, Ben Moazeni, and then the results were so great that I decided to make it my personal project to see if we can get it out of the lab

[12:02] and into production. Uh as you may know, I’m I’m not like most professors in that I love to code, and so I turned this into my my own programming project. I created a kernel module for Linux. I’m currently working through the process of getting that upstreamed into the kernel. It’s available on GitHub for download. So, let me tell you just a little bit about how Homa works. I want to mention three things. First, it’s message-based, not stream-based. >> [clears throat] >> In fact, the fundamental unit at Homa is a remote procedure call, which consists of two things: a request message sent

[12:35] from a client to a server, and then a response message returned back from the server to the client. So, the key thing here is that Homa knows about message lengths. They’re buried in the transport all the way down to the bottom, and this has a bunch of advantages. First, it allows us to predict the future. As soon as a receiver gets the first packet of a message, it knows exactly how much more data the sender wants to send, and that’s so much so much more information for doing congestion control.

[13:05] Second, Homa prioritizes shorter messages. It uses SRPT, shortest remaining processing time first, to try and prioritize shorter messages. And third, because messages are all independent, they’re not serialized into a stream, every message is independent. Shorter messages can bypass long ones, so they don’t get queued behind long messages. The second thing about Homa that’s different is that it controls congestion from the receiver. Now, when you think about it, this makes

[13:36] sense because the congestion happens primarily at that last down link to the receiver. And so, the receiver has way more information. In fact, with Homa, as soon as it gets the first packet of a message, it knows exactly how much more is coming. So, it has essentially complete information about congestion and it can therefore respond to congestion much more quickly and much more precisely. The way things work with Homa is that when a sender has a message to send, it breaks it up into packets, but it only

[14:07] transmits the first few packets, those are called unscheduled packets, to the receiver. Packets after that are called scheduled packets, and they only get transmitted when the receiver asks for them. So, the receiver will send grant packets back. They’ll paste them out and send those back to the sender over time, telling the sender, “It’s now time for you to send me the next chunk of data.” And the receiver can delay those grants. So, for example, if the receiver has 10 messages that are incoming, there’s no point in sending grants to all 10 of

[14:38] them because then you’ll just get congestion in the in the top of rack queues. So, we can use the grants to reduce congestion, and then it can also use the grants to give preference to its most favored messages, which would be the shorter ones. So, it’s a way of of implementing SRPT by favoring short messages. The third aspect of Homa is that it takes advantage of the priority queues in modern switches. So, modern data center switches have more than one queue at each egress port, typically eight, and they can be used in a priority

[15:10] mechanism where packets get transmitted preferentially from the highest priority queue. So, I’ve shown only two queues on the slide here, but typically there’s more than that. You can specify in a packets, using the various fields of the packet, you can specify which queue it should go into. And so, Homa dynamically makes those choices in a way to give priority to shorter messages. So, if we go back to the incast example from a few slides ago, all of those long messages will pile up in the lowest priority queue. But, if there’s a short message coming, it will use a higher priority queue. And so, it will immediately bypass

[15:44] all of the queued packets from the short from the the longer messages and get through to the destination more quickly. So, how much of a difference does this make? Uh here’s a uh this slide I’ve got one sample benchmark that I use as part of my tuning and evaluation of Homa. It consists of a workload of a bunch of machines on a network that are exchanging messages back and forth of different sizes, ranging from very small to very large. And on this graph, you can see on the x-axis is the message length, so from about 50 bytes up to a megabyte. The y-axis shows you the

[16:18] round-trip time for messages of that length. So, this request this uses request and response messages that are the same length. You can see TCP in green, Homa in blue. And the y-axis is is round-trip time, so lower is better. And for each protocol, I’ve got two curves. One curve is the P50 curve, that’s the median latency for messages of this length. And then P99 is the 99th percentile, i.e. tail latency for messages of this length. So, I want to point out two things. First,

[16:49] the P99 for short messages is dramatically better for Homa. So, with TCP, it’s more than a millisecond tail latency, Homa is less than 100 microseconds, about 13 times faster. Second, interestingly, you might think that because Homa favors shorter messages, that long messages suffer and get worse performance. It turns out that’s actually not the case. Even on the longest messages, Homa is almost a factor of two better than TCP. I don’t have time to explain that today, but it has to do with the fact that Homa

[17:20] uses run-to-completion approaches, which are much more effective than fair than the fair scheduling used by TCP. So, just to wrap up, the role of short messages in AI appears to be increasing. I think I think it’s likely that it’s going to continue to increase. We’ll see over the next year or two if that happens. And I just want to pose a question to you, you know, as you’re running your applications and measuring performance and seeing what the bottlenecks are, ask yourself, is high latency for short messages affecting your throughput? If the answer is yes, then just know

[17:54] there is a solution available. You should give Homa a try. You can probably reduce your tail latency by an order of magnitude or more. And by the way, this is Homa is basically my life mission right now. I’ve sort of semi-retired from Stanford, and the reason I did that is so I can spend 100% of my time hacking on Homa. So, I’d be delighted to work with you and help you if you decide you want to experiment with Homa. If you need help getting started, answer questions, bug fixes, whatever, you know, I’d be happy to work with you to try and make you successful with it. So, if that is interesting, feel free to contact me. My email’s on the slide, or you can Google

[18:26] me, too, and find me over the internet. So, thanks very much for listening, and I hope to hear from some of you. >> [music]