Ollama на CPU: какой сервер выбрать без видеокарты

MAATRIX

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

Почему процессор вообще может тянуть LLM

Инференс языковой модели — это, по сути, последовательность матричных умножений. GPU выигрывает за счёт тысяч параллельных ядер, но современные серверные CPU тоже неплохо справляются с этим типом нагрузки, особенно на моделях 7-13B в квантованном виде (Q4/Q5). Ollama под капотом использует llama.cpp, а тот умеет эффективно распараллеливать вычисления по ядрам и использовать векторные инструкции процессора. Результат не будет таким быстрым, как на видеокарте, но для многих сценариев — черновик текста, суммаризация, ответы в фоне, эксперименты — этого достаточно.

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

Ядра важнее гигагерц

Первое, на что стоит смотреть в тарифе VPS, — это количество виртуальных ядер (vCPU), а не их частота. Инференс на CPU параллелится по потокам почти линейно вплоть до определённого предела, поэтому 8 ядер на умеренной частоте почти всегда обгонят 4 ядра с более высоким мегагерцем.

Практический ориентир по числу ядер:

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

Число потоков в самой Ollama можно ограничить переменной окружения:

OLLAMA_NUM_THREADS=8 ollama serve

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

AVX2 и AVX512 — не проходите мимо этой строчки в спецификации

Это тот пункт, который проще всего упустить, выбирая тариф по цене и объёму RAM. Векторные инструкции AVX2 и AVX512 напрямую влияют на скорость матричных операций в llama.cpp — библиотека умеет использовать их для ускорения вычислений с квантованными весами. Разница между сервером с AVX2 и без него ощутима невооружённым глазом; AVX512 даёт дальнейший прирост там, где процессор его поддерживает и где сборка llama.cpp скомпилирована с соответствующими флагами.

Проверить поддержку на самом сервере просто:

cat /proc/cpuinfo | grep -o 'avx[0-9a-z_]*' | sort -u

Если в выводе есть avx2 — уже хорошо. Если есть строки с avx512 (например, avx512f, avx512bw) — ещё лучше, но учтите, что часть облачных CPU официально поддерживает AVX-512, а часть — только частично или отключает часть его подмножеств на уровне гипервизора, так что реальный прирост стоит проверять на месте, а не полагаться на маркетинговое описание тарифа.

Перед арендой имеет смысл написать в поддержку хостера и спросить прямо, какой процессор стоит на нужном тарифе и какие у него флаги — современные Xeon и EPYC почти всегда несут AVX2, а AVX-512 встречается реже и зависит от конкретного поколения.

Оперативная память: считайте с запасом, а не впритык

RAM — это второй по важности параметр после ядер, и именно здесь чаще всего ошибаются, беря сервер «точно под модель». Нужно заложить три составляющие:

1. Сама модель — размер весов в выбранном квантовании (Q4_K_M для модели 7B занимает примерно 4-5 ГБ, для 13B — около 8-9 ГБ; точные цифры зависят от архитектуры и метода квантования).
2. Контекстное окно — чем длиннее история диалога и чем больше контекст модели, тем больше памяти уходит на KV-кэш. Для длинных диалогов и RAG-сценариев с большим контекстом это может быть заметная добавка, особенно на моделях с длинным окном.
3. Система и сама Ollama — плюс ОС, сетевые процессы, возможно веб-интерфейс (Open WebUI и подобные), логи, при необходимости — сторонние сервисы на том же сервере.

Практическое правило: берите RAM с запасом минимум 30-50% сверх размера модели в выбранном квантовании, а не впритык. Если модель занимает 5 ГБ, тариф на 8 ГБ будет работать «на грани» — лучше 12-16 ГБ, особенно если параллельно планируете держать embedding-модель или векторную базу. Подробную таблицу по конкретным моделям и их запросам к памяти смотрите в статье Сколько RAM нужно для Ollama: таблица моделей.

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

NVMe диск: не столько для инференса, сколько для загрузки и смены моделей

Сам процесс генерации токенов почти не обращается к диску — модель загружается в RAM один раз и там и остаётся, пока процесс Ollama жив. А вот на что диск влияет напрямую:

• Время первого запуска и перезапуска модели — веса нужно прочитать с диска в память, и на SATA SSD это заметно дольше, чем на NVMe, особенно для моделей от 13B и выше.
• Переключение между моделями — если вы держите несколько моделей и переключаетесь между ними (ollama run llama3, потом ollama run qwen2.5 и так далее), каждая такая смена — это чтение весов с диска заново.
• Место под сами веса — квантованные модели весят от нескольких гигабайт до нескольких десятков, если держать библиотеку из 4-6 моделей разных размеров, NVMe на 40-80 ГБ съедается быстро.

Разница между NVMe и обычным SATA SSD в задачах именно загрузки моделей достаточно ощутима, чтобы предпочесть NVMe при прочих равных ценах — благо сейчас это уже почти стандарт на большинстве современных тарифов VPS. Подробное сравнение — в статье NVMe против SATA SSD на сервере.

Честно про скорость: сколько токенов в секунду ждать

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

Что можно сказать честно, ориентировочно:

• На CPU-инференсе для небольших моделей (3B-8B, Q4) скорость генерации обычно измеряется единицами-первыми десятками токенов в секунду на многоядерном сервере — это ощутимо медленнее GPU, но вполне пригодно для интерактивного использования одним пользователем.
• Крупные модели (13B и выше) на CPU заметно замедляются — задержка перед первым токеном (prompt processing) может стать заметной, особенно с длинным контекстом.
• Первый запрос после старта сервиса всегда медленнее последующих — модель прогревается, часть данных попадает в кэш ОС.
• Параллельные запросы от нескольких пользователей делят между собой одни и те же ядра — то, что комфортно для одного человека, может стать очередью при пяти одновременных запросах.

Если для вашей задачи критична именно скорость генерации в реальном времени с несколькими одновременными пользователями — честнее сразу смотреть в сторону GPU-сервера, а не пытаться выжать это из CPU. Если же сценарий — фоновая обработка, личный ассистент, RAG с не самым большим потоком запросов — CPU вполне рабочий вариант, и вы легко проверите реальную скорость на вашей связке модель+тариф в первые же полчаса после разворачивания, замерив время генерации на своих типичных запросах. Если после переезда на CPU скорость кажется ниже ожидаемой — есть отдельный разбор частых причин на странице Ollama медленно генерирует токены: причины и решение.

Как выбрать конкретный тариф: чек-лист

Собирая всё вместе, при выборе VPS под Ollama без GPU стоит пройти по такому списку:

1. Число vCPU — минимум 4, лучше 8+ для моделей от 8B, с гарантированным выделением, а не переподпиской.
2. Поддержка AVX2 обязательна, AVX512 — плюс, если процессор и гипервизор его действительно отдают.
3. RAM с запасом 30-50% сверх размера модели в выбранном квантовании плюс контекст и система.
4. NVMe диск — для быстрой загрузки и смены моделей, с запасом места под несколько версий весов.
5. Пропускная способность сети — если планируете скачивать модели через ollama pull, а они весят гигабайты, лишний лимит на трафик или медленный канал будет раздражать при каждом обновлении.
6. Возможность апгрейда тарифа без переезда — начать можно с меньшего тарифа и вырасти, если станет тесно, не разворачивая всё заново.

Сам процесс установки Ollama на сервер и первого запуска модели пошагово описан в статье Как поднять локальный запуск LLM через Ollama на сервере.

Частые вопросы