Hacker News Digest

DwarfStar 4 (ds4) — это узкоспециализированный C-движок для локального запуска frontier-моделей: DeepSeek V4/V4.1 Flash, GLM 5.x и Qwen3.8 Flash Next. Он работает на высокопамятных Mac (Metal), CUDA и ROCm-устройствах, используя асимметричную 2-битную квантилизацию routed экспертов, сохраняя точность критических путей. Это позволяет размещать 284-миллиардные параметровые модели на машинах с 128 ГБ ОЗУ, где KV-кэш сохраняется на SSD по хешу промпта, ускоряя перезапуски без полного префилла.

Движок предоставляет три интерфейса: интерактивный CLI (./ds4), локальный HTTP-сервер с OpenAI/Anthropic-совместимыми API (./ds4-server) и нативный агент для постоянных кодинг-сессий (./ds4-agent), все разделяющие одно состояние модели и кэш. На M5 Max с 128 ГБ при контексте 65K токенов достигается 398.5 токенов/с на префилле и 27.6 на генерации; на DGX Spark аналогичной конфигурации — 823.0 и 13.8 соответственно. Установка: клонировать репо, скачать веса через download_model.sh ds4f-q2, собрать под бекенд (например, make cuda-spark) и запустить. Лицензия MIT.

ds4 эффективно запускает крупные MoE-модели на Apple Silicon с 128 ГБ RAM, обеспечивая высокую скорость генерации и поддержку длинных контекстов (до 1 млн токенов, ~22 токенов/сек на Qwen 3.8 Flash Next на M5 Max). Требует дорогостоящего оборудования, ограничивая доступность. ds4 отличается минимальными зависимостями, ориентацией на frontier-модели и асимметричной 2-битной квантизацией экспертов, позволяя размещать модели до 284 млрд параметров на потребительском железе. Поддерживает Metal (Apple Silicon) и CUDA/ROCm (другие платформы), фокусируясь на реальных сценариях использования на высокопроизводительном оборудовании, а не на универсальности. Разработчики расширяют ds4: добавлена поддержка Qwen3.8 и Vision, реализованы FFI-биндинги для Go (ds4go), улучшена интеграция с Hugging Face через TUI. SSD-стриминг позволяет запускать крупные модели (например, полные GLM 5.x) на системах с менее чем 96 ГБ RAM, расширяя применимость за пределы флагманских Mac. Пользователь @simoiacos разработал собственный инференс-движок для Intel Xe-LP (без XMX) на 32 ГБ ноутбуках, поддерживающий квантизированный Gemma-4, с планами расширения поддержки MoE-моделей. Пользователь @liuliu рекомендует Local Code (TestFlight) как альтернативу для 64 ГБ M5-Pro, поддерживающую DeepSeek 4.1 Flash и Qwen 3.8 27B с SSD-стримингом и кастомными квантами. Некоторые пользователи сомневаются в уникальности ds4 по сравнению с llama.cpp или ollama, которые также поддерживают длинные контексты и квантизацию. Комментатор @doctorpangloss утверждает, что квантизированный чекпоинт DeepSeek V4 низкого качества, что ставит под сомнение точность результатов несмотря на высокую скорость. Использование C вместо Rust обусловлено стремлением к минимальным зависимостям и максимальной портируемости (как в Redis), обеспечивая лёгкую интеграцию через FFI. Пользователь @neomantra создал ds4go — Go-биндинги и TUI-инструменты для загрузки моделей с Hugging Face, упрощая использование ds4 для не-C-разработчиков. Цена MacBook Pro M5 Max с 128 ГБ RAM (~7800 €) делает ds4 доступным лишь для узкого круга пользователей, ограничивая массовое распространение несмотря на технические достижения.

Kev — это семейство небольших моделей принятия решений, построенных на базе Qwen3.5 и вдохновлённых архитектурой Jev. Доступны версии 0.8B, 4B и 9B параметров, которые можно запускать локально или дообучать под свои задачи. Модели поддерживают три типа запросов: да/нет (noul), множественный выбор (choice) и оценка (score), все они работают с одним входным текстом, но не видят ответов друг друга. API совместим с TypeSafe System One, что позволяет использовать их Python SDK с локальным сервером.

