OpenRouter, 제공업체 라우팅 알고리즘 개편

OpenRouter는 2026년 10월 28일, 회사 창립 이후 가장 큰 제공업체 라우팅 알고리즘 개선을 발표했습니다. 새 기본 라우터는 주로 입력 토큰 가격으로 요청을 배정하던 방식에서 벗어나 실효 가격, 응답 속도, 처리량, 신뢰도와 응답 품질을 반영합니다. OpenRouter는 사용자가 코드를 바꾸지 않아도 새 라우터를 이용할 수 있다고 밝혔습니다. 시험에서 중앙값 첫 토큰까지 시간은 16.9% 줄고 처리량은 16.3% 늘었으며, 용량 오류는 67% 감소했습니다. 반면 요청 1,000건당 비용은 6.0% 상승했습니다.

OpenRouter 요청의 약 77%는 여러 제공업체가 제공하는 모델로 향합니다. 기존 방식에서는 가격이 낮은 제공업체가 더 많은 트래픽을 받고, 요청이 실패하면 다음으로 저렴한 곳으로 이동했습니다. OpenRouter에 따르면 이 방식은 사용자가 실패를 기다리게 하고, 실시간 성능 변화를 놓치며, 인프라 투자보다 가격 인하에 보상하는 문제가 있었습니다. 제공업체는 입력 토큰 가격을 낮춘 뒤 캐시 토큰이나 완성 토큰에 더 높은 요금을 부과해 이를 상쇄할 수도 있었습니다.

새 라우터는 최근 모델 트래픽을 바탕으로 입력·출력 토큰 사용량을 추정하고, 캐시 적중과 평균 입력·출력 구성 등 실제 트래픽을 반영해 제공업체별 실효 가격을 계산합니다. 또한 전체 응답에서 초당 출력 토큰 수로 측정한 처리량과 스트리밍이 시작되기까지의 첫 토큰까지 시간(TTFT)을 점수화합니다. 속도 제한과 제공업체가 일으킨 실패에는 감점이 적용됩니다. 요청 실패는 시간을 쓰고 재시도를 요구할 수 있기 때문입니다. 라우터는 도구 호출이 올바른 형식인지 등 응답을 사용할 수 있는지도 점검합니다. 도구 호출이 깨졌거나 벤치마크 정확도가 해당 모델의 예상 점수보다 크게 낮다고 표시된 제공업체에는 표시가 해제될 때까지 소량의 시험 트래픽만 보냅니다.

라우터 순위 상위권에 가까운 제공업체끼리 트래픽을 나누며, 경쟁 우위에서 멀어질수록 배정량은 빠르게 줄어듭니다. 안전장치는 모든 제공업체에 소량의 요청을 계속 보내고, 실패하거나 속도 제한에 걸리는 곳의 트래픽을 낮추며, HTTP 429 오류를 내기 전까지 각 제공업체가 감당할 수 있는 부하를 넘지 않도록 제한합니다. 새 엔드포인트에는 해당 모델의 일반적인 수치가 적용됩니다. 대화는 프롬프트 캐시가 유지되는 동안 처음 선택한 제공업체를 계속 사용하지만, 해당 제공업체를 이용할 수 없게 되면 다른 곳으로 전환될 수 있습니다. 실패한 요청은 다음 순위 제공업체로 재시도됩니다. 명시적인 provider.order, provider.sort 및 일부 제공업체 필터 설정은 새 라우팅 적용 여부에 영향을 줍니다.

OpenRouter는 대표적인 오픈소스 모델 표본을 대상으로 1주일간 전환형 실험을 진행했습니다. 기존 라우터와 새 라우터를 짝을 맞춘 3시간 구간마다 번갈아 적용하고, 전환 뒤 1시간의 데이터는 제외했습니다. 두 시스템에는 입력 토큰 1,030억 개가 담긴 2,400만 건 이상의 요청이 나뉘어 배정됐습니다. 중앙값 첫 토큰까지 시간은 1,007ms에서 837ms로, 95백분위 시간은 4,601ms에서 3,733ms로 줄었습니다. 중앙값 처리량은 초당 62.4토큰에서 72.6토큰으로 올랐습니다. 전체 요청 시간의 중앙값은 4.00초에서 3.24초로, 95백분위는 41.5초에서 34.9초로 감소했습니다. HTTP 429 오류를 한 번 이상 겪은 요청은 7.1%에서 3.8%로 줄어 67% 감소로 보고됐고, 재시도가 필요했던 요청은 10.4%에서 6.9%로 줄어 47% 감소했습니다.

실험에서는 요청 1,000건당 비용이 1.25달러에서 1.32달러로 6.0% 올랐고, 토큰 100만 개당 비용은 0.301달러에서 0.324달러로 7.3% 상승했습니다. 실패한 시도에 쓴 시간은 요청당 349ms에서 242ms로 줄어 55% 감소한 것으로 보고됐습니다. 가격만 기준으로 라우팅하려는 사용자는 가격순 정렬을 선택하거나 모델 슬러그에 :floor를 붙이고, 계정 설정에서 기본값을 바꿀 수 있습니다. 사용자는 제공업체 순서를 지정하거나 대상 제공업체를 제한할 수도 있습니다.

