quantized推論のための高速かつ柔軟なカーネル「Humming」を発表

Ant GroupとvLLMコミュニティは、quantized推論向けの汎用高性能カーネルライブラリ「Humming」をオープンソース化します。Hummingは以下の特徴を提供します：

• 幅広いデバイス対応：Turing以降のNVIDIA GPUアーキテクチャに加え、T-HeadのZhenwu 810EなどCUDA互換デバイスに対応しています。
• 充実したquantization対応：統一アーキテクチャにより、denseおよびMoEワークロード向けの重みと活性化フォーマットの多様な組み合わせをサポートし、幅広い整数型・浮動小数点型、ビット幅、スケーリング方式を網羅しています。
• 高い実行パフォーマンス：多くの代表的なワークロードにおいて、vLLM Marlin、FlashInfer、DeepGEMMの既存実装を大幅に上回る性能を発揮します。

リポジトリ： github.com/vllm-project/humming

背景

モデルと推論ワークロードが成長するにつれ、メモリ容量、メモリ帯域幅、計算コストがデプロイをますます制約するようになっています。これはMoEモデルで特に顕著です。各トークンはエキスパートの一部のみを活性化しますが、重みの全セットを格納しておく必要があります。例えばDeepSeek-V3は6,710億のパラメータを持ち、トークンごとに370億が活性化されます。quantizationは重みと活性化の精度を下げてメモリ使用量とデータ移動を削減し、計算効率の向上にもつながります。

quantizationの要件はモデルやGPUの世代によって異なります。一般的な構成にはWNA16、W8A8、W4A8、W4A4があり、WとAは重みと活性化のビット幅を、Nは可変の重みビット幅を表します。同じ精度でも、INT4とNVFP4のような方式は数値フォーマットやスケーリングが異なります。さらに、スケーリングの粒度、スケールの表現、グループサイズ、対称・非対称quantizationが構成空間をさらに広げています。

こうしたストレージと計算の節約は、効率的なカーネルがあって初めて低レイテンシと高スループットにつながります。Prefill、decode、そしてMoEエキスパートごとの負荷の変動は、計算とメモリに対して異なる要求をもたらします。カーネルはこれらのワークロードに適応しつつ、変換、非quantization化、スケジューリングのオーバーヘッドを低く抑えなければなりません。

すべての組み合わせごとに専用カーネルを開発・統合すると、メンテナンス負担が増大し続けます。追加のたびに、固有の重み前処理、カーネル選択、フレームワークアダプタ、テストが必要になる場合があります。そして最適化を複数の実装に横断して適用しなければなりません。

Hummingは、quantizationの記述を実行の選択から分離し、共有コンポーネントからカーネルを組み立てることで、この問題に対処します。

汎用アーキテクチャ

Hummingの実行パスは3つの部分から構成されます：quantized計算の表現、ハードウェアとワークロードに対する構成の選択、そしてCUDAコンポーネントからのカーネルのコンパイルです。

統一されたquantization表現

異なるquantizationツールがエクスポートしたモデルは、数値フォーマット、パラメータの構成、重みレイアウトが異なります。Hummingはサポートされたエクスポート形式をHumming標準フォーマット、すなわち重み、スケール、ゼロ点などのテンソルが一貫して整理された共通のquantization記述に変換します。

この表現は、各方式のquantizationセマンティクスを保持しながら、重みフォーマット、スケーリング粒度、スケールのデータ型、ゼロ点、二次スケールを個別のパラメータとして記述します。活性化には独自の数値フォーマットとquantization設定があります。これらのパラメータは、フォーマットおよびハードウェアの制約に従って組み合わせることができます。

例えば、グループ単位のINT4重みをBF16活性化と組み合わせることができます。異なるスケーリング方式を持つ低精度浮動小数点の重みも、同じパラメータ体系を使用します。これにより、推論フレームワークは異なるソースのモデルに対して共通のインターフェースを得られます。

ワークロードごとのチューニングとJITコンパイル

