この投稿が単なるbenchmark自慢ではなかった理由

LMSYSは、launch dayにmodelを本当に使える状態へ持っていくタイプのsystems postを出した。アカウントはSGLangとMilesで DeepSeek-V4のDay-0 support を実現したと書き、抽象的な賛辞ではなく処理量の数字を添えた。投稿によれば、1.6T Proでは B200で199 tok/s、284B Flashでは H200で266 tok/s、さらに 900K context でもthroughputが大きく崩れないという。

“199 tok/s on B200… 266 tok/s on H200… throughput stays strong at 900K context.”

LMSYSは話題づくり専門のアカウントではない。model evaluationやserving stackの動きを追う人が定点観測する存在で、リンク先blogも短い宣伝ではなく技術的な分解記事だ。2026年4月25日付のその記事は、DeepSeek-V4向けの Day-0 inference and RL support を説明し、hybrid sparse attention、manifold-constrained hyper-connections、FP4 expert weightsに対応するため何を作ったかを詳しく書いている。加えて 1M-token context window と、HiSparseで 最大3倍のlong-context throughput改善 をうたう。

本当のproductは周辺software stack

benchmarkの見出しは、model launchの難しさを平らにしてしまうことが多い。新しいcheckpointは、inference kernels、cache戦略、expert routing、training stackが揃って初めて意味を持つ。LMSYSの投稿が面白いのは、DeepSeek-V4をmodel artifactではなくdeployment problemとして扱っている点だ。リンク先では、圧縮処理を融合した経路がH200で peak memory bandwidthの最大80% に達し、その段階で素朴なPyTorch pipelineより 10倍超 速いとも述べている。

次に見るべきなのは、ほかのopen-source serving stackが同じ数字を再現できるか、そしてlaunch-day supportが実運用の負荷下でも安定したsupportへ変わるかだ。LMSYSの数値が保たれるなら、DeepSeek-V4の意味はopen weightsだけでなく、それを支えるsoftware ecosystemの立ち上がり速度にもある。出典: LMSYS source tweet · LMSYS technical blog

#lmsys

LMSYS、DeepSeek-V4 Day-0対応でH200 266 tok/sの実測スループットを示した