Гайд Jamesob: запускаем SOTA LLM локально

Почему локальные LLM — это уже не хобби, а стратегия

Представьте: вы отправляете конфиденциальный запрос в ChatGPT, и ваши данные тут же уходят на серверы OpenAI, Microsoft Azure и далее по цепочке. Теперь представьте, что тот же ответ генерируется прямо у вас на машине — без API-ключей, без поминутных счётов, без утечки данных. Именно об этом — руководство Jamesob, опубликованное на GitHub под названием «Everything I know about running LLMs locally».

Запуск LLM локально сместился из ниши хобби в легитимную производственную стратегию. Разработчики, которым нужно держать проприетарный код вдали от сторонних серверов, избегать поминутных расходов или строить AI-функции, работающие офлайн, теперь имеют зрелую экосистему инструментов.

В этом материале мы разберём ключевые идеи гайда Jamesob, добавим актуальные данные по железу, инструментам и моделям по состоянию на середину 2026 года — и дадим вам готовую карту действий.

1. Зачем вообще запускать LLM локально?

«Данные никогда не покидают машину» — это и есть главный аргумент в пользу локального инференса.

Самая весомая причина запускать инференс локально очевидна: данные никогда не покидают машину. Для организаций, работающих в соответствии с GDPR, HIPAA или внутренней политикой интеллектуальной собственности, локальный инференс исключает вектора угроз, связанные с передачей данных и сторонними процессорами.

По данным за 2025 год, 44% организаций назвали конфиденциальность данных и безопасность главным барьером для внедрения LLM. Локальный запуск снимает этот барьер полностью.

Другие весомые причины:

• Нулевые расходы на токены. Локальные конфигурации снижают задержку (менее 100 мс) и полностью исключают поминутные платежи, делая их идеальными для задач с высоким объёмом запросов.
• Офлайн-работа. Локальные LLM отлично подходят для автодополнения кода с полным контекстом репозитория, RAG по приватным документам, интеграции в CI/CD для автоматического ревью кода и быстрого прототипирования.
• Контроль над моделью. Вы можете использовать любую версию, файнтюнить, менять параметры — без ограничений провайдера.

2. Железо: сколько VRAM вам реально нужно?

Основная ошибка новичков — выбирать модель, не считая память. Каждый локальный деплой LLM сводится к трём числам, которые должны поместиться в память GPU: суммарный VRAM = веса модели + KV-кэш + накладные расходы рантайма. Веса модели — доминирующая статья (70–75% от общего объёма), KV-кэш масштабируется с длиной контекста (15–20%), накладные расходы покрывают CUDA-контекст, активации и буферы фреймворка (5–10%).

Ключевой принцип: важна пропускная способность памяти, а не вычислительная мощь

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

При оценке пригодности машины для LLM-нагрузок приоритизируйте пропускную способность памяти как основной критерий. Объём памяти важен — нужно достаточно места для модели — но скорость перемещения данных определяет, работает ли система плавно или с трудом.

Таблица: железо по уровням

Наиболее значимое открытие: конфигурации из двух RTX 5090 теперь обеспечивают производительность H100 на 70B-моделях при 25% от его стоимости, что кардинально меняет экономику локального деплоя.

Apple Silicon — другой жизнеспособный путь: чипы M3, M4 и M5 Pro, Max и Ultra используют унифицированную память, то есть вся системная RAM доступна как VRAM. M5 Max с 64 ГБ может запускать модели, для которых иначе потребовался бы H100.

Минимальные требования для старта

VRAM — главное ограничение для локальных LLM: базовое требование — ~2 ГБ на 1 млрд параметров при FP16, Q8-квантизация вдвое снижает это число, Q4 — вчетверо. Модели 3B–4B запускаются практически на любой машине последних трёх лет (включая CPU-ноутбуки с 16 ГБ RAM), а 7B–14B модели отлично работают на среднем GPU типа RTX 3060 12 ГБ.

Хранилище: настоятельно рекомендуется NVMe SSD, поскольку файлы моделей большие и загружаются часто. Файлы LLM нередко превышают 200 ГБ, так что разумно зарезервировать 100–500 ГБ свободного места, если вы планируете использовать несколько моделей.

3. Квантизация: как уменьшить модель без потери качества

Квантизация сжимает веса модели с высокоточных форматов (FP16, 2 байта) до форматов с меньшей точностью (4-бит, ~0.5 байта), напрямую снижая объём памяти для весов. Это самая эффективная оптимизация для размещения моделей на потребительском железе.

Форматы квантизации

