Сервер на Intel Xeon для AI inference: когда CPU достаточно, а когда нужен GPU

Сервер на Intel Xeon может быть вполне достаточен для AI inference, если задача связана с классификацией, эмбеддингами, поиском по документам, извлечением данных, небольшими языковыми моделями или пакетной обработкой без жестких требований к задержке. GPU нужен не для любого ИИ-проекта, а тогда, когда модель крупная, пользователей много, контекст длинный, ответы должны генерироваться быстро, а простой или очередь запросов обходятся бизнесу дороже покупки ускорителя.

Инференс — это запуск уже обученной модели для получения результата: ответа чат-бота, категории документа, краткого пересказа, прогноза, найденных сущностей или векторного представления текста. Грубо говоря, можно поставить знак равенства между "инференсом" и "использованием" модели. На практике компании часто называют “ИИ-сервером” любую машину под такую нагрузку, но это слишком грубое упрощение. В одном проекте может быть достаточно обычного 2-сокетного сервера, а в другом даже дорогой GPU-сервер придется масштабировать.

Выбор зависит не от слова “ИИ” в задаче, а от пяти вещей:

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

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

Почему не все ИИ-задачи требуют GPU

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

Есть задачи, где модель делает короткий прогноз:

• определить тип обращения в поддержку;
• найти тональность отзыва;
• извлечь сумму и номер договора из документа;
• классифицировать письмо;
• построить эмбеддинг для поиска;
• транскрибировать аудио небольшого объёма или без ограничений по срокам;
• выбрать релевантные фрагменты из базы знаний.

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

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

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

1. CPU принимает запрос и очищает текст.
2. CPU строит или ищет эмбеддинги.
3. Векторная база находит похожие документы.
4. Большая модель формирует финальный ответ.
5. CPU выполняет постобработку, фильтрацию и логирование.

В такой схеме GPU может понадобиться только на этапе тяжелой генерации. Остальные этапы вполне могут жить на Xeon. Intel также отмечает, что в реальных ИИ-сценариях разные этапы обработки данных могут требовать разных типов вычислений: часть нагрузки хорошо выполняется на CPU, а часть эффективнее переносить на специализированные ускорители. Подробнее этот подход разобран в материале Intel про ускорение инференса на CPU.

Что в Intel Xeon помогает инференсу

Intel Xeon 6.

Источник изображения: newsroom.intel.com

Современный серверный CPU — это не просто “универсальный процессор”. В задачах инференса у него есть несколько сильных сторон.

Много ядер для параллельных небольших запросов

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

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

Большой объем оперативной памяти

Для ИИ важна не только вычислительная мощность. Часто критичны:

• объем модели в памяти;
• индексы поиска;
• документы и фрагменты контекста;
• кэши;
• очереди задач;
• промежуточные данные.

У 2-сокетных серверов на Xeon обычно больше возможностей по оперативной памяти, чем у рабочих станций или компактных GPU-конфигураций. Скорость оперативной памяти конечно не сравнится с HBM, но значительно дешевле за гигабайт. Это важно для document AI, RAG-систем и корпоративных баз знаний, где рядом с моделью живет много вспомогательных данных.

Встроенные ускорения для матричных операций

Нейросетевые модели активно используют матричные вычисления. В новых поколениях Intel Xeon для таких задач есть встроенные ускорения, включая Intel AMX. Этот механизм предназначен для ускорения матричных операций, которые используются в задачах глубокого обучения и инференса.

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

Хорошая роль в смешанных нагрузках

Многие корпоративные ИИ-сервисы — это не “одна модель на одном сервере”. Рядом работают:

• веб-приложение;
• база данных;
• очередь задач;
• хранилище документов;
• векторный поиск;
• мониторинг;
• авторизация;
• логирование;
• интеграции с CRM, ERP или Service Desk.

CPU-сервер удобен именно потому, что может обслуживать весь этот контур. Даже если в системе есть GPU, Xeon все равно остается центральным элементом: он готовит данные, управляет запросами, держит сервисную логику и не дает ускорителю простаивать.

Какие задачи обычно можно начинать с CPU

Классификация и маршрутизация

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

Примеры:

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

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

Эмбеддинги и семантический поиск

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

CPU может быть достаточен, если:

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

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

Document AI

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

Типичные операции:

• извлечь номер договора;
• найти дату, сумму, ИНН, адрес;
• определить тип документа;
• сравнить поля с данными в учетной системе;
• отправить документ на нужный маршрут согласования.

Неочевидный момент: узким местом здесь часто становится не модель, а качество сканов, OCR, структура документов, валидация полей и интеграция с бизнес-системами. Покупка GPU не исправит плохие шаблоны, грязные PDF и неустойчивый процесс согласования.

Небольшие языковые модели

Малые и средние языковые модели можно запускать на CPU, если они оптимизированы и требования к скорости умеренные. Особенно это актуально для внутренних инструментов, где пользователю допустимо подождать несколько секунд.

CPU может подойти для:

