🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

transformers의 vLLM 모델링 백엔드는 여러 호환 LLM 아키텍처에서 별도 vLLM 포팅 없이 네이티브 vLLM 구현과 같거나 더 빠른 추론 성능을 내도록 개선되었다.

📌 핵심 요약

• transformers는 450개 이상의 아키텍처를 일관된 API로 지원하는 참조 모델링 라이브러리이며, vLLM은 이 모델 코드를 고성능 추론 엔진 안에서 실행할 수 있게 해 왔다.
• 이번 업데이트의 핵심은 transformers 모델링 백엔드가 많은 LLM 아키텍처에서 vLLM의 손수 작성된 네이티브 구현과 같은 수준이거나 더 높은 처리량을 보였다는 점이다.
• 글은 Qwen3 4B dense, Qwen3 32B dense, Qwen3 235B-A22B-FP8 MoE를 대상으로 단일 GPU, 텐서 병렬, 데이터 병렬 및 전문가 병렬 조건에서 비교했다고 설명한다.
• 사용자는 --model-impl transformers 플래그를 붙여 Hugging Face 모델을 vLLM에서 실행할 수 있으며, 일반적인 병렬화 옵션과 함께 사용할 수 있다.
• 새 백엔드는 torch.fx로 모델 그래프를 정적으로 분석하고 ast로 소스 코드를 조작해 런타임에 추론용 레이어 퓨전과 vLLM 최적 커널 매핑을 적용한다.

🧩 주요 포인트

1. transformers는 450개 이상의 아키텍처를 일관된 API로 지원하는 참조 모델링 라이브러리이며, vLLM은 이 모델 코드를 고성능 추론 엔진 안에서 실행할 수 있게 해 왔다.
2. 이번 업데이트의 핵심은 transformers 모델링 백엔드가 많은 LLM 아키텍처에서 vLLM의 손수 작성된 네이티브 구현과 같은 수준이거나 더 높은 처리량을 보였다는 점이다.
3. 글은 Qwen3 4B dense, Qwen3 32B dense, Qwen3 235B-A22B-FP8 MoE를 대상으로 단일 GPU, 텐서 병렬, 데이터 병렬 및 전문가 병렬 조건에서 비교했다고 설명한다.
4. 사용자는 --model-impl transformers 플래그를 붙여 Hugging Face 모델을 vLLM에서 실행할 수 있으며, 일반적인 병렬화 옵션과 함께 사용할 수 있다.
5. 새 백엔드는 torch.fx로 모델 그래프를 정적으로 분석하고 ast로 소스 코드를 조작해 런타임에 추론용 레이어 퓨전과 vLLM 최적 커널 매핑을 적용한다.

🧠 상세 정리

1. transformers와 vLLM 통합의 배경

글은 transformers 라이브러리가 머신러닝의 참조 모델링 라이브러리로 자리 잡았다는 점에서 출발한다. transformers는 450개 이상의 아키텍처를 일관된 API로 지원하며, 모델 구현이 독립적이고 이해하기 쉽도록 설계되어 있다고 설명한다. 이런 특성 때문에 기여자는 transformers 코드를 읽으며 아키텍처 작동 방식을 익히고, 이후 vLLM, SGLang, MLX, llama.cpp 같은 다른 프레임워크로 옮길 수 있다. 저자들은 이 생태계 내 역할을 적극적으로 받아들이고 있으며, 그 일환으로 전년에 vLLM 안에 transformers를 모델링 백엔드로 통합한 일을 중요한 단계로 제시한다.

2. 이번 업데이트의 핵심 성과

글의 TL;DR은 transformers vLLM 백엔드가 많은 LLM 아키텍처에서 커스텀 vLLM 구현만큼 빠르거나 더 빨라졌다는 것이다. 모델 작성자는 자신이 이미 만든 transformers 구현을 활용해 별도의 포팅 없이 vLLM의 초고속 추론을 얻을 수 있다고 설명한다. 기존 통합은 LLM과 VLM을 vLLM 안에서 실행하게 해 주었고, transformers는 모델링 코드를 제공하며 vLLM은 continuous batching과 커스텀 attention kernel 같은 최적화된 추론 기법을 제공했다. 이번 글은 그 통합이 단순 실행 편의를 넘어 네이티브 속도에 근접하거나 이를 넘는 성능으로 확장되었음을 강조한다.

3. Qwen3 모델군을 통한 벤치마크 결과

저자들은 transformers 모델링 백엔드와 vLLM의 손수 작성된 네이티브 구현을 세 가지 서로 다른 Qwen3 모델에서 정면 비교했다고 밝힌다. 비교 대상은 단일 GPU에서 실행한 4B dense 모델, 2개 GPU 텐서 병렬로 실행한 32B dense 모델, 같은 8×H100 노드에서 데이터 병렬과 전문가 병렬을 사용한 235B 파라미터 FP8 Mixture-of-Experts 모델이다. 결과는 transformers 모델링 백엔드가 세 경우 모두에서 네이티브 처리량을 맞추거나 넘어섰다는 것이다. 글은 전체 재현 가능한 runner가 benchmark.sh gist로 제공된다고 덧붙이며, 비교 조건을 명확히 분리해 제시한다.

4. 사용 방법과 현재 제약

