Локальный LLM на ноутбуке 2026: Ollama, LM Studio, vLLM — практическое руководство

Зачем локальный LLM в 2026 — 4 главные причины

Я последние два года поднимал локальные LLM на разном железе — от MacBook M2 до сервера с двумя H100. Сначала это была экзотика для энтузиастов: модели глупее, скорости меньше, инференс ломался при первой попытке загрузить большой контекст. К 2026 году ситуация перевернулась: open-source-модели в категории 30-70B параметров вплотную подошли к GPT-4 уровня 2023 года, а инструменты вокруг них стали тривиальными в установке. Мой студенческий MacBook Air M2 16 ГБ запускает Llama 3.3 8B быстрее, чем я успеваю прочитать её ответ.

Первая причина, по которой бизнес массово смотрит на локальные LLM в 2026 — это приватность персональных данных. Каждый запрос в OpenAI или Anthropic — это вывоз ПД на серверы за пределами РФ, что прямо нарушает ст. 18 ч. 5 152-ФЗ. С локальной моделью данные не покидают компьютер: ни в логи провайдера, ни в обучающую выборку, никуда. Это решает 80% юридических вопросов одним движением — особенно если у вас в обработке корпоративные документы, медкарты, клиентские базы или что-то подобное.

Вторая — нулевая стоимость токенов. Заплатили один раз за железо, дальше любое количество запросов бесплатно. Я в личной работе прогоняю через локальную Qwen 2.5 32B по 200-300 запросов в день — для классификации email, транскрипции, переводов, кратких саммари статей. Если бы я делал это через OpenAI API, был бы счёт $80-150/мес. На локальном — счёт за электричество, и тот несущественный.

Третья — работа без интернета. Это не теоретическое преимущество. Я регулярно работаю в самолётах, в местах со слабой связью, в командировках по Бурятии и Монголии, где интернет идёт через спутник по 30 секунд на пакет. Локальный LLM работает одинаково везде. То же — для on-premise-внедрений в защищённых контурах, где интернет принципиально запрещён.

Четвёртая — устойчивость к блокировкам в РФ. OpenAI и Anthropic официально не доступны из России, периодически Google Gemini тоже отваливается. Бизнес, который встроил в свои процессы вызовы внешних AI-API без российской прослойки, рискует получить «упало в продакшене» в любой момент. Локальная модель — это инфраструктура, которую вы контролируете полностью.

Когда подходит локальный LLM (а когда нет)

Главная ошибка, которую я вижу: люди ставят локальную Llama 3.2 7B, задают ей вопрос уровня «разбери эту научную статью и предложи новый эксперимент», получают слабый ответ и решают, что локальный LLM — игрушка. На самом деле они просто использовали не тот инструмент. У локальных моделей очень понятная зона компетентности — и за её пределы лучше не заходить.

Мой практический критерий: если вы можете описать задачу как «возьми вот этот текст и сделай с ним вот это конкретное преобразование» — локальный LLM справится. Если задача требует размышлений вслух, перебора гипотез, нестандартных аналогий — лучше облако.

Требования к железу: сколько памяти под какую модель

В мире локальных LLM есть один главный параметр — сколько помещается в RAM/VRAM. Все остальные характеристики (скорость CPU, число ядер, тип SSD) второстепенны. Если модель не помещается в память — она будет либо не запускаться, либо ползти на скорости 0.5 токена/сек, что хуже, чем не запускаться.

Размер модели в памяти зависит от двух вещей: число параметров и quantization (битность весов). Полные веса в FP16 — это 2 байта на параметр. То есть 7B-модель в FP16 — это 14 ГБ, 70B — 140 ГБ. Никаких 140 ГБ VRAM у вас, скорее всего, нет, поэтому в практике используется quantization — сжатие весов до 4 или 5 бит без существенной потери качества.

Quantization — это процесс снижения точности весов. Был float32 — стал int4. Размер сокращается в 4-8 раз, скорость инференса растёт (меньше памяти двигать), качество падает совсем чуть-чуть. Самые популярные форматы в 2026:

