이번 Dwarkesh 에피소드를 통해 LLM 서빙의 경제학이 단순한 하드웨어 스펙이 아니라 ‘t_compute와 t_memory의 균형’이라는 아주 단순한 방정식으로 설명될 수 있다는 점이 인상 깊었다. 프론티어 랩들이 API 가격을 책정할 때, 그리고 사용자가 느끼는 첫 토큰까지의 latency와 토큰당 비용이 사실 이 두 시간의 상호작용에 의해 결정된다는 통찰은 그동안 모델 크기와 training FLOPs에만 집중했던 나의 시야를 완전히 뒤흔들었다.
근거
원문에서는 roofline analysis를 통해 batch size에 따른 latency 곡선과 cost 곡선을 그리며, 배치가 작을 때는 메모리 때문에 latency가 높고, 배치가 커질수록 compute가 병목이 된다는 점을 설명한다. 특히 “latency lower bound는 weight를 한 번 로딩하는 시간”이라는 점이 핵심이다. 어떤 작은 요청이라도 모델 전체를 HBM에서 읽어야 하므로 최소 latency가 존재하며, 이로 인해 짧은 프롬프트도 비싸질 수밖에 없다.
“이 weight를 다 로딩하는 시간은 기본으로 걸리기 때문에 이게 latency lower bound라고 얘기하는 거죠.”
연결된 생각
- 20260605-llm-inference-roofline-analysis — 이 인사이트는 roofline 분석 개념에 체계적으로 정리되어 있음
- 20260605-200k-context-threshold-memory-bound — 이 균형이 깨지는 지점이 바로 200K context 임계점
- 20260605-chunked-prefill-vllm — vLLM의 chunked prefill은 t_compute와 t_memory의 균형을 동적으로 맞추기 위한 엔지니어링 기법
출처
- 📎 클리핑: 20260613-ep96-ko-transcript