이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
작성자는 동일한 코딩 과제를 13개 모델에서 각기 6회씩 벽시계 시간으로 측정한 소규모 probe를 공유하면서 초당 토큰 수와 백만 토큰당 가격이 작업 완료 시간과 비용을 일관되게 예측하지 못했다고 보고했다. 구체적으로 KAT-Coder는 113 tok/s로 상대적으로 빠른 처리율을 보였지만 5,536개의 토큰을 생성해 동일 과제에서 완료 순위가 뒤로 밀렸고 GPT-5.5는 1,777 토큰으로 더 적게 생성해 비용과 시간이 달라졌다. 또한 Kimi K2.7의 Together 대비 DeepInfra 처리속도 차이(223 tok/s 대 28 tok/s)와 GLM-5.2의 실행 공급자 분산 사례는 프로바이더 라우팅이 성능 변동을 증폭함을 보여주며 작성자는 n=3의 probe라는 한계를 명시했고 비용이 3달러 미만이라 누구나 자신의 프롬프트로 재확인할 수 있다고 제안했다.
실용적 조언
- 자신의 프롬프트와 동일한 작업을 대상으로 wall-clock 기준으로 소규모 프로브를 실행해 모델별 생성 토큰 수와 완료 시간을 직접 측정하라.
- 비용 예측은 백만 토큰당 가격과 함께 모델별 평균 생성 토큰 수를 곱해 산정하되 실제 네트워크·라우팅 영향을 반영하기 위해 공급자별 재측정을 병행하라.
- OpenRouter 등에서 라우팅 변동이 문제라면 특정 공급자에 핀을 고정해 재현성을 확보하는 방안을 시범 적용하되 핀 고정이 장애·비용·운영 복잡도를 어떻게 바꾸는지 모니터링하라.
섹션별 상세
동일한 코딩 과제를 대상으로 13개 모델을 각기 6회씩 실행하고 벽시계 시간을 측정한 실측 방식에서 토큰 처리 속도와 실제 작업 시간 사이의 괴리가 드러났다. 예를 들어 KAT-Coder는 113 tok/s로 집계되어 집합 내에서 세 번째로 빠른 처리량이었지만 동일 과제에서 5,536 토큰을 생성해 토큰을 적게 생성한 모델들보다 완료가 늦어 전체 순위에서는 열 번째로 밀렸다. 이 사례는 초당 토큰 수와 백만 토큰당 가격 같은 사양표 지표만으로는 단일 과제의 총 소요 시간이나 비용을 예측할 수 없다는 근거가 된다.
프로바이더 라우팅이 성능 변동을 증폭시키는 기제로 관찰되었으며 공급자별 차이가 초당 처리속도와 최종 소요 시간에 큰 영향을 미쳤다. Kimi K2.7은 Together에서 측정한 223 tok/s와 DeepInfra에서 측정한 28 tok/s로 동일 모델이라도 실행 호스트에 따라 처리속도가 수배 차이로 달라졌고 GLM-5.2는 여섯 번의 실행에서 여섯 개의 서로 다른 공급자에 배치되어 일관된 퍼포먼스를 보이지 않았다. 라우팅에 의해 결정되는 실행 노드의 하드웨어·부하·네트워크 특성이 결과적으로 초 단위 완료시간과 비용을 뒤바꾸는 주요 원인으로 작동했다.
재현성과 실무적 의사결정 관점에서 이 결과는 소규모 프로브의 가치와 핀 고정(pin) 전략의 필요성을 시사한다는 점이 논의 포인트로 제시되었다. 작성자는 직접 측정한 값이 아니라 n=3 크기의 probe 결과임을 명시했고 비용은 두 경우 모두 3달러 미만이라 충분히 자신이 사용하는 프롬프트로 재실행해볼 수 있다고 알렸다. 이 점은 엔지니어들이 사양표가 아닌 자신의 프롬프트·환경으로 스몰 샘플을 돌려 wall-clock 기준으로 모델과 공급자를 비교해야 함을 의미한다.
용어 해설
- 초당 토큰 수(Tokens per second)
- — 모델이 초당 생성하거나 처리하는 토큰 수를 의미하며 입력 토큰과 출력 토큰을 합친 처리량 지표로 사용된다. 이 값은 모델의 처리 효율과 연산 자원 사용량을 대략적으로 알려주지만 동일 작업에서 생성되는 총 토큰 수가 달라지면 실제 작업 시간이나 비용과는 불일치가 발생할 수 있다. 따라서 wall-clock 기반의 응답 시간과 결합해 평가해야 실제 사용자 경험을 예측할 수 있다.
- 백만 토큰당 가격(Price per Mtok)
- — API 공급자가 제시하는 백만 토큰 처리 기준 가격으로, 토큰 생성량에 비례한 비용 추정을 위해 자주 사용된다. 이 단위는 동일한 토큰 수를 생성할 때의 비용 비교에는 유용하지만 각 모델이 같은 입력에서 생성하는 토큰 수가 다르면 실제 과제 비용과 괴리가 발생한다. 따라서 비용 예측에는 모델별 토큰 사용량과 wall-clock 시간 분석이 병행되어야 한다.
- 벽시계 시간(Wall-clock time)
- — 사용자가 체감하는 실제 경과 시간으로, 요청 시작부터 응답 완료까지 걸린 총 시간을 의미한다. 모델의 토큰 처리 속도, 네트워크 대기, 라우팅으로 인한 공급자 차이 등 모든 요인이 합쳐져 결정되며 작업 완료 시간과 비용을 직접적으로 나타내는 지표이다. 벤치마크에서는 단순 처리량 수치 대신 wall-clock 기반 측정이 실제 성능 판단에 더 유의미하다.
- 프로바이더 라우팅(Provider routing)
- — 요청을 어느 호스트나 서비스 공급자에 보낼지를 결정하는 과정으로, 라우팅 정책에 따라 동일 모델 요청이 서로 다른 인프라에서 실행될 수 있다. 라우팅은 각 공급자의 하드웨어 특성과 현재 부하에 따라 토큰 처리 속도와 응답 지연을 크게 바꿀 수 있어 일관된 성능을 확보하려면 핀 고정(pin)이나 공급자별 재측정이 필요하다. 라우팅 변동성은 실사용 시 지연과 비용 예측을 어렵게 만드는 주요 원인이다.
언급된 도구
OpenRouter중립
다중 공급자 라우팅 및 API 프록시 역할을 수행하는 라우팅 도구
Together중립
모델 호스팅 공급자 중 하나로서 요청 처리 환경을 제공하는 서비스
DeepInfra중립
다른 모델 호스팅 공급자로서 실행 노드 특성에 따라 처리속도가 달라질 수 있는 환경을 제공
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 07. 23.수집 2026. 07. 23.출처 타입 REDDIT
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
