LMSYS, DeepSeek-V4 Day-0 지원에서 H200 266 tok/s 성능을 제시
Original: LMSYS published Day-0 DeepSeek-V4 inference and RL support results View original →
이 트윗이 벤치마크 자랑 이상이었던 이유
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
Related Articles
HN이 이 post를 흥미롭게 본 이유는 Apple Silicon unified memory가 Wasm sandbox와 GPU buffer 사이의 copy boundary를 실제로 줄일 수 있느냐는 구현 질문이었다.
중요한 점은 enterprise OCR failure가 academic PDF benchmark보다 훨씬 먼저 agent를 망가뜨린다는 데 있다. LlamaIndex는 ParseBench가 사람 검증을 거친 약 2,000개 페이지와 16만7천 개가 넘는 규칙으로 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!