• Q4_K_M — золотой стандарт. 4-битный с динамической квантизацией важных слоёв. Качество практически неотличимо от FP16 на бизнес-задачах. Размер минимальный.
• Q5_K_M — на 25% больше, чем Q4, качество ещё чуть выше. Брать, если памяти хватает.
• Q8_0 — 8-битная, размер примерно как у FP16, качество идентично. Особо смысла нет.
• IQ4_XS, IQ2_XS — экспериментальные квантизации, IQ2 экстремально маленькие, но качество страдает заметно. Брать только если совсем мало памяти.

На практике 95% моих локальных запусков — это Q4_K_M или Q5_K_M. Разница в качестве между ними и оригиналом FP16 настолько мала, что её можно увидеть только на специальных бенчмарках.

Что покупать конкретно. Для серьёзной работы с локальным LLM в 2026:

• MacBook Pro M3 Max 36 ГБ / 64 ГБ. Unified memory означает, что вся RAM доступна модели как «VRAM». 36 ГБ хватит для 32B Q4_K_M, 64 ГБ — для 70B Q4_K_M. Сборка из коробки, нулевая возня с драйверами. Мой основной рабочий ноут.
• Десктоп с RTX 4090 (24 ГБ VRAM). Идеален для 14-24B-моделей, для 70B — тесно. Скорость инференса выше, чем у MacBook, но шумнее, греется и нужно держать дома.
• Десктоп с двумя RTX 4090 / одной RTX 5090. 48 ГБ VRAM позволяют комфортно гонять 70B-модели на хорошей скорости.
• Сервер с H100 / A100. Для бизнеса, где нужно обслуживать много пользователей одновременно. Тут уже стек vLLM или TGI.

Покупать что-то слабее, чем M2 16 ГБ или RTX 3060 12 ГБ, для серьёзной работы не советую. Технически модели уровня 3B-7B на них запустятся, но качества от них на бизнес-задачах — мало.

Ollama — самый простой путь

Если вы первый раз ставите локальный LLM, ставьте Ollama. Это утилита командной строки, которая делает за вас всё: качает модели, выбирает правильный quantization, поднимает HTTP-сервер, кеширует контекст. Установка занимает 2 минуты, первый запуск — ещё 5.

Базовая последовательность для macOS/Linux:

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

# Или на macOS через Homebrew
brew install ollama

# Запуск сервиса (на Linux — через systemd)
ollama serve &

# Скачиваем и запускаем модель — первый запуск качает её (5-40 ГБ)
ollama run llama3.2

# Готовая модель доступна через CLI и через HTTP API на порту 11434
curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2",
  "prompt": "Объясни RAG простыми словами"
}'

Список самых полезных моделей, которые я держу под рукой:

• ollama pull llama3.2 — 3B-модель, мгновенная, для простых задач.
• ollama pull llama3.1:8b — основная рабочая лошадь, баланс качества и скорости.
• ollama pull qwen2.5:32b — большая модель с отличным русским.
• ollama pull qwen2.5-coder:32b — для кода, на уровне DeepSeek Coder.
• ollama pull mistral-small:24b — отличная для function calling и агентов.
• ollama pull llama3.3:70b — флагман open-source, если железо тянет.
• ollama pull nomic-embed-text — для embeddings в локальном RAG.

Что хорошо в Ollama сверх простоты установки. HTTP API совместим с OpenAI — это значит, что любой ваш код, который ходил в OpenAI, можно переключить на локальную модель одной строчкой (поменять base_url). Удобно держать модели в одном месте, есть простой синтаксис создания собственных «персон» через Modelfile. Минусы: ограниченная управляемость параметрами инференса по сравнению с llama.cpp напрямую, нет нормального batching для production.

LM Studio — GUI для тех, кто не любит терминал

