vLLM における Flint の Day-0 サポート

vLLM は 0 日目からの Recursive の Flintサポートしています。NVFP4 と BF16 の両チェックポイントが 1 枚の GPU で動作し、単一リクエストのデコードは約 500 tokens/s で、コンテキストが 100K トークンにあっても 1 枚の GB200 上で実行できます。

vLLM は 0 日目からの Recursive の Flintサポートしています。NVFP4 と BF16 の両チェックポイントが 1 枚の GPU で動作し、単一リクエストのデコードは 約 500 tokens/s で、コンテキストが 100K トークンにあっても 1 枚の GB200 上で実行できます。

Flint は 40B パラメータの MoE で、トークンごとに約 2.5B のパラメータのみを活性化します。ほとんどの層にスライディングウィンドウアテンションを採用し、262K トークンのコンテキストに対応します。NVFP4(量子化認識トレーニング済み)と BF16 の 2 つの別個のチェックポイントとして提供されます。

クイックスタート

Day-0 の Docker イメージ vllm/vllm-openai:flint (x86_64 と arm64、CUDA 13.0)には Flint サポートが組み込まれています:

# NVFP4 checkpoint (GGUF): config and tokenizer come from the BF16 repo
docker run --gpus all --ipc=host -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:flint \
  RecursiveSI/flint-nvfp4-gguf \
  --hf-config-path RecursiveSI/flint --tokenizer RecursiveSI/flint \
  --enable-auto-tool-choice --tool-call-parser glm47 \
  --reasoning-parser glm47 --exclude-tools-when-tool-choice-none
 
# BF16 checkpoint
docker run --gpus all --ipc=host -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:flint \
  RecursiveSI/flint \
  --enable-auto-tool-choice --tool-call-parser glm47 \
  --reasoning-parser glm47 --exclude-tools-when-tool-choice-none

Flint サポートは vLLM にマージされつつあります(#62938)。それを含む vLLM ビルドでは、同じ方法でサーブできます:

# NVFP4 checkpoint (GGUF): config and tokenizer come from the BF16 repo
vllm serve RecursiveSI/flint-nvfp4-gguf \
  --hf-config-path RecursiveSI/flint --tokenizer RecursiveSI/flint \
  --enable-auto-tool-choice --tool-call-parser glm47 \
  --reasoning-parser glm47 --exclude-tools-when-tool-choice-none
 
# BF16 checkpoint
vllm serve RecursiveSI/flint \
  --enable-auto-tool-choice --tool-call-parser glm47 \
  --reasoning-parser glm47 --exclude-tools-when-tool-choice-none

モデルアーキテクチャ

Flint は隠れ層サイズ 2048 の 49 層 pre-norm MoE です。特徴的なのは、コンテキスト全体を見る部分がいかに少ないかという点です。

図 1: Flint の層スタックと 2 つのサブレイヤー。金色は標準的な pre-norm MoE との違いを示します。全画面で開く.

大部分はローカルアテンション。 35 層は RoPE 付きの 513 トークンのスライディングウィンドウにアテンションし、残りの 14 層は位置エンコーディングなしでコンテキスト全体にアテンションします。シーケンス全体の KV を保持するのはその 14 層のみで、キャストコストはトークンあたり 28 KiB です。
学習されたアテンションシンク、32 個のクエリヘッドと 4 個の KV ヘッドによる GQA、ヘッドごとの Q/K RMSNorm。
256 個のエキスパート、sigmoid top-6、さらに共有エキスパート。 層 0 と層 1 では代わりに dense MLP を使用します。

NVFP4 チェックポイントは、ブロックが NVIDIA の NVFP4 形式を異なるバイト順で格納した GGUF ファイルです。vLLM はロード時にこれをロスなしで再パックし、Recursive のリファレンス実装と同様に、BF16 の活性化と KV キャッシュで weight-only(W4A16)として実行します。すべての Flint カーネルはリファレンスの丸め位置に従い、GSM8K、GPQA-Diamond、長文コンテキスト MRCR、ツール呼び出しスイートにおいて精度が一致しています。

最適化

vLLM の標準レイヤーから構築した最初の実装は、小バッチサイズで低速でした。1 回のデコードステップで 1,096 個のカーネルが実行され、その多くははるかに大きなバッチ向けにチューニングされたものでした。我々はそれらを Flint 専用カーネルに一度に 1 つずつ置き換え、それぞれをリファレンスと照合して検証しました。

図 2: 各変更後の 1 枚の GB200 におけるモデルフォワードのレイテンシ。100K コンテキストでのバッチ 1 デコードと 8,192 トークンのプレフィルの結果です。チェックポイントを切り替えたり、全シェイプの表を表示したりできます。全画面で開く.

Q/K ノーム、RoPE、KV キャッシュ書き込みの融合 (−8%):3 つのカーネルを 1 つに。
小バッチ用 MoE カーネル (−27%): 選択されたエキスパートの重みのみを読み込むルーターおよびエキスパートのGEMV。プリフィルでの最大の改善もここにある。
小バッチの密GEMV (−25%)、大バッチ用カーネルと同じパック済みNVFP4重みに対して。
Norm と SiLU のカーネル (−10%) 続きます。
Decode attention (−5%)、シンクおよびスライディングウィンドウを備え、CuTe DSLによるものです。
低レイテンシデコードパス (−14%)、以下に示します。

最大8リクエストまでは、低レイテンシ経路が各MoEレイヤーを7つのカーネルとして実行します。Q/Kノルム、RoPE、ルーティングおよびエキスパート結合は、隣接するGEMVカーネルに融合されます。各カーネルはプログラマティック依存起動で起動されるため、前のカーネルがまだ実行中の間に自身の重みをロードします。

図3: 低レイテンシのデコードパスにおける1つのMoEレイヤーの7つのカーネル。

合計で、NVFP4のデコードは4.81ミリ秒から1.78ミリ秒へ(2.7倍)、BF16のデコードは3.53ミリ秒から2.34ミリ秒へ(1.5倍)、8Kトークンのプリフィルは207ミリ秒から145ミリ秒へ(1.4倍)それぞれ短縮されました。1回のフォワードで実行されるカーネル数は1,096から346になりました。エンドツーエンドで提供した場合、100Kコンテキストでのバッチサイズ1のデコードは1トークンあたり2.06ミリ秒(約485トークン/秒)かかり、これはフォワードにLMヘッドとサンプリングを加えた時間です。

使用上の注意

FlintはGLM-4.7スタイルのツール呼び出しと思考ブロックを出力するため、 glm47 パーサー。 --exclude-tools-when-tool-choice-none プロンプトからツール定義を削除するのは tool_choice である "none"、リファレンスと一致しています。
デフォルトのサンプリング設定は温度1.0、top-p 0.95、top-k 20です。推論は次に算入されます max_tokensそのため、難しい問題には少なくとも32Kを確保してください。
Flintカーネルは単一のBlackwell GPU(TP=1、BF16 KVキャッシュ)を対象としており、その他の構成ではvLLMの標準レイヤーにフォールバックします。

原文の出典

vLLM Blog

原文を読む

内容について

原文の公開と権利は出典元に帰属します。

機械翻訳 · 原文をご参照ください