Локальные LLM модели в Ollama: пошаговый запуск без сети

Зачем держать LLM на своём ПК: приватность, офлайн и экономика

Локальная LLM на своём ПК закрывает три задачи: работу с чувствительными данными, генерацию в изолированном контуре без интернета и предсказуемые расходы вместо токенной тарификации облака.

Сценарий первый — приватность. Договоры под NDA, медицинские выписки, клиентские базы, зарплатная ведомость. Любой запрос в чужой дата-центр уходит в логи, а иногда и в обучающие выборки.

Зависит от политики провайдера, но проверить это снаружи невозможно. Локальная модель такой роскоши не позволяет: веса лежат на диске, наружу уходит ноль байт. Факт легко подтвердить обычным монитором трафика.

Сценарий второй — изолированный контур. Сеть без выхода в интернет, выезд на объект, командировка без связи, самолёт. Модель на 7–9B параметров в 4-битной квантизации занимает 5–7 ГБ и спокойно живёт на ноутбуке с 16 ГБ памяти.

Сценарий третий — экономика. Топовый облачный тариф стоит около 200 $ в месяц, то есть 180–220 тыс ₽ за год. Видеокарта на 16 ГБ — 65–90 тыс ₽ разово плюс 4–5 тыс ₽ на электричество за год при 8 часах работы в день.

Вариант	Первый год	Что получаете
Топовый облачный тариф	180–220 тыс ₽	Флагманская логика, но лимиты и выгрузка данных наружу
Видеокарта 16 ГБ + свет	70–95 тыс ₽	Модели до 32B в квантизации, полный офлайн
Локально + API по факту	90–120 тыс ₽	Рутина на своём железе, сложное — в облако

Разрыв в первый год — примерно вдвое. Со второго года видеокарта уже отбита, и вы платите только за киловатты. Методику расчёта окупаемости под свой объём задач я разбирал в материале про ROI внедрения ИИ.

Честно про качество: на многошаговой логике, работе с большим контекстом и вызове инструментов флагманы заметно впереди. Локальная 14B-модель там сыпет ошибками, и делать вид, что это не так, смысла нет.

Актуальные лимиты, цены за миллион токенов и набор моделей провайдеры публикуют в открытой документации — линейку OpenAI удобно сверять в официальном описании моделей.

Итог простой: приватность и офлайн нельзя купить по подписке ни за какие деньги. А вот экономию — можно, если честно разделить задачи между своим железом и облаком.

Ollama под капотом: как рантайм работает с вашим железом

Ollama — это демон-оркестратор: Go-бинарник, который держит REST API на порту 11434, управляет библиотекой моделей и вызывает под капотом llama.cpp для инференса GGUF-файлов. Сам инференс делают C++ и CUDA/Metal — Ollama только дирижирует.

Разделение простое: llama.cpp — это движок, GGUF — формат упаковки весов, Ollama — удобная обёртка с CLI, автозагрузкой моделей, менеджером версий и Modelfile. Последний работает как Dockerfile: базовый образ, системный промпт, параметры сэмплинга, температурные настройки.

Что реально происходит при ollama run qwen3:8b? Сначала идёт проверка манифеста в ~/.ollama/models: есть ли нужный тег, совпадают ли SHA256-хэши слоёв. Если модели нет — качаются блобы. Дальше начинается интересное: слои подгружаются в RAM и по возможности offload-ятся на GPU.

Параметр num_gpu решает, сколько слоёв уедет в VRAM, остальное добирает CPU. На 8 ГБ видеопамяти модель на 7–8 млрд параметров в Q4 уходит на GPU целиком, 30-миллиардная — только частично, и скорость падает с 45–60 токенов/с до 6–10. Второй пожиратель памяти — KV-кэш контекста: 8192 токена на 8B-модели съедают ещё около 1 ГБ.

