Experiential, 트래픽으로 모델과 라우팅을 최적화하는 오픈소스 LLM 게이트웨이 공개
- Experiential은 사용 트래픽을 바탕으로 모델 선택과 라우팅을 최적화한다고 밝힌 오픈소스 LLM 게이트웨이 프로젝트임
- 프로젝트는 BYOK 요청에서 게이트웨이가 추가하는 지연 시간이 1ms 미만이라고 설명함
- 라우팅은 모델을 매 요청마다 바꾸기보다 작업 경계에서 드물게 전환하며, 도메인별 모델 풀을 보통 두 개로 제한한다는 개발자 설명임
- 실제 작업 성공을 반영하는 온라인 신호로 사용자가 TUI에서 보정한 루브릭을 적용하는 LLM 심사를 사용함
- 초기 Python 구현을 Rust로 다시 작성했으며, Tinker 기반 지속적 RL 추가를 계획 중임
Hacker News 의견들
여러 모델을 오가면 성능은 나아질 수 있어도 캐시된 입력 토큰 비용 절감 효과를 잃을 텐데, 캐싱이 어떻게 동작하는지 더 듣고 싶음. 캐싱은 성능에도 영향 있음.
라우팅은 자주 바꾸지 않거나 작업 경계에서만 바꾸는 게 요령임. 결론이 특정 작업에서는 한 모델이 파레토 전선에 있으니 계속 쓰라는 경우도 많음.
도메인별 모델 풀은 보통 두 개면 충분하다고 봄. 라우터를 만들며 정리한 글도 있음:
드디어 이런 걸 하는 오픈소스 도구가 나왔네.
처음에는 Python으로 만들었다가 Rust로 다시 쓴 건지 궁금함.
맞음. 커밋 이력을 보면 Python 구현을 Rust로 옮긴 흐름이 보임.
아직 써보진 않았는데 LiteLLM과 비슷한지, 다르다면 뭐가 다른지 궁금함.
트래픽에서 라우터와 모델을 최적화하는 기능이 주된 차이임.
BYOK 요청에 게이트웨이 지연이 1ms 미만이라는 건 인상적임. Tinker 쪽이 특히 마음에 드는데, 컨텍스트 파일을 잔뜩 쌓는 것보다 파인튜닝이 낫다고 봄.
Tinker를 통한 지속적 RL도 곧 넣을 계획임.
오픈소스에 마크업 없는 게이트웨이는 기본값으로 맞다고 봄. 그래도 모델을 바꿀 때 캐시가 어떻게 되는지는 먼저 답을 듣고 싶음.
실제로는 거의 전환하지 않음. 많은 경우 에이전트가 사용할 모델을 한 번 바꾸는 정도임.
게이트웨이가 모델만 고르는지, 추론 노력 수준도 결정하는지 궁금함.
추론 노력 수준도 정함. 예를 들어 Opus 5 저추론이 고추론과 비슷한 경우가 자주 있음.
시뮬레이션 순위를 실제 작업 성공으로 다시 보정하는 온라인 신호가 뭔지 궁금함. 라우터 차원의 시맨틱 캐시도 지원할 계획인지 알고 싶음.
온라인 신호는 사용자가 TUI에서 오프라인 보정한 루브릭을 쓰는 LLM 심사임. 시맨틱 캐시는 흥미롭지만 현재 계획에는 없음.
사업 모델은 엔터프라이즈 플랜으로 보임. 프롬프트별 모델 최적화, 캐싱, 트래픽으로 학습한 자체 모델이 그 플랜의 Intelligence 기능으로 적혀 있음.