2026: Ollama на CPU работает слишком медленно — сначала оптимизировать или менять сервер?

Запрос в Ollama долго не выдаёт ответ или генерация заметно замедляется при длинном вводе.

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

Подойдёт разработчикам, которые уже запускают Ollama без GPU и хотят найти узкое место, прежде чем расширять ресурсы.
Поможет небольшим командам отделить нагрузку приложений и поиска по базе знаний от самой генерации.
Техническим руководителям, рассматривающим переход с VPS на выделенную машину, позволит проверить, устранит ли миграция именно их ограничение.

Последняя проверка: 23 октября 2026 года. Дата обновления и доступные настройки Ollama сверены с официальной документацией и журналом выпусков; конфигурации SFP Cloud следует сверять с актуальной таблицей серверов и тарифов.

Начните с повторяемого теста, а не с покупки сервера

Фраза «Ollama CPU работает медленно» описывает симптом, но не причину. Медленно может загружаться модель, долго обрабатываться большой ввод, с задержкой начинаться генерация или возникать очередь из нескольких запросов. Для каждого случая нужны разные проверки. Рост числа ядер не устранит нехватку RAM, а добавление памяти не исправит ограничение контейнера.

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

• [ ] Запишите точное имя модели и вариант квантизации. Сверьте их с локальным списком моделей и не меняйте их между сравниваемыми запусками.
• [ ] Подготовьте один и тот же запрос и одинаковую историю диалога. Если приложение передаёт контекст автоматически, сохраните и фактический ввод, а не только текст последнего сообщения.
• [ ] Отдельно измерьте задержку до первого токена и время генерации ответа. В API Ollama для этого предусмотрены поля с длительностями этапов; их описание есть в документации API генерации.
• [ ] Во время теста наблюдайте за занятой и доступной памятью, использованием swap, загрузкой CPU и активностью диска. Фиксируйте также работающие рядом приложения и контейнеры.
• [ ] Повторите запуск без параллельных запросов и фоновых задач, а затем отдельно проверьте обычный режим работы. Это поможет отличить медленную генерацию одного запроса от ожидания в очереди.
• [ ] После каждой корректировки меняйте только один фактор. Записывайте результат и условие теста, иначе сравнение не покажет, что именно помогло.

Для оценки используйте одинаковый набор входных данных. В качестве краткого журнала подойдут строки «модель и квантизация», «длина контекста», «время до первого токена», «время генерации», «память и swap», «ограничения контейнера» и «соседняя нагрузка». Универсального значения задержки, после которого всем нужно менять сервер, нет: приемлемое время зависит от того, отвечает ли система человеку в интерактивном диалоге или обрабатывает задачу в фоновом режиме.

Не сравнивайте свой результат с показателем из случайного обсуждения, если неизвестны процессор, память, версия модели, формат квантизации, длина контекста и параметры запуска. Публикация Ollama об обновлении 0.30 от 5 июня 2026 года описывает изменения, связанные с llama.cpp и совместимостью с GGUF, но это не обещание определённой скорости на конкретном сервере. Актуальные выпуски проверяются в официальном журнале GitHub.

Проверьте модель и контекст до увеличения ресурсов

Размер файла модели — только начальная оценка занимаемой памяти. Для грубой оценки весов можно использовать формулу:

параметры модели × битность квантизации ÷ 8.

Результат не равен точному требованию к RAM: дополнительно учитываются служебные данные, особенности реализации и память для контекста. При генерации важна и KV cache, объём которой зависит от настроек модели и длины контекста. Поэтому модель, чей файл формально помещается в память, не обязательно оставит достаточно RAM для стабильной работы вместе с Ollama и остальными сервисами. Сведения о форматах и моделях приведены в документации llama.cpp по поддерживаемым моделям, а поведение Ollama и частые ограничения — в её официальном FAQ.

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

Контекст тоже требует проверки. Приложение может передавать модели историю диалога, найденные фрагменты документов и системные инструкции, даже если пользователь ввёл короткое сообщение. Сравните фактический объём передаваемого текста с тем, что нужно для ответа. Уберите старые сообщения, не относящиеся к текущей задаче, и проверьте, можно ли сократить размер фрагментов из поиска. Если после сокращения контекста меняется время обработки, это полезный результат; он ещё не доказывает, что серверу не хватает ядер.

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

Разделите нехватку памяти и вычислительную нагрузку

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

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

