[vllm] vLLM에 Humming MXFP4 MoE 백엔드 통합: 성능 최적화와 양자화의 만남

2026년 5월 3일수정: 2026년 5월 3일

PR 링크: vllm-project/vllm#41083 상태: Merged | 변경: +None / -None

들어가며

대규모 언어 모델(LLM)의 추론 성능은 서비스의 효율성과 비용에 직결되는 중요한 요소입니다. 특히 Mixture-of-Experts (MoE) 모델은 파라미터 수가 많아 높은 성능 최적화가 필수적입니다. 이번 PR은 vLLM에 Humming MXFP4 MoE 백엔드를 통합하여 MoE 모델의 추론 성능을 획기적으로 개선하는 것을 목표로 합니다. Humming은 혼합 정밀도(Mixed Precision) 양자화를 통해 모델 크기를 줄이고 연산 속도를 높이는 데 특화된 라이브러리입니다. 이 통합을 통해 DeepSeek-V4와 같은 MoE 모델의 추론 속도를 크게 향상시키면서도 정확도를 유지하는 방법을 살펴보겠습니다.

코드 분석: Humming MoE 백엔드 통합

이번 PR은 크게 두 가지 핵심 변경 사항을 포함합니다. 첫째, vLLM의 커널 설정에 Humming 백엔드를 추가하여 사용자가 Humming을 선택할 수 있도록 합니다. 둘째, fused_humming_moe.py 파일을 수정하여 Humming MoE 커널의 동작 방식을 개선하고, 특히 GEMM(General Matrix Multiply) 연산의 타입을 보다 유연하게 설정할 수 있도록 합니다.

1. `vllm/config/kernel.py`: Humming 백엔드 추가

이 변경은 vLLM이 지원하는 커널 목록에 humming을 추가하여, 사용자가 --moe-backend humming 플래그를 통해 Humming 백엔드를 명시적으로 선택할 수 있도록 합니다.

Before:

KERNEL_BACKENDS: list[str] = [
    "flashinfer_cutlass",
    "flashinfer_cutedsl",
    "marlin",
    "aiter",
    "emulation",
]

class KernelConfig:
    # ...
    - "marlin": Use Marlin kernels (weight-only quantization)
    - "aiter": Use AMD AITer kernels (ROCm only)
    - "emulation": use BF16/FP16 GEMM, dequantizing weights and
                   running QDQ on activations.

After:

KERNEL_BACKENDS: list[str] = [
    "flashinfer_cutlass",
    "flashinfer_cutedsl",
    "marlin",
    "humming",
    "aiter",
    "emulation",
]

class KernelConfig:
    # ...
    - "marlin": Use Marlin kernels (weight-only quantization)
    + "humming": Use Humming Mixed Precision kernels
    - "aiter": Use AMD AITer kernels (ROCm only)
    - "emulation": use BF16/FP16 GEMM, dequantizing weights and
                   running QDQ on activations.

무엇이 왜 좋은가: 이 변경은 vLLM의 확장성을 높이고, 다양한 최적화 백엔드를 선택할 수 있는 유연성을 제공합니다. 특히 Humming은 MXFP4와 같은 혼합 정밀도 양자화를 지원하여, 기존 Marlin과 같은 W4A16 양자화 방식보다 더 공격적인 양자화(예: W4A8)를 통해 메모리 사용량을 줄이고 연산 효율을 높일 수 있는 잠재력을 제공합니다. 이는 사용자가 특정 하드웨어(예: Blackwell GPU)나 성능 요구사항에 맞춰 최적의 백엔드를 선택할 수 있게 합니다.

2. `vllm/envs.py`: `VLLM_HUMMING_MOE_GEMM_TYPE` 환경 변수 개선

이 변경은 VLLM_HUMMING_MOE_GEMM_TYPE 환경 변수의 처리 로직을 개선합니다. 기존에는 maybe_convert_bool 함수를 사용하여 불리언 값으로 변환하려 했으나, GEMM 타입은 문자열(indexed, grouped 등)이므로 이 변환이 적절하지 않았습니다. 이제는 환경 변수 값을 직접 문자열로 가져오도록 수정하여 올바른 GEMM 타입 설정을 가능하게 합니다.

Before:

    "VLLM_HUMMING_MOE_GEMM_TYPE": lambda: maybe_convert_bool(
        os.environ.get("VLLM_HUMMING_MOE_GEMM_TYPE", None)
    ),

