Летом 2026 года большие языковые модели наконец-то научились запускаться на железе, которое стоит под столом, а не в дата-центре

Летом 2026 года большие языковые модели наконец-то научились запускаться на железе, которое стоит под столом, а не в дата-центре. Замер, который расставляет всё по местам: модель на 2,8 триллиона параметров запустили на одном MacBook с M1 Max и 64 ГБ памяти. Скорость — примерно один токен в минуту. Первая реакция — «ну и зачем?» — самая простая и самая неправильная. Если разобраться, это лучший бесплатный учебник по иерархии памяти за последние годы.

Ситуация знакомая: приходит идея внутреннего ассистента по коду, доходишь до вопроса «а куда уходят данные» — и разговор заканчивается за пятнадцать минут. Дальше два пути: закрытый контракт с провайдером или своё железо. Только про своё железо в интернете написано либо «нужен кластер из восьми H100», либо «да всё прекрасно крутится на ноутбуке». Истина где-то посередине. «Своё железо» — это не бинарный выбор, а целая шкала возможностей, и почти никто не понимает, где именно на этой шкале стоит он.

Ключ ко всему — архитектура MoE, смесь экспертов. Вместо одной большой сети модель состоит из множества специализированных блоков, и маршрутизатор на каждом шаге выбирает лишь некоторые из них. Kimi K3, веса которой Moonshot выложила в конце июля, устроена так: 2,8 триллиона параметров всего, но на каждый токен активируются 16 экспертов из 896 на каждом слое. По оценкам, в вычислении участвует порядка 104 миллиардов параметров. Основная масса весов экспертов хранится в четырёхбитном формате MXFP4: числа пакуются по 4 бита, а на блок из 32 значений хранится один общий масштабный множитель. Это даёт примерно восьмикратную экономию против bf16 при контролируемой потере точности. Важная деталь: это не постфактум-квантование готового чекпойнта — модель обучали с учётом низкой точности начиная со стадии SFT, а часть весов вне экспертов остаётся в более высокой точности. Репозиторий на Hugging Face весит около 1,56 ТБ.

Модель делится на две очень разные по поведению части. Спина — эмбеддинги, слои внимания, общие эксперты, латентные проекции — работает на каждом токене всегда, это около 114 ГБ в bf16. Маршрутизируемые эксперты — 82 432 штуки, порядка 1,45 ТБ. На конкретном токене нужна крошечная доля, остальные лежат мёртвым грузом. И здесь частое заблуждение: малое число активных параметров снижает вычислительную стоимость токена, но не уменьшает объём, который надо где-то держать. Память определяется полным набором весов, вычисления — активным. Поэтому на ограниченном железе MoE превращает проблему из «как запихнуть всё в память» в другую: как организовать иерархию хранения и доставку выбранных экспертов. «Память» — не один уровень, а несколько с разницей в пропускной способности на порядки. Вопрос не в том, хватает ли её, а в том, через какой уровень на каждом токене приходится тащить рабочий набор весов.

На практике для локального запуска таких моделей встречаются три подхода. Первый — динамическое квантование. В конце июля команда Unsloth выпустила калиброванные динамические кванты K3. Слово «динамические» ключевое: большая часть весов уезжает в 1–2 бита, а чувствительные к квантованию тензоры получают более высокую битность. Однобитная сборка — около 594 ГБ против исходных 1,56 ТБ, при этом по замерам команды она удерживает примерно 78,9% от результата восьмибитного эталона на их наборе задач. Это относительная доля бенчмарк-скора, а не accuracy классификатора, и её нельзя переносить на свои задачи без проверки. Двухбитные сборки — 711 и 861 ГБ. Калиброванный квант и «слепой» квант — принципиально разные вещи. Ранние конверсии делались вслепую, потому что модель было не на чем прогнать для калибровки.

