Знаете это чувство, когда читаешь статью про локальные LLM и думаешь: «А, ну это же просто. Поставлю Ollama, тяну модель, и у меня уже свой ИИ-агент, который знает весь код»?

Я думал именно так.

Меня зовут Егор Лаптев, я QA Fullstack Java в SENSE на проекте крупного российского банка. У меня MacBook Pro M2 Pro с 32 ГБ RAM: не topical машина, но для разработки рабочая лошадка. Даже не подозревал, что через 20 минут после запуска модели ноутбук будет звучать как истребитель на взлёте, а температура процессора будет такой, что можно было бы варить яичницу на крышке.

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

Две команды в терминале

Всё началось с двух команд в терминале:

ollama pull qwen-coder:3.5-72b

ollama run qwen-coder:3.5-72b

Модель — Qwen Coder 3.5, 72 миллиарда параметров, а по меркам LLM это уже тяжёлый класс. В интернете пишут: «72B — это для воркстейшнов, тебе нужен сервер с 128 ГБ». Но Ollama с агрессивным квантованием до Q2_K (~26 ГБ) «вмещает» модель в 32 ГБ, так что технически она влезает, если сжать её до состояния, при котором она сама начинает сомневаться в своём интеллекте.

Да, я знаю, что вы сейчас подумали: «Q2_K? Это же каша из токенов, любая логика умирает». И вы правы, но цель была проверить, заведётся ли вообще 72B на ноутбуке, а эксперимент — не продакшн. Для реальной работы я бы взял Qwen 2.5 7B или 14B в Q4_K_M или Q8, а это 90% качества при трети ресурсов. Но тогда бы не было этой статьи.

Не стал ничего настраивать: никаких лимитов или ограничений GPU. Просто ollama run и поехали.

Вентилятор заорал

Ollama забрал всю доступную RAM, все 32 ГБ: 32 гигабайта, и он сожрал ВСЕ. macOS начала активно использовать swap, и диск начал гудеть как стиральная машина на отжиме, а CPU и GPU (у нас же unified memory, так что это одно и то же) стояли на 100% весь период инференса. Вентилятор заорал, а всё остальное на машине стало неюзабельным: браузер лагал, IDE зависала, даже ls в терминале отвечал с задержкой. Через несколько минут включился thermal throttling, и система начала принудительно снижать частоты, чтобы не сгореть.

Кто-то скажет: «Да macOS не даст одному процессу забрать всю память». И будет прав: по умолчанию есть лимит ~70-75% от общего объёма RAM для GPU. Но Ollama + macOS в связке с 72B моделью ушли в жёсткий своп: модель не влезала в отведённые 75%, и macOS начала активно писать и читать на SSD. А это медленная смерть для диска: постоянная нагрузка на NAND-ячейки, нагрев, деградация. MacBook страдал не только от CPU/GPU, но и от того, что SSD работал на износ.

Я смотрел на Activity Monitor, где все графики были красными, и подумал: «Больше похоже на запуск ракеты, чем на деплой агента». Каким-то чудом ноутбук выжил, но я понял, что так продолжаться не может.

Пытаемся спасти ситуацию: лимит памяти

Первым делом я поставил лимит на память: пусть модель работает в отведённом бюджете, а остальное достанется системе и моим окнам. 4096 MB, как советовали в туториалах, не сработали: 72B in Q2_K весит ~26 ГБ, и в 4 ГБ она просто не влезает, Ollama честно сообщал об ошибке загрузки. Пришлось поднять лимит до 28 ГБ, ровно чтобы модель влезла, и ни гигабайтом больше. У меня 32 ГБ, а модель мучается в 28. Звучит как издевательство, но это единственное, что позволяло ноутбуку не перегреться.

# В конфиге Ollama или через переменные окружения

OLLAMA_NUM_PARALLEL=1

# Лимит памяти через системные настройки macOS