Модели работают на CUDA, ROCm и Apple Silicon (через MLX); 4B и 9B версии помещаются в 32 ГБ памяти Mac. Есть веб-игровая площадка для тестирования ввода и наблюдения за влиянием порядка вариантов на ответы, доступная в Hugging Face Spaces без установки. Для запуска требуется Python 3.12–3.13 и менеджер пакетов uv. В репозитории есть код для обучения, наборы данных для оценки и тесты, включая проверку через TypeSafe SDK. Лицензия — Apache-2.0, как и у базовых моделей Qwen.

Kev и подобные модели применяются в локальных задачах классификации и принятия решений, но их уникальность по сравнению с Jev ставится под сомнение из-за различий в обучении и качестве. Для классификации с малым числом примеров (50–100) рекомендуется использовать Codex/Claude для создания эмбеддингов + логистической регрессии: модель <1MB, обучение на CPU за 5 минут, точность 95%, инференс <100мс, данные остаются локально. Jev-подобные модели на Qwen3.5 не считаются настоящими Jev, так как Jev обучен на RLCD, а Qwen — на RLHF, что влияет на поведение при принятии решений. Jev-подобные модели могут автоматизировать стилистические правила в фронтенде (React, CSS), устраняя дрейф и дублирование, сокращая рутину разработчиков. Модели размером 0.8B–9B подходят для встраивания в игры как «питомцы»: обработка голосовых команд через STT и локальный инференс для выбора действий NPC. Для фильтрации спама такие модели могут заменить 27B-модели, снижая вычислительные затраты при сохранении высокой точности. На Gemma 4 (12B) достигнута задержка 220 мс на шаг в игре Snake на старом ПК, что указывает на потенциал снижения задержки на более мощных машинах. Прокси-слои между Jev и другими API (например, Frontier) сокращают количество вызовов инструментов на 60%, оптимизируя стоимость и производительность. Jev-подобные модели не имеют принципиального отличия от обычных классификаторов, так как их специфичность определяется обучающими данными, а не архитектурой; открытые альтернативы пока уступают по качеству. Для локального использования моделей с ограниченным knowledge cutoff требуется постоянное дообучение или регулярная смена версий, иначе они устаревают. Jev-подобные модели могут использоваться для автоматической разметки данных, но сравнение их качества с Kev в этой задаче пока неясно. Быстрое появление открытых альтернатив Jev в течение недели после релиза свидетельствует о живом интересе сообщества к простым, локальным моделям принятия решений. Создание Jev-подобных моделей на базе Qwen3.5 может упростить внутреннюю логику маршрутизации в системах, но требует проверки надёжности на критических путях.

Главная идея — первый рабочий запуск DeepSeek‑V4‑Flash‑0731 на одной видеокарте AMD MI300X без дополнительной квантовки или оффлоу. Модель полностью помещается в 156,7 GiB HBM3, а благодаря 192 GiB памяти и 5,3 TB/s пропускной способности достигается пропускная способность до ≈ 8 K токенов/сек при предзаполнении и 168,6 токенов/сек в медиане однопоточного декодирования. При 8‑х одновременных потоках суммарный вывод достигает 542 токенов/сек, а пиковый 64‑потоковый баст‑запрос укладывается в 830 токенов/сек без OOM и ошибок движка. Контекст поддерживается до 256 K токенов (архитектура теоретически позволяет 1 M).

Ключевые факты, которые стоит запомнить:

• 156,7 GiB весов — полностью в HBM, без offload‑квантовки;
• ≈ 8 K tok/s предзаполнение (6 988–7 019 tok/s в продакшн‑профиле);
• 542 tok/s суммарный вывод при 8‑х потоках, 830 tok/s при 64‑потоковом басте;
• Исправления касаются FP8‑формата MI300X, MoE‑маршрутизации, CPU‑KV синхронизации и специфичных ядер ROCm.

Эти детали позволяют использовать MI300X как дешевый (в 2–3 раза) альтернативный вариант к NVIDIA‑решениям для тяжёлых LLM‑задач.

DeepSeek V4 Flash можно запускать на AMD MI300X, но с ограничением контекстного окна с 1M до 256k — по опыту @monster_truck, это не снижает качество. @Tepix считает MI300X неподходящей как OAM-модуль, но @WhitneyLand отмечает, что модель работает, хоть и с ограничениями. MI350P — альтернатива с 144GB памяти, но меньшей, чем у MI300X. @fergusfinn советует использовать MI300X с высоким HBM и делится опытом работы с 2xMI300X. Производительность MI300X всё ещё ниже, чем у H800 (15k токенов/сек).