Мультитенантная архитектура шлюза LLM для команд
Создавайте мультитенантные шлюзы LLM с областями действия группы, ключами проекта, изолированными квотами, журналами использования и владением носителем без утечки учетных данных.
Мультитенантный шлюз LLM — это плоскость управления, которая позволяет многим командам, проектам и приложениям совместно использовать один OpenAI-совместимый вход, сохраняя при этом учетные данные, квоты, использование и владение носителями отдельно. Проблема архитектуры не в том, чтобы «добавить столбец tenant_id». Он заставляет каждый запрос последовательно отвечать на четыре вопроса: кто звонит, кто платит, какие модели они могут использовать и какие артефакты они могут прочитать впоследствии. В этой статье эти вопросы сопоставляются с шаблонами шлюзов, которые вы можете реализовать, включая рабочие области групп, ключи на уровне проекта, области ограничения скорости и изоляцию мультимедиа для заданий с изображениями и видео.
Почему мультитенантность появляется после первой производственной победы
Ранние развертывания часто начинаются с одного ключа администратора и одного канала поставщика. Это работает до тех пор, пока:
- продукт, исследования и поддержка используют один и тот же пул расходов
- подрядчикам нужен временный доступ к модели, не видя секретов организации
- финансы спрашивают, какой проект привел к выставлению счета в прошлом месяце
- сгенерированный URL-адрес видео не должен быть доступен для загрузки родственной команде
- один шумный агент исчерпывает лимиты ставок для всех
На этом этапе вам нужны границы аренды в шлюзе, а не только в коде приложения. Мягкие ограничения на стороне приложения помогают, но они не могут помешать утекшему ключу или неправильно настроенному работнику взимать плату с неправильного владельца. мультипровайдерский шлюз LLM без изоляции арендаторов в конечном итоге становится общей инфраструктурой с общим радиусом действия. Сравните это с тонким обратным прокси в Прокси-сервер LLM и шлюз AI: прокси вперед; мультитенантные шлюзы авторизуют и учетные записи.
Основная модель аренды: владелец, действующее лицо и масштаб
Сохраняйте три идентификатора отдельно для каждого запроса:
- Субъект — человек или субъект службы, инициировавший вызов.
- Владелец выставления счетов — кошелек, который теряет квоту при расчете вызова.
- Область доступа — группа/проект (или личное рабочее пространство), ограничивающее ключи, модели и артефакты.
В системах, похожих на репозитории, личные токены обычно выставляют счет владельцу пользователя, тогда как токены на уровне команды связывают как команду, так и проект, и выставляют счета в командном кошельке. Промежуточное программное обеспечение должно отклонять токены на уровне группы, когда рабочие области группы отключены, когда проект неактивен или когда действующему лицу не хватает действий, необходимых для этого проекта. Эта проверка должна быть на горячем пути перед распространением канала.
Client / agent
| Bearer sk-...
v
Auth middleware
- resolve token -> user, team_id, project_id, owner_type
- validate membership + project action grants
v
Policy + rate-limit scope
- team:project:user (or personal user scope)
- model allowlists / group grants
v
Relay / task submit
- upstream channel selection
- pre-consume quota against billing owner
v
Usage log + optional media persistence
- store actor, team, project, billing owner
- authorize later content proxy by same scope
Если актер и владелец выставления счетов сгруппированы в одно поле, вы не сможете ответить «кто потратил бюджет команды» или «кто нажал «Создать». Если областью действия является только метка в журналах, авторизация на /v1/videos/{id}/content будет передаваться между арендаторами.
Поверхности аренды, которые должны оставаться ровными
1. Ключи API и привязка проекта
Выдавайте ключи как первоклассные объекты аренды:
- персональные ключи для отдельных песочниц
- ключи команды привязаны к
team_id+project_id - необязательная группа или модель предоставляют ограничения на то, какие стабильные псевдонимы шлюзов могут вызываться ключом
Стабильные псевдонимы (например, gpt-image-2 или video-default, ориентированные на продукт) должны сопоставляться с идентификаторами вышестоящих моделей в конфигурации канала. Клиенты сохраняют псевдоним; операторы меняют необработанные идентификаторы восходящего потока, не переписывая каждую услугу. Никогда не встраивайте секреты вышестоящего поставщика в клиентские среды. Клиенты проходят аутентификацию только на шлюзе; каналы содержат учетные данные поставщика. Примените ту же дисциплину изоляции к RBAC для доступа к AI API во всех продуктах, предназначенных для нескольких команд.
2. Квоты и безопасность перед потреблением
Безопасность выставления счетов является заботой арендаторов. Предварительное потребление против владельца счета перед дорогостоящей работой; рассчитаться или вернуть деньги после завершения восходящего потока. Для множителей мультимедиа, таких как изображение n или продолжительность видео, установите жесткие границы во время проверки, чтобы враждебный или ошибочный клиент не мог переполнить математическую квоту и получить отрицательный заряд. В этой кодовой базе ограничено количество изображений (MaxImageN = 128) и продолжительность видео (MaxTaskDurationSeconds). Мультитенантные системы должны обеспечивать глобальную защиту, даже если политика команды ограничивает бюджеты проектов.
3. Ограничения скорости с помощью составных ключей области
Полезный ключ области выглядит как team:{id}:project:{id}:user:{id} для группового трафика и ключ только для пользователя для личного трафика. Это не позволяет шторму агентов одного проекта истощать трафик чата другого проекта. Сохраняйте решения по лимитам независимыми от выбора канала: команде может быть разрешена модель, но ее все равно будут ограничивать.
4. Использование журналов использования в качестве поверхности аудита
Для каждого урегулированного вызова следует сохранять исполнителя, владельца выставления счетов, команду/проект (при наличии), псевдоним модели, идентификатор запроса и множители мультимедиа (n, секунды, размер). Эти поля нужны специалистам по финансам и безопасности. Представления использования, связанные с продуктом, представляют собой аутентифицированные поверхности консоли; общедоступная документация должна объяснять модель аудита, а не постоянно связывать читателей с частными консольными маршрутами.
5. Владение СМИ не является необязательными метаданными
Артефакты изображений и видео сохраняются после запроса HTTP. Рассматривайте ключи объектов и идентификаторы задач как ресурсы арендатора:
| Поверхность | Область действия в этом репозитории (проверьте, прежде чем заявлять права) | Правило владения |
|---|---|---|
| Рабочая среда изображений UI/API | Персональный/сессионный/токен под вариантами ключей /api/user/image-workbench и API; ключи объекта принадлежат пользователю | Сегодня нет маршрутов для работы с изображениями команды/проекта. |
| Видео-инструмент UI/API | Личное под /api/user/video-workbench и команда/проект под /api/teams/:team_id/video-workbench | Командные запуски и активы, утвержденные командой + гранты проекта |
| Вход изображения, совместимого с OpenAI | POST /v1/images/generations, POST /v1/images/edits | Выставить счет владельцу биллинга токена; не придумывайте историю команды, если не сохраните ее сами |
| OpenAI-совместимый видеовход | POST /v1/videos, получение, содержимое; ремикс еще зарегистрирован | GET содержимого должен повторно проверить того же владельца/область, которая создала задачу. |
Срок действия URL-адресов вышестоящего поставщика часто истекает. Шлюзы, которые сохраняют объекты в частном хранилище и повторно обслуживают через авторизованный прокси-сервер, уменьшают количество неработающих ссылок и случайного публичного раскрытия. Если для рабочей среды требуется хранилище объектов, закройте его при сбое, если хранилище настроено неправильно, а не возвращайте временный URL-адрес с незаданной областью.
Контрольный список изоляции перед набором второй команды
Используйте это как ворота выпуска, а не слайд:
| Граница | Критерии прохождения |
|---|---|
| Авторизация | Токен на уровне группы не работает для удаленных участников и отключенных проектов |
| Биллинг | Командная работа никогда не списывает средства с личного кошелька (и наоборот) |
| Модели | Проект без гранта не может вызывать ограниченные псевдонимы. |
| Журналы | Межгрупповой запрос журнала возвращает пустые или запрещенные строки, а не частичные. |
| СМИ | Прокси-сервер видеоконтента отклоняет идентификаторы задач сторонней команды как не найденные/запрещенные |
| Ограничение скорости | Загрузка проекта A не потребляет корзину токенов проекта B. |
| Админ | Действия суперадминистратора проверяются отдельно от администраторов арендатора. |
Автоматизированные тесты должны идти по пути отрицания, а не только по счастливому пути. Ошибки мультитенантности скрываются в «мягких решениях 404»: возврат 404 для внешних ресурсов часто лучше, чем 403, если само существование ресурса является конфиденциальным.
Путь запроса ссылки для группового чата
curl https://your-gateway.example.com/v1/chat/completions \
-H "Authorization: Bearer $TEAM_PROJECT_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "YOUR_STABLE_CHAT_ALIAS",
"messages": [
{"role": "user", "content": "Summarize yesterday deploy risk for project alpha."}
],
"max_tokens": 400
}'
Что шлюз должен делать внутри:
- Аутентифицируйте ключ и разрешите
team_id/project_id. - Убедитесь, что актер может использовать токен проекта для этого проекта.
- Разрешите псевдоним модели с помощью разрешенного набора групп/каналов.
- Предварительно израсходуйте расчетную квоту, полученную от владельца платежной системы.
- Ретранслируйте восходящий поток и записывайте журнал потребления с полями актера и владельца.
- Предоставляйте одни и те же идентификаторы в представлениях использования с проверкой подлинности для финансов и поддержки.
Медиа, подчиняющиеся одним и тем же правилам токена, разные области рабочей среды.
Конечные точки мультимедиа не должны изобретать вторую систему аутентификации для выставления счетов. Предпочитайте тот же токен и правила сеанса для входа, совместимого с OpenAI:
# Image generation through OpenAI-compatible ingress (GPT Image returns b64_json)
curl https://your-gateway.example.com/v1/images/generations \
-H "Authorization: Bearer $TEAM_PROJECT_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-image-2",
"prompt": "Product hero shot on matte black pedestal, studio light",
"size": "1024x1024",
"n": 1,
"output_format": "png"
}'
# Async video job (evaluate Sora 2 only with the official deprecation timeline in mind)
curl https://your-gateway.example.com/v1/videos \
-H "Authorization: Bearer $TEAM_PROJECT_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "YOUR_STABLE_VIDEO_ALIAS",
"prompt": "Slow orbit around a ceramic mug on a wood table",
"seconds": "4",
"size": "1280x720"
}'
Пользовательские интерфейсы Workbench различаются:
- Рабочая среда изображений — это личная панель оператора: предустановки, прогоны и ресурсы доступны только пользователю. Не запрашивайте историю изображений команды или маршруты
/api/teams/:team_id/image-workbench, если вы их не реализовали. - Видео верстак поддерживает личные и групповые/проектные области действия. Сопоставьте возможности создания и управления активами с командными действиями и сохраняйте историю выполнения в рамках проекта, когда сеанс привязан к команде.
Конечные точки с сохранением повторных попыток не должны повторно передавать актив другому владельцу. Для новой работы с видео отдавайте предпочтение поставщикам и адаптерам шлюзов, которые вы все еще можете поддерживать после завершения работы OpenAI Videos API / Sora 2 на 2026-09-24 (Прекращение поддержки OpenAI); если вы все еще удерживаете трафик Sora, запланируйте миграцию хранилища задач и путей клиентского кода сейчас.
Уровни политики, которые масштабируются без переписывания клиентов
Политики стека от грубой к тонкой:
- Настройки платформы по умолчанию — максимальное количество изображений
n, максимальное количество секунд видео, заблокированные модели. - Политика команды – разрешенные группы, оповещения о бюджете, флажки функций.
- Гранты на проекты — участники которых могут создавать медиафайлы или управлять видеоресурсами.
- Основные ограничения — списки разрешенных IP-адресов, срок действия, подмножество моделей.
- Ограничения по времени выполнения – число долей в минуту/доверенное число в минуту и количество одновременных задач.
Клиенты продолжают звонить по /v1/*. Операторы меняют политику в конфигурации администратора и сопоставлениях моделей каналов. Это операционная выгода OpenAI-совместимый шлюз API.
Режимы сбоя, уникальные для многопользовательских шлюзов
- Тихий запасной вариант владельца: если командное решение не удалось, не выставляйте счет из личного кошелька актера «за помощь». Отклонить запрос.
- Привязка общего канала без меток изоляции: ключи кэша должны включать область клиента, иначе вы смешаете состояние закрепленной маршрутизации.
- При условии, что инструмент обработки изображений поддерживает работу команды: личные графические ресурсы, принадлежащие пользователю, — это не то же самое, что командные видеопроекты.
- Хранение журналов без учета правовых границ: при отключении команды может потребоваться выборочное удаление; разрабатывайте задания по удержанию с помощью фильтров владельцев.
- Спутанность прокси-сервера контента. Для аутентификации сеанса информационной панели и аутентификации по токену API требуются одинаковые проверки владения.
- Уведомления о бюджете без грантов на действия: оповещение финансов бесполезно, если какой-либо участник все еще может чеканить ключи.
Применяются рекомендации по безопасности из OWASP LLM Топ 10: чрезмерное вмешательство, раскрытие конфиденциальной информации и неограниченное потребление становятся инцидентами с арендой, когда один арендатор может повлиять на другого.
Минимальная последовательность реализации
- Модельные команды, проекты, участники и гранты на действия.
- Добавьте поля владельца в токены и используйте журналы.
- Обеспечьте проверку токена команды в промежуточном программном обеспечении аутентификации.
- Ограничения по объему и запросы на использование.
- Перенос авторизации задач видео и прокси контента в один и тот же помощник области; оставляйте рабочую среду изображений принадлежащей пользователю, если только вы намеренно не добавите сохранение командного образа.
- Добавьте тесты e2e для перекрестного отказа в чате, байтах изображений, которые вы храните, и видеоконтенте.
- Только после этого переносите реальный трафик продукта на ключи команды.
Пропуск тестов запрета пути — это то, как «у нас есть многопользовательский пользовательский интерфейс» без многоарендной безопасности.
Связанное чтение
Источники и дальнейшее чтение
- OWASP Top 10 для приложений LLM
- Лучшие практики производства OpenAI
- Прекращение поддержки OpenAI (включая отключение Videos API / Sora 2 2026-09-24)
- Google Cloud Руководство по многопользовательской работе для корпоративных организаций
Проверка решений
Требуется ли отдельная база данных для каждого арендатора?
Нет для большинства шлюзов AI. Изоляция на уровне строк с помощью дисциплинированных фильтров запросов является обычным явлением. Отдельные базы данных помогают регулировать изоляцию или ограничивать количество шумных соседей, но они умножают миграции и конфигурацию каналов. Выбирайте, основываясь на соответствии, а не на моде.
Должен ли каждый микросервис создавать собственный ключ провайдера?
Нет. Создавайте ключи шлюза для каждого идентификатора службы и храните ключи поставщика в каналах. Это сохраняет ротацию, видимость расходов и аварийное переключение.
Как личные рабочие пространства сосуществуют с командными?
Сохраняйте личный тип владельца как первоклассный путь. Пользователи могут создавать прототипы личных ключей и рабочей среды личных изображений, а затем переключаться на ключи группового проекта для совместного использования чата/видео без изменения формы запроса — меняются только токен носителя и политика.
Какова самая большая ошибка мультитенантных СМИ?
Рассматривать восходящие URL-адреса результатов как надежные общедоступные ссылки или предполагать, что каждая рабочая среда находится в пределах рабочей группы. Настаивайте, когда продукт требует надежности, прокси-сервера через авторизованные маршруты, истечения срока действия документа, когда вы не можете продолжать, и честно заявляйте о личной собственности, а не о командной.
Учения по миграции
Выберите одно производственное приложение и перенесите его с общего ключа администратора на ключ группового проекта. Убедитесь, что в журналах потребления указан правильный владелец выставления счетов, что идентификаторы внешних задач видео запрещены на /v1/videos/{id}/content, что активы рабочей среды изображений остаются во владении пользователя, пока вы не создали дополнительный общий доступ, и что ограничения скорости проекта больше не конфликтуют с нагрузочными тестами родственной группы.