AI 클러스터에서 TCP의 종말 — John Ousterhout의 Homa

원문 제목: Homa: The End of TCP for AI Clusters — John Ousterhout, Stanford URL: https://www.youtube.com/watch?v=eZ8WWZzoaR0 날짜: 2026-09-18 채널: aiDotEngineer 발표자: John Ousterhout, Stanford University 명예교수(Emeritus) 영상 길이: 1128초

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 클러스터의 작업 부하가 대형 데이터 전송 중심에서 짧은 메시지 교환 중심으로 이동한다면, TCP와 RDMA의 송신자 중심 혼잡 제어로는 꼬리 지연(tail latency)을 감당할 수 있는가?==

• 학습(training)은 여전히 기가바이트급 그래디언트·가중치 전송이 중심이어서 처리량(throughput)이 중요하다.
• 추론(inference)과 에이전트(agentic workload)는 KV 캐시 조회, 메타데이터 교환, 배리어 동기화 같은 짧은 메시지와 짧은 계산 구간이 늘어나 평균 지연보다 99백분위 지연(P99)이 중요해진다.
• TCP와 RDMA는 스트림·송신자 중심 설계와 선입선출 큐 때문에 긴 메시지와 짧은 메시지를 섞을 때 높은 꼬리 지연과 헤드 오브 라인 블로킹(head-of-line blocking)을 만든다.
• Stanford에서 처음부터 다시 설계한 Homa는 메시지 길이를 아는 수신자 중심 전송, 짧은 메시지 우선 처리(SRPT), 스위치의 우선순위 큐를 결합해 짧은 메시지 P99를 TCP보다 약 13배 낮추고, 긴 메시지도 거의 2배 개선한다.

John Ousterhout는 네트워크 지연이 AI 애플리케이션의 성능을 이미 좌우하며, 추론·에이전트 추세가 계속되면 그 영향이 더 커질 것이라고 주장한다. 발표 초반에는 샌프란시스코 행사장에 설치된 안개 발생기를 보고 “안개 발생기가 있는 강당에서 발표하는 것은 처음”이라며 농담한다. 이후 약 15~20분 동안 작업 부하의 변화, 기존 프로토콜의 한계, Homa의 설계와 측정 결과라는 세 단계로 논리를 전개한다.

1. AI 네트워크 작업 부하의 전환

AI 작업 부하는 여러 기계에 분산될 수밖에 없고, 기계 사이 통신 성능이 애플리케이션 성능을 결정한다. 핵심 지표는 작업의 형태에 따라 처리량에서 지연으로 이동하고 있다.

1.1. 발표의 세 가지 목표와 기존 작업 부하

1. 발표가 세우는 세 가지 주장

   1. 작업 부하가 변한다: 과거에는 대형 전송이 완전히 지배해 처리량이 핵심이었지만, 점점 더 작은 전송이 많아져 지연이 결정적 요인이 된다.
   2. 레거시 프로토콜이 맞지 않는다: TCP와 RDMA(Remote Direct Memory Access)는 오늘날 데이터센터 환경을 위해 만들어지지 않았고, 긴 메시지와 짧은 메시지를 섞으면 꼬리 지연이 매우 높아진다.
   3. Homa가 대안이 된다: Stanford에서 데이터센터용 전송을 클린 슬레이트(clean-slate)로 재설계했으며, 이런 혼합 작업 부하에서 꼬리 지연을 한 자릿수 배수, 즉 한 자릿수 이상 규모로 줄일 수 있다.

2. 역사적으로 지배적이었던 대형 전송

   1. 전송 내용: 모델의 가중치 그래디언트(weight gradient) 같은 데이터가 기계 사이에서 기가바이트 단위로 이동했다.
   2. 처리량 중심의 평가: 파이프를 초당 몇 기가비트(gigabit per second)로 채울 수 있는지가 중요했다. 연결을 설정하고 전송을 시작하는 데 시간이 조금 걸려도 전송 자체가 오래 지속되므로 전체 결과에는 큰 영향을 주지 않았다.
   3. 기존 프로토콜의 적합성: 이런 환경에서는 TCP와 RDMA가 비교적 잘 작동했다. 여기서 RDMA는 오늘날 대부분의 용도에서 쓰이는 RoCE(RDMA over Converged Ethernet)를 뜻한다.

1.2. 추론·에이전트 작업 부하의 세분화