Квант GGUF	Бит на вес	7B-модель	Потеря качества
FP16	16	~14 ГБ	эталон
Q8_0	8,5	~7,6 ГБ	почти нет
Q4_K_M	4,5	~4,4 ГБ	1–3%
Q3_K_S	3,5	~3,3 ГБ	заметно

Форматы вроде Safetensors Ollama конвертирует внутри — при импорте через Modelfile она прогоняет веса через конвертер в GGUF и раскладывает по слоям. Так что скачанные с репозиториев исходники тоже заведутся, просто подготовка займёт лишние 5–15 минут.

Хорошая новость: популярные открытые семейства — Qwen, Llama, Gemma, Mistral и открытые веса DeepSeek — уже лежат в GGUF в официальной библиотеке. Тянуть их в оригинальном формате почти никогда не нужно.

Если хочется поднять локальный инференс до уровня агентных сценариев без терминала, посмотрите наш разбор DeepSeek Harness: десктопные агенты без терминала и кода — там как раз про то, что делать поверх готового рантайма.

Сравнение моделей: что реально влезает в вашу видеопамять

Короткий ответ: 8 ГБ VRAM — это модели 7–9B в Q4_K_M, 16 ГБ — 14B, 24 ГБ — 24–32B или MoE с 3B активных параметров. Всё крупнее требует 48 ГБ+ памяти и заметно проседает по скорости.

Главная ловушка новичка — путать размер файла с реальным потреблением. К весам добавляется KV-кэш контекста: на 32K токенов модель 14B съедает сверху ещё 2–4 ГБ, а 32B — уже 6–8 ГБ. Ollama и llama.cpp честно печатают расход в логах при загрузке, так что смотрите туда, а не на число в названии тега.

Модель и размер	Квантование	Память (VRAM/RAM)	Скорость, ток/с	Под какие задачи брать
Qwen3 4B / Llama 3.2 3B	Q4_K_M	2,5–3 ГБ	70–110	Автодополнение, классификация, короткие ответы бота
Qwen3 8B / Mistral 7B / Llama 3.1 8B	Q4_K_M	5–6 ГБ	40–70	Универсальная лошадка: тексты, RAG, простой код
То же, 7–9B	Q5_K_M	6,5–7,5 ГБ	35–60	Когда Q4 начинает «тупеть» на сложных инструкциях
То же, 7–9B	Q8_0	9–10 ГБ	20–35	Почти эталонное качество, нужна карта на 12 ГБ+
Qwen3 14B	Q4_K_M	9–10 ГБ	25–45	Аналитика, длинные инструкции, код-ревью
Qwen3 14B	Q5_K_M	11–12 ГБ	20–38	Оптимум «качество/память» на 12–16 ГБ
Qwen3 14B	Q8_0	16–17 ГБ	12–18	24 ГБ карта, работа почти без потерь
Qwen3 32B / Gemma 3 27B / Mistral Small 3.2 24B	Q4_K_M	17–20 ГБ	12–25	Агенты, длинный контекст, тяжёлый код
То же, 24–32B	Q5_K_M	21–24 ГБ	10–18	Предел для 24 ГБ, контекст придётся экономить
То же, 24–32B	Q8_0	34–36 ГБ	—	В одну карту не влезает: нужно 2×24 ГБ или 48 ГБ unified
Qwen3 30B-A3B (3B активных)	Q4_K_M	18–20 ГБ	60–120	Быстрые чаты и агенты в реальном времени
MoE 100B+ (Llama 4 Scout, Mixtral 8x22B)	Q4_K_M	40–65 ГБ	15–35	Только при наличии двух карт или 64 ГБ RAM

Квантование — это компрессия весов. Q4_K_M — рабочая лошадка: минус около 70% объёма против FP16 при деградации в пределах статистической погрешности. Q5_K_M — компромисс: плюс 1–2 ГБ за заметно более чистые ответы на коде и математике. Q8_0 — уже роскошь, оправданная только на 24 ГБ и выше.

