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

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

Когда речь заходит о локальном запуске больших языковых моделей, обычно первым возникает вопрос стоимости инфраструктуры: «Self-hosted LLM — это десятки или сотни GPU?». Для обучения foundation-моделей или публичных сервисов с миллионами пользователей это действительно так. Но применение LLM внутри SOC устроено иначе.

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

Именно поэтому естественной точкой интеграции LLM становится SOAR. Этот класс решений уже объединяет данные из разных систем: события SIEM, информацию об активах из CMDB, данные Threat Intelligence, сведения об уязвимостях, результаты работы EDR и других средств защиты. К моменту запуска AI-сценария большая часть необходимого контекста уже собрана и структурирована.

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

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

В таком случае главный вопрос звучит уже не «можно ли запустить большую модель локально?», а «какие ресурсы действительно нужны для конкретных задач SOC?». Что сильнее влияет на производительность — количество параметров модели или длина контекста? Почему в реальных сценариях объем видеопамяти может быть важнее вычислительной мощности? Сколько параллельных запросов сможет обработать одна GPU и где находится практический предел конкурентности?

Чтобы ответить на эти вопросы, мы провели серию экспериментов на self-hosted-стенде с использованием Qwen3.5-122B-A10B-GPTQ, vLLM и RTX PRO 6000 Blackwell Max-Q с 96 GB GDDR7.

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

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

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

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

Материал будет полезен ML-инженерам, работающим с LLM, а также CISO и SOC-командам, которые оценивают применение генеративного ИИ в задачах кибербезопасности.

Почему именно Qwen3.5-122B-A10B

Для экспериментов мы выбрали Qwen3.5-122B-A10B-GPTQ. На первый взгляд такое решение может показаться неожиданным: модель содержит более 120 миллиардов параметров, а значит должна предъявлять высокие требования к вычислительным ресурсам. Однако это впечатление обманчиво. Qwen3.5 построена на архитектуре Mixture of Experts (MoE). Несмотря на общий размер в 122 млрд параметров, при генерации каждого токена активируется лишь небольшая часть модели — около 10 млрд параметров. Благодаря этому вычислительная нагрузка оказывается значительно ниже, чем можно ожидать.

При использовании GPU для инференса все веса модели должны находиться в видеопамяти, даже несмотря на то, что в каждый момент времени задействована только часть параметров. В рамках этой статьи мы рассматриваем именно такой сценарий, поскольку он позволяет обеспечить достаточную скорость ответа ИИ-сервиса для задач SOC. Варианты, при которых часть весов модели выгружается в оперативную память (RAM), сознательно не рассматривались из-за существенного снижения производительности.

Именно поэтому для self-hosted-инференса важно смотреть не только на количество параметров модели. Производительность определяется сразу несколькими факторами: архитектурой модели, объемом KV Cache, механизмами работы движка инференса и особенностями управления длинным контекстом. Разберем каждый из них подробнее.

1. Dense (плотные) архитектуры, например Qwen3.5-27B,

Принцип: при генерации каждого токена активируются все параметры модели.

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

Минусы: высокие требования к вычислительной мощности (FLOPs). Требования к VRAM и compute растут почти линейно с размером модели; запуск Dense-модели на 100B+ обычно требует multi-GPU сервера.

2. MoE (Mixture of Experts) архитектуры, например Qwen3.5-122B-A10B.

Принцип: модель состоит из множества «экспертов». Для каждого токена маршрутизатор выбирает только несколько активных экспертов.

Пример: Qwen3.5-122B-A10B имеет 122B общих параметров, но около 10B активных параметров на токен. Вычислительно она ближе к модели меньшего класса, но хранит знания и признаки гораздо более крупной сети.

Плюсы: высокое качество при меньших активных вычислениях на токен, экономия compute.

Минусы: большее потребление VRAM, потому что веса всех экспертов все равно нужно держать в памяти.

