Как запустить 480-миллиардную модель на MacBook с 36 ГБ памяти — стриминг экспертов MoE с SSD
Разработчик форкнул llama.cpp, чтобы запускать огромные MoE-модели (до 480B параметров) на обычном MacBook, подгружая веса экспертов с SSD по требованию вместо загрузки всей модели в RAM. Qwen 35B выдаёт ~13-19 tok/s, даже 118B-модель работает на устройстве с 36 ГБ памяти. Приложение доступно как готовый .dmg для macOS, код открыт (MIT), все бенчмарки — включая провалившиеся эксперименты — опубликованы.
Это реальный способ запускать модели уровня 35B–118B на обычном MacBook без аренды облака — важно для разработчиков, которым нужна приватность, низкая латентность и контроль над кодом. Открытая публикация провалов задаёт стандарт честности в бенчмарках.
Стриминг MoE-моделей с SSD: как запустить 118B на MacBook
Разработчик под ником Illustrious-Cup-5895 представил Slipstream — форк llama.cpp, позволяющий запускать огромные Mixture-of-Experts (MoE) модели на Mac с ограниченной памятью. Суть подхода: держать в RAM только постоянно используемые веса, а веса экспертов — стримить с SSD по мере необходимости.
Почему это работает
MoE-модели на каждый токен активируют лишь несколько из десятков экспертов — остальные веса простаивают. Slipstream использует bounded RAM cache: загружает только те эксперты, которые нужны прямо сейчас, и не даёт системе уйти в swap.
Реальные цифры
- Qwen3.6-35B-A3B (Q4, стриминг с NVMe): 13 tok/s при кэше 10 ГБ (78% попаданий), 19 tok/s при 14 ГБ — вполне пригодна для интерактивной работы.
- Laguna 118B-A8B (модель НЕ влезает в 36 ГБ целиком): 2.8 tok/s — хватает для batch-обработки кода, но не для чата.
- Главный буст дало перемещение файла с экспертами на более быстрый диск: прирост в 2.7× раза. Скорость хранилища важнее алгоритмов.
- Zero-copy оптимизация, которую автор сначала отбросил, дала +13–24% при реальных размерах кэша — включена по умолчанию.
Честность: что НЕ сработало
Автор опубликовал и провалившиеся эксперименты:
- Dual-SSD striping (внутренний NVMe + медленный USB): отрицательный результат из-за shared bus.
- Спекулятивный prefetch (статический + онлайн-предсказание): −8%, накладные расходы не окупаются.
- Резервирование кэша под HOT-экспертов: −1 до −6% — сокращение общего кэша убивает выигрыш.
Готовое решение
Slipstream поставляется как нативное macOS-приложение: скачиваешь .dmg, перетаскиваешь в Applications, открываешь (через правый клик → Open, т.к. не нотаризировано). Движок внутри, ничего компилировать не нужно. Поднимается API на localhost:8080 — работает с Kilo, Cline, Cursor, OpenCode.
Код открыт (MIT), работает 100% on-device на Apple Silicon + Metal. Вдохновлён проектом JustVugg/colibri (аналог для CPU/CUDA).
Полные бенчмарки — включая негативные результаты — в BENCHMARKS.md в репозитории.
Ключевые выводы
- MoE-модели можно запускать на Mac с 36 ГБ RAM, стримя веса экспертов с SSD — подход работает благодаря тому, что на каждый токен активны лишь несколько экспертов
- Размещение файлов на быстром диске даёт кратный прирост скорости (2.7×), превосходя любые программные оптимизации
- Спекулятивный prefetch и резервирование кэша под популярные эксперты на практике ухудшают производительность — честное тестирование важнее теоретических предположений
- Qwen 35B достигает 13-19 tok/s, что делает локальную работу с большой моделью на Mac вполне практичной для генерации кода
- Публикация провалившихся экспериментов — редкость в ML-сообществе, но критически важна для инженерного прогресса
Автор: Анна Мельникова · Источник: reddit.com
Это один из тех проектов, где радуешься не только результату, но и *подходу*. Автор не просто решил задачу — он показал все грабли, на которые наступил. Спекулятивный prefetch? Минус восемь процентов. Dual-SSD striping? Не работает на shared bus. Резервирование кэша под горячие эксперты? Минус шесть.
В мире ML-бенчмарков, где обычно публикуют только победные цифры, это глоток свежего воздуха. По сути, Slipstream — инженерное доказательство, что MoE-модели можно делать *практичными* на потребительском железе. Да, 2.8 tok/s для 118B — это не GPT-4 в облаке, но для batch-обработки кода на собственном устройстве, без утечки данных в API и без ежемесячной подписки — это вполне рабочий вариант. А главное — код открыт, движок упакован в .dmg, который просто работает. Никаких `brew install`, `cmake`, `pip install torch==точно.эта.версия`.
Инструменты из статьи
Автономный AI-агент для кода в VS Code: читает проект, правит файлы и...
Доступ из РФ →AI-редактор кода на базе VS Code: автодополнение, агентный режим, работа с...
Доступ из РФ →
Комментарии