推論系統
Ling-3.0-flash INT4、単一マシンで実測38.7 token/s――メインラインvLLMの誤用で誤った出力が気付かれず生成される可能性
コミュニティのデプロイ手順では、単一のDGX Spark上でCUDA Graphと1層のMTP投機的デコーディングを有効にし、Ling-3.0-flash INT4の生成速度を20.8 token/sから38.7 token/sへ引き上げた。さらに重要なのは、メインラインのvLLMがV3アーキテクチャをまだサポートしておらず、古いattentionパスを無理に適用すると、エラーが報告されないまま、一見流暢だが誤った内容が出力される可能性があるという点だ。
新たに公開されたデプロイ手順によると、総パラメータ数124B、tokenごとに約5.1Bパラメータを有効化するLing-3.0-flash INT4は、128GBの統合メモリを搭載した単一のNVIDIA DGX Sparkに収容できる。テストは同一マシン、同一プロンプト、単一ストリーム、1回につき512 tokenを生成する条件で実施され、ウォームアップを除外した3回の平均値を採用した。eager modeをそのまま使用し、MTPを無効にした場合は20.8 token/sだったが、`--enforce-eager`を外して投機tokenを1個有効にすると38.7 token/sまで向上した。比較対象として、コミュニティによるQ5_K_M GGUFパスでは35.2 token/sを記録した。
速度差の主因は量子化形式ではなく、実行スケジューリングにある。Lingは各ステップで少数のexpertしか有効化しないため、GPU kernel launchの固定コストがより顕著になる。CUDA Graphはキャプチャ済みの実行グラフをリプレイできるため、tokenごとの起動オーバーヘッドを削減できる。checkpointにはさらに1層のmulti-token prediction用draft layerが含まれており、サーバー側は`bailing_hybrid_v3_mtp`を使って次のtokenを先に予測し、その後メインモデルで検証する。
速度の数値以上に注目すべきなのが、デプロイ上のリスクだ。メインラインのvLLMには現時点で`BailingMoeV3ForCausalLM`が存在しない。V3の重みを旧V2.5クラスに無理に渡すと、KDAの重みが本来とは異なるattention計算パスへ送られる可能性がある。サービス自体は起動でき、出力も文法的に自然な場合があるため、一般的なヘルスチェックでは数値的・意味的な誤りを検出しにくい。このデプロイ手順では、inclusionAIの`vllm-ling-v3`専用ブランチを使用するよう求めている。
ただし、これは単一の作者が単一のマシンで実施した小規模なテストにすぎず、検証済みのcontext lengthも16Kまでとなっている。また、コールドスタート時に24個のshardをロードする際、約50%の確率で処理が停止する問題があり、現時点ではwatchdogによる再試行で対処している。エンジニアリングチームは、まず既知の正解を用いたテストとtool callingの回帰テストを追加したうえで、throughput、time to first token、long-context品質を比較すべきだ。メインラインvLLMによる正式サポートと、GB10専用MoE kernelのチューニングも待つ必要がある。