Ascend 가속기에서 대형 언어 모델을 구동하는 개발자를 위한 vLLM Ascend의 새 정식 버전이 나왔다. 주요 모델에 맞춘 실행 방식과 캐시·병렬 처리 지원을 넓혔으며, 기존 배포를 옮길 때는 모델별 실행기 선택과 다음 버전의 전환 계획을 함께 살펴볼 필요가 있다.
1. 주요 모델에 맞춘 실행 경로가 늘었다
프로젝트가 10월 29일 공개한 vLLM Ascend 0.30.0은 상위 vLLM 0.30.0에 맞춰 빌드됐다. 출시 후보 버전 이후 발견된 어텐션, 입력 정보의 중요도를 반영하는 계산 관련 문제, 캐시 전송, 새 실행기의 안정성 문제에 대한 수정도 포함했다.
DeepSeek V4.1에는 새 실행기에서 4비트 잠재 KV 캐시를 쓰는 TurboQuant 지원이 추가됐다. 추론 중 보관하는 중간 데이터를 낮은 정밀도로 저장하는 방식이며, 기존 실행기에서도 묶음 형태의 KV 캐시를 사용할 수 있다.
Kimi K3는 후보 답변을 먼저 만든 뒤 검증하는 추측 디코딩과 여러 연산을 합치는 최적화 등을 포함한 전체 실행 지원을 얻었다. Ascend 950에서는 위치 정보를 반영하는 회전 연산을 쓰지 않는 어텐션 경로도 지원한다.
GLM-5.3-Flash에는 필요한 부분을 골라 계산하는 희소 어텐션과 8비트 묶음 KV 캐시 지원이 추가됐다. 작은 슬롯에서 캐시 페이지가 과다 할당되는 문제도 수정했다.
Qwen3.8-27B는 서로 떨어져 저장된 KV 캐시를 처리하도록 보강됐다. 310P에서 양자화 모델을 배포할 때의 성능과 커널, 장치 연산을 수행하는 저수준 코드의 호환성 문제도 수정해, 해당 하드웨어를 쓰는 개발자가 확인할 변경 사항이 됐다.
2. 캐시를 미리 읽고 불필요한 처리를 줄였다
캐시 풀, 캐시 데이터를 모아 관리하는 공간에는 모델의 레이어별 데이터를 적재할 때 앞으로 쓸 구간을 미리 읽는 기능이 추가됐다. 캐시 조회와 페이지 관리의 부담을 줄이고, 병렬 실행 중 불필요한 CPU 동기화를 생략하는 변경도 들어갔다.
추측 디코딩을 병렬 실행과 결합하는 지원도 넓어졌다. 입력을 나눠 처리하는 PCP에서는 추측 디코딩 요청 분할을 보강했다.
프로젝트는 이 같은 변경을 성능 개선 항목으로 소개했다. 배포를 검토하는 개발자에게는 자신이 쓰는 모델에서 어떤 캐시·병렬 실행 조합을 활용할 수 있는지가 이번 변경을 살펴볼 기준이 된다.
3. 기본 실행기는 유지하고 다음 전환을 준비한다
이번 버전의 기본 실행기는 V1이며, 새 실행기의 이름은 V2다. 실행기는 모델 계산을 실제로 진행하는 구성 요소로, 이번 릴리스는 두 세대가 함께 쓰이는 시점에 해당한다.
설치 기준도 함께 제시됐다. CANN은 9.2.1이며, 릴리스 이미지의 Python은 3.12다.
PyTorch는 2.10.0, torch_npu는 2.10.0.post7에 맞춰져 있다. 기존 환경을 갱신하는 개발자는 모델 지원뿐 아니라 이 기반 구성도 함께 대조할 수 있다.
모델별 배포 방법은 릴리스 노트가 연결한 공식 튜토리얼에서 확인하도록 안내됐다. 새 기능을 시험할 때는 사용할 모델의 실행 경로와 현재 환경을 먼저 맞추는 것이 출발점이다.
4. 선택지 확대의 대가는 기존 구성 점검이다
캐시 관리의 낭비를 줄이고 양자화·병렬 실행 조합을 늘린 점은 모델 운영의 선택지를 넓힌다. 반면 프로젝트는 사용량이 줄어든 구형 모델을 유지 비용에 따라 순차적으로 지원 종료할 예정이며, 레이어 분할과 FlashComm2 등 폐기 대상 기능은 이미 제거했다.
프로젝트는 다음 버전에서 기존 실행기를 제거하고 새 실행기로 완전히 전환할 계획이라고 밝혔다. 따라서 새로 배포하는 팀은 추가된 모델 지원을 활용할 수 있고, 기존 배포를 유지하는 팀은 사라지는 기능과 실행기에 의존하는 구성을 찾아 전환 일정을 잡는 일이 함께 생긴다.
5. 모델별 실행 조건과 캐시 제약은 남았다
일부 모델은 새 실행기를 켜야 지원되며, Gemma-4-E4B-it은 어텐션 연산자 문제로 실행에 실패하고 GLM-5.3의 구조화 출력은 상위 프로젝트의 같은 버전과 결과가 맞지 않는다고 릴리스 노트는 안내했다.
Mooncake 기반 캐시 풀링은 RoCE 네트워크, 이더넷 기반 저지연 통신을 쓰는 네트워크에서 SSD 오프로드, 캐시 데이터를 SSD로 옮겨 처리하는 기능을 지원하지 않으며, 레이어별 풀링에 SSD 오프로드와 파이프라인 병렬, 계산을 단계별로 나눠 이어 처리하는 방식을 함께 쓰면 SSD 캐시를 찾지 못하는 문제도 남아 있다.
이번 릴리스의 핵심은 모델별 실행 선택지를 넓히되, 기존 배포에는 다음 실행기 세대로 옮길 준비를 앞당긴다는 데 있다.