사용 방법은 --model-impl transformers 플래그 하나로 제시된다. 예시에서는 Qwen3-4B를 단일 GPU에서 실행하고, Qwen3-32B를 --tensor-parallel-size 2와 함께 실행하며, Qwen3-235B-A22B-FP8 MoE를 --data-parallel-size 8 및 --enable-expert-parallel과 함께 실행한다. 노드 메모리가 제한적이면 --max-model-len 8192를 추가할 수 있다고 설명한다. 다만 모든 모델이 현재 지원되는 것은 아니며, linear attention을 쓰는 모델은 아직 지원되지 않지만 곧 지원될 예정이라고 한다. 또한 코드가 Hub 저장소 안에 있는 커스텀 모델은 규격에 맞게 작성되지 않았을 가능성이 있어 작동 가능성이 낮다고 명시한다.

5. 성능 비교 방식과 이전 한계

측정은 코드 경로만 다르고 나머지는 동일한 세 조건에서 이루어졌다고 설명한다. 첫 번째는 --model-impl vllm을 사용한 vLLM의 손수 작성된 네이티브 모델이고, 두 번째는 PR이 적용된 --model-impl transformers이며, 세 번째는 PR이 적용되지 않은 이전 transformers 백엔드다. 글은 기존 transformers 백엔드가 추론 병목으로 attention에 초점을 맞췄고, 런타임에 vLLM의 attention 구현을 연결해 효율적으로 실행할 수 있었다고 회고한다. 그러나 GPU 병렬화, 컴파일, fused kernel 등 최대 추론 성능을 끌어내는 여러 배포 차원은 여전히 커스텀 포팅이 더 잘 다룰 수 있었기 때문에, 최고 성능을 원하는 모델 작성자는 별도 vLLM 구현을 작성해야 했다.

6. torch.fx와 ast를 이용한 런타임 최적화

새로운 transformers 모델링 백엔드는 호환 아키텍처에 대해 런타임에 추론 특화 레이어 퓨전을 동적으로 적용해 커스텀 코드 구현의 속도에 맞춘다. 이를 위해 torch.fx로 모델 그래프를 정적으로 분석하고, 최적화할 수 있는 알려진 패턴을 찾은 뒤 ast, 즉 abstract syntax tree를 사용해 소스 코드를 조작하고 일부 연산을 제자리에서 다시 쓴다. 대표적인 성과로는 Mixture-of-Experts 모델의 Expert Parallelization에 쓰이는 vLLM의 초최적화 커널로 여러 연산을 매핑하는 fused operation이 언급된다. 또한 MergedColumnParallelLinear와 QKVParallelLinear 같은 vLLM 블록을 통해 텐서 병렬 계획을 추론하고, decoder block list가 쉽게 식별되면 pipeline parallel 계획도 추론할 수 있다고 설명한다.

7. 모델 코드 재사용성과 향후 설명 계획

조작된 모델은 전용 vLLM 모델 구현과 마찬가지로 torch.compile과 CUDA Graphs를 통과할 수 있어, 컴파일 가능한 상태를 유지한다고 설명한다. 동시에 transformers 모델 구현은 vLLM 전용 구현과 달리 학습에도 사용할 수 있으므로, 같은 모델 코드를 학습, 평가, RL rollout, 추론 serving에 활용할 수 있다는 장점이 제시된다. 글은 이 접근이 호환 모델에서 별도 추론 최적화 코드를 한 줄도 작성하지 않고 네이티브 vLLM 추론 속도를 얻는 결과로 이어진다고 정리한다. 마지막으로 저자들은 최적화된 추론 방법 내부를 더 자세히 설명하고, 모델을 어떻게 조작해 이런 방법에 맞추는지 다루는 상세 블로그 글을 준비 중이라고 밝힌다.

🧾 핵심 주장 / 시사점

• 이 업데이트의 실질적 의미는 모델 작성자가 transformers 구현을 한 번 작성한 뒤, 별도 vLLM 포팅 없이 고성능 추론 경로를 바로 활용할 수 있다는 점이다.
• 성능 개선의 핵심은 단순히 attention 구현을 갈아 끼우는 수준을 넘어, 그래프 분석과 소스 코드 재작성으로 병렬화와 fused kernel에 필요한 구조를 런타임에 만들어 내는 데 있다.
• 동일한 transformers 모델 코드를 학습, 평가, RL rollout, vLLM serving에 함께 사용할 수 있다는 점은 모델 구현과 추론 최적화 사이의 중복 작업을 줄이는 방향을 보여준다.

✅ 액션 아이템

• vLLM에서 --model-impl transformers 플래그를 붙여 Hugging Face 모델을 실행하고, 텐서·데이터·전문가 병렬 옵션과의 동시 적용을 실측한다.
• transformers가 지원하는 450개 이상 아키텍처에서 Qwen3 4B dense, 32B dense, 235B-A22B-FP8 MoE를 동일 조건으로 비교해 처리량 방향을 정리한다.
• torch.fx 기반 정적 그래프 분석과 AST 조작 경로에서 레이어 퓨전 및 vLLM 최적 커널 매핑 효과를 추론 성능 지표로 정량 점검한다.

❓ 열린 질문

• Qwen3 4B dense, 32B dense, 235B-A22B-FP8 MoE에서 네이티브 vLLM 대비 처리량이 실제로 동일하거나 더 높은가?
• 단일 GPU뿐 아니라 텐서 병렬·데이터 병렬·전문가 병렬 조건에서도 성능 우위가 동일하게 유지되는가?
• 새 백엔드의 torch.fx/AST 처리 단계가 특정 아키텍처에서 예외 동작이나 안정성 이슈를 유발할 가능성은 어디까지인가?