Инференс

Кому подходит Такой контур нужен командам, которые хотят использовать крупную языковую модель для работы с внутренними инженерными данными: первичного разбора инцидентов, сопоставления логов с описанием проблемы, runbook и changelog, подготовки технических резюме и формирования гипотез для дальнейшей диагностики. Self-hosted-развертывание позволяет выполнять такую обработку внутри контролируемой инфраструктуры и не передавать служебные данные во внешний API. Для запуска используем официальный квантизованный checkpoint nvidia/MiniMax-M2.7-NVFP4. Модель развернем через vLLM. Входные данные будем получать из Object Storage, а результат анализа сохранять обратно в бакет. В реальном контуре модель может работать с внутренними логами, описаниями инцидентов, конфигурациями и эксплуатационной документацией. В статье такие данные использовать нельзя, поэтому весь пайплайн покажем на публичных NGINX sample logs из репозитория Elastic. Они нужны для безопасной и воспроизводимой проверки интеграции. На выходе получим базовый закрытый контур для обработки инженерных данных: Такой пайплайн можно использовать как основу для внутренних AI-инструментов: помощника дежурной смены, предварительного incident triage, подготовки RCA-черновиков, анализа конфигураций и сопоставления технических артефактов. В демонстрации ограничимся отчетом по публичному фрагменту NGINX access logs. В статье посмотрим, как: подобрать конфигурацию сервера для запуска; создать преднастроенную VM из AI-каталога Selectel; запустить MiniMax-M2.7 через vLLM; подключить S3 и загрузить туда тестовые логи; передать модели технический контекст из Object Storage и сохранить сформированный отчет обратно в бакет. В качестве тестовых данных используем открытые NGINX sample logs из репозитория Elastic. Модель должна выделить основные паттерны запросов, сгруппировать HTTP-статусы, найти URL и request patterns, требующие внимания, и подготовить рекомендации для SRE/DevOps-команды. Что будем реализовывать Соберем базовый пайплайн для обработки технических артефактов с помощью self-hosted LLM: В продакшене вместо простых файлов модель может изучать комплексные данные: выгрузку логов за время сбоя, описание симптомов, конфигурацию серверов, историю последних релизов и инструкции для дежурных инженеров. Обычно эти артефакты собираются из систем мониторинга вроде Loki, OpenSearch или ClickHouse. Весь процесс мы разделим на три понятных слоя: Вычислительный слой. На GPU-сервере запустим nvidia/MiniMax-M2.7-NVFP4 через vLLM и получим OpenAI-совместимый API. Слой хранения. В Object Storage разместим входные технические артефакты и итоговые отчеты. Такое разделение позволяет останавливать или пересоздавать инференс-сервер без потери данных. Клиентский слой. Python-скрипт скачает входные файлы, сформирует запрос к модели, сохранит ответ локально и загрузит отчет обратно в бакет. В продакшене перед этим шагом обычно добавляют фильтрацию и агрегацию данных. Передавать крупной модели весь поток access logs целиком экономически и технически нецелесообразно. На их примере проверим передачу технического контекста из Object Storage и формирование структурированного отчета с раздельными блоками наблюдений и гипотез. На выходе мы получим детальный отчет для SRE/DevOps-команды, который будет включать в себя краткое резюме по логам, распределение HTTP-статусов, требующие внимания URL, а также подозрительные IP, user agents или шаблоны запросов. Кроме того, модель выявит возможные причины ошибок, сформирует рекомендации по мониторингу и предложит готовый план первичных действий. Почему MiniMax-M2.7 nvidia/MiniMax-M2.7-NVFP4 — крупная квантованная модель, которую можно развернуть локально через vLLM на GPU Blackwell. По своим возможностям: анализ, написание тестов и работы с контекстом она практически сравнялась с флагманами вроде GPT-5.5 и моделями типа Opus. Главное же преимущество заключается в глубокой оптимизации под архитектуру NVIDIA Blackwell через формат NVFP4. Это позволяет запустить тяжелую MoE-модель (230B параметров) внутри закрытой инфраструктуры с высокой скоростью генерации, чтобы безопасно обрабатывать данные без риска их утечки во внешние API. Для простого подсчета HTTP-статусов такая модель избыточна. Ее применение становится оправданным, когда запрос включает несколько типов технического контекста и требует не просто агрегации, а интерпретации. Модель способна сопоставить сырые логи с описанием симптомов и временной шкалой инцидента, учесть конфигурацию NGINX, приложения или балансировщика, а также проверить связь возникшей проблемы с последним релизом. В этих сценариях она работает как интеллектуальный слой интерпретации: сопоставляет отобранные технические артефакты и формирует готовый черновик инженерного разбора. Опираясь на внутренний runbook и правила эскалации, модель сама выдвигает гипотезы RCA, упорядочивает дальнейшие шаги диагностики и готовит емкое техническое резюме для смежных команд. В карточке NVIDIA модель отмечена как предназначенная для research and development. Перед продакшен-внедрением необходимо отдельно проверить условия лицензии, ограничения применения, качество на внутренних данных и требования к сопровождению. В протестированной конфигурации checkpoint запускался с tensor parallelism на двух GPU. Подбор конфигурации В инструкции используем конфигурацию, на которой checkpoint был успешно запущен: GPU — 2 × NVIDIA RTX PRO 6000 Blackwell Server Edition, 96 ГБ (Общая VRAM: 192 ГБ); vCPU — 32 ГБ; RAM — 240 ГБ; Локальный диск — 1 TB; ОС — AI-ready образ / GPU Optimized Ubuntu. Основной ограничивающий ресурс здесь — видеопамять, необходимая для выбранной модели. Конфигурация рассчитывается по размеру checkpoint, длине контекста, KV-cache и числу параллельных запросов, а не по размеру демонстрационного log-файла. Официальный checkpoint занимает значительный объем, а при запуске vLLM требуется дополнительная память под KV-cache, runtime и служебные буферы. Поэтому используем две GPU и распределяем модель через tensor parallelism. Репозиторий модели занимает около 140 ГБ на диске. По метаданным Hugging Face checkpoint содержит около 116 млрд параметров, представленных тензорами разных типов, включая NVFP4-совместимое квантованное представление. При запуске vLLM дополнительно использует GPU-память под KV-cache, CUDA-графы и служебные буферы. На одной GPU с 96 ГБ VRAM этот checkpoint в протестированной конфигурации не размещается, поэтому модель распределяем между двумя GPU. Две NVIDIA RTX PRO 6000 Blackwell Server Edition по 96 ГБ дают 192 ГБ суммарной VRAM. Модель распределяется между GPU с tensor-parallel-size2. Для более компактной модели аналогичный пайплайн можно реализовать на существенно меньшем числе GPU или на одной карте. Здесь задача — проверить инфраструктурный контур для дальнейшей работы с внутренними инженерными данными. В протестированной конфигурации 240 ГБ RAM хватило для системных процессов, Docker, токенизации и подготовки входных файлов. Локальный диск 1 ТБ используется под Docker-образы, кэш Hugging Face и временные данные; входные файлы и отчеты хранятся в S3. Параметры запуска модели ограничим так: tensor parallelism — 2; max model len — 32768; KV-cache dtype — fp8_e4m3. max-model-len32768 задает максимальный суммарный контекст одного запроса: входные сообщения, служебные токены chat template и генерируемый ответ. Значение выбрано для демонстрационного запуска и позволяет контролировать расход памяти под KV-cache. Структура файлов в S3 В бакете создадим два префикса: input/ и output/. В input/ загрузим входные данные: nginx_access.log — публичная тестовая выборка вместо внутренних продакшен-логов; incident_context.md — пример дополнительного контекста, который в реальной эксплуатации может содержать симптомы, временной интервал, версию сервиса, сведения о релизе и затронутых компонентах; analysis_task.md — требования к структуре инженерного отчета. В продакшен этот файл можно заменить шаблоном RCA, runbook или регламентом incident response. Результат сохраним в output/: В продакшене в бакет не следует безусловно выгружать полный поток логов. До обращения к LLM данные желательно отфильтровать по временному диапазону, сервису, trace ID или признакам аномалии и дополнить агрегированной статистикой. Перейдем к практической реализации и развертыванию контура. Создаем GPU-сервер В панели управления вверху выберите Продукты, далее в всплывающем окне в разделе AI-платформа нажмите AI-маркетплейс. Выберите конфигурацию: После создания сервера подключитесь по SSH: Проверьте, что система видит обе GPU: В выводе должны отображаться две NVIDIA RTX PRO 6000 Blackwell Server Edition. Обновите пакеты: Затем подготовьте окружение и установите базовые утилиты: Когда утилиты готовы, можно переходить к установке видеодрайвера. Сначала проверьте, какую версию рекомендует сама система: В тестовой конфигурации использовался пакет: После установки перезагрузите сервер и снова подключитесь по SSH: Проверьте, что обе карты доступны. Проверяем Docker Если Docker еще не установлен, установите его командой: Далее для проброса видеокарт в контейнеры нам понадобится утилита NVIDIA Container Toolkit. Сначала проверьте ее наличие в системе: Если команда не найдена, нужно добавить ключ одной строкой: Затем зарегистрируйте сам репозиторий в списках источников apt: После подключаем репозиторий и устанавливаем NVIDIA Container Toolkit: Настройте NVIDIA runtime для Docker и перезапустите демон: В качестве финальной проверки запустите легковесный тестовый контейнер и убедитесь, что у него есть прямой доступ к аппаратным ресурсам хоста: Если команда показывает обе GPU, окружение готово для запуска vLLM. Готовим Hugging Face cache Создайте директорию для кэша модели: Если модель требует авторизацию на Hugging Face, передайте токен в переменную окружения: Запускаем nvidia/MiniMax-M2.7-NVFP4 через vLLM Устанавливать vLLM через pip не нужно: используем официальный Docker-образ vllm/vllm-openai:v0.25.0. Запустим модель через vLLM в Docker, для этого пропишем команду: В рамках нашей демонстрации API публикуется на стандартном порту 8000. Ключевые параметры: --tensor-parallel-size 2 — распределяет модель между двумя GPU; --max-model-len 32768 — задает максимальную сумму входных и выходных токенов одного запроса; --kv-cache-dtype fp8_e4m3 уменьшает объем памяти, занимаемый KV-cache, по сравнению с BF16. Использование FP8 может влиять на качество генерации, поэтому для продакшен-нагрузки его следует проверять на собственных запросах; --enable-prefix-caching позволяет повторно использовать KV-cache для запросов с одинаковым префиксом. В одиночном демонстрационном запросе заметного эффекта может не быть; --enable-chunked-prefill разбивает prefill длинного запроса на части и позволяет планировщику vLLM эффективнее совмещать его с другими запросами; -v /root/.cache/huggingface:/root/.cache/huggingface — сохраняет checkpoint на диске хоста между пересозданиями контейнера; -e HF_HUB_DISABLE_XET1 — отключает Xet-транспорт Hugging Face; в тестовом окружении загрузка через обычный HTTP оказалась стабильнее. На другом маршруте или версии huggingface_hub параметр может быть не нужен. Первый запуск занимает время: контейнер скачивает около 140 ГБ и затем инициализирует модель на обеих GPU. Следите за логами до строки Application startup complete: Проверяем API модели Как только vLLM завершит загрузку, убедитесь, что эндпоинт доступен, и проверьте список моделей: Если сервер вернул корректный список, выполним тестовую проверку генерации. Для этого отправим простой проверочный запрос в Сhat Completions API: В ответе должен быть JSON с полем choices и текстом модели в choices.message.content. Если API отвечает, это значит что наш локальный инференс-сервер полностью работоспособен. Теперь можно переходить к настройке Object Storage и подготовке входных файлов с логами. Создаем S3-бакет Создайте S3-бакет в панели управления. Для этого перейдите по пути: Продукты → Хранение и обработка данных → S3 → кнопка Создать бакет. Для примера используем имя: minimax-nginx-demo. В бакете будем использовать два префикса: input/ — входные данные для анализа;output/ — результат работы модели. Создайте сервисного пользователя и выпустите S3-ключ. Нам понадобятся: Access Key ID и Secret Access Key. Ключи будем передавать через переменные окружения. Установка и настройка клиента S3cmd Для удобной работы с файлами из терминала настроим s3cmd — классический CLI-клиент для объектных хранилищ, полностью совместимый с API S3. Установка выглядит просто: После завершения установки запустите мастер интерактивной конфигурации: Там указываем: Access Key; Secret Key; S3 Endpoint Selectel. После настройки проверяем: s3cmd ls. Должен появиться список бакетов. Скачиваем тестовые NGINX logs Для безопасной проверки интеграции мы будем использовать публичные демонстрационные логи NGINX из репозитория Elastic. Для начала склонируйте этот репозиторий в домашнюю директорию вашего сервера: Переходим в директорию с NGINX logs: Смотрим содержимое: ls -lh Нам нужны файлы с логами: И рабочая директория для входных файлов: Копируем sample log в рабочую директорию: Проверяем первые строки файла: Добавляем контекст задачи Помимо сырых логов, для качественного анализа модели необходим бизнес-контекст инцидента и четкие критерии отчета. Сначала создадим файл описания инцидента, который задаст модели рамки исследования: Затем зафиксируем требования к структуре финального документа. Для этого сформируем файл с конкретной постановкой задачи для SRE-команды: Проверьте входные файлы: В выводе терминала вы должны увидеть готовый к отправке набор из трех файлов: analysis_task.md, incident_context.md и nginx_access.log. Загружаем файлы в S3 После настройки s3cmd загрузите подготовленные файлы в бакет Object Storage. Сначала задайте имя бакета: Создайте в бакете каталог input и загрузите в него все входные файлы: В бакет будут загружены: input/nginx_access.log; input/incident_context.md; input/analysis_task.md. После этого исходные данные для анализа хранятся в S3. На следующем шаге скрипт скачает их из бакета, передаст содержимое логов локально развернутой модели MiniMax и сохранит готовый отчет обратно в Object Storage. Пишем скрипт для анализа логов Создадим отдельное Python-окружение для клиентского скрипта: Установим зависимости: Создадим файл: В него добавляем скрипт с анализом, промптом и требуемой структурой отчета. Полный скрипт вынесен в отдельный листинг, чтобы не перегружать инструкцию. Передаем параметры подключения Экспортируйте переменные окружения: export S3_BUCKETminimax-nginx-demo; export S3_ENDPOINThttps://s3.ru-7.storage.selcloud.ru; export ACCESS_KEY_ID ; export SECRET_ACCESS_KEY ; export DEFAULT_REGIONru-7. Параметры локального API модели уже заданы в скрипте. При необходимости их можно переопределить: Что делает скрипт Написанный на Python скрипт полностью автоматизирует клиентскую часть нашего пайплайна. Он подключается к S3-бакету, скачивает из префикса input/ подготовленный лог-файл вместе с файлами контекста и объединяет их в единый структурированный промпт. Затем этот текстовый массив передается в локальный OpenAI-совместимый API движка vLLM. После того как модель завершает генерацию, скрипт принимает ответ, сохраняет его на сервере в виде файла Markdown и автоматически загружает итоговый инженерный отчет в бакет по пути output/. Учитывайте, что этот процесс универсален. В реальном продакшен-контуре вместо трех демонстрационных файлов скрипт может точно так же собирать и агрегировать любые отфильтрованные логи, метрики систем мониторинга, конфигурации инфраструктуры, историю последних релизов и внутренние инструкции компании. Ограничение объема входных данных В клиентском скрипте заданы ограничения: Первый параметр ограничивает чтение отдельного файла, второй — общий объем документов, включаемых в запрос. Модель запущена с max-model-len32768, а для ответа зарезервировано до 6 000 токенов. Поэтому объем входного текста дополнительно ограничен: фактическое число токенов зависит от содержимого и определяется токенизатором модели, а не количеством символов. Демонстрационный скрипт анализирует только начальный фрагмент NGINX logs. В продакшене вместо простого обрезания лучше использовать предварительную выборку: временной диапазон инцидента, ошибки 4xx/5xx, проблемные endpoint, редкие user agents, trace ID и агрегированную статистику. Запуск анализа Перед тем как запустить автоматизацию, ещё раз убедитесь, что инференс-движок vLLM полностью загрузился и готов принимать входящие соединения: Далее запустите скрипт: python analyze_nginx_logs.py Пример ожидаемого вывода: Проверяем отчет в S3 Проверьте, что файл появился в каталоге output/ бакета: В списке должен появиться объект: output/nginx_log_analysis_report.md. Скачайте отчет на сервер: Откройте файл: Скрипт также сохраняет локальную копию отчета: В результате должен получиться структурированный Markdown-отчет со сгруппированными наблюдениями. Пример ниже показывает формат результата. Модель работает только с переданным фрагментом данных и не имеет доступа к метрикам, трейсам, истории релизов и конфигурации инфраструктуры, если они не включены в контекст. Что получилось в результате Мы развернули не отдельный «анализатор NGINX logs», а базовый self-hosted контур для обработки внутренних инженерных данных с помощью крупной языковой модели: В статье вместо внутренних данных использованы публичные NGINX sample logs. Однако архитектура остается той же для более содержательных сценариев: incident triage, подготовки RCA-черновиков, анализа изменений конфигурации, сопоставления логов с runbook и формирования технического резюме. Object Storage хранит входные артефакты и результаты, а GPU-сервер используется как инференс-слой. Это позволяет независимо управлять жизненным циклом вычислительных ресурсов и данных. Что важно учитывать при интерпретации отчета LLM не заменяет полноценную систему observability. В этой инструкции модель работает с выгрузкой логов, которую мы передали в промпт. Она не видит метрики, трейсы, конфигурацию балансировщика и историю деплоев, если эти данные не добавлены во входной контекст. Поэтому отчет модели — первичный triage, а не источник истины. Любой вывод нужно сверять с метриками, трейсами, конфигурацией и временной шкалой инцидента. Для продакшен-сценария в промпт стоит добавлять больше контекста: временной интервал инцидента; версию сервиса; changelog или release notes; конфигурацию NGINX; информацию об upstream-сервисах; метрики latency и error rate; runbook или правила эскалации. Чем точнее входной контекст, тем полезнее будет итоговый отчет. Описанную схему также можно расширять: обрабатывать несколько файлов логов; добавить предварительную агрегацию; сохранять технические артефакты в S3; подключить регулярный запуск через cron, systemd timer или CI/CD.

Инференс

Зарегистрируйтесь в панели управления