В итоге модель отвечает, а скорость инференса при этом упала до 1-2 токенов в секунду (для сравнения, на RTX 4090 та же модель выдаёт 10-15 tok/s).

Что это значит на практике? Простой запрос «напиши функцию для парсинга JSON» заставляет ждать минуту-две, пока модель генерирует ответ. Токены приходят по одному-два, буква за буквой, как будто кто-то печатает на машинке 1985 года.

Оно живое. Но живое как черепаха. Разница между двумя режимами видна в таблице.

Параметр

Без лимита

С лимитом 28 ГБ

RAM usage

28-32 ГБ (всё)

~28 ГБ

Скорость

~3-4 tok/s (до троттлинга)

~1-2 tok/s

Юзабилити

MacBook неюзабелен

Работает, но медленно

Температура

95°C+

~85-90°C

Для экспериментов, конечно, терпимо, но для ежедневной работы точно нет.

Переезд на ПК, который теперь работает на агента

Решение было очевидным: нужен ПК уровня рабочей станции.

Спеки, которые у меня были в наличии:

  • GPU: RTX 4070 Ti Super 16GB

  • RAM: 32 ГБ DDR5

  • SSD: 2TB NVMe Gen4

  • CPU: Intel Core i5-13600KF

72B в Q2_K (~26 ГБ) не влезает в 16 ГБ видеопамяти целиком, часть весов живёт в оперативке, и это заметно. Но модель на этом железе работает:

  • 5-8 токенов в секунду — ответ на простой запрос генерируется за 10-20 секунд

  • Можно держать открытыми IDE, браузер, терминал — всё работает

  • GPU не в 100%, а в 60-70% при инференсе

Звучит идеально, правда? Но теперь, когда я запускаю агента:

  • GPU сидит на 80-90% во время инференса

  • Играть в AAA-тайтлы — невозможно (GPU занят)

  • Монтировать видео — можно, но медленно (конкуренция за VRAM)

  • ПК теперь на 50% ИИ-сервер и на 50% личный компьютер

Оно живое и быстрое, но мне немного жаль личный ПК: он теперь работает на меня 24/7, а я не могу даже поиграть в Cyberpunk без того, чтобы сначала остановить агента.

RAG-база: кошелёк начинает нервничать

И вот тут начинается самое интересное. Потому что модель, которая просто генерирует текст, ещё не агент. Агент — это модель + контекст. А контекст — это RAG (Retrieval-Augmented Generation).

Мне хотелось, чтобы агент знал мой домен: код, доки, процессы, тикеты, чаты. Для этого я начал собирать RAG-пайплайн: векторная база + эмбеддинги + retrieval. И вот тут я сел посчитать, а сколько это всё вообще весит.

Расчёт: сколько нужно для «полного» покрытия домена

Исходные данные:

  • Средний документ: 10-50 страниц

  • Размер чанка: 500 токенов (~350 слов)

  • Размерность эмбеддинга: 1536 или 4096

Масштаб

Документов

Страниц

Чанков

Хранение

Личный проект

500

10,000

14,000

~200 MB

Внутренние доки

50,000

1,000,000

1,400,000

~20 GB

Полный домен

500,000

10,000,000

14,000,000

~200 GB

Enterprise-grade

5,000,000+

100,000,000+

140,000,000+

~2 TB

И это только векторная база, давайте ещё приплюсуем к ней:

  • Веса модели: 32B в FP16 = 64 ГБ, в FP32 = 128 ГБ

  • Данные для fine-tuning + состояния оптимизатора: ×3-4

  • Структуры индекса: HNSW-графы добавляют 30-50% overhead

В сумме получим, что реалистичный footprint для «полностью обученного» личного агента — это 2-4 ТБ.

Show me the money: сколько стоит агент целиком

Считаем железо, которое нужно для локального агента:

Компонент

Минимум для агента

Стоимость (ориентир)

GPU (24GB+ VRAM)

