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

MAATRIX

DeepSeek поднимается на сервере за час, а потом неделю уходит на выяснение, почему модель отвечает иероглифами, обрывает ответ на середине размышления и требует 404 гигабайта диска. Почти все эти DeepSeek ошибки — не баги, а следствие двух особенностей: под именем deepseek-r1 лежит семь разных моделей, и рассуждающая модель расходует контекст не так, как обычная. Разберём по слоям, с текстами ошибок и командами проверки.

Сначала проверьте, какой DeepSeek у вас на самом деле

Самая частая жалоба звучит не как ошибка: «локальный DeepSeek глупее, чем на deepseek.com». Дело не в глюке и не в квантовании. Команда ollama run deepseek-r1 тянет тег latest, а под ним не DeepSeek-R1, а дистилляция: Qwen или Llama, дообученная на цепочках рассуждений настоящего R1.

Проверяется командой ollama show deepseek-r1:8b — поле architecture не врёт. Видите qwen3 или llama — у вас дистилляция. Инструмент рабочий, но требовать от 8-миллиардной модели уровня 671-миллиардной бессмысленно. То же с кодом: deepseek-coder-v2:16b — Lite-версия, полная :236b весит 133 ГБ. Отдельная ловушка: старые гайды описывают deepseek-r1:8b как дистилляцию Llama 3.1, но после обновления 0528 это Qwen3 — с другим шаблоном и другими требованиями к версии Ollama. Отсюда и растут ошибки следующей секции.

Модель не грузится: архитектура, версия Ollama и 404 гигабайта

Сервис живой, ollama list показывает модель, а запуск падает:

Error: llama runner process has terminated: error loading model:
llama_model_load: error loading model architecture: unknown model architecture: 'qwen3'

Это не про DeepSeek — это про версию Ollama. Дистилляции на Qwen2.5 и Llama работают с 0.5.7, а пересобранный 8B на базе Qwen3 требует не ниже 0.9.0: на ветках 0.6–0.8 он честно скачается и не запустится. Вариант unknown model architecture: 'deepseek2' означает древнюю сборку — так падают попытки поднять V2, V3 или настоящий R1. Лечится обновлением через curl -fsSL https://ollama.com/install.sh | sh и systemctl restart ollama, модели остаются на месте.

Ещё два сценария той же группы:

• done_getting_tensors: wrong number of tensors; expected 1147, got 1025. Импорт стороннего GGUF по частям: файлы вида model-00001-of-00004.gguf перед ollama create объединяют через llama-gguf-split --merge, первый кусок сам по себе бесполезен.
• no space left on device на 671b. Честно: deepseek-r1:671b в Q4_K_M — 404 ГБ на диске и более 500 ГБ RAM. Ни один VPS такое не потянет, своп не спасает. Потолок арендованной машины — 32B, в редких случаях 70B.

«requires more system memory»: почему MoE считается не так, как кажется

Когда памяти не хватает, Ollama обычно предупреждает заранее — Error: model requires more system memory (21.4 GiB) than is available (15.6 GiB). Хуже, когда предупреждения нет и процесс исчезает с Error: llama runner process has terminated: signal: killed. Это OOM-killer ядра, и ищут его не в логе Ollama, а в системном журнале: journalctl -k | grep -i "killed process" вернёт Out of memory: Killed process 1183 (ollama_llama_se) total-vm:24118512kB.

Специфика DeepSeek в том, что часть моделей — MoE, «смесь экспертов», и привычная арифметика ломается. У deepseek-coder-v2:16b 15,7 млрд параметров, но на каждый токен работают только 2,4 млрд: память нужна под все веса, а скорость выходит как у маленькой модели. Отсюда парадокс: 16B на CPU обгоняет 8B-дистилляцию R1 в полтора раза, занимая вдвое больше RAM.

Замеры на 8 vCPU (EPYC, DDR4-3200, без видеокарты), Q4_K_M:

