Сколько RAM нужно для DeepSeek

MAATRIX

Требования DeepSeek к RAM считают неправильно чаще, чем у любой другой модели. Под одним именем живут семь разных моделей, и шесть из них — вообще не DeepSeek по архитектуре. Вдобавок рассуждающая модель тратит контекст на размышление, и привычные 4096 токенов оборачиваются ответом, который не приходит.

Короткий ответ: сколько RAM требует DeepSeek

Формула та же, что для любой модели в Ollama:

RAM ≈ вес файла × 1,1 + KV-кэш под контекст + 1,5 ГБ на систему

Но подставляют в неё не те числа. Контекст нельзя ставить 4096 «чтобы сэкономить»: R1 думает вслух, и на размышление уходит от 800 до 4000 токенов до первого слова ответа. Расчёт ниже идёт при num_ctx = 16384 — минимальном окне, где рассуждающая модель не обрывается на полуслове.

Ориентиры при Q4_K_M, контексте 16k, одном пользователе:

• 4 ГБ — deepseek-r1:1.5b, годится для тестов и почти ни для чего больше;
• 8 ГБ — deepseek-r1:7b, нижняя рабочая планка;
• 12 ГБ — deepseek-r1:8b (да, ему нужно больше, чем 7b) или deepseek-coder-v2:16b;
• 16 ГБ — deepseek-r1:14b, самый разумный размер для CPU;
• 32 ГБ — deepseek-r1:32b с коротким контекстом;
• 64 ГБ — deepseek-r1:70b, влезет, но ответа ждать четверть часа;
• 512 ГБ — настоящий deepseek-r1:671b в Q4_K_M. Это не опечатка.

Главная развилка: `deepseek-r1:14b` — это не DeepSeek

В библиотеке Ollama под именем deepseek-r1 лежит одна настоящая модель и шесть дистиллятов — чужих моделей, дообученных на цепочках рассуждений R1. Память им считают по архитектуре донора, а не по «DeepSeek».

Модель сама сообщает, кто она.

curl -s http://127.0.0.1:11434/api/show -d '{"model":"deepseek-r1:14b"}' \
  | jq -r '.model_info["general.architecture"], .details.parameter_size'

qwen2
14.8B

Дистиллят наследует от донора число слоёв и KV-голов, то есть расход памяти на контекст. Отсюда странность, на которой промахиваются с тарифом: deepseek-r1:8b требует памяти заметно больше, чем deepseek-r1:7b, хотя весит на полгигабайта тяжелее. Донор у 7b — Qwen2.5 с четырьмя KV-головами на 28 слоёв, у 8b — Qwen3 с восемью на 36. Кэш растёт в 2,6 раза, на 16k это лишние полтора гигабайта — та самая ступенька, где 8 ГБ заканчиваются.

Таблица RAM по всем тегам DeepSeek

Вес — размер GGUF в Q4_K_M, то есть то, что даёт ollama pull без суффикса. Минимум посчитан при контексте 16 384 токенов, комфорт — при 32 768.

Три строки с комментарием. deepseek-coder-v2:16b — лучший размен для CPU: весит как 14B, а кэша просит в шесть раз меньше и считает вчетверо быстрее. deepseek-r1:70b от лишней памяти комфортнее не станет: 64 ГБ хватает и на 16k, и на 32k, упирается всё в скорость. У флагмана на 671B смехотворный KV-кэш — гигабайт на 128k там, где Llama-70B просит сорок.

Как требования меняются при другом квантовании — в разборе про выбор квантования для DeepSeek; сравнение с остальной библиотекой — в таблице RAM для Ollama.

MLA и MoE: почему у DeepSeek память считается не как у всех

MLA — multi-head latent attention. Обычная модель хранит в кэше ключи и значения для каждой головы внимания. DeepSeek сжимает их в один латентный вектор и кэширует только его:

KV(MLA) = слои × (kv_lora_rank + qk_rope_head_dim) × токены × 2 байта

Для R1 и V3 это 61 слой, kv_lora_rank = 512, qk_rope_head_dim = 64: 61 × (512 + 64) × 2 = 70 272 байта на токен — 1,1 ГБ на 16k и 9,2 ГБ на все 128 тысяч токенов. При классическом внимании со 128 головами вышло бы около 5 МБ на токен и 41 ГБ уже на 8k, разница в семьдесят раз. Сборки llama.cpp старше весны 2025 года MLA не умели и разворачивали кэш целиком: видите десятки гигабайт под KV — у вас старый бинарник, а не мало памяти.

MoE — mixture of experts. В R1 671 миллиард параметров, но на токен работают 8 экспертов из 256 плюс один общий: 37 миллиардов активных. У deepseek-coder-v2:16b (это DeepSeek-V2-Lite) — 64 эксперта, 6 активных, 2,4 миллиарда из 16. Ключевая деталь: в памяти лежат все веса, а читаются на токен только активные. RAM платится как за большую модель, скорость выходит как у маленькой.

Замер на 16 vCPU / 64 ГБ DDR5-4800, полоса памяти 52 ГБ/с (mbw -n 5 1024), Ubuntu 24.04, контекст 16k:

Почему генерация упирается именно в полосу памяти — в разборе медленной работы Ollama.

Налог на размышление: почему R1 требует контекст 16k и больше

R1 сначала выдаёт блок <think> — пятьсот, тысячу, иногда четыре тысячи токенов черновых рассуждений, и только потом ответ. Токены живут в том же окне и том же KV-кэше, а Ollama по умолчанию даёт 4096. Симптом нехватки — не ошибка, а тишина: модель думает, упирается в границу окна и замолкает, так и не начав отвечать.

