AIREITER고동시성 양자화 MoE 서비스를 Hopper급 하드웨어에서 운영한다면 vLLM Humming을 우선 검토할 만합니다. 다만 공개된 벤치마크만으로 모든 환경에서 성능이 좋아지는 범용 백엔드라고 보기는 어렵습니다. H100의 group-32 스케일링 결과와 Ampere의 batch-1 디코드 결과가 보여주듯, 실제 모델·GPU·양자화 포맷·배치 형태를 기준으로 직접 테스트해야 합니다.
결론부터 말하면: Humming은 조건부 업그레이드다
Humming은 양자화 추론을 위한 JIT 컴파일 GEMM 커널 라이브러리입니다. vLLM 커뮤니티가 Ant Group과 함께 공개했으며, 여러 양자화 포맷과 NVIDIA GPU 세대에서 dense 및 mixture-of-experts(MoE) 워크로드를 겨냥합니다. 공식 발표에서는 커널 성능이 최대 5배, 일부 엔드투엔드 MoE 성능이 14%–43% 향상됐다고 밝혔습니다. 다만 이 수치는 특정 모델, 하드웨어, 포맷과 동시성 조합에서 나온 결과입니다(vLLM 발표 자료).
도입 판단 기준은 간단합니다.
- 먼저 Humming을 시험할 환경은 지원되는 Hopper 또는 그 이후 구성에서 대규모 배치나 고동시성으로 운영하는 W4A8/W4A16 MoE 서비스입니다.
- 성능 향상을 전제하면 안 되는 환경은 batch-1 디코드, 구형 Ampere GPU, 특이한 group-wise 스케일링 구성입니다.
- 폴백을 반드시 준비해야 합니다. 현재 이슈에는 shape 라우팅 버그와 백엔드별 느린 경로가 보고돼 있습니다.
독립적으로 진행된 DeepSeek-V4.1-Flash 테스트에서는 튜닝한 vLLM 기본 구성으로 출력 토큰 5,856 tokens/s, data-parallel attention 적용 후 12,802 tokens/s, 수정된 Humming W4A8 커널 적용 후 17,634 tokens/s를 기록했습니다. 테스트 환경은 GH200 네 장이 장착된 노드 한 대였습니다(엔지니어링 보고서). 다만 이 결과에는 커널 수정과 튜닝 수정이 필요했으므로, 기본 설치만으로 얻을 수 있는 성능이 아니라 특정 워크로드 유형에서 가능한 결과로 해석해야 합니다.
vLLM 구성에서 Humming이 바꾸는 것
Humming은 양자화 행렬 곱을 유연한 JIT 커널 계층으로 옮겨 dense 및 MoE GEMM 경로를 처리합니다. Turing 이후의 NVIDIA 아키텍처와 여러 저비트 포맷을 지원하는 것을 목표로 합니다(Humming 저장소).
앞서 언급한 Hopper 테스트에서는 Marlin이 FP4 가중치를 BF16으로 디퀀타이즈한 반면, Humming은 SM 내부에서 FP4 가중치를 FP8로 업캐스트한 뒤 FP8 텐서 코어 연산을 사용했습니다. 이 차이는 디코드 워크로드가 연산 병목에 진입한 뒤에야 효과를 냈습니다. 그 전에는 메모리 트래픽, shape 타일링, 스케일 처리, 커널 실행 오버헤드, 레지스터 압박이 성능을 좌우할 수 있습니다.
성능 향상이 나타나는 조건과 사라지는 조건
공개된 자료는 하나의 대표 수치라기보다, 어떤 조건에서 성능 경계가 달라지는지를 보여주는 지도로 읽는 편이 정확합니다.
고동시성 MoE: 가장 뚜렷한 강점
공식 DeepSeek-V4.1-Flash 사례는 H20 GPU 8장에서 Marlin W4A16과 Humming W4A8을 비교했습니다. 엔드투엔드 MoE 처리량은 14%–43% 높았고, 동시성이 높을수록 개선 폭이 커졌습니다. 벤치마크를 재게시한 사용자는 동시성 64에서 출력 토큰 처리량이 442에서 634 tokens/s로 증가했다고 구체적으로 설명했지만, 이때 양자화 포맷도 함께 바뀌었다는 점을 덧붙였습니다(사용자 논의).
따라서 이 결과는 Humming이 유망한 서빙 경로라는 점을 뒷받침하지만, 동일한 포맷에서 커널만 교체해 얻은 순수한 배수 효과로 보기는 어렵습니다.
H100 group-32 W4A8: 반드시 확인해야 할 경고 사례
Humming 이슈 #38은 H100에서 MXFP4 가중치, MXFP8 활성값, group-32 스케일을 조합해 테스트했습니다. 비교한 모든 경로가 수치적으로는 정상 작동했지만, 보고된 행렬 크기에서는 fused 경로가 크게 느렸습니다. (4096,3072,4096)에서 fused Humming은 4.969 ms가 걸린 반면 QDQ 기준선은 0.580 ms였습니다. (4096,14336,4096)에서도 각각 22.298 ms와 1.256 ms를 기록했습니다(이슈 #38).
이후 이슈에는 로컬 튜닝으로 500 TFLOPS를 넘긴 결과와, 추가 전처리 및 가중치 저장 방식을 적용한 실험 구현에서 약 580–665 TFLOPS를 기록한 결과도 남았습니다. 즉 스케일 세분성, 타일 선택, 레지스터 압박, 전처리 방식에 따라 결과가 완전히 달라질 수 있습니다.
SM80 단일 요청 디코드: Ampere 성능을 섣불리 일반화하지 말 것
이슈 #72는 NVIDIA SM80에서 M=1 디코드 시 INT3 활용률이 낮다고 보고합니다. CMP 170HX에서 측정된 Humming 커널은 약 691 GB/s를 기록했습니다. 이 수치는 약 1,591 GB/s인 HBM 최대 대역폭의 43.4%에 해당합니다. 반면 RTX 5070 Ti의 SM120 테스트는 약 753 GB/s로, 827 GB/s의 최대 대역폭 대비 약 91% 활용률을 보였습니다(이슈 #72).
같은 보고서에 인용된 A800 저장소 결과에서는 M=1에서 692.4 GB/s를 기록했습니다. 명시된 최대 대역폭 2,039.04 GB/s의 34.0%에 불과한 수치입니다. 비교 대상인 일반 BF16은 1,232.3 GB/s에 도달했습니다.
“현재 SM80 INT3 Humming 경로가 이 워크로드에 최적화되지 않은 상태일 가능성이 있을까요?” —
yangfangyunyun, vLLM Humming 이슈 #72
설치 후 가장 안전하게 시작하는 방법
공식 자료에 따르면 CUDA 설치에 Humming이 의존성으로 포함되는 시점은 vLLM 0.29.0입니다. MoE 경로에는 --moe-backend humming, 지원되는 linear layer에는 --linear-backend humming을 사용할 수 있습니다. 모델별 경로는 문서에 나온 Humming 양자화 설정을 적용해야 합니다(vLLM 양자화 문서). 다만 아키텍처가 다른 환경에 플래그를 그대로 복사하기 전에 릴리스 문서와 모델 문서를 먼저 확인해야 합니다.
첫 테스트는 통제된 조건에서 진행하는 것이 좋습니다.
- vLLM, CUDA, PyTorch, GPU 아키텍처, 체크포인트 양자화 방식, 모델 shape을 기록합니다.
- 프롬프트 길이, 출력 길이, 동시성, 반복 횟수를 동일하게 유지합니다.
- 기존 백엔드와 Humming을 비교하되, 동일한 서빙 명령에 해당 백엔드 플래그만 추가합니다.
- 초당 출력 토큰 수, TTFT, 토큰 간 지연 시간, GPU 메모리, 시작 및 JIT 워밍업 시간을 측정합니다.
- 커널 캐시가 예열된 뒤 다시 측정하고, batch 1과 실제 운영 동시성도 별도로 테스트합니다.
- 지원되지 않는 shape이나 선택 실패에 대비해 자동 또는 수동 폴백을 유지합니다.
처리량이 높아졌다는 사실만으로는 충분하지 않습니다. TTFT, 테일 레이턴시, 워밍업 비용, 메모리 사용량이 악화된다면 전체 서비스 성능은 오히려 나빠질 수 있습니다. vLLM의 perf-eval 프로젝트는 비교 가능한 테스트를 위해 YAML 레시피, 반복 실행, 중앙값 집계, 고정된 입력·출력 길이를 권장합니다(perf-eval 저장소).
백엔드 라우팅이 정상적인 Humming 설정을 막을 수 있다
별도의 vLLM 이슈는 폴백 테스트가 필요한 이유를 잘 보여줍니다. 이슈 #60700에서는 intermediate dimension이 640인 compressed-tensors W4A8 MoE 체크포인트를 다뤘습니다. CUTLASS는 256 단위로 정렬된 차원을 요구했지만, Humming은 테스트한 shape을 처리할 수 있었습니다. 문제는 선택된 백엔드가 로드되기 전에 무조건적인 assertion이 실행됐다는 점입니다. 그 결과 --moe-backend humming을 명시해도 실행에 실패했습니다.
제보자가 제안한 패치는 해당 assertion의 적용 범위를 CUTLASS로 제한했습니다. 수정 후 H100 NVL GPU 두 장에서 62개 샤드가 모두 로드됐고, 기준 CUTLASS 구성과 비교해 TTFT는 12%–50% 낮아졌으며 시스템 처리량은 2%–13% 높아졌습니다(이슈 #60700). 확인 당시 이슈는 여전히 열려 있었고, 라우팅 수정안으로 PR #60711이 제안된 상태였습니다.
따라서 Humming 실행 실패가 항상 커널 문제를 의미하는 것은 아닙니다. 해당 구성을 포기하기 전에 선택된 백엔드, shape 제한, 관련 수정안의 반영 여부를 확인해야 합니다.
운영자를 위한 도입 판단표
| 워크로드 | Humming 판단 | 이유 |
|---|---|---|
| Hopper/GH200에서 고동시성 MoE | 초기에 우선 테스트 | 수정과 튜닝을 거친 독립 서빙 테스트에서 17,634 tok/s를 기록했습니다. |
| 대규모 배치의 DeepSeek 스타일 디코드 | 유력한 후보 | MoE GEMM이 연산 병목에 들어가면 FP8 텐서 코어 실행이 도움이 될 수 있습니다. |
| SM80에서 batch-1 또는 낮은 배치 디코드 | 성능 향상을 전제하지 말 것 | 이슈 #72는 테스트한 INT3 경로에서 실효 대역폭이 34%–43%에 그쳤다고 보고합니다. |
| H100의 group-32 활성값 스케일링 | 제한된 shape 조합으로 벤치마크 | 이슈 #38은 하나의 fused 경로에서 심각한 성능 저하를 보여줍니다. |
| 256 단위로 정렬되지 않은 W4A8 MoE shape | vLLM 버전과 라우팅 수정 여부 확인 | 공유 assertion이 가중치 로드 전에 Humming 실행을 막을 수 있습니다. |
| 소스 코드 수정 여력이 없는 프로덕션 환경 | 대표 워크로드 비교 테스트 후에만 사용 | 일부 독립적인 성능 향상에는 커널 또는 휴리스틱 수정이 필요했습니다. |
FAQ
Humming은 어떤 GPU를 지원하나요?
Humming은 Turing 이후의 NVIDIA GPU를 대상으로 하며, 여러 양자화 경로를 문서화하고 있습니다. 지원된다는 사실이 모든 포맷과 워크로드가 동일하게 최적화됐다는 뜻은 아닙니다. SM80과 특이한 스케일링 구성은 별도로 벤치마크해야 합니다.
Humming을 사용하려면 미리 양자화된 체크포인트가 필요한가요?
Humming은 범용 양자화 도구가 아니라 추론 커널 라이브러리입니다. 앞서 인용한 워크플로는 호환되는 양자화 가중치와 활성값 방식을 사용하는 체크포인트를 전제로 합니다. 서빙하기 전에 vLLM 문서와 저장소에서 모델의 포맷을 확인해야 합니다.
Humming이 모든 vLLM 백엔드보다 빠른가요?
아닙니다. Humming은 일부 양자화 워크로드, 특히 보고된 고동시성 MoE 사례에서 더 빠릅니다. 실제 결과는 아키텍처, 포맷, 차원, 스케일 그룹화 방식, 배치 크기에 따라 달라집니다.
실무적인 결론은 분명합니다. Humming은 조건이 잘 맞는 양자화 vLLM 서비스의 성능을 크게 높일 수 있습니다. 하지만 공개된 결과가 특정 구성에 한정돼 있는 만큼, 짧고 반복 가능한 비교 테스트를 거치는 과정 자체가 도입 절차의 일부입니다.