標準フォーマットは、エクスポート形式に共通の表現を提供します。その後、前処理がパラメータを検証し、次元をパディングし、これらのテンソルをターゲットカーネルに適したレイアウトに再パックします。Hummingはquantization記述を重みの形状、GEMMタイプ、ターゲットGPU、計算オプションと組み合わせて実行を構成します。

カーネルは3つの構成によって記述されます：

• Layer Config はテンソルの形状、データ型、quantizationパラメータ、ターゲットアーキテクチャを記述します。
• Compute Config はGEMMタイプと、バッチ不変性や入力スケールレイアウトなどの計算オプションを指定します。
• Tuning Config タイル形状、パイプラインステージ数、ワープスペシャライゼーション、メモリアクセス、およびMMA命令を選択します。また、並行性とスケジューリングも制御し、TMAはテンソルごとに設定できます。

デフォルトでは、Hummingはデバイス固有のヒューリスティックを用いてチューニング設定を選択します。入力サイズの範囲ごとに異なる設定を準備し、実行時に適切なカーネルへディスパッチすることができます。

Hummingの統一アーキテクチャにより、実行パラメータのチューニングや、異なるワークロードに対するパイプラインの選択が容易になります。小さなバッチサイズでは、非同期コピー（cp.async）とMMAを用いたマルチステージパイプラインが、TMAとUMMAを中心に構築されたパイプラインを上回る性能を示すことがあります。大きなバッチサイズでは、TMAとUMMAがより高いスループットを提供できます。Hummingは両方の実行パスを同一の設定・コンポーネントフレームワーク内で扱うことができ、ワークロードごとにより効果的な戦略を選択できます。

これら3つの設定が連携して、NVRTCまたはNVCCでコンパイルされた特殊化されたカーネルを生成します。コンパイルされたカーネルは再利用のためにキャッシュされます。推論では、選択されたカーネルを前処理済みの重みと実行時の活性化テンソルと組み合わせます。

フォーマットとアーキテクチャを横断して共有されるCUDAコンポーネント

CUDAレベルにおいて、Hummingはタスクスケジューリング、データ移動、非量子化とスケーリング、Tensor Core計算、出力処理を再利用可能なコンポーネントとして整理しています。標準、ワープ特殊化、専用UMMAの各パイプラインを提供します。これらのパイプラインは互換性のあるコンポーネントを共有しつつ、各実行戦略に必要なデータフローと同期を用います。

各コンポーネント群は異なる変動要因を扱います:

• 数値処理は量子化フォーマットを扱います。 デコードおよび算術コンポーネントは、ビット幅、整数または浮動小数点表現、スケール、ゼロポイントに対応します。非量子化とスケーリングはカーネルの計算に統合されています。
• メモリおよび計算バックエンドはGPUアーキテクチャを扱います。 Hummingは対象アーキテクチャに応じたデータ移動とTensor Coreの実装を選択し、サポートされている場合は非同期コピーやTMA、マルチキャストを利用します。
• タスクマッピングとスケジューリングはdenseおよびMoEワークロードを扱います。 各GEMMタイプは適切なスケジューリングロジックを使用します。スケーリングとバイアス加算も出力ステージに融合できます。

JITコンパイルはこれらのコンポーネントを3つの構成に従って組み合わせ、未使用の実装分岐を排除します。そのため、新しいフォーマットやアーキテクチャは、関連するコンポーネントを拡張することでサポートできます。共有コンポーネントの改善は互換性のある構成すべてに恩恵をもたらし、個別の特殊化カーネルの重複した開発と保守を削減します。

このCUDA実装は軽量であり、重量級のカーネルフレームワーク依存を回避しているため、JITコンパイルも高速に保たれています。CUDA 13.4を搭載したH200サーバーでの単一のW4A16カーネルコンパイルテストでは、コンパイル時間は NVCCを使用するCUTLASSでは23.35秒 から NVCCを使用するHummingでは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を完全にサポートしており、共有カーネルとチューニング機能をより多くのハードウェアプラットフォームにもたらしています。

