동일한 측정을 다시 해보니, 병목 현상(Bottleneck)은 움직이고 있었다

수개월 후에 동일한 측정을 다시 해보니, 내역이 정반대로 바뀌어 있었다. 생성(Generation)은 전체의 1할. 남은 9할은 대기열(Queue)과 거리였다.

지난번 가장 효과적이었던 레버(Lever)는 이제 빗나갔다. 병목 현상은 움직인다——정답에는 유통기한이 있다.

그래서 왕복 시간을 없애고자 사용자 근처에서의 추론(Edge Inference)을 시도했더니, 이번에는 전체가 3배 느려졌다. 부분 최적화는 전체 관점에서는 패배한다.

지난번, 느려짐의 원인은 모델의 생성——정확히는, 모델이 답하기 전에 "생각"하고 있었던 것이었다고 썼다. 사고(Reasoning)를 끄고(reasoning=none), 생성은 단숨에 가벼워졌다. 당시에는 그것으로 충분했다.

문제는, 정답에 유통기한이 있다는 것이다.

한번 "분해해서 측정하기"를 익히면 그것이 습관이 된다. 다른 작업을 하는 김에, 나는 다시 한번 동일한 내역 측정을 돌렸다. 깊은 의도는 없었고, 그저 "지금은 어떻게 되어 있는가"를 보고 싶었을 뿐이다.

나온 숫자를 보고 손이 멈췄다.

과거에 시간을 지배했던 생성이 이제는 **10%**까지 줄어들어 있었다. 게다가 신구 2개 기종(각 38개 샘플)에서 거의 일치하므로, 이는 측정 노이즈가 아니라 구조다.

이유는 바로 알 수 있었다. 지난번 모델의 "생각"을 멈추고, 그 후에도 출력을 좁혀나가면서 생성 자체가 가벼워졌다. 생성을 가볍게 만든 만큼, 상대적으로 "대기"와 "거리"가 부상한 것이다. 지배 항목이 바뀌어 있었다.

방금 전의 167ms는 대기열의 **중앙값(Median)**일 뿐이다. 그리고 대기열은 평균으로 말해서는 안 되는 것의 전형이었다. 그것을 통감한 것은 지금의 현행 모델이 아니라, 그 하나 전의 본방 후보였던 다른 모델에서의 일이다.

그 모델은 공유 인프라 상의 거대 모델이었다. 혼잡 시에 동일한 대기열을 측정하면——중앙값부터가 자릿수가 달랐다.

이 모델은 중앙값만으로 이미 약 1초——현행 모델(167ms)의 약 6배다. 그리고 100번에 1번은 약 5초를 기다려야 한다. 게다가 까다로운 점은 언제 그렇게 될지 예측할 수 없다는 것이다——한가한 시간대라면 150ms, 혼잡하면 이 분포. "항상 빠르다"도 "항상 느리다"도 아닌, 예측할 수 없다.

평균만 보고 있다면 이 테일(Tail)은 전혀 보이지 않는다. 하지만, 사용자가 기억하는 것은 평균이 아니라 그 최악의 한 번이다——매니페스트의 세 번째 원칙——좋은 대리 지표는 평균이 아니라 최악의 한 번(Tail)을 보는 것이다——그 자체다. 그리고 이 테일은 외부의 공유 인프라를 사용하는 한 없앨 수 없다——함께 줄을 서는 상대를 우리가 선택할 수 없기 때문이다. (전용(Dedicated)하면 이 테일째로 사라진다. 그것이 제5회 내용이다.)

네트워크의 275ms를 더 분해하면, 접속은 커넥션 풀(Connection Pool)로 재사용되고 있어 확립 비용은 거의 제로, 응답도 작고 전송도 순식간이다. 즉 275ms는 거의 순수한 지리적 왕복——단말기에서 먼 곳(당시에는 미국)에 있는 추론 서버까지의 물리적인 왕복 시간이었다. (세계 각지의 AWS 리전에서 실측한 상세 내용은 심층 분석 「지리는 레이턴시의 움직일 수 없는 바닥이다」를 참조.)

