記事一覧へ戻る
推論・デプロイ

vLLM、TML InklingをDay-0対応:1Tマルチモーダルモデルの推論最適化を前面に

読了目安 3 分

導入

vLLMは公式ブログで、TML InklingへのDay-0対応を発表した。TML InklingはThinking Machines Labが訓練した1Tパラメータ級のマルチモーダルモデルで、テキスト、画像、音声を入力として受け取り、テキストを生成する。今回の発表は単なるモデル追加ではなく、長文コンテキスト、MoE、相対注意、short convolution、MTP推測デコードを含む複雑な構成を推論基盤に取り込んだ点が重要だ。

対応対象は thinkingmachines/Inkling-NVFP4 とBF16版の thinkingmachines/Inkling。vLLMによれば、現時点ではNVIDIA BlackwellおよびHopper GPUに対応し、より広いハードウェア対応は進行中だという。

主要ポイント

  • ネイティブなマルチモーダル入力:Inklingはテキスト、画像、音声を入力し、decoder-only Transformerのバックボーンで処理する。
  • 最大1M tokensのコンテキスト:66層のうち11層がfull attention、55層がsliding-window attentionであり、長大な文脈処理の効率化に寄与している。
  • RoPEではなく相対注意:位置表現にはRoPEではなく、attention logitsに学習された相対位置項を加える方式を採用している。
  • short convolutionの多用:各層でwindow size 4のshort convolutionをkey、value、attention output、MoE outputに適用する。vLLMはこのsconv cacheを仮想的なsliding-window attentionのKV cacheとして扱い、統一的なキャッシュ管理とprefix cachingを可能にした。
  • MoEとexpert sink:各層は256個のルーティング専門家とtop-6選択、さらに2個の共有専門家を持つ。共有専門家はルーティングスコア計算には関与するが、top-6候補からは除外される。
  • MTPによる高速化:Inklingは8個のMTP headsを備え、1回のforwardで最大9 tokensを生成できる構成を持つ。vLLMはdraft tokenが拒否された場合のKV cacheの不整合にも対処している。

性能と検証

vLLMは、4基のNVIDIA GB200 GPU上でMTP8を有効にした場合、最大380 tokens/s/user、平均acceptance length 4.5を達成したとしている。MTPを使わない場合の数値は140 tokens/s/user。測定はSPEED-Benchから抽出した8K入力プロンプトを用い、各リクエストで1K tokensを生成する条件で行われた。

正確性については、音声のMMAU、視覚のMMMU-Pro、ツール呼び出しのBFCL、推論のHLE、長文コンテキストのNIAHで検証したとされる。長文では221K tokensまで参照実装と完全一致し、513K tokensまでおよそ1ポイント以内に収まった一方、800Kを超えるような極端な長さでは実行間のばらつきが大きくなるという。

意義と影響

今回の統合は、推論フレームワークに求められる役割が広がっていることを示している。大規模モデルを動かすだけでなく、モデル固有の注意機構、キャッシュ、通信、並列化、量子化、推測デコードまで含めて最適化する必要がある。

開発者にとっては、LoRA、TP/DP/EP/PP、prefix caching、disaggregated servingといった機能を保ちながら、複雑な1T級モデルを扱える点が実用的な価値となる。モデル開発側にとっても、Day-0対応はモデル公開と推論エコシステムの連携がより密になっていることを示す動きだ。

出典:vLLM Blog

コメント

ログイン状態を確認中…

コメントを読み込み中…

関連記事

CCTest · Blog
モデルルーティングは単なる「モデル選択」ではない:IBM Research が示す企業向け Agent の現実
推論・デプロイ
cctest.ai
推論・デプロイ

モデルルーティングは単なる「モデル選択」ではない:IBM Research が示す企業向け Agent の現実

IBM Research は、Agent システムにおけるモデルルーティングを分類問題として扱うだけでは不十分だと指摘する。実運用では、コスト、品質、遅延、キャッシュ、インフラ、ガバナンスを同時に考える必要がある。

続きを読む
CCTest · Blog
モデル最適化を経験則から制約駆動の設計判断へ
推論・デプロイ
cctest.ai
推論・デプロイ

モデル最適化を経験則から制約駆動の設計判断へ

この arXiv 論文は、モデル圧縮と推論高速化を単なる手法選択ではなく、運用制約に基づく多目的なエンジニアリング判断として捉え直している。鍵となるのはデータ、遅延、メモリ、精度、再学習予算の五つの軸だ。

続きを読む