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

В таких случаях альтернативой становится запуск LLM на центральном процессоре (CPU), который хотя и медленнее GPU, но гораздо дешевле. Например, если сервер с двумя CPU обойдется за месяц в 150 000 ₽, то сервер с GPU — более 700 000 ₽. Конечно, сервер с GPU может «прожевать» больше запросов. Но если вам столько не надо?

Привет, Хабр! Меня зовут Никита Староверов, я системный архитектор в Selectel. В этой статье рассмотрю, насколько реалистично запускать современные крупные языковые модели исключительно на CPU. А еще — покажу, какие инструменты и подходы позволяют загружать и выполнять такие модели, какие требования к железу и насколько производительность системы остается приемлемой для практического использования.

Используйте навигацию, если не хотите читать статью полностью:

• О каких моделях идет речь

• Как собрать Inference-сервер на CPU

• Конфигурирование моделей

• Развертывание веб-интерфейса

• Тестирование конфигурации

• Выводы и заключение

О каких моделях идет речь

Мы сосредоточимся на нескольких современных открытых языковых моделях с числом параметров от 235 до 671 млрд. Среди них — Qwen3-235B, Qwen3-Coder-480B (480 млрд параметров), DeepSeek-V3 (671 млрд параметров) и R1.

Конечно, это не самый большой выбор моделей, но из доступных в open source они показывают отличные результаты в бенчмарках. А еще — выделяются архитектурным подходом, так как построены на принципе Mixture of Experts (MoE).

• Qwen3 — это серия новых моделей от Alibaba, которая вышла в июле 2025 и интересна своим набором «специализаций». Вариант Instruct подходит для ботов и помощников типа вопрос-ответ, Thinking — для решения задач и сложного кодинга, а Coder — для анализа и генерации кода.

• DeepSeek V3 нашумел в прошлом году своей эффективной архитектурой и размером. С тех пор команда разработчиков выпустила версию 3.1 с поддержкой агентов, а затем — исправление проблем с «подмешиванием» символов других языков в вывод в версии 3.1 Terminus.

• DeepSeek R1 — модель, которую стоит выделить отдельно. Хоть она и основана на DeepSeek V3, R1 — полноценное ответвление с частично измененной архитектурой и другим датасетом, который нацелен на более длинные «рассуждения».

Всем ли нужны GPU

Одно из ключевых преимуществ архитектуры Mixture of Experts заключается в том, что на каждом шаге генерации активируется только часть параметров модели. Например, в Qwen3-235B при общем числе параметров в 235 млрд на один токен используется лишь около 22 млрд. Это резко снижает вычислительную нагрузку по сравнению с плотными моделями аналогичного масштаба, что делает MoE-модели потенциально пригодными для запуска на менее производительных системах — в том числе на CPU. 

Насколько снижает? Примерно во столько раз, во сколько число активированных параметров меньше общего числа параметров. Проще говоря, в случае с Qwen3-235B 235 делим на 22 — и получаем ускорение примерно в десять раз.

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

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

Итого, распределение экспертов по разным GPU позволяет запустить большую модель, но ограниченная пропускная способность PCI Express создает новое бутылочное горлышко. Распределение слоев нейросети по картам увеличивает пропускную способность (читай «число пользователей»), но увеличивает и задержку, то есть скорость для каждого отдельного пользователя.

Здесь и проявляется неожиданное преимущество современных серверных CPU. Современные процессоры Intel, например Sapphire Rapids, и AMD (EPYC 9004/Genoa и новее) поддерживают многоканальную память DDR5, а в конфигурациях с несколькими сокетами могут достигать пропускной способности 200–400 ГБ/с на сокет — и более 700 ГБ/с в двухпроцессорной системе.

Как собрать Inference-сервер на CPU

Hardware

Для генерации текста с помощью LLM критична пропускная способность памяти. Чтобы достичь максимальной производительности, лучше всего использовать серверы на базе процессоров AMD EPYC четвертого или пятого поколения. При этом все слоты оперативной памяти должны быть заняты — это критически важно для эффективной работы моделей с большим количеством параметров.

Процессор

• AMD EPYC^TM 9474F (48 ядер) — наилучшая скорость генерации в четвертом поколении за счет высокой частоты.

• AMD EPYC^TM 9754 (128 ядер) — больше ядер, поэтому быстрее готовит промт. Однако частота меньше, поэтому генерация чуть медленнее.

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

Память

