Как запустить Qwen 2.5 на VPS

MAATRIX

Qwen 2.5 — самая практичная открытая модель для скромного железа: линейка от 0,5B до 72B, честные 32 тысячи токенов контекста и приличный русский. Но между «модель скачалась» и «сервис отвечает приложениям» лежат шаги, на которых теряют половину скорости и весь контекст. Ниже — путь от чистой Ubuntu до рабочего API: команды, замеры и границы возможностей VPS.

Какой Qwen 2.5 брать: разбор тегов и размеров

В библиотеке Ollama у qwen2.5 больше сотни тегов, и половина проблем начинается с того, что скачали не то. Формат: qwen2.5:<размер>-<вариант>-<квантование>; короткое qwen2.5 — псевдоним для qwen2.5:7b-instruct-q4_K_M, 4,7 ГБ.

Три вещи до первого pull:

• Вариант base вместо instruct. Базовые веса не выполняют инструкции, а продолжают текст: на «Переведи фразу» придёт выдуманное продолжение задания.
• Пиньте тег целиком. qwen2.5:7b через полгода может указывать на другую сборку, а qwen2.5:7b-instruct-q4_K_M воспроизводит и вес, и поведение.
• qwen2.5 — только текст. Для картинок нужна qwen2.5vl, для кода — qwen2.5-coder:7b с лучшим FIM-автодополнением.

Что проверить на VPS до установки

Пять команд перед стартом. Чистая Ubuntu 24.04 LTS или Debian 13, под root.

systemd-detect-virt                      # kvm — хорошо, lxc/openvz — плохо
lscpu | grep -E "Model name|^CPU\(s\)"
grep -m1 -o avx2 /proc/cpuinfo           # пусто — будет вдвое медленнее
free -h
df -h /

• lxc или openvz в ответе. Контейнерный VPS показывает в free память всей ноды, а лимит режется cgroup: Ollama решает, что модель влезает, и ловит signal: killed на середине загрузки весов. Нужна KVM.
• Нет avx2. Ollama подберёт запасной CPU-рантайм, и скорость упадёт примерно вдвое.
• Мало RAM. Грубая формула: вес файла × 1,1 + KV-кэш под ваш контекст + 1,5 ГБ на систему. Полная разбивка — в таблице RAM для Ollama.
• Диск. Веса при системной установке лежат в /usr/share/ollama/.ollama/models — на корневом разделе, а не в домашнем каталоге. Под одну 7B закладывайте 15 ГБ.
• Swap. Проверьте ещё swapon --show: с подкачкой не влезшая в RAM модель не упадёт, а «заработает» на 0,1–0,3 токена в секунду, читая веса с диска — сервер жив, ответа нет.

Установка и первый запуск: команды и ожидаемый вывод

Единственный путь без возни с CUDA, Python и сборкой llama.cpp.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version          # ollama version is 0.33.1
systemctl is-enabled ollama && systemctl is-active ollama

Скрипт создаёт пользователя ollama, юнит /etc/systemd/system/ollama.service и демон на 127.0.0.1:11434; обе проверки должны ответить enabled и active. Если установка виснет на >>> Downloading Linux amd64 bundle — это про сеть, а не про Ollama; разбор в статье почему Ollama не запускается.

ollama pull qwen2.5:7b-instruct-q4_K_M
ollama run qwen2.5:7b-instruct-q4_K_M --verbose "Объясни в трёх предложениях, чем KV-кэш отличается от весов модели."

После ответа --verbose печатает статистику — главное средство диагностики:

total duration:       1m14.812s
prompt eval rate:     66.24 tokens/s
eval count:           398 token(s)
eval rate:            5.73 tokens/s

prompt eval rate — чтение запроса, упирается в процессор; eval rate — генерация, упирается в память, её вы и чувствуете в чате. Дальше проверьте, где модель считается:

$ ollama ps
NAME                          ID              SIZE      PROCESSOR    UNTIL
qwen2.5:7b-instruct-q4_K_M    845dbda0ea48    6.5 GB    100% CPU     4 minutes from now

SIZE больше веса файла: это веса плюс KV-кэш плюс буферы. Без видеокарты в PROCESSOR будет 100% CPU.

Контекст 32k, который надо включить руками

