Как я провёл вечер с диспетчером задач, логами и моделью на 4B параметров. Выяснил, что убивает память на самом деле. И нашёл способ увеличить количество сессий без покупки новой видеокарты.
1. Вступление: с чего всё началось
Я сидел вечером за компьютером, пил чай и смотрел на диспетчер задач. Потом переключался на логи LM Studio. Потом снова на диспетчер задач. Потом — на выводы OpenClaw.
В моей голове постепенно возник вопрос, как так получается, что одна и та же ЛЛМ тратит разное количество RAM и VRAM независимо от сложности задач?
Я заметил: иногда модель начинает медленней генерировать токены или странно себя вести, хотя контекст ещё не заполнен. А иногда — летает как ракета, даже когда контекст уже под 120K.
Что-то было не так.
Интуитивно я увидел закономерность, тогда и решил — хватит гадать. Пора ставить эксперимент.
И я его поставил.
2. Среда обитания нашего подопытного
Для чистоты эксперимента расскажу, на чём всё крутилось.
- Модель - nvidia/nemotron-3-nano-4b (4B параметров — малышка, но боевая)
- Платформа - LM Studio (родной интерфейс, который я обожаю за простоту и функциональность)
- Агент - OpenClaw 2026.4.20 (сборка свежая, стабильная)
- ОЗУ - 32 гб, норма, но не фонтан
- VRAM - 8 ГБ на RTX 4060 — тут вообще всё на грани
- Контекст модели - 131072 токена (стандартный рабочий, под исследовательские задачи можно на 800К выкрутить)
- Parallel slots - 4 слота (параметр означающий допустимое количество параллельных генераций)
Почему Nemotron? Потому что модель относительно лёгкая и очень быстрая. Её скорость даже на процессорных тестах довольно высока. В квантизации Q8_0 модель спокойно помещается в памяти RTX 4060 и обладает очень хорошей скоростью генерации. В среднем 50 токенов в секунду при четырёх активных параллелях, завидная оптимизация -идеальный подопытный.
Кто не знаком с параметрами квантизации моделей может изучить мою статью простым языком за пять минут объясняю сложные термины.
Читать 👉 https://dzen.ru/a/aeHUcvywjFy782ef
3. Первая фаза: большие задачи — и никаких проблем
Я начал с того, что дал модели тяжёлые задачи.
Не «напиши стишок», а реальные приложения: шифровальщик с графическим интерфейсом, многопользовательский чат-сервер, парсеры данных. В общем, то, на что у профессионала ушёл бы минимум час, а модель сделала за пару минут.
Характер генераций:
- На каждую задачу уходило 1–2 генерации
- Но каждая генерация была огромной — до 50K токенов
- Модель писала код, объясняла, поправляла себя
Мои наблюдения за диспетчером задач:
Ключевые наблюдения на этом этапе. ОЗУ стояла на месте. VRAM тоже. Модель как будто говорила: «Ну что ты смотришь? Я сделала своё дело, память не трогала».
Память практически не росла.
Я сначала подумал: «Может, глюк?» Но нет. Модель просто один раз аллоцировала KV-кэш и больше к нему не возвращалась. Она писала, писала, писала — а память стояла как вкопанная.
Первый вывод, который возник у меня в голове:
«Объём одной генерации оказывает минимальное влияние на затраты памяти»
4. Вторая фаза: много маленьких задач — и память поползла
Смена подхода дала любопытные результаты.
Я перешёл к задачам, где модель должна была использовать инструменты. Веб-поиск. Открыть страницу, прочитать, проанализировать, сравнить, выдать результат.
Характер генераций:
- На один мой запрос уходило 3–5 генераций
- Но каждая генерация была маленькой — 1.5–30K токенов
- Поиск → извлечение → анализ → сравнение → ответ
Мои наблюдения:
Вот тут я испытал восторг!
Память поползла! Сначала медленно. Потом быстрее. Каждый вызов инструмента — каждая маленькая генерация — съедала кусочек.
Я смотрел на диспетчер задач и видел, как цифры растут, хотя токенов стало меньше. Намного меньше, чем когда модель писала приложения.
Меня осенило!
Второй вывод:
«На затраты памяти сильно влияет количество генераций»
Каждая генерация требует выделения новых буферов в памяти. Даже если токенов мало. А если вызовов много — память разрастается как снежный ком.
- Сто раз напиши ЛЛМ - Привет! - и она займёт всю память на ПК сгенерировав минимум токенов.
5. Третья фаза: длительная сессия — и модель начала чудить
Для полноты картины требовалось идти до конца.
Я дал модели 15 разнородных задач подряд. Без перерыва. Без отдыха. Пусть крутится.
Что же ей скормил:
- Сравнение товаров на маркетплейсах;
- Анализ регулирования ИИ в разных странах;
- Подбор комплектующих для ПК под бюджет;
- Построение туристического маршрута;
- И ещё кучу всего.
Что произошло:
К 57–65 генерациям я заметил, что система начала активно работать на пике. Она как будто устала.
- Скорость генерации уменьшилась на 7-10 токенов в секунду
- Начались параллельные генерации
- Не смотря на работу в пике качество ответов осталось на высоте, что радует
- К 65 генерации когда память раздуло до масштабов кратно превышающих саму ЛЛМ началась заметная экономия токенов в ответах
Я посмотрел на контекст: 521% от лимита. 683K токенов при лимите 131K. Сработал rollingWindow и compact — модель начала забывать начало диалога и сжимать его, контекст выровнялся до 64К токенов.
Но самое интересное было не в этом. Финальное наблюдение позволившее разработать стратегию оптимизации памяти было сделано на следующем этапе.
6. Момент озарения: перезагрузил модель — память упала
Когда контекст выровнялся до 64К затрачиваемая моделью память изменилась всего на пару гигабайт. Моё более раннее предположение что контекст имеет меньшее влияние на память чем количество генераций обрело дополнительную силу.
Я запросил проверку статуса, выгрузил в ручную модель из памяти и загрузил обратно. Результат меня ошарашил:
- До выгрузки - контекст 64К, одно сжатие контекста, память 8.9 ГБ RAM + 6.9 VRAM;
- После выгрузки и загрузки обратно - контекст 64К, одно сжатие контекста, память 4.69 ГБ RAM + 6.9 ГБ VRAM
Контекст сохранился полностью, модель помнила всё что мы обсуждали ранее, но память упала.
Третий вывод:
«Модель сбросила счётчик генераций. И прошлую логику. Память освободилась, а знания остались.»
Это был ключ. Самый важный момент всего эксперимента.
7. Финальный вывод, стратегия оптимизации
Эксперимент показал - что основным фактором, влияющим на затраты памяти является количество генераций, а не их качество.
Десять маленьких генераций с выводом по 500 токенов потратят в два раза больше памяти чем одна генерация размером 5К токенов.
Всё потому что модель поверх контекста записывает всю свою логику рассуждений все вызовы инструментов и множество других данных, которые расходуют огромное количество памяти.
Особенно сильно эти затраты видны когда ЛЛМ работает в формате Агента, который занимается кодингом, личным ассистированием или другими агентными задачами.
Простейшая стратегия оптимизации памяти заключается в ограничении числа генераций, после которого наступает перезагрузка для сброса ненужных данных
Модель уже хранит важнейшую логику рассуждений внутри выделенного контекстного окна, всё что сверху может быть безопасно забыто.
При использовании простейших сценариев интеграции ЛЛМ в свои сервисы для ведения чатов достаточно настроить автоматическую выгрузку модели из памяти после 60 минут простоя если вы единственный пользователь - это сильно сэкономит ресурсы хоста.
При использовании сложных сценариев интеграции в системы где происходит регулярный контроль стабильности соединения с ЛЛМ API важно настраивать правильные политики работы с контекстом, размеры контекстного окна, алгоритмы сжатия и оптимизации.
Чаще всего Агентные системы и Оркестраторы не поддерживают передачу флага Max idle TTL (параметр разрешающий выгрузить модель через n минут простоя), что вызывает необходимость разработки отдельных модулей контролирующих количество генераций.
Разработчики Агентов и Оркестраторов ещё не обратили внимание на оптимизацию памяти вне их систем, что видно по отсутствию ключей позволяющих передать нужные параметры модели при её загрузке.
Тем не менее при стандартных интеграциях в качестве чат ботов даже неопытный пользователь сможет оптимизировать затраты памяти таким методом, что может кратно увеличить количество пользователей без апгрейда железа.
Будущее ИИ не только в увеличении вычислительных мощностей ЦОД, а ещё и в оптимизации!
8. Подписывайтесь!
Если хотите следить за экспериментами «Локального мозга» — залетайте:
👉 ВК: https://vk.com/local_mozg
👉 Дзен: https://dzen.ru/lokal_mozg
В следующих статьях:
- как настроить параллельные слоты в LM Studio на практике
- сколько пользователей реально тянет RTX 4060
- бенчмарк моделей: Nemotron vs Qwen vs Gemma на количество генераций
Прохор
Инженер приватных AI-систем
🧷 Теги для Дзена
#LLM #память #оптимизация #LMStudio #OpenClaw #эксперимент #локальныйИИ #ЛокальныйМозг