OpenRouter 라우팅의 함정: 동일 모델도 Provider별 성능·기능 편차 발생

OpenRouter를 통해 오픈소스 모델을 사용하는 Olly(iMessage AI 어시스턴트) 사례를 바탕으로, 라우팅된 Provider별 성능 편차와 주의사항을 분석했다. 모델 가중치는 동일하지만 호스팅 기업의 GPU, 정밀도, 최적화 방식에 따라 실제 동작이 크게 차이 난다.

Provider별 성능 및 기능 편차

• 벤치마크 격차: DeepSeek V4 Flash 기준, First-party 대비 일부 Provider(DigitalOcean 등)는 TAU-Bench 점수가 20p 이상 하락했다. GLM-5.3 모델에서는 Provider별 순위가 완전히 뒤바뀌기도 했다.
• 비전 인식 오류: Qwen3.5 122B는 DeepInfra에서 색상과 문자를 잘못 인식하는 오류가 발생했으며, MiniMax M3는 Venice와 Together에서 이미지 입력을 무시하고 'no image provided'로 응답했다.
• 파라미터 무시: reasoning.effort 설정이 일부 Provider(digitalocean, venice 등)에서는 무시되어 reasoning token 수에 영향을 주지 않았다.

정량화(Quantization)와 응답 품질

• fp4 vs fp8: fp4가 fp8보다 성능이 낮다는 통념과 달리, fp4 호스트가 fp8 그룹 중간에 위치하거나 상위권을 차지하는 등 정밀도는 품질의 좋은 지표가 아니다. 하드 필터링보다는 보드 점수 기반으로 필터링해야 한다.
• 빈 응답(Hollow Completions): HTTP 200 OK를 반환하면서도 content, reasoning, usage가 모두 null인 경우가 발생한다. StreamLake의 DeepSeek 트래픽 중 약 **20%**가 이 현상을 겪었으며, 이를 실패로 간주하고 재시도하는 로직이 필요하다.

프로덕션 운영 시 주의사항

• IP 기반 제한: Venice와 Novita는 Mac 환경에서는 정상 작동했으나, 프로덕션 인프라 IP에서는 429 Too Many Requests 에러가 빈번했다. 실제 배포 환경에서 벤치마크를 수행해야 한다.
• Provider 고정(Pinning)의 위험: 신뢰할 만한 3개 Provider만 허용하고 폴백을 끄면, 해당 Provider들의 일시적 장애나 모델 미제공으로 전체 서비스가 다운될 수 있다. 유연한 라우팅과 재시도 전략이 필수적이다.