1. 작아지는 계산과 교환

   1. 계산 단위의 세분화: 작업이 더 작은 계산 덩어리와 더 작은 데이터 교환으로 쪼개지고 있다.
   2. 변화가 두드러지는 영역: 추론과 에이전트 작업 부하에서 특히 뚜렷하다. 반면 학습 작업은 여전히 거대한 데이터 전송이 중심이다.

2. 짧은 메시지의 실제 역할

   1. 분산 KV 캐시 조회: 특정 항목이 분산된 KV 캐시(distributed KV cache)에 존재하는지 확인하는 메타데이터 요청이 오간다.
   2. 배리어 동기화: 계산 단계가 끝날 때 여러 노드가 다음 단계로 넘어갈 수 있는지 조정하는 배리어 동기화(barrier synchronization)가 필요하다.
   3. 왕복 지연: 작은 데이터를 네트워크로 보내고, 상대편에서 약간의 계산을 수행한 뒤 작은 결과를 돌려받는 왕복 시간(roundtrip time)이 핵심이 된다.

2. 짧은 메시지 지연이 GPU 처리량을 결정하는 이유

짧은 메시지 환경에서는 평균 지연만 낮추는 것으로 충분하지 않다. 많은 요청 중 가장 늦은 일부가 모든 노드의 다음 계산을 막기 때문에 P99 같은 꼬리 지연이 전체 처리량을 제한한다.

2.1. 동기화와 꼬리 지연

1. P99가 중요한 이유

   1. 평균이 아닌 최악에 가까운 지연: 많은 짧은 메시지를 보냈을 때 모두 빠르게 완료되는지가 중요하며, 대표적으로 99백분위 지연(P99)을 측정한다.
   2. 전체 처리량과의 연결: 단 몇 개의 늦은 메시지도 전체 시스템의 처리량을 제한할 수 있다. 분산 계산은 모든 필요한 교환이 끝나야 다음 단계로 진행하기 때문이다.

2. 노드-계산-교환 패턴

   1. 병렬 계산: 작업을 여러 노드에 나누고 각 노드가 GPU로 일정 시간 집중 계산을 수행한다.
   2. 교환 단계: 모든 노드가 계산을 끝내면 메타데이터를 포함한 작은 데이터를 서로 교환하고 다음 계산 라운드로 넘어간다.
   3. GPU 유휴: 교환·동기화가 진행되는 동안 GPU는 할 일이 없어 대기한다.
   4. 한 개의 지연도 전체를 정지: 여러 교환 중 하나라도 오래 걸리면 모든 교환이 끝날 때까지 프로세스 전체가 멈춘다.

2.2. 에이전트 추론에서의 시간 규모

1. 과거에는 문제가 작았던 이유

   1. 계산 단계가 5초 정도 지속되고 교환에 몇 밀리초가 걸린다면 교환 비용은 무시할 만했다.
   2. 이것이 과거의 전형적인 상황이어서 대형 전송·처리량 최적화만으로도 충분했다.

2. 밀리초 계산과 밀리초 동기화의 충돌

   1. 토큰 생산: 에이전트 작업 부하는 토큰을 비교적 빠르고 일정한 속도로 내보내려 하므로 계산 구간이 밀리초 단위로 줄어든다.
   2. 유의미한 자원 낭비: 계산이 밀리초 단위인데 동기화에도 밀리초가 걸리면 GPU 자원의 상당 부분이 계산이 아니라 동기화 대기에 쓰인다.
   3. 청중 반응: Ousterhout가 짧은 메시지 지연이 애플리케이션 전체 처리량에 영향을 주는 사람에게 손을 들어 달라고 하자 예상보다 많은 참석자가 손을 들었다. 그는 작업 부하 추세가 이어지면 이 문제가 악화될 가능성이 크다고 본다.

3. TCP와 RDMA가 혼합 메시지에서 만드는 병목

짧은 메시지의 꼬리 지연은 주로 인캐스트와 큐 대기에서 발생한다. 기존 프로토콜은 혼잡을 감지한 송신자가 뒤늦게 속도를 조절하는 방식이어서, 수신 링크의 실제 병목을 빠르고 정밀하게 제어하기 어렵다.

3.1. 인캐스트와 마지막 홉 큐

1. 인캐스트(incast)의 구조

   1. 여러 노드가 동시에 하나의 목적지 노드로 데이터를 보내는 상황이다.
   2. 예를 들어 세 송신 노드가 동시에 보내면 세 링크의 합산 유입 속도가 단일 수신 노드가 받을 수 있는 속도의 세 배가 될 수 있다.
   3. 병목은 목적지로 향하는 마지막 다운링크(last downlink), 즉 톱오브랙(top-of-rack) 스위치에서 목적지 노드로 나가는 이그레스 포트(egress port)에 생긴다.