RTX 4090 / A5000

$4,500

RAM (64GB+)

DDR5 64GB

$500

Storage (4TB NVMe)

4TB Gen4 SSD

$500

CPU (16+ cores)

Ryzen 9 / i9

$600

БП, корпус, охлаждение

1000W+

$400

Итого

$6,500

Плюс электричество:

  • RTX 4090 превращает ~350W под нагрузкой

  • 8 часов в день = ~2.8 кВт·ч/день

  • В год: ~$100-180

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

Когда локально, а когда облако

Раз расчёт вышел таким, остаётся решить, что запускать локально, а что в облаке. Однозначного ответа тут нет: многое зависит от того, какое у вас железо, насколько чувствительны данные и нужен ли агенту аптайм 24/7. Ниже условия, при которых я бы выбрал тот или другой вариант.

Когда локально имеет смысл:

  • У вас уже есть мощное железо (воркстейшн, игровой ПК с 24GB+ VRAM)

  • Вам нужна конфиденциальность (чувствительный код, внутренние доки, данные клиентов)

  • Вы экспериментируете и не нужен 24/7 аптайм

  • Модель маленькая (7B-14B) и задача не требует глубокого рассуждения

Когда облако / корпоративная инфраструктура лучше:

  • Нужна скорость и постоянная доступность

  • Нужен полный RAG-пайплайн на масштабе (миллионы чанков)

  • Не хотите обслуживать железо (апгрейды, замена, охлаждение)

  • Стоимость инференса в облаке часто ниже амортизированной стоимости железа

Sweet spot: гибридный подход

Задача

Где

Почему

Быстрые задачи, приватность

Локально (7B)

Дёшево, быстро, данные не уходят

Сложное рассуждение, генерация

Облако (70B+)

Качество, скорость, масштаб

RAG на больших данных

Облако

200GB+ не потянет локально

Fine-tuning

Облако / GPU-кластер

Состояния оптимизатора ×4

Используйте MacBook для того, что он умеет. А облако — для того, что он не умеет.

Ноутбук цел, а счёт остался

MacBook жив и полностью в порядке. Один троттлинг ещё не болезнь, просто macOS снизил частоты, чтобы не перегреться. Вреда и последствий нет. Живёт, работает, как и раньше, разве что иногда чуть сильнее греется под нагрузкой, но, как уже понял, это не про LLM.

Если считать целиком, цена локального ИИ складывается из четырёх частей:

  • Железо: $3000-6500 (или личный ПК, который теперь сервер)

  • Электричество: $100-180/год (мало, но это не ноль)

  • Время: настройка, отладка, мониторинг, апгрейды

  • Ограничения: личное устройство теперь работает на агента

Но опыт того стоил. Теперь я знаю, что 7B-14B можно держать на своём железе, а RAG на сотни гигабайт и дообучение лучше отдать облаку.

А вот терпение закончилось: ждать минуту на каждый ответ я не хочу.

Если вы думаете «а я просто запущу на своём ПК», загляните в блок «RAG-база» и посчитайте, прежде чем решать.

Какую модель вы запускаете локально, на каком железе и что вас остановило? Давайте обсудим в комментариях. 

