Qwen 2.5 на сервере: частые ошибки и решения

MAATRIX

Сервер жив, ollama ps показывает загруженную модель, а в ответе торчит <|im_end|>, текст обрывается на середине фразы или в русский абзац влезают иероглифы. Почти все частые ошибки Qwen 2.5 — не поломка Ollama, а несовпадение между тем, что вы скачали, и тем, чего ждёт приложение. Ниже шесть типовых сценариев: по какой строке опознаётся каждый и чем чинится.

Сначала спросите модель о ней самой

Прежде чем лезть в journalctl, спросите саму модель — командой ollama show. Она печатает то, что реально записано в GGUF.

  Model
    architecture        qwen2
    context length      32768
    quantization        Q4_K_M

  Capabilities
    completion
    tools

  Parameters
    stop    "<|im_start|>"
    stop    "<|im_end|>"

Четыре строки закрывают четыре класса ошибок. architecture у Qwen 2.5 — qwen2; qwen2vl — это мультимодальная qwen2.5vl, на которой прошлогодний демон падает с unknown model architecture: 'qwen2vl', а qwen3 — третья линейка с режимом рассуждений. Capabilities без строки tools — вызов функций не заработает, как ни правьте клиент. Пустой блок Parameters — модель не остановится на конце реплики. context length 32768 — потолок весов, а не окно сервера: по умолчанию Ollama даёт 4096.

Второй инструмент — поле done_reason в ответе /api/chat: добавьте к запросу | jq '{done_reason, eval_count}'. stop — модель закончила сама, length — упёрлась в лимит токенов или в границу окна, load — ответ пустой, запрос лишь прогрел модель.

Не тот Qwen: `file does not exist`, base-веса и сборки с Hugging Face

Самые частые ошибки происходят ещё до запуска, на pull.

Опечатка в теге. Ollama отвечает лаконично и без подсказок:

Error: pull model manifest: file does not exist

В девяти случаях из десяти виноват регистр в суффиксе квантования: в библиотеке тег записан как q4_K_M, а не q4_k_m. Второй источник — выдуманные сочетания вроде qwen2.5:8b. Что есть на самом деле, покажет curl -s https://registry.ollama.ai/v2/library/qwen2.5/tags/list | jq -r '.tags[]'.

Базовые веса вместо инструктивных. В библиотеке Ollama базовый вариант помечен суффиксом -text, а не -base: qwen2.5:7b-text-q4_K_M. Инструкции он не выполняет, а продолжает текст — на просьбу перевести фразу вы получите «Задание 2. Переведите на русский следующие фразы…». Ошибки нет, просто веса не те.

GGUF с Hugging Face режется на части. Официальные репозитории вида Qwen/Qwen2.5-7B-Instruct-GGUF хранят веса как qwen2.5-7b-instruct-q4_k_m-00001-of-00002.gguf, а Ollama такие не тянет:

Error: pull model manifest: 400: The specified repository contains sharded GGUF.
Ollama does not support this yet.

Выходов два: сборка с цельным файлом (у bartowski/Qwen2.5-7B-Instruct-GGUF квантования до Q6 лежат одним куском) либо склейка через llama-gguf-split --merge. Ей нужно место под обе копии сразу: для 7B около 10 ГБ, для 32B — под 45 ГБ, и no space left on device посреди merge на диске в 60 ГБ — обычное дело.

Служебные теги в ответе и диалог, который модель ведёт сама с собой

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

Столица Франции — Париж.<|im_end|>
<|im_start|>user
А Германии?<|im_end|>
<|im_start|>assistant
Берлин.

Причина в разметке. Qwen 2.5 обучена на ChatML: реплика обёрнута в <|im_start|>роль … <|im_end|>, и конец ответа помечен токеном <|im_end|> (id 151645), а не привычным <|endoftext|> (151643). Если в GGUF нет шаблона и стоп-параметров — обычное дело для сборок, залитых через ollama create из голого файла, — Ollama не знает, где резать, и печатает теги как текст.