After:

    "VLLM_HUMMING_MOE_GEMM_TYPE": lambda: os.environ.get(
        "VLLM_HUMMING_MOE_GEMM_TYPE", None
    ),

무엇이 왜 좋은가: 이 수정은 VLLM_HUMMING_MOE_GEMM_TYPE 환경 변수가 의도한 대로 문자열 값을 받아 GEMM 연산 타입을 정확하게 제어할 수 있도록 합니다. GEMM 타입은 MoE 커널의 성능에 직접적인 영향을 미치므로, 올바른 타입 선택은 최적의 성능을 달성하는 데 중요합니다. 특히 grouped_contiguous와 같은 새로운 GEMM 타입이 도입되면서, 이 환경 변수를 통해 사용자가 특정 하드웨어(예: TMA를 지원하는 Blackwell GPU)에 최적화된 GEMM 타입을 선택할 수 있게 됩니다.

3. `vllm/model_executor/layers/fused_moe/fused_humming_moe.py`: Humming MoE 커널 로직 개선

이 파일은 Humming MoE 백엔드의 핵심 로직을 담고 있습니다. 주요 변경 사항은 다음과 같습니다.

3.1. GEMM 타입 결정 로직 개선

get_humming_moe_gemm_type 함수에서 GEMM 타입 결정 로직이 변경되었습니다. 특히 Blackwell GPU와 같은 최신 하드웨어의 특성을 반영하여 grouped_contiguous 타입을 우선적으로 고려하도록 수정되었습니다.

Before:

def get_humming_moe_gemm_type() -> str:
    env_gemm_type: str = envs.VLLM_HUMMING_MOE_GEMM_TYPE or ""
    env_gemm_type = env_gemm_type.lower()
    if env_gemm_type in ["indexed", "grouped"]:
        gemm_type = env_gemm_type
    elif current_platform.has_device_capability(90):
        # for device that supports TMA, use grouped gemm
        gemm_type = "grouped"
    else:
        gemm_type = "indexed"

    return gemm_type

After:

def get_humming_moe_gemm_type() -> str:
    env_gemm_type: str = envs.VLLM_HUMMING_MOE_GEMM_TYPE or ""
    env_gemm_type = env_gemm_type.lower()
    if env_gemm_type == "indexed":
        gemm_type = env_gemm_type
    elif env_gemm_type in ["grouped_contiguous", "grouped"]:
        gemm_type = "grouped_contiguous"
    else:
        gemm_type = "indexed"

    return gemm_type

무엇이 왜 좋은가: 이 변경은 Humming MoE 커널이 최신 GPU 아키텍처의 기능을 최대한 활용할 수 있도록 합니다. 특히 Blackwell GPU의 TMA(Tensor Memory Accelerator)와 같은 기능을 활용하는 grouped_contiguous GEMM 타입은 MoE 연산에서 데이터 접근 패턴을 최적화하여 성능을 크게 향상시킬 수 있습니다. 환경 변수를 통해 이를 제어할 수 있게 함으로써, 다양한 환경에서 최적의 성능을 끌어낼 수 있는 유연성을 제공합니다.

3.2. `HummingExpertsBase` 초기화 및 속성 접근 방식 변경

HummingExpertsBase 클래스의 초기화 방식과 일부 속성(예: humming_gemm_type, is_batched)의 접근 방식이 변경되었습니다. 특히 prepare_finalize 객체에 의존하던 로직을 제거하고, max_num_tokens와 num_dispatchers를 직접 인자로 받도록 하여 코드의 명확성과 유연성을 높였습니다.

Before:

class HummingExpertsBase(mk.FusedMoEExpertsModular):
    def __init__(
        self,
        layer: torch.nn.Module,
        quant_method: "HummingMoEMethod",
        prepare_finalize: mk.FusedMoEPrepareAndFinalizeModular | None = None,
    ):
        # ...
        if prepare_finalize is not None:
            max_num_tokens: int | None = None
            num_dispatchers: int | None = None
            if self.is_batched:
                max_num_tokens = prepare_finalize.max_num_tokens_per_rank()
                num_dispatchers = prepare_finalize.num_dispatchers()

            assert quant_method.moe_quant_config is not None
            super().__init__(
                moe_config=quant_method.moe,
                quant_config=quant_method.moe_quant_config,
                max_num_tokens=max_num_tokens,
                num_dispatchers=num_dispatchers,
            )
        else:
            assert not self.is_batched

    @property
    def humming_gemm_type(self) -> HummingGemmType:
        raise NotImplementedError

    @property
    def is_batched(self) -> bool:
        return self.activation_format() == mk.FusedMoEActivationFormat.BatchedExperts

