Humming: vLLM과 Ant Group, 양자화 추론을 위한 범용 커널 라이브러리 오픈소스 공개
Ant Group과 vLLM 커뮤니티가 양자화 추론을 위한 범용 고성능 커널 라이브러리인 Humming을 오픈소스로 공개했습니다. Humming이 중요한 이유는 양자화 형식마다 하나의 커널을 만드는 방식을 통합 양자화 표현, JIT 컴파일 경로, 공유 CUDA 컴포넌트로 대체하여, 단일 라이브러리로 Turing 이후의 NVIDIA GPU와 T-Head의 Zhenwu 810E와 같은 CUDA 호환 장치에서 Dense 및 MoE 워크로드를 모두 지원하면서도, 다양한 대표 워크로드에서 vLLM Marlin, FlashInfer, DeepGEMM 대비 상당한 속도 향상을 보고하기 때문입니다.
코드는 github.com/vllm-project/humming에서 확인할 수 있습니다.
양자화 추론에 범용 커널 라이브러리가 필요한 이유
양자화는 가중치와 활성화의 정밀도를 낮춰 메모리 사용량과 데이터 이동을 줄이고, 계산 효율성도 향상시킬 수 있습니다. 모델과 추론 워크로드가 성장함에 따라 메모리 용량, 메모리 대역폭, 계산 비용이 점점 더 배포를 제약합니다.
이러한 압박은 MoE 모델에서 가장 두드러집니다: 각 토큰은 전문가의 일부만 활성화하지만, 전체 가중치 집합은 여전히 저장해야 합니다. 발표에서 인용된 DeepSeek-V3는 6710억 개의 파라미터를 가지며 토큰당 370억 개가 활성화됩니다.
양자화 요구 사항은 모델과 GPU 세대에 따라 크게 다릅니다. 일반적인 구성에는 WNA16, W8A8, W4A8, W4A4가 있으며, 여기서 W와 A는 가중치 및 활성화 비트 폭을, N은 가변 가중치 비트 폭을 나타냅니다. 동일한 정밀도에서도 INT4와 NVFP4와 같은 방식은 숫자 형식과 스케일링이 다릅니다. 스케일링 세분성, 스케일 표현, 그룹 크기, 대칭 또는 비대칭 양자화는 구성 공간을 더욱 확장합니다.
이러한 저장 및 계산 절감은 효율적인 커널이 있어야만 낮은 지연 시간과 높은 처리량으로 이어집니다. Prefill, Decode, 다양한 MoE 전문가 부하는 계산과 메모리에 서로 다른 요구를 하며, 커널은 변환, 역양자화, 스케줄링 오버헤드를 낮게 유지하면서 이러한 워크로드에 적응해야 합니다.
모든 조합에 대해 전용 커널을 개발하고 통합하는 것은 점점 증가하는 유지보수 부담을 만듭니다: 각 추가는 자체 가중치 전처리, 커널 선택, 프레임워크 어댑터, 테스트가 필요할 수 있으며, 최적화는 여러 구현에 걸쳐 수행되어야 합니다. Humming은 양자화 설명을 실행 선택과 분리하고 공유 컴포넌트에서 커널을 구성하여 이 문제를 해결합니다.
Humming의 아키텍처: 표현, 구성, 컴파일
Humming의 실행 경로는 세 부분으로 구성됩니다: 양자화된 계산을 표현하고, 하드웨어 및 워크로드에 대한 구성을 선택하고, CUDA 컴포넌트에서 커널을 컴파일합니다.
통합 양자화 표현
Humming은 다양한 양자화 도구에서 내보낸 모델을 Humming 표준 형식으로 변환합니다: 일관되게 구성된 가중치, 스케일, 영점 및 기타 텐서를 포함하는 공통 양자화 설명입니다. 이 표현은 각 방식의 양자화 의미를 보존하면서 가중치 형식, 스케일링 세분성, 스케일 데이터 유형, 영점 및 보조 스케일을 별도의 파라미터로 설명합니다. 활성화는 자체 숫자 형식과 양자화 설정을 가지며, 이러한 파라미터는 형식 및 하드웨어 제약 조건에 따라 결합될 수 있습니다.
예를 들어, 그룹별 INT4 가중치는 BF16 활성화와 짝을 이룰 수 있으며, 다른 스케일링 방식을 가진 저정밀 부동 소수점 가중치는 동일한 파라미터 시스템을 사용합니다. 이는 추론 프레임워크에 다양한 출처의 모델에 대한 공통 인터페이스를 제공합니다.
워크로드별 튜닝 및 JIT 컴파일
전처리는 파라미터를 검증하고, 차원을 패딩하며, 텐서를 대상 커널에 적합한 레이아웃으로 다시 패킹합니다. 그런 다음 Humming은 양자화 설명을 가중치 형태, GEMM 유형, 대상 GPU 및 계산 옵션과 결합하여 실행을 구성합니다. 세 가지 구성이 커널을 설명합니다:
- 레이어 구성은 텐서 형태, 데이터 유형, 양자화 파라미터 및 대상 아키텍처를 설명합니다.
- 계산 구성은 GEMM 유형과 배치 불변성, 입력 스케일 레이아웃과 같은 계산 옵션을 지정합니다.
- 튜닝 구성은 타일 형태, 파이프라인 단계 수, 워프 전문화, 메모리 액세스 및 MMA 명령을 선택합니다. 또한 동시성과 스케줄링을 제어합니다; TMA는 텐서별로 구성할 수 있습니다.
기본적으로 Humming은 장치별 휴리스틱을 사용하여 튜닝 구성을 선택하며, 입력 크기 범위에 대해 다른 구성을 준비하고 런타임에 적절한 커널에 디스패치할 수 있습니다. 발표에서는 작은 배치 크기에서 비동기 복사(cp.async)와 MMA를 사용하는 다단계 파이프라인이 TMA와 UMMA를 중심으로 구축된 파이프라인보다 성능이 뛰어날 수 있지만, 더 큰 배치 크기에서는 TMA와 UMMA가 더 나은 처리량을 제공할 수 있다고 언급합니다. Humming은 동일한 구성 및 컴포넌트 프레임워크 내에서 두 실행 경로를 모두 수용합니다.
세 가지 구성은 NVRTC 또는 NVCC로 컴파일된 커널을 전문화하며, 컴파일된 커널은 재사용을 위해 캐시됩니다. 추론은 선택된 커널을 전처리된 가중치 및 런타임 활성화와 결합합니다.
형식 및 아키텍처 전반에 걸친 공유 CUDA 컴포넌트
CUDA 수준에서 Humming은 작업 스케줄링, 데이터 이동, 역양자화 및 스케일링, Tensor Core 계산, 출력 처리를 재사용 가능한 컴포넌트로 구성합니다. 표준, 워프 전문화, 전용 UMMA 파이프라인을 제공하며, 각 실행 전략에 필요한 데이터 흐름과 동기화를 사용하면서 호환 가능한 컴포넌트를 공유합니다.
각 컴포넌트 그룹은 다양한 변형 소스를 처리합니다:
- 숫자 처리는 양자화 형식을 처리합니다. 디코딩 및 산술 컴포넌트는 비트 폭, 정수 또는 부동 소수점 표현, 스케일 및 영점을 고려합니다. 역양자화 및 스케일링은 커널 계산에 통합됩니다.
- 메모리 및 계산 백엔드는 GPU 아키텍처를 처리합니다. Humming은 대상 아키텍처에 대한 데이터 이동 및 Tensor Core 구현을 선택하며, 지원되는 곳에서 비동기 복사, TMA 및 멀티캐스트를 사용합니다.
- 작업 매핑 및 스케줄링은 Dense 및 MoE 워크로드를 처리합니다. 각 GEMM 유형은 적절한 스케줄링 논리를 사용하며, 스케일링 및 바이어스 추가는 출력 단계에 융합될 수 있습니다.
JIT 컴파일은 세 가지 구성에 따라 이러한 컴포넌트를 결합하고 사용되지 않는 구현 분기를 제거합니다. 따라서 새 형식이나 아키텍처는 관련 컴포넌트를 확장하여 지원할 수 있으며, 공유 컴포넌트의 개선은 호환 가능한 구성에 이점을 제공하여 별도의 전문화된 커널의 중복 개발 및 유지보수를 줄입니다.
JIT 컴파일은 반복 튜닝에 충분히 빠릅니다
Humming의 CUDA 구현은 가볍고 무거운 커널 프레임워크 의존성을 피하므로 JIT 컴파일 속도가 빠릅니다. CUDA 13.4가 설치된 H200 서버에서 단일 W4A16 커널 컴파일 테스트에서 컴파일 캐시를 비활성화한 상태에서 컴파일 시간이 CUTLASS with NVCC의 23.35초에서 Humming with NVCC의 1.82초 또는 NVRTC의 1.88초로 단축되었습니다.
Humming은 또한 모델 워밍업 중에 커널을 병렬로 컴파일합니다. 보고된 테스트에서 단일 레이어의 GEMM에 대해 지원되는 모든 M 크기를 포함하는 커널을 컴파일하고 로드하는 데 약 2~4초만 소요되므로, 추론 전에 여러 전문화된 커널을 준비하는 것이 실용적입니다.
장치별 성능 튜닝
Humming은 GEMM 구성과 장치 파라미터를 모두 사용하여 커널을 최적화합니다. 양자화 형식, 행렬 형태, GPU 명령 지원, SM 수, 공유 메모리 및 레지스터 리소스가 모두 실행 선택에 영향을 줍니다.
기존 GPU에서 효율적인 W4A8-MXFP4 추론. Blackwell 이전 아키텍처는 기본 MXFP4 Tensor Core 지원이 없으며, 기존 W4A8-MXFP4 커널은 큰 M에서 역양자화 및 스케일링 오버헤드로 인해 제한될 수 있습니다. Humming은 커널 내에서 MXFP4 가중치를 지원되는 계산 형식으로 변환하는 빠른 MXFP4-to-INT8/FP8 역양자화 경로로 이를 해결합니다. 이 설정에서 이 경로는 작은 M에서 기존 W4A8 구현보다 훨씬 뛰어난 성능을 보이며, 큰 M에서는 W8A8 성능에 근접하므로 H200과 같은 GPU는 4비트 가중치의 저장 이점을 유지하면서 고성능 W4A8-MXFP4 커널을 실행할 수 있습니다.
각 장치에 맞춰진 역양자화 경로. 동일한 양자화 형식도 GPU에 따라 다른 구현의 이점을 얻을 수 있습니다. Humming은 장치에 맞는 디코딩, 숫자 변환 및 스케일링 경로를 선택하여 적절한 메모리 액세스 및 계산 파이프라인과 짝을 이루어 명령 및 데이터 이동 오버헤드를 줄입니다. 공유 컴포넌트는 이러한 최적화를 호환되는 Dense 및 MoE 커널에서 재사용할 수 있게 합니다.
장치별 휴리스틱을 갖춘 광범위한 튜닝 제어. Humming은 타일 형태, 파이프라인 단계 수, 워프 전문화, TMA, MMA 명령, CTA 동시성 및 Stream-K 스케줄링을 노출합니다. 장치별 휴리스틱은 GEMM 형태와 리소스 제약을 결합하여 병렬 처리, 데이터 재사용 및 파이프라인 오버헤드의 균형을 맞추고, 입력 크기가 변경됨에 따라 다른 실행 전략을 선택합니다. 개발자는 기본 구성을 직접 사용하거나 특정 모델 및 배포 시나리오에 맞게 개선할 수 있습니다.
결과: 장치 지원
Humming의 통합 아키텍처는 광범위한 GPU 지원을 가능하게 합니다. NVIDIA GPU의 경우 Humming은 Turing 이후의 모든 아키텍처를 완전히 지원하여 여러 하드웨어 세대에 공통 양자화 컴퓨팅 프레임워크를 제공합니다. 통합 JIT 아키텍처는 CUDA 프로그래밍과 호환되는 다른 GPU로 Humming을 확장하는 것을 간단하게 만들며, Humming은 이미 T-Head의 Zhenwu 810E를 완전히 지원합니다.
장치 지원은 명령 수준에서 균일하지 않습니다. B300(SM103)의 UMMA 명령은 더 이상 INT8 계산을 지원하지 않지만, 이전 MMA 명령은 여전히 INT8 GEMM을 상당히 낮은 성능으로 실행할 수 있습니다.
결과: 양자화 지원
Humming의 양자화 유형 지원은 주로 활성화와 가중치 유형 간의 호환성에 달려 있습니다. 통합 양자화 표현과 커널 아키텍처는 다양한 정수 및 부동 소수점 가중치 형식이 서로 다른 정밀도의 활성화와 함께 작동할 수 있게 합니다.
Humming은 또한 지수 비트가 0인 특수 부동 소수점 형식을 지원하며, 이 형식의 표현 가능한 값은 동일한 비트 폭의 대칭 정수와 일치합니다. 예를 들어, -128을 제외한 INT8과 float8e0m7은 모두 -127에서 127 사이의 정수를 나타냅니다. 이 형식의 가중치는 동일한 비트 폭의 INT 가중치와 동일한 활성화 유형 호환성을 가지며, Humming은 더 빠른 역양자화를 위해 적격한 대칭 정수 가중치를 자동으로 이 형식으로 변환합니다.
커뮤니티는 또한 Blackwell Tensor Core에서 두 가지 숨겨진 기능을 발견했습니다: PTX 유형 시스템에 노출되지 않은 두 가지 특수 부동 소수점 형식인 float4e0m3 및 float8e3m4에 대한 기본 지원입니다. Humming은 데이터센터 SM100/SM103 및 워크스테이션과 개인용 컴퓨팅을 위한 SM120/SM121 장치를 포함한 모든 Blackwell 아키텍처에서 이러한 기능을 지원합니다. Rubin은 이러한 두 가지 숨겨진 Tensor Core 형식을 지원하지 않으므로 이러한 기본 계산 경로에 대한 지원은 Rubin으로 확장되지 않습니다.
결과: 커널 마이크로벤치마크
커널 마이크로벤치마크는 vLLM 커뮤니티에서 실행되었으며, M이 1에서 8192까지의 모든 2의 거듭제곱을 포함하는 GEMM 성능을 측정합니다. 커널은 완전히 워밍업되고 콜드 L2 캐시로 독립적으로 타이밍되며, 샘플 사이에 짧은 일시 중지가 있습니다. MoE 속도 향상은 Gateup 및 Down GEMM 지연 시간의 합을 사용합니다.
WnA16
WnA16은 저비트 가중치와 FP16/BF16 활성화를 결합하여 널리 사용 가능한 16비트 계산 기능을 사용하면서 가중치 저장 및 메모리 트래픽을 줄입니다. W4A16 제품군은 Humming 최적화 작업의 주요 초점입니다.
Dense W4A16의 경우 Humming은 대부분의 테스트 구성에서 vLLM Marlin과 동일하거나 더 나은 성능을 보이며, 여러 Hopper 및 Blackwell 워크로드에서 상당한 이점을 제공합니다. 공통 기준선으로 cuBLAS를 사용하여 Humming은 작은 배치 크기에서 여러 장치에서 약 3~4배 속도 향상을 제공합니다. 배치 크기가 커짐에 따라 대형 배치 H200 워크로드에서 Marlin 성능의 약 2배에 도달하고 일부 B300 사례에서 3배 이상에 도달합니다.
이러한 이점은 MoE로 확장됩니다. Humming은 토큰이 전문가에 분산되고 전문가당 작업량이 부하에 따라 달라지는 워크로드를 위한 효율적인 Indexed 및 Grouped 경로를 제공합니다. H20 및 H200의 MXFP4 W4A16은 여러 중간~대형 배치 사례에서 Marlin 성능의 약 2배에 도달합니다. B300에서 MXINT4 및 NVFP4 경로는 대형 배치 크기에서 훨씬 더 큰 이점을 제공하며, Grouped 경로는 약 5배에 도달합니다. SM120 및 SM121의 결과도 Humming이 다양한 워크로드에서 Marlin 및 해당 FlashInfer 구현보다 우수함을 보여줍니다.
Humming의 최적화는 W4A16을 넘어 다른 WnA16 조합으로 확장됩니다. 공유 역양자화 및 계산 경로는 INT1, INT2, INT3, FP4~FP8을 포함한 다양한 비트 폭의 정수 및 부동 소수점 가중치에 대해 강력한 성능을 제공합니다. SM120의 최저 비트 구성은 BF16 cuBLAS 성능의 5배 이상을 초과하며, H20의 대형 배치 크기에서 여러 비트 폭은 BF16 cuBLAS에 가까운 계산 효율성을 유지합니다.
W8A8 / W4A8 / W4A4
Hopper와 함께 블록별 스케일링을 사용하는 FP8 W8A8은 고성능 양자화 추론의 주류 접근 방식이 되었습니다. Humming은 데이터 이동, 스케일링 및 전문가 스케줄링을 함께 최적화하여 이 기존 경로를 개선합니다. H20 및 H200의 작은 및 중간 배치 크기에서 Humming의 W8A8은 각각 DeepGEMM Contiguous 성능의 약 2.6배 및 2.5배에 도달하며, Indexed 및 Grouped 레이아웃 모두에서 경쟁력 있는 성능을 보입니다.
더 많은 모델이 기본 MXFP4 가중치 양자화를 채택함에 따라 더 작은 가중치 공간을 실용적인 추론 이점으로 전환하는 것이 점점 더 가치 있어집니다. Humming의 W4A8 경로는 MXFP4 가중치가 로드될 때 빠르게 역양자화하고 FP8 Tensor Core를 계산에 사용하여 Hopper에서 효율적인 W4A8-MXFP4 실행을 가능하게 합니다. DeepGEMM W8A8을 기준선으로 유지하면서 Humming의 W4A8은 작은 및 중간 배치 크기에서 H20에서 약 4.2배, H200에서 4.5배의 기준선 성능에 도달하며, 동일한 그림에서 Humming 자체 W8A8 결과보다 훨씬 뛰어납니다. FlashInfer CUTLASS W4A8도 Humming의 접근 방식을 기반으로 한 구현이지만, Humming의 현재 구현은 표시된 벤치마크에서 더 나은 성능을 달성합니다.
Blackwell은 MXFP8 및 MXFP4와 같은 마이크로스케일링 형식에 대한 기본 Tensor Core 지원을 추가합니다. 데이터센터 SM100/SM103 장치에서 워크스테이션 및 개인용 컴퓨팅용 SM120/SM121 장치에 이르기까지 Humming은 각 아키텍처의 저정밀 계산 기능을 사용하여 하나의 커널 및 튜닝 프레임워크 내에서 W8A8, W4A8 및 W4A4를 지원합니다. B300(SM103)에서 해당 정밀도의 DeepGEMM Contiguous를 기준선으로 사용하여 W8A8, W4A8 및 W4A4는 작은 및 중간 배치 크기에서 각각 약 1.25배, 1.6배 및 1.4배의 기준선 성능에 도달하며, 많은 워크로드에서 해당 FlashInfer 구현보다 우수합니다. Indexed 및 Grouped 경로 모두 기본 저정밀 계산의 이점을 얻습니다.
이러한 이점은 SM120 및 SM121로도 확장됩니다. Humming의 MXFP4 × MXFP8 W4A8 및 NVFP4 × NVFP4 W4A4는 대부분의 테스트 지점에서 FlashInfer CUTLASS보다 우수합니다. SM121의 작은 배치 크기에서 성능 향상은 W4A8의 경우 약 19%, W4A4의 경우 약 9% 에 도달합니다; SM120에서도 Humming은 대부분의 테스트 크기에서 앞서 있습니다.
엔드투엔드 추론 성능
Humming의 W4A8 이점은 모델 서빙으로 확장됩니다. 8개의 H20 GPU에서 TP=8로 DeepSeek-V4.1-Flash 테스트에서 모델의 MXFP4 가중치를 변경하지 않고 MoE 실행을 Marlin W4A16(BF16 활성화)에서 Humming W4A8(토큰별 FP8 활성화)로 전환하여 엔드투엔드 처리량이 약 14%~43% 개선되었고 평균 TTFT(첫 번째 토큰까지의 시간)가 약 25%~32% 감소했습니다. 처리량 이점은 동시성에 따라 증가합니다: 동시성 64에서 출력 처리량은 442.37에서 633.94 토큰/초로 증가하고, 출력 토큰당 평균 시간(TPOT)은 약 31% 감소합니다.
| 동시성 | MoE 백엔드 | 입력 처리량(토큰/초) ↑ | 출력 처리량(토큰/초) ↑ | TTFT(ms) ↓ | TPOT(ms) ↓ |
|---|---|---|---|---|---|
| 1 | vLLM Marlin W4A16 | 2827.15 | 88.30 | 543.13 | 9.24 |
| 1 | Humming W4A8 | 3226.23 (+14.1%) | 100.77 (+14.1%) | 383.80 (-29.3%) | 8.46 (-8.5%) |
| 2 | vLLM Marlin W4A16 | 4781.06 | 149.33 | 794.31 | 10.33 |
| 2 | Humming W4A8 | 5646.98 (+18.1%) | 176.38 (+18.1%) | 555.66 (-30.0%) | 9.20 (-10.9%) |
| 4 | vLLM Marlin W4A16 | 7427.64 | 231.99 | 1422.32 | 11.72 |
| 4 | Humming W4A8 | 9160.81 (+23.3%) | 286.12 (+23.3%) | 971.74 (-31.7%) | 10.22 (-12.9%) |
| 8 | vLLM Marlin W4A16 | 9190.03 | 287.04 | 2049.81 | 19.90 |
| 8 | Humming W4A8 | 12263.89 (+33.4%) | 383.04 (+33.4%) | 1386.91 (-32.3%) | 15.49 (-22.2%) |
| 16 | vLLM Marlin W4A16 | 11124.67 | 348.96 | 2463.69 | 36.28 |
| 16 | Humming W4A8 | 15171.00 (+36.4%) | 475.89 (+36.4%) | 1844.71 (-25.1%) | 26.44 (-27.1%) |
| 32 | vLLM Marlin W4A16 | 12669.43 | 398.83 | 3546.74 | 66.44 |
| 32 | Humming W4A8 | 17804.79 (+40.5%) | 560.49 (+40.5%) | 2465.47 (-30.5%) | 47.48 (-28.5%) |
| 64 | vLLM Marlin W4A16 | 13937.42 | 442.37 | 5467.35 | 123.25 |
| 64 | Humming W4A8 | 19973.00 (+43.3%) | 633.94 (+43.3%) | 3882.94 (-29.0%) | 85.70 (-30.5%) |
설치
Humming은 PyPI에서 설치할 수 있습니다:
pip install humming-kernels
Humming은 CUDA 컴파일러를 사용하여 커널을 즉시 생성합니다. 시스템에 CUDA 컴파일러가 없는 경우 다음 설치 옵션 중 하나를 선택하여 환경의 CUDA 주요 버전에 맞는 컴파일 종속성을 포함하세요:
pip install "humming-kernels[cu12]" # CUDA 12
pip install "humming-kernels[cu13]" # CUDA 13
Humming은 매우 가볍고 단순한 종속성과 약 500KB 크기의 휠 패키지를 갖추고 있습니다. 온디맨드 컴파일은 대규모 사전 컴파일된 커널 번들을 피합니다. 원칙적으로 PyTorch 2.7을 실행할 수 있는 모든 환경에서 Humming도 실행할 수 있습니다.
vLLM에서 Humming 사용
Humming은 vLLM에 깊이 통합되어 있습니다. vLLM 0.29.0부터 CUDA 설치에는 Humming이 종속성으로 포함되므로 별도의 Humming 설치가 필요 없습니다. Humming은 Turing 이후의 모든 아키텍처(SM75 이상)에서 NVIDIA GPU를 지원합니다.
--linear-backend 및 --moe-backend 옵션은 각각 Dense GEMM 및 MoE GEMM의 계산 백엔드로 Humming을 선택합니다. 예를 들어, 텐서 병렬 크기 8로 둘 다 Humming을 활성화합니다:
vllm serve deepseek-ai/DeepSeek-V4.1-Flash-1017 \
--tensor-parallel-size 8 \
--linear-backend humming --moe-backend humming
--quantization humming 옵션은 Humming이 지원하지만 vLLM이 더 이상 지원하지 않거나 아직 기본적으로 지원하지 않는 형식(예: GPTQ INT3)에 대한 호환 경로로만 사용됩니다:
vllm serve hfl/Qwen2.5-VL-3B-Instruct-GPTQ-Int3 --quantization humming
활성화 유형 선택
기본적으로 Humming은 체크포인트에 지정된 활성화 유형을 사용하고 장치에 맞게 실행을 조정합니다. GPU가 해당 계산 유형을 지원하지 않으면 Humming은 지원되는 더 높은 정밀도 유형으로 폴백합니다. 예를 들어, 기본 MXFP4 지원이 없는 장치는 FP8, BF16 또는 FP16 계산 경로를 자동으로 사용할 수 있으므로 동일한 양자화된 체크포인트가 GPU 세대에 걸쳐 실행될 수 있습니다.
사용자는 vLLM의 양자화 구성 인터페이스를 통해 기본값을 재정의하여 배포에 적합한 활성화 유형을 선택할 수 있습니다. 다음 예제는 MoE 레이어의 활성화 유형을 MXFP8로 설정합니다:
vllm serve openai/gpt-oss-20b --moe-backend humming --quantization-config.moe.activation mxfp8
향후 계획
더 넓고 깊은 장치 지원
Humming은 새로운 장치의 계산 및 메모리 기능에 적응하면서 하드웨어 범위를 계속 확장할 것입니다. 명시된 우선 순위는 다음과 같습니다:
- Locality Domains를 포함한 더 많은 Rubin 아키텍처 기능을 지원하여 작업 매핑 및 데이터 액세스를 더욱 최적화합니다.
- Zhenwu M890을 포함한 더 많은 T-Head PPU 장치로 지원을 확장합니다.
- CUDA 프로그래밍과 호환되는 더 많은 장치를 지원하여 기존 양자화 형식, 커널 컴포넌트 및 튜닝 기능을 추가 하드웨어 플랫폼으로 가져옵니다.
Autotune 추가
타겟 튜닝을 통해 Humming은 대부분의 시나리오에서 이미 최첨단 성능을 달성할 수 있습니다. 그러나 다양한 모델 형태, 양자화 구성 및 장치 리소스로 인해 휴리스틱이 모든 경우에 최적의 구성을 선택하기 어렵습니다. 따라서 Humming은 대상 장치에서 후보 구성을 벤치마킹하여 각 워크로드에 더 나은 실행 파라미터를 찾는 autotune을 도입할 계획입니다. Autotune은 기존 휴리스틱을 보완하여 수동 구성 검색을 줄입니다.
추론 프레임워크와의 더 깊은 통합
Humming은 vLLM과 같은 추론 프레임워크와의 통합을 계속 심화하여 양자화된 모델 로딩, 백엔드 선택, 병렬 추론, 런타임 스케줄링 및 장치 적응 전반에 걸쳐 지원을 확장할 것입니다. 명시된 목표는 전문가 병렬 처리(EP)를 위한 양자화된 All-to-All(A2A) 통신과 같은 최적화를 포함하여 더 많은 양자화 방법이 프레임워크 기능의 전체 범위에서 작동하도록 하는 것입니다.
감사의 말
발표에서는 Ant Group의 Jinzhen Lin, Zekai Gu, Zhilin Huang과 vLLM 커뮤니티의 Michael Goin, Roberto L. Castro, Chauncey Jiang 및 기타 구성원들이 Humming 개발 전반에 걸쳐 기여하고 지원해준 것에 감사를 표합니다. 또한 다양한 하드웨어와 워크로드에서 Humming을 검증하고 개선하는 데 사용된 개발, 테스트 및 CI 리소스를 제공한 vLLM 커뮤니티에 감사합니다.
Humming의 설계와 최적화는 Marlin, vLLM Marlin, LMDeploy, DeepGEMM, FlashInfer, CUTLASS 및 기타 오픈소스 프로젝트에서 영감을 얻었습니다.