토큰 가격 너머

프론티어 AI 기업들이 공개하는 토큰 가격을 볼 때면, 이 숫자가 AI 제품을 운영하는 비용에 대해 얼마나 말해 주는지 궁금해진다. 모델에 보내는 텍스트와 모델이 생성하는 텍스트의 양을 알면 토큰 비용은 어림할 수 있다. 그런데 그 작업 대부분이 바쁜 한 시간에 한꺼번에 몰린다면 서비스에는 무슨 일이 생길까? 이 질문을 따라가며 공개된 Azure 워크로드를 들여다본 노트다.

출발점은 사고실험이었다. 같은 모델로 하루에 같은 양의 토큰을 처리하는 서비스가 두 가지 경우에 놓여 있다고 하자. 한 경우에는 요청이 고르게 들어오고, 다른 경우에는 한 시간에 몰린다. 토큰 비용은 똑같을 수 있다. 그래도 두 번째 경우에는 그 한 시간 동안 더 많은 용량이 필요하거나 사용자를 기다리게 할 것이라고 예상한다. 실제 요청 데이터에서는 이 차이가 얼마나 드러날까?

이를 확인하려고 Microsoft가 공개한 Azure의 코드 관련 추론 요청 기록을 분석했다. 각 요청이 언제 도착했는지, 입력과 출력이 얼마나 길었는지가 담긴 자료로, 2024년 5월의 일주일을 다룬다. 응답 시간은 들어 있지 않다. 그래서 들어온 작업량은 살펴볼 수 있어도 Azure가 그 작업을 얼마나 빨리 끝냈는지는 알 수 없다.

요청이 도착하는 시점

먼저 궁금했던 것은 평균 도착률을 용량 추정의 출발점으로 삼아도 되는지, 아니면 평균이 바쁜 구간을 너무 많이 가려 버리는지였다. 기록 전체에서 1분마다 들어온 요청 수를 세어 보면 분포는 다음과 같다.

이 요청들을 평균 속도로 고르게 들어오는 흐름으로 바꾸면 가장 바쁜 구간이 사라진다. 그런데 비용 문제에서 가장 중요한 것이 바로 그 구간이다. 서비스가 들어오는 작업을 충분히 빨리 처리할 수 있는가, 아니면 요청이 기다려야 하는가. 도착 건수만으로는 Azure에 대기열이 생겼는지, GPU가 몇 대 필요했는지 알 수 없다.

내가 계속 되돌아가는 트레이드오프는 대기를 어디까지 받아들일 것인가다. 가장 바쁜 구간에 맞춰 용량을 확보하면 그 뒤에는 이미 비용을 치른 컴퓨터가 놀 수 있다. 요청을 기다리게 하면 용량은 덜 필요할 수 있지만, 그 지연을 제품이 감당할 수 있을 때만 그렇다. 용량을 얼마나 빨리 바꿀 수 있는지, 서비스가 어떤 응답 시간을 약속하는지 모르면 도착 패턴을 비용 추정으로 바꿀 수 없다.

입력과 출력 길이

도착 시점을 보고 나니 다른 질문이 생겼다. 들어오는 요청마다 요구하는 작업량은 비슷할까? 모델에 보낸 텍스트와 모델이 생성한 텍스트를 나눠서 보았다. 주어진 문맥을 처리하는 일과 답을 생성하는 일은 성격이 다른 작업이기 때문이다.

전형적인 요청 하나를 반복하는 식으로 용량을 추정하면, 이 기록에 있는 긴 요청을 서비스가 어떻게 처리하는지 놓치게 된다. 토큰 생성 몇 단계로 끝나는 답이 있는가 하면 훨씬 많은 단계가 필요한 답도 있다. 입력 길이가 다르면 생성이 시작되기 전의 문맥 처리량도 달라진다. 서비스를 비교할 때 쓰는 워크로드에는 이런 차이가 그대로 들어가야 한다.

