AI 클러스터는 TCP를 버려야 할까? Homa의 장점과 도입 장벽

핵심 요약

Homa는 메시지 단위로 통신하며, 수신 측이 후속 데이터 전송과 우선순위를 조율합니다.
짧은 메시지를 우대해 혼잡할 때 작은 요청이 오래 기다리는 문제를 줄이려는 설계입니다.
AI 클러스터에서는 통신 패턴과 GPU 연결 경로에 따라 프로토콜 교체의 효과가 달라집니다.
도입 여부는 애플리케이션 수정과 운영에 드는 비용까지 따져 보고, 전체 작업 완료 시간을 기준으로 판단해야 합니다.

비싼 GPU가 데이터를 기다리느라 멈춰 있다면 네트워크도 연산 성능의 일부입니다. 익숙한 TCP를 Homa로 바꾸면 AI 클러스터가 더 빨라질까요? 전송 속도만으로는 답하기 어렵습니다. 어떤 데이터가 어디에서 기다리는지부터 살펴봐야 합니다.

TCP와 Homa는 데이터를 보는 단위가 다릅니다

TCP는 데이터를 순서가 있는 바이트 스트림으로 전달합니다. 애플리케이션이 보낸 내용을 하나의 연속된 데이터 흐름으로 다룬다는 뜻입니다. 요청 하나가 어디서 끝나는지는 애플리케이션이 따로 구분해야 합니다.

Homa의 기본 단위는 메시지입니다. 주로 다른 서버에 작업을 요청하고 응답을 받는 RPC 통신을 위해 설계됐습니다. RPC는 쉽게 말해 네트워크 건너편의 프로그램에 일을 부탁하는 방식입니다.

메시지의 경계를 알면 전송 순서를 정하기가 수월합니다. 작은 요청인지, 아직 보낼 데이터가 많이 남은 메시지인지 구분할 수 있기 때문입니다. Homa는 이 정보를 바탕으로 수신 측이 후속 데이터의 전송량과 우선순위를 조율하게 합니다.

택배에 비유하면 TCP는 물건을 순서대로 전달하는 운송 체계에 가깝습니다. Homa는 상자마다 크기를 살펴보고, 받는 쪽이 처리할 수 있는 여건에 맞춰 배송 순서까지 조정하는 방식입니다.

Homa의 승부처는 작은 메시지의 대기 시간입니다

가령 4KB짜리 조회 응답과 4MB짜리 데이터 전송이 같은 네트워크 링크를 쓴다고 해보겠습니다. 작은 응답은 금방 보낼 수 있습니다. 하지만 네트워크가 혼잡하면 실제로 데이터를 보내는 시간보다 차례를 기다리는 시간이 더 길어질 수 있습니다.

Homa는 짧게 끝낼 수 있는 메시지를 우대합니다. 수신 측에서 전송을 제어하고 네트워크에서 우선순위에 따라 처리하는 방식을 함께 써서, 작은 메시지가 기다리는 시간을 줄이려 합니다.

이때 살펴볼 지표가 꼬리 지연입니다. 대부분의 요청은 빨리 끝나는데 일부 요청만 유난히 늦게 끝나는 현상을 가리킵니다. 여러 서버의 응답을 모두 모아야 다음 단계로 넘어갈 수 있는 작업이라면, 느린 응답 하나 때문에 전체 작업이 기다려야 할 수 있습니다.

그렇다고 이런 설계만으로 “TCP보다 몇 배 빠르다”고 결론 내릴 수는 없습니다. 메시지 크기가 어떻게 분포하는지, 네트워크에 부하가 얼마나 걸리는지에 따라 결과가 달라집니다. 비교 대상 TCP의 혼잡 제어와 시스템 설정도 함께 봐야 합니다.

AI 클러스터에서는 무엇을 보내는지가 먼저입니다

AI 클러스터 안에는 서로 다른 통신이 섞여 있습니다. 작업을 배정하는 짧은 요청도 있고, 여러 GPU가 학습 결과를 합치는 대규모 전송도 있습니다. 같은 네트워크를 쓰더라도 어떤 통신이냐에 따라 중요한 성능 지표가 다릅니다.

짧은 요청이 도착해야 다음 연산을 시작할 수 있다면, 그 요청의 대기 시간을 줄이는 것이 의미 있을 수 있습니다. 큰 데이터를 계속 보내는 구간에서는 링크를 얼마나 효율적으로 쓰는지가 더 중요할 수 있습니다.

여러 GPU의 값을 모아 합산하는 AllReduce 같은 집단 통신도 따져봐야 합니다. 작업이 끝나는 데 걸리는 시간은 전송 프로토콜만으로 정해지지 않습니다. 통신 알고리즘과 GPU 배치도 영향을 주고, 네트워크 연결 구조에 따라 특정 구간으로 트래픽이 몰릴 수도 있습니다.

GPU 사이의 통신 경로가 반드시 TCP인 것도 아닙니다. RDMA를 사용하는 구간도 있습니다. RDMA는 원격 장치의 메모리와 데이터를 주고받을 때 CPU와 운영체제의 개입을 줄이는 통신 방식입니다.

따라서 “우리 클러스터가 TCP를 쓰는가”만 확인해서는 부족합니다. GPU를 기다리게 만드는 바로 그 구간이 어떤 통신 경로를 사용하는가까지 알아야 합니다. Homa의 장점이 나타나는 구간과 실제 병목이 겹쳐야 전체 작업이 빨라집니다.

도입의 벽은 프로토콜 바깥에도 있습니다

애플리케이션부터 살펴봐야 합니다. TCP의 연속된 데이터 흐름을 전제로 만든 프로그램은 Homa의 메시지 기반 인터페이스에 맞게 수정해야 할 수 있습니다. 기존 통신 라이브러리와 어떻게 연결할지도 확인해야 합니다.

네트워크 설정도 중요합니다. Homa의 우선순위 설계가 효과를 내려면 스위치의 우선순위 큐를 적절하게 써야 합니다. 다른 서비스와 같은 네트워크를 쓴다면 서로의 트래픽이 섞였을 때 어떻게 동작하는지도 살펴봐야 합니다.

운영 경험의 차이도 있습니다. TCP에는 오랫동안 쌓인 진단 도구와 장애 대응 절차가 있습니다. 새로운 전송 체계를 도입하려면 성능을 측정하는 데서 더 나아가, 패킷 손실이나 과부하가 생겼을 때 상황을 파악할 수 있는 관측 수단도 갖춰야 합니다.

그래서 도입을 검증할 때 작은 메시지의 지연만 재고 끝내서는 안 됩니다. 실제 작업을 실행하면서 GPU가 기다리는 시간과 전체 작업이 끝나는 데 걸리는 시간을 함께 비교해야 합니다. 메시지가 빨리 도착해도 다른 병목이 그대로라면 학습이나 추론 작업의 완료 시간은 크게 달라지지 않을 수 있습니다.

저는 Homa를 특정 통신 병목을 해결할 후보로 놓고 평가해야 한다고 봅니다. TCP 교체의 가치는 전체 작업이 얼마나 빨라지는지, 그 개선이 도입과 운영 비용을 감당할 만한지에 달려 있습니다. 그러려면 클러스터에서 GPU가 기다리는 이유가 작은 메시지의 지연인지, 큰 데이터의 전송 시간인지부터 확인해야 합니다.