2026年8月21日、RadixArk SGLangチームとAnt Ling InfraチームはLMSYS公式ブログでLing-3.0-flashの単一リクエスト復号最適化結果を発表しました。 4台のNVIDIA Blackwell GPU、TP4、bf16、並行処理が1に設定された固定環境下では、最適化されたNEXTNパスにより平均出力スループットが288 tok/sから606 tok/sに向上し、平均出力トークン時間が3.33ミリ秒から1.53ミリ秒に短縮されました。
なぜバッチ1は最適化が難しいのでしょうか?
この結果は、連続して1つのリクエストのみがデコードされる低並行性のシナリオに当てはまります。 起動やスケジューリングのオーバーヘッドを分担するための大規模な要求がなければ、CPUとGPU間の同期やカーネルの小さな起動遅延はユーザーの待ち時間を直接反映し、高スループットのバッチ処理よりもシステムオーバーヘッドを隠すのが難しいのです。
パフォーマンスは単に1コアで倍増するだけではありません
チームはまず、ホストを各ステップでフリーズさせるCPUシーケンス長同期を廃止し、ホスト準備とGPU実行を重ねることを可能にしました。 次に、プログラム依存開始を用いてMoE、ルーティング、KDA、トータルリダリングパスを接続し、小さなコア間のギャップを減らします。 残りの最適化には、オペレーターフュージョン、KDA再キャリブレーション、ルーティングゲートおよび出力ヘッド計算をfp32からbf16に調整することも含まれます。
これらの変化は総じて重要な経路を短縮しました。 公式説明によると、BF16ルーターのゲートと出力ヘッドが構造調整後の最大の変更点であり、約10%の改善をもたらしています。 チームは短期的なピークだけに焦点を当てるのではなく、トークンごとの平均時間と受け入れ期間を用いて安定性を評価しました。
DSparkは最適化の中に「より多くのトークンを推測する」ことも含まれていました
同じ報告書では、DSparkの信頼度スケジューリングによる推測的復号もテストしました。 同じマシン、同じコマンド、1000件のリクエストを制御された比較で、DSparkは平均1120 tok/s、0.78ms TPOT、平均受理時間9.95を達成しました。 その利点は、単一ステップで高速化するだけでなく、検証ごとにより多くの予測トークンを提出できることにあります。
しかし、1120 tok/sはすべての作業の普遍速度とは直接考えられません。 テストでは固定された8192トークン入力、1024トークン出力、グリーディデコード、合成ランダムロードが用いられます。 チップの内容、出力分布、コンテキストの長さ、サンプリング設定、ハードウェアはすべて投機的トークンの受理率に影響を与えます。 公式の声明では、9.95はモデルの固有の定数ではなく、この負荷下の結果として明確に扱われています。
展開チームにとっては何を意味するのでしょうか?
この最適化はモデルのパラメータや回答の質を変えませんでした。変わったのは推論システムがホスト作業、GPUカーネル、ドラフト検証の配置方法でした。 低並行遅延はスケジューリング、通信、数値精度、推測戦略にまたがることが多く、グラフィックスカードの計算能力だけで真の速度を説明するのは困難です。
再現実験では、ハードウェア、SGLangのバージョン、入出力長、復号パラメータをロックし、その後TPOT、スループット、正確性を比較する必要があります。 実験的な数値を異なるGPUやビジネストラフィックに直接適用すると、過度に楽観的な容量推定が生まれやすいです。