2. 짧은 메시지가 긴 메시지 뒤에 갇히는 과정

   1. 긴 패킷들이 목적지 포트 큐에 차곡차곡 쌓인다.
   2. 다른 노드가 같은 목적지로 짧은 메시지를 보내도 짧은 메시지는 큐의 긴 메시지 뒤에 선다.
   3. 패킷이 너무 많이 유입되면 스위치 버퍼가 가득 차 패킷을 버리고, 타임아웃과 재전송이 이어져 지연이 더 커진다.

3.2. 송신자 중심 혼잡 제어의 지연

1. 전통적 책임 배치

   1. Homa 이전의 사실상 모든 네트워크 프로토콜, TCP와 RDMA를 포함해 혼잡 제어(congestion control)는 송신자 책임이다.
   2. 문제는 혼잡이 데이터센터 네트워크 반대편의 수신 링크에서 발생하는데, 송신자가 그 상태를 직접 보지 못한다는 점이다.

2. 패킷 손실에서 ECN으로의 발전

   1. 초기의 방식: 큐가 넘쳐 패킷이 유실되면 송신자는 ACK를 받지 못한 사실로 손실을 감지하고 혼잡이라고 추정해 전송률을 낮췄다. 이 방식은 비싸고 반응이 늦다.
   2. ECN(Early Congestion Notification): 오늘날에는 톱오브랙 스위치가 큐 길이가 임계치에 도달해 넘치기 훨씬 전부터 패킷에 ECN 표시를 한다.
   3. 정보의 왕복: 수신자가 표시를 확인하고 다음 ACK 같은 응답에 그 표시를 담아 송신자에게 돌려보내면, 송신자가 그제야 어딘가에 혼잡이 있으니 전송 속도를 낮춰야 한다고 판단한다.

3. 제어 루프의 근본적 불안정성

   1. 송신자는 “어딘가에 혼잡이 있다”는 한 비트에 가까운 정보만 받고, 같은 목적지로 보내는 여러 송신자가 동시에 조정한다.
   2. 각 송신자가 얼마나 줄여야 하는지, 언제 다시 속도를 올릴 수 있는지 알기 어렵다.
   3. 혼잡 통지가 송신자에 도착하기까지 제어 지연(control lag)이 있다. 적정 대역폭에 맞추려면 보통 여러 왕복이 걸려 점진적으로 전송률을 조정해야 한다.
   4. 조정이 끝날 즈음에는 새 전송이 시작되거나 기존 전송이 끝나 네트워크 상태가 이미 바뀐다. 결과적으로 시스템은 과도한 전송과 과도한 감속 사이를 계속 진동(oscillation)하고 안정화되지 않는다.
   5. 이 문제는 연구 커뮤니티에서 20년 넘게 알려졌고 수많은 논문과 개선이 있었지만, 송신자 측에서 큐가 생긴 뒤에야 혼잡을 알아내는 근본 구조는 여전히 큐 축적과 지연을 만든다.

3.3. 바이트 스트림과 헤드 오브 라인 블로킹

1. 메시지 경계를 잃는 데이터 모델

   1. TCP와 RDMA의 기본 데이터 모델은 구분 없는 바이트 스트림(byte stream)이다.
   2. TCP 소켓으로 여러 메시지를 보내도 하나의 스트림으로 직렬화된다. 슬라이드에서는 메시지마다 색이 다른 것처럼 그렸지만 실제 TCP에는 그 색, 즉 메시지 경계 정보가 없다.
   3. 수신자는 현재 메시지 뒤에 데이터가 얼마나 더 올지 알 수 없어 전송의 미래 규모를 예측하기 어렵다.

2. 우선순위와 HOL 문제

   1. 짧은 메시지를 먼저 통과시키고 싶어도 스트림만으로는 짧은 메시지를 식별해 우선 처리하기 어렵다.
   2. 한 목적지로 긴 메시지 두 개를 먼저 보내고 짧은 메시지를 뒤에 보내면, 짧은 메시지는 앞선 긴 메시지가 끝날 때까지 스트림 안에서 대기한다.
   3. 이 헤드 오브 라인 블로킹(head-of-line blocking)이 다시 꼬리 지연을 키운다. 따라서 TCP와 RDMA는 혼합 크기 데이터센터 작업 부하에 잘 맞지 않는다.