Шаблон не пишите руками, забирайте у библиотечной модели: ollama show --template qwen2.5:7b-instruct-q4_K_M > qwen.tmpl. Дальше он идёт в ваш Modelfile вместе со стоп-токенами:

FROM ./qwen2.5-7b.gguf
TEMPLATE """<содержимое qwen.tmpl>"""
PARAMETER stop "<|im_start|>"
PARAMETER stop "<|im_end|>"
PARAMETER stop "<|endoftext|>"

Обратная ошибка ищется дольше: пустые ответы. Добавили в борьбе с тегами PARAMETER stop "assistant" — генерация обрывается на первом символе, а done_reason приходит как stop. Стоп-строки должны совпадать только со служебными токенами.

Заодно про язык: встроенный системный промпт Qwen 2.5 английский — «You are Qwen, created by Alibaba Cloud», и клиенты, которые не шлют system, оставляют его в силе. Свой SYSTEM на русском решает это лучше просьб в чате.

Ответ обрывается на середине: `done_reason: length` и таймауты

Три причины с одинаковым проявлением.

Клиент задал лимит. OpenAI-совместимый слой превращает max_tokens в num_predict. У Ollama по умолчанию -1, но библиотеки подставляют своё — отсюда обрывы ровно на 512, 1024 или 2048 токенах: eval_count в ответе равен подозрительному круглому числу.

Промпт съел окно. Промпт и ответ делят один буфер: при num_ctx 4096 и документе на 3800 токенов на ответ остаётся 296. Через /v1/chat/completions окно не расширить: в схеме OpenAI такого поля нет, только OLLAMA_CONTEXT_LENGTH в drop-in юнита.

Потолок самой модели. Qwen 2.5 принимает 32 768 токенов на входе, но рассчитана максимум на 8192 токена генерации за раз — дальше идут повторы и потеря структуры. Длинные тексты собирайте по главам.

Отдельная история — обрыв соединения, который выглядит обрывом ответа. На CPU скорость чтения промпта у 7B около 66 токенов в секунду: документ на 30 000 токенов считается почти восемь минут, и всё это время клиент не получает ни байта.

В журнале Ollama остаётся msg="context canceled": сервер честно считал, ушёл клиент. Лечится proxy_read_timeout 600s; и proxy_buffering off; в Nginx плюс поднятым таймаутом у клиента. Важная деталь: чтение промпта, в отличие от генерации, распараллеливается по ядрам — лишние vCPU ускоряют первый токен, но не скорость печати. Остальные узкие места — почему Ollama медленно генерирует токены.

Петля из повторов и иероглифы в русском тексте

Две обидные жалобы: «пишет одно и то же по кругу» и «вставляет китайские символы в русский абзац». Обе лечатся сэмплированием и выбором сборки.

Ollama по умолчанию берёт temperature 0.8, top_p 0.9, top_k 40, repeat_penalty 1.1, repeat_last_n 64. Авторы Qwen 2.5 рекомендуют другое, и разница на русском видна сразу:

PARAMETER temperature 0.7
PARAMETER top_p 0.8
PARAMETER top_k 20
PARAMETER repeat_penalty 1.05
PARAMETER repeat_last_n 256

repeat_last_n 64 — окно всего в 64 токена: на ответе в тысячу токенов модель уже не помнит абзац с той же формулировкой выше и уходит в петлю «и так далее, и так далее». Расширить окно до 256 помогает больше, чем поднять штраф. А repeat_penalty выше 1.1 вреден: он падает и на служебные токены, и модель калечит падежи, лишь бы не повторить слово, а в коде — ломает отступы.

