2026-06-08 — 회 조회

왜 DGX Spark의 GB10은 디코딩 23 tok/s인데 프리필은 1,884 tok/s로 나오는가: 대역폭 예산 분해

vLLM의 2026년 6월 DGX Spark 배포에 대한 검증된 분해: 120B NVFP4 MoE 모델은 디코딩이 약 23 tok/s이지만 프리필은 약 1,884 tok/s이며, GB10의 273 GB/s 메모리 대역폭이 그 격차를 설명한다.

무엇이 공개되었나

2026년 6월 1일, vLLM 프로젝트는 단일 NVIDIA DGX Spark(GB10 Grace Blackwell 데스크톱 기기) 위에서 대규모 언어 모델을 구동하는 것에 관한 심층 분석 글을 공개했다. 그리고 그것은 대부분의 “첫인상” 게시물이 건너뛰는 한 가지를 해냈다——단일한 멋진 숫자 하나가 아니라, 하나의 현실적인 배포의 완전한 지연시간-처리량 형상을 보고한 것이다. 테스트 대상 모델은 Nemotron-3-Super-120B-A12B-NVFP4——NVFP4로 양자화된 120B 파라미터 mixture-of-experts(MoE) 체크포인트로, 토큰당 대략 10-15B 파라미터가 활성화되며, 기기의 128 GB 통합 CPU+GPU 메모리 풀 안에서 131,072-토큰의 최대 컨텍스트로 서비스되었다.

이 단일 구성은 로컬 Blackwell 추론이 실제로 어떻게 동작하는지를 보여주는 깔끔한 교육용 사례다. 왜냐하면 그것은 추론 요청의 두 단계——프리필(프롬프트를 읽기)과 디코딩(한 번에 한 토큰씩 답을 쓰기)——를 분리하고, 둘이 완전히 다른 성능 곡선 위에 있음을 보여주기 때문이다.

숫자들, 그리고 그것이 어느 단계에 속하는가

다음은 vLLM 게시물이 그 배포에 대해 보고한 수치에, 그것들이 자리한 GB10 하드웨어의 상한(NVIDIA의 칩 출시 상세 자료에서)과, 배치 처리의 전체 그림을 채워주는 커뮤니티 동시성 연구를 더한 것이다.

지표	수치	출처
디코딩 처리량(단일 스트림)	22.7–23.7 tok/s	vLLM, Nemotron-3-Super-120B-A12B-NVFP4
프리필, 짧은 심판 호출(58-토큰 프롬프트)	~140 tok/s, TTFT 0.42 s	vLLM
프리필, 중간 프롬프트(1,834 토큰)	1,636 tok/s, TTFT 1.12 s	vLLM
프리필, 긴 프롬프트(7,234 토큰)	~1,884 tok/s, TTFT 3.85 s	vLLM
테스트한 최대 컨텍스트	131,072 토큰	vLLM
데모 트래픽 하의 KV 캐시 사용률	30% 미만	vLLM
GB10 메모리 대역폭	273–301 GB/s	The Register(GB10 상세)
GB10 메모리	128 GB LPDDR5x, 256-bit 버스, 9,400 MT/s	The Register
GB10 FP4 최대 연산 성능	~1 petaFLOP	The Register

이 표를 위에서 아래로 읽으면 이야기는 저절로 쓰인다. 긴 프롬프트의 프리필은 1,600-1,900 tok/s로 돌아간다——디코딩 속도의 70배 이상이다. 디코딩은 프롬프트가 아무리 길어도 약 23 tok/s로 기어가듯 진행된다. vLLM 저자들은 디코딩이 “여전히 활성 파라미터 수에 의해 형성된다”고 지적하며, 프롬프트 크기 전반에 걸쳐 평탄하게 유지된다고 한다. 그 평탄함이 바로 단서다.

메커니즘: 디코딩은 대역폭 제약, 프리필은 연산 제약

자기회귀 디코딩은 순전파 1회당 토큰 1개를 생성한다. 각 토큰마다 엔진은 모델의 활성 가중치를 메모리에서 Tensor Cores로 스트리밍해야 한다. 각 약 0.5바이트인 약 12B의 활성 NVFP4 파라미터로 계산하면, 그것은 토큰당 대략 6 GB의 가중치 읽기(여기에 소량의 KV 캐시 읽기)다. GB10의 약 273 GB/s 하한에서 6 GB는 약 22 ms가 걸리며, 이는 이론상 45 tok/s 근처에서 상한을 두고, KV 읽기, MoE 라우팅, 프레임워크 오버헤드를 더하면 약 23 tok/s에 안착한다. 약 1 PFLOP의 FP4 연산 성능은 디코딩 중에는 거의 유휴 상태다——Tensor Cores는 대부분의 시간을 메모리를 기다리는 데 쓴다. 이것이 프롬프트가 58 토큰이든 7,234 토큰이든 디코딩 속도가 거의 움직이지 않는 이유다: 토큰당 가중치 읽기는 동일하다.