LM Studio — это GUI-обёртка над тем же движком, что и Ollama (llama.cpp в основе). Скачали приложение, выбрали модель из встроенного каталога, нажали «Download», нажали «Load» — модель работает. Можно сразу болтать с ней в красивом чат-интерфейсе, не открывая ни одной командной строки.

Главное преимущество LM Studio — встроенный каталог моделей с уже подобранными quantization для вашего железа. Программа сама понимает, сколько у вас RAM/VRAM, и показывает зелёным то, что точно запустится, жёлтым — на грани, красным — не запустится. Очень удобно для новичков, которые ещё не разобрались в Q4_K_M vs Q5_K_M.

Второе преимущество — режим Local Server. Вы запускаете сервер прямо из GUI, и он предоставляет OpenAI-compatible API. То есть ваше приложение, написанное под OpenAI, можно перенаправить на http://localhost:1234/v1 и оно будет работать с локальной моделью. Удобно для разработки и быстрого прототипирования.

Когда выбирать LM Studio vs Ollama:

• LM Studio. Вы только начинаете, любите GUI, хотите быстро поэкспериментировать с разными моделями, не хотите изучать CLI.
• Ollama. Вам нужно автоматизировать запуск моделей в скриптах, использовать их в production, легче интегрировать с n8n, Python-агентами и так далее. CLI и REST API — более «инженерный» путь.

На своих ноутбуках я держу обе. LM Studio — когда нужно быстро потестить новую модель из любопытства. Ollama — для рабочих задач, скриптов, RAG-сервера.

vLLM — production-grade inference

Если у вас задача обслужить десятки или сотни запросов одновременно — Ollama и LM Studio начнут захлёбываться. Они хороши для single-user-сценария: один запрос — один ответ. Для multi-tenant прода нужно совсем другое — высокая пропускная способность через batching, эффективное использование GPU, paged attention.

vLLM — это open-source инференс-движок, разработанный командой UC Berkeley, который делает именно это. Ключевые фичи:

• Continuous batching. Запросы, пришедшие в разное время, склеиваются в один батч на GPU, что даёт 5-15× прирост throughput.
• PagedAttention. Эффективное хранение KV-кеша в страницах, как виртуальная память. Позволяет обслуживать длинные контексты без OOM.
• Speculative decoding. Маленькая модель «угадывает» несколько следующих токенов, большая — проверяет. Ускорение в 2-3 раза для типичных запросов.
• OpenAI-compatible API. Из коробки.

Пример запуска vLLM с Qwen 2.5 32B на сервере с GPU:

# Установка
pip install vllm

# Запуск OpenAI-compatible сервера
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-32B-Instruct \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.9 \
  --port 8000

# Использование как OpenAI API
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2.5-32B-Instruct",
    "messages": [{"role": "user", "content": "Привет"}]
  }'

Когда vLLM реально нужен: вы строите внутренний AI-сервис для команды или клиентов компании, на одну модель приходится больше 10 одновременных пользователей, нужно держать SLA по latency. Если ваш сценарий — один пользователь делает запросы себе на ноуте — vLLM избыточен, Ollama хватит.

Какие модели выбрать в 2026 — обзор

Каталог open-source-моделей в 2026 году огромный. Я отслеживаю около 30 — реально использую 6-7. Перечисляю те, что прошли через мои проекты.

Llama 3.3 70B

Лучшая open-source модель общего назначения. Качество вплотную приближается к GPT-4 уровня 2023-2024. Хорошо говорит по-русски (намного лучше предыдущих версий), отлично работает с function calling, поддерживает контекст 128k токенов. Q4_K_M помещается в 64 ГБ VRAM. Когда брать: задачи общего назначения, RAG, агенты, если железо тянет.

Qwen 2.5 32B (и 72B)

Китайская модель от Alibaba. По бенчмаркам на русском и английском Qwen 2.5 72B обгоняет Llama 3.3 70B. Особенно сильна в математике и кодинге. Версия Qwen 2.5 32B — отличный баланс качества и размера, работает на одном RTX 4090 в Q4. Когда брать: математика, технические тексты, мультиязычные задачи, особенно если важен китайский.