Второй подход — оффлоад экспертов в RAM. Это реально применимо на обычной рабочей станции. В llama.cpp есть флаг -n-cpu-moe N, который оставляет MoE-веса части слоёв в системной памяти, а остальной граф считает на видеокарте. Механизм рабочий, но оптимальные параметры зависят от версии llama.cpp, бэкенда и конкретного файла модели. Более тонкий контроль — через переопределение размещения тензоров. Однако этот механизм работает поверх реальных имён тензоров конкретного файла, а не абстрактных «слоёв». Раскладывать блоки по нескольким картам через регулярные выражения можно, но шаблон придётся строить под свою модель. Порядок действий такой: посмотреть фактические имена тензоров, начать со стандартного механизма, и только если его не хватает — браться за переопределения.

Третий подход — самый радикальный — стриминг. Не держать экспертов в памяти вообще, а подтягивать их с NVMe или по сети по мере обращения. Именно так работает история с ноутбуком. Проект называется Deltafin, автор задал честный абсурдный вопрос: можно ли запустить K3 на одном ноутбуке Apple Silicon? Схема такая. Спина скачивается один раз — те самые 114 ГБ — и опционально конвертируется в int8, что вдвое сокращает объём чтения на каждом токене. По проверкам автора порядок топ-5 кандидатов сохраняется, верхний логит смещается на 0,07%. Все 82 432 эксперта остаются на удалённом хранилище: на каждый токен маршрутизатор выбирает 16 штук на слой, и они докачиваются range-запросами в растущий локальный кэш. Со временем кэш вырастает до той части модели, которая реально используется. Под спину с её int8-копией нужно около 175 ГБ диска, плюс место под кэш — автор советует закладывать от 350 ГБ.

И вот что в проекте интереснее всего — приёмы, которыми автор отжимал эти минуты. Они узнаваемы для любого, кто оптимизировал работу с диском в бэкенде. Склеенное чтение: шесть тензоров каждого эксперта лежат подряд в файлах, автор проверил это для всех 82 432. Значит, эксперт вытягивается одним range-запросом на 17,55 МБ через пул keep-alive соединений. Измеренное ускорение — около 6,4 раза. Кэш сырых байт: файлы кэша содержат байты исходных шардов без обёртки, чтение через mmap. Двойная буферизация загрузки слоёв: отдельный поток читает данные следующего слоя, пока текущий считается. Префетч по маршруту предыдущего токена: соседние токены переиспользуют примерно 40% выбранных экспертов — замерено 39,7%, что близко к 41,3%, о которых сообщал другой проект для иной модели. Поэтому набор экспертов текущего токена фоном докачивается в расчёте на следующий. Это эвристика, которая достаточно часто угадывает, а не точное предсказание маршрута. Фьюзед gemv на NEON: распаковка MXFP4 и умножение в один проход через табличный поиск, вместо медленной связки «сначала распаковали, потом перемножили». На проверенных входах результат совпал с эталонной реализацией бит в бит. Переиспользование буферов через шаблонные слои: 69 слоёв KDA имеют одинаковую форму тензоров, а 24 слоя MLA — другую. Достаточно двух постоянно висящих на ускорителе «шаблонных» слоёв, в которые копируются веса. Профилирование показало, что возня аллокатора съедала заметную долю времени на токен.

Отдельно стоит уважение к тому, что автор опубликовал провалы. Низкоранговая аппроксимация экспертов не сработала — и это тоже часть учебника. Установившееся декодирование — 60–76 секунд на токен при прогретом кэше. Холодный кэш и длинный промпт дают совсем другие цифры. Но сам факт: модель на 2,8 триллиона параметров работает на ноутбуке, пусть и со скоростью один токен в минуту. Это не практичное решение для продакшена, зато идеальная демонстрация того, как работает иерархия памяти: VRAM, RAM, диск, сеть — и как доставка данных становится главным узким местом.

Для backend-инженера всё это не просто забавный трюк. Вопрос «а можно ли крутить это у нас внутри?» приходит не от датасайентистов, а от безопасности и юристов. Когда речь идёт о платёжном контуре, легаси-коде или любых чувстви

Телеграм: t.me/ainewsline

Источник: vk.com

Комментарии: