DeepInfer 벤치마크 읽기: V4.1-Flash 성능

DeepInfer의 V4.1-Flash 벤치마크는 인용하기는 쉽고 해석하기는 어렵습니다. 초당 토큰 수는 엔진의 속성이 아닙니다. 엔진, 모델, 배치, 컨텍스트 길이, 하드웨어 구성, 워크로드가 함께 만드는 속성입니다. 차트는 한 번의 여정을 그린 지도이지, 여러분의 여정에 대한 보장이 아닙니다.

단위의 함정

서빙 논의에는 서로 다른 세 가지 속도가 등장하며, 서로 바꿔 쓸 수 없습니다.

한 시스템이 높은 tokens/s/GPU와 낮은 tokens/s/user를 동시에 가질 수 있습니다. 디코드 차트가 보여 주는 것이 바로 그것입니다. 동시성이 높아지면 전체 처리량은 오르지만 사용자별 스트림은 느려집니다. 어느 숫자도 엔진의 “속도” 그 자체가 아닙니다.

엔드투엔드 지연에는 네트워크, 큐잉, 토큰화, 스케줄링, API 오버헤드가 더해집니다. 어느 것도 두 차트에 없습니다. 디코드 100 ms/step은 첫 토큰까지 100 ms라는 뜻이 아니고, 325 tokens/s/user는 응답이 325 ms라는 뜻이 아닙니다.

프리필: 배치가 처리량을 사고, 지연이 그 값을 치른다

프리필은 프롬프트를 처리하고 KV cache를 만듭니다. 배치가 커지면 가중치 읽기를 분산 상각하고 GPU 활용률이 올라가 처리량이 증가합니다. 하지만 스텝마다 시간이 더 걸리므로 지연도 함께 늘어납니다.

DeepInfer의 프리필 차트는 131,072 토큰 컨텍스트에서 SM100 GPU 4개를 사용합니다. 라벨은 4,096에서 65,536까지의 배치 크기입니다. 곡선은 처음에 가파르게 오르다가 평평해집니다.

• 배치당 4,096 토큰에서 처리량은 약 60k tokens/s/GPU이고 각 스텝은 약 68 ms 걸립니다.
• 16,384에서는 처리량이 약 81k, 각 스텝은 약 200 ms입니다.
• 65,536에서는 처리량이 약 89k, 각 스텝은 약 730 ms입니다.

정점보다 꺾이는 지점이 더 중요합니다. SLO가 빡빡하다면 곡선의 왼쪽에 머물고 처리량으로 그 비용을 치르게 됩니다. 오프라인 배치 평가를 돌린다면 오른쪽에 머물며 긴 스텝을 받아들일 수 있습니다. 어느 쪽이 맞는지는 차트가 아니라 여러분의 워크로드가 알려 줍니다.

프리필 차트가 무엇을 측정하는지도 보세요. 비캐시 입력 처리량입니다. 프롬프트 대부분이 캐시 적중이라면 프리필 작업량은 훨씬 작아지고, 이 곡선은 병목이 아닙니다. 캐시 적중률은 별개의 변수이며, 빠진 KV cache 시스템이 최대화하려는 대상이 바로 이 변수입니다.

디코드: 동시성이 처리량을 사고, 상호작용성이 그 값을 치른다

디코드는 스텝마다 요청당 토큰 하나를 생성합니다. 동시 요청이 많아지면 GPU가 스텝마다 더 많은 유효 작업을 하므로 전체 처리량이 올라갑니다. 하지만 요청마다 토큰 사이 대기가 길어져 사용자당 속도는 떨어집니다.

DeepInfer의 디코드 차트는 131,072 토큰 컨텍스트에서 SM100 GPU 64개를 사용하며, nextn=3 fixed와 토큰당 드래프트 수용률 75%를 적용합니다. 라벨은 DP 랭크당 요청 수입니다.

• 랭크당 8 요청에서 전체 처리량은 약 2.6k tokens/s/GPU이고 사용자 한 명은 약 325 tokens/s를 봅니다.
• 랭크당 64 요청에서 처리량은 약 15.5k, 사용자 한 명은 약 248 tokens/s입니다.
• 랭크당 256 요청에서 처리량은 약 26k, 사용자 한 명은 약 103 tokens/s입니다.

형태는 전형적인 서빙 맞교환입니다. 채팅 제품은 왼쪽을 고를 수 있고, 배치 요약이나 오프라인 에이전트 워크로드는 오른쪽을 고를 수 있습니다. 차트가 유용한 이유는 단일 지점이 아니라 전체 프런티어를 보여 주기 때문입니다.

