서빙 튜닝에서 가장 먼저 부딪히는 벽은 지연과 처리량이 반대 방향으로 움직인다는 사실이다. 한쪽을 좋게 만드는 거의 모든 수단이 다른 쪽을 나쁘게 만든다.
왜 반대로 가는가
GPU는 행렬 하나를 크게 곱할 때 가장 효율적이다. 요청을 모아서 한 번에 계산하면 장비 입장에서는 이득이다. 모으는 동안 먼저 온 요청은 기다린다. 그 기다림이 지연이다.
즉 처리량은 “얼마나 모았는가”의 함수이고, 지연은 “얼마나 기다렸는가”의 함수다. 같은 손잡이를 반대로 돌린다.
기준점을 먼저 정한다
그래서 튜닝에 들어가기 전에 한쪽을 고정해야 한다. 실무에서는 지연 상한을 먼저 못 박는 편이 낫다.
- 대화형 서비스: 첫 토큰 1초 이내, 토큰 간격 50ms 이내
- 비동기 배치 작업: 지연 상한 없음, 처리량만 본다
상한을 정하면 질문이 명확해진다. “이 상한을 지키면서 낼 수 있는 최대 처리량은 얼마인가.”
상한 안에서 최대치를 찾는 법
동시 요청 수를 늘려가며 상한을 넘기는 지점을 찾는다. 그 직전 값이 그 장비의 실질 용량이다. 이 값은 모델과 프롬프트 분포에 따라 달라지므로, 실제 트래픽 로그에서 뽑은 길이 분포로 재야 의미가 있다.
균일한 길이로 측정한 용량은 대체로 과대평가다. 긴 요청 하나가 배치 전체를 붙잡는 효과가 빠져 있기 때문이다. 이 효과를 어떻게 줄이는지가 다음 부의 주제다.