DeepSeek-V3

Frontier-модель с архитектурой MoE (Mixture of Experts). 671B параметров суммарно, но активны на каждом токене только 37B. По бенчмаркам сопоставима с GPT-4o и Claude 3.5 Sonnet. Минус — для локального запуска нужны мощные серверы с многими GPU, на ноуте не запустить. Когда брать: серьёзный production со своим сервером, нужно frontier-качество без облака.

Mistral Large 2 / Mistral Small 24B

Mistral Large 2 (123B) — топ-уровня для агентов и function calling. Mistral Small 24B — компактный балансированный вариант. Французы славятся качеством базовой математики и логики. Когда брать: AI-агенты с tools, function calling.

Phi-3 / Phi-4

Microsoft, маленькие модели (3-14B) с упором на эффективность. Phi-3-mini (3.8B) запустится даже на старом ноуте. Качество удивительно хорошее для размера, но потолок ограничен. Когда брать: слабое железо, edge-инференс, мобильные приложения.

Yi-Large / Yi-34B

Команда 01.AI Кай-Фу Ли. Отлично справляется с русским и китайским. Когда брать: контент-задачи на русском и китайском.

Gemma 2 (9B / 27B)

Open-source-линейка Google. Хорошее качество, лицензия дружелюбная к коммерческому использованию. Когда брать: альтернатива Llama, если нужна другая «школа» в ансамбле.

Бенчмарки скорости — реальные цифры из моих тестов

Цифры производительности, которые приводят производители, обычно сняты в идеальных условиях. Я мерил скорость на своих машинах на реальных задачах: chat-запросы по 200-500 токенов, RAG-запросы с контекстом 2-8k токенов. Результаты в токенах/сек на генерации:

Что эти цифры значат на практике. 30-50 токенов/сек — это скорость, на которой ответ модели читается комфортно: примерно как медленный набор текста человеком. 10-15 t/s — терпимо, но ощущается медленно. Меньше 5 t/s — раздражает, для интерактива не годится, но для batch-обработки терпимо.

Отдельно — про prompt processing speed (скорость обработки входного контекста). Для RAG это важнее, чем generation: если у вас 5000 токенов контекста и 200 токенов ответа, время «думанья» модели до первого выданного токена может быть больше, чем время генерации. На MacBook M3 Max prompt processing идёт примерно 200-400 t/s для 8B-модели, на RTX 4090 — 2000-4000 t/s. Это одна из главных причин, почему GPU всё равно ощутимо быстрее Apple Silicon для серьёзного RAG.

Интеграция с OpenAI-compatible API

Главный лайфхак локальных LLM в 2026 — почти все обёртки (Ollama, LM Studio, vLLM, llama.cpp server) предоставляют API совместимый с OpenAI. Это означает, что весь ваш код, который написан под OpenAI SDK, переключается на локальную модель сменой одной строчки — параметра base_url. Никаких переделок логики.

Пример на Python:

from openai import OpenAI

# Было — облачный OpenAI
client = OpenAI(api_key="sk-...")

# Стало — локальный Ollama на 11434
client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",  # игнорируется, но обязателен для SDK
)

# Дальше всё как раньше
response = client.chat.completions.create(
    model="llama3.1:8b",
    messages=[
        {"role": "system", "content": "Ты — помощник техподдержки IT-компании."},
        {"role": "user", "content": "Как сбросить пароль?"},
    ],
    temperature=0.3,
    max_tokens=500,
)

print(response.choices[0].message.content)

Аналогично работают LangChain, LlamaIndex, любые надстройки. В LangChain пишете ChatOpenAI(base_url="http://localhost:11434/v1", model="qwen2.5:32b") — и весь ваш agent code, RAG-пайплайн, tools работают с локальной моделью. Это позволяет разрабатывать на дешёвом локальном LLM, а перед прода переключаться на облако (или наоборот — разрабатывать с GPT-4 и потом переезжать на локалку для удешевления).

