Что делать, если локальный ИИ зависает на ноутбуке с 8 ГБ памяти
Вы наверняка сталкивались с ситуацией, когда после просмотра видео на YouTube вы вводили в терминале команду для установки модели, и экран зависал. Причина, по которой локальные LLM падают на старых MacBook с 8 или 16 ГБ оперативной памяти или на бюджетных ноутбуках, заключается вовсе не в нехватке вычислительных ядер. Настоящий виновник — ситуация, когда в условиях катастрофически узкой пропускной способности памяти рантайм пытается прочитать данные, превышающие его предел. Оценив пропускную способность устройства и настроив размер контекста, вы сможете запустить и успешно использовать модель для помощи в написании кода даже на старом железе.
Установка диагностического инструмента без затрагивания системного Python
Современные macOS и Ubuntu блокируют прямую установку пакетов в системный Python. При попытке выполнить pip install процесс тут же останавливается с ошибкой PEP 668 (error: externally-managed-environment). Если из лени снять системную защиту принудительным флагом (--break-system-packages), со временем основные инструменты ОС запутаются, и систему придется переустанавливать. Для установки диагностического инструмента лучше использовать pipx, который поддерживает изоляцию в независимых виртуальных окружениях.
С помощью открытого диагностического инструмента llmfit, разработанного Алексом Джонсом (Alex Jones), развернем изолированное окружение для сбора характеристик нашего железа.
`bash
Установка pipx для macOS (для Linux: sudo apt install -y pipx)
brew install pipx
pipx ensurepath
Установка llmfit и сохранение результатов сканирования железа
pipx install llmfit
mkdir -p ~/local-ai-workspace/{configs,logs,scripts}
llmfit --json system > ~/local-ai-workspace/logs/system_specs.json
`
После завершения этого процесса в терминале, объем ОМП (оперативной памяти) устройства и информация о шине памяти будут аккуратно записаны в файл system_specs.json всего за одну минуту без изменения системных библиотек.
Расчет пропускной способности и выбор моделей на 3B и 7B
Генерация текста локальной языковой моделью — это последовательный процесс, при котором каждый следующий символ создается на основе уже сгенерированных токенов. На каждом шаге миллиарды весов модели должны считываться целиком из шины памяти. Иными словами, воспринимаемая скорость работы определяется не тактовой частотой GPU, а пропускной способностью памяти.
Скорость генерации токенов в секунду (TPS) рассчитывается по следующей формуле:
TPS approx rac{ ext{Memory Bandwidth (GB/s)}}{ ext{Model Weights Size (GB)} + ext{KV Cache per Step (GB)}} imes etaЗначение eta в формуле представляет собой коэффициент эффективности реальной пропускной способности рантайма (MBU) и обычно составляет около 0.65.
Если полностью загрузить 4-битную квантованную 7B-модель (около 4.5 ГБ) в обычную десктопную оперативная память DDR4 с пропускной способностью около 45 ГБ/с, скорость вычислений останется на уровне 45div4.5imes0.65approx6.5extTPS. Текст выводится по одному символу с заметными задержками, что сильно раздражает при использовании модели для рабочих задач. С другой стороны, при запуске на RTX 4060 с 8 ГБ VRAM и пропускной способностью 288 ГБ/с или на унифицированной памяти чипов серии M с пропускной способностью более 100 ГБ/с скорость достигает 35–40 токенов в секунду, легко превосходя скорость набора текста.
После проверки характеристик вашего устройства выберите одну из двух моделей:
- Написание кода и тестов: Используется
Qwen2.5-Coder-7B-Instruct (Q4_K_M) размером 4.7 ГБ. На MacBook с 16 ГБ унифицированной памяти или дискретной видеокарте с 8 ГБ VRAM скорость составляет более 35 TPS.
- Суммаризация документов и написание логов коммитов: Используется
Llama-3.2-3B-Instruct (Q4_K_M) размером 2.0 ГБ. Она потребляет меньше памяти даже в среде DDR4 на маломощных ноутбуках и стабильно выдает около 15 TPS.
Ограничение окна контекста до 4096 для предотвращения ошибок OOM
Даже если модель успешно запускается, после нескольких вопросов процесс тихо завершается. Ошибка Exit Code 137, выводимая в терминале, означает, что менеджер памяти операционной системы (Linux OOM-Killer или macOS JetSam) принудительно завершил процесс (SIGKILL) из-за нехватки памяти.
При использовании дискретного GPU возникает еще более коварная проблема — тихий откат на CPU (Silent CPU Fallback). Если объем VRAM исчерпан, процесс не завершается, но часть вычислительных слоев переносится в медленную системную память. В этот момент загрузка GPU падает до минимума, а скорость снижается до одного токена в секунду.
Главный виновник — кэш KV (Key-Value), который поглощает оперативную память по мере удлинения диалога. Если оставить контекст модели Llama-3 размером до 32 768 (32K) токенов, то помимо весов размером 4.5 ГБ потребуется еще 4.0 ГБ только под кэш-память. На устройствах с 8 ГБ это гарантированно приводит к сбою. Ограничение длины до 4 096 (4K) токенов уменьшает объем кэша до 512 МБ, что позволяет модели работать стабильно на системах с 8 ГБ.
Ниже описан порядок проверки текущего состояния и фиксации лимита.
Сначала введите ollama ps в терминале. Если в графе PROCESSOR значение отображается не как 100% GPU, а разделено, например, как 30%/70% CPU/GPU, это значит, что VRAM переполнена и данные выгружены в медленную память.
Создайте файл конфигурации для фиксации размера контекста. Откройте ~/local-ai-workspace/configs/Modelfile.coder и добавьте в него следующие строки:
`dockerfile
FROM qwen2.5-coder:7b
Верхний предел в 4096 токенов для предотвращения переполнения кэша
PARAMETER num_ctx 4096
PARAMETER temperature 0.2
`
Выполните сборку кастомной модели через терминал:
`bash
ollama create custom-coder:7b -f ~/local-ai-workspace/configs/Modelfile.coder
`
По окончании сборки очистите дисковый кэш командой sudo purge в терминале macOS или закройте неиспользуемые экземпляры WSL с помощью wsl --shutdown в Windows, чтобы освободить не менее 2 ГБ доступной оперативной памяти.
Создание изолированного локального пайплайна без утечки данных
Чтобы исходный код компании или личные проекты не покидали устройство, привяжите эндпоинт обслуживания модели исключительно к локальному циклическому интерфейсу (127.0.0.1).
Создайте файл ~/local-ai-workspace/scripts/serve_secure.sh со следующим содержимым:
`bash
#!/bin/bash
export OLLAMA_HOST="127.0.0.1:11434"
export OLLAMA_ORIGINS="http://127.0.0.1:*,http://localhost:*"
ollama serve > ~/local-ai-workspace/logs/ollama_runtime.log 2>&1 &
`
После запуска скрипта проверьте с помощью команды lsof -i :11434 | grep LISTEN в терминале, что адрес приема запросов отображается как 127.0.0.1:11434. Если виден адрес 0.0.0.0:11434, доступный извне, процесс следует немедленно закрыть.
Для интеграции используется плагин Continue.dev для VS Code. Откройте файл конфигурации (~/.continue/config.json) и разделите модели для чата и автодополнения.
`json
{
"models": [
{
"title": "Local Qwen2.5-Coder (Chat)",
"provider": "ollama",
"model": "custom-coder:7b",
"apiBase": "http://127.0.0.1:11434"
},
{
"title": "Local Llama3.2 (Summary)",
"provider": "ollama",
"model": "llama3.2:3b",
"apiBase": "http://127.0.0.1:11434"
}
],
"tabAutocompleteModel": {
"title": "Local Autocomplete",
"provider": "ollama",
"model": "qwen2.5-coder:1.5b",
"apiBase": "http://127.0.0.1:11434"
},
"allowAnonymousTelemetry": false
}
`
Для ответов на вопросы назначьте 7B-модель с предварительно ограниченным контекстом, а для автодополнения во вкладках укажите ультралегкую модель qwen2.5-coder:1.5b размером 1 ГБ. Задержки при автодополнении исчезнут.
Проверку работоспособности следует проводить при отключенном интернете. Отключите Wi-Fi, откройте терминал в автономном режиме и отправьте тестовый запрос:
`bash
curl -s -X POST http://127.0.0.1:11434/api/generate -d '{
"model": "llama3.2:3b",
"prompt": "Тест локальной изолированной сети",
"stream": false
}' | grep "response"
`
Если при отключенной сети возвращается корректный JSON-ответ, настройка среды разработки, работающей исключительно за счет ресурсов вашего ноутбука и защищенной от внешних облачных зависимостей, успешно завершена.