como o protocolo homa tcp reduz latência de cauda

O protocolo Homa, desenvolvido em Stanford, promete reduzir a latência de cauda de mensagens curtas em clusters de IA em uma ordem de grandeza ou mais, onde o TCP oscila. A tese de John Ousterhout é direta: cargas de inferência e agentes agora misturam transfers gigantes com trocas de milissegundos, e o transporte legado não foi feito para isso.

Protocolo Homa ou TCP: o que muda para clusters de IA

O protocolo Homa reduz a latência de cauda de mensagens curtas em data centers onde o TCP sofre, chegando a ganhos de uma ordem de grandeza nos testes do próprio autor. A tese vem de John Ousterhout, professor emérito de Stanford, criador do Raft e do Tcl, que apresentou o argumento em palestra sobre redes para cargas de IA.

O argumento não é que o TCP seja ruim. Ele sustenta a internet há décadas e funciona bem em transfers enormes, onde o que importa é vazão. O problema é outro: as cargas de IA estão mudando de forma, e o transporte legado não acompanhou essa mudança.

Por que as cargas de trabalho de IA estão mudando

As cargas de IA deixaram de ser dominadas apenas por transfers gigantes e hoje misturam trocas cada vez menores. No treinamento distribuído, gradientes de pesos e sincronizações movem gigabytes entre máquinas, e nesse cenário o TCP e o RDMA performam bem: se a conexão demora alguns milissegundos para ser configurada, o transfer de vários segundos absorve o custo.

O que mudou é o crescimento da inferência e dos workloads agênticos. Agentes geram tokens em ciclos regulares e curtos, com trocas de metadados entre nós: verificar se uma entrada existe numa KV cache distribuída, fazer sincronização de barreira ao fim de um período de computação. Essas trocas duram milissegundos.

A consequência é matemática. Se o ciclo de computação durava 5 segundos e a sincronização 2 milissegundos, o tempo ocioso da GPU era desprezível. Quando o ciclo cai para a escala de milissegundos, a mesma sincronização consome uma fração significativa dos recursos. E não basta a latência média ser baixa: se uma única troca demorar, todo o cluster espera por ela.

Como o incast cria latência de cauda

O incast é a causa típica da latência de cauda: vários nós transmitem simultaneamente para o mesmo destino. Como todos os enlaces da rede têm a mesma capacidade, três nós podem enviar três vezes mais rápido do que um único nó consegue receber. Os pacotes se acumulam no switch top-of-rack, na porta de saída do destino.

Quando um nó resolve mandar uma mensagem curta para esse mesmo destino, ela entra na fila atrás dos pacotes das mensagens longas. No pior caso, o buffer do switch estoura, pacotes são descartados e entram timeouts e retransmissões, que pioram tudo.

O problema é conhecido há mais de 20 anos na comunidade acadêmica e gerou dezenas de papers, com melhorias reais ao longo do caminho. Segundo Ousterhout, porém, nenhuma abordagem baseada em controle pelo emissor resolve o problema de raiz.

Por que TCP e RDMA sofrem com mensagens curtas

O TCP e o RDMA, mais precisamente o RoCE (RDMA over Converged Ethernet), usado como transporte do RDMA na maior parte das implantações atuais, carregam dois defeitos estruturais para esse cenário.

O primeiro é o controle de congestionamento no emissor. O congestionamento acontece no último salto, perto do receptor, mas quem precisa frear é o emissor, do outro lado do data center. Hoje o mecanismo comum é o ECN: o switch marca pacotes quando a fila passa de um limiar, o receptor devolve a marcação ao emissor e este reduz a taxa. O problema é a informação mínima, um bit de congestionamento, e o atraso de controle: o emissor leva vários round-trips para ajustar a taxa, e quando ajusta, a rede já mudou. Os sistemas oscilam entre mandar demais e de menos, sem nunca estabilizar.

O segundo defeito é o modelo de dados. O TCP trabalha com um fluxo de bytes sem fronteiras de mensagem. As mensagens são serializadas no stream: o transporte não sabe o tamanho de cada uma, não pode priorizar as curtas e não permite que uma mensagem pequena ultrapasse uma grande. O resultado é o head-of-line blocking, a mensagem curta presa atrás de duas gigantes na mesma fila.

Como o Homa funciona: três decisões de design

O Homa é um redesenho limpo do transporte para data centers, praticamente toda decisão diverge do TCP. O projeto nasceu na tese de doutorado de Behnam Montazeri, orientado por Ousterhout, publicada no SIGCOMM de 2018, e virou o projeto pessoal do professor. Três decisões explicam o funcionamento.

Baseado em mensagens e RPCs

A unidade fundamental é uma chamada de procedimento remota: uma mensagem de requisição do cliente ao servidor e a resposta de volta. O Homa conhece o tamanho das mensagens desde o primeiro pacote, o que dá ao receptor informação completa para prever o que vem e priorizar mensagens curtas via SRPT (shortest remaining processing time first). Como cada mensagem é independente, as curtas não ficam presas atrás das longas.

Controle de congestionamento no receptor

