추론 병목 전이 모델
단위부터: 저장하는 토큰과 생성하는 토큰
context tokens × KV bytes/context-token = bytes/session
500,000 × 890 B = 445 MB/session
10,000 sessions × 445 MB = 4.45 TB
generated tokens/s × bytes/generated-token = bytes/s
4M tok/s × 100 KB/tok = 400 GB/s
4M tok/s × 1 MB/tok = 4 TB/s
전체 처리량 = 활성 세션 수 × 세션당 속도. 예: 1,000 × 200 tok/s/session = 200,000 tok/s.
두 bytes/token은 서로 다른 값입니다. 저장된 context 토큰 1개의 KV 크기와 출력 토큰 1개를 생성할 때 다시 읽는 전체 데이터량을 구분합니다. 여러 sequence를 만드는 사용자는 여러 세션으로 셉니다. 속도가 다르면 평균값 또는 세션별 합계를 씁니다. 예시는 10진 단위의 가정입니다.
예: KV 예산 10 TB ÷ 445 MB/session = 약 22,472개 세션. 20 TB/s ÷ (1 MB/token × 200 tok/s/session) = 100,000개 세션. 둘의 최솟값은 용량·대역폭만 고려한 상한이며 연산·통신·지연도 확인해야 합니다.
Inference Bottleneck Transition Model
기술·서빙 조건이 바뀌면, 자원 수요와 다음 포화 지점은 어떻게 달라질까?
모든 기본값·변화 배수는 교육용 가정입니다. 제품 실측이나 투자 전망치가 아닙니다. 하나의 decode 풀과 여기에 할당한 KV 계층을 계산합니다.
KV 절반 + GPU 통신 공급 2배 + 유효 연산 공급 1.5배. 특정 제품의 전망치가 아닙니다.
현재 가정에서 압력 최대: GPU 간 네트워크 → HBM 용량
변화 후 100% 이상: 없음 · 아직 포화 전
같은 수요 구성을 늘릴 때 첫 포화: GPU 간 네트워크 → HBM 대역폭
수요 압력 = 요청 수요 ÷ 유효 공급. 100% 초과는 미처리 수요를 뜻하며 실제 사용률이 아닙니다. 회색은 변화 전, 색은 변화 후입니다.
- HBM 용량87.5% → 73.75%
용량: 59 / 80 GB
- HBM 대역폭83.6% → 67.6%
대역폭: 0.85 / 1.25 TB/s
- 연산80% → 53.33%
연산: 2 / 3.75 PFLOP/s
- GPU 간 네트워크88.55% → 44.28%
대역폭: 0.27 / 0.6 TB/s
- DRAM39.06% → 19.53%
대역폭: 20 / 200 GB/s · 용량: 200 / 1,024 GB
- SSD50% → 25%
대역폭: 8 / 32 GB/s · 용량: 2,000 / 8,192 GB
점선 = 100%. 막대 범위 0–200%, 초과 값은 숫자로 표시. DRAM·SSD 점수는 용량/대역폭 압력 중 큰 값입니다.
요청 처리량 · 전 → 후
20,000 → 20,000 tok/s
같은 수요 구성의 연속 상한 · 전 → 후
22,585.41 → 29,585.8 tok/s
상한은 실측 throughput이 아닙니다. 고정 TPS, 고정 배치·token당 비용, 세션·warm/cold 보관·이동의 동일 비율 확장을 전제합니다. 가중치·버퍼는 고정합니다.
어느 수요 항목이 바뀌었나
- HBM 가중치 읽기: 31.25 → 31.25 MB/token
- HBM KV 읽기: 20 → 10 MB/token
- HBM 기타 이동: 1 MB/token
- 전체 연산 / 그중 재계산: 100 / 0 → 100 / 0 GFLOP/token
- 전문가 왕복 통신: 12.58 → 12.58 MB/token · 기타 통신: 0.7 MB/token
- DRAM 세션 이동: 40 → 20 GB/s
- SSD 이동 / 보관: 16 GB/s / 4,000 GB → 8 GB/s / 2,000 GB
- 대역폭·용량만으로 계산한 최소 SSD 수: 2 → 1 · ceil(max(BW/장치 BW, 용량/장치 용량)). IOPS·수명·복제·장애 여유·공유 링크는 별도입니다.
시스템·워크로드별 비교표
직접 입력한 가정만 비교합니다. 저장한 행은 이 화면에서만 유지됩니다. 이름에 제품명을 넣어도 실측 자료가 되지는 않습니다.
| 시스템 / 워크로드 가정 | HBM 용량 | HBM 대역폭 | 연산 | GPU 간 네트워크 | DRAM | SSD |
|---|---|---|---|---|---|---|
| 기준 | 87.5% | 83.6% | 80% | 88.55% | 39.06% | 50% |
| 현재 변화 | 73.75% | 67.6% | 53.33% | 44.28% | 19.53% | 25% |
다음 포화 지점에서 확인할 공급망 지표
- · 메모리 업체: 유효 대역폭·에너지/bit·스택 구성·제품 믹스 확인
기술 압력은 기업의 매출·마진·주가 변화와 같지 않습니다. 제품 믹스·채택·공급 경쟁·가격·납품으로 연결을 검증합니다.
변화 배수 직접 조정
수요·아키텍처 배수
자원 공급 배수
기준 시스템·워크로드 입력
동일 풀 전체의 값입니다. 유효 공급은 해당 정밀도·커널·통신 경로에 맞춰 입력하며 사용률을 다시 곱하지 않습니다. warm/cold KV 크기는 활성 KV와 다를 수 있어 별도 입력합니다.
워크로드와 KV
HBM 공급과 가중치
연산 공급과 token당 비용
GPU 간 통신
DRAM warm tier
SSD cold tier
계산 방법·해석 조건·출처
연산 = tok/s × (attention + MoE + 별도 dense + routing + replay + 기타). MoE의 MLP를 dense 항목에 다시 넣지 않습니다. HBM 읽기 = 배치당 가중치/유효 배치 + context KV × 읽기 비율 + 기타. 전문가 통신 = 2 × hidden dimension × 원소 bytes × top-k × 원격 비율 × 층 수. KV와 PD/collective 항목도 중복 없이 더합니다.
HBM 용량은 가중치 + 런타임 버퍼 + 활성·유휴 상주 KV입니다. DRAM/SSD 이동량은 (저장/s + 재개/s) × 세션당 KV, 용량은 보관 세션 × KV입니다. SSD 최소 개수는 정수 올림입니다. 모든 byte 접두사는 10진법입니다.
tok/s 상한은 모든 세션·보관·이동을 같은 비율로 늘리는 경우에만 비교 가능합니다. HBM은 고정 가중치·버퍼를 먼저 뺍니다. 그래서 현재 압력 최대와 첫 포화 자원이 다를 수 있습니다. offload 횟수가 token 수와 독립적으로 움직이면 tok/s 상한 대신 각 tier의 GB/s·GB 압력을 보세요.
SWA 재계산·MLA/GQA·KV 재사용·양자화의 효과 배수는 모델·품질·커널별로 보정해야 합니다. 전체 전문가 수 증가만으로 token당 활성 연산·통신이 반드시 늘지는 않습니다. 복제는 원격 비율과 상주 용량을 바꾸지만 HBM 읽기를 자동으로 늘리지 않습니다. 배치 증가의 유효 연산 성능 개선도 직접 검증해 공급 배수로 입력합니다.
Prefill·midfill 혼합, KV 변경에 따른 품질 손실, speculative acceptance, 샤드 불균형, IOPS·지연·큐·공유 PCIe/네트워크 경합은 계산하지 않습니다. 네트워크 입력은 전문가 왕복과 같은 집계 기준이며 DRAM/SSD 유효 대역폭은 DMA·연결 경로를 포함해야 합니다. 여러 tier가 한 경로를 공유한다면 합산 수요를 별도로 확인해야 합니다.
로컬 원문은 KV 감소 후 연산·통신 제약 가능성과 HBM→DRAM→저장 계층을 설명합니다. 특정 SWA 구현의 효과나 GB300/Rubin 조합별 수치로 검증된 표를 제공하는 것은 아닙니다.
SemiAnalysis · 2026-09-13 · Long Live the Short King ↗SemiAnalysis · 2026-09-21 · Computation and Data Movement for Inference ↗NVIDIA Dynamo · KV cache offloading ↗NVIDIA Megatron Core · Expert dispatch / combine ↗Midfill을 Attention·Expert로 나눠 검토
이상적 roofline 비교이며 전체 Midfill의 병목 판정이 아닙니다. Attention은 요청 하나, Expert는 아래 요청 수를 모은 배치입니다. activation·output·통신·커널 지연을 생략한 전문가 AI는 낙관적 상한입니다.
현재 계산 범위: GB200 Superchip · 2 GPUs
버튼은 공식 peak 사양 참고값을 넣습니다: Attention BF16 dense, Expert FP8 dense. 실제 커널 유효 성능은 더 낮을 수 있습니다. KV 저장 정밀도와 연산 정밀도를 혼동하지 마세요. 사양 확인: 2026-09-27, Rubin은 예비 사양.
단계별 계산 가정 수정
Machine balance: Attention 312.5 / Expert 625 FLOP/B
| 신규 토큰 M | Attention FLOP/B | KV 읽기 ms | QK+AV 연산 ms | Attention | 평균 token/expert | Expert FLOP/B | Expert |
|---|---|---|---|---|---|---|---|
| 50 | 50 | 2.19 | 0.35 | 메모리 쪽 | 1.56 | 3.93 | 메모리 쪽 |
| 100 | 100 | 2.19 | 0.7 | 메모리 쪽 | 3.13 | 6.52 | 메모리 쪽 |
| 500 | 500 | 2.19 | 3.5 | 연산 쪽 | 15.63 | 31.25 | 메모리 쪽 |
| 1,000 | 1,000 | 2.19 | 7 | 연산 쪽 | 31.25 | 62.5 | 메모리 쪽 |
| 5,000 | 5,000 | 2.19 | 35 | 연산 쪽 | 156.25 | 312.5 | 메모리 쪽 |
| 10,000 | 10,000 | 2.19 | 70 | 연산 쪽 | 312.5 | 625 | 경계 |
현 가정의 crossover: Attention M ≈ 312.5, Expert M ≈ 10,000 (모든 전문가가 충분히 선택되는 근사).
Attention AI = M × query당 FLOPs/KV-byte ÷ KV 읽기 횟수. 계수 1은 단순 BF16 MHA 가정에 가깝습니다. GQA는 query/KV head 비율에 따라 달라지고 MLA는 별도 연산 구조가 필요합니다. 원문의 70 kB/context-token은 압축 attention 참고값이므로 35 GB라는 저장 크기만으로 연산량을 확정할 수 없습니다.
Expert 평균 할당 = M × 함께 모인 요청 × top-k / 전체 전문가. AI는 균등 라우팅에서 실제 선택되는 전문가 수를 추정해 계산합니다. 선택되지 않은 전문가까지 읽지 않습니다. 실제 쏠림·캐시·GEMM 크기·TP/EP 배치는 결과를 바꿉니다. 요청 여러 개가 모이면 단일 요청 10k token 같은 경계가 그대로 유지되지 않습니다.
256 experts에서 EP=256은 복제·TP 없이 한 expert를 한 rank에만 놓는 경우의 상한입니다. 전체 시스템의 절대 GPU 상한이 아닙니다. EP를 넓히는 가치는 bytes만 아니라 전문가별 token 수·불균형·동기화·지연으로 검증합니다.
네트워크: 바이트 여유와 지연 예산은 별개
8,192 × 2 bytes × top-8 × 왕복 2 × 70층 = 약 18.35 MB/token. 풀 전체 10k tok/s라면 약 183.5 GB/s입니다. 이 합계를 GPU 한 개의 포트 대역폭과 비교해 전체 fabric 병목을 판정할 수는 없습니다. 가장 바쁜 GPU·링크·방향·시간 구간을 맞춰야 합니다.
가정한 직렬 통신 시간: 3.5 ms / 토큰 간 시간 예산 5 ms = 70%
예시 입력은 실측이 아닙니다. 통신을 완전히 직렬로 더한 시간이며 실제 overlap·큐·tail latency는 trace로 확인합니다. 연산·메모리 시간도 이 예산을 사용합니다. 대역폭 사용이 낮아도 지연 제약이 있을 수 있습니다.
공식 사양 기준으로 GB200의 HBM 16 TB/s는 2 GPU 합계입니다. GPU당 8 TB/s와 NVLink 1.8 TB/s를 맞추면 비율은 22.5%입니다. Rubin HGX 표의 22 TB/s와 3.6 TB/s는 약 16.4%입니다. 다른 NVLink 소개 페이지에는 3 TB/s도 남아 있어 범위·사양 버전을 맞춰야 합니다. 이 비율 자체가 실효 병목을 판정하지는 않습니다.
KV 용량 효과만 따로 보기 · 네 자원 기초 실험
KV를 줄이면, 다음에는 어디가 막힐까?
교육용 가정입니다. 같은 decode 풀에서 충분한 요청을 받으며 세션당 속도를 고정합니다. Rubin·DeepSeek 실측 성능이 아닙니다.
HBM 용량 → GPU 간 네트워크
동시 세션 상한: 25,000 → 40,000
고정 속도에서의 총 처리량 상한: 5,000,000 → 8,000,000 tok/s
- HBM 용량25,000 → 100,000 세션
- HBM 대역폭80,000 → 80,000 세션
- 연산50,000 → 50,000 세션
- GPU 간 네트워크 · 먼저 포화40,000 → 40,000 세션
위 회색 = 감소 전 · 아래 색 = 감소 후. 가장 낮은 상한이 제한합니다.
같은 token당 비용에서: 총 GPU 간 전송 0.5 → 0.8 TB/s · 총 연산 100 → 160 PFLOP/s.
연산·통신·메모리 가정 바꾸기
모든 값은 동일한 서빙 풀 전체 기준입니다. 대역폭과 bytes/token은 같은 통신 경로·송수신 집계 방식을 써야 합니다. 아래 token당 비용은 슬라이더와 독립적으로 고정됩니다.
계산식·원문 조건·기업을 볼 때의 의미
용량 제한 세션 = ⌊KV 예산 / 세션당 KV⌋. 나머지 세션 제한 = ⌊(유효 자원/초 ÷ token당 소요량) / 세션당 고정 tok/s⌋. 네 상한의 최솟값에 고정 tok/s를 곱합니다. KB·MB·GB·TB는 10진 단위입니다.
이 값은 실측 처리량이 아닙니다. 최소 TPS만 보장하고 여유 자원으로 더 빠르게 생성하는 서비스에는 그대로 적용할 수 없습니다. 작은 배치의 지연, 통신 중첩, expert 쏠림, 샤드별 용량, 큐·스케줄러 때문에 실효 성능이 달라집니다.
KV 압축이 token당 연산·통신을 반드시 늘리지는 않습니다. 동일한 작업량에서도 동시 세션이 늘면 초당 총부하가 커질 수 있습니다. 압축·배치·모델 변경은 token당 비용도 바꿀 수 있으므로 별도로 측정해야 합니다.
원문은 V4.1 Flash의 활성 KV가 V4 Flash 대비 약 75% 작다고 설명하며 다음 제약이 연산·통신일 가능성을 제시합니다. 이는 저자 분석입니다. 본문 roofline 예시는 Kimi K3 / Rubin Ultra NVL576이며 Rubin NVL72 + V4.1 + 200 TPS의 실측 검증으로 합치지 않습니다.
MoE 통신량은 모든 층의 원격 expert 전달·결과 회수와 필요한 collective를 같은 기준으로 합산합니다. 총 링크 대역폭만으로는 혼잡·bisection·지연을 설명할 수 없습니다. 예를 들어 10M tok/s × 100KB/token = 1TB/s는 단위 계산이며 제품 성능 수치가 아닙니다.
기업 분석에서는 HBM 용량 프리미엄, HBM 대역폭, 가속기 연산, GPU 간 연결을 따로 봅니다. 삼성전자·SK하이닉스의 총수요 감소나 NVIDIA·네트워크 업체의 매출 증가를 이 계산만으로 확정하지 않습니다. 동일 품질에서 KV 상주량·유효 처리량·연산률·링크 혼잡·납품을 확인합니다.
SemiAnalysis · 2026-09-13 · Long Live the Short King: Why 4-hi HBM Wins ↗NVIDIA · GPU Performance Background ↗