OpenRouter는 2026년 10월 28일, 회사 창립 이후 가장 큰 제공업체 라우팅 알고리즘 개선을 발표했습니다. 새 기본 라우터는 주로 입력 토큰 가격으로 요청을 배정하던 방식에서 벗어나 실효 가격, 응답 속도, 처리량, 신뢰도와 응답 품질을 반영합니다. OpenRouter는 사용자가 코드를 바꾸지 않아도 새 라우터를 이용할 수 있다고 밝혔습니다. 시험에서 중앙값 첫 토큰까지 시간은 16.9% 줄고 처리량은 16.3% 늘었으며, 용량 오류는 67% 감소했습니다. 반면 요청 1,000건당 비용은 6.0% 상승했습니다.

OpenRouter 요청의 약 77%는 여러 제공업체가 제공하는 모델로 향합니다. 기존 방식에서는 가격이 낮은 제공업체가 더 많은 트래픽을 받고, 요청이 실패하면 다음으로 저렴한 곳으로 이동했습니다. OpenRouter에 따르면 이 방식은 사용자가 실패를 기다리게 하고, 실시간 성능 변화를 놓치며, 인프라 투자보다 가격 인하에 보상하는 문제가 있었습니다. 제공업체는 입력 토큰 가격을 낮춘 뒤 캐시 토큰이나 완성 토큰에 더 높은 요금을 부과해 이를 상쇄할 수도 있었습니다.

새 라우터는 최근 모델 트래픽을 바탕으로 입력·출력 토큰 사용량을 추정하고, 캐시 적중과 평균 입력·출력 구성 등 실제 트래픽을 반영해 제공업체별 실효 가격을 계산합니다. 또한 전체 응답에서 초당 출력 토큰 수로 측정한 처리량과 스트리밍이 시작되기까지의 첫 토큰까지 시간(TTFT)을 점수화합니다. 속도 제한과 제공업체가 일으킨 실패에는 감점이 적용됩니다. 요청 실패는 시간을 쓰고 재시도를 요구할 수 있기 때문입니다. 라우터는 도구 호출이 올바른 형식인지 등 응답을 사용할 수 있는지도 점검합니다. 도구 호출이 깨졌거나 벤치마크 정확도가 해당 모델의 예상 점수보다 크게 낮다고 표시된 제공업체에는 표시가 해제될 때까지 소량의 시험 트래픽만 보냅니다.

라우터 순위 상위권에 가까운 제공업체끼리 트래픽을 나누며, 경쟁 우위에서 멀어질수록 배정량은 빠르게 줄어듭니다. 안전장치는 모든 제공업체에 소량의 요청을 계속 보내고, 실패하거나 속도 제한에 걸리는 곳의 트래픽을 낮추며, HTTP 429 오류를 내기 전까지 각 제공업체가 감당할 수 있는 부하를 넘지 않도록 제한합니다. 새 엔드포인트에는 해당 모델의 일반적인 수치가 적용됩니다. 대화는 프롬프트 캐시가 유지되는 동안 처음 선택한 제공업체를 계속 사용하지만, 해당 제공업체를 이용할 수 없게 되면 다른 곳으로 전환될 수 있습니다. 실패한 요청은 다음 순위 제공업체로 재시도됩니다. 명시적인 provider.order, provider.sort 및 일부 제공업체 필터 설정은 새 라우팅 적용 여부에 영향을 줍니다.

OpenRouter는 대표적인 오픈소스 모델 표본을 대상으로 1주일간 전환형 실험을 진행했습니다. 기존 라우터와 새 라우터를 짝을 맞춘 3시간 구간마다 번갈아 적용하고, 전환 뒤 1시간의 데이터는 제외했습니다. 두 시스템에는 입력 토큰 1,030억 개가 담긴 2,400만 건 이상의 요청이 나뉘어 배정됐습니다. 중앙값 첫 토큰까지 시간은 1,007ms에서 837ms로, 95백분위 시간은 4,601ms에서 3,733ms로 줄었습니다. 중앙값 처리량은 초당 62.4토큰에서 72.6토큰으로 올랐습니다. 전체 요청 시간의 중앙값은 4.00초에서 3.24초로, 95백분위는 41.5초에서 34.9초로 감소했습니다. HTTP 429 오류를 한 번 이상 겪은 요청은 7.1%에서 3.8%로 줄어 67% 감소로 보고됐고, 재시도가 필요했던 요청은 10.4%에서 6.9%로 줄어 47% 감소했습니다.

실험에서는 요청 1,000건당 비용이 1.25달러에서 1.32달러로 6.0% 올랐고, 토큰 100만 개당 비용은 0.301달러에서 0.324달러로 7.3% 상승했습니다. 실패한 시도에 쓴 시간은 요청당 349ms에서 242ms로 줄어 55% 감소한 것으로 보고됐습니다. 가격만 기준으로 라우팅하려는 사용자는 가격순 정렬을 선택하거나 모델 슬러그에 :floor를 붙이고, 계정 설정에서 기본값을 바꿀 수 있습니다. 사용자는 제공업체 순서를 지정하거나 대상 제공업체를 제한할 수도 있습니다.