Несколько ключей на провайдера: взвешенное распределение, липкая привязка, резервное переключение
Привяжите несколько API-ключей к одному upstream: взвешенное распределение, липкая привязка каждого вызывающего, резервные ключи с weight=0 как страховка — больше никаких жёстких ожиданий при 429.
На что на самом деле жалуется сообщество
Любимые темы Reddit: «RPM одного ключа OpenAI не хватает, как ротировать между несколькими аккаунтами», «ключ упёрся в 429, и бизнес просто ждёт», «при смене ключа теряется всё сродство кеша сессии».
Собственная ротация означает самостоятельную реализацию липкости, весов, резерва и вытеснения при сбое — настоящая инженерная работа.
Как это делает GateLLM
Форма upstream в GateLLM принимает несколько API-ключей: детерминированный взвешенный хеш (FNV-1a) липко закрепляет каждого вызывающего за одним и тем же ключом upstream (стабильно в пределах TTL; ротация ключа на месте не ломает липкость), а веса задают пропорции распределения. При отказе ключа шлюз повторяет запрос следующим непробованным ключом внутри этого upstream — не переопределяя исходную липкую привязку.
Ключи с weight=0 — резервные, включаются только после отказа всех ключей с weight>0. Состояние привязок (binding / predicted / stale) видно построчно в консоли.
Механизм ортогонально сочетается с балансировщиками: Smooth WRR выбирает upstream среди записей, затем липкий выбор определяет ключ внутри него.
5 рычагов, которые действительно работают
- Несколько ключей с весами: детерминированный взвешенный хеш распределяет вызывающих, веса — это пропорции
- Липкая привязка: каждый вызывающий остаётся на одном ключе upstream в пределах TTL — сродство кеша
- Резервные ключи: ключи с weight=0 не участвуют в обычном распределении, включаются только после отказа всех активных
- Наблюдаемые привязки: состояния binding / predicted / stale построчно, автообновление каждые 3 с
- Ортогональность балансировке: выбор ключа внутри upstream + Smooth WRR между upstream складываются в два слоя