Какие AI модели можно запустить на своем сервере

Что определяет, какие модели ИИ можно разместить на собственном сервере

То, какие модели ИИ можно разместить на собственном сервере, определяется одним числом: объемом оперативной памяти на устройстве. Семейство модели и фреймворк имеют гораздо меньшее значение, чем то, помещаются ли веса в память с запасом. В этой статье приведена арифметика для таких расчетов. Установка среды выполнения — это отдельная задача, описанная в руководстве по запуску Ollama на VPS.

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

Расчет объема: бит на параметр

Файл модели почти полностью состоит из весов. Каждый вес хранится с определенным количеством бит. Квантование означает хранение весов с меньшим количеством бит, чем при обучении; это приводит к незначительной потере точности, но значительно экономит память. Размер модели рассчитывается напрямую из этого показателя:

weights in GB = (parameters in billions x bits per weight) / 8

Модели выпускаются с точностью 16 бит, что соответствует 2 ГБ на миллиард параметров. Именно поэтому почти никто не запускает модели в исходной точности на VPS. Ниже приведены варианты квантования, которые вы встретите на практике, с их реальным средним количеством бит на вес:

• Q8_0 хранит около 8.5 бит на вес, что составляет примерно 1.1 ГБ на миллиард параметров.
• Q6_K хранит около 6.6 бит, что составляет примерно 0.83 ГБ на миллиард.
• Q5_K_M хранит около 5.7 бит, что составляет примерно 0.71 ГБ на миллиард.
• Q4_K_M хранит около 4.8 бит, что составляет примерно 0.6 ГБ на миллиард.

Используйте значение 0.6 ГБ на миллиард параметров как рабочую оценку. Q4_K_M — разумный выбор по умолчанию для систем, ограниченных объемом памяти: потеря качества по сравнению с 8 битами невелика в большинстве задач, а размер файла почти вдвое меньше. Ниже 4 бит потери быстро растут, поэтому модель 70B, сжатая до 2 бит, обычно работает хуже, чем модель 32B с квантованием 4 бита того же поколения. Если памяти не хватает, лучше выбрать модель меньшего размера, чем опускаться ниже 4 бит.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

В столбце весов выше применено правило 0.6 ГБ на миллиард. Реальные файлы GGUF отклоняются от этого значения на несколько процентов, так как слои эмбеддингов и вывода сохраняются с более высокой точностью, чем остальные. Модель 3B с квантованием 4 бита занимает около 1.8 ГБ. Модель 8B занимает 4.8 ГБ. Модель 32B занимает 19.2 ГБ, а модель 70B — 42 ГБ.

Почему длина контекста потребляет больше оперативной памяти, чем веса модели

KV cache (кэш ключей и значений, состояние внимания, которое модель хранит для каждого токена в текущем диалоге) — это вторая статья расходов памяти. Он выделяется при загрузке модели, его размер определяется заданной длиной контекста, и он растёт линейно по мере увеличения этой длины.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

При стандартном контексте Ollama модель 8B тратит полгигабайта на кэш. При 8192 токенах она потребляет 1 GB. При контексте 128k, заявленном в карточке модели, она потребляет 16 GB, что более чем в три раза превышает размер весов. Модель 70B — обратный случай: её кэш при 128k составляет 40 GB, что меньше размера её собственных весов, так как механизм grouped query attention не даёт стоимости на токен расти так же быстро, как количеству параметров.

Стандартная длина контекста Ollama составляет 4096 токенов на сервере только с CPU. При наличии GPU значение выбирается автоматически исходя из объёма VRAM: 32k при объёме от 24 до 48 GiB и 256k при 48 GiB и выше. Увеличьте это значение с помощью переменной OLLAMA_CONTEXT_LENGTH на сервере, а затем проверьте, какое значение фактически получила запущенная модель, в столбце CONTEXT команды ollama ps. Математика памяти для этого параметра подробно разобрана в статье о num_ctx и длине контекста.

Есть два способа уменьшить потребление памяти кэшем. Запрашивайте тот контекст, который вам действительно нужен, а не тот, что указан в карточке модели, так как большинство задач чата и программирования укладываются в диапазон от 8k до 32k. Либо выполните квантование самого кэша до 8 бит, что сократит его размер вдвое ценой некоторого снижения точности при работе с длинным контекстом.

