vLLM이 에이전트로 Kimi K3 디코드 성능을 1.5~2배 끌어올렸다

Hacker News14일 전조회 1

vLLM 팀이 Kimi K3의 디코드 실행 경로를 에이전트 지원 방식으로 다시 설계해 NVIDIA GB300에서 눈에 띄는 성능 향상을 얻었다. 핵심은 attention, MoE, GPU 간 통신을 하나로 묶은 CuTe DSL 기반 디코드 경로다. 8개 또는 16개 GPU로 구성된 NVLink 도메인을 전제로, 배치 크기 1부터 64까지와 긴 컨텍스트를 위한 디코드 컨텍스트 병렬화(DCP) 옵션을 함께 지원한다.

수치는 분명하다. 16개 GB300 GPU에서 배치 1 기준 DSpark(synthetic AL=6) 환경으로 초당 840 토큰을 넘겼고, 테스트한 여러 구성에서 디코드 처리량이 1.5~2배 늘었다. 에이전트 워크로드인 AgentX에서는 P90 인터랙티브 지표가 최대 1.8배 개선됐다. 레이어당 커널 타임라인도 달라졌다. 기본 vLLM이 레이어당 23개 커널에 130마이크로초를 쓰던 것을, 특화 디코드 경로는 13개 커널에 69마이크로초로 줄였다.

최적화는 크게 네 갈래다. 먼저 배치 크기에 따라 커널을 바꿔 쓴다. attention 입력 프로젝션은 배치 1~2에서 소형 행렬 전용 커널을, 큰 배치에서는 행렬 곱을 여러 GPU 워커에 나누는 split-K 커널을 쓴다. KDA 역시 배치 크기와 GPU당 attention 헤드 수에 맞춰 스케줄을 조정한 CuTe DSL 커널을 쓴다. 긴 컨텍스트에서는 KV 캐시를 GPU별로 쪼개 각자 로컬 구간을 계산한 뒤, 부분 결과를 v-proj 및 게이팅과 합치는 융합 커널로 모은다.

두 번째는 연산과 통신의 겹치기다. attention 출력 프로젝션을 all-reduce와 뒤따르는 residual 계산에 직접 붙이고, 커널들이 NVLink로 접근 가능한 버퍼에 부분 결과를 써두면 받는 쪽 커널이 이를 합쳐 계산을 이어간다. 작은 배치에서는 생산자와 소비자를 한 커널로 합치기도 하며, 데이터 교환은 오버헤드를 최소화한 fence-less 방식으로 처리한다. 배치가 커지면 GPU끼리 담당 구간을 먼저 합친 뒤 결과를 분배하는 2단계 reduction으로 전환해 GPU 간 데이터 이동을 줄인다.

MoE 쪽도 손봤다. expert가 이미 텐서 병렬화되어 있어도 기준 구현은 라우터 점수와 잠재 입력 프로젝션을 모든 GPU에서 전부 계산했다. 이를 TP 랭크별로 나눠 각자 맡은 몫을 하나의 행렬 곱으로 합치고 NVLink로 교환하면서, expert 실행 전의 중복 연산과 가중치 읽기, 커널 실행 횟수를 줄였다. 공유 expert는 별도 스트림에서 돌려 구성에 따라 라우팅이나 라우티드 expert 연산과 겹친다. 작은 배치에서는 메모리 대역폭이 병목이 되기 쉬운 점을 이용해, 통신이 진행되는 동안 사이드 스트림에서 다음 연산의 가중치를 미리 캐시에 올려 캐시 적중률을 높인다.

이 작업의 배경에는 개발 방식의 변화가 있다. 코딩 에이전트가 복잡한 GPU 커널 작성, 연산자 간 융합, 연산-통신 오버랩, 배치 및 GPU 구성별 튜닝 같은 어려운 영역을 상당 부분 도울 수 있게 되면서, 생성되는 최적화 코드의 속도가 사람이 검토하고 유지보수하는 절차를 앞지르기 시작했다. 모든 커널의 모든 줄을 이해하고, 문제 지점을 찾고, 지원 구성마다 테스트하는 작업은 매우 오래 걸리지만, 그 과정을 생략하면 프로덕션에서 깨질 수 있는 코드를 내보내는 위험을 진다.

그래서 vLLM은 fast-track 모델 최적화 RFC를 통해 리뷰 부담은 낮추고 위험은 관리하는 쪽으로 성능 작업의 구조 자체를 바꾸려 한다. 원칙은 네 가지다. 최적화를 모델 코드 안에 격리하고, 런타임에서도 최적화 경로가 언제 선택되고 어떤 상태를 바꾸며 어떻게 표준 경로로 돌아오는지 추적 가능하게 한다. 지원 하드웨어와 워크로드 범위를 명확히 제한하되 프로덕션 LLM에 필요한 필수 기능은 유지한다. 정해진 성능·정확성 벤치마크를 돌려 지원 구성 전부에서 확실히 더 나은 성능을 확인한다. 마지막으로 기여자가 자기 GPU에서 표준 평가를 실행해 재현 가능한 결과를 공유한 뒤 메인테이너의 검토를 요청하도록 한다.

개발자 입장에서 달라지는 것은 리뷰의 단위다. 사람은 더 이상 커널을 한 줄씩 읽는 대신 설계와 증거를 상위 수준에서 판단하고, 에이전트는 테스트 구성, 종합 평가와 벤치마크 실행, 실패 원인 조사, 최적화가 유효한 조건 문서화까지 맡는다. 모델별 최적화를 모델 코드 안에 두는 관행은 영향 범위를 좁혀 리뷰어가 고려할 폭발 반경을 줄이는 역할도 한다.

한계도 분명히 밝혀져 있다. 격리 원칙 때문에 입력 준비, 샘플링, KV 캐시 관리처럼 대부분의 vLLM 배포가 공유하는 컴포넌트는 이 빠른 경로에서 제외된다. 특정 워크로드를 위해 이들을 건드리면 다른 수십 개의 안정적인 구성이 깨질 위험이 있기 때문이며, 이런 영역은 코어 메인테이너와 훨씬 긴밀하게 협업해야 한다. 또한 하나의 최적화가 모든 배포에서 좋아질 필요는 없고, 특정 GPU나 병렬화 설정, 배치 범위만 겨냥해도 유용하다는 것이 이 접근의 전제다.