같은 모델 이름이 같은 동작을 보장하지 않는다 - OpenRouter의 제공업체별 실행 계약

TL;DR

• 같은 가중치라도 제공업체의 실행 환경과 파서에 따라 도구 호출과 응답 품질이 달라질 수 있다.
• HTTP 200만으로 작업 성공을 판단하지 않는다. 빈 응답, 구조화된 도구 호출, 다음 턴의 이력 처리를 별도로 검증한다.
• 제공업체 제한은 재현성을 높이지만 장애 대체 경로를 줄인다. 허용한 업체마다 실제 운영 환경에서 같은 검사를 수행해야 한다.

Source

So you want to use OpenRouter?

OpenRouter 공식 문서 — Provider Routing

OpenRouter 공식 문서 — Reasoning Tokens

Knowledge

모델 선택 뒤에도 실행 환경 선택이 남는다

Mo Moustafa의 Olly 운영 사례는 모델의 가중치와 그것을 서비스하는 업체를 구분한다. 제공업체마다 정밀도와 실행 최적화, 도구 호출 파서가 다르다. 같은 모델 이름으로 보낸 요청도 이미지 인식이나 도구 실행에서 다른 결과를 낼 수 있다. 글에 포함된 업체별 평가와 이미지 검사는 이런 차이를 보여주는 시점별 관찰이며 현재의 모든 요청에서 같은 차이가 난다는 보장은 아니다.

정밀도 표기만으로 업체를 고르는 방법에도 한계가 있다. 원문의 비교에서 낮은 비트 수가 항상 낮은 평가 점수로 이어지지는 않았다. 추론 강도 설정을 받아들이면서 실제 동작에는 충분히 반영하지 않는 경우도 관찰됐다. 이 사례의 실무적 의미는 업체 이름과 요청 옵션을 함께 기록하는 데 있다. 모델을 바꾸지 않았다는 사실만으로 실행 조건까지 유지됐다고 판단하면 품질 변화의 원인을 놓친다.

응답을 받는 것과 에이전트가 계속 일하는 것은 다르다

원문에는 HTTP 200인데 사용자에게 보여줄 내용이 비어 있는 응답과 도구 호출이 일반 텍스트에 섞인 사례가 나온다. 추론만 존재하는 응답과 사용량 정보까지 없는 응답도 구분된다. 도구 호출 파싱 실패는 서비스 전체의 오류율만으로 파악하기 어렵다. 전송 성공과 작업 성공을 별도로 집계해야 실패가 정상 응답 속에 묻히지 않는다. 이는 저자의 운영 관찰을 해석한 검증 기준이며 여기서 해당 장애를 직접 재현한 결과는 아니다.

추론 이력에는 별도의 연속성 규칙이 있다. OpenRouter 공식 문서는 모델이 반환한 추론을 다음 호출에 전달할 수 있으며 암호화되거나 요약된 형태는 구조를 보존하는 reasoning_details로 다루도록 설명한다. 연속된 추론 블록의 순서를 바꾸거나 내용을 수정하면 안 된다. 도구 결과를 돌려주는 호출은 앞선 추론의 연장이므로, 화면에 보여줄 최종 답변만 저장하는 방식으로는 필요한 이력을 복원하지 못할 수 있다.

라우팅 제한은 품질과 가용성을 함께 바꾼다

공식 라우팅 문서에서 provider.order는 시도할 순서이고 provider.only는 허용 목록이다. 기본값이 참인 allow_fallbacks는 주 경로가 불가능할 때 대체 업체 사용을 허용한다. 또한 require_parameters를 참으로 지정하면 요청한 매개변수를 지원하지 않는 업체를 제외한다. 이 필터는 지원 조건을 제한하는 장치다. 응답이 정확한지까지 판정하는 품질 검사로 해석해서는 안 된다.

제한을 강하게 걸면 검증하지 않은 업체로 넘어갈 가능성은 줄지만 사용 가능한 경로도 줄어든다. Moustafa는 신뢰하던 세 업체로 경로를 제한한 뒤 서비스 중단과 요청 제한이 겹쳐 가용성을 잃었다. 노트북과 운영 인프라에서 요청 제한 양상이 달랐다는 관찰도 있다. 따라서 허용 목록은 한 번 고르는 설정으로 끝나지 않는다. 운영 환경에서 대체 경로도 같은 응답·이력 검사에 통과하는지 확인해야 품질을 지키면서 장애에 대응할 수 있다.

더 생각해보기

• 지금의 성공률은 HTTP 응답을 세는가, 사용자가 쓸 수 있는 결과를 세는가?
• 주 제공업체가 중단되면 대체 업체가 같은 도구 호출과 추론 이력을 처리할 수 있는가?