下の図は、各デバイスでHummingがサポートする高性能な活性化タイプを示しています。これはデバイスのピーク計算能力を最大限に活用できるタイプです。図から省略された一部のタイプも、他の命令パスを通じて実行できます。たとえば、B300（SM103）のUMMA命令はもはやINT8計算をサポートしていませんが、以前のMMA命令は依然としてINT8 GEMMを実行できます。ただし、性能は大幅に低下します。

量子化サポート

Humming の量子化タイプのサポートは、主に活性化(activation)と重み(weight)のタイプ間の互換性に依存します。統一された量子化表現とカーネルアーキテクチャにより、幅広い整数型および浮動小数点型の重みフォーマットが、異なる精度の活性化と組み合わせて動作可能であり、モデルの精度とデプロイ時のパフォーマンスについて柔軟な選択肢を提供します。

下の図は、Humming がサポートする重みと活性化のタイプの組み合わせを示しています。行は重みのタイプ、列は活性化のタイプを表し、チェックマークはサポートされている組み合わせを示します。上記のデバイスサポートマトリックスと合わせて、各ハードウェアアーキテクチャで利用可能な高性能な量子化計算パスを概説しています。

Hummingは、指数ビットがゼロの特殊な浮動小数点フォーマットにも対応しており、その表現可能な値は同じビット幅の対称整数と一致します。例えば、INT8から -128 と float8e0m7 を除いたものは、いずれも -127 から 127までの整数を表します。このフォーマットの重みは、同じビット幅のINT重みと同じアクティベーション型の互換性を持ちます。Hummingは、対象となる対称整数の重みを、より高速な逆量子化のためにこのフォーマットへ自動的に変換します。

コミュニティはさらに、Blackwell Tensor Coresに隠された 2つの隠し機能を発見しました。それはPTXの型システムでは公開されていない2つの特殊な浮動小数点フォーマット、 float4e0m3 と float8e3m4のネイティブサポートです。Hummingは、データセンター向けSM100/SM103や、ワークステーション・パーソナルコンピューティング向けSM120/SM121を含むすべてのBlackwellアーキテクチャでこれらの機能をサポートします。両フォーマットは統合された量子化・計算フレームワークに組み込まれており、低精度推論のためのより多くのネイティブ計算オプションを提供します。Rubinはこれら2つの隠されたTensor Coreフォーマットをサポートしないため、これらのネイティブ計算パスのサポートはRubinには拡張されません。

パフォーマンス

以下のカーネルマイクロベンチマークは、vLLMコミュニティが実施したもので、Mを1から8192までのすべての2のべき乗としてGEMM性能を測定しています。カーネルは十分にウォームアップされ、コールドなL2キャッシュでサンプル間に短い間隔を置いて個別に計時されています。MoEの速度向上はGateupとDownのGEMMレイテンシの合計を使用しています。各図には、ベースライン、量子化フォーマット、行列の次元、ソフトウェアのバージョンが示されています。

WnA16

WnA16は、量子化推論において最も汎用性が高く広く使われている手法の1つです。低ビットの重みをFP16/BF16のアクティベーションと組み合わせることで、重みのストレージとメモリトラフィックを削減しつつ、広く利用可能な16ビット計算能力を活用します。これにより、多くのGPU世代やモデルのデプロイシナリオに適したものとなっています。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でのW8A8の結果を示しています。小・中バッチサイズにおいて、HummingはDeepGEMM Contiguousのそれぞれ約2.6倍および2.5倍の性能に達し、IndexedとGroupedの両レイアウトで競争力のある性能を示しています。

