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

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