Резидентная модель удерживает RAM до тех пор, пока её что-то не выгрузит

Ollama удерживает модель в памяти в течение 5 минут после последнего запроса, после чего выгружает её. Это значение по умолчанию подходит для ноутбука, но не для сервера, где каждый первый запрос после периода простоя снова требует времени на загрузку.

ollama ps
ollama stop qwen3:4b

ollama ps выводит список резидентных моделей, где столбец SIZE показывает объем занимаемой памяти, а столбец UNTIL — время до истечения срока хранения. Чтобы закрепить модель в памяти постоянно, установите OLLAMA_KEEP_ALIVE=-1 в настройках сервиса. Значение 0 приводит к выгрузке модели сразу после завершения каждого ответа.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Отправьте один запрос, а затем снова запустите ollama ps через десять минут. Модель всё ещё находится в списке, и именно в этом суть: она занимает RAM независимо от того, использует её кто-либо или нет. Закрепленная модель не является свободным ресурсом. На VPS с 16 GB модель 8B с контекстом 8k занимает примерно 6 GB на всё время работы сервиса, поэтому рассчитывайте ресурсы сервера исходя из суммы объема модели и вашего приложения, а не только модели. Закрепление модели в памяти описывает компромисс между этим подходом и задержкой при «холодном» старте.

Что можно запустить на VPS с 4 GB ОЗУ

Зарезервируйте около 1 GB для операционной системы и сервера моделей, что оставит примерно 3 GB свободными. Этого достаточно для моделей объёмом от 1B до 4B параметров с квантованием 4 бита и стандартным контекстом 4096 токенов. По состоянию на август 2026 года к этому классу относятся Llama 3.2 (3B), Qwen 3 (1.7B и 4B), а также компактные релизы Gemma и Phi. Рассматривайте эти названия как примеры размеров, а не как рекомендации. Названия моделей меняются каждые несколько месяцев, а математические принципы остаются прежними.

Ожидайте скорость генерации примерно от 6 до 14 токенов в секунду. Столь компактные модели хорошо справляются с узкими задачами: классификацией, извлечением тегов, краткими резюме, переписыванием абзацев в заданном стиле. Они плохо подходят для многошаговых логических рассуждений и работы с кодом, распределённым по нескольким файлам; никакие техники промптинга не исправят этот недостаток.

Основная проблема на данном уровне ресурсов — использование swap. Если модель не помещается в ОЗУ, Linux не отказывается её загружать. Вместо этого система выгружает память на диск. Поскольку для генерации каждого токена необходимо один раз считать все веса модели, скорость генерации падает до секунд на один токен. Следите за free -h, а также за столбцами si и so в утилите vmstat 1 во время работы модели. Ненулевые значения swap in и swap out в процессе генерации означают, что модель слишком велика для выбранного тарифного плана.

Что можно запустить на VPS с 8–16 ГБ ОЗУ

На этом уровне объема памяти self-hosted модели становятся по-настоящему полезными. На 8 ГБ можно запустить модель 7B или 8B с квантованием 4 бита (около 4.8 ГБ весов) и контекстом 8k. На 16 ГБ можно запустить модель 13B или 14B с квантованием 4 бита (около 8.4 ГБ) или оставить 8B с квантованием 8 бит, если вы предпочитаете точность модели, а не количество параметров.

Основная проблема — скорость. Модель 8B на CPU генерирует от 3 до 7 токенов в секунду, а 14B — от 1.5 до 3.5. Человек читает со скоростью примерно 5–10 токенов в секунду, поэтому работа с 8B на VPS без GPU напоминает наблюдение за медленным машинистом. Это приемлемо для фоновых задач, но утомительно для интерактивного чата. Замеры работы Qwen 3 (8B и крупнее) на VPS показывают, как это выглядит на практике.

Что можно запустить на VPS с 32–64 ГБ ОЗУ

Модель 32B с квантованием 4 бита занимает около 19.2 ГБ, поэтому она помещается на тариф с 32 ГБ ОЗУ при небольшом контексте и комфортно работает на 48 ГБ или 64 ГБ. Модель 70B с квантованием 4 бита занимает около 42 ГБ, поэтому ей требуется 64 ГБ ОЗУ еще до выделения памяти под кэш.

