스탠퍼드 Ousterhout의 "TCP는 AI 클러스터의 병목" Homa 강연, HN에서 설계 비판까지

lwn.net 기사랑 USENIX ATC21 Ousterhout 논문 링크 같이 올려준 사람 덕에 원문 바로 읽었음.

그 링크들 좋아서 toptext에도 추가했음.

Jane Street 팟캐스트에서 Ron Minsky가 몇 달 전에 같은 얘기 했었음. 회로 교환이 패킷 교환에 밀린 게 트래픽이 너무 랜덤해서였는데, AI 클러스터는 흐름이 훨씬 예측 가능하니까 맞춤 구현이 훨씬 잘 먹힌다는 거.

Google TPU는 광 라우팅 되는 광섬유로 회로 교환처럼 토폴로지 자체를 학습 부하에 맞춰 바꾼다고 들었음.

영상 말고 글로 된 링크를 본문에 걸어줘.

Homa는 2018년 논문부터 있었음. 메시지를 첫 RTTbytes만큼 unscheduled로 먼저 보내고 나머지는 수신자가 GRANT 패킷으로 요청해야 보내는 구조임. 짧은 RPC에는 맞고 QNX 네트워킹이랑 비슷함.

예전 소프트웨어 스위치는 패킷당 비용이 커서 작은 패킷이 손해였는데, 요즘 하드웨어 스위치는 FPGA가 처리하니까 그 비용이 낮아져서 지금 통하는 거임.

QNX 언급 반갑다. RT 제어 쪽에서 잘 썼음. 요약도 고맙고.

패킷 크기는 TCP든 Homa든 같은 게 맞고, 차이는 송신자 기반이냐 수신자 기반 혼잡 제어냐임.

6분쯤에 혼잡 제어는 송신자 책임이라고 하는데, RoCE나 이더넷 PFC에는 그런 게 없는 건가? InfiniBand는 크레딧 기반으로 무손실 보장한다고 알고 있음.

문제는 목적지가 아니라 중간 링크나 스위치임. RoCE 대규모로 한 번 썼는데 pause frame 파도가 몰려오면 다 멈춰버렸음.

flow control은 없는 것보단 낫지만 혼잡이 번지고 버퍼블로트가 생김. QCN이나 Falcon, Ultra Ethernet이 RoCE에는 더 낫지만 Homa보다 최신 하드웨어가 필요함.

이더넷 flow control은 특수한 경우 빼면 혼잡을 못 고침. A랑 B가 C로 보내는데 S1-S2 링크가 꽉 차면 S2가 S1로 pause를 보내도 D로 가는 트래픽까지 멈춤. 병목만 옮기고 주변을 망치는 셈임.

Homa 설계는 별로임. 연결 상태가 없어서 RPC 패킷이 전부 유실되면 서버가 재전송할 방법이 없고, 암호화도 없어서 위나 아래에 따로 얹어야 함. 60kB 평균 메시지 벤치마크는 5 하이퍼스레드로 20 Gbit/s, 스레드당 4 Gbit/s밖에 안 나옴.

시스템 콜당 패킷 하나짜리 순진한 구현도 하이퍼스레드당 8 Gbit/s는 나옴. 조금만 신경 쓰면 30 Gbit/s도 쉽고.

QUIC이 훨씬 유명한데 여기 쓰면 단점이 있나?

타임아웃을 TCP SYN처럼 걸어야 함. TCP도 암호화는 없음. QUIC이 빠르다고 테스트 없이 말하면 안 됨.

노드 사이 통신에 암호화를 왜 함?

Homa를 몇 년째 듣고 있었는데 뭐가 새로운지 궁금했음. git 저장소 README에 changelog가 있어서 그걸 봤음.

LLM이 가중치 그라디언트나 모델 가중치, KV 캐시, 체크포인트를 Homa 같은 걸로 옮기게 되면 post-training 상호작용에서도 TCP가 병목이 될지 궁금함.