[vllm] vLLM GLM5.3 성능 최적화: 메타데이터 연산 속도 1.6~4.8배 향상

2026년 9월 25일수정: 2026년 9월 25일

PR 링크: vllm-project/vllm#58450 상태: Merged | 변경: +26 / -25

들어가며

최근 대규모 언어 모델(LLM)의 발전 속도는 눈부십니다. 특히 추론(Inference) 단계에서의 속도와 효율성은 실제 서비스 적용에 있어 매우 중요한 요소로 작용합니다. vLLM은 이러한 LLM 추론 속도를 높이기 위해 PagedAttention과 같은 혁신적인 기술을 도입하며 주목받아 왔습니다.

이번 분석 대상인 GitHub Pull Request(PR)는 vLLM에서 GLM5.3 모델의 메타데이터 연산 성능을 개선하는 데 초점을 맞추고 있습니다. 구체적으로 _build_req_id_per_token 함수의 비효율성을 해결하고, GPU 버퍼 재사용 및 Triton 커널 도입을 통해 커널 레벨에서 1.6배에서 최대 4.8배까지 성능 향상을 달성했습니다. 이 글에서는 해당 PR의 코드 변경 사항을 상세히 분석하고, 왜 이러한 변경이 성능 향상으로 이어졌는지, 그리고 이를 통해 얻을 수 있는 일반적인 교훈은 무엇인지 살펴보겠습니다.

코드 분석

이번 PR의 핵심 변경 사항은 크게 두 가지로 나눌 수 있습니다. 첫째, _build_req_id_per_token 함수의 구현을 최적화하여 GPU 메모리 접근 및 연산 오버헤드를 줄였습니다. 둘째, torch.arange 연산의 비효율성을 개선했습니다.

1. `_build_req_id_per_token` 최적화

이 함수는 각 토큰에 해당하는 요청 ID를 생성하는 역할을 합니다. 이전 구현은 CPU에서 NumPy 배열을 사용하여 요청 ID를 생성하고, 이를 다시 GPU로 복사하는 과정을 거쳤습니다. 이 과정은 여러 단계의 데이터 이동과 변환으로 인해 상당한 오버헤드를 발생시켰습니다.

Before:

--- a/vllm/model_executor/layers/attention/sparse_mla_attention.py
+++ b/vllm/model_executor/layers/attention/sparse_mla_attention.py
@@ -291,17 +291,7 @@
         self, 
         common_attn_metadata: "CommonAttentionMetadata",
     ) -> torch.Tensor:
-        num_tokens = common_attn_metadata.num_actual_tokens
-        starts = np.asarray(common_attn_metadata.query_start_loc_cpu, dtype=np.int32)
-        seg_lengths = np.diff(starts)
-        req_id_per_token = np.repeat(
-            np.arange(seg_lengths.shape[0], dtype=np.int32), seg_lengths
-        )
-        self.req_id_per_token_buffer.fill_(0)
-        self.req_id_per_token_buffer[: req_id_per_token.shape[0]].copy_(
-            np_to_pinned_tensor(req_id_per_token), non_blocking=True
-        )
-        return self.req_id_per_token_buffer[:num_tokens]
+        return common_attn_metadata.token_to_req_indices(self.req_id_per_token_buffer)
 
     def _build_chunked_context_fields(
         self,

After:

변경된 코드는 CommonAttentionMetadata 객체의 token_to_req_indices 메서드를 직접 호출합니다. 이 메서드는 내부적으로 GPU에서 효율적으로 요청 ID를 계산하고, 미리 할당된 GPU 버퍼(self.req_id_per_token_buffer)에 결과를 저장합니다. 이를 통해 CPU-GPU 간 데이터 복사 및 NumPy 연산 오버헤드가 제거되었습니다.

이 변경은 다음과 같은 이점을 제공합니다:

GPU 버퍼 재사용: req_id_per_token_buffer를 재사용하여 매번 새로운 버퍼를 할당하는 비용을 줄입니다.
Triton 커널 활용: CommonAttentionMetadata.token_to_req_indices는 내부적으로 최적화된 Triton 커널을 사용할 가능성이 높습니다. Triton은 CUDA 커널을 더 쉽고 효율적으로 작성할 수 있게 해주는 라이브러리로, GPU 하드웨어에 최적화된 연산을 가능하게 합니다.
CPU-GPU 데이터 이동 최소화: 모든 연산이 GPU 내에서 이루어지므로, 데이터 전송 병목 현상을 크게 줄일 수 있습니다.

2. `torch.arange` 연산 최적화

flashattn_mla_sparse.py 파일에서도 유사한 최적화가 이루어졌습니다. cu_seqlens_q를 계산하는 부분에서 이전에는 매번 torch.arange를 호출하여 시퀀스 길이에 따른 시작 인덱스를 계산했습니다. 하지만 이 값은 이전 스텝과 동일하거나 매우 유사한 경우가 많습니다.

Before:

--- a/vllm/v1/attention/backends/mla/flashattn_mla_sparse.py
+++ b/vllm/v1/attention/backends/mla/flashattn_mla_sparse.py
@@ -178,6 +178,11 @@
         assert self.topk_indices_buffer is not None, (
             "Indexer or topk_indices_buffer required for sparse MLA"
         )
+        self.cu_seqlens_q_buffer = torch.arange(
+            self.topk_indices_buffer.shape[0] + 1,
+            dtype=torch.int32,
+            device=self.topk_indices_buffer.device,
+        )
         self.supports_quant_query_input = False
 
     def forward_mqa(
@@ -306,9 +311,7 @@
             kv_cache if cache_is_flat else flat_kv_row_view(kv_cache, block_size)[0]
         )
 
-        cu_seqlens_q = torch.arange(
-            0, q_rope.shape[0] + 1, dtype=torch.int32, device=q_rope.device
-        )
+        cu_seqlens_q = self.cu_seqlens_q_buffer[: q_rope.shape[0] + 1]
         v_cache = kv_rows[:, : self.kv_lora_rank].unsqueeze(1).unsqueeze(1)
         if self.qk_rope_head_dim == 0:
             # FA3's QV path requires the 64-wide Q/K specialization. For NoPE

After:

변경된 코드에서는 __init__ 메서드에서 self.cu_seqlens_q_buffer라는 고정된 버퍼를 미리 생성해 둡니다. 이후 forward_mqa 메서드에서는 이 버퍼의 필요한 부분만 슬라이싱하여 사용합니다. 이는 torch.arange 연산 자체의 비용은 낮지만, 반복적으로 호출될 때 발생하는 오버헤드를 줄이는 효과가 있습니다. 특히 CUDA 그래프(Graph)와 같이 연산이 반복적으로 재사용되는 환경에서 더욱 유리합니다.

3. 테스트 코드 변경

test_indexer_deepseek_v4_slot_mapping.py 파일에서는 새로운 최적화 기법을 테스트하기 위해 use_sparse_mla_builder라는 파라미터가 추가되었습니다. 이를 통해 기존 방식과 새로운 SparseMLACommonMetadataBuilder를 사용한 방식 모두를 비교 테스트할 수 있게 되었습니다. 또한, [0, 0, 0]과 같이 빈 시퀀스 길이를 포함하는 테스트 케이스가 추가되어 엣지 케이스에 대한 커버리지를 높였습니다.

왜 이게 좋은가?

이 PR은 LLM 추론 성능 향상에 있어 다음과 같은 중요한 시사점을 제공합니다.

GPU 연산 집중 및 데이터 이동 최소화: CPU와 GPU 간의 데이터 이동은 LLM 추론에서 가장 큰 병목 중 하나입니다. 이 PR은 _build_req_id_per_token 함수에서 CPU-NumPy 연산을 제거하고 GPU 내에서 연산을 완료함으로써 이러한 병목을 효과적으로 해결했습니다. 이는 CommonAttentionMetadata.token_to_req_indices 메서드가 내부적으로 최적화된 GPU 커널(Triton 등)을 활용하기 때문에 가능합니다.
리소스 재사용 및 오버헤드 감소: torch.arange와 같이 반복적으로 사용되는 연산의 경우, 결과를 미리 계산하여 저장하고 재사용하는 방식은 상당한 성능 향상을 가져올 수 있습니다. 특히 CUDA 그래프와 같이 연산 그래프를 캐싱하고 재실행하는 메커니즘에서는 이러한 최적화가 더욱 빛을 발합니다.
실질적인 성능 향상: 제공된 벤치마킹 스크립트의 결과는 이러한 최적화가 실제 추론 속도에 미치는 영향을 명확하게 보여줍니다. 특히 토큰 수가 증가할수록 mapping 연산에서 최대 2.71배, arange 연산에서 최대 4.8배의 속도 향상이 관찰되었습니다. 이는 모델의 복잡성과 처리해야 할 데이터 양이 증가할수록 최적화의 효과가 커짐을 의미합니다.

일반적인 교훈:

병목 지점 식별 및 집중: LLM 추론 성능 개선의 핵심은 병목 지점을 정확히 파악하고 해당 부분을 집중적으로 최적화하는 것입니다. 이 PR은 메타데이터 생성 과정의 비효율성을 정확히 찾아내어 개선했습니다.
GPU 네이티브 연산 활용: 가능한 모든 연산을 GPU 내에서 처리하고, CPU-GPU 간 데이터 전송을 최소화하는 것이 중요합니다.
리소스 재사용 전략: 반복적으로 사용되는 계산 결과나 버퍼는 미리 할당하고 재사용하는 방식을 적극적으로 고려해야 합니다.
테스트 커버리지 확보: 새로운 최적화 기법을 도입할 때는 다양한 시나리오(특히 엣지 케이스)에 대한 철저한 테스트를 통해 안정성과 성능을 검증해야 합니다.

결론

이번 vLLM PR은 GLM5.3 모델의 메타데이터 연산 최적화를 통해 추론 성능을 크게 향상시킨 좋은 사례입니다. GPU 연산 집중, 리소스 재사용, 그리고 철저한 테스트를 통해 달성된 1.6배 ~ 4.8배의 성능 향상은 LLM 추론 최적화의 중요성을 다시 한번 강조합니다. 이러한 최적화 기법들은 vLLM뿐만 아니라 다른 LLM 추론 프레임워크에서도 널리 적용될 수 있는 일반적인 원칙을 제시합니다.

참고 자료

⚠️ 알림: 이 분석은 AI가 실제 코드 diff를 기반으로 작성했습니다.

PR Analysis 의 다른글

이전글 [flashinfer] Blackwell 아키텍처를 위한 극한의 최적화: MiniMax-H3 Fused 커널의 256-Column Tiling 전략
현재글 : [vllm] vLLM GLM5.3 성능 최적화: 메타데이터 연산 속도 1.6~4.8배 향상
다음글 [onnxruntime] ONNX Runtime, x86 CPU에서 FP16 LayerNorm 및 RMSNorm 성능 최적화: AVX2 활용