4. Homa의 클린 슬레이트 전송 설계

Homa는 TCP를 조금 고친 프로토콜이 아니라 데이터센터 전송을 처음부터 다시 생각한 결과다. 거의 모든 주요 설계 결정이 TCP·RDMA와 다르며, 큰 메시지와 작은 메시지를 함께 처리하면서 작은 메시지 지연을 낮추는 데 초점을 둔다.

4.1. 스트림이 아닌 메시지와 RPC

1. 기본 단위의 변경

   1. Homa는 스트림 기반(stream-based)이 아니라 메시지 기반(message-based)이다.
   2. 기본 단위는 원격 프로시저 호출(RPC, remote procedure call)이며, 클라이언트가 서버로 보내는 요청 메시지와 서버가 클라이언트로 돌려보내는 응답 메시지로 구성된다.

2. 메시지 길이를 아는 전송 계층

   1. 메시지 길이 정보가 전송 계층 깊숙한 곳까지 보존된다.
   2. 수신자가 메시지의 첫 패킷을 받는 순간 송신자가 앞으로 얼마나 더 보낼지 정확히 알 수 있다.
   3. 이 정보는 혼잡 제어에 기존 스트림 프로토콜보다 훨씬 풍부한 관측을 제공한다.

3. 짧은 메시지를 위한 세 가지 이점

   1. 미래 예측: 남은 데이터 양을 알 수 있으므로 수신자가 현재·예상 혼잡을 함께 고려할 수 있다.
   2. SRPT 우선순위: Homa는 최단 잔여 처리 시간 우선(SRPT, Shortest Remaining Processing Time)을 사용해 짧은 메시지를 우선한다.
   3. 독립성과 우회: 메시지가 스트림에 직렬화되지 않고 서로 독립적이므로 짧은 메시지가 긴 메시지를 우회할 수 있다.

4.2. 수신자 중심 혼잡 제어

1. 혼잡이 생기는 위치에 책임을 둔다

   1. 혼잡은 주로 수신자에게 들어가는 마지막 다운링크에서 발생한다.
   2. 그러므로 그 위치를 직접 관찰하는 수신자가 송신자보다 훨씬 많은 정보를 가진다.

2. 빠르고 정밀한 판단

   1. 수신자는 첫 패킷에서 이미 전체 메시지 길이와 남은 양을 안다.
   2. 이 사실상 완전한 혼잡 정보를 이용해 어느 송신자에게 언제 더 보내도 되는지 빠르고 정밀하게 결정한다.
   3. 송신자가 여러 왕복 뒤 간접적으로 상태를 추정하는 TCP/RDMA의 제어 루프와 대조된다.

4.3. 비예약·예약 패킷과 그랜트

1. 두 종류의 전송 패킷

   1. 송신자가 메시지를 패킷으로 쪼갠 뒤 처음 몇 패킷만 수신자에게 바로 보낸다. 이것이 비예약 패킷(unscheduled packet)이다.
   2. 그 뒤의 예약 패킷(scheduled packet)은 수신자가 전송을 허가할 때만 보내진다.

2. 수신자가 보내는 그랜트(grant)

   1. 수신자는 그랜트 패킷을 송신자에게 돌려보내며 “이제 다음 데이터 덩어리를 보내라”고 알려준다.
   2. 그랜트를 한꺼번에 보내지 않고 시간에 따라 나눠 보내며, 이를 통해 목적지 쪽 큐가 감당할 수 있는 속도로 유입을 조절한다.
   3. 수신자에게 열 개의 메시지가 들어오는 상황에서 열 개 모두에 즉시 그랜트를 보내면 톱오브랙 큐에 다시 혼잡이 생긴다. 수신자는 그랜트 발급 자체를 늦춰 혼잡을 줄일 수 있다.
   4. 그랜트 순서를 조절해 선호하는 메시지, 특히 더 짧은 메시지에 먼저 자원을 주면 SRPT를 실제 전송 순서로 구현할 수 있다.

4.4. 스위치 우선순위 큐 활용

1. 현대 스위치의 하드웨어 기능

   1. 데이터센터 스위치는 이그레스 포트마다 보통 하나가 아닌 여러 개, 전형적으로 8개의 큐를 가진다.
   2. 우선순위 메커니즘에서는 가장 높은 우선순위 큐의 패킷을 먼저 전송한다.
   3. 패킷 필드의 여러 값을 이용해 어느 큐에 들어갈지 지정할 수 있다.