MoE позволяет уместить крупную модель класса 100B+ в одну мощную рабочую станцию, жертвуя объемом VRAM под веса, но выигрывая в скорости генерации по сравнению с плотной моделью сопоставимого общего размера. Многие современные флагманские открытые модели переходят к MoE-архитектурам, хотя на рынке остаются и крупные Dense-модели. Дополнительное преимущество MoE — возможность разделять модель на несколько устройств при определенных условиях и не терять скорость так резко, как в плотных моделях.

Эволюция механизма внимания: гибрид DeltaNet + GQA

Стоит отдельно рассмотреть, как устроена работа с контекстом в Qwen3.5. В отличие от классических трансформеров, требующих полноформатный KV-cache на каждом слое, Qwen3.5-122B использует гибридный подход. Модель состоит из 48 слоев, которые чередуются в пропорции 3:1:

• 3 слоя Gated DeltaNet (линейное внимание). Работают по принципу рекуррентных сетей, обновляя фиксированное скрытое состояние, которое не растет с длиной текста. Для этих слоев не нужен полноценный исторический KV-cache: затраты памяти не растут пропорционально числу токенов.

• 1 слой Gated Attention (классическое внимание). Обычный механизм с Grouped-Query Attention (GQA), требующий сохранения KV-cache для каждого токена.

Это означает, что полноразмерный KV-cache сохраняется только для каждого четвертого слоя. На практике это снижает потребление памяти на длинный контекст по сравнению с классическими MoE-архитектурами, где KV-cache нужен на каждом attention-слое.

PagedAttention, квантизация и DeltaNet

Чтобы модель с 122 миллиардами параметров и контекстом в 120 000 токенов могла работать на одной видеокарте, требуется комбинация трех технологий.

1. PagedAttention: борьба с фрагментацией

Традиционно KV-cache выделялся одним сплошным блоком под максимальную длину запроса, что приводило к фрагментации: реально использовалось не все зарезервированное место. vLLM с алгоритмом PagedAttention разбивает KV-cache на маленькие блоки, или страницы, которые размещаются в VRAM динамически по мере роста запроса. Это устраняет фрагментацию и позволяет увеличивать пропускную способность в 2-4 раза в сценариях, описанных авторами vLLM/PagedAttention.

2. Квантизация весов и кэша: сжатие данных

• Веса модели (GPTQ-INT4). Сжатие весов из 16-битного формата в 4-битный уменьшает размер модели с порядка 244 GB до порядка 61 GB и позволяет загрузить ее в 96 GB VRAM.

• KV-cache (FP8). Использование 8-битной плавающей запятой для кэша, например через флаг —kv-cache-dtype fp8, уменьшает потребление памяти под KV-cache по сравнению с FP16 и помогает длинным контекстам.

3. Архитектурная экономия: DeltaNet

Как мы выяснили выше, значительная часть слоев модели не требует полноценного KV-cache для истории токенов. Именно эта архитектурная особенность вместе с PagedAttention и FP8 KV-cache делает возможной работу с очень длинными контекстами на одной профессиональной карте.

Расчет конкурентности

Посмотрим на реальные логи запуска vLLM для Qwen3.5-122B-A10B-GPTQ-INT4 на RTX 6000 Pro:

(EngineCore pid=80) INFO 05-26 08:09:17 [gpu_model_runner.py:4808] Model loading took 68.36 GiB memory and 28.653553 seconds(EngineCore pid=80) INFO 05-26 08:11:59 [gpu_worker.py:436] Available KV cache memory: 11.76 GiB(EngineCore pid=80) INFO 05-26 08:11:59 [kv_cache_utils.py:1319] GPU KV cache size: 254,736 tokens(EngineCore pid=80) INFO 05-26 08:11:59 [kv_cache_utils.py:1324] Maximum concurrency for 120,000 tokens per request: 7.03x

Здесь выделим важные параметры:

• веса модели заняли 68.36 GiB VRAM;

• доступная память под KV-cache составила 11.76 GiB;

