DS4 DwarfStar против llama.cpp: двукратный прирост скорости на Apple Silicon
DS4 DwarfStar от antirez выдаёт на MacBook Pro M4 Max 128GB более 30 токенов в секунду на модели DeepSeek-V4-Flash-0731-UD-Q8_K_XL (161.9 GB). Стандартный llama.cpp на том же железе и той же модели не дотягивает до 15 ток/с. Разница - двукратная. Это главный аргумент для перехода, и он подтверждён прямыми замерами при tensor-split 97,65 через RPC по Thunderbolt 5 на двухузловой конфигурации 2× MacBook Pro M4 Max 128 GB.
Плата за скорость - нестабильность RPC. Пустые сообщения ассистента в истории диалогов вызывают деградацию вывода: модель начинает генерировать последовательность «====» вместо связного ответа. Сбой на стороне воркера убивает весь сервер без автоматического восстановления. Это известные issues в llama.cpp, ожидающие исправления. Для агентных сценариев и кодинга прирост оправдан, но историю диалогов придётся нормализовать.
Практический вывод: если вы работаете на Apple Silicon и готовы к экспериментам - переходите. Если стабильность критичнее скорости или вы на CUDA/ROCm без возможности тонкой настройки - оставайтесь на llama.cpp. Детальный разбор архитектурных решений, тестов и ограничений - далее.
Кастомная квантизация Q2-Q4 с imatrix: как уменьшить модель без потери качества
DeepSeek-V4-Flash использует смешанную точность: routed experts хранятся в нативном MXFP4, а остальные слои - в FP8. Благодаря этому квантизация Q8_K_XL - это lossless repack: модель сжимается до 161.9 GB без потери точности. Дальнейшее сжатие в Q2-Q4 требует кастомной процедуры с imatrix, чтобы сохранить качество при низких битах.
imatrix - это матрица важности весов, которая направляет квантизатор: критичные для точности слои получают больше битов, второстепенные - меньше. Без imatrix агрессивная квантизация в Q2 даёт заметную деградацию на сложных задачах. С imatrix разница между IQ3_XXS-AS и IQ2_S на RTX 3090 + 128 ГБ DDR4 с AMD Ryzen 5950X оказалась незначительной: IQ2_S быстрее в генерации на 18-19% при идентичной скорости промпт-процессинга, но качество IQ3 заметно выше. Оптимальный компромисс - IQ3_XXS-AS.
Планы сообщества включают Q2_K и Q4_K - новые варианты квантизации, которые обещают дальнейшее сжатие с минимальными потерями. Предварительные оценки показывают, что Q4_K может дать размер около 100 GB при сохранении приемлемой точности для кодинга. Q2_K - экстремальный вариант для сценариев, где размер критичнее качества.
Почему голова MTP требует отдельного GGUF-файла
Multi-Token Prediction (MTP) в DeepSeek v4 Flash - это компонент, предсказывающий несколько следующих токенов одновременно. Он увеличивает пропускную способность инференса за счёт спекулятивного декодирования. DS4 DwarfStar использует этот компонент под названием DSpark, и для эффективной работы требует отдельного GGUF-файла.
Разделение файлов позволяет движку распределять вычисления: основная модель обрабатывает контекст, а голова MTP работает параллельно, генерируя черновики токенов. Без разделения память расходуется неоптимально, а скорость падает. Подготовка отдельного GGUF для MTP - обязательный шаг при кастомной квантизации под DS4.
Практические сценарии: агенты, кодинг и персистентный KV-кэш на SSD
Скорость выше 30 ток/с меняет опыт работы в IDE-подобных средах: автодополнение кода становится мгновенным, итерации «запрос-ответ» перестают тормозить рабочий процесс. В прямом сравнении DeepSeek V4 Flash и Qwen 3.6 27B на агентных задачах прирост скорости DS4 даёт решающее преимущество при длинных цепочках вызовов инструментов.
Разделение головы MTP и персистентный KV-кэш на SSD адресуют главную боль агентных сценариев - восстановление контекста. Кэш на SSD позволяет мгновенно загружать сессию после перезапуска, экономя время на повторный промпт-процессинг. Однако у этого решения есть обратная сторона: пустые сообщения ассистента в истории вызывают деградацию вывода.
Персистентный KV-кэш на SSD: когда это действительно нужно
Хранение KV-кэша в RAM даёт скорость доступа на порядок выше, чем SSD. Но для длительных агентных сессий с контекстом в сотни тысяч токенов RAM может не хватить. SSD-кэш решает эту проблему ценой небольшой задержки при первом обращении. Цифры: загрузка сессии с 100K токенов из SSD занимает 2-3 секунды против 0.1-0.2 секунды из RAM. Для агентов, работающих часами, эта разница некритична. Для интерактивного кодинга с частыми перезапусками - лучше держать кэш в RAM.
Рекомендация: используйте SSD-кэш для агентных сценариев с длинным контекстом и редкими перезапусками. Для кодинга и диалоговых интерфейсов - RAM. Чанкованный SSD matmul в llama.cpp уже ускоряет prefill до 22% на NVIDIA GPU, и аналогичные оптимизации ожидаются для DS4.
Подводные камни RPC-развертывания: пустые сообщения и падение воркеров
RPC-развертывание DS4 на двух MacBook Pro M4 Max через Thunderbolt 5 даёт двукратный прирост скорости. Но оно же приносит два критических бага. Первый: пустые сообщения ассистента в истории диалогов. Модель начинает генерировать «====» и не может восстановиться. Воспроизводится стабильно: достаточно одного пустого turn'а в середине длинного диалога. Причина - в обработке специальных токенов на стороне воркера, где пустой ответ интерпретируется как разделитель.
Второй баг: сбой на стороне воркера убивает весь сервер. RPC не имеет механизма восстановления - при падении одного узла второй продолжает слать запросы в пустоту, пока не упрётся в таймаут. Мониторинг и ручной перезапуск - единственный обходной путь на август 2026.
Как избежать деградации вывода: нормализация истории диалогов
Практический рецепт - фильтрация пустых сообщений перед отправкой в модель. Пример кода на Python для preprocessing'а:
def normalize_history(messages):
return [msg for msg in messages if msg.get("content", "").strip()]
# Применение перед вызовом DS4
clean_messages = normalize_history(chat_history)
response = ds4_client.generate(clean_messages)Альтернатива - замена пустого контента на специальный токен-заполнитель, например, «[continue]». Это сохраняет структуру диалога и не вызывает деградации. Выбор метода зависит от того, насколько важна точная история для вашего сценария.
Сравнение платформ: Metal, CUDA и ROCm - что выбирать в 2026
DS4 DwarfStar изначально оптимизирован под Metal и Apple Silicon. На MacBook Pro M4 Max он даёт стабильные 30+ ток/с. На CUDA результаты неоднородны. Конфигурация с двумя RTX 4090 (48 ГБ) и портированными Blackwell-ядрами через Triton выдаёт 105 ток/с на DeepSeek V4 Flash - в 2-3 раза быстрее llama-server. Но это требует специального Docker-образа vLLM-Moet и P2P-патча для двух GPU. Стандартная установка таких цифр не даст.
На ROCm ситуация иная. Прямое сравнение GGUF и DS4 Flash на стеке ROCM показало преимущество DS4 Flash на 20% (22.5 против 18.7 t/s) при меньшем потреблении памяти. Но стабильность ниже, чем на Metal. Для кластерных решений CUDA остаётся предпочтительной платформой - с учётом доработок, описанных в разборе запуска на одном B300.
Рекомендация: для максимальной производительности на одном устройстве - Apple Silicon с DS4. Для кластеров и пакетной обработки - CUDA с vLLM и портированными ядрами. ROCm - компромиссный вариант с хорошей скоростью, но меньшей стабильностью.
Дорожная карта: новые квантизации и кастомные векторы для абляции
Сообщество работает над Q2_K и Q4_K - вариантами квантизации, которые обещают дальнейшее сжатие DeepSeek V4 Flash. Q4_K ожидается в сентябре 2026, Q2_K - до конца года. Предварительные тесты показывают, что Q4_K сохранит приемлемое качество для кодинга при размере около 100 GB.
Отдельное направление - кастомные векторы для directional ablation (аблитерации). Эта техника позволяет управлять стилем и безопасностью модели без дообучения: определённые направления в latent space подавляются или усиливаются. Для DeepSeek V4 Flash планируются векторы для контроля токсичности и стиля кода. Сроки не объявлены, но первые эксперименты ожидаются в четвёртом квартале 2026.
Эти разработки откроют новые сценарии использования: от безопасных агентов до специализированных моделей для код-ревью с контролируемым стилем комментариев.
Выводы: когда переходить на DS4 DwarfStar, а когда остаться на llama.cpp
DS4 DwarfStar даёт двукратный прирост скорости на Apple Silicon - с менее 15 ток/с до более 30 ток/с. Это решающее преимущество для агентов и кодинга, где каждая секунда ожидания тормозит рабочий процесс. Кастомная квантизация с imatrix позволяет сжать модель до приемлемого размера без критичной потери качества, а разделение головы MTP на отдельный GGUF-файл - эффективно использовать память.
Обратная сторона - нестабильность RPC. Пустые сообщения ассистента ломают вывод, сбой воркера роняет весь сервер. Эти проблемы решаются нормализацией истории и мониторингом, но требуют дополнительных усилий.
Алгоритм принятия решения:
- Переходите на DS4, если работаете на Apple Silicon, готовы к экспериментам и нуждаетесь в скорости для агентов или кодинга.
- Оставайтесь на llama.cpp, если стабильность критичнее скорости, вы на CUDA/ROCm без возможности тонкой настройки или не готовы тратить время на обход багов.
- Рассмотрите гибридный подход: llama.cpp для продакшена, DS4 для исследовательских задач и бенчмарков.
Сообщество активно делится опытом. Сравнение Minimax 2.7, DeepSeek V4 Flash и Laguna S 2.1 на агентных задачах даёт дополнительные метрики для выбора. Делитесь своими результатами в комментариях - агрессивная квантизация на M5 Max уже показала почти идентичные результаты с нативным чекпоинтом на двух DGX Spark (54% против 52% в Terminal-Bench 2.1). Ваш опыт поможет сообществу быстрее найти оптимальные конфигурации.