AIREITEROpenRouter가 2026년 10월 28일 기본 라우터를 전면 개편했습니다. 첫 토큰까지 걸리는 시간은 16.9% 줄었고, 429 오류 이벤트는 전체적으로 67% 감소했습니다. 대신 요청 비용은 약 6% 올랐습니다. 자동 라우팅이 더 비싼 프로바이더로 조용히 요청을 옮길 수 있는 만큼, 이번 변화는 성능 개선만 보고 판단하기보다 비용과 안정성의 교환 관계를 함께 봐야 합니다.
OpenRouter의 새 라우터는 더 이상 입력 토큰 단가만 보고 가장 싼 프로바이더를 고르지 않습니다. 실제로 좋은 응답 하나를 받는 데 드는 비용을 추정합니다. 여기에는 가격뿐 아니라 대기 시간과 재시도 비용까지 포함됩니다. 그런 다음 Routing Cost가 가장 낮은 프로바이더로 요청을 보냅니다.
30초 결론: 수치로 확인한 변화
이제 OpenRouter 프로바이더 라우팅은 프롬프트 토큰 가격이 아니라 Routing Cost를 최적화합니다. 명시적인 provider.sort, provider.order, provider.only, provider.ignore 설정이 없는 요청에 자동 적용되며, OpenRouter 발표에 따르면 둘 이상의 프로바이더가 제공하는 모델로 향하는 트래픽 약 77%가 대상입니다.
결과는 1주일 동안 진행한 스위치백 테스트에서 나왔습니다. 총 2,400만 건의 요청과 1,030억 개의 입력 토큰을 대상으로 했고, 기존 라우터와 새 라우터에 트래픽을 동일하게 나눴습니다.
| 측정 항목 | 기존 라우터 | 새 라우터 | 변화* |
|---|---|---|---|
| TTFT p50 | 1,007 ms | 837 ms | 16.9% 감소 |
| 처리량 p50 | 62.4 tok/s | 72.6 tok/s | 16.3% 증가 |
| 한 번 이상 429를 만난 요청 | 7.1% | 3.8% | 3.3%p 감소; 429 이벤트 전체 67% 감소 |
| 재시도가 필요했던 요청 | 10.4% | 6.9% | 3.5%p 감소; 재시도 전체 47% 감소 |
| 요청 1,000건당 비용 | $1.25 | $1.32 | 6.0% 증가 |
| 토큰 100만 개당 비용 | $0.301 | $0.324 | 7.3% 증가 |
\* 요청 비중과 이벤트 감소율은 모두 공식 발표에 기재된 수치입니다. 여기서 67%와 47%는 각각 전체 429 이벤트와 전체 재시도 횟수의 감소율입니다. 한 요청에서 여러 오류가 발생할 수 있으므로, 단순히 오류를 경험한 요청 비율만 비교한 값은 아닙니다.
공식 발표 기준으로 호출자가 측정한 TTFT p95는 6,032 ms에서 4,504 ms로 줄었습니다. 전체 요청의 p50도 4.00초에서 3.24초로 단축됐고, 실패한 시도에 낭비된 시간은 요청당 349 ms에서 242 ms로 감소했습니다.
결론은 간단합니다. 대화형 채팅이나 에이전트처럼 지연 시간이 중요한 경우 약 6%의 비용 증가를 감수할 수 있다면 새 기본값을 유지하는 편이 좋습니다. 반대로 모든 비용을 아껴야 하는 대규모 배치 작업이라면 가격만 보는 라우팅으로 되돌리는 편이 낫습니다.
Routing Cost를 쉽게 이해하기
Routing Cost는 프로바이더마다 두 가지를 묻습니다. 한 번 시도하는 데 얼마가 드는지, 그리고 그 시도가 실제로 성공하는 비율이 얼마인지입니다. OpenRouter가 든 예시를 보면, 시도 비용 $0.40에 대기 비용 $0.60을 더한 $1.00을 성공 확률 80%로 나눠 좋은 답변 하나당 $1.25가 됩니다. 이 값이 낮은 프로바이더에 더 많은 트래픽이 배정됩니다.
이 수치는 세 가지 요소로 계산됩니다.
- 표시 가격이 아닌 실제 가격. OpenRouter는 최근 트래픽을 바탕으로 입력·출력 토큰 수를 추정하고, 프로바이더별 실제 캐시 적중률과 토큰 가격을 적용합니다. 공식 발표의 계산 예시는 다음과 같습니다. 캐시되지 않은 입력 4만 개는 $2.00/M으로 $0.080, 캐시된 입력 6만 개는 $0.50/M으로 $0.030, 출력 약 4,000개는 $8.00/M으로 $0.032가 들어 총 $0.142입니다. 입력 단가가 싸더라도 캐시 입력이나 출력 토큰 가격이 비싸면 이 계산에서는 유리하지 않습니다.
- 대기 시간의 비용 환산. 처리량은 첫 토큰까지 걸린 시간까지 포함한 전체 출력 토큰/초입니다. 예를 들어 첫 토큰까지 5초가 걸리고 이후 5초 동안 500토큰을 생성했다면 50 tok/s입니다. 라우터는 일반적인 프로바이더 요금과 속도를 바탕으로 모델별 환산율을 적용해 대기 시간을 비용으로 바꿉니다. 에이전트의 도구 호출 체인은 매 단계마다 첫 토큰을 기다리므로 TTFT에 더 큰 가중치가 부여됩니다.
- 실패에 따른 비용. 429는 프로바이더가 요청을 거절했다는 뜻입니다. 거절될 때까지 기다린 뒤 다른 곳으로 다시 보내야 합니다. 예를 들어 2.50의 대기 비용에 0.4% 오류율을 곱한 패널티가 더해져 0.01이 추가됩니다. 안정성 오류에는 약 8배 더 큰 패널티가 적용됩니다. 오류율이 1%면 비용이 약 8% 올라가는 식입니다. 다른 프로바이더보다 훨씬 불안정한 곳은 회복될 때까지 트래픽을 거의 받지 않습니다. 현재 품질 평가는 형식이 올바른 도구 호출도 확인합니다. 도구 호출 정상률이 95%라면 비용이 약 5% 올라가며, 문제가 감지된 프로바이더는 테스트 수준의 트래픽만 받습니다. 이는 공식 발표 기준입니다.
한 곳으로 트래픽이 쏠리는 것을 막는 안전장치도 있습니다. 공식 발표에 따르면 모든 프로바이더에 소량의 트래픽을 계속 보내 회복 여부를 확인하고, 실패하는 프로바이더에는 전송량을 줄입니다. 동시에 프로바이더별 처리 용량 상한을 학습해 초과분은 다른 곳으로 분산합니다.
기본 라우팅이 운영 환경에서 여전히 문제를 일으키는 이유
사용자 제보를 보면 토큰 단가만으로는 잡히지 않는 문제가 반복해서 나타납니다. 대표적인 패턴은 네 가지입니다.
도구 호출 단계가 스키마를 망가뜨린다
저에게 도구 호출을 실제로 망가뜨린 건 특정 프로바이더의 가격표가 아니라, 요청 중간에 프로바이더가 바뀐 일이었습니다.
— u/Michael_Jeffords, 피해야 할 프로바이더에 관한 r/openrouter 스레드
현재 품질 점수는 주로 형식이 올바른 도구 호출과 벤치마크 정확도 플래그를 바탕으로 합니다. 이는 공식 발표에 설명된 내용입니다. 대화 중간에 프로바이더가 바뀌면 양자화 수준이나 거부 방식이 달라질 수 있습니다. 프로바이더마다 품질이 다르고, 일부는 더 강하게 양자화된 모델을 제공하기 때문입니다.
캐시가 풀리면 비용이 급증한다
한 스레드에는 약 70만 토큰 규모의 컨텍스트에서 캐시가 적용되면 $0.20 정도여야 할 요청이 프로바이더 변경 후 거의 $2.00로 청구됐다는 사례가 올라왔습니다. 이 문제는 "캐시가 망가져 10~32배 더 내는" 상황으로 이어집니다. 새 라우터는 캐시가 살아 있는 동안 대화를 처음 사용한 프로바이더에 고정하고, 알고리즘으로 프로바이더를 고르는 작업도 첫 요청에만 수행합니다. 이는 OpenRouter의 캐시 인식 라우팅 방식입니다. 다만 다른 프로바이더로 폴백하면 이 고정이 깨집니다. 이 문제를 해결한 사용자들은 하나의 프로바이더와 스티키 세션을 직접 지정했습니다.
이걸 미리 수동으로 설정해야 한다는 점은 OR의 꽤 근본적인 결함이라고 생각합니다.
— u/welcome_to_milliways, 캐시 문제에 관한 r/openrouter 스레드
비싼 폴백이 조용히 발생한다
한 운영 사례에서는 트래픽 일부가 별다른 알림 없이 Sonnet에서 Opus로 이동했습니다. 표시 가격은 약 5배 차이였고, 서비스 가동 상태는 정상으로 보였지만 전체 비용 소모량은 시간당 $184에서 $412로 뛰었습니다. 이 내용은 @CarbonOnX가 보고한 사례입니다. 새 라우터는 이런 선택을 명시적으로 드러냅니다. 가장 싼 프로바이더가 아니라 더 빠르고 안정적인 프로바이더가 선택되는 상황이 충분히 가능해진 것입니다.
유료 계정에서도 발생하는 429
OpenRouter에 잔액을 충전했다고 해서 업스트림 처리 용량이 늘어나는 것은 아닙니다. 이 429 관련 스레드의 사용자들도 같은 점을 지적합니다. 429는 해당 모델에 배정된 프로바이더의 공유 처리 풀 상태를 반영합니다. 이번 개편 테스트에서는 429 이벤트가 67% 줄었지만, 운영 환경에서 속도 제한이 발생하는 프로바이더를 고정하거나 제외하는 방법은 여전히 유효합니다. 먼저 OpenRouter 429 오류 해결 방법을 확인하고, 이전의 가격 가중치 기본값은 OpenRouter Auto Router 가이드에서 살펴보면 됩니다.
운영에서 쓸 만한 라우팅 설정 세 가지
손을 덜 대고 속도를 얻을지, 비용 상한을 지킬지, 결과를 결정적으로 고정할지에 따라 선택이 달라집니다. 세 설정 모두 같은 provider 객체를 사용합니다. provider.order는 새 로직을 건너뛰고 지정한 순서대로 프로바이더를 시도합니다. provider.only와 provider.ignore는 후보를 걸러낸 뒤 남은 프로바이더 사이에서 새 알고리즘이 선택하도록 합니다. 명시적인 provider.sort(price, throughput, latency)를 지정하면 새 기본 로직 대신 해당 기준을 사용합니다.
1. 새 기본값 유지하기: 대화형 채팅과 에이전트
코드를 바꿀 필요가 없습니다. 각 도구 호출이 첫 토큰을 기다리는 사용자용 채팅과 다단계 에이전트에 잘 맞습니다. 지연 시간과 재시도 감소를 위해 약 6%의 비용 증가를 받아들이는 방식입니다. API 응답과 활동 페이지에 반환되는 실제 프로바이더를 TTFT p50, 429 비율과 함께 1주일 동안 기록해 보세요. 429 비율이 새 기준선인 약 4%에 머물고 캐시 적중률도 유지된다면 그대로 사용하면 됩니다. 특정 프로바이더가 실패를 독점하거나 캐시 적중률이 무너지면 세 번째 설정으로 옮기는 편이 낫습니다.
2. 가장 싼 경로 고정하기: 배치 작업과 비용 제한 작업
속도보다 비용이 중요할 때 가격 기반 라우팅을 우선하는 방법은 세 가지입니다.
{ "provider": { "sort": "price" } }또는 모델 슬러그에 :floor를 붙입니다(meta-llama/llama-4-maverick:floor). 계정 설정에서 기본 정렬 기준을 price로 지정하는 방법도 있습니다. 이는 공식 발표 FAQ에 설명되어 있습니다. :floor는 일반적인 sort와 달리 flex-tier 엔드포인트도 허용한다는 점에 유의하세요. 자세한 내용은 OpenRouter 라우팅 가이드에 나와 있습니다.
비용 상한도 함께 설정할 수 있습니다.
{ "provider": { "sort": "price", "max_price": { "prompt": 1.0, "completion": 2.0 } } }긴 프롬프트, 짧은 출력, 저렴한 재시도가 필요한 작업에 적합합니다.
3. 안정적인 프로바이더 고정하기: 캐시나 도구 호출을 사용하는 운영 환경
요청마다 최적화하는 것보다 정확성, 캐시 적중률, 규정 준수가 중요하다면 프로바이더를 고정하세요.
{
"provider": {
"order": ["deepinfra", "together"],
"allow_fallbacks": true,
"require_parameters": true
}
}require_parameters는 필요한 요청 파라미터가 없는 엔드포인트를 피할 뿐입니다. 프로바이더가 달라져도 도구 호출이나 스키마 동작이 같다고 보장하지는 않습니다. 규정 준수나 BYOK 환경에서 승인되지 않은 프로바이더를 사용하는 것보다 장애를 감수하는 편이 나을 때만 allow_fallbacks: false와 함께 order를 사용하세요. 대부분의 앱에서는 폴백을 허용하고, only/ignore로 후보를 좁힌 뒤, 따뜻한 캐시를 재사용할 수 있도록 안정적인 session_id를 전달하는 편이 좋습니다(스티키 라우팅). 특정 프로바이더가 불안정하다면 가드레일에서 차단하고 직접 프로바이더 API도 비교해 보세요. 여러 사용자가 모델을 정한 뒤 직접 연결하자 느려짐과 캐시 문제가 사라졌다고 보고했습니다(사례 스레드).
| 상황 | 추천 설정 | 이유 |
|---|---|---|
| 프로토타이핑, 트래픽이 섞인 경우 | 새 기본값, 별도 설정 없음 | 테스트에서 재시도 감소 |
| 사용자용 에이전트 | 새 기본값 + require_parameters | TTFT 개선은 유지하고 호환되지 않는 엔드포인트는 제외 |
| 야간 배치, 토큰 100M 이상 | sort: price 또는 :floor + max_price | 6~7%의 추가 비용을 줄일 수 있음 |
| 캐시를 사용하는 긴 컨텍스트 | 고정된 order + session_id | 캐시 미스에 따른 재가격 책정 방지 |
자동 라우팅은 이전보다 좋아졌습니다. 하지만 나쁜 프로바이더 전환 한 번으로 입는 손해가 토큰 단가가 조금 더 높은 상태로 일주일 운영하는 비용보다 크다면, 여전히 프로바이더를 직접 고정해야 합니다.
FAQ
새 라우팅을 사용하려면 코드를 바꿔야 하나요?
아니요. 명시적인 provider sort, order, only, ignore가 없는 요청에는 새 라우터가 자동으로 적용됩니다.
가격만 보는 라우팅을 유지하려면 어떻게 하나요?
provider.sort를 "price"로 지정하거나 :floor를 추가하세요. 계정 기본 정렬 기준을 price로 설정해도 됩니다.
새 라우팅이 내가 지정한 프로바이더 순서를 무시하나요?
아니요. order는 새 라우팅을 우회합니다. only/ignore는 먼저 후보를 걸러내고, 그다음 새 알고리즘이 남은 후보 중에서 선택합니다.
새 라우팅을 사용하면 비용이 더 드나요?
위의 결론 표를 확인하세요. 테스트에서 요청 1,000건당 6.0%, 토큰 100만 개당 7.3% 비용이 증가했습니다.
내 요청을 실제로 처리한 프로바이더는 어떻게 확인하나요?
OpenRouter 문서에 따르면 API 응답의 provider 필드와 활동 페이지에서 확인할 수 있습니다.
유료 계정인데도 왜 429가 발생하나요?
잔액 문제가 아니라 업스트림의 공유 처리 풀 제한 때문입니다. 속도 제한이 걸린 프로바이더를 고정하거나 제외하세요.