• vLLM зарезервировал место на 254 736 токенов кэша;

• итоговый расчет vLLM: Maximum concurrency for 120,000 tokens per request: 7.03x.

Разберем, как 254 736 слотов кэша могут обеспечить 7 одновременных запросов по 120 000 токенов, что в сумме дает 840 000 токенов. Секрет именно в DeltaNet. Движок vLLM знает структуру модели: 120 000 токенов контекста требуют физического KV-cache только для attention-слоев. Остальные слои проходят через линейные блоки и не занимают место под исторический контекст.

Связка PagedAttention, FP8-квантизации и архитектуры DeltaNet создает важный практический эффект: 11.76 GiB под кэш хватает на обслуживание нескольких тяжелых запросов с очень длинным контекстом. Как только один запрос завершается, PagedAttention возвращает освободившиеся страницы в общий пул.

Эксперименты: стресс-тесты LLM-инференса

В инференсе у видеокарты есть две основные статьи расхода памяти. Первая — веса модели. Они занимают почти фиксированный объем VRAM после загрузки. Вторая — KV-cache, то есть память под уже обработанный контекст. Именно KV-cache растет вместе с длиной промпта и количеством параллельных запросов.

Для SOC это критично. Один запрос может быть маленьким — например, извлечь IoC из карточки на 3-5 тысяч токенов. А может быть тяжелым: открыть большой инцидент с историей активов, похожими кейсами и фрагментами логов на 60-120 тысяч токенов. В обоих случаях модель одна и та же, но нагрузка на KV-cache отличается на порядок.

Полезно разделять две фазы инференса. Prefill — это чтение входного контекста. Decode — генерация ответа. Метрика TTFT показывает время до первого токена ответа, а TPOT — среднее время на каждый следующий токен. Поэтому сценарий «прочитай 120 тысяч токенов и дай короткий вердикт на 100 токенов» может оказаться тяжелее для интерактива, чем генерация длинного отчета после уже обработанного контекста: пользователь ждет первую реакцию, а GPU занят чтением огромного промпта.

Дальше идут два типа проверок. Сначала — синтетические стресс-тесты инференса: предельный контекст 120K, влияние длины генерации и цена MTP. Затем — прикладной SOAR-сценарий на реальных инцидентах, где та же конфигурация проверяется уже в логике оркестратора, очередей и параллельных шагов расследования.

Для проведения нижеописанных экспериментов мы использовали RTX 6000 Pro Blackwell (96 GB VRAM), версия Max-Q (300 W). В отличие от базовой версии на 600 W, она потребляет вдвое меньше энергии и выделяет меньше тепла, теряя при этом всего около 10-15% скорости генерации токенов на нашем профиле нагрузки.

В качестве основной модели выбрана Qwen3.5-122B-A10B-GPTQ (квантование INT4, ядро GPTQ-Marlin). Развертывание осуществлялось в Docker с использованием vLLM v0.18.1rc1.

Критически важные параметры запуска:

• —max-model-len 120000 — максимальная длина контекста, которую разрешаем модели принимать в одном запросе;

• —gpu-memory-utilization 0.95 — доля VRAM, которую vLLM может использовать под веса, KV-cache и внутренние буферы;

• —kv-cache-dtype fp8 — сжатие KV-cache до 8-битного формата, чтобы хранить больше токенов в видеопамяти;

• —max-num-seqs 16 — максимальное количество параллельных последовательностей, то есть верхний лимит одновременных запросов внутри движка;

• —enable-chunked-prefill True и —max-num-batched-tokens 32768 — включение chunked prefill, чтобы длинные промпты обрабатывались частями и не блокировали весь сервис.

Как читать размеры контекста в токенах

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

Эксперимент 1: определение максимальной конкурентности для 120K контекста

Цель: проверить, как система справляется с ростом числа одновременных запросов при предельном контексте: 119 800 токенов на вход, 100 токенов на выход. Режим рассуждений отключен.