Надо установить 24 модуля по 32 ГБ, то есть 768 ГБ оперативной памяти в сумме. Такого объема будет достаточно для запуска любых современных моделей, упомянутых в статье.

Хранилище

Подойдут любые NVMe- или SSD-диски с объемом не менее 1 ТБ. Этого хватит для размещения модели, временных файлов и кэша. При этом скорость диска не критична, ведь основная нагрузка приходится на CPU и RAM.

Сетевая карта

Достаточно одного гигабитного сетевого адаптера. За пару часов на гигабите можно загрузить даже самую большую модель. А после загрузки и запуска сетевая нагрузка практически отсутствует — вся работа происходит локально.

Материнская плата и корпус

Не влияют на производительность в данном сценарии. Главное — чтобы платформа поддерживала выбранные процессоры и количество модулей памяти.

Как собрать конфигурацию

1. Перейдите в панель управления Selectel и откройте раздел Выделенные серверы.

2. В открывшемся окне выберите Конфигуратор серверов.

3. Нажмите кнопку Заказать сервер.

4. Далее последовательно добавьте компоненты.

Software

Операционная система

Для работы рекомендуется использовать SelectOS — операционную систему, оптимизированную для выделенных серверов Selectel. После заказа сервера выберите ее в панели управления — установка будет выполнена автоматически.

Inference-сервер

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

Хотя llama.cpp также поддерживает работу на GPU, в рамках статьи рассматриваю только CPU-сценарий.

Установка llama.cpp

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

2. Для CPU-инференса выберите сборку, соответствующую вашей платформе. Например: llama-b6782-bin-ubuntu-x64.zip.

3. Распакуйте архив с помощью утилиты unzip. Если она не установлена — выполните команду:

sudo apt install unzip

Примечание. Сборка llama.cpp делается на Ubuntu, но бинарные файлы совместимы с SelectOS — дополнительной настройки не требуется. Можно собрать самостоятельно, в этом нет магии, но для простоты я опустил этот момент.

После распаковки вы найдете исполняемый файл llama-server — это основной серверный компонент, с которым вы будете работать. Он предоставляет OpenAI совместимое API, с которым работают, пожалуй, все фронтовые и десктопные приложения.

Для быстрых проверок можно использовать llama-cli, чтобы прямо в терминале поработать с моделью, а для бенчмарков есть утилита llama-bench, результаты работы которой мы еще увидим дальше в статье.

Конфигурирование моделей

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

Источник моделей. Модели доступны на платформе Hugging Face. Для каждой в статье приведены рекомендуемые параметры запуска, оптимизированные под сценарий работы на CPU с использованием llama.cpp.

Формат моделей: GGUF. llama.cpp использует собственный формат моделей — GGUF. Этот формат поддерживает гибкую квантизацию: модель можно сохранить с разной точностью (например, 2, 4, 5 или 8 бит на параметр), что позволяет балансировать между скоростью инференса, потреблением памяти и качеством генерации.

Аналогично сжатию видео: чем выше степень квантизации (меньше бит на параметр), тем меньше размер файла и выше скорость, но ниже точность вывода.

Выбор квантизации. Подробный анализ методов квантизации и критериев выбора выходит за рамки данного руководства. Для рассматриваемого сценария (CPU-инференс, баланс скорости и качества) рекомендуется использовать квантизацию Q4_K_M — она показывает оптимальное соотношение производительности и точности для большинства моделей.

Источник квантизированных моделей. Разработчики моделей не всегда предоставляют GGUF. Например, Qwen некоторые модели серии выкладывает в GGUF, а DeepSeek — нет.

Так как процесс квантизации выглядит относительно просто, многие пользователи Hugging Face выкладывают свои варианты, часто — неэффективные или вообще неработоспособные подделки. Поэтому будем использовать проверенные варианты от команды, которая делает правильно и подтверждает результаты бенчмарками. Это модели команды unsloth, доступные на Hugging Face.

Дальше буду ссылаться только на их названия моделей. Бенчмарки unsloth, выбор параметров и прочее можете найти в их документации. Так что переходим, наконец, к запуску моделей!

Запуск моделей

Qwen3-235B

cd ~/build/bin # По умолчанию llama.cpp распаковывается сюда

./llama-server  --alias Qwen3-235B --port 11434  -hf unsloth/Qwen3-235B-A22B-Instruct-2507-GGUF:Q4_K_M  --jinja  --temp 0.7  --top-k 20  --top-p 0.8 --min-p 0  -c 262144

Qwen3-Coder-480B