Для CPU-only-инференса полезно также понимать ограничения платформы. Серверы SFP Cloud на AMD EPYC 7543P имеют Zen 3 и поддерживают AVX2, но не AVX-512; число ядер и поддерживаемые инструкции само по себе не превращается в гарантию определённого времени ответа. Если рабочая нагрузка критически зависит от ускорения GPU, процессорная конфигурация не заменит подходящую GPU-систему.

Проверьте потоки и ограничения Docker

Когда Ollama запущена в контейнере, важно выяснить, какие ресурсы видны самому контейнеру, а не только сколько CPU установлено в хосте. Настройки cpuset могут закрепить контейнер за частью процессоров, а CPU quota — ограничить доступное процессорное время. Docker описывает эти механизмы в разделе о ресурсных ограничениях контейнеров.

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

• [ ] Посмотрите конфигурацию запуска контейнера и проверьте, задан ли cpuset.
• [ ] Проверьте наличие CPU quota и сравните её с фактической нагрузкой хоста.
• [ ] Уточните, сколько CPU видит контейнер и не запущена ли рядом конкурирующая задача.
• [ ] Проверьте параметры Ollama, связанные с параллельными запросами и настройками модели, только по документации текущей версии.
• [ ] После изменения одного ограничения повторите тот же базовый тест и сопоставьте время, загрузку CPU и память.

Не применяйте найденные в обсуждениях значения числа потоков как готовый рецепт. Рекомендация, подходящая одному процессору, сборке Ollama и контейнеру, может ухудшить работу другой конфигурации. Учитывайте и то, что ресурсы хоста могут делиться с системой, приложениями и базой знаний. Документация Ollama по запуску в Docker доступна в официальном руководстве; параметры запуска следует сверять с ним и текущими релизами, а не копировать без проверки из чужой конфигурации.

Сопоставьте симптомы с подходящим решением

Перед выбором между оптимизацией, увеличением ресурсов и сменой архитектуры определите, какая часть системы замедляет работу. Сравнение ниже — не таблица гарантированных результатов, а способ выбрать следующую проверку. Подходящие конфигурации и условия оплаты SFP Cloud можно проверить в актуальном каталоге серверов.

Таблица помогает избежать распространённого вывода «CPU занят — значит, нужно больше ядер». Загрузка CPU во время вычислений ожидаема, но решение об аренде новой машины зависит от продолжительности нагрузки, требуемой задержки и того, сколько задач выполняются одновременно. Аналогично, краткий всплеск использования swap во время запуска не доказывает, что постоянная конфигурация непригодна: важно проверить, повторяется ли проблема в обычном рабочем режиме.

Разделите модель, приложение и фоновые задачи

В самохостинговой системе генерация может конкурировать с поиском по векторной базе, обработкой документов, построением эмбеддингов и веб-приложением. Сведите в перечень процессы, которые реально работают одновременно, и отметьте, какие из них критичны для ответа пользователю. Затем протестируйте Ollama отдельно, а после — вместе с обычной нагрузкой. Если задержка появляется только во втором тесте, проблема может быть в совместном размещении сервисов, а не в модели самой по себе.

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

Для приватной базы знаний отдельно определите, какие документы остаются на собственном сервере и какая часть запроса передаётся внешней модели, если используется API. Размещение приложения и индекса на собственной машине не означает, что данные автоматически остаются локальными при любой схеме генерации. Границы передачи данных нужно описать в архитектуре и проверить в настройках приложения; сведения о подходе SFP Cloud к обработке данных изложены на странице политики конфиденциальности.

Используйте конфигурацию сервера только под измеренный узкий участок

На странице SFP Cloud представлены независимые серверы с AMD EPYC 7543P: 32 ядра и 64 потока, варианты памяти 128 или 256 ГБ DDR4-3200 ECC RDIMM и два NVMe-накопителя по 1 ТБ с прямым подключением. Доступная ёмкость накопителей для хранения модели и данных составляет 2 ТБ; аппаратного RAID нет. Серверы расположены в Токио. Эти параметры — не результат теста Ollama и не прогноз скорости генерации; они описывают доступные ресурсы, которые следует сопоставлять с вашей измеренной нагрузкой. Условия оплаты и доступные конфигурации следует сверять в актуальной таблице тарифов SFP Cloud.

Выбор между вариантами памяти делайте по суммарному потреблению: модель и её рабочий набор, контекст, Ollama, приложение, поиск по документам и фоновые задачи. Учитывайте не только момент запуска, но и одновременную работу обычных сервисов. Память в этих конфигурациях нельзя впоследствии увеличить добавлением модулей, поэтому нужный объём следует выбрать заранее по наблюдаемой нагрузке, а не по одному размеру файла модели. Если данные важны, предусмотрите отдельную схему резервного копирования: прямое подключение NVMe не создаёт зеркальную копию.