2. Homa의 동적 매핑

   1. Homa는 메시지 길이에 따라 우선순위 큐를 동적으로 선택해 짧은 메시지에 높은 우선순위를 준다.
   2. 인캐스트 상황에서 긴 메시지는 가장 낮은 우선순위 큐에 쌓인다.
   3. 짧은 메시지가 도착하면 더 높은 큐를 사용해 긴 메시지의 대기 패킷을 즉시 우회하고 목적지로 더 빠르게 통과한다.

5. 벤치마크와 측정 결과

Homa는 짧은 메시지를 우대하면서도 긴 메시지를 희생하지 않는다. Ousterhout가 튜닝과 평가에 사용하는 혼합 작업 부하 벤치마크는 메시지 크기 전 구간에서 TCP와 Homa의 중앙값과 꼬리 지연을 비교한다.

5.1. 실험 구성과 지표

1. 혼합 메시지 작업 부하

   1. 네트워크에 연결된 여러 기계가 매우 작은 메시지부터 매우 큰 메시지까지 서로 다른 크기의 메시지를 주고받는다.
   2. 요청(request)과 응답(response)은 같은 길이로 구성된다.

2. 그래프의 축과 곡선

   1. x축은 약 50바이트에서 1메가바이트까지의 메시지 길이다.
   2. y축은 해당 길이 메시지의 왕복 시간이며 낮을수록 좋다.
   3. TCP는 녹색, Homa는 파란색으로 표시된다.
   4. 각 프로토콜에는 두 곡선이 있다. P50은 중앙값 지연(median latency), P99는 99백분위 꼬리 지연이다.

5.2. 짧은 메시지와 긴 메시지의 결과

1. 짧은 메시지 P99의 큰 개선

   1. TCP의 짧은 메시지 꼬리 지연은 1밀리초를 넘는다.
   2. Homa는 100마이크로초(0.1밀리초)보다 낮다.
   3. 발표자는 이를 약 13배 빠른 결과로 설명한다. 즉, 인캐스트로 긴 패킷이 쌓여도 Homa의 수신자 제어·SRPT·우선순위 큐 조합은 짧은 메시지의 대기를 크게 줄인다.

2. 긴 메시지를 희생하지 않는 우선순위

   1. 짧은 메시지를 우선하면 긴 메시지가 느려질 것 같지만, 측정 결과 긴 메시지에서도 Homa가 TCP보다 거의 2배 낫다.
   2. 발표자는 그 이유를 자세히 설명할 시간은 없다고 전제하면서, Homa의 완료까지 실행(run-to-completion) 방식이 TCP의 공정 스케줄링(fair scheduling)보다 효과적이기 때문이라고 덧붙인다.

6. 구현 경로와 적용 권고

Homa는 연구 논문에 머물지 않고 실제 Linux 환경에서 시험할 수 있는 구현으로 이어지고 있다. Ousterhout는 직접 코드를 작성하며 사용자와 함께 실험하려 한다.

6.1. 연구에서 커널 구현으로

1. 출발점

   1. Homa는 Ousterhout의 학생 Benam Montazeri의 박사학위 논문으로 시작했다.
   2. 결과가 매우 좋아 Ousterhout가 연구실 밖, 실제 프로덕션으로 가져가는 일을 개인 프로젝트로 맡았다.

2. 공개 구현

   1. Ousterhout는 자신이 대부분의 교수와 달리 코딩을 좋아한다고 말하며 Homa를 직접 프로그래밍 프로젝트로 전환했다.
   2. Linux 커널 모듈을 만들었고 현재 Linux 커널 메인라인(upstream) 반영 절차를 진행 중이다.
   3. 구현은 GitHub에서 내려받을 수 있다.

6.2. 청중에게 제시한 실무 질문

1. 측정으로 병목 확인

   1. 애플리케이션을 실행하고 성능을 측정할 때 짧은 메시지의 높은 지연이 처리량을 떨어뜨리는지 확인해야 한다.
   2. 특히 밀리초 단위 계산 구간과 동기화 구간을 분리해 GPU가 네트워크 대기로 유휴 상태가 되는지 관찰해야 한다.

2. Homa 시험의 조건

   1. 짧은 메시지 고지연이 처리량에 영향을 준다는 답이 나오면 Homa를 시험해 볼 수 있다.
   2. 기대 가능한 개선 폭은 꼬리 지연 한 자릿수 배수 이상이며, 실제 효과는 애플리케이션의 메시지 크기 분포와 인캐스트 패턴으로 검증해야 한다.
   3. Ousterhout는 Homa 실험을 시작하는 방법, 질문, 버그 수정 등 성공에 필요한 도움을 제공하겠다고 했다.

