Локальный запуск LLM для SOC: сколько инцидентов обработает одна GPU? Часть 2

Всем привет! На связи Сергей Иванов, аналитик технологий машинного обучения ^[1] R‑Vision.

В первой части эксперимента ^[2] мы выяснили, как на производительность локальной LLM влияют длина контекста, количество параллельных запросов и объем генерируемого ответа. Стресс‑тесты позволили определить границы конфигурации Qwen3.5–122B‑A10B‑GPTQ, vLLM и NVIDIA RTX PRO 6000 Blackwell Max‑Q с 96 GB видеопамяти.

Однако предельная конкурентность и скорость генерации сами по себе еще не показывают, насколько такая конфигурация подходит для реального SOC. В промышленном сценарии запросы поступают не равномерно и не изолированно. Они создаются карточками инцидентов, шагами ИИ‑оркестратора и действиями аналитиков, а порядок их выполнения определяется логикой ^[3] расследования.

Во второй части эксперимента мы перешли от лабораторных измерений к моделированию реальной работы SOC. Мы оценили, как GPU справляется с инференсом LLM при разной численности команды и интенсивности потока инцидентов — от спокойной смены до пиковых ситуаций с массовым поступлением новых инцидентов. Важно отметить, что в эксперименте использовались не специально подготовленные тестовые примеры, а анонимизированные реальные инциденты из практики нашего внутреннего SOC.

Отдельно остановимся на режиме рассуждений. В сценарии интеграции LLM в конвейер R‑Vision SOAR мы сознательно использовали модель с отключенным thinking mode (режимом рассуждений). Ниже на результатах реальных экспериментов покажем, почему именно такой режим оказался наиболее эффективным для задач SOC.

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

Моделирование нагрузки для SOC разной численности

Какие задачи в SOC мы поручили LLM

Прежде чем перейти к моделированию нагрузки в SOC стоит отдельно остановиться на том, для каких задач использовался ИИ в нашем SOC:

1. Ранжирование инцидентов: определение приоритетности открытых инцидентов.

2. Суммаризация: подготовка краткого описания ключевых событий, активов и артефактов.

3. Поиск недавних схожих инцидентов: сопоставление с событиями за ограниченный период.

4. Ретроспективный поиск: анализ более глубокой истории и поиск связанных расследований.

5. Предварительный вердикт: формирование вывода на основе результатов предыдущих шагов.

Оценка производительности GPU для инференса LLM при различной численности SOC

Для оценки применимости LLM в реальной эксплуатации мы смоделировали работу SOC при двух типовых сценариях нагрузки для конфигурации с RTX PRO 6000 и Qwen3.5–122B‑A10B:

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

• пиковую нагрузку при массовом поступлении инцидентов.

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

Два типа нагрузки

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

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

Ранжирование 12 открытых инцидентов требует около 100 тыс. токенов контекста. Для остальных операций типичный объём составляет примерно 10–20 тыс. токенов, однако запросы поступают пачками и выполняются параллельно.

Интерактивный чат аналитика. Аналитик L1/L2 открывает карточку инцидента и задаёт вопросы ИИ‑ассистенту. В модель передаются поля инцидента, связанные события и активы, результаты обогащения, а также история предыдущих сообщений.

Контекст одной такой сессии может достигать 60–100 тыс. токенов. При этом конкурентность обычно невысока: один аналитик отправляет один‑два запроса одновременно.

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

Разделение пулов нагрузки

Чтобы фоновые задачи не занимали все доступные ресурсы, потоки можно разделить с помощью AI Gateway — промежуточного слоя, который маршрутизирует запросы к vLLM, управляет очередями и учитывает доступный объём видеопамяти.

В нашем сценарии ресурсы распределяются следующим образом.

Пул «Интерактив»:

• высокий приоритет;

• контекст до 120 тыс. токенов;

• не более пяти одновременных запросов;

• минимизация времени ожидания и TTFT.

Пул «Фон SOAR»:

• более низкий приоритет;