Переход с VPS на независимый сервер оправдан, когда мониторинг показывает устойчивую нехватку выделенной памяти или CPU, ограничения виртуальной машины мешают предсказуемой работе, а нагрузка рассчитана на постоянное размещение. Но независимость ресурсов не превращает CPU в GPU. Если нужное время ответа не достигается на подходящей модели после проверки контекста и ограничений контейнера или если несколько запросов должны обслуживаться с низкой задержкой, рассмотрите GPU-инференс либо внешний API. SFP Cloud не предоставляет GPU — поэтому CPU-сервер нельзя выбирать как замену GPU для такого требования.

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

Часто задаваемые вопросы

Почему Ollama на CPU может отвечать медленно без ошибки?

CPU-only-инференс выполняет вычисления на процессоре и не обеспечивает автоматически скорость GPU-системы. На задержку также влияют размер модели, квантизация, длина контекста, KV cache, доступная память и ограничения контейнера. Сравнивайте повторные запуски с одинаковым запросом, отдельно фиксируя задержку до первого токена и длительность генерации.

Сначала менять модель или увеличивать память?

Сначала проверьте доступную RAM и swap. Если система обращается к swap или модель вместе с остальными процессами не помещается в память, уменьшите нагрузку либо подберите модель и квантизацию под доступные ресурсы. Если памяти достаточно и обмена с диском нет, сравните более компактную модель: дополнительная RAM сама по себе не ускорит вычисления, ограниченные CPU.

Может ли длинный контекст замедлять генерацию?

Да. Длинный контекст требует обработки большего объёма входных данных и может увеличивать расход памяти, в том числе на KV cache. Проверьте фактическую историю и найденные документы, которые приложение передаёт модели. Сокращайте только нерелевантные данные и сравнивайте варианты на одинаковом наборе запросов, оценивая не только время, но и качество ответа.

Как проверить потоки Ollama в Docker?

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

Если после этих проверок генерация остаётся медленной, сначала сверяйте журнал тестов с требованиями приложения, а затем — доступные конфигурации. Для Ollama CPU, которой нужны постоянные ресурсы и предсказуемая работа рядом с другими сервисами, независимый сервер SFP Cloud может быть уместнее VPS с ограниченной или разделяемой средой. Но при жёстком требовании к низкой задержке и высокой параллельности нужно выбирать GPU-инференс или внешний API, а не рассчитывать, что увеличение CPU-сервера решит задачу.

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

1. Q
   Почему Ollama на одном процессоре может отвечать медленно даже без видимой ошибки?

   CPU-only-инференс выполняет вычисления на процессоре и не следует ожидать от него скорости GPU-системы. Время ответа также зависит от размера модели, квантизации, объёма контекста, KV cache, доступной памяти и того, не ограничен ли контейнер. Сравните повторные запуски с одинаковыми входными данными и отдельно оцените задержку до первого токена и длительность генерации.

2. Q
   Что сначала менять при медленном CPU-инференсе в Ollama — модель или объём памяти?

   Сначала выясните, есть ли признаки нехватки памяти: активный swap, загрузка модели с обращениями к диску или недостаток доступной оперативной памяти. Если модель помещается в RAM и обмена с диском нет, проверьте более компактную модель или подходящую квантизацию при неизменном запросе. Увеличение памяти не ускорит вычисления, если ограничение связано с процессором.

3. Q
   Может ли длинный контекст замедлить генерацию в Ollama?

   Да, длинный контекст увеличивает объём данных, который нужно обработать, и может повысить требования к памяти, включая KV cache. Проверьте, действительно ли приложению нужна вся передаваемая история: удалите нерелевантные сообщения и сравните результаты на одинаковой модели. Не меняйте одновременно длину контекста, квантизацию и параметры запуска — иначе будет сложно установить причину изменения.

4. Q
   Как проверить ограничения потоков и CPU, если Ollama запущена в Docker?

   Сначала проверьте, какие CPU доступны контейнеру, и сравните это с ограничениями quota и cpuset в конфигурации запуска. Затем убедитесь, что Ollama использует доступные ресурсы, а параллельно не работают другие контейнеры с тяжёлой нагрузкой. Синтаксис и поддерживаемые настройки сверяйте с актуальной документацией Ollama и Docker; найденное в обсуждении частное значение не считайте универсальной настройкой.