Laguna S 2.1 INT4とDFlashを組み合わせ、RTX 3090×4枚で200Kコンテキストと最大282.5 token/sを実測

新たに公開されたコミュニティのデプロイレシピでは、PoolsideのLaguna S 2.1 INT4とDFlashによる投機的デコーディングをvLLM 0.25.1に組み込み、各24GBのRTX 3090を4枚使って200Kコンテキストを提供している。作者はモデルが起動できることを確認しただけではなく、190,002-tokenのプロンプトを入力した後も生成を継続させた。同じエンドポイントにおけるピーク時のデコード速度は282.5 token/sで、モデルとドラフトcheckpointを合わせて約85GBのストレージを必要とする。

Laguna S 2.1本体は、総パラメータ数が約118B、tokenごとに約8Bをアクティブ化するMoEコーディングモデルで、256個のルーティング専門家、top-10選択、1個の共有専門家を備える。48層のattentionのうち、36層は512-tokenのsliding windowを採用し、12層はglobal attentionを使用する。BF16の重みは約235GBに達するため、旧世代のコンシューマー向けGPUに実用的な形で搭載するうえでINT4が鍵となる。公式のvLLMレシピでも、量子化した本体には同じ精度のDFlashドラフトモデルを組み合わせるよう求めており、数値形式の違いによってacceptance rateや出力品質が悪化するのを防いでいる。

DFlashは単にモデルを小型化するものではなく、検証のたびに複数の候補tokenを並列に提案し、メインモデルがそれらを一度に確認する仕組みだ。vLLMのドキュメントによると、自然言語で測定した平均accepted lengthは約3.1 tokenで、コードでは通常さらに長くなる。ただしLagunaの実行パスではTriton MoEへ切り替える必要がある。デフォルトのDeepGEMMバックエンドがドラフトモデルの実行パスと互換性を持たないためだ。また、投機的デコーディングを有効にすると、`min_p`や`logit_bias`を任意に追加することはできず、追加した場合はvLLMがリクエストを拒否する。

今回の結果は、大規模なsparseコーディングモデルでも、中古のワークステーションクラスのハードウェアで長いコンテキストを扱えることを示している。ただし、この数値をそのままマルチユーザーサービスのキャパシティへ換算することはできない。ピーク値については、完全な同時実行条件、消費電力、継続的な出力速度の分布が明らかにされていない。コミュニティによるApple Silicon上の量子化テストでも、一部の超低ビット版はメモリに収まる一方、品質テストをほとんど完了できない可能性が示されている。次の段階では、同じマシンでDFlashを使用しない場合のベースライン、プロンプト長ごとのacceptance rate、200K KV cache環境における同時実行性能の低下を比較する必要がある。