Как запустить LLM на 2,8 трлн параметров на ноутбуке

Всем привет, меня зовут Сергей Прощаев, и в этой статье расскажу про то, как летом 2026 года большие языковые модели научились запускаться на железе, которое стоит под столом, а не в дата‑центре, и что из этого может забрать себе обычный backend‑инженер.

Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce и преподаю на курсах разработки и архитектуры в ОТУС.

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

В конце июля появился замер, который расставляет это по местам: модель на 2,8 триллиона параметров запустили на одном MacBook с M1 Max и 64 ГБ памяти. Скорость — примерно один токен в минуту.

Первая реакция у меня была та же, что и у вас: ну и зачем? Ответ «низачем» — самый простой и самый неправильный. Я потратил вечер на разбор этого проекта и понял, что это лучший бесплатный учебник по иерархии памяти, который попадался мне за последние годы.

Почему это не праздное любопытство

Я не занимаюсь машинным обучением как основной работой. Но за последний год вопрос «а можно ли это крутить у нас внутри?» приходил ко мне трижды, и все три раза — не от датасайентистов, а от безопасности и от юристов.

Помню, как однажды мы разбирали идею подсказок по легаси‑коду для команды, которая работает с платёжным контуром. Задача звучала безобидно. Дошли до выгрузки репозитория во внешний API — и на этом всё закончилось. Репозиторий с логикой обработки транзакций наружу не поедет.

И вот тут выясняется, что «своё железо» — это не бинарный выбор. Это шкала, и почти никто не понимает, где именно он на ней стоит.

Арифметика, которая делает трюк возможным

Ключ ко всему — архитектура MoE (Mixture‑of‑Experts, “смесь экспертов”): вместо одной большой сети модель состоит из множества специализированных блоков, и маршрутизатор на каждом шаге выбирает лишь несколько из них.

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

Модель делится на две очень разные по поведению части:

• Спина — эмбеддинги, слои внимания, общие эксперты, латентные проекции. Работает на каждом токене, всегда. Около 114 ГБ в bf16. Термин «spine» не официальный из архитектуры K3, это обозначение из проекта, о котором пойдёт речь ниже, но оно удобное.

• Маршрутизируемые эксперты — 82 432 штуки, порядка 1,45 ТБ. На конкретном токене нужна крошечная доля, остальные лежат мёртвым грузом.

Сразу оговорюсь про частое заблуждение. Малое число активных параметров снижает вычислительную стоимость токена, но не уменьшает объём, который надо где‑то держать. Память определяется полным набором весов, вычисления — активным. Поэтому на ограниченном железе MoE не отменяет проблему, а превращает её в другую: как организовать иерархию хранения и доставку выбранных экспертов. Схематично это показано на рис. 2.

Уточню про первый уровень: на машине с дискретной картой это VRAM, отделённая от системной памяти шиной PCIe. На Apple Silicon процессор и графика делят одну физическую память, и копирования между уровнями там нет — есть только разница в том, что успело осесть в резидентной памяти, а что читается с диска.

Главная мысль этой схемы: «память» — не один уровень, а несколько с разницей в пропускной способности на порядки, и вопрос не в том, хватает ли её, а в том, через какой уровень на каждом токене приходится тащить рабочий набор весов.

Три способа уместить гиганта

На практике для локального запуска таких моделей встречаются три подхода. Это моя классификация, а не отраслевой стандарт.

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

Мне как‑то попалась мысль, которая хорошо описывает суть: калиброванный квант и «слепой» квант — принципиально разные вещи. Ранние конверсии делались вслепую, потому что модель было не на чем прогнать для калибровки.

Оффлоад экспертов. Это то, что реально применимо на обычной рабочей станции. В llama.cpp есть флаг ‑n‑cpu‑moe N, который оставляет MoE‑веса части слоёв в системной памяти, а остальной граф считает на видеокарте. Механизм рабочий, но его поведение и оптимальный набор параметров зависят от версии llama.cpp, бэкенда и конкретного файла модели, поэтому фактическое распределение стоит сверять с выводом загрузчика при старте.

