Из 284 миллиардов параметров модели DeepSeek V4 Flash на каждый токен активируются 13 миллиардов. Именно эта цифра определяет всю дискуссию об аппаратном обеспечении. Плотная модель такого же размера была бы недостижима для чего-либо, кроме кластера графических процессоров, а эта — нет.
В этом руководстве рассказывается, что необходимо для локального запуска DeepSeek V4 Flash: какой уровень квантизации GGUF выбрать, какой минимальный объём реальной памяти требуется (измеренный, а не расчётный), и какое количество токенов в секунду вы получите после загрузки. Все приведенные ниже результаты были получены в ходе тестирования с использованием llama.cpp версии b10273 на Ubuntu 24.04 в августе 2026 года на процессоре Xeon с 16 потоками и 8 физическими ядрами, 123 GiB доступной оперативной памяти и без использования графических процессоров.
Почему модель объёмом 284B помещается в 128 ГБ оперативной памяти
Каждый эксперт должен находиться в памяти, но только часть из них выполняет какую-либо работу над конкретным токеном. Микс экспертов направляет каждый токен через небольшое подмножество сети, поэтому эта модель держит в памяти 284 миллиарда параметров, при этом умножая примерно 13 миллиардов из них на каждый токен.
Отсюда и вытекают все проблемы с аппаратным обеспечением. Объем памяти пропорционален общему количеству параметров, поскольку в любой момент может быть выбран любой эксперт, и все они должны быть доступны для загрузки. Пропускная способность памяти и вычислительная мощность пропорциональны числу активных числом параметров, которое в данном случае составляет около 4,6 % от общего числа.
Таким образом, ограничивающим фактором является объем имеющейся памяти, а не её скорость. Это противоречит обычным рекомендациям. Машина с большим пулом обычной памяти DDR5 может вместить эту модель, в то время как быстрая видеокарта на 24 ГБ не сможет с ней справиться. Если соотношение между объединенной системной памятью и выделенной VRAM является новой областью, то разбивка по принципу «объединенная память против VRAM» охватывает эту проблему, а расчет размера VRAM применяет ту же логику к более мелким моделям.
Именно этот подход, при котором на первом месте стоит емкость, исключил возможность локального запуска Kimi K3 на машинах данного класса. Обе модели относятся к разряду разреженных MoE-моделей, но для той из них требуется как минимум 610 ГБ совокупного объема ОЗУ и VRAM, что является задачей для дата-центра, а не для настольного компьютера.
Два организационных момента перед установкой. Релиз 0731 на Hugging Face является официальным и заменяет собой более раннюю предварительную версию, поэтому используйте именно его, а не обычный репозиторий. Лицензия — MIT, поэтому разрешены локальное использование, тонкая настройка и коммерческое развертывание.
Выберите уровень квантизации GGUF
Unsloth публикует тринадцать уровней, от 1-битной сжатой версии объемом менее 83 ГБ до 8-битной сборки объемом 162 ГБ. То, что вы сможете запустить, зависит от суммарного объема ОЗУ и видеопамяти, поскольку llama.cpp распределит модель между ними. Вот те варианты, из которых стоит выбирать.
| Уровень квантования | Размер | Биты | Практическая цель |
|---|---|---|---|
| UD-IQ1_S | 82,5 ГБ | 1 | Машины с 96 ГБ |
| UD-IQ2_M | 90,9 ГБ | 2 | 128 ГБ с запасом для длинного контекста |
| UD-Q2_K_XL | 96,8 ГБ | 2 | 128 ГБ |
| UD-IQ3_XXS | 104 ГБ | 3 | 128 ГБ, лучший выбор |
| UD-IQ3_S | 116 ГБ | 3 | 128 ГБ — мало, 192 ГБ — в samom деле |
| UD-IQ4_XS | 137 ГБ | 4 | 192 ГБ |
| UD-Q4_K_XL | 155 ГБ | 4 | 192 ГБ, практически без потерь |
| UD-Q8_K_XL | 162 ГБ | 8 | 192 ГБ, без потерь |
В документации Unsloth по этой модели для достижения наилучших результатов рекомендуется использовать UD-IQ3_XXS, а минимальный объем оперативной памяти установлен на уровне 110 ГБ. Именно этот уровень используется для всех значений в данном руководстве. Четыре его фрагмента занимали на диске в общей сложности 104 207 848 032 байта, что, по данным llama.cpp, после загрузки соответствует 97,05 ГиБ; разница между этими двумя цифрами объясняется различием в единицах измерения (ГБ против ГиБ), а не тем, что какие-то данные были упущены.
Размер модели — это минимальный порог, а не обязательное требование. К нему добавляется KV-кеш для контекста, а окно контекста в данном случае может содержать до 1 048 576 токенов, если подать столько данных. На машине с 128 ГБ памяти 2-битовый уровень обеспечивает значительно больше полезного контекста, чем 3-битовый, поэтому выбирайте степень квантования исходя из фактически необходимой длины контекста, а не из максимальной, которая технически может загрузиться.
Запустите DeepSeek V4 Flash локально с помощью llama.cpp
Необходимо выполнить три действия: скомпилировать llama.cpp, загрузить фрагменты и установить связь между ними. Начните с инструментария и создания виртуальной среды (virtualenv) для клиента загрузки Hugging Face.
sudo apt update
sudo apt install -y build-essential cmake git curl libssl-dev time python3-pip python3-venvНе включайте клиент загрузки в системный Python:
python3 -m venv ~/hfvenv
~/hfvenv/bin/pip install "huggingface_hub[hf_transfer]"Укажите квант и путь назначения один раз, так как далее на них будут неоднократно ссылаться:
export QUANT=UD-IQ3_XXS
export MODEL_DIR=$HOME/models/v4flashСначала запустите загрузку, так как загрузка 104 ГБ займет больше времени, чем компиляция llama.cpp:
HF_HUB_ENABLE_HF_TRANSFER=1 ~/hfvenv/bin/hf download \
unsloth/DeepSeek-V4-Flash-0731-GGUF --include "${QUANT}/*" \
--local-dir "${MODEL_DIR}"Пока она выполняется, соберите llama.cpp во второй оболочке. Повторно выполните там две команды export, так как все последующие команды будут использовать их. Поддержка этой архитектуры входит в основную ветку, поэтому свежий клон не требует патчей:
git clone https://github.com/ggml-org/llama.cpp ~/llama.cpp
cd ~/llama.cpp
cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_NATIVE=ON
cmake --build build --config Release -j"$(nproc)"GGML_NATIVE=ON уже является значением по умолчанию при компиляции на машине, на которой будет запускаться модель, поэтому приведённый выше флаг служит скорее напоминанием, чем изменением. Важно не отключать его: компиляция выполняется с учетом набора инструкций локального процессора, и на хостах Sapphire Rapids или Zen 4 это означает разницу между использованием широких векторных блоков и их игнорированием. Старые руководства по сборке также передают -DLLAMA_CURL=OFF . Пропустите его. В файле llama.cpp libcurl был заменён на встроенный HTTP-клиент, и этот параметр теперь устарел и игнорируется без предупреждения, поэтому он ничего не отключает. Более подробное описание того же процесса сборки вы найдёте в руководстве по настройке llama.cpp.
Важны два бинарных файла. Прежде чем продолжить, убедитесь, что оба были успешно скомпилированы:
ls build/bin | grep -E '^llama-(cli|bench)$'Оба имени должны вывестись на экран, по одному в строке:
llama-bench
llama-cliТеперь загрузите их. Укажите первый шард, и llama.cpp сам найдёт остальные три. Значения выборки соответствуют тем, что указаны в документации к модели Unsloth, и они шире, чем те, которые вы бы использовали для плотной модели чата. Одно важное уточнение, о котором стоит знать, прежде чем подключать это к чему-либо: Unsloth рекомендует --top-p 0.95 для агентных рабочих нагрузок и 1,0 для всего остального.
~/llama.cpp/build/bin/llama-cli \
--model "${MODEL_DIR}/${QUANT}/DeepSeek-V4-Flash-0731-${QUANT}-00001-of-00004.gguf" \
--threads 16 \
--temp 1.0 --top-p 1.0 --min-p 0.0 \
-st \
-p "In exactly three sentences, explain what a mixture-of-experts model is."Именно этот -st флаг многие упускают из виду. Без режима «single turn» llama-cli переходит в интерактивный режим, а запуск скрипта без подключенного терминала зацикливается на конце файла вместо того, чтобы завершиться. За две минуты, пока мы это не заметили, он создал лог-файл объёмом 388 МБ.
Заставка при запуске подтверждает, какая сборка и какой квант фактически загружены:
build : b10273-a6aa6f545
model : /home/ubuntu/models/v4flash/UD-IQ3_XXS/DeepSeek-V4-Flash-0731-UD-IQ3_XXS-00001-of-00004.gguf
ftype : IQ3_XXS - 3.0625 bpw
modalities : textЗатем открывается окно генерации с блоком обоснования, прежде чем появится текст ответа. Наш начинался дословно так:
[Start thinking]
1. **Understand the User's Request**: The user wants a three-sentence explanation of what a mixture-of-experts (MoE) model is and why only *some* parameters activate per token.Учитывайте это. Каждый ответ тратит токены на повторение запроса перед тем, как дать ответ, и при скорости в однозначное число токенов в секунду эти токены превращаются в минуты реального времени, в течение которых читатель ничего не видит.
У него есть переключатель выключения, и на медленной машине это самый мощный рычаг, который у вас есть. --reasoning off полностью исключает блок размышлений. Чтобы сохранить процесс рассуждений и вместо этого настроить его, передайте --chat-template-kwargs '{"reasoning_effort":"max"}', который также принимает high. По умолчанию установлено значение «High», поэтому при запуске без настройки программа долго размышляет, прежде чем выдать ответ. В старых руководствах используется enable_thinking через тот же механизм kwargs, а в llama.cpp теперь выдаётся предупреждение о том, что этот вариант устарел, и вместо него рекомендуется использовать --reasoning .
Производительность на машине с 128 ГБ оперативной памяти, использующей только ЦП
llama-bench отдельно отчитывается об обработке подсказок и генерации текста, без накладных расходов, связанных с сессией чата. Предварительное заполнение и декодирование — это разные рабочие нагрузки на данной модели, и единое усреднённое значение скрывает самую интересную часть.
/usr/bin/time -v ~/llama.cpp/build/bin/llama-bench \
-m "${MODEL_DIR}/${QUANT}/DeepSeek-V4-Flash-0731-${QUANT}-00001-of-00004.gguf" \
-p 512 -n 128 -t 16 -r 1Одно повторение, поэтому в столбце «дисперсия» указано значение «ноль». Вот что получилось:
| model | size | params | backend | threads | test | t/s |
| --------------------------------- | ---------: | ---------: | ------- | ------: | ----: | -----------: |
| deepseek4 ?B IQ3_XXS - 3.0625 bpw | 97.05 GiB | 284.33 B | CPU | 16 | pp512 | 12.33 ± 0.00 |
| deepseek4 ?B IQ3_XXS - 3.0625 bpw | 97.05 GiB | 284.33 B | CPU | 16 | tg128 | 5.61 ± 0.00 |
build: a6aa6f545 (10273)
Maximum resident set size (kbytes): 109503840Последняя строка взята из time , а не из llama.cpp, и именно её следует прочитать дважды. Пиковый размер резидентного набора составил 109 503 840 единиц того, что GNU time обозначает как kbytes, но на самом деле указывает в кибибайтах, поэтому истинный пик составляет 104,4 GiB. В пересчёте на десятичные гигабайты, используемые в модельных картах, это 112,1 ГБ при 123 GiB доступной оперативной памяти. Осталось около 18,6 GiB свободного места.
Именно эти измеренные данные служат основанием для того, чтобы рассматривать 128 ГБ как нижний порог для этого уровня, а не как число, заимствованное из спецификации, и обратите внимание, с какой стороны от ориентира Unsloth в 110 ГБ он находится. Реальный пик оказался выше этого значения, а не ниже. Рассматривайте 110 ГБ как точку, в которой веса укладываются, а 128 ГБ — как точку, в которой у машины ещё есть запас для их обработки.
Свопинг не производился. Во время генерации процесс демонстрировал нулевое использование свопа, нулевое количество чтений блоков и 93% загрузки пользовательского ЦП при 16–18 запущенных потоках, поэтому модель находилась в страничном кэше, а производительность системы ограничивалась исключительно вычислительными ресурсами. Модель с 284B параметрами действительно генерирует текст на ЦП без каких-либо ускорителей.
Обработка подсказок — это реальное «узкое место»
Скорость генерации 5,61 токена в секунду — это медленно, но приемлемо для пакетных заданий, которые оставляют работать. Скорость обработки подсказок 12,33 токена в секунду — вот что на самом деле исключает эту конфигурацию для интерактивной работы.
Проведите расчёты на примере реалистичного запроса агента. Десять тысяч токенов системного запроса, определений инструментов и вставленного исходного кода при скорости 12,33 токена в секунду — это 811 секунд, то есть примерно 13,5 минут до появления первого токена вывода. Если направить модель на кодовую базу объёмом 100 000 токенов, вам придётся ждать более двух часов, пока модель закончит чтение.
Тот же объем памяти в 128 ГБ с ускорителем, способным к ней обращаться, ведет себя совершенно иначе. Опубликованные данные о запуске DGX Spark на llama.cpp с использованием GB10 с 128 ГБ унифицированной памяти показывает производительность обработки подсказок от 459 до 462 токенов в секунду и около 19,1 токена в секунду при генерации одного потока на 2-битовом уровне UD-IQ2_M.
| Показатели | Только ЦП, 123 ГиБ ОЗУ | DGX Spark GB10, 128 ГБ унифицированной памяти |
|---|---|---|
| Уровень квантования | UD-IQ3_XXS (104 ГБ) | UD-IQ2_M (90,9 ГБ) |
| Обработка запросов | 12,33 ток/с | от 459 до 462 ток/с |
| Генерация, один поток | 5,61 токена/с | около 19,1 токена/с |
| Время до первого токена, запрос 10k, рассчитано | около 13,5 мин | около 22 с |
| Источник | измерено здесь | Отчёт на форуме разработчиков NVIDIA |
Производительность генерации улучшилась в 3,4 раза. Производительность обработки подсказки улучшилась в 37 раз. Это не является контролируемым сравнением. Квантизация различается, конфигурация контекста различается, а в запуске Spark использовался llama-server с включенным flash attention, пакетом из 2048 токенов и микропакетом из 1024 токенов, в то время как в нашем случае использовались настройки по умолчанию llama-bench, которые специально оптимизируют префилл на стороне Spark. Ни один из этих факторов не объясняет 37-кратного различия. Prefill представляет собой умножение плотных матриц по всему пакету и требует параллельных вычислений; декодирование ограничено объёмом памяти, и процессор с достаточно широким пулом памяти справляется с этой задачей гораздо лучше, чем ожидают большинство людей.
Одно замечание по поводу наших собственных данных. Компьютер с ЦП представлял собой срез облачной виртуальной машины (AWS r7i.4xlarge, Xeon Platinum 8488C, 8 физических ядер с SMT), а срез не гарантирует полную пропускную способность памяти хоста. Мы также запустили 16 потоков, чтобы соответствовать количеству виртуальных ядер (vCPU), тогда как llama.cpp обычно предпочитает количество потоков, соответствующее количеству физических ядер, поэтому, вероятно, и здесь есть небольшой запас производительности. Рассматривайте значения 5,61 и 12,33 как нижний предел для класса, использующего только ЦП, а не как его верхний предел.
Оборудование, которое действительно работает
Примерно 128 ГБ памяти, к которой GPU или NPU могут обращаться напрямую. Именно в этом классе данная модель переходит от технической работоспособности к реальной применимости, и существует три способа достичь этого.
Системы с унифицированной памятью. DGX Spark, платформа Ryzen AI Max+ 395 и топовые модели Apple серии M объединяют один банк памяти для ЦП и ускорителя — именно это и требуется для работы с разреженными моделями MoE. В сравнительном обзоре систем Ryzen AI Max+ 395 рассмотрены цены на готовые комплекты этого класса и их отличия, а сравнение Mac mini, мини-ПК и систем с дискретными графическими процессорами позволяет принять аналогичное решение с учётом цены. Если вы выбираете систему в этом ценовом диапазоне, в руководстве по локальному ИИ для мини-ПК приводятся рекомендации по конфигурации памяти в зависимости от размера модели.
Системы с несколькими графическими процессорами. Наличие достаточного объёма VRAM для полного хранения 2-битного или 3-битного уровня — это самый быстрый путь, но и самый дорогой в пересчёте на гигабайт; в статье «Какой графический процессор купить для работы с LLM» рассмотрены актуальные модели карт. Более интересным вариантом является промежуточный подход: llama.cpp --n-cpu-moe N хранит веса экспертных слоёв первых N слоёв в системной оперативной памяти, в то время как «горячие» слои и KV-кеш остаются на графическом процессоре, и --cpu-moe сохраняет все экспертные веса на ЦП. Именно благодаря такому гибридному разделению модели MoE вообще становятся применимыми на потребительском оборудовании, и именно в этом случае одна карта объёмом 24 ГБ перестаёт быть бесполезной.
Только ЦП с большим объёмом оперативной памяти. Это работает, и приведённый выше тест подтверждает это. При скорости предварительной загрузки 12,33 токена в секунду это подходит для ночных пакетных заданий, но не для того, чтобы человек ждал результата. Стоит использовать, если ОЗУ уже установлено в компьютере, но никогда не стоит покупать оборудование специально для этого.
Есть ещё вариант, который по цене превосходит все три. DeepSeek указывает стоимость deepseek-v4-flash в 0,14 доллара за миллион входных токенов при промахе кэша, 0,0028 доллара за миллион при попадании в кэш и 0,28 доллара за миллион выходных токенов. Было объявлено о введении тарифов для пиковых и непиковых часов, но дата вступления в силу пока не определена; после введения тарифов стоимость удвоится в течение двух периодов пекинского рабочего дня. День интенсивного использования агента обойдется в несколько центов. Самостоятельное использование весов выгодно, когда они должны храниться на вашем собственном оборудовании, когда нет доступа к сети или когда вы намерены провести тонкую настройку. Если ни один из этих случаев не подходит, хостируемый API обойдется дешевле, чем расходы на электроэнергию.
Что не отражено в этих цифрах
Четыре пробела, названные прямо, потому что тест, скрывающий свои ограничения, стоит меньше, чем тот, который их указывает.
Отсутствуют данные по разгрузке GPU. В тестовой установке не было ускорителя, поэтому здесь нет результатов измерений для описанного выше гибридного экспертного разделения задач. Именно такую конфигурацию будут использовать большинство читателей, и именно этих данных не хватает в данном руководстве.
Отсутствуют результаты для Apple Silicon. Компьютеры серии M выполняют этот тест через другой стек, и результаты не сопоставимы, поэтому любые показатели для Mac следует рассматривать как не имеющие отношения к данным в этом руководстве.
Только один квант. Все вышеуказанное относится к UD-IQ3_XXS. 2-битовые уровни меньше по размеру и быстрее, и мы не измеряли, в чём они уступают по точности, что для модели рассуждений является важным вопросом.
Отсутствует пропускная способность для длинного контекста. Увеличение контекста до 32 768 привело к значительному замедлению работы того же промпта, при этом модель по-прежнему полностью размещалась в оперативной памяти, а объем подкачки был нулевым, так что дело не было в перегрузке памяти. Мы не выявили причину, поэтому здесь нет показателя «токены в секунду» для длинного контекста. Следующим этапом измерений станет надлежащий прогон по глубине.
Если у вас есть машина с 128 ГБ оперативной памяти и ускорителем, способным обращаться к этой памяти, то именно этот тест стоит провести. Именно он определит, найдётся ли место модели объёмом 284B в вашем повседневном рабочем процессе.