Таблица результатов: вход около 120K, выход 100 токенов.

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

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

Выводы по эксперименту 1:

1.  Расчетный предел конкурентности около 7 запросов подтвердился. При Concurrency=5 система работает стабильно. При Concurrency=7 время до первого токена (TTFT) начинает расти до двух минут, так как prefill новых запросов выстраивается в очередь.

2.  При Concurrency=10 запросы формально не упали с OOM, однако TTFT вырос до 2.5 минут, а TPOT составил около 1.4 секунды на токен. vLLM начинает вытеснять (preempt) KV-cache в CPU-память, что приводит к большим задержкам. Работа в таком режиме неприемлема.

3.  Высокий TPOT при коротком ответе связан с включенным chunked prefill. Движок чередует обработку тяжелых чанков prefill новых запросов с генерацией единичных токенов, что снижает скорость генерации.

Эксперимент 2: влияние длины генерации на производительность

Цель: проверить, как меняется скорость генерации (TPOT), если модель переходит от короткого ответа к длинному — 10K-20K токенов на выходе.

Таблица результатов для длинного ответа:

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

Как только очередь полностью опустошается, количество активных запросов в обработке выходит на стабильный максимум. В самом начале теста, в первые 1-2 минуты, происходит лавинообразное накопление запросов. Когда очередь падает до нуля, vLLM выходит на режим максимальной параллельной обработки. После завершения обработки первого батча оставшиеся в очереди запросы формируют новый батч.

Выводы по эксперименту 2:

1.  При длинной генерации TPOT падает с сотен миллисекунд до 26-33 мс на токен. Скорость генерации около 30-38 токенов в секунду превышает скорость чтения человека. Движок эффективно утилизирует широкую шину памяти RTX 6000 Pro.

2.  Конкурентность 10 остается проблемой даже при длинных ответах: TTFT достигает 3-4 минут из-за необходимости переносить данные в оперативную память.

3.  Конкурентность 5-7 запросов при длинном контексте является рабочей серединой. Модель обеспечивает комфортную скорость генерации объемных аналитических отчетов без блокировки сервиса.

Эксперимент 3: цена спекулятивного декодирования (Multi-Token Prediction)

Современные модели внедряют механизмы Multi-Token Prediction (MTP) или speculative decoding. В этой схеме используется небольшая «голова» — вспомогательная легковесная нейросеть, которая работает параллельно с основным алгоритмом. Она быстро генерирует кандидаты-токены на несколько шагов вперед, а тяжелая основная модель верифицирует их за один проход. Мы провели серию тестов с включенной MTP-головой.

В vLLM для загрузки модели с MTP-головой была добавлена команда —speculative-config {«method»: «mtp», «num_speculative_tokens»: 1}. В нашем случае есть только одна MTP-голова, что указано в конфигурации модели: mtp_num_hidden_layers = 1. Параметр mtp_use_dedicated_embeddings = false означает, что для MTP-головы используется общее с основной моделью пространство эмбеддингов.

Логи запуска той же модели Qwen3.5-122B-A10B-GPTQ, но с MTP-головой:

vllm-qwen35-122b-gptq | (EngineCore pid=100) INFO 06-09 07:14:43 [gpu_model_runner.py:4808] Model loading took 73.06 GiB memory and 40.832187 seconds vllm-qwen35-122b-gptq | (EngineCore pid=100) INFO 06-09 07:18:12 [gpu_worker.py:436] Available KV cache memory: 11.38 GiB vllm-qwen35-122b-gptq | (EngineCore pid=100) WARNING 06-09 07:18:12 [kv_cache_utils.py:1059] Add 3 padding layers, may waste at most 8.33% KV cache memory vllm-qwen35-122b-gptq | (EngineCore pid=100) INFO 06-09 07:18:12 [kv_cache_utils.py:1319] GPU KV cache size: 226,368 tokens vllm-qwen35-122b-gptq | (EngineCore pid=100) INFO 06-09 07:18:12 [kv_cache_utils.py:1324] Maximum concurrency for 120,000 tokens per request: 5.74x