GGUF — универсальный формат для локального LLM-инференса. Разработанный в рамках экосистемы llama.cpp, это однофайловый формат, объединяющий веса модели, токенизатор и метаданные. Ollama, LM Studio, GPT4All, Jan и koboldcpp напрямую работают с GGUF-файлами.

Для большинства пользователей Q4_K_M — рекомендуемый вариант по умолчанию: он сохраняет почти всё качество модели при примерно четверти от полноточного размера. Если у вас достаточно VRAM и нужна максимальная точность — используйте Q6_K или Q8_0.

graph TD
    A[Исходная модель FP16] --> B{Квантизация}
    B --> C[Q2_K — минимальный размер\nзначительная потеря качества]
    B --> D[Q4_K_M — оптимальный баланс\n~0.5 байта/параметр]
    B --> E[Q6_K / Q8_0 — высокое качество\nтребует больше VRAM]
    D --> F[GGUF-файл]
    F --> G[llama.cpp / Ollama / LM Studio]

Практический расчёт

# Быстрая оценка нужного VRAM:
# (количество параметров × биты) ÷ 8 = GB

# Пример: 7B модель при 4-bit квантизации:
# (7_000_000_000 × 4) ÷ 8 = 3.5 GB весов
# + KV-кэш + overhead ≈ 5-6 GB итого

# Пример: 32B модель при Q4_K_M:
# (~0.6 GB × 32) ≈ 19-20 GB VRAM

4-битная квантизация снижает требования к памяти до 75%. Это означает, что модель, которая в FP16 требовала бы 28 ГБ, в Q4 влезет в 7 ГБ.

4. Инструменты: llama.cpp, Ollama и что выбрать

llama.cpp — движок под капотом

llama.cpp считается де-факто стандартом в ядре почти всех локальных инструментов инференса, включая Ollama и LM Studio.

Главная цель llama.cpp — обеспечить LLM-инференс с минимальной настройкой и максимальной производительностью на широком спектре железа — локально и в облаке. Реализация на чистом C/C++ без зависимостей; Apple Silicon является первоклассной платформой, оптимизированной через ARM NEON, Accelerate и Metal; поддерживается квантизация 1.5-бит, 2-бит, 3-бит, 4-бит, 5-бит, 6-бит и 8-бит.

# Запуск модели через llama.cpp
llama-cli -m my_model.gguf

# Скачать и запустить модель напрямую с Hugging Face
llama-cli -hf ggml-org/gemma-3-1b-it-GGUF

# Поднять OpenAI-совместимый API-сервер
llama-server -hf ggml-org/gemma-3-1b-it-GGUF

Ollama — для быстрого старта

Ollama предоставляет однобинарную установку со встроенным реестром моделей, автоматическим определением GPU и OpenAI-совместимым REST API. Управление моделями сводится к ollama pull и ollama run. Поддерживается переключение между моделями, настройка через Modelfile и эндпоинты /api/chat и /api/generate. Для большинства разработчиков, начинающих с локальных LLM, Ollama — правильный первый инструмент.

# Установка (macOS/Linux)
curl -fsSL https://ollama.com/install.sh | sh

# Запуск Qwen3 32B
ollama run qwen3:32b

# Запуск с параметрами (4-bit квантизация, контекст 8K)
ollama run qwen3:32b --num-ctx 8192

Когда что выбирать

Ollama оптимизирован для удобства: однострочная установка, курируемый реестр моделей и простота ollama run llama3. llama.cpp оптимизирован для контроля: вы выбираете точные флаги сборки, точную квантизацию, точные настройки семплинга и KV-кэша, и получаете каждую новую функцию в день её появления. Выбирайте Ollama, если хотите максимально быстрый путь «просто работает». Выбирайте llama.cpp напрямую, если вам важно выжать максимум из конкретного железа, нужны функции вроде speculative decoding или вы разворачиваете лёгкий продакшн-сервер.

vLLM — для многопользовательских сценариев

vLLM — движок инференса с открытым исходным кодом для запуска LLM в производственном масштабе. В отличие от Ollama или LM Studio, vLLM приоритизирует пропускную способность и задержку в многопользовательских сценариях. Его ключевое новшество — PagedAttention, который управляет GPU-памятью как виртуальной. Реальные бенчмарки показывают 793 токена/с на Llama 70B против 41 т/с у Ollama при конкурентной нагрузке.

5. Какие модели запускать: тиры от Jamesob

Одна из самых ценных частей гайда Jamesob — структурированный подход к выбору модели в зависимости от доступного железа. Вот обновлённая версия этих тиров:

Тир 1: 16 ГБ RAM / без дискретной GPU

Модели в диапазоне 3B–8B теперь приближаются к оценкам GPT-3.5 на бенчмарках HumanEval и MMLU для задач генерации кода, суммаризации и RAG. В числе ключевых семейств: Llama 4 Scout, Phi-4 от Microsoft, Gemma 3 от Google, Qwen 3 от Alibaba и Mistral Small 3.2.

Google Gemma 4 E4B — очевидный выбор для ноутбуков и десктопов с 16 ГБ памяти.

Тир 2: RTX 3090/4090 (24 ГБ VRAM)

Для задач кодирования Qwen 2.5 Coder 32B выделяется среди других, набирая 92% на бенчмарке HumanEval — выше, чем 90.2% у GPT-4o. При наличии 24 ГБ VRAM эта модель отлично подходит для генерации и ревью кода.

Тир 3: 4× RTX 6000 Pro (384 ГБ VRAM)

На этом уровне вы получаете следующую ступень интеллекта модели — что-то весьма близкое к Claude Opus. Конфигурация — 4× RTX 6000 Pro суммарно на 384 ГБ VRAM.

Бонус: локальный STT (Speech-to-Text)

Можно также запустить SOTA speech-to-text через whisper-large-v3 — это очень полезный инструмент. Локальный STT оказывается удивительно практичным, и с ним комфортно работать в отличие от облачного аналога. Готовая конфигурация требует лишь ~11 ГБ VRAM на Nvidia GPU.

MoE-модели: особый случай

MoE-модели требуют VRAM для всех параметров, а не только для активных. 120B MoE-модель с 12B активными параметрами всё равно загружает все 120B весов в память. Количество активных параметров определяет лишь вычислительную стоимость и скорость генерации, но не объём памяти.

6. Пайплайн локального RAG и приватный ИИ-ассистент

Одно из главных практических применений локальных LLM — построение полностью приватного RAG (Retrieval-Augmented Generation) пайплайна.

Сочетание локального LLM с локальным векторным хранилищем, таким как ChromaDB или SQLite-vec, создаёт полностью офлайн RAG-пайплайн. Это практично для кодовых баз, внутренней документации и датасетов, достаточно малых для встраивания и индексации на одной машине — примерно до нескольких сотен тысяч документов.

graph LR
    A[Приватные документы] --> B[Embedding-модель\nnomic-embed-text]
    B --> C[Локальная векторная БД\nChromaDB / SQLite-vec]
    D[Вопрос пользователя] --> E[Поиск релевантных чанков]
    C --> E
    E --> F[Контекст + вопрос]
    F --> G[Локальный LLM\nOllama / llama.cpp]
    G --> H[Ответ]

# Минимальный пример RAG с Ollama
import ollama
import chromadb

# Инициализация клиентов
client = chromadb.Client()
collection = client.create_collection("docs")

# Добавление документов
collection.add(
    documents=["Ваш приватный текст здесь"],
    ids=["doc1"]
)

# Поиск и генерация
query = "Что говорится о проекте?"
results = collection.query(query_texts=[query], n_results=3)
context = "\n".join(results['documents'][0])

response = ollama.chat(
    model='qwen3:8b',
    messages=[{
        'role': 'user',
        'content': f'Контекст:\n{context}\n\nВопрос: {query}'
    }]
)
print(response['message']['content'])

Заключение: когда локальный LLM имеет смысл

Запуск LLM локально — уже не нишевое хобби. В 2026 году open-weight модели типа Qwen 3.5, Llama 4 Scout и другие конкурируют с проприетарными API на большинстве бенчмарков.

Локальный LLM — ваш выбор, если:

• Данные не должны покидать организацию (медицина, юриспруденция, госсектор)
• Высокий объём запросов делает API экономически невыгодным
• Нужна работа офлайн или минимальная задержка
• Вы хотите полного контроля над моделью и её параметрами

Облачный API — лучше, если:

• Нужна максимальная производительность на сложных задачах рассуждения
• Нет ресурсов для покупки и обслуживания железа
• Объём запросов слишком мал для окупаемости инвестиций

Точка безубыточности для самохостинга по сравнению с API обычно наступает при примерно 2 миллионах токенов в день при надлежащей утилизации железа выше 70%.

Главный вывод гайда Jamesob и всей практики 2026 года прост: начинайте с Ollama и модели, подходящей под ваше железо, итерируйте. Разрыв между локальными и облачными моделями продолжает сокращаться — и момент, когда локальный стек станет «достаточно хорошим» для большинства задач, уже наступил.