Легкие LLM на CPU: какие задачи реально решать на недорогом VPS

Фронтирные модели, в которых компании ежедневно сжигают миллиарды токенов, становятся все более монструозными и дорогими. Экономика и законы о ПДн подталкивают бизнес к идее локального инференса. Но запуск большой открытой модели требует сложной инфраструктуры и дорогих GPU (которые еще попробуй найди!). Хорошая новость в том, что для многих бизнес-задач – разобрать обращения, достать контакты из письма, оценить отзыв – фронтирные модели избыточны. Это все равно что забивать гвозди микроскопом. А легкие модели размером 1–4B работают и на обычных процессорах.

Я проверил, насколько это рабочий вариант: взял VPS с шаблоном Ollama примерно за 1,5 тыс. ₽ в месяц (4 vCPU, 4 ГБ RAM, без видеокарты) и прогнал девять легких моделей на семи бизнес-задачах плюс нагрузочный тест.

TL;DR

• На VPS с 4 vCPU и 4 ГБ RAM без видеокарты работают модели до 4B параметров.

• Короткие задачи – классификация обращений, тональность отзывов – модели решают на рабочем уровне: QVikhr-3-4B правильно разметила 20 обращений из 20, по 3,5 сек на каждое. Потолок сервера – около 950 таких запросов в час.

• Извлечение данных из заявок, нормализация CRM и черновики объявлений работают, если ответы модели проверяет код, а то, что уходит наружу, – человек.

• Длинные тексты (резюме документов, ответы по базе знаний) – это 40-100 сек на ответ и активный swap. Подходит для фоновой обработки, для чата с клиентом – нет.

• Модели на 1-2B для бизнес-задач не подходят: путают категории и придумывают факты.

• Сервер обрабатывает запросы по очереди. Параллельные слоты и flash attention на этом сервере скорость не увеличили.

• Узкое место – память. Рекомендую брать за минимальную базу конфигурацию с 8 ГБ RAM.

Кому будет полезна эта статья

Во-первых, командам, у которых много текстовой рутины, – поддержке, продажам, маркетингу, продукту, в интернет-магазине на десяток сотрудников или в отделе крупной компании. Под рутиной я понимаю разбор обращений и заявок, анализ отзывов, ответы по базе знаний, черновики объявлений и чистку данных в CRM. Статья особенно полезна тем, кому нельзя или не хочется отдавать данные клиентов в облачные API.

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

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

Инфраструктура эксперимента: VPS с шаблоном Ollama

Сервер – обычный VPS у Justhost.ru, на который при заказе ставится шаблон Ollama. Внутри шаблона:

• Ollama 0.35 и Open WebUI 0.11 в Docker; снаружи nginx с HTTPS (без своего домена сертификат самоподписанный);

• предустановленная модель llama3.2:1b (1B, 1,3 ГБ) – можно сразу писать в чат;

• API Ollama наружу не открыт: программы ходят к модели через Open WebUI по API-ключу, есть OpenAI-совместимый эндпоинт;

• требования шаблона – от 4 ГБ RAM, 4 vCPU и 40 ГБ диска; автобэкапов нет.

Характеристики сервера: 4 vCPU Intel Xeon Gold 6148 (2,4 ГГц), 4 ГБ RAM (доступно 3,8 ГБ), без GPU, Ubuntu 24.04, около 1,5 тыс. ₽ в месяц.

Я рассчитывал получить сервер, на котором удобно запускать разные модели. Но оказалось, что шаблон собран под одну маленькую модель и чат, и под мои задачи его пришлось перенастраивать:

• Open WebUI сам занимает около гигабайта памяти. Вместе с ним в 4 ГБ помещаются только модели на 1-3B. Чтобы запустить 4B, интерфейс пришлось остановить.

• Образы Docker занимают около 13 ГБ диска еще до первой скачанной модели.

• Предустановленная модель отвечает быстро, но в тестах на бизнес-задачах оказалась худшей из девяти.

Цель и вопросы эксперимента

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