Поддерживается практически всё: function calling (через те модели, что его умеют — Mistral Small, Qwen 2.5, Llama 3.3), streaming, JSON mode, structured outputs. Различия с настоящим OpenAI API существуют, но они мелкие и связаны со специфичными фичами вроде logprobs или fingerprinting.

Локальный RAG на ноутбуке: рабочий пример

Самый частый production-кейс для локального LLM — это RAG по приватной базе знаний. Документы не покидают компьютер, ответы строятся локально. Ниже минимальный пример связки Ollama + Chroma + LangChain, который реально работает и который я использовал как стартер на нескольких проектах:

# pip install langchain langchain-community langchain-ollama chromadb

from langchain_community.document_loaders import DirectoryLoader, TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
from langchain_ollama import OllamaEmbeddings, ChatOllama
from langchain.chains import RetrievalQA

# 1. Загружаем документы из папки ./docs
loader = DirectoryLoader("./docs", glob="**/*.txt", loader_cls=TextLoader)
documents = loader.load()

# 2. Разбиваем на куски
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=100)
chunks = splitter.split_documents(documents)

# 3. Создаём embeddings и индекс через локальную модель
embeddings = OllamaEmbeddings(model="nomic-embed-text")
vectorstore = Chroma.from_documents(
    chunks,
    embedding=embeddings,
    persist_directory="./chroma_db",
)

# 4. Поднимаем LLM
llm = ChatOllama(model="qwen2.5:14b", temperature=0.2)

# 5. Создаём RetrievalQA-цепочку
qa = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=vectorstore.as_retriever(search_kwargs={"k": 4}),
    return_source_documents=True,
)

# 6. Спрашиваем
result = qa.invoke({"query": "Какие у нас регламенты по обработке жалоб?"})
print(result["result"])
for doc in result["source_documents"]:
    print("Источник:", doc.metadata.get("source"))

Это работает «из коробки» на MacBook M2/M3 16+ ГБ. Скорость: на базе из 1000 коротких документов первая индексация занимает 5-15 минут, потом ответ на вопрос — 5-15 секунд. Полностью локально, ни одного байта наружу.

Более серьёзный setup — это связка с MongoDB Atlas Vector Search (локально через self-hosted), pgvector в PostgreSQL или Qdrant. Подробнее про векторные БД — в статье о RAG-системах.

Стоимость владения — облако vs локальное

Главный экономический аргумент за локальный LLM — отсутствие затрат на токены. Но за это вы платите upfront — покупаете железо. Я свёл цифры в одну таблицу для разных профилей нагрузки.

Дополнительные факторы, которые таблица не учитывает: время разработчика на настройку и поддержку локального стека (1-3 дня для базовой настройки, плюс периодические обновления моделей), стоимость электричества при постоянной нагрузке (для MacBook незначительна, для RTX 4090 — может быть 1-3 тыс. ₽/мес), стоимость потенциального риска отказа железа.

Чистая выгода локального LLM проявляется на нагрузках от 500-1000 запросов/день. Ниже этого — облако обычно дешевле. Если же вы считаете не только деньги, но и приватность данных, юридические риски, независимость от блокировок — локальный LLM выигрывает раньше.

Безопасность и юр-нюансы в РФ

В контексте 152-ФЗ локальный LLM решает практически все вопросы одним движением. Раз персональные данные не покидают компьютер пользователя или сервер компании — нет «передачи третьим лицам», нет «трансграничной передачи», нет требования к локализации (она автоматически соблюдена). Это огромный аргумент в проектах, где вы обрабатываете клиентские данные, медицинские документы, финансовые операции и тому подобное.

Что важно настроить, даже если LLM локальный:

