요약: 이제 트랜스포머(transformers) vLLM 백엔드는 여러 LLM 아키텍처에서 커스텀 vLLM 구현과 동일하거나 더 빠른 속도를 제공합니다. 모델 작성자들은 자신들의 트랜스포머 구현을 활용하여 초고속 vLLM 추론을 무료로 얻을 수 있습니다.

# vllm pip 패키지 업그레이드
uv pip install --upgrade vllm --torch-backend auto

트랜스포머 라이브러리는 머신러닝의 참조 모델링 라이브러리가 되었습니다. 일관된 API를 통해 450개 이상의 아키텍처를 지원하며, 모델 구현이 자체적으로 포함되어 있고 이해하기 쉬운 것을 주요 목표로 설계되었습니다. 트랜스포머 코드를 살펴보는 것은 기여자들이 특정 아키텍처가 어떻게 작동하는지 쉽게 배우고, 이를 vLLM, SGLang, MLX, llama.cpp 등 다른 프레임워크로 포팅(port)하는 데 도움을 줍니다.

우리는 이 생태계 내에서의 역할을 완전히 수용했으며, 이를 더 쉽게 만들기 위해 많은 노력을 기울이고 있습니다. 이러한 노력의 큰 진전은 작년에 트랜스포머를 vLLM의 모델링 백엔드로 통합한 것입니다. 이는 모델 작성자들이 아무것도 포팅할 필요 없이 vLLM 내부에서 트랜스포머 모델(LLM 및 VLM 모두)을 실행할 수 있게 해주었습니다. 트랜스포머가 모델링 코드를 제공하고, vLLM은 연속 배치 처리(continuous batching)와 커스텀 어텐션 커널(custom attention kernels)과 같은 극도로 최적화된 추론 기술을 제공합니다.

이 통합 기능이 이제 더욱 좋아졌습니다 🚀!

우리는 트랜스포머 모델링 백엔드를 vLLM의 수작업 네이티브 구현과 세 가지 매우 다른 Qwen3 모델에 대해 직접 비교했습니다:

• 단일 GPU에서 4B 밀집(dense) 모델
• 텐서 병렬 처리(tensor parallelism)를 이용한 32B 밀집 모델
• 동일한 8×H100 노드에서 데이터 + 전문가 병렬 처리(data + expert parallelism)를 적용한 235B 파라미터 FP8 Mixture-of-Experts (MoE)

트랜스포머 모델링 백엔드가 이 모든 경우에 네이티브 처리량과 같거나 능가하는 결과를 보였습니다.

어떤* Hugging Face 모델을 트랜스포머 모델링 백엔드를 통해 실행하려면 단 하나의 플래그만 추가하면 됩니다 — --model-impl transformers

이는 일반적인 병렬 처리 옵션과 결합되므로, 서비스 설정에 아무런 변경도 필요하지 않습니다:

# Qwen3-4B dense, single GPU
vllm serve Qwen/Qwen3-4B --model-impl transformers
# Qwen3-32B dense, tensor-parallel across 2 GPUs
...

선형 어텐션(linear attention)을 사용하는 모델은 현재 지원되지 않지만, 곧 지원될 예정입니다! Hub 저장소에 코드가 존재하는 사용자 지정 모델의 경우, 준수하게 작성되지 않았기 때문에 작동하지 않을 가능성이 높습니다.

각 모델은 코드 경로만 다르고 다른 모든 면에서 동일한 세 가지 조건으로 비교되었습니다:

native—--model-impl vllm

(vLLM이 직접 구현한 모델로, 맞춰야 할 기준입니다)after—--model-impl transformers

withthe PRbefore—--model-impl transformers

withoutthe PR

전체적이고 재현 가능한 실행기는 gist에서 사용할 수 있습니다: benchmark.sh

traders modeling backend for vLLM은 원래 추론의 병목 현상으로 *어텐션(attention)*에 초점을 맞추었습니다. 런타임에 vLLM의 어텐션 구현을 플러그인함으로써, 우리는 transformers 모델이 vLLM 엔진 내부에서 효율적으로 실행되도록 할 수 있었습니다. 하지만 최대 추론 성능을 끌어내기 위해서는 사용자 지정 포트만 목표할 수 있는 많은 차원들이 존재합니다. GPU 간 병렬화(Parallelization across GPUs), 컴파일(Compilation), 융합 커널(Fused kernels) 등 훨씬 더 많은 요소들이 모두 초고속 추론을 달성하기 위해 하드웨어를 활용하는 데 기여합니다.

새로운 모델이 transformers용으로 한 번 통합되고, vLLM에 사용자 지정 최적화와 함께 한 번 통합되던 방식

모델 작성자들이 절대적인 최고의 성능을 원할 때도 여전히 사용자 지정 vLLM 구현을 작성해야 했습니다.

새로운 모델이 transformers용으로 통합된 후, 이제 네이티브 vLLM 구현 속도로 즉시 vLLM에서 사용 가능해진 방식

vLLM의 transformers modeling backend은 호환 가능한 아키텍처에 대해 런타임에 추론 특정 레이어 융합(inference specific layer fusions)을 동적으로 적용하여 사용자 지정 코드 구현 속도와 일치하도록 합니다.

vLLM의 transformers modeling backend은 이제 torch.fx를 사용합니다.

모델 그래프에 대한 정적 분석을 수행하기 위해서입니다. 이 과정은 최적화될 수 있는 알려진 패턴들을 검색합니다. 어떤 패턴들이 식별되면, 추상 구문 트리(abstract syntax tree, ast)를 사용하여 소스 코드를 조작하고 일부 연산을 제자리에서 재작성합니다.

이것으로 무엇을 달성할 수 있을까요?

• Mixture-of-Experts (MoE) 모델의 Expert Parallelization (EP)에 사용되는 것과 같은, 다수 대 하나로 매핑되는 융합 연산(Fused operations)을 (초)최적화된 vLLM 커널로 구현할 수 있습니다.
• 주요 다른 융합 연산으로는 vLLM의 MergedColumnParallelLinear와 QKVParallelLinear가 있습니다. 이 블록들은 TP (tensor-parallel)를 위한 병렬 계획(parallel plans)을 추론할 수 있게 해줍니다. 디코더 블록 목록이 쉽게 식별 가능하다면 PP (pipeline-parallel) 계획도 추론될 수 있습니다. - 조작된 모델들은 여전히 완전히 (torch) 컴파일 가능하며, 전용 vLLM 모델 구현과 마찬가지로 torch.compile 및 CUDA Graphs를 통해 전달됩니다. - vLLM 모델 구현과는 달리, Transformers 모델 구현은 **학습(training)**에 사용될 수 있습니다. 따라서 학습/평가(evals)/RL 롤아웃에 동일한 모델 코드를 사용할 수 있습니다.

위에서 보았듯이, 이는 호환 가능한 모델의 경우, 추론을 위해 모델을 최적화하는 데 단 한 줄의 코드도 작성할 필요 없이 네이티브 vLLM 추론 속도를 달성하게 합니다.

저희는 이러한 최적화된 추론 방식들을 깊이 파고들어 모델을 어떻게 조작하여 적응시키는지 상세히 설명하는 자세한 블로그 게시물을 작성하는 과정에 있습니다.