Энтузиаст запустил GLM-5.2 на ноутбуке с 25 ГБ RAM: без дистилляции, но на скорости от 0,05 токена в секунду

[Front-Den]

Владею ноутбуком на RTX 5080, 64Gb DDR5, 2Tb SSD, Ultra 9 275HX. Так вот под рукой всегда qwen3.6-35b-a3b - MoE модель, которая не требуя интернета достаточно быстро работает 65-85 т/с, в зависимости от контекстного окна. Очень помогает в рутинных повторяющихся задачах. Для основной работы есть подписка на Codex. Было бы здорово чтобы реально появилась возможность запускать такие модели как GLM 5.2, Kimi, DeepSeek в приемлемой скорости 10-20 т/с на таком железе. Учитывая двухсторонние ограничения РФ<>Европа/США, это даст хорошую опору и независимость от политоты и прочего. Надеюсь такие энтузиасты найдут способ это сделать. Moe 120b/20 (oss) уже получается запускать на 20+- т/с.

[mxr]

Можете привести пример задачи для которой вы используете 35b модель, всегда было интересно на что они годятся.

[Front-Den]

Да. Например десятки тысяч сообщений из выгрузки рабочих ТГ чатов, тикетов, задач в трекере очистить от мусора, дедуп, классификация. LLM чанкинг, составление графа и прочего, где не требуется сложная аналитика и мышление. Всё что требует тысяч вызовов к API платных моделей и что может решить локальная - делаю на локальной.

[malyazin_2010]

На мини-ПК с 128 гб озу gpt-oss120b работает чуть быстрее, около 30 ток/сек.

На макстудио 96гб озу 40-70 т/сек.

[jojozuka]

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

[VIOLIRA]

Красивое решение, и звёзды заслуженные. Отдельно зацепило, что задача решена не размером железа, а иерархией памяти: горячее ядро всегда в RAM, холодные эксперты на диске, а кэш учится на реальной нагрузке и закрепляет то, что пользователь реально дёргает. Я такую же иерархию построил этажом выше — в долговременной памяти AI-ассистента: маленький «всегда горячий» якорь в каждом промпте, холодные дневные архивы с подъёмом по ключу-дате, и ночная консолидация, которая решает, что горячее. Работает в ежедневном режиме уже который месяц. Инстинкт, похоже, один и тот же: вопрос не «сколько влезет», а «что держать под рукой». Автору удачи, и присоединюсь к просьбе про бенчмарки int4 — самый интересный открытый вопрос сейчас.

[slabnoff]

Не накидаете, что почитать о вашем подходе? Если не сложно, конечно

[VIOLIRA]

Конечно. Развёрнутая статья с разбором всех слоёв как раз лежит в песочнице Хабра — если модерация пропустит, будет здесь. А пока архитектурные заметки с датами выложены на GitHub: github.com/violira/eva-memory-bank — там шесть слоёв памяти (постоянный якорь личности, версионные факты, эпизоды, морфологический entity linker для склонений, дневные индексы, ночная консолидация), и отдельно K_INDEX_DISCLOSURE.md — про день как узел памяти первого класса с O(1) подъёмом по дате. Это не код, а декларации архитектуры, но подход из них понятен. Спасибо за интерес.

[qiper]

А если массив NVME дисков?

[m0xf]

llama.cpp тоже умеет работать напрямую с диска, используя mmap.