Что такое Slipstream и зачем он нужен
Slipstream - форк llama.cpp, который стримит веса экспертов MoE-моделей напрямую с SSD, минуя ограничения оперативной памяти. Проект решает конкретную задачу: запуск моделей, чей полный размер превышает доступную RAM, на обычном MacBook. Вместо загрузки всех параметров в память Slipstream держит в RAM только неэкспертные веса и активных экспертов, а остальные подгружает с накопителя по мере необходимости. Результат: Qwen3.6-35B-A3B в квантовании Q4 выдаёт ~13 токенов в секунду на MacBook с 36 ГБ RAM, а Laguna 118B-A8B работает со скоростью ~2.8 ток/с в сценариях пакетной генерации кода.
Техника стриминга экспертов не нова - ранее мы разбирали стриминг-инференс через TensorRT-LLM и DeepSpeed, где поднимался вопрос о реальной скорости такого подхода. Slipstream доводит идею до практического применения на Apple Silicon, показывая, что даже бюджетный MacBook способен работать с моделями, которые ещё год назад требовали серверных GPU.
Проблема: почему большие MoE-модели не запустить на обычном MacBook
Стандартный llama.cpp загружает все веса модели в RAM через mmap. Для MoE-архитектур это создаёт фундаментальное ограничение. Возьмём Qwen3.6-35B-A3B: полный размер модели в FP16 составляет около 70 ГБ, хотя активных параметров всего 3 миллиарда из 35. Остальные 32 миллиарда - эксперты, которые не используются одновременно. Традиционный подход требует держать все 70 ГБ в памяти, что невозможно на MacBook с 36 ГБ RAM.
GPU-оффлоадинг частично решает проблему, но упирается в объём видеопамяти. На Apple Silicon unified-память общая для CPU и GPU, поэтому лимит железный: 36 ГБ - это потолок для всех операций. Квантование GGUF снижает требования, но даже Q4_K_M для 70-гигабайтной модели занимает около 40 ГБ - всё ещё больше доступного объёма.
Как Slipstream обходит ограничения: стриминг экспертов с SSD
Архитектурно Slipstream модифицирует загрузчик весов llama.cpp. Неэкспертные слои - attention, shared MLP, эмбеддинги - загружаются в RAM стандартным способом. Веса экспертов остаются на SSD и читаются асинхронно в момент, когда роутер модели решает, какой эксперт активировать для текущего токена.
Механика работает так. При инференсе модель генерирует токен за токеном. Для каждого токена роутер выбирает top-k экспертов (обычно 2-4 из десятков доступных). Slipstream перехватывает этот выбор, проверяет, есть ли нужные эксперты в RAM-кэше, и при отсутствии инициирует чтение с SSD. Чтение асинхронное: пока один эксперт обрабатывается, следующий уже подгружается. Кэш в RAM хранит ограниченное число недавно использованных экспертов - политика LRU вытесняет неактивные.
Сравнение с обычным mmap показательное. mmap полагается на страничный кэш ОС и подгружает данные пассивно при page fault. Slipstream управляет загрузкой явно, зная паттерн доступа: какие эксперты понадобятся для следующего токена, предсказать нельзя, но можно минимизировать задержку через асинхронный I/O и кольцевой буфер предзагрузки. По сравнению с GPU-оффлоадингом Slipstream выигрывает в универсальности: не требует CUDA или мощного GPU, работает на чистом CPU с unified-памятью.
Реальная производительность: тесты Slipstream на MacBook 36 ГБ
Все замеры проводились на MacBook Pro с чипом M3 Pro, 36 ГБ unified-памяти и внутренним SSD объёмом 1 ТБ. Скорость последовательного чтения накопителя - около 5 ГБ/с. Модели использовались в формате GGUF с квантованием Q4_K_M, если не указано иное. Контекст - 4096 токенов, batch size равен 1 для интерактивных тестов и 8 для пакетной генерации.
Qwen3.6-35B-A3B (Q4): 13 ток/с - комфортный инференс
Qwen3.6-35B-A3B - MoE-модель с 35 миллиардами полных параметров, из которых 3 миллиарда активны на каждый токен. В квантовании Q4_K_M модель занимает около 20 ГБ на диске. Slipstream загружает в RAM примерно 6 ГБ неэкспертных весов и держит кэш на 4-6 экспертов (ещё 2-3 ГБ). Остальные эксперты стримятся с SSD.
Результат: 13.2 ток/с на decode-фазе при диалоговом сценарии. Time-to-first-token для промпта из 500 токенов - 4.8 секунды. Для сравнения, та же модель на RTX 4090 с 24 ГБ VRAM через стандартный llama.cpp с GPU-оффлоадингом выдаёт около 45 ток/с. Разрыв в 3.5 раза - плата за отсутствие GPU. Однако 13 ток/с достаточно для комфортного чтения: средняя скорость чтения человека - 200-300 слов в минуту, что эквивалентно 8-12 токенам в секунду для английского текста. Модель пригодна для диалогов, суммаризации, ответов на вопросы.
Laguna 118B-A8B: 2.8 ток/с для пакетной генерации кода
Laguna 118B-A8B - значительно более крупная MoE-модель: 118 миллиардов полных параметров, 8 миллиардов активных. Мы детально разбирали её архитектуру и бенчмарки в сравнении Laguna S 2.1 с DeepSeek V4 Flash. В Q4_K_M модель весит около 65 ГБ - почти вдвое больше доступной RAM.
Slipstream запускает Laguna со скоростью 2.8 ток/с на decode. Time-to-first-token для промпта из 1000 токенов - 18 секунд. Для интерактивного чата это медленно, но сценарий пакетной генерации кода меняет картину. При batch size 8 и отложенной выдаче результатов 2.8 ток/с на поток дают суммарную пропускную способность около 22 ток/с. Задача автодополнения функции из 50 токенов решается за 18 секунд - приемлемо для фоновой работы. Рефакторинг модуля из 200 токенов занимает чуть больше минуты.
Практический вывод: Slipstream с крупными моделями оправдан в асинхронных сценариях, где задержка некритична. Пакетная обработка, ночные прогоны тестов, генерация синтетических данных - здесь 2.8 ток/с вполне рабочий показатель.
Провальные эксперименты: что не сработало в Slipstream
Разработчики Slipstream проверили три гипотезы по ускорению стриминга. Все три дали отрицательный результат. Разбор этих попыток ценнее многих успешных кейсов: он очерчивает границы метода и экономит время тем, кто захочет повторить эксперименты.
Dual-SSD striping: почему два SSD не ускорили стриминг
Гипотеза: при стриминге экспертов узкое место - пропускная способность накопителя. Если один SSD даёт 5 ГБ/с, два в striping-режиме (RAID-0) должны дать до 10 ГБ/с и пропорционально поднять ток/с.
Реальность: скорость генерации не изменилась. Замеры показали, что даже на пике Slipstream читает с SSD около 1.2 ГБ/с при инференсе Qwen3.6-35B-A3B. Пропускная способность одного внутреннего SSD MacBook (5 ГБ/с) не исчерпана и на четверть. Узким местом оказалась не полоса пропускания, а latency случайного доступа и накладные расходы на переключение контекста между потоками чтения. Два SSD добавили оверхед на координацию, но не сократили задержку единичного запроса.
Striping имеет смысл при последовательном чтении больших блоков. Стриминг экспертов - это множество мелких случайных чтений (размер эксперта в Q4 - десятки мегабайт), где latency доминирует над throughput.
Prefetch-предикторы: как предсказание экспертов снизило скорость на 8%
Гипотеза: если предсказать, какой эксперт понадобится для следующего токена, можно начать его загрузку заранее и скрыть latency SSD за вычислениями текущего токена. Для предсказания использовалась статистика переходов между экспертами, собранная на прогоне из 10 000 токенов.
Реальность: prefetch замедлил инференс на 8%. Причина - низкая точность предсказаний. Паттерны активации экспертов в MoE-моделях слабо коррелируют между соседними токенами. Роутер выбирает экспертов на основе содержимого скрытого состояния, которое меняется от токена к токену. Статистический предиктор угадывал следующий экспертный набор лишь в 23% случаев. Остальные 77% - напрасные чтения с SSD, которые потребляли полосу и создавали конкуренцию за I/O с реально нужными данными. Оверхед на вычисление предиктора и инициацию ложных чтений перевесил выигрыш от редких попаданий.
Этот результат согласуется с нашим анализом спекулятивного декодинга на частично выгруженных MoE, где предсказание экспертов через MTP-головку показало 78% точности - но там использовалась внутренняя механика модели, а не внешняя статистика.
HOT-expert резервация: почему удержание «горячих» экспертов в RAM не помогло
Гипотеза: некоторые эксперты активируются чаще других. Если зарезервировать под них часть RAM и никогда не вытеснять, доля кэш-попаданий вырастет, а средняя задержка упадёт.
Реальность: распределение активаций экспертов действительно неравномерное - 20% экспертов покрывают около 60% вызовов. Однако «горячий» набор дрейфует. Эксперт, активный при обработке кода, может ни разу не вызваться на диалоговом промпте. При резервации фиксированного пула из 8 экспертов (около 3 ГБ RAM) доля попаданий в кэш выросла с 31% до 38% - прирост скромный. Одновременно сократился доступный объём для динамического кэша, что увеличило промахи для нерезервированных экспертов. Суммарный эффект оказался нулевым: экономия на горячих попаданиях съедена потерями на холодных промахах.
Вывод: статическое кэширование не работает для MoE с меняющимся контекстом. LRU с достаточным размером кэша показывает себя лучше любых фиксированных резерваций.
Ключевой фактор: как скорость SSD влияет на производительность Slipstream
Зависимость ток/с от скорости накопителя - не линейная, но жёсткая. Тесты на трёх конфигурациях хранения с Qwen3.6-35B-A3B:
- Внутренний SSD MacBook (5 ГБ/с sequential read): 13.2 ток/с
- Внешний Thunderbolt 4 SSD (2.8 ГБ/с): 9.1 ток/с
- Внешний USB-C 3.2 SSD (1 ГБ/с): 5.4 ток/с
Падение скорости чтения в 5 раз снижает производительность в 2.4 раза - не пропорционально, потому что часть времени уходит на вычисления, не зависящие от I/O. При 1 ГБ/с инференс становится ощутимо медленным: 5.4 ток/с - это нижняя граница комфортного чтения.
Рекомендация: минимальная скорость SSD для Slipstream - 2 ГБ/с последовательного чтения. Ниже этого порога задержка генерации начинает раздражать даже в асинхронных сценариях. Внутренние SSD MacBook на чипах M1 Pro и новее удовлетворяют требованию с запасом. Внешние накопители подходят только при подключении через Thunderbolt 4; USB-C 3.2 Gen2 (10 Гбит/с) даёт около 1 ГБ/с реальной скорости - маловато.
Интересный нюанс: random read latency важнее sequential throughput. Внутренний SSD MacBook имеет latency около 50 микросекунд на случайное чтение 4K-блока. Внешний Thunderbolt добавляет 100-150 микросекунд транспортной задержки. Slipstream делает сотни мелких чтений в секунду, и эта разница накапливается.
Slipstream vs альтернативы: когда стоит использовать форк
Slipstream не универсальное решение. Выбор между ним и другими подходами зависит от трёх факторов: размера модели, доступного железа и требуемой скорости.
GGUF-квантование + стандартный llama.cpp. Если модель влезает в RAM после квантования - используйте этот вариант. Он даст максимальную скорость, поскольку все веса уже в памяти. Slipstream имеет смысл, только когда даже Q4 не помещается. Для MacBook с 36 ГБ граница проходит примерно на моделях с полным размером от 50-60B в FP16.
MLX и Ollama. MLX - нативный фреймворк для Apple Silicon с хорошей поддержкой квантования, но без стриминга экспертов. Ollama использует llama.cpp под капотом и наследует его ограничения. Slipstream выигрывает в единственном сценарии: модель слишком велика для RAM, а GPU-оффлоадинг невозможен или не покрывает разницу.
GPU-оффлоадинг на дискретные карты. Для систем с мощным GPU (RTX 3090/4090) и достаточной VRAM оффлоадинг даст лучшую скорость. Оптимизация инференса DeepSeek-V4-Flash на одном B300 показывает, что при грамотной настройке можно достичь сотен токенов в секунду. Slipstream - для ситуаций, когда GPU нет или его памяти недостаточно.
Плюсы Slipstream: запуск моделей, которые иначе не запустить на данном железе; работа на чистом CPU без GPU; низкий порог входа (MacBook с 36 ГБ RAM есть у многих разработчиков). Минусы: скорость жёстко привязана к SSD; крупные модели работают медленно; не все GGUF-модели совместимы (требуется поддержка со стороны загрузчика).
Практическое правило: если модель влезает в RAM с квантованием Q4 - берите стандартный llama.cpp. Если нет, но у вас MacBook с быстрым SSD и вы готовы мириться со скоростью 2-13 ток/с - Slipstream открывает доступ к моделям, которые иначе были бы недоступны.
Быстрый старт: как установить и запустить Slipstream на MacBook
Установка повторяет процесс сборки llama.cpp с несколькими дополнительными флагами.
git clone https://github.com/slipstream-project/slipstream.git
cd slipstream
mkdir build && cd build
cmake .. -DGGML_METAL=ON -DSLIPSTREAM=ON
make -j8Флаг -DSLIPSTREAM=ON активирует модифицированный загрузчик весов и асинхронный I/O. Сборка занимает около двух минут на M3 Pro.
Для запуска нужна модель в формате GGUF. Подойдут стандартные квантованные версии с Hugging Face - Slipstream автоматически определяет MoE-архитектуру и применяет стриминг к экспертным слоям. Пример команды для Qwen3.6-35B-A3B:
./build/bin/slipstream-cli \
-m models/qwen3.6-35b-a3b-q4_k_m.gguf \
-c 4096 \
--slipstream-cache 8 \
--slipstream-prefetch 2 \
-p "Объясни разницу между MoE и dense-моделями"Ключевые параметры: --slipstream-cache задаёт число экспертов, удерживаемых в RAM (рекомендуется 6-10 для 36 ГБ); --slipstream-prefetch - количество экспертов для фоновой предзагрузки (значение 2 оптимально, больше создаёт лишний I/O). Мониторинг скорости включается флагом --slipstream-stats, который выводит ток/с, процент кэш-попаданий и объём прочитанных с SSD данных.
Выбор модели зависит от задачи. Для диалогов и оперативной работы - Qwen3.6-35B-A3B или аналоги с 3-5B активных параметров. Для пакетной генерации кода - Laguna 118B-A8B, как показали наши тесты сравнения точности агрессивной квантизации на MacBook и DGX Spark. Перед запуском крупной модели убедитесь, что на SSD достаточно места: модель плюс кэш слотов контекста могут занять на 20-30% больше заявленного размера GGUF-файла.