Введение

Это вторая статья из цикла о том, как при правильно поставленной задаче и грамотном подходе к архитектуре можно собрать реализацию self-hosted системы по анализу алертов при помощи локально развернутой LLM с участием нейросети, как исполнителя.

В первой части рассматривалась постановка задачи, формирование ТЗ и пояснения, почему для нейросети лучше ставить правильные, четкие задачи. В этой же части рассмотрим выбор локальной LLM под нашу задачу.

Часть 1: Вводная и формирование ТЗ

Часть 2: Выбор локальной LLM (Вы здесь)

Часть 3: Формирование HLD и немного LLD

Часть 4: Что из этого вышло

Из практического опыта работы, подход к задаче начался не с кода (в целом код был отдан на 99% нейросети, но об этом в следующих статьях), а с привычного для любого инфраструктурного проекта шагов:

• ТЗ (в предыдущей части);

• критерии выбора локальной LLM;

• архитектурное решение приложения (HLD);

• детализация (LLD);

• реализация.

Причины выбора локальной модели

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

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

Для текущего проекта модель должна быть не просто чатом для общения, а выполнять конкретные функции, указанные в ТЗ (в прошлой статье). То есть выбор должен быть основан так же по определенным критериям.

Обобщенно:

• осуществлять триаж событий уровня Warning и ниже (низкая критичность);

• осуществлять формирование рекомендаций только для диагностики;

• выполнять корреляцию при отсутствии детерминированной логики;

• работать в локальном контуре.

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

• получение быстрого ответа на домашнем сервере;

• интеграцию через Ollama для упрощения взаимодействия.

Критерии выбора модели

Для указанной задачи в разрезе прикладной инфраструктурной системы были выделены следующие критерии.

1. Возможность локального запуска без облачной зависимости и API внешнего провайдера.

Причинами данного решения были:

• уведомления и контекст алертов содержать чувствительные инфраструктурные данные (имена, IP-адреса и т.д.);

• подход к построению домашней инфраструктуры изначально подразумевал минимальную зависимость от внешних сервисов;

• получение воспроизводимой схемы развертывания в другой инфраструктуре в случае отладки или миграции.

2. Достаточность качества при следовании точным инструкциям и кратком анализе

От модели требуется:

• работать по шаблону;

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

• поддерживать краткую уверенную стилистику;

• возвращать структурированный результат.

Другими словами, от модели не требуется написание текстов, моделирование многослойного агентного поведения или генерации кода.

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

3. Требование к ресурсам и размер

Один из ключевых моментов, т.к. собиралось для домашнего сервера без выделенного GPU с устаревшими CPU, еще и в Docker внутри ВМ. Модель должна быть не слишком требовательная, при этом давая приемлемый latency для событийного пайплайна, так как параллельно на той же ВМ будут работать и другие проекты в контейнерах.

4. Скорость инференса

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

• растет очередь;

• audit log становится бесполезным в реальном времени;

• происходят критические задержки до получения результата с потерей актуальности информации.

Таким образом важен баланс между качеством ответа и скоростью подачи.

5. Предсказуемость поведения

Модель не должна быть излишне творческой, т.к. задача у нее в проекте не быть чат-бот ассистентом. Соответственно модель не должна:

• уходить в длинные рассуждения;

• выдумывать что-то за пределами строгих рамок;

• менять формат ответа от запроса к запросу;

• развертывать ответ за пределами поставленной задачи.

В проекте изначально заложены строгие ограничения, однако и сама модель из коробки должна быть послушна в следовании инструкциям.

6. Нормальная работа в Ollama

Критерий для упрощения развертывания и взаимодействия. Модель должна быть:

• доступной по тегу;

• без проблем тянуться;

• стабильно существовать в локальной системе;

• не требовать отдельной сборки;

• не требовать кастомной конвертации или runtime.

Чем меньше нестандартных телодвижений – тем проще будет интеграция.

7. Разумная квантизация

При изучении основных параметров для меня это понятие было самым сложным для понимания, т.к. часто упоминается вскользь. На деле – это так же важный критерий при запуске локально (тем более в домашнем контуре), поэтому рассмотрю квантизацию отдельным подпунктом.

Что такое квантизация для проекта?

Квантизация — это способ уменьшить размер модели и требования к ресурсам (памяти) за счет представления весов в более компактной форме (температура модели).

