Знаете это чувство, когда читаешь статью про локальные 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)

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

Egor1301 Автор
05.11.2026 13:33Да в том-то и дело, что незачем!) Аналогия со щебнем и легковушкой просто идеальная, украду её себе.
Моя статья — это как раз история одного эксперимента из серии «что будет, если засыпать три тонны щебня в багажник Мазды». В интернетах часто пишут: «Да Ollama оптимизирована, macOS круто жонглирует памятью, запускайте что хотите!». Вот мне и стало интересно проверить, где эта граница, за которой начинается абсурд. Оказалось — на 72B в Q2. Завелось? Завелось. Пользоваться этим в здравом уме для работы? Конечно, нет.
Про RAG тоже согласен, реализаций миллион. Но ко мне часто приходят ребята с горящими глазами: «Мы сейчас натянем локальный RAG на всю базу знаний компании и запустим на офисном мини-ПК!». Приходится садиться и на пальцах (пусть и грубо) показывать им математику, чтобы спустить с небес на землю.
Так что мы с вами говорим об одном и том же. Вы описываете, как должно быть в идеальном мире (с выделенными серверами под LLM), а я показал, почему популярная идея «да я всё на ноуте сделаю» не работает на практике. Зато повеселился и ноутбук протестировал)

ross-s
05.11.2026 13:33Еще веселее, когда и SSD переполнен: тогда мак зависает и отключается только по hard reset
ToxaBes
Зачем, если есть "такая же но меньше и новее" Qwen3.8-27B в Q4/Q5 от Unsloth или подобные, что влезет.
С расчетами RAG на миллионы документов и весом модели в FP16/FP32 посмеялся в голос, повеселили, спасибо.
Egor1301 Автор
Да, на сто процентов правы. Я и в самой статье пытался подсветить, что это эксперимент из серии «заведется ли вообще 72B на ноуте», а не готовый рецепт для продакшна. Понятно, что для нормальной работы я бы сам взял 7B–14B в квантовании Q4/Q5. А 72B в Q2_K на 32 ГБ оперативки — это не инструкция «как надо», это чистый фан и проверка границ. Статья скорее про личный опыт и грабли, а не про строгий гайд.
По поводу расчетов для RAG — отлично понимаю, почему они вызвали улыбку) Там цифры действительно грубые, но задача была не выдать точную спецификацию под конкретный проект, а просто показать порядок величин. Когда прикидываешь 14 млн чанков × 1536 dim × 4 байта, получаешь ~86 ГБ чисто под вектора. Докидываем сюда оверхед от HNSW, индексы — и сразу понятно, почему идея «запущу-ка я локальный RAG на всем домене на домашнем ноуте с 32 ГБ» разбивается о суровую реальность. На таком железе это максимум 500 документов. Если этот пример помог запомнить, что под доменный RAG нужно совсем другое железо, то цифры свою задачу выполнили.
Ну а фраза «я проверял, когда ещё 3.8 не вышла» — это вообще до боли знакомо, пожалуй, самый жизненный момент. Мы сейчас все в этой лодке: только настроил пайплайн, потратил кучу времени, а через месяц выходит новая модель и все твои костыли превращаются в тыкву. Это, кстати, один из главных плюсов облака — там ты просто переписываешь одну строчку в конфиге, а не пересобираешь всё руками с нуля.
В любом случае — спасибо за фидбек, с такими уточнениями дискуссия выходит гораздо интереснее!
ToxaBes
Попробуйте еще модель из моего комментария вот тут.
Дело в том, что ваши цифры оторваны от реальности. Начиная от использования 16 и 32 битных весов моделей и заканчивая 1536 dim и сотнями миллионов документов.
Мимо использующий RAG локально под каждый проект, а также создающий их для корпоративных систем. Поэтому меня ваши расчеты и повеселили.
Это я вообще не понял к чему, это вы промахнулись или ответ из нейронки?
Egor1301 Автор
Да не, не нейронка, просто сам знатно затупил) Я как раз в начале июля со всем этим игрался, когда в топе была линейка Qwen 3.7, а 3.8 только тизерили — вот и переклинило в цифрах, сорри.
А если по делу и про RAG — раз уж вы их собираете под инкорпорейт, давайте без утрированных примеров, мне действительно интересен ваш продакшн-опыт.
Расчёты в статье намеренно сделаны «в лоб» и верхнеуровнево, просто чтобы на пальцах показать новичкам: enterprise-объёмы на дефолтных настройках на домашний ноут не встанут. Понятно, что в реальном проекте никто не хранит вектора без оптимизации. Там в ход идет и квантование самих векторов (Scalar/Product Quantization), которое жмет память в 4–8 раз, и легковесные эмбеддеры вместо классических 1536 dim, и те же кастомные bge-модели.
Но статья-то писалась для тех, кто об этих оптимизациях еще не слышал и думает, что RAG — это просто закинуть PDF-ки в дефолтную базу и всё заведется.
Поделитесь, раз у вас есть боевые кейсы: какой стек и какие методы сжатия обычно используете, чтобы упаковать базу на те же пару сотен тысяч документов локально? Без иронии — это круто дополнило бы ветку для читателей:)
ToxaBes
1536 dim нужно довольно редко, 384-dim достаточно для большинства корпоративных RAG, ретривал обязательно должен быть контекстуальным, т.е. не наивный RAG, а гибридный, если таблицы/сканы/ocr то дополнительно VL эмбеддинги и тд.
Вместо одной большой модели используется несколько небольших, каждая со своей специализацией и отвечает также небольшая квантованная модель размером 8-12B, причем качественнее чем если использовать одну большую 27-35B модель.
Ответ на самом деле тянет на большую статью (в хорошем смысле), но у меня сейчас нет времени ее писать.
Egor1301 Автор
Всё так, это как раз классическое разделение на «наивный» RAG для быстрых экспериментов и нормальную продакшн-архитектуру.
Собственно, размерность 384, гибридный поиск и связка из нескольких специализированных моделей по 8B–12B вместо одного неповоротливого гиганта — это как раз те оптимизации, которые спускают требования к железу с небес на землю. Но чтобы всё это настроить, подрубить VL-эмбеддинги и контекстный ретривал, как раз и нужен нормальный инженерный подход.
Мой текст был скорее про первый шаг новичка, который накатил дефолтные конфиги и ждёт чуда на домашнем ноуте. Хорошо, что в ветке подсветили хардкорную сторону. Если всё-таки выберете время и оформите полноценную статью, с удовольствием ее прочту:)
ToxaBes
У меня скорее всего просто проф деформация, увидел то что написано в статье и загорелась красная лампочка в голове)
К вашей статье как к первому подходу новичка вопросов вообще никаких. Спасибо, что поделились. Мои проф деформации это мои проблемы.