llm-d 분리 추론: 가까운 GPU를 골라도 첫 응답이 늦는 이유

질문을 읽는 곳과 답을 만드는 곳 사이에 생기는 비용

Prefill은 입력 프롬프트를 처리하는 단계이고, Decode는 그 결과를 이용해 다음 토큰을 생성하는 단계다. P/D 분리는 두 역할을 서로 다른 작업자 풀로 나눈다. Prefill이 만든 KV 캐시, 즉 이후 토큰 계산에 재사용할 attention 정보를 Decode 쪽으로 넘겨야 한다. llm-d가 2026년 10월 29일 공개한 GKE 분석은 이 전송을 장치 할당부터 라우팅까지 연결해 다룬다. 공식 분석

이 글의 질문은 이미 P/D 분리를 선택한 팀이 요청을 어디로 보낼지다. 분리 자체가 통합 서빙보다 유리한지, 어느 GPU가 가장 빠른지는 별도 비교가 필요하다. 확인일은 11월 6일이며, 아래에는 문헌·공개 코드 분석과 직접 만든 가상 계산만 있다. 실제 클러스터 성능을 측정하지 않았다.

예를 들어 사내 문서 도우미에 긴 보고서 질문이 몰린다고 하자. Prefill 풀을 늘리면 입력 처리 대기는 줄 수 있지만, 결과를 받을 Decode 작업자와의 전송이 느리거나 그쪽 큐가 길면 사용자는 여전히 기다린다. 한쪽의 여유 자원만으로 요청 전체의 여유를 설명할 수 없다.

서로 다른 세 번의 선택을 연결한다

장치 할당은 작업자가 시작할 때 GPU와 NIC를 정한다. NIC는 네트워크 인터페이스 장치다. 전송 라이브러리는 실제로 사용할 통신 경로를 정하고, 라우터는 요청마다 어느 Prefill과 Decode를 짝지을지 정한다. 이 세 선택을 한 번의 “가까운 GPU 배치”로 뭉뚱그리면 바꿔야 할 곳을 놓친다.

Kubernetes DRA는 장치를 단순 개수뿐 아니라 속성에 따라 요청하고 할당하는 체계다. 읽어 본 llm-d GKE의 초기 고정 설정은 GPU 하나와 NIC 하나를 같은 ResourceClaimTemplate에 넣고, resource.kubernetes.io/pcieRoot가 같도록 제약한다. 이는 해당 장치들이 같은 PCIe root에 속하도록 묶는 설정이며, 모든 클러스터에 자동으로 적용되는 기본값은 아니다. DRA 개념 · 고정 GKE 할당 예제

그다음에는 설정한 장치와 실제 사용한 경로가 같은지 확인해야 한다. GKE 분석은 RDMA 사용 의도와 달리 TCP로 전송된 사례, 같은 노드의 별도 Pod 사이에서도 RDMA 경로를 사용한 사례를 구분한다. 같은 호스트라는 이름만으로 NVLink 전송을 확정할 수 없다. 실제 전송 확인 범위

결정 시점	이때 정하는 것	다음 단계에 넘겨야 할 정보
작업자 배치·장치 할당	GPU와 NIC의 조합	장치 식별자·공유 PCIe root·배치 시각
통신 경로 준비·연결	사용할 수 있는 전송 경로	실제 사용 경로·연결 실패·측정 시각
요청별 라우팅	상대 작업자	후보별 지역성·부하·선택 결과

이 표는 필자가 제안하는 인수 정보다. 같은 요청을 다시 조사하려면 “GPU 1번” 같은 재사용 가능한 이름보다 그 실행의 장치·작업자 식별자와 유효 시점이 필요하다. 재배치 뒤의 정보로 이전 요청을 설명하지 않도록 연결한다.

가까운 후보만 남기면 부하 점수는 무엇을 놓칠까

11월 6일 확인한 router 커밋 af04c1243c70에는 topology-affinity-filter와 topology-affinity-scorer가 따로 있다. 필터는 후보를 제거하고, scorer는 남은 후보에 점수를 준다. 현재 소스를 읽은 결과이며, 설치한 안정 버전의 동작을 확인한 실행 기록은 아니다. 고정 필터 코드 · 고정 scorer 코드