• внутреннего помощника по регламентам;
• генерации коротких черновиков;
• суммаризации небольших документов;
• классификации диалогов;
• подготовки ответов оператору поддержки;
• локальных прототипов без передачи данных во внешние сервисы.

Но здесь важно не путать “запустить модель” и “запустить удобный сервис”. Одно дело — получить ответ в тестовой консоли. Другое — обслуживать пользователей в рабочем интерфейсе, где важны стабильность, очереди, безопасность и понятная задержка.

Пакетная обработка

Если результат не нужен мгновенно, CPU часто оказывается достаточно выгодным.

Примеры:

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

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

Где CPU быстро становится ограничением

Большие языковые модели

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

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

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

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

Высокая параллельность

Один внутренний пользователь и 200 одновременных пользователей — это разные инфраструктурные задачи.

CPU может справиться с пилотом:

• 5–10 сотрудников;
• короткие вопросы;
• небольшие документы;
• невысокая частота запросов;
• допустимое ожидание.

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

Длинный контекст

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

Длинный контекст увеличивает:

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

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

Видео, изображения и речь в реальном времени

GPU почти всегда рациональнее, если система должна в реальном времени:

• анализировать видеопоток;
• распознавать речь;
• обрабатывать изображения;
• работать с мультимодальными моделями;
• генерировать изображения;
• выполнять сложную компьютерную обработку на потоке.

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

Сравнение сценариев: CPU или GPU

Как оценивать нагрузку до покупки сервера

Размер модели

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

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

Длина входных данных

Короткий запрос вроде “к какой категории относится письмо?” и запрос с 20 страницами договора — разные нагрузки. Даже если используется одна и та же модель, длинный вход меняет время обработки.

Для корпоративных систем это особенно важно, потому что пользователи часто хотят “загрузить весь документ”. Но модели редко нужно видеть все сразу. Обычно лучше:

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

Число одновременных пользователей

Нужно считать не только общее количество сотрудников в компании. Важнее понять, сколько людей реально обращается к системе одновременно.

Для оценки полезны такие вопросы:

• сколько запросов в минуту будет в обычный день;
• есть ли утренние или вечерние пики;
• сколько пользователей может работать одновременно;
• будет ли сервис публичным;
• что произойдет, если очередь вырастет;
• допустимо ли пользователю ждать 5–10 и более секунд.

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

Пакетная обработка

Пакетная обработка означает, что запросы можно собирать и выполнять группами. Это помогает эффективнее использовать железо.

Она хорошо подходит для:

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

Она хуже подходит для:

• онлайн-чата;
• голосового помощника;
• подсказок оператору в момент разговора;
• интерактивного поиска;
• пользовательского интерфейса, где ответ нужен сразу.

Задержка и пропускная способность

При выборе сервера важно измерять не только “работает или нет”. Для пользовательского сервиса важны задержка, пропускная способность и стоимость обслуживания запросов. В руководстве NVIDIA по бенчмаркингу инференса LLM эти параметры рассматриваются как базовые метрики для оценки качества и экономики сервинга модели.

Для оценки нужно смотреть:

• время до первого видимого ответа;
• общую длительность запроса;
• скорость генерации;
• число запросов в секунду;
• поведение при пиковых нагрузках;
• долю медленных запросов;
• стоимость одного ответа.

Среднее значение может обманывать. Если 90% запросов отвечают быстро, а 10% зависают, пользователи будут запоминать именно эти 10%.

Матрица выбора CPU или GPU

Почему стоимость владения важнее цены сервера

Цена покупки — только часть решения. В ИИ-инфраструктуре нужно считать полную стоимость владения.

В нее входят:

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

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

Сценарии, где GPU часто окупается:

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

Сценарии, где GPU может быть лишним:

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

Иногда самый выгодный путь — начать с Xeon, измерить реальную нагрузку, оптимизировать модель и только потом покупать GPU. Это снижает риск переплаты за оборудование, которое не будет загружено.

Как оптимизировать инференс на CPU

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

Оптимизированные библиотеки

Для CPU-инференса используют OpenVINO, ONNX Runtime, oneDNN, llama.cpp и другие инструменты. В документации OpenVINO CPU device указано, что CPU-плагин предназначен для высокопроизводительного инференса на процессорах Intel x86-64 и Arm, а новые поколения CPU дают дополнительный прирост, особенно для INT8-моделей.

Это важно, потому что “запустить модель на CPU” можно по-разному. Нативная, неоптимизированная сборка может показать слабый результат, а правильно подготовленная модель — уже приемлемую скорость.

Квантизация

Квантизация уменьшает точность чисел внутри модели. Например, вместо более тяжелых форматов могут использоваться INT8 или INT4. Модель занимает меньше памяти, быстрее загружается и может работать быстрее.

Плюсы:

• меньше расход памяти;
• ниже требования к серверу;
• выше скорость;
• проще запуск на CPU.

Минусы:

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

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

Разумный контекст