curl -s http://127.0.0.1:11434/api/chat -d '{"model":"deepseek-r1:14b","stream":false,
  "messages":[{"role":"user","content":"Сколько будет 17 × 23? Покажи ход решения."}],
  "options":{"num_ctx":4096}}' | jq '{done_reason, eval_count}'

{ "done_reason": "length", "eval_count": 4077 }

"done_reason": "length" значит «кончилось окно», а не «модель закончила». При num_ctx: 16384 тот же запрос отдаёт "stop" и eval_count около 1200: примерно 1150 токенов ушло на размышление и 50 на сам ответ. Отсюда честная арифметика ожидания:

Три способа снизить налог:

• Задайте окно явно: Environment="OLLAMA_CONTEXT_LENGTH=16384" через systemctl edit ollama. Open WebUI перебивает переменную своим options.num_ctx из профиля модели — проверьте и там.
• Сжимайте кэш, а не окно. OLLAMA_FLASH_ATTENTION=1 вместе с OLLAMA_KV_CACHE_TYPE=q8_0 режет KV вдвое: у deepseek-r1:14b на 16k это 1,55 ГБ вместо 3,1. Без флеш-аттеншена вторая переменная молча игнорируется.
• Отключайте размышление, где оно не нужно. У свежих сборок Ollama есть флаг "think": false в теле запроса, поддержан он не всеми тегами.

Отдельно про deepseek-r1:1.5b: он склонен зацикливаться внутри <think> до конца окна. Ответа не будет при любом контексте — это ограничение дистиллята, памятью не лечится.

Что происходит при нехватке и что делать по шагам

Отказ на старте — удобный случай: Ollama посчитала требования заранее и назвала обе цифры.

Error: model requires more system memory (452.9 GiB) than is available (61.4 GiB)

Неизвестная архитектура — специфика DeepSeek: MoE требуют свежего рантайма. deepseek-coder-v2 не заработает на сборках старше 0.1.42, deepseek-r1:671b — младше 0.5.5:

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

Память тут ни при чём — проверьте ollama -v. Остальные симптомы — в частых ошибках DeepSeek на сервере.

Молчаливая деградация — худший вариант. Ollama открывает GGUF через mmap, поэтому 404-гигабайтная модель на 64-гигабайтной машине формально «запустится»: ядро подкачивает страницы весов с NVMe на каждый токен. Ошибки не будет — будет вот это:

iostat -x 2
Device   r/s      rkB/s      %util
nvme0n1  41250    1284000    99.8

Диск непрерывно читает больше гигабайта в секунду, генерация идёт со скоростью 0,08–0,15 токена в секунду: один ответ с размышлением занимает больше двух часов. Смотрите на available в free -h, а не на used — отображённые через mmap веса попадают в buff/cache и создают иллюзию свободной памяти.

Порядок действий, от дешёвого к дорогому:

1. Смените модель на архитектурно выгодную: задача про код — deepseek-coder-v2:16b вместо deepseek-r1:14b, та же память, вчетверо быстрее.
2. Включите OLLAMA_FLASH_ATTENTION=1 и OLLAMA_KV_CACHE_TYPE=q8_0 — минус половина кэша.
3. Ограничьте слоты: OLLAMA_NUM_PARALLEL=1 и OLLAMA_MAX_LOADED_MODELS=1, иначе кэш умножается на число слотов.
4. Берите размер меньше в Q4_K_M, а не тот же в Q3: deepseek-r1:7b в Q4_K_M рассуждает связнее, чем deepseek-r1:14b в Q3_K_S. И не режьте num_ctx ниже 16384 — с рассуждающей моделью это экономия, отбирающая результат.

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

Локальная модель никуда не ходит: веса лежат у вас, запросы не покидают машину. Ради этого DeepSeek и разворачивают сами — облачное API дёшево, но отправлять в него рабочие данные готовы не все. Локацию выбирают по пользователям и юрисдикции. Лондон (UK) — базовый вариант: 15–30 мс до Европы, 45–60 мс из Москвы, европейская юрисдикция для клиентских данных. Сетевая задержка тут незаметна — вы всё равно ждёте минуты, пока модель думает. Россия нужна ради 152-ФЗ и персональных данных россиян.

Минимум — 4 vCPU / 8 ГБ RAM / 80 ГБ NVMe. Здесь живёт deepseek-r1:7b с контекстом 16k: 5,2 + 0,92 + 1,5 = 7,6 ГБ, впритык и без соседей. Годится для фоновых задач по расписанию; для живого диалога медленно: две с половиной минуты до первого слова ответа — не чат. И учтите: deepseek-r1:8b сюда не влезет.

Комфорт — 8 vCPU / 16 ГБ RAM / 160 ГБ NVMe. Рабочая точка для DeepSeek на процессоре: помещается deepseek-r1:14b с контекстом 16k либо deepseek-coder-v2:16b с запасом, плюс Open WebUI в контейнере (ещё 0,7–1,5 ГБ). Три-четыре модели этого класса — уже 30–40 ГБ диска.

Дальше честно. Под deepseek-r1:32b нужно 16 vCPU / 48 ГБ: формально хватит и 32 ГБ, но только с контекстом 16k и без соседей, а два токена в секунду означают ночную пакетную обработку. deepseek-r1:70b влезает в 64 ГБ и выдаёт около токена в секунду — проверка гипотезы, а не инструмент; такие размеры решаются видеокартой, см. подбор GPU-сервера под инференс LLM. Полноценный deepseek-r1:671b на VPS не запускается никак: 404 ГБ весов требуют 512 ГБ RAM, а квантование в 1,58 бита ужимает модель до 131–158 ГБ, и тогда нужно 192 ГБ. Нужен флагман — берите его по API, а локально держите 14B для чувствительных данных.

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

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