LLM-шлюз и on-premise модели: закрытый контур для AI-агентов

Зачем нужен LLM-шлюз

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

Шлюз решает это централизованно:

• Изоляция ключей. Ключи провайдеров хранятся в шлюзе. Разработчики получают виртуальные ключи, которые можно отозвать в любой момент.
• Логирование. Каждый запрос и ответ записывается: кто, когда, какая модель, сколько токенов. Это нужно для аудита ИБ и для разбора ошибок агентов.
• Бюджеты. Лимиты токенов по командам, проектам и пользователям. Мультиагентная схема, которая ушла в бесконечный цикл, упрётся в лимит.
• Маршрутизация. Простые шаги идут на дешёвые модели, сложные на сильные. Задачи с чувствительными данными идут только на локальную модель.
• Фильтры. Маскирование секретов и персональных данных до отправки во внешнюю модель.
• Независимость от вендора. Агенты обращаются к шлюзу. Смена провайдера или модели меняет конфигурацию шлюза, код агентов остаётся прежним.

Как устроен закрытый контур

Агенты: Claude Code, Codex,
Cursor, агенты в CI
        │ виртуальные ключи
        ▼
┌─────────────────────┐
│      LLM-шлюз       │
│ логи · бюджеты      │
│ маскирование        │
│ маршрутизация       │
└─────────────────────┘
   │              │
   ▼              ▼
облачные       on-premise
провайдеры     модель:
(общие         NDA, ПДн,
задачи)        коммерческая
               тайна

В кейсе Праксора для крупной корпорации требования ИБ сформулировали так: единый шлюз с проксированием к провайдерам, логированием запросов, изоляцией реквизитов, бюджетированием токенов и маршрутизацией по безопасности и цене. Чувствительные задачи закрывает модель, развёрнутая on-premise.

Готовые шлюзы

Писать шлюз с нуля обычно не нужно. Распространённые варианты:

Для закрытого контура выбирают решения, которые разворачиваются внутри периметра компании. На что смотреть: поддержка нужных форматов API, виртуальные ключи, бюджеты, экспорт логов в вашу систему и работа без доступа в интернет для локальных моделей.

Как подключить агентов к шлюзу

Большинство агентов умеют работать через собственный адрес API. Claude Code, например, поддерживает шлюзы, которые отдают формат Anthropic Messages. В документации Claude Code описано подключение через LiteLLM. Настройка — две переменные окружения:

export ANTHROPIC_BASE_URL=https://llm-gateway.internal.company.ru
export ANTHROPIC_AUTH_TOKEN=<виртуальный ключ из шлюза>

Переменные раскатывают централизованно через управляемые настройки, чтобы разработчики не подключались к провайдерам в обход шлюза. У агентов с OpenAI-совместимым API настройка похожая: адрес шлюза и виртуальный ключ.

Что проверить при подключении:

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

Когда нужна on-premise модель

Локальная модель нужна, если какие-то данные нельзя отправлять внешнему провайдеру ни при каких условиях:

• код и документы под NDA с заказчиком;
• персональные данные, если компания не оформляет их трансграничную передачу. По 152-ФЗ базы с данными граждан РФ должны находиться в России. Отправка таких данных зарубежному провайдеру считается трансграничной передачей и требует уведомления Роскомнадзора;
• коммерческая тайна, которую политика ИБ запрещает передавать наружу;
• контуры без доступа в интернет.

Для разработки на своих серверах используют открытые модели для кода, например семейства Qwen и DeepSeek. Модели разворачивают через серверы инференса vLLM или SGLang, которые отдают OpenAI-совместимый API. Шлюз подключает их как ещё одного провайдера.

Ограничения стоит учесть заранее:

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

Правила маршрутизации

Маршрутизация определяет, какие данные куда уходят и сколько стоит каждая задача. Пример политики:

routes:
  - match: { project_tag: "nda" }          # репозитории под NDA
    model: onprem-coder
  - match: { contains_pii: true }          # сработал фильтр ПДн
    model: onprem-coder
  - match: { task: "explore" }             # поиск по коду, выжимки
    model: cloud-fast
  - default:
    model: cloud-strong
    fallback: onprem-coder                 # если провайдер недоступен

budgets:
  team/billing:  { monthly_tokens: 400M, alert_at: 80% }
  team/reports:  { monthly_tokens: 150M, alert_at: 80% }

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

Вопросы