Многие ИИ-сервисы работают медленно не из-за слабого сервера, а из-за того, что модели передают слишком много текста.

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

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

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

Настройка потоков и памяти

CPU-инференс чувствителен к настройкам:

• число потоков;
• распределение нагрузки между сокетами;
• NUMA;
• скорость памяти;
• конкуренция с базой данных;
• нагрузка на диск;
• сетевой обмен с хранилищем.

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

Гибридная архитектура: когда CPU и GPU работают вместе

В зрелой ИИ-инфраструктуре вопрос редко звучит как “CPU или GPU”. Чаще правильный ответ — “и CPU, и GPU, но каждый для своей части”.

CPU хорошо подходит для:

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

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

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

Такой подход помогает не тратить GPU на служебные операции. Ускоритель занят генерацией или обработкой модели, а Xeon поддерживает все, что находится вокруг нее.

Пример корпоративного RAG-сервиса:

1. Пользователь задает вопрос.
2. CPU принимает запрос, проверяет доступы и очищает текст.
3. CPU или отдельный сервис ищет релевантные документы.
4. GPU генерирует финальный ответ на основе найденных фрагментов.
5. CPU проверяет формат, сохраняет лог и возвращает результат пользователю.

Если нагрузка умеренная, пункт 4 тоже можно оставить на CPU. Если задержка становится неприемлемой, именно этот этап переносится на GPU первым.

Какие серверы рассматривать

Dell PowerEdge R760.

Источник изображения: Сервер Молл

Для CPU-инференса обычно важнее не один максимальный параметр, а баланс. Сервер должен иметь достаточно ядер, памяти, быстрые накопители и нормальный запас по охлаждению.

Для стартовых и средних сценариев стоит смотреть на 2-сокетные платформы Intel Xeon:

• классификация;
• эмбеддинги;
• document AI;
• внутренние ассистенты;
• RAG умеренной нагрузки;
• пакетная обработка;
• сервисы с небольшой параллельностью.

Для таких задач подойдут универсальные 2U-серверы, например Dell PowerEdge R760 или Dell PowerEdge R770, если нужен запас под новые поколения CPU, память, NVMe и дальнейшее развитие сервиса.

При выборе CPU-сервера важно смотреть на:

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

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

Для компаний, которые планируют развивать ИИ-инфраструктуру постепенно, разумно смотреть не только на конкретную модель сервера, но и на поколение платформы. Например, серверы Dell 17-го поколения могут быть интересны, если нужен запас под новые процессоры, память, сетевые карты и более долгий жизненный цикл.

Как принять решение без переплаты

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

Последовательность может быть такой:

1. Определить тип задачи: классификация, поиск, эмбеддинги, RAG, генерация, видео, речь.
2. Зафиксировать модель или хотя бы класс модели.
3. Понять, сколько текста модель получает на вход.
4. Оценить длину ответа.
5. Посчитать число одновременных пользователей.
6. Разделить обычную и пиковую нагрузку.
7. Определить допустимую задержку.
8. Проверить, можно ли использовать пакетную обработку.
9. Протестировать задачу на CPU.
10. Сравнить CPU-only, GPU-only и гибридный вариант по полной стоимости владения.

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

Измерять стоит не только “ответ появился”, а конкретные параметры:

• время до первого ответа;
• общую длительность запроса;
• скорость генерации;
• число запросов в секунду;
• загрузку CPU;
• использование памяти;
• очереди;
• энергопотребление;
• стоимость одного запроса.

Такой тест часто показывает, что часть системы можно оставить на Xeon, а GPU нужен только для одного тяжелого этапа. Или наоборот: CPU подходит для пилота, но не для промышленной нагрузки.

Когда Intel Xeon — разумный выбор

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

CPU-платформа подходит, когда:

• модель небольшая или средняя;
• данные можно обрабатывать очередью;
• задержка не критична;
• пользователи внутренние;
• важна простота эксплуатации;
• нужен большой объем RAM;
• рядом с моделью работают база, поиск, API и интеграции;
• GPU будет простаивать большую часть времени.

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

Когда GPU нужен сразу

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

Это случаи, когда:

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

В таких проектах попытка “сэкономить на GPU” может привести к обратному эффекту: придется покупать больше CPU-серверов, сложнее масштабировать систему и объяснять пользователям, почему ассистент отвечает слишком долго.

Итог

Intel Xeon подходит для многих задач AI inference, если модель не слишком крупная, нагрузка умеренная, контекст контролируется, а задержка не является жестким бизнес-требованием. На CPU можно начинать классификацию, эмбеддинги, document AI, внутренние ассистенты, пакетную обработку и часть RAG-сценариев.

GPU нужен не потому, что проект связан с ИИ, а потому что есть конкретные требования: большая модель, длинный контекст, много пользователей, низкая задержка, мультимодальность или высокая стоимость ожидания. Самый надежный путь — сначала описать нагрузку, затем протестировать реальный сценарий на Xeon, посчитать полную стоимость владения и только после этого выбирать CPU, GPU или гибридную архитектуру.