Иными словами квантование – это метод снижения вычислительных затрат и затрат памяти на инференс путем представления весов и активаций с помощью типов данных низкой точности.

Мне очень помогла о представлении вот эта статья на Хабре.

Для проекта это будет значить уменьшение потребления ресурсов, порога входа self-hosted среды и повышения общей скорости модели.

Однако существует ряд минусов:

• возможна потеря качества;

• возможно падение стабильности следования формату.

В локальном проекта квантизация неизбежна, но остается вопрос, насколько модель сохраняет полезность после квантизации.

Что было важно для текущего проекта

Для моего пайплайна модель в квантизированном виде должна была остаться полезной для триажа, коротких и структурированных вердиктов, рекомендаций с ограничением на безопасную диагностику, fallback корреляцию (вспоминаем ТЗ).

8. Лицензия и практическая доступность

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

Поэтому необходимо понимать:

• правовую возможность тянуть и запускать локально;

• ограничения на использование;

• актуальность экосистемы вокруг модели.

Какая же модель выбрана?

Суммаризируя все критерии и отсеяв по ним предложения, выбор пал на Qwen3.5-4B.

Пройдем по чек-листу

Сравнение с другими моделями

Основная задача была не в выборе лучшей небольшой модели, а наиболее приемлемой для локального пайплайна.

Поэтому в первую очередь сравнение было с близкими по назначению малыми моделями – Llama3.2-3B и Gemma3-4B.

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

Размерная линейка

У Meta в текстовой lightweight-линейке Llama 3.2 доступны 1B и 3B модели. То есть ближайший малый вариант - это 3B, а следующего шага на 4B внутри той же lightweight-линейки просто нет. Официальная карточка прямо указывает, что текстовые Llama 3.2 - это именно 1B и 3B модели с контекстом 128K.

У Gemma 3 линейка шире: 270M, 1B, 4B, 12B и 27B; в Ollama отдельно указано, что 4B-модель (так же, как и остальные) относится к multimodal-вариантам с контекстом 128K.

У Qwen3.5 в Ollama размерная линейка выглядит более плавной: 0.8B, 2B, 4B, 9B, 27B, 35B и 122B. На странице тегов Ollama для семейства Qwen3.5 прямо видны эти размеры, а для актуального тега указывается контекст 256K.

Это не доказательство качества той или иной модели, но дает информацию о позиционировании в самом семействе.

Сравнение по контекстному окну

Для текущего сценария длинный контекст не является главной причиной выбора. Однако полностью отбрасывать его нельзя, так как при обогащении информацией алерта, audit log, корреляции с соседними событиями (RCA) и пояснениями, промпт может увеличиваться.

У Qwen3.5-4B в официальной карточке на Hugging Face указан default context length 262,144 tokens, и отдельно отмечено, что при OOM можно снижать окно, но для сохранения thinking capabilities рекомендуется держать не менее 128K.

У Gemma 3 4B в Ollama и модельной карточке фигурирует 128K context window.

У Llama 3.2 3B официально указан 128K context length.

Исходя из этого получаем, что Qwen дает запас по контексту среди моделей своего класса.

Сравнение по лицензированию

Qwen3.5-4B в карточке на Hugging Face указана лицензия Apache 2.0.

У Llama 3.2 используется Llama 3.2 Community License - собственная лицензия Meta.

У Gemma модели поставляются с open weights и допускают "ответственное коммерческое использование", но это отдельный набор условий Google/Gemma Terms of Use.

Для пет-проекта это не критично, но глобально Apache 2.0 делает модель более предсказуемой с точки зрения лицензирования при включении в собственный self-hosted стек.

Вывод

Из 3-х основных требований, по которым проводилось сравнение близких малых LLM мне больше подошла Qwen3.5-4B.

Итог второго этапа

В данной статье была рассмотрена методология выбора локальной LLM в рамках имеющейся задачи и соответствующий выбор.

Данный шаг я решил выделить до HLD и LLD по нескольким причинам:

• у меня до этого не было никакого опыта с локальными LLM и базовые понятия были всего лишь пустым звуком, поэтому необходимо было наверстать упущенное;

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

Изыскания по выбору модели действительно были интересными и дали более полноценное понимание работы этого инструмента.

Что будет дальше

В следующей статье уже перейдем к дизайну проекта, разберем, какие вещи в архитектурном планировании можно отдать нейросети (конечно же не бесконтрольно), представлю полученную архитектуру, и, через статью, перейду к реализации и описанию результата.