Пример команды (bash). Он показывает механику флага на модели среднего размера и не является командой запуска Kimi K3 — её на одной карте не запустить:

./llama-server \
  --model qwen3.6-35b-a3b-IQ4_NL.gguf \
  --n-gpu-layers 99 \
  --n-cpu-moe 24 \
  --ctx-size 16384 \
  --flash-attn

Более тонкий контроль — через переопределение размещения тензоров (bash):

# иллюстративный пример: отправить все маршрутизируемые
# эксперты в системную память
--override-tensor "exps=CPU"

Скажу прямо: этот механизм работает поверх реальных имён тензоров конкретного файла, а не абстрактных «слоёв». Раскладывать конкретные блоки по нескольким картам через регулярные выражения можно, но шаблон придётся строить под свою модель, глядя на её имена тензоров. Мой порядок такой: посмотреть фактические имена, начать с --n-cpu-moe, и только если стандартного механизма не хватает — браться за переопределения.

Стриминг. Самый радикальный вариант — не держать экспертов в памяти вообще, а подтягивать их с NVMe или по сети по мере обращения. Именно так работает та самая история с ноутбуком.

История, которая расставила всё по местам

Проект называется Deltafin, лежит на GitHub у gavamedia. Автор задал абсурдный вопрос честно: можно ли запустить K3 на одном ноутбуке Apple Silicon? Дальше я разбираю состояние репозитория на начало августа 2026 года — проект развивается, поэтому цифры и механизмы относятся к этому срезу, а не к последнему коммиту на момент, когда вы это читаете.

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

Что получилось по скорости:

Уточню, потому что это часто путают: 60–76 секунд — установившееся декодирование при прогретом кэше, а не время ответа на запрос целиком. Холодный кэш и длинный промпт дают совсем другие цифры.

И вот что мне понравилось больше всего — приёмы, которыми автор эти минуты отжимал. Они узнаваемы для любого, кто оптимизировал работу с диском в бэкенде:

• Склеенное чтение. Шесть тензоров каждого эксперта оказались лежащими подряд в файлах — автор проверил это для всех 82 432. Значит, эксперт вытягивается одним range‑запросом на 17,55 МБ через пул keep‑alive соединений. Измеренное ускорение — около 6,4 раза.

• Кэш сырых байт. Файлы кэша содержат байты исходных шардов без обёртки, чтение через mmap.

• Двойная буферизация загрузки слоёв. Отдельный поток читает данные следующего слоя, пока текущий считается.

• Префетч по маршруту предыдущего токена. Соседние токены переиспользуют примерно 40% выбранных экспертов — замерено 39,7%, что близко к 41,3%, о которых сообщал проект colibri для другой модели. Поэтому набор экспертов текущего токена фоном докачивается в расчёте на следующий. Это эвристика, которая достаточно часто угадывает, а не предсказание маршрута.

• Фьюзед gemv на NEON — распаковка MXFP4 и умножение в один проход через табличный поиск, вместо медленной связки «сначала распаковали, потом перемножили». На проверенных автором входах результат совпал с эталонной реализацией бит в бит.

• Переиспользование буферов через шаблонные слои. В реализации Deltafin 69 слоёв KDA имеют одинаковую форму тензоров, а 24 слоя MLA — другую. Значит, достаточно двух постоянно висящих на ускорителе «шаблонных» слоёв, в которые копируются веса. Профилирование показало, что возня аллокатора съедала заметную долю времени на токен.

Отдельно уважаю то, что автор опубликовал провалы. Низкоранговая аппроксимация экспертов не пошла: ранг 128 захватывает лишь около 13% энергии, общего подпространства у экспертов нет. Сжатие файлов бесполезно — энтропия полезной нагрузки MXFP4 составила 7,51 бита на байт. HTTP/2 в этом сценарии проиграл HTTP/1.1 с keep‑alive. Тензорный параллелизм на двух маках не сходится по арифметике. А переход на fp16 по умолчанию дал около 0,1 логитного шума — достаточно, чтобы переворачивать близкие по вероятности токены и нарушать бит‑в‑бит воспроизводимость. Могу себе представить, сколько вечеров ушло на каждый из этих пунктов.

