두 팀이 DeepSeek V4.1 Flash에 대해 초당 수백 개의 토큰을 보고할 수 있지만 여전히 서로 다른 것을 측정하고 있을 수 있습니다. 한 팀은 단일 요청의 디코드 속도를 의미할 수 있고, 다른 팀은 수십 개의 동시 요청에 걸친 총 출력을 의미할 수 있습니다. DeepSeek V4.1 Flash 추론 처리량 최적화를 개선하려면, 먼저 서비스에 필요한 지표를 선택한 다음, 자체 요청 믹스를 벤치마킹하고, 한 번에 하나의 서빙 변수를 변경하며, 지연 시간, 품질, 비용을 함께 검증하세요. 이제 모델 제품군에는 10월 17일 Flash-1017 업데이트가 포함되므로, 결과를 비교하기 전에 정확한 체크포인트를 기록하세요. 공개 보고서는 유용한 최적화 경로를 보여주지만, 자체 하드웨어에서 일치된 테스트를 대체할 수는 없습니다.
주요 요점
- 초당 총 출력 토큰은 요청 전반의 용량을 측정하고, 요청당 디코드 속도는 개별 사용자의 경험을 측정합니다.
- 튜닝 전에 프롬프트 길이, 출력 제한, 동시성, 워밍 상태, 지연 시간 목표를 재현하세요.
- V4.1 Flash의 압축된 KV 캐시와 바운디드 리플레이는 메모리 압박을 줄이지만, 고정된 종단 간 속도 향상을 보장하지는 않습니다.
- vLLM과 SGLang은 동일한 모델, 하드웨어, 워크로드, 측정 조건에서만 비교하세요.
DeepSeek V4.1 Flash에서 처리량이란 무엇인가?
처리량은 비율이지만, 분자와 테스트 경계가 중요합니다. 추론 서비스의 경우 최소 다섯 가지 측정값을 기록하세요:
| 지표 | 알려주는 내용 | 일반적 용도 |
|---|---|---|
| 초당 총 출력 토큰 수 | 모든 활성 요청이 초당 생성하는 출력 토큰 | 용량 계획 및 플릿 효율성 |
| 요청당 디코드 토큰/s | 개별 요청이 경험하는 생성 속도 | 생성 중 대화형 응답성 |
| 프리필 토큰/s | 초당 처리되는 입력 토큰 | 긴 프롬프트 및 검색 집약적 워크로드 |
| 첫 토큰까지 걸리는 시간 (TTFT) | 요청 도착부터 첫 출력 토큰까지의 시간 | 인지되는 시작 지연 |
| 종단 간 지연 시간, p50/p95 | 트래픽 분포 전반에 걸친 총 요청 지속 시간 | 서비스 수준 목표 및 테일 동작 |
서버는 더 많은 시퀀스를 배칭하여 총 처리량을 높이는 동시에 각 사용자가 토큰 사이에서 더 오래 기다리게 할 수 있습니다. 반대로 낮은 동시성에 맞춰 조정된 설정은 개별 응답은 빠르지만 가속기를 충분히 활용하지 못할 수 있습니다. 어느 결과도 보편적으로 더 낫지 않습니다. 올바른 목표는 제품의 서비스 목표를 충족하는 처리량-지연 시간 곡선상의 한 점입니다.
두 비율은 서로 다른 출력 스트림을 계산합니다. 이는 개념도이며, 측정된 DeepSeek V4.1 Flash 성능이 아닙니다.
처리량에 프리필, 디코드 또는 둘 다가 포함되는지 명시하세요. GPU 수로 나누는지도 밝히세요. 요청된 최대 토큰이 아닌 성공한 출력 토큰을 보고하고, 취소나 오류를 공개하세요. 이러한 세부 정보가 없으면, 토큰/s 수치는 운영자가 해당 애플리케이션을 예측할 수 있는지 알려줄 수 없습니다.
재현 가능한 DeepSeek V4.1 Flash 기준선 구축
유용한 기준선은 병목 현상을 드러낼 만큼 프로덕션 트래픽과 유사합니다. 단일 짧은 프롬프트는 큰 대화 기록을 반복해서 보내는 에이전트에 대한 빈약한 대리물이며, 고정된 1,024토큰 출력은 일찍 중단되거나 크게 변하는 워크로드를 놓칩니다.
워크로드 및 측정 창 고정
관찰된 트래픽에서 요청 버킷을 만드세요. 각 버킷에 대해 대략적인 입력 길이, 예상 출력 길이, 도착 패턴, 공유 접두사를 유지하세요. 실제 요청 경로의 일부인 경우 도구 또는 추론 턴을 포함하세요. 실행 간에 프롬프트, 샘플링 설정, 중지 조건, 출력 상한을 고정하세요.
낮은 동시성 사례와 서비스가 피크에 기대하는 동시성을 모두 실행하세요. 그런 다음 중간 동시성 수준을 추가하여 처리량이 상승을 멈추거나 지연 시간이 한계를 넘는 지점을 드러내세요. 워밍업 후 안정적인 측정 창을 사용하고, 각 지점을 반복하며, 중앙값과 범위를 보고하세요. 짧은 버스트는 안정적인 서비스 용량보다 시작 동작을 측정할 수 있습니다.
콜드 스타트 측정을 웜 서빙과 분리하세요. 콜드 실행은 스택에 따라 모델 로딩, 그래프 캡처 또는 캐시 채우기를 포함하고, 웜 실행은 서비스 준비가 된 시스템을 설명합니다. 접두사 캐싱 워크로드의 경우 캐시 적중 및 캐시 미스 트래픽을 별도로 측정하세요. 믹스가 프로덕션과 일치하지 않는 한 하나의 평균으로 결합하지 마세요.
벤치마크 기록 유지
각 실행에 대해 다음 필드가 포함된 행을 저장하세요: 체크포인트 또는 모델 개정; 런타임 및 커밋; GPU 모델 및 수; 인터커넥트; 정밀도 및 양자화; 텐서, 전문가 또는 파이프라인 병렬 레이아웃; 입력 및 출력 토큰 분포; 동시성 및 요청 도착 패턴; 웜 또는 콜드 상태; 실행 지속 시간; 성공률; 총 처리량; 요청당 디코드 속도; TTFT; 그리고 p50/p95 종단 간 지연 시간.
이 기록은 리더보드 숫자보다 유용합니다. 다음 실험을 재현 가능하게 만들기 때문입니다. 튜닝 전에 이를 동결하세요. 워크로드나 체크포인트가 변경되면, 차이를 서빙 플래그에 귀속시키지 말고 새로운 기준선을 시작하세요.
프리필, 디코드, KV 캐시 또는 스케줄링 진단
증상을 사용하여 다음 측정을 선택하고, 수정을 추측하지 마세요. 디코드 속도가 수용 가능한데 TTFT가 높으면 입력 처리, 큐잉, 캐시 미스 또는 시작 오버헤드를 가리킵니다. 낮은 동시성에서 느린 디코드는 커널, 메모리 대역폭, 병렬 통신 및 모델의 실행 경로를 조사해야 함을 시사합니다. 동시성이 증가함에 따라 정체되는 총 처리량은 메모리 압박, 스케줄러 제한, 통신 오버헤드 또는 포화된 컴퓨팅 경로를 나타낼 수 있습니다. 긴 컨텍스트 성능 저하는 캐시 상주, 프리필 작업 및 호스트-장치 이동을 측정해야 합니다.
| 관찰 | 첫 번째 확인 사항 |
|---|---|
| 프롬프트 길이에 따라 TTFT 증가 | 프리필 속도, 큐 시간, 접두사 캐시 적중률, 그래프 또는 컴파일 워밍업 |
| 동시성 1에서도 디코드 속도가 낮음 | 런타임 모델 경로, 커널 지원, 정밀도, GPU 활용도, 통신 오버헤드 |
| 동시성 증가에 따라 초당 총 토큰이 정체 | KV 캐시 용량, 스케줄러 배칭, 메모리 대역폭, 병렬 토폴로지 |
| 총 출력이 개선되는 동안 p95 지연 시간이 급증 | 배치 크기, 큐잉 정책, 요청 길이 믹스, 서비스 목표 |
| 긴 프롬프트가 유용한 활성 요청을 축출 | KV 캐시 상주, 캐시 할당, 컨텍스트 분포, 호스트 메모리 트래픽 |
V4.1 Flash에는 이러한 압력 중 일부를 완화하기 위한 아키텍처 기능이 있습니다. 모델 보고서는 계층 간 캐시 재사용과 FP4 글로벌 KV 캐싱을 갖춘 CSA2를 설명하며, 이는 토큰당 890바이트의 글로벌 KV 풋프린트를 보고합니다. 이는 V4-Flash의 해당 풋프린트의 약 4분의 1입니다. SWA 바운디드 리플레이는 다른 스토리지 트레이드오프를 해결합니다. 모든 슬라이딩 윈도우 어텐션 상태를 유지하는 대신, 배포는 최근 윈도우를 재생하여 누락된 상태를 재구성할 수 있습니다. DeepSeek는 이 설계에 대해 V4-Flash 풋프린트의 약 8분의 1에 가까운 영구 KV 캐시를 보고하며, 약간의 추가 프리필 재계산이 있습니다. 이는 아키텍처 및 배포 결과이지, 8배 처리량 약속이 아닙니다. (DeepSeek 기술 보고서, 2026년 9월)
소스 그림은 모든 배포에 대한 종단 간 처리량 승수가 아닌 캐시 용량을 설명합니다.
진단이 불분명하면, 하나의 대표적인 실행을 프로파일링하고 큐 시간, GPU 활용도, 메모리 사용량, 단계별 타이밍을 검사하세요. 하나의 변수를 변경하고 동일한 워크로드를 다시 실행한 후, 출력 정확성이나 작업 품질을 확인하세요. 이렇게 하면 겉보기 속도 향상이 서비스나 답변의 회귀를 가리는 것을 방지할 수 있습니다.
동일한 목표에 대해 vLLM 또는 SGLang 튜닝
배포하려는 체크포인트와 하드웨어를 지원하는 현재 모델 경로를 가진 런타임을 선택하세요. 정확한 릴리스, 커널, 그래프 동작, 병렬 레이아웃을 확인하세요. 모델이 지원됨으로 나열된다고 해서 모든 양자화 또는 토폴로지가 동등하게 최적화되었다는 의미는 아닙니다.
vLLM: 릴리스별 모델 경로 검증
vLLM 팀의 10월 보고서는 AgentX 벤치마크에서의 진행 상황을 설명합니다. 자사 데이제로 기준선 대비 저지연 결과에서 약 1.9배 개선, 150 TPS 제약 조건에서 약 5.3배 처리량을 보였습니다. 이 작업에는 CUDA 그래프를 사용한 SWA 바운디드 리플레이와 모델별 커널 통합이 포함되었습니다. 이러한 값을 해당 벤치마크에서 스택이 시간이 지남에 따라 크게 변경되었다는 증거로 취급하고, 다른 클러스터에 적용할 승수로 간주하지 마세요. ( vLLM 엔지니어링 보고서, 2026년 10월)
실행을 위해 먼저 지원되는 릴리스와 검증된 구성을 설정하세요. 그런 다음 그래프 캡처 또는 리플레이 동작, 배칭, 병렬 처리를 개별적으로 측정하세요. 더 높은 처리량 지점을 선택하는 데 사용된 지연 시간 제약을 유지하세요. 그래프 캡처가 시작 또는 메모리 요구 사항을 변경하는 경우, 해당 비용을 배포 결정에 포함하세요.
SGLang: 동시성 프로필 일치
SGLang 팀의 보고서는 테스트 컨텍스트가 왜 중요한지에 대한 매우 명확한 예를 제공합니다. 8개의 H200 GPU에서 추측 디코딩 없이 최적화된 실행은 동시성 1에서 사용자당 약 76에서 168 토큰/s로 상승했고, 동시성 64에서 GPU당 약 96에서 221 출력 토큰/s로 상승했습니다. 고정된 8,192토큰 입력과 1,024토큰 출력을 사용했습니다. 별도의 4×GB300 결과는 다른 프롬프트 길이, 병렬 설정, DSpark 추측 디코딩을 사용했습니다. 따라서 이 보고서는 vLLM AgentX 수치와 직접 순위를 매기는 것이 아니라, 귀하의 트래픽에서 SGLang의 최적화를 평가하는 것을 뒷받침합니다. ( LMSYS/SGLang 최적화 보고서, 2026년 9월)
소스 보고서는 서로 다른 워크로드와 하드웨어를 사용하므로, 해당 수치를 일대일 차트로 읽어서는 안 됩니다.
하나의 런타임으로 시작하여 지원되는 경로를 최적화하세요. 체크포인트, GPU 할당, 프롬프트 및 출력 분포, 동시성, 워밍업, 서비스 목표를 일정하게 유지할 수 있는 경우에만 두 번째 런타임 비교를 구축하세요. 이러한 비교는 엔지니어링 시간을 소모하므로, 먼저 현재 스택이 실제로 제한 요인인지 확인하세요.
SLO를 깨지 않고 동시성 및 긴 컨텍스트 최적화
동시성을 단계적으로 증가시키고 각 단계에서 총 출력, 요청당 디코드 속도, TTFT, p95 지연 시간, 메모리 사용량, 실패를 캡처하세요. 지연 시간과 오류율이 여전히 서비스 목표를 충족하는 경우에만 최고 처리량 지점을 유지하세요. 생성 전에 요청이 대기열에 쌓이면, 더 큰 배치가 장치 활용도를 개선할 수 있지만 제품이 더 느리게 느껴질 수 있습니다.
긴 컨텍스트 트래픽의 경우 활성 컨텍스트 분포와 캐시 적중률을 측정하세요. 명시된 최대 컨텍스트 창이 모든 요청이 해당 길이로 동시에 처리될 수 있다는 의미는 아닙니다. KV 캐시는 가중치, 활성화, 그래프 풀, 런타임 버퍼와 메모리를 두고 경쟁합니다. 가변 요청 길이를 위한 여유 공간을 남기고 현실적인 트래픽에서 축출 또는 선점을 측정하세요.
더 긴 컨텍스트나 더 많은 동시 요청은 KV 캐시 수요를 증가시킬 수 있습니다. 메모리 블록은 도식적이며 축척에 맞지 않습니다.
양자화, KV 캐시 정밀도, 텐서 병렬 처리, 전문가 병렬 처리, 프리필/디코드 분리를 별도의 실험으로 취급하세요. 이들은 메모리 사용, 통신, 커널 선택, 출력 품질, 지연 시간을 변경할 수 있습니다. 최상의 레이아웃은 GPU 유형과 인터커넥트에 따라 달라집니다. GPU를 더 추가하면 통신 비용이 증가하거나 일부 리소스가 유휴 상태로 남을 수 있습니다. 정밀도나 모델 실행을 변경한 후 정확한 출력 품질과 실패 모드를 확인하세요.
실용적인 순서는 간단합니다: 기준선을 재현하고, 목표를 벗어난 지표를 식별하고, 하나의 병목 가설을 세우고, 하나의 설정을 변경하고, 반복하세요. 설정이 한 지표를 개선하면서 다른 지표를 해치는 경우, 그 트레이드오프가 제품에 적합한지 명시적으로 결정하세요. 이렇게 하면 최적화가 플래그 더미가 아닌 통제된 결정이 됩니다.
추측 디코딩 및 주장된 모든 속도 향상 검증
추측 디코딩은 초안 토큰이 효율적으로 수락되고 런타임이 검증을 잘 구현할 때 직렬 대상 모델 작업을 줄일 수 있습니다. 그 이점은 초안 경로, 수락 동작, 배치 형태, 하드웨어, 프롬프트/출력 믹스에 따라 달라집니다. 디코드에 바운드된 트래픽에 도움이 될 수 있으며, 프리필, 큐잉 또는 통신이 지배적인 경우에는 가치가 거의 없습니다.
추측을 활성화 및 비활성화한 상태로 A/B 테스트를 실행하세요. 모델 체크포인트, 프롬프트 세트, 토큰 상한, 도착 패턴, 동시성, 워밍업, 측정 창을 고정하세요. 가능한 경우 검증 단계당 수락된 토큰을 총 처리량, 요청당 속도, TTFT, p95 지연 시간, GPU 사용, 실패, 작업 품질과 함께 기록하세요. 게시된 벤치마크의 시뮬레이션된 수락 길이는 테스트 조건이지, 프롬프트에 대해 가정할 값이 아닙니다.
주장된 속도 향상은 세 가지 검사를 통과할 때만 유용합니다: 동일한 서비스 목표, 수용 가능한 답변 품질, 공정한 비용 비교. 게시하는 모든 숫자와 함께 전체 컨텍스트를 보고하세요. 다른 GPU 수, 프롬프트 길이, 출력 길이, 정밀도 모드, 모델 개정 또는 지표를 통제된 실험인 것처럼 비교하지 마세요.
자체 호스팅 또는 관리형 DeepSeek V4.1 Flash API 사용?
자체 호스팅은 트래픽이 GPU를 유용하게 유지할 만큼 안정적이고, 팀이 추론 인프라를 운영할 수 있으며, 하드웨어나 실행에 대한 제어가 운영 작업을 정당화할 때 합리적입니다. 가속기, 용량 여유, 전력, 네트워킹, 스토리지, 유지보수, 엔지니어링 시간의 전체 비용을 포함하세요. 높은 최고 토큰/s 결과만으로는 성공적인 작업당 비용이 더 낮다는 것을 입증하지 않습니다.
관리형 API는 팀이 제품 수요를 신속하게 검증하거나, 서빙 플릿을 운영하지 않거나, API 기준선을 자체 배포와 비교해야 할 때 유용합니다. Atlas Cloud는 DeepSeek V4.1 Flash를 모델 ID deepseek-ai/deepseek-v4.1-flash로 OpenAI 호환 API와 함께 나열합니다. DeepSeek V4.1 Flash 모델 페이지는 현재 백만 입력 토큰당 $0.30, 백만 출력 토큰당 $1.20, 백만 캐시 읽기 토큰당 $0.03을 표시하며, 2026년 10월 기준으로 할인이 표시되지 않습니다. 지출을 추정하기 전에 현재 가격 목록을 확인하세요. 관리형 엔드포인트가 자체 요청 지연 시간이나 트래픽 경제성을 측정할 필요성을 없애지는 않습니다.
이 목록은 관리형 API 옵션을 식별하며, 서빙 벤치마크가 아닙니다.
공정한 배포 결정을 위해 동일한 비즈니스 요청을 자체 호스팅 서비스와 관리형 엔드포인트에 대해 재생하세요. 완료된 작업당 비용, 지연 시간 분포, 안정성, 각 옵션을 유지하는 데 필요한 직원 시간을 비교하세요. 주요 목표가 DeepSeek V4.1 Flash 추론 처리량 최적화라면, 두 경로 모두에 동일한 워크로드와 성공 기준을 유지하세요.
자주 묻는 질문
처리량과 사용자당 초당 토큰의 차이점은 무엇인가요?
총 처리량은 활성 요청 전반의 출력을 계산합니다. 사용자당 토큰/s는 하나의 요청의 디코드 속도를 측정합니다. 배칭은 첫 번째를 증가시키면서 두 번째를 감소시킬 수 있으므로, 대화형 서비스의 경우 둘 다 보고하세요.
동시성을 높이면 항상 처리량이 향상되나요?
아니요. 총 출력은 컴퓨팅이나 메모리가 포화될 때까지 상승하다가 평탄해질 수 있습니다. 그 시점 이후에는 큐잉과 테일 지연 시간이 계속 악화될 수 있습니다. 서비스 목표가 실패하면 동시성 증가를 중단하세요.
vLLM과 SGLang 벤치마크 수치를 직접 비교할 수 있나요?
모델 개정, 하드웨어, 프롬프트 및 출력 길이, 동시성, 웜 상태, 측정 경계, 지연 시간 제약이 일치하는 경우에만 가능합니다. 게시된 보고서는 서로 다른 설정을 사용하므로, 직접적인 런타임 승자를 보여주기보다 최적화 경로를 보여줍니다.
자체 호스팅 대신 관리형 API를 언제 사용해야 하나요?
관리형 API는 통합 속도와 인프라 작업 감소가 서빙 스택을 소유하는 것보다 더 중요할 때 사용하세요. 자체 호스팅은 활용도, 운영 전문성, 제어, 측정된 총비용 사례가 GPU 실행을 정당화할 때 사용하세요.