cd ~/build/bin 

./llama-server --alias Qwen3-Coder-480B –port 11434 -hf unsloth/Qwen3-Coder-480B-A35B-Instruct-GGUF:Q4_K_M --temp 0.7  --min-p 0.0  --top-p 0.8  --top-k 20  --repeat_penalty 1.05 -c 262144

DeepSeek-V3.1-Terminus

cd ~/build/bin 

./llama-server --alias Deepseek-V3.1-Terminus  --port 11434 

  -hf unsloth/DeepSeek-V3.1-Terminus-GGUF:Q4_K_M  --jinja  --temp 0.6  --top-p 0.95    --min_p 0.01 -c 163840

DeepSeek R1

cd ~/build/bin 

./llama-server --port 11434 --alias Deepseek-R1-0528  -hf unsloth/DeepSeek-R1-GGUF:Q4_K_M --temp 0.6 --top_p 0.95  -c 163840

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

Кроме того, важно знать, что все загруженные модели будут лежать в ~/.cache/llama.cpp. Оценить объем, который будет загружен с HuggingFace, можете в карточке модели в разделе Files или быстро прикинуть по числу параметров и виду квантизации. Для Q4_K_M это примерно число параметров в модели, деленное на четыре. Например, у DeepSeek будет около 350 гигабайт.

Параметры запуска сервера и моделей

Полную справку по параметрам можно получить командой llama-server –help, не все из них там подробно описаны и большинство вам вовсе не понадобятся.

• –alias — имя, под которым модель будет видна в API сервера.

• –port — сетевой порт, на котором будет доступно OpenAI-совместимое API сервера llama-server.

• –host — адрес, на котором доступно API. По умолчанию это 127.0.0.1, чтобы не выставить случайно в интернет публично доступное API. Укажите 0.0.0.0, если хотите выдать доступ к серверу llama-server по сети с других машин.

• –api-key — какой-то длинный пароль, который придумываете сами. Обязательно нужен, если –host указан, чтобы ограничить доступ к модели только для тех, кому дадите api-key.

• -hf — название модели на huggingface, по нему сервер сам находит файлы моделей и скачивает в локальное хранилище.

• –temp — температура. Влияет на вариативность ответов модели, насколько сильно она будет «фантазировать» и делать свой ответ разнообразнее. Температуру можно смело менять в промежутке от 0 до 1, результаты могут вас удивить. Для начала оставьте мою рекомендацию, я ее выставил строго как советуют разработчики.

• –top_p, –top_k, –min_p — это параметры того, как модель будет выбирать следующий токен при генерации. Обычно их рекомендуют разработчики и авторы квантизаций, поэтому лучше не трогать без понимания архитектуры модели и того, как сэмплируются токены. Можете менять, если хотите, но не удивляйтесь, если из модели полезут галлюцинации.

• --jinja — всего лишь указание серверу на формат chat_template для модели, тоже указание от разработчиков. Каким-то моделям надо указывать, какие-то работают и без этого.

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

• -с — размер контекста. Максимальный текст, который модель может принять на вход и сгенерировать сама. Если размер входного текста выше этого значения, то модель будет терять старую информацию, что почти всегда приводит к негодному результату. В примерах запуска я поставил максимально допустимый для каждой модели. Если хотите приближенно понять сколько это в символах, умножайте на 3, в словах — умножайте на 0,75.

Развертывание веб-интерфейса

OpenaAI API поддерживают почти все приложения. Можно подключить к плагину в IDE для разработки кода или к интерфейсу чата. Если не знаете, с чего начать, то попробуйте веб интерфейс в стиле ChatGPT. 

Давайте поставим на наш сервер приложение Open WebUI, к которому затем подключимся через браузер. Open WebUI поставляется контейнером для Docker или альтернативных сред. В случае SelectOS поставим Podman и дополнительный сетевой компонент:

sudo apt install podman slirp4netns

Теперь можем запустить Open WebUI:

podman run -d -p 8080:8080 --network=slirp4netns:allow_host_loopback=true \

--env "ENABLE_OLLAMA_API=false" --env "ENABLE_OPENAI_API=true" --env "HF_HUB_OFFLINE=1" --env "OFFLINE_MODE=1" --env "OPENAI_API_BASE_URL=http://llama-cpp:11434" --env "ENABLE_TITLE_GENERATION=false" --env "ENABLE_FOLLOW_UP_GENERATION=false" --env "ENABLE_TAGS_GENERATION=false" --add-host=llama-cpp:10.0.2.2 \

 --name open-webui http://ghcr.io/open-webui/open-webui:main

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