Своп не выручает: модель запустится, но при выгрузке весов на диск скорость падает до 0,2–0,4 токена в секунду, а рассуждающей модели нужны тысячи токенов до первого полезного слова. Расклад покажет ollama ps: колонка PROCESSOR выдаст 100% CPU либо 43%/57% CPU/GPU.

Ответ обрывается на середине: контекст 4096 против рассуждения на 3000 токенов

Симптом узнаваемый: модель начинает думать, а ответ кончается на полуслове — закрывающего тега нет вовсе. В логе при этом лежит:

level=WARN source=runner.go:131 msg="truncating input prompt" limit=4096 prompt=5321 keep=5 new=4096

Ollama по умолчанию даёт модели 4096 токенов контекста независимо от того, что DeepSeek-R1 обучена на 128k. Обычной модели хватает, рассуждающей — нет: на бытовой вопрос R1 выдаёт 800–3000 токенов размышления, на математике уходит за 8–10 тысяч. Окно переполняется, начало диалога выбрасывается, генерация упирается в потолок.

Поднимать контекст правильнее своей сборкой модели, а не правкой каждого запроса:

FROM deepseek-r1:14b
PARAMETER num_ctx 16384
PARAMETER temperature 0.6
PARAMETER top_p 0.95

Собирается как ollama create deepseek-r1-14b-ctx16k -f Modelfile. Через API то же делает поле options, а глобальный дефолт задаёт OLLAMA_CONTEXT_LENGTH=16384 в systemctl edit ollama. Отдельная засада — фронтенды: Open WebUI и большинство клиентов шлют свой num_ctx в каждом запросе и молча перебивают серверные настройки.

Обратная крайность тоже наказуема. Поставить num_ctx 131072 «с запасом» нельзя: Ollama выделяет KV-кэш сразу и целиком. У 8B-дистилляции кэш стоит около 144 КБ на токен в f16 — 32k контекста добавляют 4,5 ГБ поверх весов, а 128k потребуют около 18 ГБ только под кэш. Вдвое уменьшают две строки в [Service]: Environment="OLLAMA_FLASH_ATTENTION=1" и Environment="OLLAMA_KV_CACHE_TYPE=q8_0".

И честная арифметика времени: при 10 tok/s размышление на 2500 токенов — больше четырёх минут до первой строки ответа. Рассуждающая модель на CPU хороша в фоне и плоха в живом чате.

Блок `<think>` в ответе, пустые рассуждения и внезапный китайский

DeepSeek-R1 выводит цепочку рассуждений в тегах <think>...</think>, и это ломает всё, что ждёт чистый текст. С Ollama 0.9.0 рассуждение отделено от ответа: в /api/chat приходит поле message.thinking рядом с message.content, и содержимое тегов в content больше не попадает.

curl -s http://127.0.0.1:11434/api/chat -d '{"model":"deepseek-r1:8b","think":true,
  "stream":false,"messages":[{"role":"user","content":"17% от 4820"}]}' \
  | jq '{think: .message.thinking, answer: .message.content}'

На старых версиях всё лежало одной строкой в content — отсюда битые парсеры. Запрос с "format":"json" к рассуждающей модели закономерно даёт мусор: она сначала обязана подумать словами, так что для извлечения структуры берите нерассуждающую модель. И не питайте иллюзий: убрать рассуждение из вывода не значит его отключить. R1 обучен думать всегда; переключаемый режим есть только у гибридных версий вроде DeepSeek-V3.1.

Две родственные странности:

• Пустое рассуждение. Приходит <think>\n\n</think> и сразу текст: модель проскочила размышление, качество падает. Известное поведение R1, разработчики рекомендуют принудительно начинать генерацию с <think>\n. Правится шаблоном — сверьтесь с ollama show deepseek-r1:8b --template, чаще всего его ломают чужие гайды.
• Китайский посреди русского текста. R1 оптимизирован под английский и китайский и на других языках переключается — иногда в середине рассуждения, иногда в ответе. Лечится не настройками, а промптом: явное «Отвечай только по-русски» в пользовательском сообщении работает, в системном — хуже.

