ARK는 KV 캐시 대형 플로우를 스파인 예약으로 분산해 TTFT를 줄인다

무엇인가

Prefill과 decode를 서로 다른 GPU 풀에 나눠 배치하는 분리형(disaggregated) LLM 서빙에서는 prefill GPU가 만든 KV 캐시를 디코드 GPU로 네트워크 너머 전송해야 한다. 이 논문이 겨냥하는 문제는 그 전송량이 더 이상 일반적인 데이터센터 트래픽이 아니라는 데 있다. LLaMA-3.1-405B 기준 토큰당 KV 캐시가 504KB이고, 100K 토큰짜리 요청 하나면 48GB에 달한다. 400Gbps 링크를 960ms 동안 포화시키는 크기이며, 전송이 끝나야 토큰 생성이 시작되므로 전송 시간 증가가 곧 TTFT 증가와 SLO 위반으로 이어진다.

어떻게 동작하나

문제는 프로덕션 패브릭이 여전히 5-튬플 해시 기반의 무상태 ECMP를 쓴다는 점이다. 해시는 플로우 크기를 모르기 때문에 두 개의 거대 KV 플로우가 같은 스파인으로 몰리면 그 링크만 몇 초간 포화되고 나머지 스파인은 놀게 된다. 기존 해법들은 비용이 크다. CONGA는 커스텀 leaf ASIC을, ConWeave는 프로그래머블 ToR과 재정렬 버퍼를, LetFlow는 스위치 단의 flowlet 감지를 요구한다. 패킷 스프레이는 순서가 뒤바뀌어 수신 측 재조립 부담이 크고, 호스트 측 PLB는 ECN 마킹이 여러 라운드 연속으로 찍힌 뒤 연결이 유휴 상태일 때만 경로를 바꾸는 반응형 방식이라 유휴 구간이 거의 없는 RDMA 기반 KV 전송에는 잘 맞지 않는다.

무엇과 다른가

저자들이 주목한 것은 이 워크로드의 두 가지 성질이다. 첫째, KV 플로우는 수백 ms에서 수 초까지 살아 있으므로 ms 수준의 승인 시점 조정 비용이 전체 수명의 1% 미만으로 상각된다. 둘째, 목적지 GPU와 바이트 수, 시작 시각이 prefill 엔진이 캐시를 확정하는 순간 이미 알려져 있어 Hedera 같은 런타임 코끼리 플로우 탐지가 필요 없다. 등가 경로 또한 호스트에서 열거 가능하다. 즉 플로우와 경로 양쪽이 첫 바이트가 나가기 전에 정확히 알려진다.

어떻게 쓰나

ARK의 구성은 호스트 사용자 공간에서 도는 경로 예약 컨트롤러다. 각 호스트는 패브릭 전체의 점유 경로를 기록한 예약 테이블 R(t)의 복제본을 유지한다. 부팅 시에는 목적지 피어별로 소스 포트 오프셋 2^16개를 훑어 해시 결과가 각 스파인으로 가는 오프셋 집합 M(p_k)을 미리 계산해 둔다. 새 플로우가 도착하면 R(t)를 스캔해 예약되지 않은 가장 작은 인덱스의 스파인을 고르고, 그 스파인에 대응하는 소스 포트 오프셋을 버킷에서 꺼내 RDMA 큐 페어를 만들고, 선택 사실을 피어들에게 RESERVE로 브로드캐스트한다. 플로우가 끝나면 RELEASE를 뿌려 테이블에서 해제한다. 모든 K개 경로가 예약된 경우에는 무작위 인덱스를 뽑아 기존 ECMP로 폴백한다. 바꾸는 필드가 소스 포트 하나뿐이라 스위치 수정도, 수신 측 패킷 재정렬도 필요 없다.

전제와 한계

복제 테이블은 비동기로 갱신되므로 두 호스트가 브로드캐스트 지연 창 안에서 같은 경로를 예약하는 경쟁이 생길 수 있다. ARK는 RESERVE 메시지에 (타임스탬프, id) 키를 실어 더 작은 키가 이기고, 진 쪽이 다른 경로로 재해시하는 결정론적 규칙으로 이를 해소한다. 이 규칙이 성립하려면 호스트 시계가 브로드캐스트 지연 이내로 동기화되어야 하며, PTP로 충분하다고 본다. 제어 평면은 대역폭이 낮은 별도 네트워크나 기존 관리 채널에 두어, 예약 지연이 데이터 패브릭의 큐잉이 아니라 전파 지연에 묶이게 한다. 이는 알고리즘 요구가 아니라 배포 선택이며, 제어 메시지가 데이터 패브릭을 공유해도 동작은 하지만 경쟁 창이 커진다.