O emissor transmite apenas os primeiros pacotes, chamados de unscheduled. O restante só sai quando o receptor pede, por meio de pacotes de grant que liberam os próximos blocos. Com isso, o receptor, que sabe exatamente quanto dado está chegando, dosa os grants para evitar congestionamento e favorecer suas mensagens preferidas.

Filas de prioridade nos switches

Switches modernos têm várias filas por porta de saída, tipicamente oito. O Homa direciona dinamicamente os pacotes: mensagens longas vão para a fila de menor prioridade, e uma mensagem curta entra numa fila alta e ultrapassa todo o acúmulo. Em vez de adivinhar a taxa certa, o protocolo transforma a priorização em Mecanismo explícito do hardware.

O que dizem os benchmarks do Homa

O benchmark citado por Ousterhout é de uso próprio dele, para ajuste e avaliação do Homa: várias máquinas trocam mensagens de tamanhos variados, de cerca de 50 bytes a 1 megabyte, medindo a latência de round-trip com requisição e resposta do mesmo tamanho. Os números abaixo são, portanto, medições do próprio autor, ainda não reproduzidas de forma independente aqui.

Para mensagens curtas, o P99 do TCP passava de 1 milissegundo; o do Homa ficava abaixo de 100 microssegundos, cerca de 13 vezes melhor. E contra a intuição, as mensagens longas também ganham: nas maiores, o Homa chega perto de 2 vezes menos latência que o TCP, o que o autor atribui à execução até o fim (run to completion) em vez do escalonamento justo usado pelo TCP.

Um alerta de honestidade: esses resultados vêm da implementação de referência do projeto e de quem o criou. Independentemente do número exato, a direção é consistente com a literatura de transporte orientado a receptor publicada desde o SIGCOMM de 2018.

Estado atual do projeto no GitHub

O Homa não é só paper. Ousterhout implementou o protocolo como módulo de kernel para Linux, disponível no repositório oficial no GitHub, e o site do projeto Homa documenta o protocolo e as implementações. Ele relatou estar trabalhando no processo de subir o código para o kernel principal do Linux, o que ainda não é um fato consumado: quem avaliar hoje deve tratar o Homa como módulo externo.

Ele também disse ter se semi-aposentado de Stanford para dedicar 100% do tempo ao projeto, oferecendo suporte direto a quem quiser experimentar. Para um protocolo de infraestrutura, ter o autor disponível para dúvidas e correções é um diferencial raro.

Vale a pena testar o Homa no seu cluster?

A resposta depende de um diagnóstico simples, e a própria palestra sugere o caminho. Antes de trocar qualquer protocolo, meça.

1. Meça a latência P99 das mensagens curtas no seu ambiente, não só a média, usando a ferramenta de benchmark do repositório.

2. Verifique se há períodos de sincronização em que as GPUs ficam ociosas esperando a rede, sobretudo em inferência e workloads agênticos.

3. Compare a duração dos ciclos de computação com a latência das trocas: se ambos estão na escala de milissegundos, há desperdício.

4. Se o gargalo existir, teste o Homa num subconjunto do cluster e compare contra o TCP com a mesma carga.

Se a sua carga continua sendo treinamento com transfers massivos, o TCP e o RoCE seguem adequados, e a troca não traz benefício claro. O Homa resolve um problema específico, não todos.

Perguntas frequentes sobre o Homa e o TCP

• O Homa substitui o TCP na internet? Não. O Homa foi projetado para data centers, onde o operador controla switches e hosts. O TCP segue como transporte da internet e para cargas de vazão pura.

• O Homa já está no kernel do Linux? Ainda não como parte integrante. O código existe como módulo de kernel externo no repositório do projeto, e o autor relatou trabalhar para enviá-lo ao kernel principal.

• Os ganhos de 13x valem para qualquer workload? Não. O número vem de um benchmark específico do próprio autor, com mensagens de 50 bytes a 1 MB em round-trip. Resultados no seu cluster podem diferir e precisam ser medidos.

• O que é exatamente a latência de cauda (P99)? É o 99º percentil: 99% das mensagens completam mais rápido que esse valor. Em cargas síncronas, uma única mensagem acima do P99 trava o ciclo inteiro.

• O RDMA também é afetado? Sim, segundo o autor. O RoCE usa o mesmo modelo de controle de congestionamento pelo emissor e o mesmo tipo de limitação quando mensagens curtas dividem a rede com transfers longos.

Transforme palestras técnicas em artigos com o Skala Blog

A palestra de Ousterhout condensa anos de pesquisa em vinte minutos, e foi assim que este artigo nasceu: um vídeo de conferência convertido em material pesquisável. Se você acompanha canais como o Crazystack Typescript, do Gustavo Dev Doido, e o Bootcamp do Dev Doido, já sabe quanto conhecimento valioso fica preso dentro de vídeos que ninguém encontra por busca.

O Skala Blog resolve isso com um fluxo simples: você cola a URL de um vídeo do YouTube, a plataforma transcreve o conteúdo e gera um artigo estruturado, com títulos, fontes e seções prontas para revisão. Vale para aulas, entrevistas, opiniões e aqueles materiais técnicos que merecem existir também em texto. Experimente com um vídeo que você já considera indispensável e veja o que ele vira no papel.

Source video