DSparkで興味深いのは、speculative decodingを「長くdraftすれば速い」とだけ扱っていない点だ。DeepSeek-AIとPeking Universityの論文は、parallel drafterが長いtoken blockを一度に作れても、acceptされにくいsuffix tokenまでtarget modelに検証させるとbatch容量を浪費すると見る。高並行のservingでは、その無駄がそのままthroughputと体感latencyに響く。

DSparkは二段構えでこの問題を扱う。まずsemi-autoregressive architectureにより、parallel backboneの上に軽量なsequential moduleを加え、block内tokenの依存関係を補う。parallel draftingの速さを残しながら、後半tokenのacceptanceが落ちるsuffix decayを抑える狙いだ。さらにconfidence-scheduled verificationが各位置のprefix survival probabilityとengineごとのthroughput profileを見て、requestごとに検証長を変える。

数字も具体的だ。Qwen3-4B、8B、14Bを対象にしたoffline benchmarkでは、DSparkはEagle3に対してmacro-average accepted lengthを約26.7〜30.9%、DFlashに対して16.3〜18.4%改善したという。DeepSeek-V4のproduction servingでlive user trafficに載せた結果では、MTP-1 baseline比でV4-Flashのper-user generation speedが60〜85%、V4-Proが57〜78%速くなったと説明している。

HNでの関心は、単なる高速化よりもDeepSeekがproduction由来の推論最適化とcheckpointを公開する点に向いた。2022年からあるspeculative decodingと何が違うのか、という問いも出ている。論文上の答えは、semi-autoregressive draftingとload-aware verificationを組み合わせた点にある。

LLM productでは、modelそのものだけでなく周辺のschedulerやverification policyが速度と費用を左右する。DSparkは、target modelを変えなくてもdraft、accept、verifyの設計を変えることで、日常的な応答速度の境界を動かせることを示す事例だ。

#serving

DeepSeek DSpark、LLM推論の詰まりを「検証長」で解く試み