After:

class HummingExpertsBase(mk.FusedMoEExpertsModular):
    def __init__(
        self,
        layer: torch.nn.Module,
        moe_config: FusedMoEConfig,
        quant_config: FusedMoEQuantConfig,
        max_num_tokens: int | None = None,
        num_dispatchers: int | None = None,
    ):
        # ...
        if self.is_batched():
            assert max_num_tokens is not None and num_dispatchers is not None

        super().__init__(
            moe_config=moe_config,
            quant_config=quant_config,
            max_num_tokens=max_num_tokens,
            num_dispatchers=num_dispatchers,
        )

    @staticmethod
    def humming_gemm_type() -> HummingGemmType:
        raise NotImplementedError

    @classmethod
    def is_batched(cls) -> bool:
        return cls.activation_format() == mk.FusedMoEActivationFormat.BatchedExperts

무엇이 왜 좋은가: 이 변경은 HummingExpertsBase의 생성자 인터페이스를 더 명확하고 직접적으로 만듭니다. prepare_finalize 객체를 통해 간접적으로 전달되던 max_num_tokens와 num_dispatchers를 직접 인자로 받음으로써, 객체 생성 시 필요한 정보를 명시적으로 전달할 수 있게 됩니다. 또한, humming_gemm_type과 is_batched를 @property에서 @staticmethod 또는 @classmethod로 변경하여, 인스턴스에 의존하지 않고 클래스 수준에서 해당 정보를 제공할 수 있도록 합니다. 이는 코드의 재사용성을 높이고, MoE 커널의 동작 방식을 더 유연하게 정의할 수 있게 합니다.

3.3. `is_supported_config` 메서드 추가

HummingExpertsBase에 is_supported_config 정적 메서드가 추가되어, 주어진 MoE 설정이 현재 Humming 백엔드에서 지원되는지 여부를 판단합니다. 이는 vLLM의 커널 오라클(kernel oracle)이 적절한 MoE 백엔드를 동적으로 선택하는 데 중요한 역할을 합니다.

After:

    @staticmethod
    def is_supported_config(
        cls: type[mk.FusedMoEExperts],
        moe_config: FusedMoEConfig,
        weight_key: QuantKey | None,
        activation_key: QuantKey | None,
        activation_format: mk.FusedMoEActivationFormat,
    ) -> tuple[bool, str | None]:
        if activation_format == mk.FusedMoEActivationFormat.BatchedExperts:
            supported = cls.activation_format() == activation_format
            reason = "activation_format mismatched"
        elif activation_format == mk.FusedMoEActivationFormat.Standard:
            if cls.activation_format() != mk.FusedMoEActivationFormat.Standard:
                supported = False
                reason = "activation_format mismatched"
            else:
                assert hasattr(cls, "humming_gemm_type")
                gemm_type = cls.humming_gemm_type().value.lower()
                preferred_gemm_type = get_humming_moe_gemm_type().lower()
                supported = preferred_gemm_type == gemm_type
                reason = "preferred gemm type mismatched"
        else:
            supported = False
            reason = "unsupported activation_format"

        return supported, None if supported else reason

무엇이 왜 좋은가: 이 메서드는 vLLM이 다양한 MoE 백엔드 중에서 현재 실행 환경과 설정에 가장 적합한 것을 선택할 수 있도록 돕습니다. 특히 activation_format과 humming_gemm_type을 기준으로 지원 여부를 판단함으로써, 특정 MoE 커널이 특정 조건에서만 최적의 성능을 발휘할 수 있음을 명시하고, 잘못된 커널 선택으로 인한 성능 저하를 방지합니다. 이는 vLLM의 견고성과 성능 최적화 전략에 중요한 기여를 합니다.

왜 이게 좋은가: 성능 수치와 일반적 교훈

이번 Humming MoE 백엔드 통합은 DeepSeek-V4-Flash 모델 벤치마크에서 매우 인상적인 성능 향상을 보여주었습니다.

벤치마크 결과 (TPS - Tokens Per Second):

	Prefill	Decoding
Marlin W4A16	10532.12	1650.82
Humming W4A16	15052.24	1727.73
Humming W4A8	19404.33	1730.07

