Когда задача — не чат-бот, а конвейер обработки инфраструктурных алертов, выбор языковой модели превращается в инженерную задачу с конкретными ограничениями. Автор цикла статей на Habr строит self-hosted систему анализа событий Zabbix на домашнем сервере: устаревший CPU, никакого выделенного GPU, Docker внутри виртуальной машины, рядом работают другие контейнеры.
Главное требование к модели — не интеллект в широком смысле, а дисциплина. Система должна проводить триаж событий уровня Warning и ниже, формировать краткие диагностические рекомендации и выполнять корреляцию алертов там, где нет готовой детерминированной логики. Модель, которая хорошо пишет эссе, но не держит формат JSON-ответа от запроса к запросу, для такой задачи бесполезна.
| Критерий | Соответствие Qwen3.5-4B |
|---|---|
| Локальный запуск без облачных API | Соответствует — готовый тег qwen3.5:4b в Ollama, запуск на localhost:11434 |
| Качество следования точным инструкциям | Частично соответствует — линейка позиционируется как «utility and performance» |
| Скромные требования к ресурсам | Соответствует — 4B параметров, работает без GPU |
| Скорость инференса | Приемлемо для событийного пайплайна на домашнем сервере |
| Предсказуемость поведения | Соответствует — модель не склонна к длинным рассуждениям |
| Работа в Ollama без кастомных сборок | Соответствует — стандартный тег, без конвертации |
| Разумная квантизация | Соответствует — доступны квантизированные версии |
| Лицензия и доступность | Соответствует — открытый доступ для локального использования |
Автор сформулировал восемь критериев отбора. Первый и принципиальный — локальный запуск без внешних API: алерты содержат чувствительные данные (IP-адреса, имена хостов), а архитектура изначально строилась с минимальной зависимостью от облачных сервисов. Второй критерий — качество следования точным инструкциям при коротких запросах, а не максимальная общая мощность. Третий — скромные требования к ресурсам. Четвёртый — скорость инференса: если триаж занимает десятки минут, очередь растёт, а результат теряет актуальность ещё до того, как его прочитают. Пятый — предсказуемость: модель не должна «уходить в рассуждения» или менять структуру ответа без причины. Шестой — нормальная работа в Ollama без кастомных сборок и конвертаций. Седьмой — разумная квантизация.
Ключевые критерии отбора: скорость инференса, предсказуемость формата ответа, разумная квантизация и отсутствие зависимости от внешних API.
Квантизация заслуживает отдельного пояснения. Это метод сжатия весов модели до типов данных с меньшей точностью — например, с float32 до int4 или int8. Результат: меньше памяти, выше скорость инференса, но потенциально ниже стабильность следования формату. Для домашнего сервера квантизация неизбежна; вопрос лишь в том, насколько модель сохраняет полезность после сжатия. Восьмой критерий — лицензия: правовая возможность запускать модель локально и использовать её в дальнейших проектах.
По совокупности критериев выбор пал на Qwen3.5-4B. Модель семейства Qwen разрабатывается командой Alibaba и позиционируется как «utility and performance» — то есть ориентирована на прикладные задачи, а не на академические benchmark'и. Для неё в Ollama есть готовый тег qwen3.5:4b, запуск одной командой, локальный API на localhost:11434. К моменту публикации статьи вышла Qwen3.6, однако основное улучшение там касается генерации кода, а версии на 4B параметров в новом семействе нет — для ресурсоограниченного домашнего стенда это принципиально.
Отдельного внимания заслуживает архитектурный подход автора: весь код проекта на 99% написан самой нейросетью, но только после того, как человек сформулировал техническое задание, выбрал модель и спроектировал высокоуровневую архитектуру. Такая последовательность — ТЗ, критерии, HLD, LLD, реализация — позволила нейросети работать внутри заранее заданных ограничений, не подменяя архитектурное мышление. Детали реализации и результаты автор обещает раскрыть в третьей и четвёртой частях цикла.