MTP съедает KV-cache

Сравним логи инициализации vLLM без MTP и с MTP:

MTP-голова заняла дополнительные 4.7 GB VRAM. Кроме того, vLLM выдал предупреждение: Add 3 padding layers, may waste at most 8.33% KV cache memory. Из-за рассинхронизации слоев движок резервировал память под «холостые» слои кэша. В результате потолок конкурентности упал с 7 до 5.74x.

Сценарий А: длинный контекст + короткий ответ (худший кейс)

Вход: 119 800 токенов. Выход: 100 токенов. Конкурентность: 7.

Сценарий 120K на вход и 100 токенов на выход оказывается худшим для инференса, потому что он почти полностью аннулирует преимущества MTP. Во-первых, большая часть времени уходит на prefill — чтение огромного контекста, где MTP-голова простаивает. Во-вторых, при генерации короткого ответа гигантский KV-cache перегружает пропускную способность памяти GPU, и основная модель тратит слишком много времени на верификацию «догадок» MTP-головы. Накладные расходы превышают выгоду, а короткий ответ не дает системе выйти на крейсерскую скорость.

При забитой VRAM MTP разрушает производительность: acceptance rate падает до 11.6%. Основная модель отвергает 88.4% предсказаний драфта, впустую тратя вычислительные ресурсы.

На графике видно, как число одновременных запросов упирается в предел 5. Из-за небольшого числа токенов для генерации основное время уходит на обработку входящего промпта.

Сценарий Б: длинный контекст + длинный ответ (лучший кейс)

Вход: 99 800 токенов. Выход: 20 000 токенов. Конкурентность: 5.

В режиме монотонной генерации MTP раскрывает потенциал: acceptance rate 85% дает прирост скорости примерно на 10-12%.

Выводы по эксперименту 3:

1.  MTP забирает критически важные гигабайты под веса и padding-слои, снижая максимальную конкурентность системы.

2.  MTP нежелателен в режиме интерактивного чата с высокой нагрузкой. При коротких ответах низкий acceptance rate увеличивает задержку для пользователей.

Ключевые выводы из стресс-тестов инференса

Анализ поведения системы позволяет сделать выводы о границах применимости RTX 6000 Pro:

1.  Теоретический предел 7.03x подтвердился. До лимита (C=5) система работает свободно. На лимите (C=7) планировщик жонглирует ресурсами — на графиках это выглядит как «пила» очередей. За лимитом (C=10) наступает preemption: вытеснение кэша в CPU, что приводит к катастрофической деградации латентности без краша приложения.

2.  Длинный контекст и короткий ответ — худший сценарий для инференса: скорость падает из-за постоянных переключений между prefill и decode. Генерация объемных отчетов, напротив, позволяет системе выйти на крейсерскую скорость около 38 токенов в секунду.

3.  Для оптимизации инфраструктуры нужно разделять потоки пользовательских задач: длинные документы, RAG, анализ логов и отчеты следует выносить в профиль тяжелой аналитики; быстрый оперативный чат — маршрутизировать на отдельный пул или профиль с меньшим контекстным окном и минимальным TTFT.

Эти выводы можно распространять на модели других размеров только после проверки их архитектуры внимания, квантования и фактического поведения KV-cache. Формально похожий размер модели не гарантирует такой же профиль памяти.

Вывод первой части

Мы выяснили, что одна профессиональная GPU действительно способна обслуживать крупную LLM в задачах SOC. Но достаточно ли этого для реальной эксплуатации? Во второй части мы посмотрим, как эта конфигурация ведет себя уже внутри конвейера обработки инцидентов R-Vision SOAR: сколько времени занимает автоматическое обогащение инцидентов, какую нагрузку создают ИИ-сценарии и сколько инцидентов способна обработать одна видеокарта за сутки.