Комментарии (13)


  1. ToxaBes
    05.11.2026 13:33

    qwen-coder:3.5-72b

    Зачем, если есть "такая же но меньше и новее" Qwen3.8-27B в Q4/Q5 от Unsloth или подобные, что влезет.

    С расчетами RAG на миллионы документов и весом модели в FP16/FP32 посмеялся в голос, повеселили, спасибо.


    1. Egor1301 Автор
      05.11.2026 13:33

      Да, на сто процентов правы. Я и в самой статье пытался подсветить, что это эксперимент из серии «заведется ли вообще 72B на ноуте», а не готовый рецепт для продакшна. Понятно, что для нормальной работы я бы сам взял 7B–14B в квантовании Q4/Q5. А 72B в Q2_K на 32 ГБ оперативки — это не инструкция «как надо», это чистый фан и проверка границ. Статья скорее про личный опыт и грабли, а не про строгий гайд.

      По поводу расчетов для RAG — отлично понимаю, почему они вызвали улыбку) Там цифры действительно грубые, но задача была не выдать точную спецификацию под конкретный проект, а просто показать порядок величин. Когда прикидываешь 14 млн чанков × 1536 dim × 4 байта, получаешь ~86 ГБ чисто под вектора. Докидываем сюда оверхед от HNSW, индексы — и сразу понятно, почему идея «запущу-ка я локальный RAG на всем домене на домашнем ноуте с 32 ГБ» разбивается о суровую реальность. На таком железе это максимум 500 документов. Если этот пример помог запомнить, что под доменный RAG нужно совсем другое железо, то цифры свою задачу выполнили.

      Ну а фраза «я проверял, когда ещё 3.8 не вышла» — это вообще до боли знакомо, пожалуй, самый жизненный момент. Мы сейчас все в этой лодке: только настроил пайплайн, потратил кучу времени, а через месяц выходит новая модель и все твои костыли превращаются в тыкву. Это, кстати, один из главных плюсов облака — там ты просто переписываешь одну строчку в конфиге, а не пересобираешь всё руками с нуля.

      В любом случае — спасибо за фидбек, с такими уточнениями дискуссия выходит гораздо интереснее!


      1. ToxaBes
        05.11.2026 13:33

        Попробуйте еще модель из моего комментария вот тут.

        На таком железе это максимум 500 документов. Если этот пример помог запомнить, что под доменный RAG нужно совсем другое железо, то цифры свою задачу выполнили.

        Дело в том, что ваши цифры оторваны от реальности. Начиная от использования 16 и 32 битных весов моделей и заканчивая 1536 dim и сотнями миллионов документов.

        Мимо использующий RAG локально под каждый проект, а также создающий их для корпоративных систем. Поэтому меня ваши расчеты и повеселили.

        Ну а фраза «я проверял, когда ещё 3.8 не вышла» — это вообще до боли знакомо, пожалуй, самый жизненный момент. Мы сейчас все в этой лодке: только настроил пайплайн, потратил кучу времени, а через месяц выходит новая модель и все твои костыли превращаются в тыкву. Это, кстати, один из главных плюсов облака — там ты просто переписываешь одну строчку в конфиге, а не пересобираешь всё руками с нуля.

        Это я вообще не понял к чему, это вы промахнулись или ответ из нейронки?


        1. Egor1301 Автор
          05.11.2026 13:33

          Да не, не нейронка, просто сам знатно затупил) Я как раз в начале июля со всем этим игрался, когда в топе была линейка Qwen 3.7, а 3.8 только тизерили — вот и переклинило в цифрах, сорри.

          А если по делу и про RAG — раз уж вы их собираете под инкорпорейт, давайте без утрированных примеров, мне действительно интересен ваш продакшн-опыт.

          Расчёты в статье намеренно сделаны «в лоб» и верхнеуровнево, просто чтобы на пальцах показать новичкам: enterprise-объёмы на дефолтных настройках на домашний ноут не встанут. Понятно, что в реальном проекте никто не хранит вектора без оптимизации. Там в ход идет и квантование самих векторов (Scalar/Product Quantization), которое жмет память в 4–8 раз, и легковесные эмбеддеры вместо классических 1536 dim, и те же кастомные bge-модели.

          Но статья-то писалась для тех, кто об этих оптимизациях еще не слышал и думает, что RAG — это просто закинуть PDF-ки в дефолтную базу и всё заведется.

          Поделитесь, раз у вас есть боевые кейсы: какой стек и какие методы сжатия обычно используете, чтобы упаковать базу на те же пару сотен тысяч документов локально? Без иронии — это круто дополнило бы ветку для читателей:)


          1. ToxaBes
            05.11.2026 13:33

            А если по делу и про RAG — раз уж вы их собираете под инкорпорейт, давайте без утрированных примеров, мне действительно интересен ваш продакшн-опыт.

            1536 dim нужно довольно редко, 384-dim достаточно для большинства корпоративных RAG, ретривал обязательно должен быть контекстуальным, т.е. не наивный RAG, а гибридный, если таблицы/сканы/ocr то дополнительно VL эмбеддинги и тд.

            Вместо одной большой модели используется несколько небольших, каждая со своей специализацией и отвечает также небольшая квантованная модель размером 8-12B, причем качественнее чем если использовать одну большую 27-35B модель.

            Ответ на самом деле тянет на большую статью (в хорошем смысле), но у меня сейчас нет времени ее писать.


            1. Egor1301 Автор
              05.11.2026 13:33

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

              Собственно, размерность 384, гибридный поиск и связка из нескольких специализированных моделей по 8B–12B вместо одного неповоротливого гиганта — это как раз те оптимизации, которые спускают требования к железу с небес на землю. Но чтобы всё это настроить, подрубить VL-эмбеддинги и контекстный ретривал, как раз и нужен нормальный инженерный подход.

              Мой текст был скорее про первый шаг новичка, который накатил дефолтные конфиги и ждёт чуда на домашнем ноуте. Хорошо, что в ветке подсветили хардкорную сторону. Если всё-таки выберете время и оформите полноценную статью, с удовольствием ее прочту:)


              1. ToxaBes
                05.11.2026 13:33

                Мой текст был скорее про первый шаг новичка, который накатил дефолтные конфиги и ждёт чуда на домашнем ноуте.

                У меня скорее всего просто проф деформация, увидел то что написано в статье и загорелась красная лампочка в голове)

                К вашей статье как к первому подходу новичка вопросов вообще никаких. Спасибо, что поделились. Мои проф деформации это мои проблемы.


  1. ampir-nn
    05.11.2026 13:33

    Хоть убейте - зачем вообще Q2 ???? Цель была проверить, заведётся ли вообще 72B на ноутбуке - ну заведётся а зачем ? Или цель была убить MacBook ? Убить MacBook - не получится :) Про RAG - это уже вообще понятие растяжимое, дело в реализации в зависимости от типа данных. Когда локально имеет смысл - тогда, когда у вас есть сервер LLM, который собран для выполнения нужных задач. Зачем использовать легковой автомобиль для перевозки трех тонн щебня - в принципе можно, но зачем ??? :)


    1. Egor1301 Автор
      05.11.2026 13:33

      Да в том-то и дело, что незачем!) Аналогия со щебнем и легковушкой просто идеальная, украду её себе.

      Моя статья — это как раз история одного эксперимента из серии «что будет, если засыпать три тонны щебня в багажник Мазды». В интернетах часто пишут: «Да Ollama оптимизирована, macOS круто жонглирует памятью, запускайте что хотите!». Вот мне и стало интересно проверить, где эта граница, за которой начинается абсурд. Оказалось — на 72B в Q2. Завелось? Завелось. Пользоваться этим в здравом уме для работы? Конечно, нет.

      Про RAG тоже согласен, реализаций миллион. Но ко мне часто приходят ребята с горящими глазами: «Мы сейчас натянем локальный RAG на всю базу знаний компании и запустим на офисном мини-ПК!». Приходится садиться и на пальцах (пусть и грубо) показывать им математику, чтобы спустить с небес на землю.

      Так что мы с вами говорим об одном и том же. Вы описываете, как должно быть в идеальном мире (с выделенными серверами под LLM), а я показал, почему популярная идея «да я всё на ноуте сделаю» не работает на практике. Зато повеселился и ноутбук протестировал)


  1. ross-s
    05.11.2026 13:33

    Еще веселее, когда и SSD переполнен: тогда мак зависает и отключается только по hard reset