지난번의 정답 "모델이 생각하게 하지 않는다"는 이제 더 이상 효과가 없다. 10%밖에 안 되는 생성을 어떻게 만져도 체감은 거의 움직이지 않는다. 지금 지배적인 것은,

거리 (왕복 275ms) → 추론을 사용자 근처에 두면 사라진다. 이 275ms는 움직일 수 없는 물리적인 "바닥"이다.
queue (167ms) → 공유 인프라의 대기열. 전용하면 사라진다.

즉 레버는 "모델을 빠르게"도 "출력을 깎기"도 아닌, 추론 서버를 물리적으로 가깝게·전용으로 갖는 것으로 옮겨가 있었다.

"왕복만 없애면 빨라진다"라면 사용자 근처의 에지(Edge)에서 추론하면 된다. 운 좋게도 어떤 에지 추론 서비스에 완전히 동일한 모델이 올라와 있었다. 이미 그 에지 기반을 경유하고 있었기에, 호출 대상을 바꾸는 것만으로 비교할 수 있었다. 이론상으로는 완벽했다.

결과는 다음과 같다.

결정적인 패배. 왕복 시간(Round-trip time)을 250ms나 줄였음에도 불구하고, 전체 시간은 더 느려졌다.

원인은 분해표 덕분에 즉시 판명되었다. 거리가 가깝더라도, 에지(Edge)의 범용 GPU로는 생성이 제시간에 이루어지지 못했다. 워밍업(Warm-up) 이후의 순수 생성 속도조차 현행보다 느렸으며(측정 가능한 범위 내에서 약 1.5배), 실제 운용 시에는 콜드 스타트(Cold start)나 대기 시간까지 겹쳐, 번역이 끝나기 전에 제한 시간(1500ms)에 의해 중단되었다——그래서 자막이 나오지 않는 것이다. 표의 '1500ms'는 생성 속도가 아니라 클라이언트 측의 제한 시간 그 자체다. 왕복 시간을 아무리 줄여도, 생성이 마감 시간을 넘겨버리면 전체 결과에서는 패배한다. 10%까지 줄어들었어야 할 생성이, 느린 하드웨어에 올라간 순간 승패를 결정지었다.

여기서 지난번의 또 다른 교훈이 힘을 발휘한다. 부분 최적화(Partial optimization)는 함정이다. 왕복 시간만 줄여도 생성이 느리면 의미가 없다. 반대로 생성만 빨라도 거리가 멀면 의미가 없다.

따라서 조건은 '근접 및 고속 추론'의 양립이 된다. 시뮬레이션 결과, 전용 고속 칩을 사용자에게 가까운 지역(예: 국내)에 배치할 수 있다면 왕복 시간은 십수 밀리초(ms), 전체 시간은 100ms 전후까지 떨어질 것으로 전망되었다. 이것이 자체적으로 추론을 보유하는 것(Self-hosting)을 검토하기 시작한 진짜 기점이다. 빠른 모델을 원했던 것이 아니다. 가깝고도 빠른 장소를 원했던 것이다.

(그렇다면 왜 처음부터 자체적으로 구축하지 않았는가——그것은 공급 측의 사정이라는 또 다른 이야기로, 제4회에서 계속된다.)

병목(Bottleneck)은 움직인다. 그러므로 계속 측정하라. 한 번의 분해로 얻은 정답은 상황이 바뀌면 효력을 상실한다. 오차를 알아챌 수 있었던 것은 측정이 습관이 되어 있었기 때문이며, 지난번의 결론을 '이미 아는 것'이라며 치워두었다면 지금도 효과 없는 레버를 당기고 있었을 것이다. -
상대값으로 생각하라. 생성이 '가벼워진' 것이 아니라, 다른 요소가 상대적으로 '무거워진' 것이다. 지배적인 항목(Dominant term)은 절대값이 아니라 비율에 따라 바뀐다. -
부분 최적화는 함정이다. 왕복 시간을 줄여도 생성이 느리면 역효과를 낳는다. 전체(End-to-end) 관점에서 여러 구간을 동시에 만족시키지 못하면 이길 수 없다.