토큰 처리 속도와 단위 가격이 실제 작업 완료 시간과 비용을 예측하지 못한 사례 공유

커뮤니티는 대체로 사양표만으로 결정하는 관행에 의문을 표하고 실제 프롬프트로 벽시계 기반 측정을 수행하라는 반응을 보였으며 일부는 라우팅 변동을 줄이기 위해 공급자 핀 고정을 권했다. 경험을 공유한 댓글들은 특정 모델이 빠른 토큰 속도를 보였어도 생성 토큰 수가 늘어나면 실사용 비용과 지연이 증가한다고 일치되게 보고했다. 반면에 공급자 핀 고정의 운영 비용과 관리 복잡도를 문제 삼는 반응도 있어 접근 방식에 대한 논의가 분화되었다.

• 자신의 프롬프트와 동일한 작업을 대상으로 wall-clock 기준으로 소규모 프로브를 실행해 모델별 생성 토큰 수와 완료 시간을 직접 측정하라.
• 비용 예측은 백만 토큰당 가격과 함께 모델별 평균 생성 토큰 수를 곱해 산정하되 실제 네트워크·라우팅 영향을 반영하기 위해 공급자별 재측정을 병행하라.
• OpenRouter 등에서 라우팅 변동이 문제라면 특정 공급자에 핀을 고정해 재현성을 확보하는 방안을 시범 적용하되 핀 고정이 장애·비용·운영 복잡도를 어떻게 바꾸는지 모니터링하라.

Tokens per second

— 모델이 초당 생성하거나 처리하는 토큰 수를 의미하며 입력 토큰과 출력 토큰을 합친 처리량 지표로 사용된다. 이 값은 모델의 처리 효율과 연산 자원 사용량을 대략적으로 알려주지만 동일 작업에서 생성되는 총 토큰 수가 달라지면 실제 작업 시간이나 비용과는 불일치가 발생할 수 있다. 따라서 wall-clock 기반의 응답 시간과 결합해 평가해야 실제 사용자 경험을 예측할 수 있다.

Price per Mtok

— API 공급자가 제시하는 백만 토큰 처리 기준 가격으로, 토큰 생성량에 비례한 비용 추정을 위해 자주 사용된다. 이 단위는 동일한 토큰 수를 생성할 때의 비용 비교에는 유용하지만 각 모델이 같은 입력에서 생성하는 토큰 수가 다르면 실제 과제 비용과 괴리가 발생한다. 따라서 비용 예측에는 모델별 토큰 사용량과 wall-clock 시간 분석이 병행되어야 한다.

Wall-clock time

— 사용자가 체감하는 실제 경과 시간으로, 요청 시작부터 응답 완료까지 걸린 총 시간을 의미한다. 모델의 토큰 처리 속도, 네트워크 대기, 라우팅으로 인한 공급자 차이 등 모든 요인이 합쳐져 결정되며 작업 완료 시간과 비용을 직접적으로 나타내는 지표이다. 벤치마크에서는 단순 처리량 수치 대신 wall-clock 기반 측정이 실제 성능 판단에 더 유의미하다.

Provider routing

— 요청을 어느 호스트나 서비스 공급자에 보낼지를 결정하는 과정으로, 라우팅 정책에 따라 동일 모델 요청이 서로 다른 인프라에서 실행될 수 있다. 라우팅은 각 공급자의 하드웨어 특성과 현재 부하에 따라 토큰 처리 속도와 응답 지연을 크게 바꿀 수 있어 일관된 성능을 확보하려면 핀 고정(pin)이나 공급자별 재측정이 필요하다. 라우팅 변동성은 실사용 시 지연과 비용 예측을 어렵게 만드는 주요 원인이다.