Самая частая жалоба после запуска — «модель забывает начало документа». Это не баг Qwen: модель объявляет 32 768 токенов, но Ollama открывает окно 4096 (в свежих сборках подбирает по объёму видеопамяти — на CPU-only VPS те же 4k). Лишнее молча отрезается с начала промпта; ошибки нет, есть строка в журнале:

journalctl -u ollama -f | grep -i truncat
# msg="truncating input prompt" limit=4096 prompt=7213 keep=4 new=4096

За окно платят памятью. У Qwen2.5-7B (28 слоёв, 4 KV-головы, размер головы 128, fp16) выходит около 56 КБ на токен, у 14B ровно втрое больше — 48 слоёв и 8 KV-голов.

Шесть гигабайт кэша сверх девяти гигабайт весов — поэтому 14B с полным контекстом не живёт на 16 ГБ. Задать окно можно глобально (OLLAMA_CONTEXT_LENGTH=16384 в drop-in юнита), на запрос (options.num_ctx в /api/chat) или зашить в модель. Ловушка: /v1/chat/completions не принимает num_ctx — в схеме OpenAI такого поля нет, и Ollama его игнорирует. Клиенты на этом пути (Open WebUI, LangChain, большинство SDK) получают окно только из переменной окружения или из самой модели:

FROM qwen2.5:7b-instruct-q4_K_M
PARAMETER num_ctx 16384
PARAMETER temperature 0.7
PARAMETER top_p 0.8
PARAMETER top_k 20
PARAMETER repeat_penalty 1.05
SYSTEM """Отвечай по-русски, кратко и по делу. Если данных не хватает — скажи об этом."""

Собирается командой ollama create qwen-ru -f Modelfile. Значения 0,7 / 0,8 / 20 / 1,05 — рекомендации авторов Qwen 2.5: с дефолтной температурой 0,8 и без repeat_penalty семёрка на русском чаще зацикливается на длинных ответах. И не ставьте num_ctx 65536: за 32k Qwen 2.5 работает только с масштабированием эмбеддингов по методу YaRN, которое Ollama не включает. Ошибки не будет — будет незаметная деградация качества.

Реальная скорость на CPU: цифры и что на них влияет

Генерация упирается не в частоту, а в пропускную способность памяти: чтобы выдать один токен, надо прочитать все веса. Отсюда оценка — токенов в секунду ≈ пропускная способность памяти ÷ размер весов: при реальных для виртуалки 25–30 ГБ/с и весах 4,7 ГБ выходит 5–6 токенов в секунду, и удвоение ядер этого не изменит.

Замеры на 8 vCPU / 16 ГБ RAM, Ubuntu 24.04, Q4_K_M, контекст 8k, один пользователь:

Разброс по поколениям процессоров — ±30%: это порядок величины, а не обещание. Что ещё влияет:

• Параллельные слоты. OLLAMA_NUM_PARALLEL больше единицы умножает KV-кэш на число слотов: четыре слота при 16k у 7B — 3,5 ГБ вместо 0,88 ГБ. Держите OLLAMA_NUM_PARALLEL=1 и OLLAMA_MAX_LOADED_MODELS=1.
• Выгрузка модели. Модель живёт в памяти 5 минут после запроса, дальше следующий ждёт перезагрузки весов: 3–5 секунд из дискового кэша, 20–40 секунд с холодного диска. Для редких обращений ставьте OLLAMA_KEEP_ALIVE=-1, но память будет занята постоянно.
• Квантование KV-кэша. OLLAMA_FLASH_ATTENTION=1 с OLLAMA_KV_CACHE_TYPE=q8_0 уменьшают кэш вдвое почти без потери качества, но скорости не добавляют.

Итог без прикрас: 7B на процессоре нормальна для фоновых задач (разбор писем, ночная суммаризация), терпима для одного человека в чате и непригодна для пяти одновременных. Остальные узкие места — в статье почему Ollama медленно генерирует токены.

Доступ по API: systemd, Nginx и защита

Пока Ollama слушает 127.0.0.1, к модели ходят только процессы этого же сервера. Настройки кладите в drop-in (sudo systemctl edit ollama): обновление перезаписывает ollama.service целиком.

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_CONTEXT_LENGTH=16384"
Environment="OLLAMA_KEEP_ALIVE=30m"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"

