초급관리자
제공자별 다중 키: 가중 분배, 고정 바인딩, 대기 키 인계
하나의 업스트림에 여러 API 키를 붙입니다: 가중 분배, 호출자별 고정 바인딩, weight=0 대기 키를 최후 방어선으로 — 더 이상 429에 하염없이 기다리지 않습니다.
커뮤니티가 실제로 불평하는 것
Reddit 단골: "OpenAI 키 하나의 RPM으로는 부족한데 여러 계정을 어떻게 돌리나", "키가 429에 걸리면 비즈니스가 그냥 기다린다", "키를 바꾸면 세션 캐시 친화성이 전부 사라진다".
직접 순환을 구현하면 고정성, 가중치, 대기, 실패 퇴출을 스스로 처리해야 합니다 — 실제 엔지니어링 노력이 듭니다.
GateLLM은 이렇게 합니다
GateLLM 업스트림 폼은 여러 API 키를 받습니다: 결정적 가중 해시(FNV-1a)가 각 호출자를 같은 업스트림 키에 고정 바인딩하고(TTL 내 안정적이며, 키를 제자리에서 교체해도 고정성이 깨지지 않음), 가중치가 분배 비율을 정합니다. 키가 실패하면 게이트웨이가 그 업스트림 안에서 아직 시도하지 않은 다음 키로 재시도하며 원래 고정 바인딩을 덮어쓰지 않습니다.
weight=0인 키는 대기 상태로, weight>0인 모든 키가 실패한 뒤에만 활성화됩니다. 바인딩 상태(binding / predicted / stale)는 콘솔에서 행 단위로 확인할 수 있습니다.
이 메커니즘은 로드 밸런서와 직교적으로 쌓입니다: Smooth WRR이 엔트리 간에 업스트림을 고르고, 고정 선택이 그 안에서 키를 고릅니다.
실제로 효과가 있는 5가지 레버
- 가중 다중 키: 결정적 가중 해시가 호출자를 분배하고, 가중치는 비율
- 고정 바인딩: 각 호출자가 TTL 내 같은 업스트림 키에 머묾 — 캐시 친화성
- 대기 키: weight=0 키는 정상 분배에서 빠지고 모든 활성 키가 실패한 뒤에만 활성화
- 관찰 가능한 바인딩: binding / predicted / stale 상태를 행 단위로, 3초마다 자동 새로고침
- LB와 직교: 업스트림 내부 키 선택 + 업스트림 간 Smooth WRR이 두 계층으로 쌓임