이 트윗이 벤치마크 자랑 이상이었던 이유

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에서도 처리량이 크게 무너지지 않는다고 주장한다.

“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와 RL support를 설명하고, hybrid sparse attention, manifold-constrained hyper-connections, FP4 expert weights에 맞춰 무엇을 새로 만들어야 했는지 풀어 쓴다. 또한 1M-token context window와 HiSparse 기반 최대 3배 long-context throughput 개선도 언급한다.

실제 제품은 model이 아니라 주변 소프트웨어다

벤치마크 headline은 종종 진짜 어려운 부분을 지운다. 새 checkpoint가 의미를 가지려면 inference kernel, cache 전략, expert routing, training stack이 따라와야 한다. LMSYS 글이 흥미로운 이유는 DeepSeek-V4를 model artifact가 아니라 deployment 문제로 다루기 때문이다. 연결된 글은 압축 경로를 합친 구현이 H200에서 메모리 대역폭의 최대 80%에 도달하고, 해당 단계에서 순진한 PyTorch pipeline보다 10배 이상 빠르다고도 적는다.

다음 관전점은 다른 open-source serving stack이 이 숫자를 재현하는지, 그리고 launch-day support가 실제 사용자 트래픽이 들어온 뒤에도 안정적 support로 이어지는지다. LMSYS 수치가 유지된다면 DeepSeek-V4의 의미는 open weights 자체뿐 아니라, 주변 소프트웨어 생태계가 얼마나 빨리 따라붙었는지에도 있다. 출처: LMSYS source tweet · LMSYS technical blog

#lmsys

LMSYS, DeepSeek-V4 Day-0 지원에서 H200 266 tok/s 성능을 제시