필터의 minAffinity 기본값은 host다. 상대와 같은 호스트 조건을 만족하는 후보가 있으면 그 집합을 남긴다. 반면 상대의 토폴로지 정보가 없거나 조건을 만족하는 후보가 하나도 없으면 원래 후보 전체를 돌려준다. 이를 fail-open이라고 한다. 누락된 값끼리는 일치로 세지 않는다. 필터의 조건과 예외

여기에는 운영상 중요한 틈이 있다. 가까운 후보가 존재하지만 혼잡한 상황과 가까운 후보가 아예 없는 상황은 다르다. 첫 상황에서 먼 후보를 필터로 제거했다면, 그 뒤의 부하 점수를 아무리 잘 설계해도 제거된 후보를 고를 수 없다. 다음 표는 코드의 반환 조건을 읽어 만든 판독 사례이며 실제 router를 실행한 결과가 아니다.

필터 입력 상황	해당 필터의 결과	운영자가 추가로 확인할 것
같은 host의 A와 다른 host의 B가 있음	A만 남음	A의 혼잡 때 B로 넘길 수 있는 별도 정책이 있는가
A가 사라지고 다른 host의 B만 있음	일치 후보가 없어 B를 반환	B의 실제 연결 가능성은 이미 확인했는가
상대의 토폴로지가 없음	입력 후보 전체 반환	잘못된 후보가 섞여도 아래 계층이 막는가
A는 일치하고 B의 토폴로지는 누락됨	A만 남음	B가 멀어서 제외됐는지, 정보가 없어서 제외됐는지

scorer는 host·rack·zone·region의 가까움을 고정 점수로 바꾼다. 해당 소스에서 host는 1.00, rack은 0.20이고, 상대 정보가 없으면 모든 후보의 지역성 점수는 0이다. 0은 가장 먼 실제 거리를 측정했다는 뜻이 아니라 이 점수에 기여할 정보가 없다는 뜻일 수 있다. 다른 scorer와의 가중합 및 후보 집합을 함께 봐야 한다. scorer 문서

따라서 “가까운 곳을 선호하되 혼잡하면 다른 곳으로 넘긴다”가 목표라면, 거리 점수의 가중치만 살피지 말고 그 비교에 먼 후보가 남아 있는지부터 확인할 것을 제안한다. 반대로 특정 구역 안에서만 처리해야 한다면, 조건 불일치 때 후보 전체를 복원하는 이 필터 하나를 강제 경계로 사용해서는 안 된다.

전송 14ms를 아끼려고 대기 75ms를 더 할 수도 있다

Prefill 작업자는 이미 선택됐고 Decode 후보 A와 B가 모두 연결 가능하다고 가정하자. 다음 수치는 실제 GPU·NIC 성능이 아닌 판단 연습용 입력이다. 두 후보에서 이후 첫 토큰 계산은 같고, 대기와 KV 전송은 겹치지 않고 순서대로 진행한다고 단순화한다.

비교할 추가 지연 = Decode 대기 Q + KV 전송 X

후보	대기 Q	전송 X	비교할 추가 지연
가까운 A	80ms	4ms	84ms
먼 B	5ms	18ms	23ms

이 가정에서는 B가 61ms 짧다. A가 전송에서 얻는 이득은 14ms인데 대기는 75ms 더 길기 때문이다. A를 택할 조건은 Q_A − Q_B < X_B − X_A다. B의 대기가 5ms로 유지된다면 A의 대기가 19ms보다 짧을 때 A가 유리하고, 19ms면 같다. A의 대기가 10ms로 줄면 합계 14ms로 선택이 다시 뒤집힌다.

이 식을 그대로 llm-d의 점수 공식이라고 읽으면 안 된다. 공개 scorer는 밀리초를 더하는 구현이 아니다. 이 계산의 목적은 팀이 정한 “근접성 우선” 정책이 어떤 대기 조건에서 손해가 되는지 설명하는 데 있다. 실제 시스템에서는 전송과 대기가 겹칠 수 있고, 큐 길이가 시간으로 곧장 환산되지 않으며, 캐시 재사용과 Decode 처리 속도도 다를 수 있다. 그 경우 식의 항을 바꾸거나 요청 trace로 겹친 구간을 확인해야 한다.