Затем объективно оцените скорость. Модель 32B на CPU обрабатывает примерно 0.6–1.5 токенов в секунду, а модель 70B — 0.2–0.5. Ответ из 500 токенов от модели 70B занимает около двадцати минут. При такой скорости запрос обычно завершается с ошибкой до того, как модель закончит работу: сначала срабатывает тайм-аут клиента или proxy перед Ollama. Именно поэтому появляется ошибка превышения контекстного срока ожидания. Это инструменты для пакетной обработки. Если поставить им на ночь очередь документов, скорость не имеет значения. Если использовать их за интерфейсом чата, она имеет большое значение.

Архитектура Mixture of Experts (MoE) меняет этот расчет, и это единственная деталь, которую стоит изучить. Модель MoE направляет каждый токен только через небольшую часть своих весов. Модель с 30B общих параметров и 3B активных параметров на токен требует объема памяти как у 30B, но генерирует текст со скоростью, близкой к плотной модели 3B, так как каждый токен считывает только активных экспертов. На сервере с 32 ГБ ОЗУ такая модель MoE гораздо практичнее, чем плотная модель 30B. Главное правило: общие параметры определяют требования к памяти, а активные параметры определяют скорость.

Насколько быстро работает CPU-инференс в реальности?

Генерация одного токена требует однократного считывания всех активных весов из оперативной памяти. Этого невозможно избежать, поэтому скорость генерации на CPU определяется пропускной способностью памяти, а не количеством ядер. Предел вычисляется делением: доступная пропускная способность памяти делится на размер весов в байтах. Небольшой VPS общего пользования в реальности обеспечивает от 10 до 25 ГБ в секунду на все vCPU, поэтому модель размером 4.8 ГБ выдает максимум 2–5 токенов в секунду.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

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

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

Сводка, выводимая после завершения ответа, заканчивается строкой eval rate: ... tokens/s. Это и есть ваша скорость генерации. Не учитывайте первый запуск сессии, так как показатель load duration в той же сводке включает время чтения весов с диска. В разделе Правильное измерение количества токенов в секунду описано, как получить значение, пригодное для сравнения.

Два результата обычно удивляют пользователей. Добавление vCPU быстро перестает давать прирост, так как после 8 ядер дополнительные ядра простаивают в ожидании данных из памяти, а не выполняют вычисления. А на тарифах общего пользования одна и та же команда выдает разные числа в разное время суток — это связано с CPU steal time из-за шумных соседей, а не с ошибками в вашей конфигурации.

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

Что меняется при добавлении GPU

Арифметика не меняется, меняется только пул ресурсов. VRAM — это жесткое ограничение, поэтому рассчитайте объем перед арендой:

• 8 GB VRAM вмещают модель 7B или 8B с квантованием 4 бита и коротким контекстом.
• 16 GB вмещают модель 14B с квантованием 4 бита и полноценным контекстом или 8B с квантованием 8 бит.
• 24 GB вмещают модель 32B с квантованием 4 бита при условии ограничения контекста.
• 48 GB и более вмещают модель 70B с квантованием 4 бита, оставляя место для кэша и параллельных запросов.

Если модель не помещается целиком, Ollama разделяет её: часть слоев выполняется на GPU, остальные — на CPU. ollama ps отображает распределение в столбце PROCESSOR, например, как 78%/22% CPU/GPU. Воспринимайте это как предупреждение, а не как полезную функцию. Скорость работы определяется частью, выполняемой на CPU, так как каждый токен ожидает обработки этих слоев. В результате модель, у которой четверть слоев находится на CPU, работает со скоростью, близкой к CPU, а не к GPU. Если вы видите непредвиденное разделение, сначала уменьшите длину контекста. Обычно именно кэш переполняет память.

Параллельная обработка — вторая причина для увеличения ресурсов. Веса модели являются общими для одновременных запросов, но каждый активный запрос требует собственного KV-кэша. Поэтому десять одновременных пользователей модели 8B с контекстом 8k потребуют в десять раз больше 1 GB кэша сверх объема весов. В статье Обслуживание параллельных пользователей с помощью одной self-hosted модели подробно описано, где находится этот предел.

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

Что нельзя разместить на собственном сервере

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