Для справки: облачные флагманы уровня GPT-6.1 Sol или Claude 5.5 по-прежнему обходят любую домашнюю сборку — актуальный список моделей OpenAI это наглядно показывает, — но они требуют интернета и оплаты за токены.

А если хочется не просто чата, а агента, который сам разбирает файлы на диске, загляните в разбор DeepSeek Harness: десктопные агенты без терминала и кода — там как раз объясняется, почему под такие сценарии разумный минимум начинается с 14B.

Пошаговая установка на Windows, macOS, Linux и в Docker

Установка Ollama занимает 2–5 минут: на Windows через winget, на macOS через brew, на Linux через curl-скрипт, а в Docker запуском официального образа с обязательным пробросом GPU.

Дальше логика одинаковая на всех платформах: поднять демон, скачать веса, проверить, что модель реально ушла на GPU. Ниже — рабочий чек-лист без воды.

Windows. Одна команда в PowerShell:

winget install Ollama.Ollama

Инсталлятор сам поднимает демон в трее и прописывает его в автозагрузку. Отдельный ollama serve тут не нужен.

macOS. Через Homebrew:

brew install ollama
ollama serve   # если ставили только CLI, без фонового сервиса

Linux. Скрипт создаёт пользователя и systemd-юнит, всё поднимается само:

curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl status ollama

Docker. Здесь важны ровно два флага: проброс видеокарты и монтирование тома под веса.

docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

Без --gpus=all модель молча уедет на CPU и потеряет 10–20 раз в скорости генерации. Без -v ollama:/root/.ollama каждый пересозданный контейнер будет качать те же 20–40 ГБ весов заново.

Проверка после установки. Пять команд, которые закрывают 90% вопросов:

ollama --version        # CLI на месте
ollama pull qwen3:32b   # скачать веса (~20 ГБ в Q4)
ollama run qwen3:32b    # чат прямо в терминале
ollama list             # что уже лежит на диске
ollama ps               # что загружено в память сейчас

ollama ps показывает реальное потребление VRAM и метку «100% GPU» или «CPU/GPU split». Это первое место, куда смотреть, когда ответы ползут по 2 токена в секунду.

Apple Silicon — отдельная история. У M-чипов unified memory: CPU и GPU видят один пул памяти. Поэтому 32B в Q4 (около 20 ГБ) спокойно живёт на Mac с 32–64 ГБ ОЗУ, тогда как на дискретной карте с 12 ГБ он бы не влез без офлоада и просадки скорости.

И про трезвость ожиданий: локальная 32B не обгонит флагманские облачные модели вроде GPT-6.1 Sol или Claude 5.5 на сложных рассуждениях. Зато она бесплатна, работает без сети и не отдаёт ваши данные наружу. А если консоль мозолит глаза, есть десктопные агенты без терминала и кода.

Modelfile и переменные окружения: тонкая настройка под задачу

Modelfile — это текстовый конфиг, которым Ollama собирает кастомную модель из готовых весов: там задаются системный промпт, температура, размер контекста и шаблон чата. Переменные окружения управляют уже самим сервером: портами, параллелизмом и памятью.

Минимальный рабочий Modelfile выглядит так:

FROM qwen3:8b

PARAMETER temperature 0.3
PARAMETER num_ctx 8192
PARAMETER top_p 0.9
PARAMETER repeat_penalty 1.1

SYSTEM """Ты — технический ассистент. Отвечай по-русски, кратко, без воды."""

TEMPLATE """{{ if .System }}<|im_start|>system
{{ .System }}<|im_end|>
{{ end }}<|im_start|>user
{{ .Prompt }}<|im_end|>
<|im_start|>assistant
"""

Собирается одной командой: ollama create my-assistant -f Modelfile. Дальше запуск — как у обычной модели, только имя своё.

Поле TEMPLATE трогают редко: у базовых весов он уже прописан и заточен под конкретный токенизатор. Переопределять его стоит, только если вы льёте свои дообученные веса или притащили GGUF из другого проекта. А вот SYSTEM и temperature — рабочая лошадка: для кода и извлечения данных ставьте 0.1–0.3, для брейншторма 0.7–0.9.