より多くのモデルがネイティブのMXFP4重み量子化を採用するにつれ、より小さい重みフットプリントを実際の推論の向上に変えることがますます重要になっています。Hummingは、MXFP4重みをロード時に高速に逆量子化し、計算にはFP8 Tensor Coresを使用する効率的なW4A8パスによってこれに対応し、Hopper上での効率的なW4A8-MXFP4実行を可能にします。上の右列はDeepGEMM W8A8をベースラインとしています。小・中バッチサイズにおいて、HummingのW4A8はH20で約4.2倍、H200で4.5倍のベースライン性能に達し、同じ図内のHummingのW8A8の結果も大幅に上回っています。重みトラフィックの削減はGEMMレイテンシの低下につながります。FlashInfer CUTLASS W4A8もHummingのアプローチに基づく実装ですが、ここに示すベンチマークではHummingの現在の実装がより良い性能を達成しています。

Blackwellは、MXFP8やMXFP4といったマイクロスケーリングフォーマットのネイティブなTensor Coreサポートを追加しました。データセンター向けSM100/SM103デバイスから、ワークステーション・パーソナルコンピューティング向けSM120/SM121デバイスまで、Hummingは各アーキテクチャの低精度計算能力を活用し、1つのカーネルおよびチューニングフレームワーク内でW8A8、W4A8、W4A4をサポートします。

B300（SM103）において、Humming は 3 つの MX フォーマットのすべての組み合わせで大幅な性能向上を示します。以下の各パネルは、対応する精度の 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%.

使い方

インストール

pip で Humming をインストールします：

pip install humming-kernels

Humming は CUDA コンパイラを使用して、必要に応じてカーネルを生成します。システムに CUDA コンパイラが利用できない場合は、環境の CUDA メジャーバージョンに対応するコンパイル依存関係を含めるため、以下のインストールオプションのいずれかを選択してください：

pip install "humming-kernels[cu12]"  # CUDA 12
pip install "humming-kernels[cu13]"  # CUDA 13

Humming 自体は非常に軽量で、依存関係はシンプルであり、ホイールパッケージはわずか約 500 KB です。オンデマンドコンパイルにより、大量のプリコンパイル済みカーネルを同梱する必要がありません。原理的には、PyTorch 2.7 を実行できる環境であれば Humming も実行できるため、既存の推論環境への統合が容易です。

vLLM での Humming の使用

HummingはvLLMに深く統合されています。vLLM 0.29.0以降、CUDAインストールにはHummingが依存関係として含まれているため、別途Hummingをインストールする必要はありません。Hummingは、Turing以降（SM75以上）のすべてのアーキテクチャのNVIDIA GPUをサポートしています。

The --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 オプションは、GPTQ INT3 のように 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 は既存のヒューリスティクスを補完し、手動の設定探索を削減し、より多くのワークロードがカーネルの到達可能な最高性能に近づけるよう支援します。

推論フレームワークとのより深い統合

Humming は vLLM などの推論フレームワークとの統合を深め続け、量子化モデルのロード、バックエンド選択、並列推論、ランタイムスケジューリング、デバイス適応にわたるサポートを拡大します。私たちは、より多くの量子化手法が、エキスパート並列(EP)向けの量子化 All-to-All(A2A)通信などの最適化を含む、フレームワークの全機能と連携して動作するようにすることを目指しています。これらの取り組みにより、高性能な量子化カーネルが多様なデプロイメントシナリオでより使いやすくなり、カーネルの性能向上をエンドツーエンドの推論の利益へと転換できるようになります。

謝辞

Humming の開発を通じての貢献とサポートに感謝し、Ant Group の Jinzhen Lin、Zekai Gu、Zhilin Huang の皆様、ならびに vLLM コミュニティの Michael Goin、Roberto L. Castro、Chauncey Jiang、その他のメンバーの皆様に感謝いたします。

また、幅広いハードウェアとワークロードにわたって Humming を検証・改善することを可能にした開発、テスト、CI リソースを提供してくださった vLLM コミュニティにも感謝いたします。

Humming の設計と最適化は、Marlin、vLLM Marlin、LMDeploy、DeepGEMM、FlashInfer、CUTLASS、その他のオープンソースプロジェクトから着想を得ています。そのアイデアと実装を共有し、コミュニティ全体の高性能量子化推論の発展に貢献してくださった作者とコントリビューターの皆様に感謝いたします.