Зацикливание, температура, системный промпт и ошибки с tools

Модель уходит в бесконечное «Wait, but... Actually...» и не останавливается до лимита токенов. Виновата почти всегда температура: дефолт Ollama — temperature 0.8, а многие ставят 0 ради детерминизма и получают вырожденное повторение. DeepSeek для R1 рекомендует 0,5–0,7 с оптимумом 0,6 и top_p 0.95; что применилось, покажет ollama show deepseek-r1:14b --parameters.

Штрафы за повтор трогать не стоит: repeat_penalty выше дефолтных 1.1 ломает именно рассуждающие модели — цепочка размышлений естественно содержит повторы формулировок, и штраф выталкивает модель с правильного хода мысли. Осталось зацикливание после починки температуры — почти наверняка обрезан контекст. Системный промпт для R1 разработчики советуют не использовать вовсе, складывая инструкции в пользовательское сообщение: роль в стиле «ты опытный аналитик» сбивает формат рассуждения и повышает шанс пустого <think>.

Отдельная история — вызов инструментов. Дистилляции R1 не обучены function calling, и передача tools даёт Error: registry.ollama.ai/library/deepseek-r1:8b does not support tools. У своего GGUF со сломанным шаблоном ошибка иная, а смысл тот же: template: :1:11: executing "" at <.Tools>: can't evaluate field Tools. Переписывать шаблон — путь к молчаливо неверным вызовам: под агентов берите модель, которая умеет функции.

У облачного API DeepSeek ошибки другие: HTTP 402 {"error":{"message":"Insufficient Balance"}} — это пустой баланс, а не ключ, а deepseek-reasoner игнорирует temperature и отвечает 400 на возврат поля reasoning_content в истории сообщений.

Какой сервер под DeepSeek брать в MAATRIX

Половина разобранного выше — последствия неподходящей машины. Требований два: KVM, а не контейнерная виртуализация (на OpenVZ и LXC загрузка весов через mmap регулярно валится) и AVX2 — grep -o avx2 /proc/cpuinfo | head -1. Площадки MAATRIX — KVM на современных EPYC и Xeon, оба пункта закрыты.

Честно про минимум: 8 ГБ хватает для 8B-дистилляции, но именно там вы упрётесь в контекст 4096 и получите все обрывы из четвёртой секции. Рассуждающей модели нужен запас под KV-кэш, а не только под веса, — тот случай, когда лишние 16 ГБ меняют не удобство, а работоспособность. И прямо: живой чат на CPU не выйдет ни на одной строке таблицы, для 30–60 tok/s нужна видеокарта на 16–24 ГБ VRAM.

Локация — Лондон. Причина практическая: registry.ollama.ai отдаёт двадцатигигабайтные слои на полной скорости канала, без замираний на 0 B/s, — ollama pull deepseek-r1:32b занимает минуты, а не вечер с перезапусками. Пинг до Европы 15–30 мс, из Москвы 45–60 мс, что на фоне четырёхминутного рассуждения не значит ничего. Европейская юрисдикция важна, если через модель идут клиентские документы: локальный DeepSeek, в отличие от облачного API, данные никуда не отправляет. Обязаны держать персданные россиян в РФ по 152-ФЗ — берите площадку в России, требования к железу те же.

Ollama из каталога apps.maatrix.io ставится на сервер автоматически при заказе: вставлять команды не нужно, автоустановка работает на Ubuntu и Debian, доступы появляются в личном кабинете, раздел «Доступ». Дальше остаётся ollama pull deepseek-r1:14b и один Modelfile с вашим num_ctx. Оплата — картами российских банков, по СБП, криптой или токеном MAAT; зарубежная карта для Лондона не нужна. Смежное чтение: таблица RAM для Ollama, общие ошибки Ollama и почему Ollama медленно генерирует токены.

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