연결 불가능한 후보 C에 예상 지연 1ms가 적혀 있어도 비교에서 먼저 제외한다. 비용 점수가 낮다는 이유로 실패할 경로를 선택할 수는 없다. 연결 가능 여부가 미확인이면 0ms나 무한대 같은 임의 숫자로 숨기지 말고 확인 대상을 따로 남긴다.

가상 입력과 산술 검산 자료에는 위 역전·동률·연결 불가 사례를 담았다. 이는 자체 산술 검사이며 llm-d·RDMA·부하 테스트가 아니다.

3.5배라는 결과를 설정 한 줄의 효과로 읽지 않는다

공식 분석의 평균 TTFT는 2.15초, 할당·전송 확인 뒤 1.157초, 토폴로지 점수 적용 뒤 0.33초다. 두 노드·H200 16개, 고정 입력 5,000토큰·출력 250토큰, 45 QPS 조건이며 마지막 단계는 공개 배포 플러그인과 다른 실험용 scorer를 사용했다. P/D와 통합 서빙의 우열을 검증한 실험도 아니다. 실험 조건과 한계

독자가 가져올 것은 0.33초라는 목표값보다 비교의 순서다. 먼저 전송 경로가 의도대로 작동하는지, 그다음 같은 채널과 부하에서 상대 선택이 만드는 차이를 본다. 설정·장치·부하를 한꺼번에 바꾸면 어느 선택이 효과를 냈는지 설명하기 어려워진다.

배포 모드도 함께 고정해야 한다. 확인한 현재 필터 문서는 single EPP와 별도 P/D EPP를 연결하는 coordinator 방식을 구분한다. EPP는 요청을 받을 작업자를 고르는 구성요소다. coordinator 방식은 상대 토폴로지를 헤더로 전달하며, 문서는 그 헤더의 출처를 플러그인이 다시 검증하지 않는다고 명시한다. 실험용 구성, 현재 main 소스, 실제 설치 버전의 설정을 서로 섞지 않는다. 배포 모드와 헤더의 신뢰 조건

첫 도입 시험에서 남길 한 장

운영 변경 전에는 대표 요청군 하나를 골라 다음 정보를 묶을 수 있다. 긴 문서 요청과 짧은 대화 요청을 처음부터 한 평균으로 합치지 않는 편이 차이를 설명하기 쉽다. 아래는 제품 설정 파일이 아닌 시험 설계 양식이다.

요청군 / 입력·출력 길이 / 제공 부하와 완료 부하:
모델·서빙 이미지·router 커밋 / 배포 모드:
Prefill·Decode 작업자와 GPU·NIC / 정보의 유효 시각:
실제 전송 경로 / 연결 불가·정보 누락 후보:
필터 전 후보 / 필터 후 후보 / 최종 선택:
후보별 부하와 지역성 / 첫 응답까지 각 구간:
변경한 조건 하나 / 대조 실행 / 되돌릴 조건:

가까운 풀이 비었을 때, 가까운 풀이 혼잡하지만 살아 있을 때, 토폴로지 정보가 누락됐을 때를 따로 시험할 것을 제안한다. 가장 가까운 후보가 사라진 시험만 통과하면, 살아 있지만 느린 후보를 계속 고르는 문제는 놓칠 수 있다. 반대로 모든 먼 후보를 허용하면 구역 제한이나 연결 조건을 위반할 수 있으므로, 먼저 가능한 경로의 범위를 확정한다.

작업과 장비의 관계부터 복원해야 한다면 Minerva의 토폴로지 관측을, 전송 경로 안의 패킷 순서·완료 문제라면 MetaRoCE 분석을 이어 읽을 수 있다. 실제 요청의 대기와 겹치는 구간을 나누는 방법은 지연 시간 trace 해설로 연결된다. 이 시험 양식을 다시 쓸 때는 글 저장 기능을, 관련 후속 분석은 인프라 글 모음과 RSS를 이용할 수 있다.