Где на самом деле узкое место

Теперь то, ради чего всё затевалось. У инференса две фазы с разным профилем нагрузки.

Префилл — чтение промпта — обычно лучше утилизирует вычислительные блоки. Декодирование при малом батче часто упирается в эффективную пропускную способность памяти.

Слово «часто» здесь не для смягчения: соотношение зависит от батча, длины последовательности, архитектуры, квантования, ядер и железа.

В режиме одиночного запроса эффект хорошо заметен. В опубликованном сравнении на модели gpt‑oss 120B AMD Ryzen AI Max+ 395 показал около 34,13 токена в секунду, NVIDIA DGX Spark — 38,55, при пропускной способности памяти 256 против 273 ГБ/с.

На префилле в том же сравнении разрыв уже пятикратный: примерно 340 против 1723 токенов в секунду.

А три подержанных RTX 3090 в одной машине выдали 124 токена в секунду на генерации — просто потому, что суммарная полоса GDDR6X принципиально другая.

Все три цифры относятся к одному сценарию, одной модели и одному бэкенду; переносить их на свою нагрузку без собственного замера нельзя.

Отсюда правильная формулировка: при memory‑bound декодировании разница между системами может оказаться заметно меньше, чем разница в их цене и вычислительной мощности.

Но пример с тремя 3090 показывает, что это не универсальный закон — меняется тип памяти, меняется результат. И паспортная пропускная способность не равна фактической.

Хорошая иллюстрация разницы между плотной и разреженной архитектурой: плотная Llama 3.3 70B на этих коробках еле ползёт, порядка 2,6 токена в секунду, а разреженная Qwen3-Next 80B‑A3B с тремя миллиардами активных параметров идёт под 59.

Разница не в размере, а в архитектуре.

И то, о чём забывают при планировании памяти: веса — не единственный потребитель. С ростом контекста растёт объём KV‑кэша, и отдавать весь доступный объём под модель нельзя.

Если модель уже близка к лимиту, сокращение контекста часто оказывается самым дешёвым первым рычагом. Если же не помещаются сами веса, контекстом делу не поможешь — нужен оффлоад или более агрессивное квантование.

Сводно по режимам запуска:

Практики, к которым сходятся команды

Порядок действий при выборе конфигурации показан на рис. 3.

Главная мысль этой схемы: --n-cpu-moe нельзя считать монотонным параметром, его подбирают развёрткой под конкретную модель, карту, объём RAM и контекст.

На многих конфигурациях получается характерная картина: пока модель не помещается — всё катастрофически медленно, максимум оказывается где‑то рядом с границей, где она ещё работает без активного давления на память, дальше идёт деградация.

Один владелец RTX 5090 опубликовал развёртку: 54 токена в секунду при значении 20, затем 64,5 при 16, затем 69,4 при 12 — и обвал до 27,5 ещё на шаг ниже. Край не подписан, вы просто в него въезжаете.

Что ещё стоит забрать:

• Считайте активные параметры для вычислений, а полные — для памяти. «Модель на 235 миллиардов на мини‑ПК» звучит громко, но там 22 миллиарда активных, квантование Q3, около 101 ГБ на диске и порядка 11 токенов в секунду.

• Помните про перекос маршрутизации. В трассах, которые разбирали контрибьюторы llama.cpp, небольшая доля экспертов обслуживала непропорционально большую часть токенов. Отсюда идея держать горячих экспертов ближе к ускорителю между шагами вместо того, чтобы гонять одно и то же по шине каждый токен. Насколько сильный перекос будет у вас — зависит от модели и от нагрузки.

• Мерьте на своём трафике. Разница между агрессивной и мягкой сборкой всплывёт именно на ваших сложных кейсах, а не на публичном бенчмарке.

Ограничения: где я бы не стал этого делать

Скажу прямо: ничего из описанного не является продакшеном.

Сервер Deltafin держит один запрос за раз, на второй отвечает 429. Таймауты клиента приходится ставить в часах. Температура и top‑p принимаются и игнорируются, декодирование только жадное.