예제 README는 디코드 처리량 숫자의 계산식을 제시합니다.

decode throughput = avg_SPS × decode_num_requests × (1 + nextn) / cp

이것은 “전량 수용 회계”입니다. 실제 수용률과 무관하게 모든 드래프트 토큰이 수용된다고 가정합니다. 차트는 그 결과에 0.75 수용률 가정을 곱합니다. 예측하기 어려운 텍스트라면 실제 값은 더 낮습니다. 쉬운 텍스트라면 더 높을 수 있습니다.

75% 가정

추측 디코딩은 드래프트 토큰을 제안하고 배치로 검증합니다. 이득은 수용되는 드래프트 수에 달려 있습니다. 디코드 차트는 토큰당 수용률 75%를 가정하며, 이는 스텝당 평균 수용 길이 약 3.25토큰에 해당합니다.

이 가정은 예측 가능한 텍스트에서는 그럴듯하지만, 개방형 추론, 낯선 식별자가 많은 코드, 고도로 기술적인 글에서는 덜 그럴듯합니다. DeepSeek의 프로덕션 데이터에서도 DSpark 구성의 수용 길이는 3.2–3.3 수준이므로 차트의 가정이 임의로 만들어진 것은 아닙니다. 그래도 가정일 뿐, 여러분의 워크로드 속성은 아닙니다.

관련된 DSpark 최적화인 가변 길이 검증도 부하에 따라 달라집니다. DeepSeek는 프로덕션 지점에서 처리량 +4–7%를 보고하지만, 동시성이 낮을 때는 약간의 손실이 납니다. “추측 디코딩은 공짜”라는 사고방식이 왜 틀렸는지 보여 주는 좋은 예입니다. 이득은 수용률과, 검증에 얼마나 여유 용량을 쓸 수 있는지에 달려 있습니다.

평가 수치가 측정하는 것

평가 스크립트는 서빙 벤치마크가 아닙니다. 세 가지 오프라인 과제에서 모델 품질을 측정합니다.

• AIME 2026: 과제 30개, 각 32 샘플, Pass@1 99.9%.
• GPQA Diamond: 과제 198개, 각 8 샘플, Pass@1 93.4%.
• HLE-Full: 과제 2,500개(텍스트 2,158, 이미지 342), 각 1 샘플, Pass@1 42.6%.

Pass@1은 샘플 하나가 정답일 확률입니다. 과제당 32 샘플인 AIME의 99.9%는 960회 롤아웃의 평균이고, HLE의 단일 샘플은 훨씬 노이즈가 큽니다. 평가 README는 반복 실행 시 값이 달라질 수 있고, Pass@1 값은 coverage_complete가 true일 때만 유효하다고 경고합니다.

이 숫자들은 기본 구성에서 모델이 이 벤치마크들에서 유능하다는 것을 알려 줍니다. 다른 엔진보다 빠르거나 저렴하거나 안정적이라는 것은 알려 주지 않습니다. 그것을 알려면 같은 하드웨어, 컨텍스트, 워크로드로 수행한 서빙 벤치마크가 필요하고, 이상적으로는 제3자가 실행해야 합니다.

판독 체크리스트

추론 벤치마크를 보면 이렇게 물으세요.

1. 단위가 무엇인가? tokens/s/GPU인가, tokens/s/user인가, ms/step인가?
2. 워크로드는 무엇인가? 컨텍스트 길이, 입력/출력 비율, 캐시 적중률, 요청 도착 패턴.
3. 하드웨어는 무엇인가? GPU/NPU 모델, 수량, 인터커넥트, 메모리, 단일 노드인지 클러스터인지.
4. 배치와 동시성은 얼마인가? 높은 동시성에서의 처리량 정점은 지연 시간에 민감한 제품에는 무관할 수 있습니다.
5. 무엇이 포함되었나? 엔진만인가, 아니면 KV cache, 라우팅, API 오버헤드까지 포함한 전체 서빙 스택인가?
6. 무엇을 가정했나? 드래프트 수용률, 캐시 적중률, 양자화, 텐서/파이프라인 병렬화.
7. 누가 실행했나? 벤더 자체 측정인가, 독립 랩인가, 커밋 해시가 있는 재현인가?
8. 비교 대상은 무엇인가? 같은 모델, 같은 하드웨어, 같은 워크로드, 같은 SLO인가?

이 중 셋 이상에서 답이 없다면, 구매 판단용 숫자가 아니라 방향성 신호로 다루세요.

돌아가려면 차트 판독값을 보거나, 빠진 서비스 계층으로 이어서 보세요.