07.12.2025 14:44
gametwix 1 4500 Источник

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

Привет, я Павел Мохляков. Вообще я Data Science-инженер в Cloud.ru, но сегодня решил, почему бы не рассказать как с помощью LLM-шлюза можно использовать несколько LLM через один API и при этом снизить риск утечки данных, контролировать расходы и соблюдать требования №152-ФЗ. Кроме того, покажу пример тестового подключения и объясню, что делать на каждом этапе.

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

Решение через LiteLLM-шлюз

LiteLLM — open source шлюз для LLM. Устанавливаете один интерфейс, совместимый с OpenAI, и получаете интеграцию с более чем 100 LLM-провайдерами.

Чем полезен LiteLLM:

  • Не нужно переписывать код под каждый API. LiteLLM преобразует запросы под форматы провайдеров, для completion, embedding и image generation, а затем стандартизирует ответы.

  • LiteLLM распределяет запросы между несколькими экземплярами моделей или провайдерами. Для этого используются различные стратегии. Например, least_busy — направление запросов к развертыванию с наименьшим количеством активных запросов. Эта стратегия помогает минимизировать задержки в очереди.

  • При сбое у провайдера LiteLLM автоматически переводит запрос на другого. Для этого в параметре fallbacks нужно указать основную и резервные модели. К примеру, если модель недоступна на FM или OpenRouter, то запрос перенаправляется на спящий инференс.

  • В LiteLLM можно централизованно управлять доступом. Вы всегда будете в курсе, как пользователи работают с моделями: какие запросы делают и сколько тратят токенов. Можно, например, генерировать ключи API с детализированным контролем доступа, а еще организовать пользователей в группы и установить для них лимиты запросов и бюджет.

Думаю, не ошибусь, если скажу, что вопрос, как всё это поможет в комплаенсе и соблюдении №152-ФЗ, актуален для многих компаний. Рассказываю.

Если нужно фильтровать контент по ключевым словам, можно использовать LiteLLM Content Filter. Алгоритм сканирует сгенерированный текст на наличие конкретных слов или фраз, которые нужно задать самостоятельно. Другие способы настроить фильтрацию по ключам можно найти в документации. Например, прописать blocked_words в config.yaml или подключить кастомную модель для фильтрации. В общем, фильтр не даст сотрудникам тратить токены на поиск или сочинение новых фанфиков про Драмиону.

Вы не даете прямого доступа к ключам LLM-провайдера. Ключи можно создавать под конкретный проект и устанавливать ограничения на их использование. Каждый ключ открывает пользователю или команде определенные операции в рамках их доступа. А по уникальному идентификатору call_id для каждого запроса вы сможете отслеживать, кто делал запрос и на какую модель.

Доступ к моделям и расходы можно отслеживать через виртуальные ключи:

  • /key/info — расходы для конкретного ключа.

  • /user/info — расходы пользователя.

  • /team/info — расходы команды.

В общем, плюшек у LiteLLM много, но и сложности тоже есть. Самая главная в том, все обращения пользователей через один шлюз используют один и тот же API-токен. То есть внутренние лимиты для разных сервисов, команд и продуктовых групп завязаны на один корпоративный токен. Теоретически, если один пользователь внутри компании сделает, массовую рассылку запросов, он может «съесть» весь лимит корпоративных токенов и заблокировать остальных. Именно поэтому соизмеряйте объем лимитов и количество запросов.

Есть и еще одна проблема: единая точка контроля в случае чего может стать и единой точкой риска. Если проигнорировать IAM, патчинг, разделение и документирование зон ответственности — можно получить удобный вход (или выход, как посмотреть) для компрометации, так что будьте внимательны.

Практический кейс: тестовое развертывание

Здесь я покажу, как развернуть LiteLLM на конкретном примере.

Дано: в компании 10 команд используют GPT, пять — Claude, две — YandexGPT, одна — Qwen для работы с персональными данными клиентов.

Проблемы:

  • Нет единой политики доступа.

  • Данные утекают в сторонние API.

  • Сложно понять, к каким моделям чаще всего обращаются пользователи.

  • Нет fallback: если один API упал — всё встало.

Решение: LLM-шлюз как централизованная точка управления с подключенными моделями Evolution Foundation Models.

