vLLM 0.33.0 릴리스 노트: LibTorch Stable ABI로의 마이그레이션

개요

vLLM은 0.33.0 버전부터 C++ 백엔드를 LibTorch Stable ABI를 사용하도록 전환했습니다. 이번 마이그레이션을 통해 vLLM은 특정 PyTorch 바이너리 버전으로부터 독립되었으며, 사용자는 vLLM 패키지를 다시 빌드하거나 다시 링크할 필요 없이 PyTorch 환경을 업그레이드할 수 있게 되었습니다. 이 변경 사항은 유지 관리성과 배포 유연성을 크게 향상시키지만, 호환성은 여전히 Python API 안정성, CUDA 버전 요구 사항 및 타사 종속성과 같은 다른 요소의 영향을 받습니다.

LibTorch Stable ABI 이해하기

ABI(Application Binary Interface)는 컴파일된 코드가 라이브러리와 상호 작용하는 방식을 규정합니다. PyTorch의 경우, 이전에는 LibTorch ABI가 변경될 때마다 소스 수준의 API가 동일하더라도 vLLM과 같은 확장 기능을 다시 빌드해야 했습니다.

LibTorch Stable ABI는 다음과 같은 세 가지 주요 계층으로 구성되어 버전 간 일관된 바이너리 인터페이스를 제공합니다:

  • 선택된 LibTorch API를 노출하는 안정적인 C shim.
  • shim 사용을 간소화하도록 설계된 C++ 래퍼.
  • libtorch.so에 직접 링크하지 않는 헤더 전용 유틸리티(torch::headeronly).

기술적 구현 및 트레이드오프

175개 이상의 C++/CUDA 소스 파일을 포함하는 vLLM과 같은 대규모 프로젝트를 마이그레이션하려면 안정성과 성능을 보장하기 위한 체계적인 접근 방식이 필요했습니다.

마이그레이션 전략

  • 모듈식 마이그레이션: 팀은 단일 원자적 업데이트를 시도하는 대신 관리 가능한 단위로 커널을 마이그레이션하며 별도의 안정적인 라이브러리를 생성했습니다. TORCH_TARGET_VERSION 빌드 플래그를 사용하여 불안정한 헤더가 포함된 빌드를 실패하게 함으로써 규정 준수를 강제했습니다.
  • 디스패처 등록: 연산자는 STABLE_TORCH_LIBRARY를 통해 TORCH_BOX를 사용하여 등록되었으며, 이를 통해 데이터 유형을 일반적인 StableIValue 형식으로 박싱 및 언박싱했습니다.
  • 도구: 팀은 torch-abi-audit을 활용하여 .so 파일을 검사하고 심볼을 분류하며 최종 빌드에 불안정한 심볼이 남아 있지 않도록 했습니다.

성능 및 기능적 트레이드오프

  • 오버헤드: 안정적인 C shim은 유형 변환 및 연산자 박싱으로 인해 약간의 호스트 측 오버헤드를 발생시킵니다. 팀은 이 오버헤드가 일반적으로 무시할 수 있는 수준이며 CUDA Graphs 하에서는 사실상 사라진다고 보고했으며, 마이그레이션 과정에서 눈에 띄는 런타임 성능 저하는 관찰되지 않았습니다.
  • API 제한: Stable ABI가 LibTorch의 전체 영역을 다루지는 않습니다. 초기에는 안정적인 is_pinned() 메서드가 없는 등 누락된 기능의 경우, PyTorch 2.14에서 안정적인 대체 기능이 추가될 때까지 torch_call_dispatcher C shim을 사용하여 동작을 유지했습니다.

종속성 관리

vLLM 휠이 완전히 ABI 안정성을 갖추려면 모든 컴파일된 종속성도 Stable ABI를 준수해야 합니다. 이번 마이그레이션에는 FlashMLA, DeepGEMM 및 다양한 FlashAttention 버전을 포함한 7개의 주요 종속성에 대한 업데이트 조정이 필요했습니다.

주목할 만한 과제는 DeepGEMM이었는데, 이는 Stable ABI에 맞게 조정되기 전에 pybind11 기반 등록에서 TORCH_LIBRARY로 리팩토링해야 했습니다. 여기에는 기존 사용자 대면 API를 유지하면서 Stable ABI 등록 프로세스의 요구 사항을 충족하는 방식으로 C++ 데이터 유형을 처리하는 래퍼를 만드는 작업이 포함되었습니다.

향후 로드맵

CUDA 빌드가 성공적으로 마이그레이션됨에 따라, vLLM 팀은 이제 프로젝트의 CPU 및 ROCm 빌드로 ABI 안정성을 확장하는 데 집중하고 있습니다. 또한, 팀은 사용자 지정 래퍼에 대한 의존도를 줄이기 위해 안정적인 API 영역을 확장하고, 향후 릴리스에서도 이러한 API가 안정적으로 유지되도록 PyTorch 커뮤니티와 지속적으로 협력할 계획입니다.

Sources