• Логи запросов. Если Ollama пишет логи на диск, и в логи попадают запросы клиентов с ПД — логи тоже становятся местом обработки ПД, и к ним применяются все требования 152-ФЗ. Решение — отключить логирование запросов или хранить логи в защищённом виде с ограниченным доступом.
• Сетевая изоляция. Убедитесь, что сервер с LLM не имеет исходящего трафика «в неожиданные направления». Базовая проверка через tcpdump на 30 минут работы.
• Согласие на обработку. Даже локальная обработка ПД — это обработка. Согласие нужно. Просто формулировка в политике конфиденциальности меняется: «обработка осуществляется на серверах компании на территории РФ» вместо «передаётся в OpenAI».

Подробнее про требования локализации ПД и проблематику облачных LLM в РФ — в отдельной статье.

Реальные кейсы, где я использую локальные LLM

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

1. Транскрипция голосовых заметок (Whisper local)

У меня большие голосовые сообщения в Telegram, идеи дороге, надиктовки между встречами. Whisper Large-v3 на MacBook M3 Max даёт идеальную транскрипцию русского. 1 минута аудио = 5-10 секунд обработки. Дальше Qwen 2.5 14B локально делает структурированное саммари. Полный пайплайн — 30 секунд от звуковой заметки до конспекта в Obsidian. Подробнее — в статье про AI-транскрипцию совещаний.

2. Классификация email

Локальная Llama 3.1 8B классифицирует входящие письма по 7 категориям и расставляет приоритет. Работает в Python-скрипте на cron каждые 15 минут, тег ставится в Gmail через API. 100% приватно, никто на стороне Google не видит структуры моих писем.

3. Переводы документов RU↔EN

Qwen 2.5 32B даёт качество перевода, которое раньше было только у DeepL Pro или GPT-4. Перевожу клиентские документы, договоры (в неюридическом сегменте), статьи. Не покидает ноут.

4. Code review для приватного кода

Qwen 2.5 Coder 32B на проектах под NDA, где я не могу отдавать код в Claude или GitHub Copilot. Делает базовый review, ищет очевидные ошибки и потенциальные баги.

5. Анализ корпоративных документов с ПД

На внедрениях, где у клиента строгие требования к ПД, я разворачиваю Llama 3.3 70B или Qwen 2.5 72B в их инфраструктуре. Они задают вопросы своей базе документов — модель отвечает, ни байта наружу.

5 ошибок при попытке поднять локальный LLM

За два года я насмотрелся ошибок (и сам наделал их). Топ-5 в порядке частоты.

1. Берут модель больше своего железа

Самая частая. «Скачал Llama 70B на ноут с 16 ГБ RAM, она не запускается / работает 1 токен/сек». Перед скачиванием посмотрите таблицу из раздела про железо. Если модель больше вашей RAM/VRAM — она не пойдёт нормально.

2. Не делают quantization

«Качаю модель в FP16, занимает 140 ГБ». В 2026 это нерационально — Q4_K_M даёт практически то же качество в 4 раза меньшем размере. На Ollama quantization выбирается автоматически, в LM Studio тоже. Но если работаете напрямую с llama.cpp или vLLM — следите, чтобы файл был с Q4_K_M или Q5_K_M в имени.

3. Запускают на CPU без GPU/Apple Silicon

«Купил 64 ГБ DDR5, поставил Llama 70B, оно работает». Технически да, но 1-3 токена/сек на CPU — это не работает, это мучается. Для нормальной скорости нужен либо GPU (Nvidia + CUDA), либо Apple Silicon (Metal). На обычном x86 без GPU локальный LLM практически бесполезен в интерактивном режиме.

4. Не следят за thermal throttling на MacBook

«У меня M2 показывал 30 t/s, через 5 минут стало 8 t/s». MacBook при длительной нагрузке начинает резать частоты, чтобы не перегреваться. Решения: подставка с активным охлаждением, режим Performance в Pro/Max моделях, или просто принять, что long-running генерации проседают по скорости.

5. Не понимают, что 7B-модель ≠ GPT-4