Использую следующие сервисы:

  • Evolution Foundation Models — сервис для доступа к API популярных фундаментальных моделей машинного обучения с открытым исходным кодом. Все LLM развернуты на серверах в пределах РФ, и информация не попадет к зарубежным разработчикам моделей.

  • Виртуальная машина Cloud.ru — среда, в которой будем работать. Docker — система контейнеризации.

  • Docker Compose — инструмент для запуска и управления Docker-контейнерами.

  • Бесплатный сервис nip.io для получения публичного доменного имени и сертификата. Вы также можете использовать собственное зарегистрированное доменное имя и SSL-сертификат для организации доступа.

  • Nginx — веб-сервер для проксирования запросов и организации защищенного HTTPS-доступа к приложению.

  • Let’s Encrypt — сервис для автоматического получения бесплатного SSL-сертификата.

  • LiteLLM — LLM-шлюз.

Шаг 1. Подготовка: разверните ресурсы в облаке

Перед началом установки сгенерируйте SSH-ключ, он вам понадобится для подключения к виртуальной машине. Загрузите публичную часть (~/.ssh/id_rsa.pub) SSH-ключа в облако Cloud.ru (UI → «Загрузка ключа»).

Создайте бесплатную виртуальную машину (Ubuntu 22.04) со следующими параметрами:

Я использую такую минимальную конфигурацию: 2 vCPU, 4 GB RAM, 20 GB SSD. При таких параметрах ВМ должно хватить памяти для работы PostgreSQL, Docker-контейнеров и LiteLLM, и останется небольшой запас под системные процессы Ubuntu.

На странице «Инфраструктура» → «Виртуальные машины» убедитесь, что отображается виртуальная машина litellm-service со статусом «Запущена». Запишите публичный IP — потребуется далее.

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

Добавьте в нее правила:

  • TCP/22 — SSH — разрешить только с доверенных IP (укажите CIDR, например 203.0.113.10/32).

  • TCP/80 — HTTP — 0.0.0.0/0.

  • TCP/443 — HTTPS — 0.0.0.0/0.

На странице «Сети» → «Группы безопасности» убедитесь, что отображается группа безопасности litellm-service со статусом «Создана».

Сгенерируйте API-ключ для доступа к Evolution Foundation Models. Не буду сейчас подробно расписывать создание ключа — вы можете легко сделать это по инструкции.

Заполните параметры API-ключа:

  • «Сервисы» — Foundation Models.

  • «Время действия» — можно ограничить время жизни ключа сроком от одного дня до года (по умолчанию). Лучше выставить небольшое значение, например 90 дней. Нажмите «Создать» и сохраните API-ключ — он будет использоваться для конфигурации сервиса. Учтите, что после закрытия окна получить его будет нельзя.

Не вставляйте ключ прямо в публичные файлы; используйте .env или Secret Manager. Укажите явно: FOUNDATION_API_KEY=<API-ключ Evolution Foundation Models>.

Созданный API-ключ появится в списке ключей в статусе «Активен».

Подключитесь к виртуальной машине по SSH. Если SSH недоступен, используйте серийную консоль Cloud.ru для диагностики. В личном кабинете перейдите во вкладку «Инфраструктура» → «Виртуальные машины» → выберите нужную ВМ. Затем откройте вкладку «Серийная консоль». Проверьте параметры, чтобы подтвердить версию и память.

uname -a, lsb_release -a 
free -h

Шаг 2. Установка зависимостей

Сначала обновим и подготовим систему: 

sudo apt update && sudo apt upgrade -y

Установите Docker, Docker Compose. Проверьте, что они установлены корректно и в подходящей версии: 

docker --version # ожидается >= 24.0
docker compose version# ожидается >= 2.20

Затем установите Nginx сервер, Let’s Encrypt и плагин для Nginx: 

sudo apt install -y nginx certbot python3-certbot-nginx
sudo systemctl enable --now nginx

Важно, чтобы сервис nginx был в статусе active (running), проверим это: 

sudo systemctl status nginx

Выпустите SSL-сертификат через nip.io (или свой домен). Для этого нужно:

1. Перейти по адресу http://litellm.<ip-address>.nip.io. Откроется страница с текстом 502 Bad Gateway — это нормально.

2. Запустить команду для выпуска SSL-сертификата:

sudo certbot --nginx -d litellm.<ip-address>.nip.io --redirect --agree-tos -m <email>

<ip-address> — IP-адрес вашей виртуальной машины.

<email> — email-адрес для регистрации сертификата.

После выпуска сертификата перейдите по адресу https://litellm.<ip-address>.nip.io — соединение должно быть отмечено как безопасное. Важно: nip.io подходит только для тестового доступа, его нельзя использовать в проде.

Шаг 3. Запуск LiteLLM через Docker Compose

Создаем рабочую директорию и файл окружения: 

sudo mkdir -p /opt/litellm
cd /opt/litellm

Создаем файл .env для секретов:

LITELLM_MASTER_KEY=<ваш_секретный_ключ>
DATABASE_URL=postgresql://postgres:postgres@db:5432/litellm
FOUNDATION_API_KEY=<API-ключ Evolution Foundation Models>

Кстати, убедитесь, что права доступа к .env ограничены:

chmod 600 .env

Разворачиваем:

  • Контейнер PostgreSQL (для хранения ключей, логов, статистики). Для этого создайте файл docker-compose.yml.

  • Контейнер LiteLLM с конфигурацией config.yaml. В созданном файле конфигурации указываем LITELLM_MASTER_KEY — ключ и пароль для LiteLLM для полного доступа ко всем настроенным в прокси-сервере моделям. DATABASE_URL нужен для подключения к базе данных. А чтобы сохранять в базе данных все типы объектов (модели, MCP, guardrails, векторные хранилища и т. д.), нужно использовать переменную store_model_in_db: true в файле config.yaml. Для каждого типа нужны свои параметры, для хранения MCP используйте supported_db_objects: ["mcp"].

Вот мой пример, можно просто вставить его содержимое в ваш файл:

services:
 postgres:
   image: postgres:15
   container_name: postgres-for-litellm
   environment:
     POSTGRES_USER: litellm
     POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
     POSTGRES_DB: litellm_db
   volumes:
     - postgres_data:/var/lib/postgresql/data
   env_file:
     - ./.env
   ports:
     - "5432:5432"
   restart: unless-stopped
   healthcheck:
     test: ["CMD-SHELL", "pg_isready -U litellm -d litellm_db"]
     interval: 10s
     timeout: 5s
     retries: 5

 litellm:
   image: ghcr.io/berriai/litellm:main-stable
   container_name: litellm
   ports:
     - "4000:4000"
   volumes:
     - ./config.yaml:/app/config.yaml
   env_file:
     - ./.env
   environment:
     DATABASE_URL: "postgresql://litellm:${POSTGRES_PASSWORD}@postgres:5432/litellm_db"
     LITELLM_MASTER_KEY: ${LITELLM_MASTER_KEY}
     STORE_MODEL_IN_DB: "true"
   depends_on:
     postgres:
       condition: service_healthy
   restart: unless-stopped
   command: ["--config", "/app/config.yaml"]
volumes:
 postgres_data:

Шаг 4. Интеграция с Evolution Foundation Models

Откройте панель управления LiteLLM и перейдите к добавлению новой модели. В поле Enter custom model name введите нужную модель из Evolution Foundation Models с дополнительным префиксом /openai, например:

  • openai/openai/gpt-oss-120b;

  • openai/zai-org/GLM-4.6;

  • openai/Qwen/Qwen3-Coder-480B-A35B-Instruct.

Модель можно переименовать так, как удобно вам. Например, GLM-4.6 вместо openai/zai-org/GLM-4.6. Это имя будет использоваться в API LiteLLM вместо полного пути.

Дальше настроим эндпоинт для обращения к модели: поле API base → https://foundation-models.api.cloud.ru/v1/. А в поле OpenAI API Key введите API-ключ для доступа, который мы создали раньше. Проверьте подключение: внизу страницы нажмите Test Connect. Если все параметры указаны верно, в ответ вы получите сообщение Connection to custom successful!

Теперь модель доступна через единый API, как будто она «своя».

Шаг 5. Виртуальные ключи и политики доступа

Откройте панель управления LiteLLM и перейдите во вкладку управления ключами (API Keys или Virtual Keys). Создайте виртуальные ключи для разных команд: например, для HR — доступ только к модели для генерации текста вроде GLM-4.6, для Dev-команды — доступ к Qwen3-Coder. Опционально можно задать имя ключа для удобства (например, HR_text_key или Dev_coder_key).

