여러 모델과 제공자를 한곳에서 골라 쓰고 싶을 때 앞에 두는 계층을 LLM 게이트웨이 또는 라우터라고 부른다. 애플리케이션은 게이트웨이 하나만 알고, 뒤에 무엇이 붙어 있는지는 설정으로 바꾼다.
이것이 없으면 다음이 애플리케이션 코드에 흩어진다.
게이트웨이를 두면 이 모두가 한 지점으로 모인다. 반대로 말하면 그 지점이 단일 장애점이 되므로, 도입한다면 이중화와 관측을 함께 준비해야 한다.
| 항목 | 확인할 것 |
|---|---|
| API 호환 | OpenAI 호환 인터페이스를 제공하는가. 기존 SDK 를 그대로 쓸 수 있으면 이전 비용이 거의 없다 |
| 지원 백엔드 | 상용 API 뿐 아니라 사내 vLLM · Ollama · NIM 같은 자체 서빙을 붙일 수 있는가 |
| 설치 형태 | 폐쇄망에 올릴 수 있는가. SaaS 전용이면 검토 대상에서 빠진다 |
| 라우팅 | 모델 별칭, 장애 시 대체, 가중치 분배, 비용 기준 선택 |
| 키 관리 | 팀별 가상 키 발급, 사용량 상한, 만료 |
| 관측 | 요청 로그, 토큰 사용량, 지연 시간, 비용 집계. Prometheus 로 내보낼 수 있는가 |
| 캐시 | 동일 요청 캐시 지원 여부 |
| 스트리밍 | SSE 스트리밍을 그대로 통과시키는가 |
| 라이선스 | 상용 조건과 기능 제한 |
제품 목록은 빠르게 바뀌므로 개별 제품명을 외우는 것보다 갈래를 아는 편이 낫다.
LLM 호출 자체를 다루도록 만들어진 것들이다. 모델 별칭, 토큰 집계, 가상 키 같은 기능이 기본으로 들어 있다. 사내 구축에서 가장 많이 쓰이는 것은 LiteLLM 이고, 프록시 모드로 띄우면 OpenAI 호환 엔드포인트 하나로 여러 백엔드를 묶는다.
이미 API 게이트웨이를 운영하고 있다면 그 위의 플러그인으로 해결되는 경우가 있다. 인증 · 레이트 리밋 · 로깅 같은 공통 기능을 이미 쓰고 있다는 것이 장점이고, LLM 특화 기능(토큰 단위 과금 집계 등) 은 상대적으로 약하다.
vLLM 처럼 서빙 엔진이 자체 라우터를 제공하는 경우가 있다. 같은 모델의 여러 인스턴스 앞에 두는 용도이지, 이종 제공자를 묶는 용도는 아니다.
키 하나로 여러 상용 모델을 쓰게 해 주는 서비스도 있다. 설치가 없다는 것이 장점이고, 요청 내용이 외부를 거친다는 점 때문에 사내 데이터가 오가는 구성에는 대개 맞지 않는다.
이 문서의 바탕이 된 대화에는 이름을 처음 보는 제품이 여럿 등장했다. 그중 실재와 활동 여부를 확인하지 못한 것이 있어 옮기지 않았다. (확인 필요 — 제품을 고를 때는 저장소의 최근 커밋, 릴리스 주기, 이슈 응답을 직접 확인한다. 생성형 모델이 만들어 낸 목록을 그대로 후보로 삼지 않는다.)