Arm CPU 위의 vLLM 최적화: 실행 가능성에서 실전 추론으로

도입

LLM 서빙에서 CPU는 여전히 중요한 배포 선택지다. 전용 가속기만큼의 최고 성능을 목표로 하지는 않지만, 인프라가 널리 깔려 있고 비용과 운영 복잡도 측면에서 장점이 있다. Arm Neoverse 기반 서버가 클라우드와 기업 데이터센터에서 확대되면서, vLLM이 Arm CPU에서 얼마나 잘 동작하는지도 중요해졌다. vLLM Blog는 PyTorch, oneDNN, KleidiAI 등과 함께 진행한 Arm CPU 추론 스택 개선 내용을 공개했다.

핵심 포인트

• 사용성부터 보강: Arm CPU 경로에는 사전 빌드 wheel과 Docker 이미지가 제공되고, 크래시, 정확도, 스레딩, CPU 활용률 관련 문제가 수정됐다. chunked prefill, prefix caching, INT8 W8A8 / W4A8 추론, GPT-OSS, Whisper, Qwen 3.5 / 3.6 모델 지원도 포함됐다.
• 병목은 GEMM만이 아니었다: 2025년 10월 초기 벤치마크에서 모델 실행 시간의 약 80%는 dense layer에 쓰였고, 해당 부분은 이미 최적화된 BF16 GEMM으로 전달됐다. 그러나 단독 GEMM 커널 효율은 기대치에 가까웠기 때문에, 실제 병목은 할당기, 런타임 동기화, 프레임워크 오버헤드, attention 커널, 양자화 실행 경로에 분산돼 있었다.
• 메모리 할당 개선 효과가 컸다: PyTorch가 Arm에서 glibc malloc을 사용할 때 큰 메모리 할당의 재사용이 좋지 않아 페이지 폴트와 스레드 경쟁이 발생했다. Arm CPU에서 mimalloc을 기본 할당기로 활성화하자 Llama 3.1 8B 오프라인 처리량은 2.3배 향상됐고, 낮은 동시성 서빙에서는 약 7배 개선이 보고됐다.
• 고코어 환경에서는 동기화가 문제: 프로파일링 결과 paged attention 시간의 74%가 OpenMP 동적 스케줄링 경로에 소비되는 사례가 있었다. Neoverse V2는 LSE 기반 하드웨어 원자 명령을 지원하지만, 기존 PyTorch 런타임은 이를 충분히 활용하지 못했다. LSE 원자 명령을 사용하는 libgomp 빌드로 Llama 3.1 8B 오프라인 처리량은 9% 증가했고, 낮은 동시성 TPOT 지연은 15% 줄었다.
• BF16 가중치 사전 패킹: 고성능 GEMM 커널은 커널의 벡터화와 캐시 접근에 맞는 블록형 가중치 레이아웃을 선호한다. 매 호출마다 변환 비용을 내면 낮은 동시성에서 손실이 커진다. oneDNN과 Compute Library for Arm Architecture를 활용한 경로는 모델 warmup 중 BF16 가중치를 패킹하고 추론 중 재사용한다. 그 결과 오프라인 처리량은 16% 향상되고 낮은 동시성 TPOT는 60% 감소했다.
• Arm에 맞춘 paged attention: 기존 CPU paged attention은 QK, PV, softmax 지수 계산에서 참조 구현에 의존했다. 새 구현은 Arm BFMMLA Advanced SIMD 명령 기반 커스텀 GEMM과 벡터화된 3차 다항식 근사 softmax exponential을 사용한다. paged attention은 최대 4배 빨라졌고 Llama 3.1 8B 오프라인 처리량은 12% 향상됐다.

의미와 영향

이번 최적화는 Arm CPU에서 vLLM을 단순히 실행하는 단계를 넘어, 실제 서빙 플랫폼 후보로 평가할 수 있게 만드는 작업에 가깝다. 기업 입장에서는 낮은 동시성, 비용 민감형 서비스, 기존 CPU 인프라 재사용 같은 시나리오에서 선택지가 넓어진다.

또한 LLM 추론 성능은 하나의 행렬곱 커널만으로 결정되지 않는다는 점도 분명해졌다. 메모리 관리, 스레드 런타임, 가중치 레이아웃, attention 구현, 양자화 경로가 모두 합쳐져 엔드투엔드 성능을 만든다. Arm CPU가 추론 인프라에서 더 큰 역할을 하려면 이러한 스택 전반의 최적화가 계속 중요해질 것이다.

출처: vLLM Blog