• контекст до 30 тыс. токенов;

• до 11 одновременных запросов;

• возможность пакетной обработки и ожидания в очереди.

Суммарная конкурентность при такой конфигурации не превышает установленный в vLLM лимит —-max-num-seqs 16.

При этом одного подсчёта запросов недостаточно. AI Gateway также должен учитывать длину контекста: пять запросов по 100 тыс. токенов создают значительно более высокую нагрузку на KV‑cache, чем пять запросов по 10 тыс. токенов.

Сценарий 1. Спокойная смена

Состав смены: 3–5 аналитиков L1/L2.
Входящий поток: 10–15 инцидентов в час.

Фоновая нагрузка

SOAR‑оркестратор обрабатывает инциденты по мере поступления. Как показал эксперимент, полный цикл обогащения одного инцидента занимает около 60 секунд.

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

Интерактивная работа

Одновременно два‑три аналитика могут обращаться к ИИ‑ассистенту по своим расследованиям.

Потребление ресурсов

Общая конкурентность в таком сценарии обычно составляет 8–10 запросов и лишь периодически достигает 10–12.

При условии, что контекст интерактивных сессий остаётся заметно ниже предельных 120 тыс. токенов, у системы сохраняется запас по числу последовательностей и объёму KV‑cache.

Однако фактические показатели TTFT и потребления памяти ^[4] необходимо проверять на реальном профиле нагрузки. Несколько длинных диалогов или карточек с большим количеством связанных данных могут существенно изменить ситуацию даже при том же количестве запросов.

Для небольшого SOC одной RTX PRO 6000 может быть достаточно, если входящий поток остаётся умеренным, а длина контекста и очереди контролируются на уровне AI Gateway.

Сценарий 2. Массовое поступление инцидентов

Состав смены: 5–7 аналитиков, включая привлечённых специалистов L2/L3.
Входящий поток: 50–100 инцидентов за короткий период.

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

Фоновая нагрузка

Допустим, оркестратор ставит в очередь 50 инцидентов на обогащение.

Если все 16 последовательностей доступны фоновому конвейеру, на первой фазе можно одновременно обрабатывать до четырёх инцидентов:

4 инцидента × 3 запроса = 12 запросов.

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

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

3 инцидента × 3 запроса = 9 запросов.

Ещё два слота остаются для вердиктов, ранжирования или других фоновых задач.

При длительности полного цикла около одной минуты очередь из 50 инцидентов может быть обработана примерно за 15–20 минут. Это расчётная оценка для экспериментального профиля запросов. Увеличение контекста или длины ответов снизит пропускную способность.

Интерактивная работа

Одновременно три‑пять аналитиков работают с наиболее критичными инцидентами. Их запросы должны получать более высокий приоритет, поскольку задержка в чате непосредственно влияет на скорость расследования.

Управление ресурсами

Без отдельного управляющего слоя длинные интерактивные сессии могут занять значительную часть KV‑cache. Например, пять чатов с контекстом около 100 тыс. токенов каждый создадут существенно более высокую нагрузку, чем фоновые запросы по 10–20 тыс. токенов.

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

AI Gateway позволяет управлять этой нагрузкой:

• резервировать ресурсы для интерактивного чата;

• ограничивать максимальную длину контекста;

• оценивать стоимость запроса до его передачи в vLLM;

• помещать фоновые задачи в управляемую очередь;

• менять приоритет в зависимости от критичности инцидента;

• не запускать одновременно слишком много тяжёлых запросов.

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

Сколько инцидентов обработает одна RTX PRO 6000

Внедрение LLM в SOC меняет саму парадигму работы аналитика. Вместо того чтобы тратить время на чтение сырых логов и на изучение связанных активов, аналитик получает инцидент, уже обогащенный ИИ: с суммаризацией, оценкой схожести и предварительным вердиктом.