«Поставил Llama 3.2 3B, она хуже GPT-4». Конечно, хуже. У GPT-4 примерно 1.7T параметров (по оценкам), у Llama 3.2 3B — 3B. Это разные классы инструмента. Локальный LLM 7-14B сравним с GPT-3.5, 32B-70B — с GPT-4 уровня 2023 года. Имейте реалистичные ожидания и сравнивайте корректно.

Частые вопросы

Что лучше — Ollama, LM Studio или llama.cpp напрямую?

Для большинства пользователей — Ollama. Простая установка, REST API, скрипты автоматизации работают сразу. LM Studio — если предпочитаете GUI и хотите быстро поэкспериментировать. llama.cpp напрямую — если нужен максимальный контроль над параметрами инференса (нечасто).

Работают ли локальные LLM на Windows?

Да, и Ollama, и LM Studio имеют нативные Windows-версии. Через GPU Nvidia или CPU. Apple Silicon в Windows, понятно, не получится. С AMD GPU — поддержка ROCm в llama.cpp есть, но менее зрелая, чем CUDA.

Можно ли совмещать локальный LLM и облачный?

Да, это рабочая практика. Простые задачи (классификация, форматирование, краткие ответы) делает локальный LLM, сложные (frontier-reasoning, длинные креативные тексты) — облачный. Экономия 60-80% бюджета на API при сохранении качества по сложным задачам. Реализуется через router: код сначала пытается локально, если уверенности недостаточно — эскалирует в облако.

Сильно ли страдает качество от quantization?

На бизнес-задачах Q4_K_M отличается от FP16 на 1-3% в бенчмарках. На субъективном восприятии — практически неотличимо. Q3 и ниже — заметная деградация. Q5_K_M / Q6_K — золотая середина с минимальной потерей.

Безопасно ли использовать Ollama в production?

Для внутреннего сервиса в компании — да, проверено в нескольких проектах. Для публичного интернет-сервиса с тысячами пользователей — лучше vLLM или TGI, у них лучше throughput и стабильность под нагрузкой. Ollama не задумывалась как production-grade инференс-движок изначально.

Что с function calling в локальных моделях?

В 2026 уже работает нормально. Mistral Small 24B, Qwen 2.5, Llama 3.3 умеют function calling в формате OpenAI tools. Качество чуть слабее GPT-4o, но достаточно для большинства агентских сценариев. Подробнее — в статье про AI-агентов.

Можно ли локально запустить мультимодальную модель (зрение)?

Да. LLaVA, Qwen 2.5-VL, Llama 3.2 Vision — все доступны в Ollama. Работают на тех же ноутах. Качество чуть слабее GPT-4o vision, но для базовых задач (описать картинку, прочитать текст с фото, проанализировать график) — хватает.

Выводы: 5 шагов запустить первый локальный LLM сегодня

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

1. Установите Ollama. Одна команда (curl -fsSL https://ollama.com/install.sh | sh или brew install ollama). На Windows скачайте инсталлятор с ollama.com.
2. Запустите первую модель. ollama run llama3.2 — скачается за пару минут, запустится через секунду. Поболтайте с ней, оцените скорость и качество для ваших задач.
3. Подберите модель под железо. Посмотрите таблицу в разделе про железо, выберите оптимальную для вашей RAM/VRAM. Скачайте через ollama pull название.
4. Подключите к коду. Если вы что-то пишете на Python — установите openai SDK, переключите base_url на локальный Ollama, запустите свой существующий код. Должно заработать сразу.
5. Постройте первый локальный RAG. Скачайте мой пример из раздела про RAG, замените папку ./docs на вашу базу, запустите. Через 10-15 минут у вас работающая локальная база знаний.

Если на каком-то шаге упёрлись или хотите сразу делать промышленный setup без танцев с бубном — пишите. У меня готовый шаблон проекта: за неделю поставлю Ollama / LM Studio / vLLM под ваш сценарий, интегрирую с вашими сервисами, обучу команду, оставлю документацию.