주요 성능 향상:

Prefill 성능: Humming W4A16은 Marlin W4A16 대비 약 43% (10532.12 -> 15052.24) 향상되었으며, Humming W4A8은 무려 84% (10532.12 -> 19404.33) 향상되었습니다.
Decoding 성능: Humming W4A16/W4A8은 Marlin W4A16 대비 약 4-5% (1650.82 -> 1727.73/1730.07) 향상되었습니다.

이러한 성능 향상은 주로 MoE 커널과 MoE sum 커널의 최적화 덕분입니다. 특히 Humming W4A8의 Prefill 성능은 압도적인데, 이는 MXFP4 양자화와 최적화된 GEMM 연산이 긴 프롬프트 처리(Prefill)에 매우 효과적임을 보여줍니다.

정확도 테스트:

리뷰어의 요청에 따라 정확도 테스트도 수행되었습니다. GSM8K 벤치마크 결과는 다음과 같습니다.

	flexible-extract (exact_match)	strict-match (exact_match)
Marlin W4A16	0.9272	0.1486
Humming W4A16	0.9227	0.1471
Humming W4A8	0.9219	0.1433

Humming 백엔드는 Marlin 대비 약간의 정확도 하락을 보이지만, 그 차이는 매우 미미합니다 (약 0.5% 이내). 특히 W4A8과 같은 공격적인 양자화에서도 이 정도의 정확도 유지는 매우 긍정적인 결과입니다. 이는 Humming의 혼합 정밀도 양자화 기술이 성능과 정확도 사이의 균형을 잘 맞추고 있음을 시사합니다.

일반적 교훈:

양자화의 중요성: W4A16에서 W4A8로의 전환은 Prefill 성능을 크게 향상시켰습니다. 이는 적절한 양자화 전략이 메모리 대역폭과 연산 효율을 개선하여 전체적인 추론 속도를 높일 수 있음을 보여줍니다.
하드웨어 최적화: grouped_contiguous GEMM 타입과 같은 하드웨어별 최적화는 특정 GPU 아키텍처(예: Blackwell)의 잠재력을 최대한 활용하여 성능을 극대화할 수 있습니다.
모듈화된 백엔드 아키텍처: vLLM과 같이 모듈화된 백엔드 아키텍처는 새로운 최적화 기술(Humming)을 쉽게 통합하고, 사용자가 자신의 요구사항에 맞는 최적의 솔루션을 선택할 수 있도록 합니다.
성능-정확도 트레이드오프: 양자화는 일반적으로 성능 향상을 가져오지만, 정확도 손실이 발생할 수 있습니다. Humming은 이 트레이드오프를 효과적으로 관리하여, 미미한 정확도 손실로 큰 성능 이득을 제공합니다.

이번 PR은 vLLM이 MoE 모델의 추론 성능을 한 단계 더 끌어올리는 중요한 발걸음이며, 특히 고성능 컴퓨팅 환경에서 LLM을 효율적으로 서비스하는 데 기여할 것입니다.

참고 자료

⚠️ 알림: 이 분석은 AI가 실제 코드 diff를 기반으로 작성했습니다.

PR Analysis 의 다른글

이전글 [LlamaFactory] LlamaFactory: Qwen-VL 비디오 토큰 전처리 최적화로 450배 성능 향상 달성
현재글 : [vllm] vLLM에 Humming MXFP4 MoE 백엔드 통합: 성능 최적화와 양자화의 만남
다음글 [sglang] SGLang UnifiedRadixTree에 HiCache 프레임워크 도입: 하이브리드 모델 성능 최적화

[vllm] vLLM에 Humming MXFP4 MoE 백엔드 통합: 성능 최적화와 양자화의 만남

들어가며

코드 분석: Humming MoE 백엔드 통합

1. `vllm/config/kernel.py`: Humming 백엔드 추가

2. `vllm/envs.py`: `VLLM_HUMMING_MOE_GEMM_TYPE` 환경 변수 개선

3. `vllm/model_executor/layers/fused_moe/fused_humming_moe.py`: Humming MoE 커널 로직 개선

3.1. GEMM 타입 결정 로직 개선

3.2. `HummingExpertsBase` 초기화 및 속성 접근 방식 변경

3.3. `is_supported_config` 메서드 추가

왜 이게 좋은가: 성능 수치와 일반적 교훈

참고 자료

댓글

관련 포스트

PR Analysis 의 다른글