Для чат-бота на базе модели с 8 млрд параметров компания приобретает GPU-сервер, но после запуска обнаруживает, что ускоритель используется лишь на 10%. Разберем, для каких нагрузок вместо GPU достаточно двух процессоров Intel Xeon 6 с AMX и на какой серверной платформе можно построить такую систему.
Почему GPU-сервер для модели 8B остаётся недозагруженным
Корпоративный ИИ-проект в 2026 году часто строится по следующей схеме: база знаний из PDF-документов, векторный поиск и чат-бот на основе открытой модели класса 8B. Внутри закрытого контура с системой работают примерно от 50 до 100 активных пользователей.
Для запуска такого решения нередко приобретают сервер с ускорителем, руководствуясь принципом «для искусственного интеллекта обязательно нужен GPU». Однако через несколько месяцев мониторинг показывает другую картину: память HBM заполнена примерно на четверть, SM-ядра не работают в промежутках между запросами, а значительная часть размещённой в стойке инфраструктуры обслуживает компоненты, которые вообще не выполняются на GPU.
Более важный момент связан с архитектурой поисковой генерации. RAG-конвейер не ограничивается одной языковой моделью. В него входят балансировщик нагрузки, сервер приложений, очередь Kafka, векторная база данных, MongoDB с метаданными, модель для построения эмбеддингов, модель переранжирования и только после них — движок vLLM с основной LLM.
Все компоненты до vLLM используют процессор и оперативную память. Если саму языковую модель также можно выполнять на CPU, весь RAG-конвейер размещается в едином кластере, работает под управлением одного оркестратора и обслуживается по общей эксплуатационной модели. В этом случае не приходится отдельно поддерживать GPU-сегмент и окружающую его CPU-инфраструктуру.
Третий аспект касается корпоративных данных. При локальном использовании открытых моделей документы, записи разговоров и тендерная переписка остаются внутри дата-центра. Вместо расходов на облачные API, например для распознавания речи, компания оплачивает приобретение и амортизацию собственного оборудования.
Intel Xeon 6 P-cores для инференса: AMX, DDR5-6400 и PCIe 5.0
Семейство Intel Xeon 6 включает две отдельные линейки. Процессоры с P-ядрами ориентированы на высокую производительность каждого ядра. E-ядра рассчитаны на производительность на ватт и используются в таких задачах, как CDN, микросервисы и DevOps. Для машинного обучения и HPC выбирают модели с P-ядрами.
Сама линейка P-cores также разделена на два направления. Процессоры серии 6900P, или Granite Rapids AP, предлагают до 128 ядер, 12 каналов памяти и теплопакет до 500 Вт. Серия 6700P, известная как Granite Rapids SP, поддерживает до 86 ядер, 8 каналов памяти, теплопакет до 350 Вт, до 88 линий PCIe 5.0 и до 4 ТБ памяти на один сокет.
ITPOD-SL201-D12R-NV-G5 относится к платформам на базе SP-профиля. Сервер поддерживает два процессорных сокета с теплопакетом до 350 Вт на каждый CPU и оснащается 32 слотами для памяти DDR5.
Ключевая технология для инференса — Intel AMX. Это встроенный в процессор матричный ускоритель, который работает отдельно от основных ядер, не забирает их ресурсы и поддерживает FP16.
В опубликованных Phoronix результатах геометрическое среднее по набору тестов составило 156,99 при включённом AMX. После отключения ускорителя показатель снизился до 57,15. Следовательно, разница между неэффективным и рабочим CPU-инференсом определяется не только поколением процессора. Необходимы также матричный блок внутри CPU и правильно оптимизированный движок.
С практической точки зрения важна и работа с памятью. По сравнению с Gen2 её пропускная способность увеличилась приблизительно в два раза. Для небольших моделей это особенно значимо: производительность их инференса ограничивается прежде всего пропускной способностью памяти, а не скоростью арифметических вычислений.
Результаты Llama 3.1 8B на двух Intel Xeon 6767P
Intel опубликовала результаты тестирования двухсокетной системы на базе Xeon 6767P. Каждый процессор содержит 64 ядра, поэтому суммарная конфигурация включает 128 ядер и четыре домена NUMA. В системе использовалась память DDR5-6400.
Модель запускали с помощью vLLM 0.9.0 с префиксным кэшированием. Испытания проводились в Ubuntu 22.04 и RHEL 9.6 на наборе данных Sonnet. Для каждой комбинации параметров выполняли по три прогона.
Во всех четырёх профилях использовалась одна и та же модель. Менялись только диапазоны входных и выходных данных.
Комфортным показателем для генеративного пользовательского интерфейса считается скорость 10 токенов в секунду на одного пользователя. Текст генерируется быстрее, чем человек успевает его читать.
Каждый из четырёх профилей нагрузки преодолел этот ориентир. В чат-сценарии система сохранила необходимую скорость почти при ста одновременных запросах, а время ответа осталось меньше одной секунды.
Количество запросов непосредственно к движку не равно числу людей, работающих с системой. Примерно сто одновременных обращений к vLLM могут соответствовать приблизительно тысяче пользователей, подключённых через браузеры или мобильные приложения.
До поступления в vLLM каждый запрос проходит через балансировщик, сервер приложений и очередь Kafka, сглаживающую поток. Кроме того, часть нагрузки снимает кэш. В специализированных корпоративных сценариях многие запросы повторяются, поэтому слой кэширования может вернуть готовый результат без новых вычислений — непосредственно из DDR5 этого же сервера.
Какие задачи можно выполнять с помощью CPU-инференса
Набор корпоративных сценариев, который Intel сформировала на основе своей практики, во многом одинаков у разных заказчиков.
- RAG по документам. Источниками могут быть FAQ с корпоративного сайта, руководства по продуктам, кадровые политики и база обращений сервис-деска. Чаще всего именно такой сценарий становится первым ИИ-проектом компании.
- Анализ нормативных требований. Краулер регулярно получает документы регулятора, после чего система присваивает им теги, находит связанные материалы и предыдущие редакции, а также определяет, действует ли конкретное требование в настоящий момент.
- Оценка тендеров, проверка аудиторских документов и подготовка отчётов. Такие решения позволяют сократить процесс, который прежде занимал две недели, до получаса. При этом человек продолжает контролировать и проверять результат.
- Разговорный ИИ и работа с речью. К этой категории относятся распознавание, перевод, синтез речи и автоматический анализ общения оператора с клиентом. Система может проверить, соблюдал ли сотрудник регламент и рассказал ли о продукте.
- Запросы к хранилищу данных на естественном языке. Например, пользователь может спросить, сколько жалоб поступило с определённой площадки в июле и какая часть из них пришлась на утренние часы.
Все перечисленные сценарии имеют общий профиль: модели уровня 8–11B, десятки параллельных запросов и запрет на передачу данных за пределы корпоративного контура. Для такой нагрузки подходит процессорный инференс.
Развёртывание RAG на CPU с использованием vLLM, OPEA и Kubernetes
Разрабатывать каждый компонент конвейера самостоятельно необязательно. Intel входит в консорциум OPEA — Open Platform for Enterprise AI, проект фонда LF AI & Data — и предоставляет провалидированные RAG-конвейеры.
Готовые решения охватывают обработку PDF, загрузку информации в векторную базу, хранение метаданных в MongoDB, получение релевантного контекста и его передачу в vLLM.
Развёртывание выполняется в Docker или Kubernetes. В качестве инфраструктурной основы также могут использоваться OpenShift, Nutanix и VMware.
При построении архитектуры следует учитывать два практических принципа.
Использование оркестратора обязательно. Инфраструктура постепенно становится неоднородной: в ней одновременно работают процессоры разных поколений и GPU разных производителей. Kubernetes объединяет эти ресурсы и позволяет запускать в подах как ИИ-компоненты, так и стандартные сервисы RAG-конвейера.
Над моделями необходим отдельный слой задач. Сегодня вопросно-ответный сценарий может выполняться с помощью Llama, а завтра — с помощью DeepSeek. Когда прикладной код обращается к API конкретной задачи, а не напрямую к определённой модели, замена LLM не требует переработки всего решения.
ITPOD-SL201-D12R-NV-G5: конфигурация 2U для CPU-инференса
ITPOD-SL201-D12R-NV-G5 выполнен в форм-факторе 2U. На передней панели расположено 12 универсальных отсеков с поддержкой горячей замены.
Для ИИ-конвейера важно устройство дисковой подсистемы. Обозначение D12R-NV указывает на универсальный backplane: в одних и тех же 12 отсеках можно использовать SATA/SAS- и NVMe-накопители в различных сочетаниях.
Векторная база размещается на NVMe, тогда как для архива документов и резервных копий можно использовать ёмкие SAS-диски. Оба типа нагрузки остаются на одном сервере, поэтому выделять для них две отдельные системы не требуется.
Два слота OCP 3.0 с подключением по PCIe 5.0 обеспечивают работу сетевых интерфейсов 25/100G без использования райзеров. Райзеры при этом можно оставить под контроллеры хранения или дополнительный ускоритель, если в дальнейшем он потребуется проекту.
Отдельно необходимо учитывать конфигурацию оперативной памяти. В сервере предусмотрено 32 слота на два процессорных сокета — по 8 каналов и по 2 модуля на каждый канал.
Номинальная скорость 6400 MT/s гарантируется при использовании одного модуля на канал, то есть при установке 16 модулей. Остальные слоты позволяют увеличить общий объём памяти, но при конфигурации 2 DPC её частота снижается.
Поскольку производительность инференса ограничивается пропускной способностью памяти, для ИИ-нагрузки по умолчанию используют 16 модулей большей ёмкости, а не 32 модуля меньшего объёма.
Ещё одна инженерная особенность связана с NUMA. Два процессора Xeon 6 образуют четыре домена NUMA. Чтобы воспроизвести приведённые выше показатели, необходимо правильно выполнить пиннинг vLLM по этим доменам.
При некорректной настройке движок обращается к весам модели через межпроцессорную шину. Соответствующая конфигурация задаётся во время развёртывания и пусконаладочных работ.
Когда вместо Xeon 6 требуется GPU-сервер
Граница применимости CPU-инференса сохранилась, но сместилась в сторону более производительных нагрузок. Модели класса 8–11B можно комфортно запускать на процессорах в интерактивных сценариях с десятками одновременных обращений.
Для задач за пределами этого профиля уже требуется GPU:
- модели от 30B, особенно при работе с длинным контекстом и строгих требованиях к латентности;
- сотни или тысячи параллельных сессий на один экземпляр модели;
- обучение и дообучение;
- пакетная обработка больших массивов данных;
- потоковые задачи компьютерного зрения.
Для таких нагрузок у ITPOD предусмотрена линейка AI/ML Computing — серверные системы форм-фактора 4U с поддержкой восьми ускорителей.
Однако начинать с подобной платформы проект, первым сценарием которого станет чат-бот по корпоративной базе знаний, не всегда оправданно. Компания фактически приобретает дорогостоящую HBM-память для нагрузки, производительность которой ограничивается DDR5.
Тестирование ITPOD-SL201-D12R-NV-G5 на прикладной нагрузке
В августе ITPOD планирует получить несколько серверов ITPOD-SL201-D12R-NV-G5 для тестирования. На них можно запускать не синтетические тесты, а конкретную задачу заказчика: его документы, выбранную модель и реальный профиль запросов.
Результатом тестирования станут показатели в том же формате, который использовался в приведённых ранее замерах:
- конкурентность;
- время до первого токена;
- количество токенов в секунду на пользователя.
Для оценки необходимо предоставить описание сценария, размер модели, предполагаемое количество пользователей и требования к контуру размещения данных.
На основании этих параметров можно определить, подходит ли для проекта Intel Xeon 6, в какой точке потребуется переход на GPU и какая конфигурация ITPOD соответствует нагрузке.
Оставьте заявку на проведение тестового прогона ITPOD-SL201-D12R-NV-G5 в августе.
Предыдущая статья