Как мы выяснили в эксперименте с нашими инцидентами, полный цикл автоматического обогащения одного инцидента (4 шага) занимает ~60 секунд. При обработке инцидентов среднего размера (10k–20k токенов) ограничителем выступает не скорость инференса, а лимит конкурентности ‑max‑num‑seqs 16. Пик конкурентности на один инцидент приходится на фазу сбора аналитики (3 параллельных запроса). Следовательно, система способна одновременно обрабатывать до 5 инцидентов (5 инцидентов × 3 запроса = 15 активных потоков).

Таким образом, максимальная пропускная способность одной RTX 6000 Pro для фонового конвейера SOAR под наш набор данных составляет:

• 5 инцидентов в минуту

• 300 инцидентов в час

• 7 200 инцидентов в сутки

MoE‑архитектура дает интеллект ^[5] 122B модели со скоростью генерации модели на 10B, а отключение режима размышлений позволяет получать точные вердикты без задержек. Использование более легких моделей заставило бы либо отказаться от сложных вердиктов, либо резко сократить объем контекста по инциденту, что неприемлемо для зрелых ИБ‑процессов.

Выбор модели и режима работы LLM

Чтобы корректно интерпретировать результаты эксперимента, необходимо учитывать технические особенности используемой LLM. Ниже рассмотрим, почему для эксперимента была выбрана именно Qwen3.5–122B‑A10B и какую роль в задачах SOC играет режим рассуждений.

Выбор модели для эксперимента

Для прикладного теста мы сохранили ту же конфигурацию, которая использовалась в первой части статьи: Qwen3.5–122B‑A10B‑GPTQ.

Qwen3.5–122B‑A10B построена на архитектуре Mixture of Experts. Модель содержит 122 млрд параметров, но при формировании каждого токена активируется около 10 млрд. Это снижает объем вычислений по сравнению с плотной моделью аналогичного общего размера, хотя веса всех экспертов по‑прежнему должны находиться в видеопамяти.

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

При работе с длинными последовательностями необходимо учитывать эффект Lost in the Middle ^[6]: качество извлечения информации может снижаться, если важные сведения расположены в середине большого контекста. Сам по себе размер модели не гарантирует решения этой проблемы, поэтому способность работать с реальными карточками инцидентов необходимо проверять экспериментально.

Qwen3.5 использует гибридную архитектуру, сочетающую слои Gated DeltaNet (линейное внимание ^[7]) и механизм полного внимания. Вместе с большой общей емкостью модели это делает ее подходящим кандидатом для проверки сложных сценариев с длинным контекстом. Но наш эксперимент не доказывает, что модель класса 122B необходима для любого SOC: более компактные модели также нужно сравнивать на конкретных данных и задачах.

Сравнение thinking и non‑thinking режимов

Результаты свежих отраслевых бенчмарков для SecOps — CyberSOCEval от Meta и CrowdStrike ^[8], а также AI SOC LLM Leaderboard от Simbian ^[9] — показывают общую тенденцию: более крупные современные модели часто лучше справляются с комплексными задачами анализа угроз. При этом преимущество зависит не только от количества параметров, но и от состава обучающих данных, архитектуры модели, промпта и конкретного сценария.

Это важно и для reasoning‑моделей. Способность выполнять длинную цепочку рассуждений не гарантирует автоматического улучшения каждого SecOps‑сценария. В задачах с большим количеством зашумленных данных дополнительные рассуждения могут как помочь модели обнаружить сложную связь, так и привести к построению лишних гипотез.

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

Эксперимент: обработка инцидентов в R‑Vision SOAR

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

Входные данные по задачам были следующими:

Отдельно выполнялось ранжирование всех открытых инцидентов. Системный и пользовательский промпты для этого шага составили в сумме 15 793 токена.

График показывает, что pipeline обработки разбит на две фазы: сначала выполняется 6 параллельных запросов — суммаризация и два поиска схожести по двум инцидентам, а затем 2 параллельных запроса — вердикты.