주요 발언 모음

“AI 작업 부하는 변하고 있다. 예전에는 처리량이 핵심인 대형 전송이 지배적이었지만, 이제는 지연이 결정적인 더 작은 전송을 점점 더 많이 보고 있다.”

“짧은 메시지의 지연이 높으면 시스템 전체의 처리량이 제한될 수 있다.”

“Homa의 기본 단위는 스트림이 아니라 메시지이며, 메시지 길이를 전송 계층 깊숙한 곳까지 알고 있다.”

“혼잡은 주로 수신자로 향하는 마지막 다운링크에서 발생하므로 수신자가 훨씬 더 많은 정보를 가진다.”

“짧은 메시지의 높은 지연이 처리량에 영향을 준다면, 해결책이 있다. Homa를 시험해 보라.”

“Homa는 지금 내 삶의 사명이다. Stanford에서 반쯤 은퇴한 이유는 시간의 100%를 Homa 해킹에 쓸 수 있도록 하기 위해서다.”

핵심 데이터 & 수치

• 영상 길이: 1128초, 약 18분 48초로 안내됨.
• 기존 계산 구간 예시: 약 5초 계산 뒤 몇 밀리초 교환이면 과거에는 문제가 되지 않았다.
• 새 작업 부하의 시간 규모: 에이전트 토큰 생성의 계산 구간과 동기화가 밀리초 단위로 내려간다.
• P99 기준: 혼합 메시지 벤치마크는 중앙값 P50과 99백분위 P99를 함께 측정한다.
• 메시지 크기 범위: 약 50바이트부터 1메가바이트.
• TCP 짧은 메시지 P99: 1밀리초 초과.
• Homa 짧은 메시지 P99: 100마이크로초 미만, TCP보다 약 13배 빠름.
• 긴 메시지: Homa가 TCP보다 거의 2배 우수함.
• 스위치 우선순위 큐: 이그레스 포트마다 전형적으로 8개 이상.
• 혼잡 제어 역사: 송신자 중심 제어의 문제는 연구 커뮤니티에서 20년 넘게 알려짐.
• Homa 구현 상태: Linux 커널 모듈이 공개되어 있고 메인라인 업스트림 절차가 진행 중임.

결론 및 시사점

1. AI 네트워크의 최적화 목표를 분리하라: 학습의 대형 그래디언트 전송은 처리량이 핵심이지만, 추론·에이전트의 메타데이터와 동기화는 왕복 지연과 P99가 핵심이다.
2. 평균값만 보지 마라: 분산 GPU 파이프라인에서는 한 개의 느린 교환이 모든 노드의 다음 계산을 막으므로 P99를 애플리케이션 처리량과 함께 측정해야 한다.
3. 인캐스트를 병목의 출발점으로 분석하라: 여러 송신자가 한 수신자에게 동시에 보내는 마지막 홉에서 긴 패킷 큐가 짧은 메시지를 가로막고, 버퍼 고갈·손실·타임아웃·재전송으로 문제가 증폭된다.
4. 제어 위치와 정보량이 중요하다: 송신자가 여러 왕복 뒤 ECN을 받아 속도를 조절하는 구조보다, 메시지 길이와 수신 큐를 직접 아는 수신자가 그랜트를 배분하는 구조가 데이터센터 혼잡에 적합하다.
5. 메시지 경계를 보존하라: 스트림에 메시지를 섞으면 짧은 요청을 식별하거나 긴 메시지를 우회시키기 어렵다. 메시지 기반 RPC와 SRPT는 짧은 메시지를 독립적으로 처리할 수 있게 한다.
6. 하드웨어 우선순위 큐를 소프트웨어 정책과 결합하라: Homa는 수신자 그랜트 정책과 스위치의 다중 우선순위 큐를 함께 사용해 긴 전송을 낮은 큐에 두고 짧은 전송을 앞세운다.
7. 짧은 메시지 우선이 긴 메시지의 희생을 뜻하지는 않는다: 벤치마크에서 Homa는 짧은 메시지 P99를 약 13배 낮추면서 긴 메시지도 TCP보다 거의 2배 빠르게 처리했다.
8. 실제 클러스터에서 검증하라: 메시지 크기 분포, 동시 송신자 수, GPU 계산·동기화 주기를 측정한 뒤 Homa의 Linux 구현을 시험해 꼬리 지연과 GPU 유휴 시간을 비교해야 한다.