Теперь про сам сервер. Ключевые переменные окружения:

Переменная	По умолчанию	Что делает
OLLAMA_HOST	127.0.0.1:11434	Адрес и порт API. 0.0.0.0:11434 открывает доступ из локальной сети
OLLAMA_NUM_PARALLEL	1–4 (авто)	Сколько запросов крутится одновременно. Каждый съедает свой кусок KV-кэша
OLLAMA_MAX_LOADED_MODELS	3 × число GPU	Сколько моделей держать в памяти разом
OLLAMA_KEEP_ALIVE	5m	Сколько модель висит в памяти после ответа. -1 — вечно, 0 — выгрузить сразу
OLLAMA_FLASH_ATTENTION	авто	Ускоряет генерацию и открывает квантование KV-кэша
OLLAMA_KV_CACHE_TYPE	f16	q8_0 режет память KV-кэша вдвое, q4_0 — вчетверо

Комбо OLLAMA_FLASH_ATTENTION=1 + OLLAMA_KV_CACHE_TYPE=q8_0 на модели 8B экономит около 0.5 ГБ при контексте 8192 — и почти без потери качества ответов. На gpt-oss:20b выигрыш уже 1.5–2 ГБ, что часто и решает, влезет модель в 12 ГБ VRAM или нет.

Подключение к своему скрипту — это обычный HTTP:

curl http://localhost:11434/api/chat -d '{
  "model": "my-assistant",
  "messages": [{"role": "user", "content": "Что такое KV-кэш?"}],
  "stream": false
}'

А вот то же самое на Python с переопределением параметров на лету:

import requests

r = requests.post("http://localhost:11434/api/chat", json={
    "model": "my-assistant",
    "messages": [{"role": "user", "content": "Что такое KV-кэш?"}],
    "options": {"temperature": 0.2, "num_ctx": 8192},
    "stream": False,
})
print(r.json()["message"]["content"])

Отдельный бонус: Ollama отдаёт OpenAI-совместимый эндпоинт /v1/chat/completions. Значит, официальный SDK подхватит локальную модель сменой одной строки base_url — удобно, когда прототип на облачном GPT-6.1 Sol нужно перевести на свои железки или наоборот. Подробнее про сами модели можно свериться в документации OpenAI.

Дальше эту ручку легко превратить в агента: примеры уже разбирали в материале про десктопные агенты без терминала и про SEO-агента на n8n. Локальный сервер на OLLAMA_HOST подключается туда точно так же, как любой внешний API.

GUI и рабочие сценарии: Open WebUI, RAG и локальные агенты

Open WebUI — оптимальная оболочка для локальных LLM на домашнем ПК: она даёт чат, встроенный RAG, агентные цепочки и OpenAI-совместимый API поверх Ollama, поднимаясь одной командой в Docker за 30–60 секунд.

Но это не единственный путь. Терминал быстрее и не жрёт RAM на веб-морду, LM Studio удобнее для первого старта, а встраивание в редактор кода — вообще отдельный жанр. Расклад по четырём сценариям:

Оболочка	Плюсы	Минусы	Кому
Терминал (ollama run)	0 накладных, полный контроль флагов	Нет истории, RAG руками	Скриптам и пайплайнам
Open WebUI	Чат, RAG, агенты, API, мультиюзер	~1,5 ГБ образ, нужен Docker	Основной рабочий стол
LM Studio	GUI-выбор модели, замер tok/s	Слабее в агентных цепочках	Новичкам и бенчмаркам
Continue / Cline	Подсказки прямо в IDE	Контекст режется до 8–16k	Кодингу на закрытом контуре

Самый сочный сценарий — локальный RAG на своих документах. Схема простая: эмбеддинги (bge-m3 или nomic-embed-text), нарезка на чанки по 500–1000 токенов с перехлёстом 10–15%, векторный индекс (ChromaDB, Qdrant) и подача top-k фрагментов в промпт.