프리필은 정반대다. 모든 프롬프트 토큰을 하나의 큰 행렬 곱으로 병렬 처리하므로, 메모리 버스가 아니라 FP4 Tensor Cores를 포화시킨다. 이것이 프리필이 네 자릿수 tok/s에 도달하는 이유이며, TTFT가 프롬프트 길이에 따라 스케일하는 반면 디코딩은 그렇지 않은 이유다.

MoE 설계야말로 여기서 120B 모델을 애초에 쓸 만하게 만드는 것이다. NVFP4의 밀집 120B 모델은 토큰당 약 60 GB의 가중치 읽기를 필요로 하며 한 자릿수 낮은 값으로 디코딩하게 된다. 토큰당 약 12B 파라미터만 활성화함으로써, MoE는 토큰당 대역폭 청구서를 약 5배 깎는다——풍부한 통합 메모리 용량(120B 파라미터 전부를 저장)을 희소한 메모리 대역폭(스텝당 12B만 읽기)과 맞바꾸는 것이다. 이것이 로컬 Blackwell 추론의 핵심 설계 수다: 용량은 싸고, 대역폭이 곧 예산이다.

배치 처리가 계산을 바꾼다

단일 스트림 디코딩은 느려 보이지만, 별도의 동시성 벤치마크(Dendro Logic, 2026년 4월 22일)는 배치 처리할 때 무슨 일이 일어나는지를 보여준다. 단일 DGX Spark 위에서 Nemotron Super 49B v1.5 NVFP4는 1 스트림에서 합계 5.79 tok/s였던 것이 32 스트림에서 161.90 tok/s, 256 스트림에서 695.11 tok/s로——합계 120배의 향상——간 반면, 시퀀스당 속도는 5.79에서 2.85 tok/s로 떨어졌다. OpenAI의 gpt-oss 120B(MXFP4)도 동일한 형상을 보였다: 단일 스트림 33.53 tok/s가 256 스트림에서 합계 862.84 tok/s로 올랐다. 게시물의 표현은 정확하다: “메모리 대역폭은 당신이 쓰는 예산이다……두 스트림을 동시에 돌릴 때, 당신은 같은 가중치를 읽는 데 같은 대역폭 예산을 쓰고, 두 스트림 모두 결과를 얻는다.” 가중치는 한 번만 로드하고 그 읽기를 배치 전체에 분산하므로, KV 캐시 메모리나 연산이 마침내 포화될 때까지 합계 처리량은 계속 올라간다.

소프트웨어 스택은 또 다른 레버였다. NVIDIA는 2026년 1월 5일에, Qwen-235B에서 NVFP4와 추측 디코딩이 FP8 대비 최대 2.6배의 향상을 가져왔고, NVFP4가 메모리 사용량을 약 40% 줄이며, llama.cpp 업데이트가 MoE 모델에서 평균 35%의 향상을 더했다고——모두 동일한 실리콘 위에서——보고했다.

실무 노트

만약 내가 이런 기기 중 하나에 어시스턴트나 에이전트 루프를 배포한다면, 단일 스트림 디코딩을 “속도”로 인용하는 것을 그만두고, 대신 이 두 곡선을 중심으로 설계할 것이다. 대화형 단일 사용자에게 약 23 tok/s는 채팅에는 괜찮지만 긴 생성에는 고통스러우므로, 추측 디코딩에 기대고 출력을 짧게 유지할 것이다. 한 명 이상의 호출자에게 서비스하는 무엇이든——작은 팀, 배치 요약 작업, 많은 후보를 채점하는 LLM 심판 파이프라인——에는 동시성 16-32로 돌리고 기기를 처리량 엔진으로 취급할 것이다. 왜냐하면 그곳이 바로 대역폭 예산이 실제로 본전을 뽑는 곳이기 때문이다(위 데이터에서 합계 45~162 tok/s). 나는 기본값으로 NVFP4 MoE 체크포인트를 채택하고, 총 파라미터 수를 최대화하기보다는 활성 파라미터가 대역폭 예산에 여유 있게 들어맞도록 모델 크기를 정할 것이며, 누군가의 헤드라인 tok/s——내 것까지 포함해——를 믿기 전에 내 자신의 프롬프트 길이 분포로 프리필과 디코딩을 따로 벤치마크할 것이다.

간과된 관점

모두가 디코딩 tok/s를 벤치마크하지만, 에이전트 루프에 맞춰 프리필 예산을 짜는 사람은 거의 없다. 매 스텝마다 점점 커지는 7K-토큰 스크래치패드를 다시 읽는 에이전트형 워크플로는 매 턴 약 3.85초의 TTFT를 지불하며, 20스텝 루프 전체에 걸치면 그 프리필 비용이 실제 생성을 압도할 수 있다. 대역폭에 제약된 기기에서 프롬프트 캐싱과 KV 재사용은 있으면 좋은 최적화가 아니다——그것들은 쓸 만한 로컬 에이전트와, 실제 시간의 대부분을 자기 자신의 컨텍스트를 다시 읽는 데 쓰는 에이전트 사이의 차이 그 자체다. 120B 모델을 로드 가능하게 만드는 통합 메모리 설계는, 낭비된 프리필을 비싸게 만드는 바로 그 설계다. 왜냐하면 그것을 뒤에 숨길 여분의 대역폭이 없기 때문이다.