Первое — это закрытые веса. Передовые коммерческие модели не распространяются в открытом доступе, поэтому файла для загрузки не существует, и никакой объем оперативной памяти здесь не поможет. Вы можете разместить на своем сервере всё, что окружает модель: интерфейс, уровень поиска данных (retrieval layer), цикл агента, логи. Сама модель остается удаленным API. В статье Можно ли разместить Claude на своем сервере это разобрано подробно.

Второе — это модели с открытыми весами, которые просто слишком велики. Самые крупные открытые релизы представляют собой архитектуры mixture of experts с общим количеством параметров в сотни миллиардов. К ним применяется то же правило: модель с общим объемом 400B параметров в 4-битном квантовании требует около 240 GB только для весов, без учета кэша. Это специализированное оборудование, и его ежемесячная аренда стоит значительно дороже, чем большинство пользователей тратят на API-токены за год. В статье Что нужно для размещения модели класса Kimi на своем сервере описаны реальные требования. Такое же разделение встречается в библиотеке Ollama, где GLM 5.2 указана только как облачная модель, а на VPS загружается лишь её значительно более компактная версия.

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

Оцените доступные ресурсы перед выбором

free -h
nproc
lscpu | grep 'Model name'

Планируйте исходя из столбца available в free -h, а не столбца total, так как total учитывает память, которую система уже использует. Вычтите около 1 GB для операционной системы и сервера моделей. Разделите оставшееся значение на 0.6, чтобы получить максимальное количество параметров в миллиардах, которое можно разместить в 4-битном квантовании. Затем вычтите объем KV cache для нужного вам контекста. Полученное значение и будет вашим ответом; в отличие от списка названий моделей, этот метод не теряет актуальности.

FAQ

Сколько оперативной памяти нужно для запуска модели 8B?

Примерно 4.8 ГБ для весов при 4-битной квантованности, плюс KV-кэш для вашей длины контекста, плюс около 1 ГБ для операционной системы и сервера модели. При контексте в 8192 токена кэш добавляет около 1 ГБ, поэтому план на 8 ГБ подходит, а на 4 ГБ — нет. Если вам нужен полный контекст 128k, заявленный в карточке модели, только кэш составит 16 ГБ, и вам потребуется план на 32 ГБ.

Почему модель работает медленно, хотя на VPS много vCPU?

Потому что генерация ограничена пропускной способностью памяти, а не количеством ядер. Каждый токен требует выгрузки всего набора активных весов из оперативной памяти, поэтому, как только несколько ядер насыщают каналы памяти, остальные просто простаивают. Другая частая причина — swap. Если vmstat 1 показывает ненулевые значения si и so во время ответа модели, значит, веса не помещаются в RAM и часть каждого токена считывается с диска, что обходится значительно дороже, чем кажется.

Действительно ли для более длинного окна контекста нужно больше памяти?

Да, рост потребления памяти линейно зависит от количества токенов. Типичная модель 8B использует около 128 KiB KV-кэша на токен, поэтому 8192 токена стоят 1 ГБ, а 131072 токена — 16 ГБ. Кэш выделяется при загрузке модели, а не по мере роста диалога, поэтому запрос контекста 128k резервирует этот объем памяти сразу, даже если каждый ваш запрос состоит всего из 200 токенов.

Что лучше: запустить большую модель в 2 бита или меньшую в 4 бита?

Выбирайте меньшую модель в 4 бита. Качество падает медленно при переходе с 8 бит до 4 и быстро — ниже 4, поэтому модель 70B, сжатая до 2 бит, обычно дает худшие ответы, чем модель 32B в 4 битах того же поколения. Сильная квантованность проявляется в виде повторов и игнорирования инструкций, а не в виде сообщений об ошибках, из-за чего легко ошибочно винить свой промпт. Считайте 4 бита нижним пределом и лучше меняйте количество параметров.

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

Не на обычном VPS. Самые мощные модели с открытыми весами насчитывают сотни миллиардов параметров, что при 4 битах означает более 200 ГБ оперативной памяти еще до учета KV-кэша, а самые сильные коммерческие модели вообще не распространяются. Обычное оборудование хорошо справляется с запуском качественной модели от 8B до 32B для конкретной задачи, где узкоспециализированная и хорошо настроенная небольшая модель часто не уступает универсальной. Если вам нужно качество уровня frontier, сравните стоимость API и оборудования перед покупкой того или другого.