Дальше sudo systemctl daemon-reload && sudo systemctl restart ollama. OLLAMA_HOST намеренно остался локальным: у Ollama нет авторизации вообще, ни ключей, ни паролей. Открытый в интернет порт 11434 сканеры находят за часы, и дальше вашим процессором круглосуточно бесплатно пользуются посторонние. Наружу — только через прокси с паролем и TLS.

ufw allow 22/tcp
ufw allow 443/tcp
ufw deny 11434/tcp
ufw enable

location / {
    proxy_pass http://127.0.0.1:11434;
    proxy_set_header Host localhost:11434;
    proxy_http_version 1.1;
    proxy_buffering off;
    proxy_read_timeout 600s;
    auth_basic "llm";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

Три строки неочевидны. proxy_set_header Host localhost:11434; — Ollama проверяет заголовок Host и на чужое доменное имя отдаёт 403 Forbidden, это ошибка «локально работает, через домен нет». proxy_buffering off; обязателен для стриминга: иначе Nginx копит ответ и отдаёт целиком, и вместо печати по словам пользователь минуту смотрит в пустой экран. proxy_read_timeout 600s; спасает от 504 Gateway Time-out: ответ на 2000 токенов идёт вшестеро дольше дефолтных 60 секунд.

Проверка нативного API вместе с num_ctx:

curl -s http://127.0.0.1:11434/api/chat -d '{"model":"qwen2.5:7b-instruct-q4_K_M",
  "messages":[{"role":"user","content":"Что такое KV-кэш?"}],
  "options":{"num_ctx":16384},"stream":false}' | jq -r '.message.content'

В клиентах в поле «OpenAI API base URL» указывайте https://ваш-домен/v1, ключ любой непустой. Стыковка с веб-интерфейсом — в статье, почему Open WebUI не видит Ollama.

Какой сервер под Qwen 2.5 взять в MAATRIX

Без видеокарты Qwen 2.5 — задача про объём и пропускную способность памяти, а не про частоту процессора. Отсюда три границы.

Минимум: 4 vCPU, 8 ГБ RAM, 60 ГБ NVMe. Здесь живёт qwen2.5:3b с контекстом 8–16k: 12–16 токенов в секунду, хватает для разметки, извлечения полей и коротких ответов бота. Семёрка формально влезает, но только с окном 4k и без ничего рядом — ни Open WebUI, ни базы, ни второй модели.

Рабочий вариант: 8 vCPU, 16 ГБ RAM, 100–160 ГБ NVMe. Целевая связка для qwen2.5:7b-instruct-q4_K_M с контекстом 16k: 6,5 ГБ под модель с кэшем, 2–3 ГБ на Open WebUI с Postgres, запас на вторую модель на диске.

Комфорт: 8–16 vCPU, 32 ГБ RAM, от 200 ГБ NVMe. Порог для qwen2.5:14b, на которой русский становится по-настоящему хорошим: 9 ГБ весов и до 6 ГБ KV-кэша.

Скажу прямо: интерактивный чат на несколько человек процессорный VPS не вытянет — пять параллельных запросов к 7B дают полторы минуты ожидания у каждого, тут нужен GPU.

Ollama есть в каталоге приложений MAATRIX, и ставить его руками не нужно: при заказе он разворачивается автоматически на Ubuntu или Debian, юнит поднят и в автозапуске, доступы появляются в личном кабинете в разделе «Доступ». Вам остаётся ollama pull qwen2.5:7b-instruct-q4_K_M и настройка контекста из четвёртой секции.

Локация — Лондон, причина практическая. Из российских сетей пятигигабайтный слой из реестра Ollama регулярно рвётся на середине, а ollama run hf.co/... для GGUF-сборок с Hugging Face попросту не работает; с лондонской площадки оба источника идут на полной скорости канала. Пинг из Москвы 40–60 мс на фоне 5–7 токенов в секунду — шум, зато сервер в европейском правовом периметре, что важно, если через модель идут рабочие документы. Если данные обязаны оставаться в РФ по 152-ФЗ, берите российскую площадку.

Оплата — картой российского банка, по СБП, криптой или токеном MAAT: иностранная карта не нужна, хотя сервер стоит в Великобритании.

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