1. Какие типовые бизнес-задачи вообще решаются моделями, которые помещаются в 4 ГБ?

2. Какая модель лучше для каждой задачи, и есть ли универсальная?

3. Сколько времени уходит на одну задачу и сколько задач сервер сделает за час?

4. Что будет под нагрузкой, когда запросы приходят одновременно, и помогают ли настройки Ollama?

Для ответа я прогнал семь сценариев, которые встречаются почти в любом бизнесе: классификация обращений, тональность отзывов, извлечение данных из заявки, суммаризация, ответы по базе знаний (RAG), объявления для Яндекс Директа и нормализация данных CRM, и в конце провел нагрузочный тест.

Стенд, модели и подготовка сервера

При выборе моделей основной критерий был один – они должны помещаться в память вместе с контекстом, то есть быть не больше 4B параметров в 4-битной квантизации. Я взял популярные семейства из реестра Ollama и две модели с Hugging Face, в том числе дообученную на русском QVikhr.

Модели с Hugging Face и большинство из реестра – в квантизации Q4_K_M. Российские модели покрупнее, такие как GigaChat 3.1 Lightning, T-lite и YandexGPT-5-Lite, в 4 ГБ не поместились и ждут тестов на сервере побольше.

Перед замерами пришлось немного повозиться с сервером и сделать четыре вещи:

• Swap 4 ГБ с vm.swappiness=10. Без него ядро завершало 4B-модели на длинных текстах по нехватке памяти, со swap они работают, хотя и медленнее.

• Open WebUI остановлен на время замеров: гигабайт памяти на этом сервере – это четверть всей RAM.

• fail2ban на SSH. В первые же дни подключения стали обрываться по таймауту: сервер перебирали боты. Когда fail2ban начал блокировать IP после пяти неудачных попыток (с нарастающим сроком), подключения стабилизировались.

• Никакой посторонней нагрузки во время замеров. Пробный прогон параллельно со скачиванием моделей шел в 1,7 раза медленнее.

Как был устроен эксперимент

Все сценарии прогонялись одним раннером на Python без внешних зависимостей, который ходит в API Ollama. Сценарий – это папка из двух файлов: dataset.json с примерами и эталонами и scenario.py с промптом, JSON-схемой ответа и функцией оценки.

Датасеты. На каждый сценарий – от 4 длинных документов до 30 коротких примеров на русском с эталонными ответами и меткой сложности. Не меньше трети из них «ловушки»: сарказм, два телефона в письме, отмененное по ходу совещания решение, «до пятницы» вместо даты. Данные синтетические, были сгенерированы под вымышленный интернет-магазин электроники с небольшим отделом продаж.

Одинаковые условия для всех моделей:

• один промпт без подгонки под конкретную модель;

• структурный ответ через structured outputs Ollama (JSON-схема в поле format), как и в реальной интеграции;

• temperature 0, seed 42, num_ctx 2048 (для длинных документов 6144); для объявлений в Директ temperature 0.7;

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

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

Запрос к модели выглядит так:

payload = {    "model": "qwen3.5:4b",    "messages": [{"role": "system", "content": rules},                 {"role": "user", "content": text}],    "format": schema,          # JSON-схема ответа    "think": False,            # для моделей с режимом рассуждения    "options": {"temperature": 0, "seed": 42, "num_ctx": 2048},    "keep_alive": "15m",    "stream": False,}r = api("/api/chat", payload)# в ответе: prompt_eval_count/duration, eval_count/duration – из них считаем скорости

Метрики. Качество (точность, macro-F1, доля верных полей или фактов), время на задачу, скорость чтения промпта и генерации в токенах в секунду, задач в час, холодный старт и память модели. Swap я оценивал по объему обмена из /proc/vmstat, а не по пику занятого swap: старые страницы в swap работу не замедляют, замедляет только активный обмен.

Ручной разбор. Автоматическая оценка – это только первый фильтр. Все ошибки я читал руками и отделял ошибки модели от спорной разметки и слишком строгой проверки. Если была виновата проверка, она правилась, а пересчет проводился по сохраненным ответам, без повторного прогона. Если виноват был промпт, исправленная версия тестировалась отдельным прогоном, и в статье показаны оба результата.

Результаты по сценариям

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

Закономерность по всем сценариям: модели от 2B параметров дали рабочий результат, модели на 1B – нет. В классификации у предустановленной llama3.2:1b 7 ошибок из 20. В RAG на все три вопроса, которые в базе не рассматриваются, она сочинила свои ответы. В извлечении данных модели на 1B придумали по 4-8 полей.

Классификация обращений

В датасет вошли 20 обращений в поддержку интернет-магазина по шести категориям, 8 из 20 – смешанные темы. QVikhr-3-4B, qwen3.5 (2B и 4B) и gemma3:4b сделали все без ошибок, но с трехкратной разницей в скорости: 1018 обращений в час у QVikhr и 312 у qwen3.5:4b. Причина была не в генерации (ответ – 7-8 токенов), а в чтении промпта: QVikhr переиспользовала уже прочитанный системный промпт (кэш префикса) и читала 154 ток/с, а гибридные qwen3.5, granite и gemma3 со скользящим окном каждый раз читали его заново по 28-46 ток/с. На CPU это главный фактор скорости. В сложном примере «продавец не разбирается в товаре, обучайте персонал» 4 модели из 9 приняли жалобу за вопрос о товаре.

Тональность отзывов

Модели получили в работу 24 отзыва, в том числе смешанные, с сарказмом и сленгом. QVikhr и qwen3.5:4b справились с 22 из 24, но QVikhr сделала это вдвое быстрее. Сарказм не распознал почти никто. Отзыв «Спасибо, что всего за три недели доставили, я почти забыл, что заказывал» 7 моделей из 8 оценили как позитивный или нейтральный, а QVikhr записала причину как «быстрая доставка за три недели». Модели на 1B все смешанные отзывы записали в негатив и местами переходили на смесь языков («kurьер»). На практике можно так: если модель видит позитив, а оценка в звездах низкая, отзыв уходит на проверку человеку.

Извлечение данных из заявок

На входе был датасет из 10 писем в отдел продаж, в каждом шесть полей: контакт, компания, телефон, email, бюджет, срок. Некоторые письма содержали «ловушки»: диапазон бюджета, ИНН и номер счета для путаницы, название дня недели вместо конкретной даты и т. п. Контакты и бюджет сильные модели доставали почти идеально, а вот сроки нет. «До пятницы» в письме от вторника 20.10 не перевела в 23.10 ни одна модель. Первая версия промпта кое-где сама сбивала модели. После уточнения правил qwen3.5:4b дала 59 полей из 60 и ни одного выдуманного, а вот gemma3:4b от тех же правок стала только хуже (57 → 54). Правила для маленьких моделей лучше проверять отдельно на каждой.

Суммаризация

Для этого сценария я заготовил четыре документа, включая расшифровку совещания на 2000 слов, где решения меняются по ходу встречи. Задача – написать резюме из пяти основных пунктов для руководителя. Сильные модели правильно взяли итоговые решения, а не первоначальные. Но в резюме попадались искажения, которые находит только человек: gemma3:4b посчитала прирост продаж в 13% вместо 8%, qwen3.5:2b написала, что технически сложные товары «не подлежат возврату», потеряв оговорку «кроме брака». Без искажений справилась только qwen3.5:4b, но на документ в 600 слов у нее ушло 71 сек, и сервер при этом активно использовал swap. QVikhr, лидер коротких задач, здесь оказалась самой медленной: 6,3 мин на расшифровку. У нее обычное внимание, и кэш контекста растет с длиной текста, а у гибридных qwen3.5 почти не растет.

Ответы по базе знаний (RAG)

База включала пять документов (около 4700 слов), нарезанных на 34 фрагмента. Модель bge-m3 перевела фрагменты и вопросы в векторы. К вопросу подбирались четыре самых близких по смыслу фрагмента, и в промпт вместе с вопросом попадали только они, а не вся база. Индексация всей базы заняла 49 сек, поиск – 0,1 сек, и нужный документ находился всегда. QVikhr, qwen3.5 (2B и 4B) и granite ответили верно на 14 вопросов из 15 и честно писали «в базе нет информации», когда ответа не было. Слабым местом стали исключения из правил. На вопрос «Можно ли вернуть исправный ноутбук?» модели отвечали «Да, в течение 14 дней», хотя из найденного фрагмента прямо следовало обратное. Но это можно починить на стороне базы: исключения стоит оформлять явными вопросами-ответами. Скорость 40-95 сек на вопрос приемлема для внутреннего помощника, но не для чата с клиентами.

Объявления для Яндекс Директа

Модели получили шесть брифов. По каждому требовалось создать пять объявлений: заголовок до 56 символов, текст до 81 символа, только факты из брифа. Маленькие модели не умеют считать символы. Длина текста у большинства из них лежала в диапазоне 80-170 символов при лимите 81. Только qwen3.5:4b уложилась в лимит во всех 30 объявлениях. Лишь 50% сгенерированных объявлений не нуждались в фактологических правках. Qwen раздавала вымышленные скидки, а gemma3:4b придумала кредит с «решением банка за 5 минут». QVikhr выдавала почти одинаковые варианты. Рабочая схема в таких обстоятельствах: генерировать 10–15 вариантов и отфильтровывать кодом по длине и цифрам из брифа.

Нормализация данных CRM

Каждая модель получила три запроса, по 10 «грязных» строк одного типа в каждом: телефоны, названия компаний или адреса («мск садовая 14-8», «ебург»). Адреса сильные модели разбирали хорошо – именно такие случаи трудно покрыть регулярками. А вот с телефонами возникли проблемы: даже сильные модели обнуляли номера и превращали белорусские в российские. Такого типа задачи лучше отдавать коду. Самый опасный обнаруженный дефект – сдвиг строк. У 4 моделей из 9 в одном из запросов ответы съехали на одну позицию, и каждая запись досталась чужому клиенту. В боевой интеграции ответ должен содержать id строки, а код должен проверять соответствие.

Нагрузочный тест: сколько выдержит сервер

В сценариях выше запросы шли по одному, поэтому замеры показывают, сколько ждет ответа один пользователь. На практике запросы приходят одновременно от нескольких сотрудников или интеграций, и важно, сколько запросов потянет сервер и насколько вырастет задержка. Чтобы это измерить, я написал небольшой нагрузочный скрипт: он шлет серию запросов в 1, 2 и 4 потока и считает пропускную способность, медиану и p95 задержки, память и обмен со swap. Запросы были двух типов: короткие, как при классификации обращений, и длинные, как при ответах по базе знаний (около 2 тыс. токенов на входе).

Три конфигурации Ollama:

• A – настройки Ollama из шаблона без изменений, по одному запросу за раз;

• B – OLLAMA_NUM_PARALLEL=4;

• C – B плюс OLLAMA_FLASH_ATTENTION=1 и OLLAMA_KV_CACHE_TYPE=q8_0.

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

Из этого следует, что:

• Одна модель – одна очередь. Пропускная способность на 1, 2 и 4 потоках одна и та же (qwen3.5:4b: 272 / 279 / 274 в час), растет только ожидание. Четыре сотрудника, задавшие вопрос одновременно, ждут вчетверо дольше.

• Параллельность на 4 vCPU не помогает. Процессор просто делится между запросами: генерация на запрос падает с 6,9 до 1,2 ток/с, а слоты резервируют память под контекст четырех запросов, и на длинных задачах сервер тонет в swap.

• qwen3.5 параллельные запросы не поддерживает вовсе. Ollama 0.35 пишет в лог model architecture does not currently support parallel requests и тихо обрабатывает их по одному, а память под слоты все равно резервирует.

• Flash attention на этом CPU вредит: чтение промпта падает с 27 до 12 ток/с. А сжатие KV-кэша без flash attention в Ollama не включается.

• Длинный контекст упирается в память. При очереди из 2-4 длинных запросов к 4B-модели ядро убивает процесс (Out of memory: Killed process ... (llama-server)), клиент получает HTTP 500, модель грузится заново около 30 сек. Без ошибок под нагрузкой выжила только qwen3.5:2b.

В нагрузочном тесте лучше всего показала себя Ollama, в настройках которой я ничего не менял (конфиг A). Параллельные слоты, flash attention и сжатие KV-кэша на этом сервере выигрыша не дали.

Проблемы с замерами и как их обойти

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

1. Кэш промпта искажает замеры. В первом нагрузочном прогоне длинные запросы «читались» со скоростью 1900 ток/с вместо 27: одни и те же вопросы повторялись, и llama.cpp брал их из кэша. Результат пришлось выбросить. Решение – случайная метка в каждом запросе и прогрев посторонним текстом. По той же причине в ранних сценариях было занижено время первого примера.

2. Неотключаемое рассуждение обнуляет результат. LFM2.5-2.6B игнорировала think: false, расходовала весь лимит токенов на рассуждение и возвращала пустой ответ. В первом прогоне классификации она не разметила ни одного обращения из 20, и дело было в лимите, а не в качестве. С лимитом 1024 токена она отвечала прилично, но в 10 раз медленнее остальных. На CPU рассуждение не окупилось ни в одном сценарии.

3. Слишком строгая автопроверка занижает оценки. Первая версия скрипта оценки засчитывала адрес, только если в нем были «г.» перед городом и «д.» перед номером дома. Модели писали «Москва, ул. Ленина, 5»: по смыслу верно, но скрипт поставил всем ноль. Так же проверка цифр в объявлениях считала выдумкой сокращение «15 тыс.», потому что искала в тексте точное число из брифа. Поэтому ошибки стоит разбирать вручную, а сырые ответы сохранять, чтобы пересчитывать оценку без повторного прогона.

4. Примеры в промпте не должны совпадать с заданиями из теста, иначе вы меряете не модель, а подсказку.

5. Сторонняя нагрузка искажает результаты. Скачивание модели параллельно с прогоном замедлило его в 1,7 раза. По той же причине скорость ответов на VPS может меняться от прогона к прогону из-за активности соседей по хосту.

6. Боты обрывают SSH-подключения. Сервер со входом по паролю начинают перебирать сразу. fail2ban тут гигиенический минимум, но вход по ключу надежнее.

7. Переключение между моделями съедает до 35 сек. Две 4B-модели в 4 ГБ не помещаются; на каждое переключение уходит 20-35 сек загрузки. В проде модель нужно держать загруженной. В шаблоне модель выгружается после 30 мин простоя (OLLAMA_KEEP_ALIVE=30m), и первый запрос после паузы снова ждет загрузки.

Что в итоге можно доверить модели на сервере за 1,5 тыс. ₽

Даже на VPS без GPU локальные LLM неплохо справляются с некоторыми распространенными бизнес-задачами.

Им в целом можно доверить:

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

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

• отвечать сотрудникам по внутренней базе знаний за полминуты-минуту;

• ночью делать резюме документов, черновики объявлений и чистку базы клиентов.

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

Какую модель выбрать

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

Ставьте очередь с одним обработчиком, таймаут от 5 мин для длинных задач и повтор при ошибке 500. В RAG попробуйте брать три фрагмента вместо четырех: в моем тесте нужный документ всегда попадал в первый фрагмент, а короткий промпт читается быстрее.

Узкое место – память. С 8 ГБ RAM 4B-модели перестанут уходить в swap и падать на длинных текстах, а в памяти поместятся две модели и чат. У того же Justhost.ru разница между 4 и 8 ГБ при тех же 4 vCPU около 550 ₽ в месяц. Больше ядер ускорит чтение длинных текстов, но кратного роста темпа, скорее всего, не даст. Чат для клиентов с ответом за секунды уже задачка для GPU с другим порядком цен.

P.S. Если вы запускали легкие модели на CPU под свои задачи, напишите в комментариях, какие сценарии и модели у вас заработали.