300 t/s на prefill, 16 t/s на decode и мягкая деградация скорости вплоть до 110 тысяч токенов контекста: такие цифры приводит пользователь, запустивший DeepSeek v4.1 Flash на конфигурации DS4 с квантизацией q2. Слабое место оказалось не в скорости. В Hermes-воркфлоу модель искала удалённый файл на локальном диске, перебирала ls ~/.ssh/ и делала grep по удалённой машине, хотя путь к нужному файлу уже был выведен в контексте. Задача закрылась только после прямого указания инструментов.
Короткий ответ на главный вопрос: DeepSeek v4.1 Flash на DS4 с q2 хорошо подходит для длинного контекста и быстрой обработки больших промптов, но для автономных агентов с набором инструментов она слабее GLM 5.3 Flash. Промпта Hermes на 18k токенов не хватило, чтобы модель начала пользоваться доступным выполнением кода, а это ключевая часть агентных сценариев.
Дальше идут замеры, кейс с tool calls, сравнение с GLM 5.3 Flash и вопрос перехода на q4. Все цифры взяты из описания одного практического запуска, а не из официального бенчмарка или лабораторного теста.
Что такое DeepSeek v4.1 Flash и конфигурация DS4
DeepSeek v4.1 Flash - открытая языковая модель семейства DeepSeek с архитектурой MoE (mixture of experts). На каждый токен активируется лишь часть экспертов, поэтому модель помещается в ограниченный объём памяти и выдаёт высокую пропускную способность при генерации. Такая схема позволяет запускать крупную модель на одной рабочей станции, а не на кластере GPU.
DS4 здесь означает связку инференс-движка и железа на базе M3U 32/80c. Обозначение 32/80c читают как 32 ядра CPU и 80 ядер GPU в одной системе с общей памятью. DS4 DwarfStar уже знаком читателям проекта: движок рассчитан на Apple Silicon, поддерживает кастомные квантизации Q2-Q4 с imatrix и разделение головы MTP, а в прошлом разборе давал 30+ ток/с против примерно 15 в llama.cpp.
Квантизация q2 означает, что веса модели сжаты примерно до двух бит на параметр. Памяти нужно меньше, модель умещается целиком, но качество почти всегда проседает, и на сложных задачах это меняет поведение, включая выбор инструментов. q4 хранит больше бит на вес: качество выше, а памяти и вычислений требуется больше.
Оговорка: всё описанное ниже - опыт одного пользователя в конкретной сборке. Повторяемость на другом железе, другой версии движка и другом промпте не гарантирована.
Скорость prefill и decode на DS4 с квантизацией q2
Prefill и decode - две разные фазы работы модели. На prefill движок обрабатывает весь входной промпт и заполняет KV-кэш: работа распараллеливается по токенам, поэтому счёт идёт на сотни токенов в секунду. На decode модель генерирует по одному токену, и скорость упирается в пропускную способность памяти, потому что каждый шаг требует чтения весов.
Замеры пользователя на DS4 с q2: около 300 t/s на prefill и 16 t/s на decode. Для агентных задач решающей оказывается вторая цифра. 16 t/s дают примерно 960 токенов в минуту, этого хватает на большинство шагов агента, но мало для больших дампов кода и длинных ответов.
Интереснее поведение на длинном контексте. В задаче по поиску багов скорость опустилась ниже 16 t/s только после примерно 110 тысяч токенов. До этой отметки заметной просадки пользователь не увидел. Загрузка GPU держалась около 95%, то есть система работала у самого предела.
Для планирования это значит, что длинный контекст не обрушивает производительность сразу, а плавно снижает её. Запас при этом почти исчерпан: любой рост контекста или переход на более тяжёлую квантизацию упрутся в железо.
Почему падение скорости на DS4 мягче, чем на llama.cpp
llama.cpp - универсальный движок, который обслуживает сотни архитектур. Он удобен как эталон совместимости, но не всегда оптимален для конкретной модели и длинного контекста. DS4 DwarfStar собирали под DeepSeek и Apple Silicon, отсюда более ровная кривая деградации: движок иначе раскладывает KV-кэш, иначе планирует работу с экспертами и персистентным кэшем на SSD. Насколько сильно реализация влияет на результат, видно на другом примере: на одном B300 пользователь получил около 770 токенов/с вместо ожидаемых тысяч, пока не подобрал рабочие MoE-ядра. Модель была та же, менялся движок и его настройки.
Проверить это на своём железе можно только прямым замером. Замеряйте prefill и decode на одинаковых длинах контекста (8k, 32k, 64k, 110k), фиксируйте промпт и не сравнивайте пиковое значение с медианой. Методика честного сравнения по p50 и p95 разобрана в материале про тесты DeepSeek V4 Flash на четырёх DGX Spark: пиковые 80 tok/s там соседствуют с заметно более скромными хвостами распределения.
Поведение tool calls в Hermes-воркфлоу: реальный кейс
Сценарий такой. Пользователь работал в Hermes-воркфлоу: модель получает задачу, сама решает, какой инструмент вызвать, и получает результат. Нужный файл лежал на удалённой машине, и путь к нему уже был выведен в контексте предыдущими шагами.
Что сделала модель:
- начала искать удалённый файл на локальном диске;
- затем перебрала
ls ~/.ssh/в поисках ключей; - затем сделала grep по удалённой машине, хотя искомое уже было в контексте;
- справилась с задачей только после того, как пользователь явно указал, какие инструменты использовать.
Промпт Hermes на 18k токенов не помог. Модель по-прежнему игнорирует доступное выполнение кода в наборе инструментов: рассуждает о том, что стоило бы сделать, вместо того чтобы вызвать инструмент и получить факт. Для агентного воркфлоу это дороже низкой скорости, потому что лишние шаги съедают контекст и время.
Почему модель игнорирует выполнение кода и как это исправить
Точную причину по одному кейсу не установить. Наиболее вероятные факторы: недостаточная обученность на формат tool calls в этой сборке, установка «сначала подумай» в промпте и слишком широкий список инструментов, где выполнение кода теряется среди прочих.
Что попробовать по порядку:
- Указать инструменты явно в системном промпте, вместе с примером вызова и ожидаемым форматом ответа.
- Добавить 2-3 few-shot примера, где агент сначала вызывает инструмент, а рассуждает уже по результату.
- Сократить набор инструментов до минимума под конкретную задачу: чем меньше опций, тем выше шанс, что модель выберет нужную.
- Разрешить или запретить вызов инструментов на первом шаге, если шаблон промпта это поддерживает.
- Проверить, не конфликтует ли шаблон Hermes с шаблоном чата самой модели: такое расхождение ломает поведение чаще, чем кажется.
Закладывайте бюджет отдельно. 18k токенов инструкций и описаний инструментов не хватило, значит для сложного агента нужен либо короткий и точный промпт, либо модель, которая увереннее работает с инструментами.
Сравнение DeepSeek v4.1 Flash и GLM 5.3 Flash
По скорости на начальном этапе GLM 5.3 Flash показывает около 21-19 t/s, DeepSeek v4.1 Flash на DS4 с q2 держит 16 t/s. Разрыв небольшой, но он в пользу GLM 5.3 Flash. По эффективности работы с инструментами разрыв уже заметный: DeepSeek игнорирует выполнение кода, а GLM 5.3 Flash в этом опыте ведёт себя собраннее.
| Параметр | DeepSeek v4.1 Flash (DS4, q2) | GLM 5.3 Flash |
|---|---|---|
| Decode на старте | 16 t/s | около 21-19 t/s |
| Prefill | около 300 t/s | нет данных в описании |
| Длинный контекст | ниже 16 t/s после примерно 110k токенов | нет данных в описании |
| Tool calls | игнорирует выполнение кода, нужны явные указания | работает эффективнее по оценке пользователя |
Выбор зависит от приоритета. Нужен длинный контекст и высокая скорость обработки промпта: DeepSeek v4.1 Flash на DS4 выглядит разумно. Нужен агент, который сам вызывает инструменты и не требует подсказок: по этому опыту выигрывает GLM 5.3 Flash. Позиции семейства DeepSeek в локальных и агентных сценариях 2026 года разобраны в отдельном материале о том, отстал ли DeepSeek от Qwen и GLM или это только так выглядит: там учитываются контекстное окно, KV-кэш, VRAM и стоимость инференса. Отдельно стоит держать в голове и общий контекст: DeepSeek V4 Flash занимает второе место среди open-weight моделей при цене около $0.09 за миллион токенов, что меняет расклад в облачных сценариях.
Стоит ли переходить на квантизацию q4
Переход с q2 на q4 обычно даёт более предсказуемое качество: меньше искажений в весах, стабильнее рассуждения и выбор инструментов. Плата известна: больше памяти и меньше скорость декодирования, потому что на каждый сгенерированный токен читается больше данных.
На DS4 с q2 GPU загружен примерно на 95%. Запаса почти нет, поэтому q4 с высокой вероятностью упрётся в память или начнёт вытеснять часть весов туда, где они читаются медленнее. Ориентир для решения: GLM 5.3 Flash на начальном этапе показывает около 21-19 t/s. Если после перехода на q4 декод DeepSeek просядет ниже уровня, выигрыш в качестве придётся взвешивать против потери скорости.
Разумный порядок действий:
- Зафиксировать задачу и промпт, на которых вы уже работаете с q2.
- Замерить prefill и decode на q2 на нескольких длинах контекста, а не только на пустом чате.
- Повторить те же замеры на q4 и сравнить не только t/s, но и число шагов агента до решения задачи.
- Оценить качество на своих данных: пропущенные вызовы инструментов и ошибки в рассуждениях заметны быстрее, чем разница в скорости.
Если q2 закрывает ваши задачи, менять её незачем. Если агент постоянно ошибается с инструментами, q4 эту проблему сам не решит: корень чаще в промпте и формате tool calls.
Требования к железу и загрузка GPU
В описанной конфигурации используется DS4 на базе M3U 32/80c с общей памятью. Загрузка GPU около 95% говорит о том, что система работает у предела возможностей на квантизации q2. На практике это даёт три следствия.
Память под модель и KV-кэш почти занята: контекст на 110k токенов держится на грани, а всё, что выходит за этот объём, либо не поместится, либо уйдёт в медленное чтение. Тепловой режим и троттлинг начинают влиять на цифры, поэтому один и тот же запуск на холодной и прогретой системе может отличаться. Переход на q4 добавляет нагрузку по двум фронтам сразу: веса занимают больше памяти, а время чтения на каждый токен растёт.
Перед сменой квантизации проверьте загрузку GPU и объём занятой памяти на реальных задачах, а не только на коротком запросе. Посмотрите отдельно, сколько памяти уходит на KV-кэш при вашей длине контекста: эту часть бюджета недооценивают чаще всего. Ориентируйтесь на собственные замеры, потому что опубликованные цифры по DeepSeek V4 Flash получены на другом железе и с другими движками.
Итоги: кому подходит DeepSeek v4.1 Flash на DS4 с q2
DeepSeek v4.1 Flash на DS4 с квантизацией q2 показывает около 300 t/s на prefill и стабильные 16 t/s на decode вплоть до примерно 110k токенов контекста. Сильная сторона очевидна: длинные промпты, поиск по большому массиву кода, разбор документации и пересказ проходят быстро.
Слабая сторона одна и она серьёзная: агентное поведение. Модель ищет удалённый файл локально, перебирает ls ~/.ssh/, делает grep там, где ответ уже есть, и не пользуется выполнением кода, даже когда инструмент доступен, а промпт Hermes занимает 18k токенов. GLM 5.3 Flash в этом опыте оказалась эффективнее при сопоставимых скоростях (21-19 t/s).
Кому подойдёт: тем, кто работает с длинным контекстом, готов явно описывать инструменты и контролировать шаги агента. Кому не подойдёт: тем, кто строит автономного агента, который сам выбирает инструменты и должен ошибаться редко.
Если у вас есть замеры DeepSeek v4.1 Flash на DS4 с q2 или q4, особенно на длинных контекстах и в агентных сценариях, поделитесь цифрами. Разница между движками и квантизациями становится видна именно на реальных задачах, а не на коротком тестовом запросе.