Чат на холодном кэше особенно тяжёл: шаблон занимает шестьдесят с лишним токенов, а префилл трогает много экспертов на каждом слое, поэтому первый запрос может часами качать веса.

Это стенд, а не сервис.

Оффлоад экспертов в RAM — рабочая история, но и она проседает на длинном контексте. Владелец коробки на 128 ГБ фиксировал 20 токенов в секунду на пустом контексте и 5–10 к отметке в 30 тысяч токенов.

Где мой вывод не универсален.

Всё сказанное про полосу памяти относится к генерации в один поток. При росте батча арифметическая интенсивность увеличивается, ограничение по памяти ослабевает, зато на первый план выходят KV‑кэш и планировщик — однопоточный замер нельзя переносить на серверную нагрузку напрямую.

Для плотных моделей оффлоад тоже возможен, но обходится существенно дороже: каждый токен требует обращения к гораздо большей доле весов, и преимущество разреженности исчезает.

И отдельно про лицензии, это важнее, чем кажется.

Код Deltafin — MIT, а вот веса K3 распространяются под отдельной лицензией Moonshot, которая не является ни MIT, ни её модифицированной версией.

Там есть коммерческие пороги: в частности, если совокупная выручка лицензиата и его аффилированных лиц от бизнеса «модель как сервис» превышает 20 миллионов долларов за любые последовательные двенадцать месяцев, требуется отдельное соглашение с Moonshot.

Файл LICENSE в репозитории надо открыть и прочитать глазами, а не полагаться на то, что было в предыдущих версиях модели.

Что проверить у себя на этой неделе

Мой вариант, который я обычно предлагаю коллегам, когда разговор упирается в «а можно ли у нас локально»:

• Взять MoE‑модель среднего размера с 3–4 миллиардами активных параметров и запустить на рабочей машине с оффлоадом экспертов. Это полчаса.

• Сделать развёртку по ‑n‑cpu‑moe в пять точек и построить свою кривую. Максимум окажется не там, где вы ждёте.

• Замерить отдельно префилл, установившееся декодирование и время до первого токена. Это три разные цифры, и решение о железе принимается по той, что соответствует вашему сценарию.

• Повторить замер на контексте, близком к рабочему, чтобы увидеть вклад KV‑кэша.

• Прогнать 20–30 реальных запросов из своей предметной области и сравнить с облачной моделью. Не бенчмарк, а ваши запросы.

После последнего пункта разговор с безопасностью становится предметным: у вас на руках цифры, а не общие рассуждения.

Заключение: это эксперимент про память, а не про AI

Deltafin не доказывает, что локальный запуск победит дата‑центры. Автор сам называет это исследовательским артефактом. Он доказывает другое: за красивой цифрой «триллион параметров» стоит вполне обычная инженерная задача про иерархию хранения, последовательное чтение и префетч. Те же приёмы, которыми мы годами разгоняли работу с диском в бэкенде, работают и здесь один в один.

Как и предполагал, самым полезным в этой истории оказались не минуты на токен, а список того, что не сработало. Ранг 128 не ловит структуру экспертов, MXFP4 не сжимается, HTTP/2 проигрывает, fp16 рушит воспроизводимость на близких токенах. Это карта тупиков, за которую кто‑то заплатил своими вечерами.

Если у вас есть свой опыт запуска больших MoE на потребительском железе — особенно неудачный, с цифрами — напишите в комментариях. Отрицательный результат в этой теме сейчас ценнее очередного скриншота с бенчмарком.

Если хочется попробовать локальные LLM у себя, но пока непонятно, с какой модели начать, сколько памяти понадобится и где искать реальные ограничения железа, можно начать с бесплатных уроков OTUS. На них разберём механику работы и локального запуска LLM, чтобы перейти от экспериментов «запустилось / не запустилось» к осознанному выбору модели и конфигурации под свои задачи.

• 3 сентября, 20:00. «Локальные LLM модели для разработки». Записаться

• 8 сентября, 20:00. «Что надо знать про работу LLM моделей». Записаться

Полный список бесплатных уроков августа смотрите в дайджесте.