Иероглифы. Словарь Qwen 2.5 — 151 936 токенов, и заметная их доля китайская. Когда распределение вероятностей размазано, китайский токен выигрывает у русского, и в тексте появляется 的 посреди фразы. Виноваты, по убыванию влияния: квантование (на Q3_K_M и ниже — регулярно, на Q4_K_M — редко, на Q6 исчезает), размер модели (у 0.5b и 1.5b проблема неустранима) и высокая температура при пустом системном сообщении.

Проверяйте числом: прогоните длинный ответ с "seed": 42 и посчитайте иероглифы — jq -r .message.content | grep -oP '[\x{4e00}-\x{9fff}]' | wc -l. Ноль — настройки рабочие. Устойчиво не ноль — поднимайте квантование или размер модели, тюнингом это не лечится.

Инструменты не вызываются, а автодополнение отвечает прозой

Tool calling. На модель без поддержки инструментов Ollama отвечает явной ошибкой does not support tools (status code: 400). Хуже, когда ошибки нет: в message.content приезжает текст <tool_call>{"name": "get_weather", "arguments": {"city": "London"}}</tool_call>, а массив message.tool_calls пуст. Формат модель помнит — Qwen 2.5 использует Hermes-разметку, — но шаблон в вашем GGUF не содержит ветки для инструментов. Лечится как в третьем разделе — моделью из библиотеки или переносом шаблона. Отлаживать клиент до этого бессмысленно: ollama show qwen2.5:7b-instruct-q4_K_M | grep -A3 Capabilities.

Честное ограничение: инструменты у Qwen 2.5 надёжно работают с 7B — 3B и мельче путают имена аргументов и выдумывают несуществующие функции.

FIM и автодополнение. Классическая ошибка: в Continue прописывают qwen2.5-coder:7b, и вместо кода подсказка выдаёт «Конечно! Вот дополненный код:» с блоком в тройных кавычках. Заполнение середины умеет только базовая версия — у неё есть токены <|fim_prefix|>, <|fim_suffix|>, <|fim_middle|>, а instruct обучена вести диалог. Нужен тег -base:

ollama pull qwen2.5-coder:1.5b-base
curl -s http://127.0.0.1:11434/api/generate -d '{"model":"qwen2.5-coder:1.5b-base",
 "prompt":"def fib(n):\n    ","suffix":"\n    return result\n",
 "options":{"temperature":0,"num_predict":64},"stream":false}' | jq -r .response

Поле suffix — это и есть FIM, разметку Ollama соберёт сама. Ответ должен быть кодом без пояснений; пришла проза — вы всё ещё на instruct. Держать обе версии накладно: OLLAMA_MAX_LOADED_MODELS=1 выгружает одну ради другой.

Какая конфигурация нужна под Qwen 2.5 и где её взять

Часть разобранных ошибок — про конфиги, часть упирается в железо: signal: killed при загрузке весов, no space left on device при склейке GGUF, 504 на длинном промпте.

На восьми гигабайтах семёрка формально влезает — 4,7 ГБ весов, 0,22 ГБ кэша, полтора гигабайта системы, — но любой Docker рядом заканчивается OOM. Восемь ядер нужны не для скорости печати, а для чтения длинных промптов, то есть против 504. На 32 ГБ русский у 14B становится по-настоящему хорошим, а иероглифы пропадают как класс: 9 ГБ весов и до 6 ГБ кэша при полном окне. Арифметика памяти — в таблице RAM для Ollama.

Границу назову прямо: интерактивный чат на пять человек процессорный VPS не вытянет — 5–7 токенов в секунду делятся между всеми, тут нужен GPU-сервер.

Ollama есть в каталоге приложений MAATRIX, и ставить её руками не нужно: при заказе сервера она разворачивается автоматически на Ubuntu или Debian, юнит поднят и включён в автозапуск, версия свежая — та, что понимает qwen2vl и разбирает <tool_call>. Доступы появляются в личном кабинете, раздел «Доступ»; останется ollama pull и Modelfile из третьего раздела. Путь с нуля — как запустить Qwen 2.5 на VPS.

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

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

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