LiteLLM внутри: управляющая плоскость многоарендной шины ИИ

Один шлюз. Множество поставщиков. Множество арендаторов. Один план управления для доступа к ИИ в организации.

Вызов модели кажется простым делом:

Application → OpenAI

Однако внедрение ИИ в производственных условиях сложнее. Разные группы предпочитают разных поставщиков. Производственные среды требуют строгих правил работы моделей. Финансовый отдел нуждается в возможности отслеживания источников данных. Отдел безопасности требует единого места для предоставления и отзыва прав доступа. Команды, разрабатывающие платформу, нуждаются в механизмах ограничения нагрузки, маршрутизации, аварийного переключения и сбора телеметрических данных.

Без общего входа все соединения распространяются по разным каналам:

Application A ──► OpenAI
Application B ──► Anthropic
Application C ──► Azure OpenAI
Application D ──► Vertex AI
Application E ──► Bedrock

Каждый продукт вынужден создавать свою инфраструктуру. Важный вопрос теперь уже не в том, как вызвать модель, а в том, как обеспечить доступ к ИИ как к совместной инфраструктуре.

Слой шлюза LiteLLM централизует скрытие информации о поставщиках, процедуру входа, изоляцию тенантов, авторизацию, лимиты расходов, механизмы ограничения нагрузки, направление трафика, счетчики расходов и сбор телеметрии операционной деятельности. Основная идея заключается в том, чтобы рассматривать доступ к моделям как управляемый ресурс платформы, а не просто стандартный HTTP-запрос от каждого приложения.

1. От библиотеки клиента к шлюзу

LiteLLM начал с предоставления разработчикам единого интерфейса для работы со всеми поставщиками, чтобы командам не приходилось запоминать каждый SDK. Однако по мере распространения этого решения одной лишь абстракции становится недостаточно.

Без шлюза каждое приложение по-прежнему взаимодействует с поставщиками независимо:

                    ┌──► OpenAI
                    │
Application A ──────┼──► Anthropic
                    │
                    └──► Vertex AI

                    ┌──► OpenAI
                    │
Application B ──────┼──► Azure
                    │
                    └──► Bedrock

Это приводит к тому, что каждая база кода хранит учетные данные, настройки моделей, параметры повторных попыток, механизмы переключения на резервные источники, ограничения нагрузки, счетчики затрат и логи.

Шлюз объединяет все эти аспекты в одно целое:

                        Applications
                              │
                              ▼
                    ┌─────────────────┐
                    │  LiteLLM        │
                    │  AI Gateway     │
                    └────────┬────────┘
                             │
                ┌────────────┼────────────┐
                ▼            ▼            ▼
             OpenAI      Anthropic     Vertex

Приложения имеют одну точку входа; инженеры платформы отвечают за то, что находится за ней. Безопасное совместное использование этой точки входа между независимыми командами становится следующей проблемой проектирования.

2. Многоклиентская архитектура без совместной собственности

Представьте компанию с следующей структурой:

10,000 developers
500 applications
50 teams
Multiple departments
Multiple LLM providers

У нее есть общий шлюз. Однако она не должна делиться идентичными правами на использование моделей, бюджетами, ограничениями по скорости, административными полномочиями или секретами.

LiteLLM представляет концепцию многоклиентской архитектуры в виде иерархии:

Organization
     │
    Team
     │
    User
     │
    Key

Организация является внешней границей изоляции — это бизнес-единицы, клиенты, отделы, регионы. Команда представляет собой ежедневного пользователя сервиса, у которого есть свои сотрудники, администраторы, бюджеты, ограничения на использование ресурсов, списки разрешенных моделей и ключи доступа. Пользователь — это человек. Ключ используется для аутентификации запроса и связывает его с личностью пользователя и контекстом команды. Такая структура обеспечивает шлюзу необходимый контекст для реализации правил.

3. Контекст арендатора для каждого запроса

Живой звонок — это не просто:

Prompt → Model

Он содержит метаданные о владельце:

                        Request
                            │
              ┌─────────────┼─────────────┐
              ▼             ▼             ▼
            User           Team          Key
              │             │             │
              └─────────────┼─────────────┘
                            ▼
                     Tenant Context
                            │
                            ▼
                      Authorization
                            │
                            ▼
                       Budget Check
                            │
                            ▼
                        Rate Limit
                            │
                            ▼
                       Model Policy
                            │
                            ▼
                         Routing
                            │
                            ▼
                        Provider
                            │
                            ▼
                       Usage + Cost

Перед перенаправлением шлюз может определить, кто звонил, какая команда отвечает за трафик, разрешен ли модель, остался ли бюджет, не нарушает ли звонящий лимиты и какая версия должна ответить. Запрос анализируется, а не просто перенаправляется.

4. Вложенные бюджеты

Простая структура расходов может выглядеть так:

Organization       $1,000,000
      │
Engineering        $600,000
      │
Platform           $200,000
      │
Alice              $10,000

Теперь у средств есть структура. Проверки выполняются по вложенным лимитам, а не по одному глобальному бюджету. Это позволяет использовать командные бюджеты, взимать сборы с отделов или возвращать средства, создавать уведомления, осуществлять оптимизацию и устанавливать лимиты на одного человека. Финансовый отдел может узнать, сколько средств Платформа потратила на конкретную модель поставщика, а не только общую сумму расходов на «ИИ».

5. Доступ к моделям как часть политики

Разным группам нужны разные каталоги:

Engineering
├── GPT
├── Claude
└── Gemini

Finance
└── Approved modelsDevelopment
├── Experimental models
└── Open models

Когда приложение остается без управления, оно самостоятельно создаёт собственные правила разрешения. За шлюзом:

Application
     │
     ▼