Настройте лимиты на количество запросов, допустим, 100 запросов в минуту. Срок действия задайте 30 дней. Когда срок действия ключа закончится либо вы превысите лимит запросов, LiteLLM выдаст соответствующую ошибку.

Попробуйте отправить запрос через API LiteLLM с новым виртуальным ключом, чтобы проверить, что доступны только назначенные модели. Используйте команду curl: 

curl -H "Authorization: Bearer <виртуальный_ключ>" \
     -X POST https://<litellm-endpoint>/v1/completions \
     -d '{"model":"GLM-4.6","prompt":"Привет"}'

Шаг 6. Использование: единый API для всех

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

  • модели, которые будут доступны по этому ключу;

  • лимиты на количество запросов;

  • срок жизни ключа.

К добавленным моделям можно обращаться через единый эндпоинт LiteLLM:

from openai import OpenAI
api_key = "litellm_api_key" #API key generated in the previous step
url = https://litellm.<ip-address>.nip.io/v1 #Substitute the IP address with the service
client = OpenAI(
   api_key=api_key,
   base_url=url
)
response = client.chat.completions.create(
   model="GLM-4.6",
   max_tokens=5000,
   temperature=0.5,
   presence_penalty=0,
   top_p=0.95,
   messages=[
       {
           "role": "user",
           "content":"Как написать хороший код?"
       }
   ]
)
print(response.choices[0].message.content)

Команда не будет знать, где модель, — она просто использует единый эндпоинт.

Шаг 7. Повышение отказоустойчивости

Для повышения надежности можно использовать модели разных провайдеров как резервные.

  1. Перейдите во вкладку Settings → Router Settings → Fallbacks.

  2. Нажмите Add Fallbacks.

  3. Выберите основную и резервную модель. Если основная модель недоступна, запросы будут переадресованы на резервную.

Лучше подключать резервные модели разных провайдеров, чтобы снизить риски, а для критически важных задач настроить несколько уровней fallback. Еще проверяйте, что резервная модель совместима по API с основной моделью, чтобы запросы обрабатывались корректно. Fallback не заменяет мониторинг и уведомления о сбоях, но повышает отказоустойчивость и стабильность работы единого API.

Я советую проверить, как это работает: искусственно отключите основную модель или заблокируйте ее файрволом.

Шаг 8. Безопасность и администрирование: закрываем SSH

Когда вы закончили настройку сервиса, убедитесь, что все ключи сохранены в .env, права доступа — 600. Проверьте, что серийная консоль Cloud.ru активна. Затем удалите правило порта 22 из группы безопасности. После этого администрирование сервиса будет доступно только через серийную консоль ВМ.

Убедитесь, что доступа нет: попробуйте подключиться к виртуальной машине по SSH.

Теперь вы можете использовать LLM-модели от разных провайдеров по единому API-ключу. Давайте проверим:

curl https://litellm.<ip-address>.nip.io/v1/models \
  -H "Authorization: Bearer <виртуальный_ключ_команды>"

В ответ вы должны получить список всех доступных вам моделей.

Выводы и рекомендации

На мой взгляд, централизованный шлюз — must have для компаний, которые хотят использовать LLM от разных провайдеров и сохранить контроль и безопасность данных. А Evolution Foundation Models — подходящее решение: вы получаете доступ к популярным open source моделям, которые можно легко адаптировать под свои задачи. Модели уже готовы к использованию — не нужно развертывать инференс и писать код, достаточно подключиться через API, совместимый с OpenAI. Я попробовал сервис еще на стадии public preview, сейчас он уже доступен для всех, так что можно потестить и решить, нравится вам или нет.

Не могу не напомнить о рисках. У LiteLLM бывали случаи, когда обычный пользователь получал права администратора и мог узнать все ключи. Если вы в компании единственный, кто понимает, как вся эта история работает, то ничего страшного, пожалуй. А вот если в компании есть, кому атаковать изнутри, — лучше поберечься.

Комментарии (1)


  1. empenoso
    08.12.2025 02:19
    #29220224

    А чем отличается от OpenRouter, One API for Any Model?