Сотня PDF превращается примерно в 10–15 тысяч чанков. На CPU индекс строится 3–8 минут, дальше поиск летает за 50–150 мс.

Когда это оправдано? Когда данные нельзя выносить наружу: договоры, медкарты, внутренняя документация под NDA. Если же вопрос разовый — облако дешевле и точнее.

Гибридный поиск плюс реранкер bge-reranker-v2 поднимают точность на 15–25%, но добавляют 200–400 мс и ещё пару гигабайт VRAM. На RTX 3060 12 ГБ модель 7–8B в Q4 выдаёт 30–45 токенов/с — комфортно для чтения, но не для автодополнения кода.

Про кодинг честно: локальные модели пока уступают специализированным облачным инструментам вроде Claude Code CLI и Cursor на базе Claude 5.5 Opus или GPT-6.1 Sol — особенно на многофайловых рефакторингах. Это нормальный компромисс: вы платите скоростью и качеством за полную приватность. Для сравнения возможностей современных облачных линейк полезно держать под рукой официальную документацию OpenAI.

Если терминал и Docker — не ваш путь, есть готовые десктопные агенты: разбирали их в материале DeepSeek Harness: десктопные агенты без терминала и кода.

Частые ошибки, узкие места и диагностика производительности

Пять граблей убивают локальный запуск: медленный диск, выгрузка слоёв на CPU, неподхваченные драйверы GPU, занятый порт 11434 и нехватка места при pull. Диагностика — ollama ps и ollama logs.

Начнём с самого обидного. Модель грузится «вечно», хотя железо вроде бы нормальное. Виноват диск: 7B в Q4_K_M весит около 4,5 ГБ. На HDD со скоростью 100–150 МБ/с только чтение съест 40–60 секунд. На NVMe Gen4 (5–7 ГБ/с) та же модель поднимается за 2–4 секунды. Разница в 10–20 раз, и это чистый проигрыш в ожидании.

Вторая классика — часть слоёв уходит на CPU. Ollama сама решает, сколько влезет в VRAM. Модель 8B в Q4 требует ~5,5 ГБ, а на карте свободно 4 ГБ, и половина слоёв уезжает в оперативку. Скорость при этом падает с 40–60 ток/с до 3–8 ток/с. Признак: CPU загружен под 100%, GPU простаивает.

Третья напасть — драйверы. При первом запуске ищите в логе строку no compatible GPUs were detected. Если она есть, nvidia-smi тоже не увидит карту: старый драйвер, разъехавшаяся CUDA или WSL без проброса. Обновите драйвер и перезапустите службу, прежде чем винить модель.

Симптом	Причина	Что делать
Загрузка 40–60 с	Модель на HDD	Перенести на NVMe, задать OLLAMA_MODELS
3–8 ток/с вместо 50	Слои выгружены на CPU	Квант Q4 → Q3_K_M, освободить VRAM
no compatible GPUs	Драйвер или CUDA	Обновить драйвер, проверить nvidia-smi
address already in use	Порт 11434 занят	OLLAMA_HOST=127.0.0.1:11435
Pull падает на 80%	Нет места	Освободить 15–25 ГБ в ~/.ollama/models

Финальная проверка автономности — самая честная. Выдерните сетевой кабель и прогоните три сценария. Чат в терминале, запрос к API (curl http://localhost:11434/api/tags) и RAG-контур на локальных эмбеддингах вроде nomic-embed-text плюс векторная БД на том же диске. Если все три отвечают — контур действительно ваш, а не арендованный.

Для сравнения с облачными флагманами держите под рукой официальную документацию моделей OpenAI: локальная 8B в Q4 проигрывает им в reasoning, но выигрывает в приватности и нулевой цене за токен. А если хочется собрать агента поверх такого контура, посмотрите наш разбор десктопных агентов без терминала и кода.

Часто задаваемые вопросы (FAQ)