Спроектируйте LLM-шлюз для компании
Вопрос
В компании 40 сервисов используют LLM трёх внешних провайдеров и одну свою модель. Нужен единый шлюз: все вызовы идут через него. Нагрузка до 2000 запросов в секунду в пике. Спроектируйте шлюз.
Коротко
Что должно быть в решении
- 1Требования: единый API, маршрутизация по моделям, фолбэки, квоты и бюджеты команд, учёт стоимости, логирование, ПДн, задержка шлюза
- 2Оценка нагрузки: 2000 RPS, длинные стриминговые соединения, размер промптов и ответов, хранение логов
- 3API: совместимый формат запросов, стриминг, идентификация сервиса и команды, политика маршрута в конфиге
- 4Компоненты: stateless-прокси, конфиг маршрутов, лимитер и бюджеты (Redis), кеш, хранилище логов и метрик
- 5Надёжность: ретраи и circuit breaker на провайдера, фолбэк-цепочки, горизонтальное масштабирование, шлюз не единая точка отказа
- 6Безопасность: ключи провайдеров только в шлюзе, маскирование ПДн, запрет отправки чувствительных данных внешним провайдерам
- 7Наблюдаемость: трейсы, стоимость по командам, p95, доля ошибок и фолбэков, алерты
Что спросит интервьюер
- Как учесть стоимость, если ответ стримится и обрывается?
- Как выкатить новую версию шлюза без разрыва стримов?
- Что будет, если упадёт Redis с лимитами?
Разбор
Сильный ответ держит шлюз тонким и stateless: маршрутизация и политики в конфиге, состояние лимитов и кеш во внешнем хранилище, логи асинхронно. Особое внимание длинным стриминговым соединениям: балансировка, graceful shutdown, учёт токенов по фактически отданным. Надёжность провайдеров закрывается ретраями, circuit breaker и фолбэк-цепочками, надёжность самого шлюза репликацией и деградацией (например, при недоступности лимитера пропускать с мягкими локальными лимитами). Ключи провайдеров и политика данных живут только в шлюзе.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.