LiteLLM
     │
     ├── Authentication
     ├── Authorization
     ├── Model Policy
     ├── Budget
     └── Rate Limit

Приложение запрашивает определённую функциональность; платформа принимает или отклоняет этот запрос. Политики безопасности находятся не в самом приложении, а в инфраструктуре — это тот же принцип, что и для других общедоступных платформ.

6. Учётные записи сервисов для рабочих нагрузок

Стабильный способ управления производственным трафиком — связывание его с учётной записью конкретного пользователя:

Production → Alice's API key

Когда этот пользователь уходит, производственные процессы не должны нарушаться. Лучше использовать стабильную идентичность рабочей нагрузки:

Production Application
        │
        ▼
  Service Account
        │
        ▼
 Production Team

Этот подход применим к производственным сервисам, CI-пайплайнам, задачам, расписателям, агентам и общим заданиям. Идентичность человека следует отделять от идентичности рабочей нагрузки.

7. Маршрутизация и переключение на резервные ресурсы как задачи платформы

Поскольку весь трафик собирается в одном месте, выбор поставщика может осуществляться централизованно:

                    LiteLLM
                        │
              ┌─────────┼─────────┐
              ▼         ▼         ▼
           OpenAI      Azure    Anthropic
           Primary     Backup    Fallback

При принятии решений учитываются такие факторы, как качество модели, её доступность, поставщик, нагрузка, задержки, цена и сигналы о сбоях. Приложения выражают свои намерения; шлюз выбирает способ реализации. Если одна из конфигураций терпит неудачу, другая настроенная цель может взять её на себя, без необходимости того, чтобы каждая команда разрабатывала код для переключения на альтернативного поставщика.

8. Централизованная телеметрия и расходы

Общий шлюз служит естественной границей для сбора телеметрических данных:

                   LiteLLM
                       │
             ┌─────────┼─────────┐
             ▼         ▼         ▼
           Logs      Metrics     Cost
             │         │         │
             └─────────┼─────────┘
                       ▼
                  Observability

Владельцы платформ могут видеть, какая команда тратит больше всего ресурсов, какие модели определяют основную часть расходов, какие приложения работают медленно, у каких поставщиков возникают ошибки и какие команды приближаются к лимитам бюджета — всё это без необходимости анализа сотен потоков логов приложений.

9. Многозаказчиковая архитектура для SaaS-продуктов

Та же самая структура подходит для AI-решений в формате SaaS с большим количеством клиентов:

Customer A
Customer B
Customer C

Каждому клиенту необходимы изолированные параметры использования, бюджеты, права на доступ к моделям и учетные данные. С архитектурной точки зрения:

                     SaaS Application
                              │
                              ▼
                       LiteLLM Gateway
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
         Customer A      Customer B      Customer C
              │               │               │
           Budget           Budget           Budget
           Models           Models           Models
           Usage            Usage            Usage
           Keys             Keys             Keys

Инфраструктура остается общей; границы тенантов сохраняются строгими. В этом и заключается обещание многотенантной архитектуры.

10. Агенты и MCP повышают ставки

Простые приложения по-прежнему выглядят так:

Application → LLM

Современные системы выглядят более так:

Application
    │
    ├──► LLM
    ├──► Agent
    └──► MCP Tool

Агенты могут вызывать несколько моделей, использовать инструменты, взаимодействовать с внешними системами и работать дольше, чем один раунд чата. По мере увеличения автономии централизованное управление становится всё более важным:

                      AI Consumers
                            │
             ┌──────────────┼──────────────┐
             ▼              ▼              ▼
            Apps          Agents           MCP
             │              │              │
             └──────────────┼──────────────┘
                            ▼
                    LiteLLM Gateway
                            │
             ┌──────────────┼──────────────┐
             ▼              ▼              ▼
          Identity        Policy         Routing
             │              │              │
             └──────────────┼──────────────┘
                            ▼
                       AI Providers

Называть LiteLLM «просто прокси» — значит недооценивать его роль. Он начинает выглядеть как плоскость управления ИИ.

11. Компромисс: шлюз является критическим путем

Как только всё проходит через него:

Application
     │
     ▼
LiteLLM
     │
     ▼
Provider

Шлюз представляет собой инфраструктуру производственного назначения. Он требует высокой доступности, возможности горизонтального масштабирования, надежного хранения данных, безопасной обработки ключей, мониторинга, восстановления после катастроф, тщательной настройки, правильного регулирования нагрузки и единообразных правил работы. Централизация обеспечивает контроль, но создает зависимости — следует рассматривать его как платформу, а не просто обычный микросервис.

Более широкая перспектива

Инфраструктура ИИ обычно развивается поэтапно:

Calling models
      ↓
Routing models
      ↓
Managing models
      ↓
Governing AI consumption

Именно на поздних этапах шлюзы играют наиболее важную роль. Будущие платформы будут управлять не только конечными точками работы моделей:

Models
Agents
Tools
Identities
Credentials
Budgets
Policies
Usage

Шлюз — это место, где встречаются все эти ресурсы.

Краткое описание LiteLLM — «взаимодействие с множеством поставщиков моделей через один интерфейс». Более подробное описание — это плоскость управления для контролируемого доступа к ИИ:

Provider Abstraction
        +
Multi-Tenancy
        +
RBAC
        +
Budgets
        +
Rate Limits
        +
Routing
        +
Cost Tracking
        +
Observability

Абстракция поставщиков — это начало. Многоклиентская архитектура, иерархические бюджеты, модели политик, учетные записи сервисов, маршрутизация, переключение на резервные системы и централизованный мониторинг затрат превращают библиотеку для удобства использования в инфраструктуру общей платформы. Стремитесь к такой управляемой модели доступа, вместо того чтобы позволять каждому приложению заново создавать одни и те же механизмы контроля.