LMSYS、DeepSeek-V4 Day-0対応でH200 266 tok/sの実測スループットを示した
Original: LMSYS published Day-0 DeepSeek-V4 inference and RL support results View original →
この投稿が単なる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
Related Articles
HNがこのpostを面白がった理由は、Apple Silicon unified memoryでWasm sandboxとGPU bufferが本当に同じbytesを扱えるのかという実装上の境界だった。
重要なのは、enterprise OCRの失敗がacademic PDF benchmarkより早くagentを壊すことだ。LlamaIndexはParseBenchがhuman-verifiedの約2,000ページと16.7万超のrulesで14手法をKaggle上で比較すると述べた。
重要なのは、open model陣営で長いcontextと実運用向けの二層構成が同時に出てくる例がまだ少ないことだ。DeepSeekは1M context、1.6T・49B Pro、284B・13B Flashという数字を一度に示した。
Comments (0)
No comments yet. Be the first to comment!