Тестирование конфигурации

Модели работают, но насколько это комфортно использовать? Все-таки CPU — это не GPU, скорость меньше. 

Проверим сначала объективной оценкой (бенчмарком llama-bench) и посмотрим, на каких объемах текста и с какой производительностью работают выбранные нами модели.

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

Оцениваемые объемы входного текста выбраны с учетом типичных задач:

• 128 токенов — небольшой вопрос;

• 512 — суммаризация какого-то небольшого текста или кусок программного кода;

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

По объемам выходного текста размеры следующие:

• 128 токенов — краткий ответ на вопрос или результат суммаризации;

• 512 — длинный ответ на вопрос — возможно, с рассуждением в DeepSeek V3.1 Terminus;

• 4 096 — долгое рассуждение в DeepSeek R1, генерация кода по запросу, переформулирование текста или его перевод на другой язык.

На графиках эти размеры показаны в краткой форме. Например, запись Inp-512-Out-4096 означает, что на входе — 512 токенов, а на выходе — 4096. При этом время прописано в секундах, а скорость генерации — в токенах в секунду.

Qwen3-235B

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

В данном случае, если спросили примерно два абзаца текста (128 токенов) и получили короткий ответ (тоже 128 токенов), то ждать недолго, несколько секунд. Если же спросили 4 096 токенов (это примерно шесть страниц), то ждать начала генерации ответа понадобится около полутора минут. А вместе с генерацией ответа процесс может занять до 10 минут.

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

Обычно считается, что скорость в 8–10 токенов в секунду — это приемлемо, потому что соотносится со скоростью чтения среднего пользователя. Здесь у нас модель генерирует текст со скоростью от 8 токенов в секунду (для самого маленького вопроса и ответов), до 5 токенов в секунду — для большого вопроса и длинного ответа.

Qwen3-Coder-480B

Несмотря на то, что модель почти в два раза больше Qwen-235B, скорость обработки текста примерно одинаковая. Скорее всего, это связано с тем, что мы уперлись в предел скорости оперативной памяти. Для моделей больше чем на 200–300 млрд параметров скорости обработки близки.

DeepSeek R1

Данная модель умеет «думать» и времени на это тратит существенно больше. При этом скорость генерации у нее также меньше, чем у Qwen-235B. И важно понимать, что выходного текста — обычно больше, потому что модель выдает много «рассуждений».

Для примера: если вы закинете в нее небольшую математическую задачку, то ждать начала генерации надо будет несколько секунд, а вот время ответа, если объем выходного текста будет 4 096 токенов или близко к этому, будет около 12 минут.

Скорость генерации у этой модели не самая комфортная и составляет примерно 5-6 токенов в секунду. Это не быстро и проще дождаться полного ответа, чем читать на ходу.

DeepSeek V3.1 Terminus

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

Скорее всего, для короткого вопроса в 128 токенов получите ответ примерно на 512. Начало генерации займет несколько секунд, а полный ответ сформируется за пару минут.

Если вам интересно, как генерация выходного ответа выглядит на практике, посмотрите видео с примером работы Qwen3-235B.

Выводы и заключение

В этой статье мы рассмотрели, как можно запускать LLM на CPU. Оптимальная конфигурация может обойтись в 160 000 ₽/месяц. При этом конфигурация с восемью GPU A100, на которой вы сможете запустить DeepSeek будет стоить уже 2 000 000 ₽/месяц. 

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

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

При этом Inference на CPU точно вам не подойдет, если нужно генерировать ответы как можно быстрее. Это требование актуально для тех же чат-ботов и сервисов с постоянной высокой нагрузкой. Тогда параллельная обработка запросов пользователей батчами на GPU будет выгоднее. Только вот реально способные на это конфигурации начинаются от 3 000 000 ₽/месяц.

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

Alibaba экспериментирует с gated attention в своем Qwen3-Next, DeepSeek разрабатывает версию 3.2, в которой тоже работают над ускорением prefill. Недавно также moonshot ai выпустил версию Kimi K2 Linear, авторы которого утверждают, что решение работает в четыре раза быстрее за счет снижения качества ответов на 20%. Такие модели должны работать на CPU намного быстрее в стадии обработки входного текста.

Есть ли будущее у инференса больших моделей на CPU, покажет время. Надеюсь, вам понравился мой обзор. Еще увидимся!