실험은 LLM 서빙 시뮬레이터와 패킷 수준 네트워크 시뮬레이터를 결합해 수행했다. 연산 지연은 Vidur가 H100에서 측정한 LLaMA-3-8B 프로파일 기반 RandomForest 회귀로 예측하고, KV 전송은 AstraSim의 ECMP 기반 NS-3 백엔드에서 패킷 단위로 시뮬레이션한다. 토폴로지는 2계층 spine-leaf로, 8-GPU 서버 두 대의 GPU 16개, leaf 2개, 스파인 4개, 모든 링크 100Gbps이며 leaf당 유입 800Gbps 대 스파인 방향 유출 400Gbps로 2:1 오버서브스크립션이 걸려 있다. 워크로드는 α=0.7인 Zipf 프롬프트 토큰(평균 약 13,300개)으로, KV 플로우가 125MB에서 6.7GB(평균 1.6GB)까지 나온다. 요청은 포아송 도착으로 QPS 1에서 30까지 훑고, 실험당 1,000건을 넣는다.

결과는 부하가 오를수록 벌어진다. QPS=1에서는 플로우가 거의 겹치지 않아 평균 1.9%, P95 1.2% 감소에 그치지만, QPS=25에서 평균 FCT 27.3%, P95 FCT 34.0% 감소로 정점을 찍는다. QPS=30에서는 패브릭이 포화에 가까워져 13.8%/12.4%로 이득이 줄어든다. QPS=25 시점의 스파인별 동시 플로우를 보면 ECMP는 스파인 2·3에 최대 18개를 몰아넣고 1·4는 간헐적으로 놀리는 반면, ARK는 네 스파인에 고르게 분산한다. TTFT로 옮기면 QPS=5의 약 2%에서 QPS=25 평균 약 13%, QPS=30 P95 12%까지 개선된다. prefill 약 840ms와 첫 디코드 스텝 약 10ms는 고정 오프셋이고 QPS에 따라 커지는 것은 KV 전송 시간뿐이므로, 부하가 오를수록 TTFT 이득이 FCT 이득에 수렴한다. 토큰당 지연(TPOT)은 GPU 내부 디코드가 지배해 라우팅 방식의 영향을 받지 않는다.

컨트롤러 오버헤드는 Intel i9 단일 스레드에서 해시 계산 4.10μs, 경로 테이블 조회 0.87μs로 측정됐다. 부팅 시 2^16개 오프셋으로 테이블을 채우는 초기화는 피어당 약 326ms가 한 번 들고, 런타임 비용은 K=4에서 최대 4×0.87=3.48μs, K=1000에서도 약 870μs로 100Gbps에서 1.6GB를 보내는 약 137ms의 1%에 한참 못 미친다.

개발자 관점에서 이 논문의 실무적 함의는 분리형 서빙 스택에서 네트워크가 병목일 때 스위치나 NIC를 건드리지 않고 애플리케이션 계층에서 손쓸 여지가 있다는 것이다. 다만 저자들이 명시한 전제를 확인해야 한다. 모든 피어가 하나의 잘 알려진 목적지 포트를 쓴다는 가정(다중 포트는 피어·dport별 테이블로 확장), 호스트 시계 동기화, 그리고 경쟁 해소가 브로드캐스트 지연에 의존한다는 점이다. 평가는 16-GPU 규모의 합성 워크로드에 대한 패킷 수준 시뮬레이션이며 실제 프로덕션 배포 실험은 없다. 깊은 Clos 토폴로지로의 확장은 각 ECMP 결정 지점에서 해시를 역산하는 방식으로 가능하다고 서술하지만 검증되지는 않았고, 예약 테이블의 규모가 커질 때의 브로드캐스트 비용과 경쟁 창 증가도 이 논문의 실험 범위 밖이다.