다만 입력·출력 길이를 연산량이나 전력 사용량으로 곧바로 바꿀 수는 없다. 각 단계에 드는 작업량은 모델과 서빙 구성에 따라 달라지기 때문이다. 이 결과를 128K 문맥이나 오래 실행되는 에이전트로 넓혀 적용할 수도 없다. 이 기록에서 가장 긴 입력은 7,743토큰이다.

추론 서비스 비교

요청의 시점과 길이를 살펴본 뒤에도 어느 서비스가 더 쌀지는 여전히 모른다. 손에 남은 것은 비교에 쓸 워크로드다. 빠진 근거는 각 후보가 같은 응답 시간 요건 아래에서 이 작업을 어떻게 처리하는지, 그리고 그렇게 하는 데 비용이 얼마나 드는지다.

공개된 처리량 수치로는 이 빈자리를 채울 수 없다. 이 MLPerf 서버 결과는 해당 모델, 하드웨어 구성, 지연 목표에서 유효한 결과다. 같은 구성이 이번 Azure 기록의 도착 패턴과 요청 길이에서 어떤 성능을 낼지는 알려 주지 않는다.

실제로 쓸 수 있는 비교라면 모든 후보가 같은 요청을 같은 모델과 같은 답변 품질 목표로 처리해야 한다. 첫 응답이 얼마나 빨리 나와야 하는지, 나머지 답이 얼마나 빨리 이어져야 하는지, 실패한 요청은 어떻게 처리하는지도 정해 두어야 한다. 그렇지 않으면 더 느리거나 덜 안정적인 서비스를 같은 서비스의 저렴한 버전으로 착각할 수 있다.

내가 이해하려는 비용에는 요청이 몰리는 동안 벌어지는 일과, 그 뒤에도 비용을 계속 내야 하는 자원이 모두 들어간다. 요청을 그대로 재생하는 시험을 하면 응답 시간 요건을 충족한 요청이 얼마나 되는지, 바쁜 구간에 추가 용량이 얼마나 필요한지 측정할 수 있다. 그다음에는 구매 조건에 따라 유휴 자원, 실패, 재시도 가운데 무엇이 실제로 청구됐는지 확인할 것이다. 이 기록에는 이런 결과가 없다.

무엇을 구매하는지도 분명히 구분해야 한다. 토큰 단위로 과금하는 API라면 도착 패턴이 달라도 토큰 수가 같으면 청구액도 같을 수 있다. 그렇다면 속도 제한, 지연, 재시도는 비교에서 따로 따져야 한다. 예약 용량이나 자체 서버라면 비용을 낸 자원이 쓰이지 않는 시간이 비용에 더 직접적인 영향을 준다.

아직 측정해야 할 것

후보 하드웨어에서 이 워크로드를 재생하거나 청구서를 비교하지는 않았다. 그러니 가장 저렴한 GPU를 꼽거나 몇 퍼센트를 아낄 수 있다고 말할 수 없다. 내가 확인할 수 있는 것은, 평균적인 요청이 평균 속도로 도착한다고 놓고 만든 비교는 내가 들여다보려던 바로 그 변동을 지워 버린다는 점이다.

다음 단계는 실제 요청 순서를 공통 서비스 요건 아래에서 재생하는 것이다. 그래야 요구 응답 시간을 충족하는 구성끼리 청구액을 비교하고, 다른 기간의 워크로드에서도 그 선택이 유지되는지 확인할 수 있다. 공개된 토큰 가격과 함께 보고 싶은 근거가 바로 이것이다.

데이터: Microsoft가 공개한 코드 추론 기록 전체. 요청 16,803,695건, 2024년 5월 10~16일, 10,080분, UTC 기준, 약 692MB. 결측값이나 음수 토큰 수는 없다. 청구액, 하드웨어 구성, 답변 품질, 실제 응답 지연은 들어 있지 않다. AI 도구가 코드 작성과 원고 준비를 보조했으며, 수치는 원본 파일에서 계산했다.

데이터셋 출처: Jovan Stojkovic, Chaojie Zhang, Íñigo Goiri, Josep Torrellas, Esha Choukse, DynamoLLM: Designing LLM Inference Clusters for Performance and Energy Efficiency, HPCA 2025.