Важно понимать, что такая последовательность обусловлена бизнес‑логикой ИИ оркестратора, а не аппаратными ограничениями. Предварительный вердикт невозможно сформировать без данных о суммаризации и схожести, поэтому SOAR в этом кейсе дожидается завершения первых шагов перед отправкой промптов для вердикта.

С точки зрения ^[10] железа, RTX 6000 Pro в этом сценарии даже не приближается к пределу. В стресс‑тестах предел конкурентности для контекста 120K токенов составил около 7 запросов. Но в нашем SOC один инцидент (системный промпт, данные по инциденту, логам, связанны активам и иной полезной информации) обычно весит 10K-20K токенов. Это означает, что физический лимит VRAM позволяет держать в одновременной обработке больше таких запросов, упираясь уже в лимит конфигурации vLLM (‑max‑num‑seqs 16).

В ходе эксперимента GPU обрабатывала 6 запросов по 10–12K токенов без заметного напряжения, завершив этап сбора аналитики примерно за 30 секунд, а этап формирования вердиктов — за следующие 30 секунд.

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

По графику видно кратное увеличение времени инференса при выполнении тех же сценариев в режиме последовательных рассуждений. Чтобы понять целесообразность таких вычислительных затрат, нужно оценить, насколько меняется качество ответов при активации thinking mode.

Для верификации результатов был применен метод автоматической экспертизы LLM‑as‑a‑judge. В роли независимого судьи выступала модель GPT-5.5 Thinking. Оценка каждого сценария проводилась по пяти ключевым метрикам SecOps: фактологическая корректность, следование заданной структуре ответа, качество корреляционных связей, полнота финального вердикта, реализуемость предложенного плана реагирования ^[11].

Ниже приведены агрегированные результаты оценки по 100-балльной шкале для двух комплексных инцидентов.

Как показывают данные бенчмарка, активация режима рассуждений дает нестабильный результат. С одной стороны, в сложных аналитических задачах (например, вынесение вердикта в Инциденте 2) модель демонстрирует выраженный качественный скачок. С другой стороны, в сценариях ретроспективного поиска и детекции схожести включение логических слоев привело к ухудшению оценок судьи. Это связано с эффектом «избыточного мышления» (overthinking), когда модель начинает искать ложные взаимосвязи в зашумленных массивах исторических логов и галлюцинировать на пустом месте.

С точки зрения построения контура SOC, режим рассуждений показал себя экономически и технически неэффективным на длинной дистанции. Минимальный и волнообразный прирост качества в базовых сценариях не оправдывает экспоненциальный рост нагрузки на вычислительные ресурсы (Compute) и критическое падение скорости отклика системы. На основании этого для промышленной эксплуатации архитектуры был выбран режим быстрой генерации (non‑thinking mode) большой MoE‑модели, обеспечивающий стабильный баланс бизнес‑метрик.

Вывод

Мы не пытаемся доказать, что одна GPU способна закрыть потребности ^[12] любого SOC. Результаты показывают другое: для стартовой автоматизации конкретных SOAR‑сценариев одной профессиональной видеокарты этого класса может быть достаточно.

Self‑hosted LLM не заменяет SOC‑команду и не превращается в полностью автономного аналитика. Но уже сейчас она может работать как прикладной ИИ‑сервис для рутинных задач: ранжировать инциденты, готовить суммаризацию, искать схожие события, формировать историческую справку и предварительный вердикт, а также помогать аналитику в интерактивном чате.

Устойчивость такого контура определяется не только производительностью GPU. Не менее важны выбор модели, настройка инференса, ограничения длины контекста, управление KV‑cache и разделение фоновых и интерактивных запросов.

При правильной архитектуре система может работать внутри контролируемого контура, не передавать чувствительные данные внешним сервисам и давать SOC‑команде практический выигрыш без развёртывания крупного GPU‑кластера. В спокойном режиме одна RTX PRO 6000 способна одновременно обслуживать фоновое обогащение инцидентов и несколько интерактивных сессий, а при пиковом поступлении событий — сохранять доступность чатов аналитиков за счёт приоритизации и управляемой очереди фоновых задач.