Локальные нейросети 2026: как запустить у себя

Скачал файл на четыре с небольшим гигабайта, и теперь на ноутбуке живёт нейросеть, которой не нужен ни интернет, ни счётчик потраченных токенов. Вы это вообще видели?

Первый вечер я просидел за этим до ночи, а второй такой же вечер случился позже, когда до меня дошло, сколько всего она не умеет.

Если коротко, расклад такой. На рутине - разметка, извлечение полей, черновики, саммари - локальная модель на 8-30 миллиардов параметров в Q4 закрывает большую часть работы прямо на твоём железе. На сложных рассуждениях, длинном контексте и агентских цепочках она заметно слабее облачных флагманов, и никакими настройками это не чинится. Порог входа - видеокарта на 8-12 ГБ видеопамяти либо Mac на Apple Silicon с 16-32 ГБ общей. Дальше вопрос только один: что ты ей отдашь, а что оставишь наверху.

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

Чем локальный запуск отличается от облака?

Веса лежат у тебя на диске, и считает их твоя же видеокарта - на этом описание заканчивается.

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

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

Мне вот что в этом нравится больше всего: локальная модель не меняется. Она отвечает сегодня так же, как отвечала три месяца назад. Выстроил вокруг неё регламент с жёстким форматом вывода - и он не поедет от чужого релиза. В облаке это отдельная головная боль, она хорошо видна, когда сравниваешь движки под конкретную работу - об этом мы писали, когда разбирали выбор между Claude и ChatGPT.

Обратная сторона - потолок. Он задан твоим железом и не двигается от того, что кто-то там выпустил модель посильнее. Хочешь выше - иди покупай память.

Кому локальный запуск реально нужен?

Четыре причины, из-за которых это перестаёт быть игрушкой: чувствительные данные, объём однотипных задач, работа без сети и предсказуемая себестоимость. Если у тебя набирается хотя бы две из них, есть смысл сесть и посчитать, а когда не набирается ни одной, облако выйдет проще и по совокупным усилиям дешевле.

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

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

Сеть. Выезд, съёмка, самолёт, офис с кривым интернетом - модель на ноутбуке переживает всё это спокойно.

Цена. Платишь один раз за железо и потом за электричество. Никакого счётчика, который тикает, пока ты сорок раз подряд переписываешь промпт. У меня это, если честно, главный аргумент: я перестал жалеть попытки.

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

Какое железо нужно на самом деле?

Всё упирается в видеопамять, а мощность самого чипа влияет заметно меньше.

Модель должна целиком поместиться в VRAM вместе с KV-кэшем под контекст. Когда она влезла целиком, получаешь десятки токенов в секунду; стоит части слоёв уехать на процессор, скорость проседает в разы, и это чувствуется мгновенно. Второй по важности параметр - пропускная способность памяти, именно она решает, как быстро модель выдаёт текст.

Считается на пальцах: вес модели в гигабайтах ≈ число параметров в миллиардах × биты квантизации ÷ 8. Для 8B в Q4 выходит около 4,5 ГБ, а 32B в той же квантизации потребует уже 18-20 ГБ. Сверху накинь на контекст: чем длиннее окно, тем толще KV-кэш, и на 32 тысячах токенов он может съесть несколько гигабайт.

Железо	Что реально тянет	Где упрёшься
Только CPU, 16 ГБ RAM	3-8B в Q4, единицы токенов в секунду	Диалог невыносим, годится для ночной пакетной обработки
GPU 8 ГБ	7-8B в Q4, контекст 4-8k	Длинный контекст выталкивает слои на CPU
GPU 12-16 ГБ	12-14B в Q4 или 8B в Q8, контекст до 16-32k	Модели 30B+ уже не влезают целиком
GPU 24 ГБ	24-32B в Q4, контекст 32k+	Модели класса 70B только с сильным ужатием
Apple Silicon, 32-64 ГБ	14-70B в зависимости от памяти	Скорость упирается в пропускную способность у базовых чипов
Две GPU или 48+ ГБ	70B в Q4, MoE-модели крупнее	Питание, охлаждение, возня со сплитом по картам

У Apple Silicon своя арифметика. Общая память - огромный плюс: на Mac с 64 ГБ спокойно живут модели, под которые на обычном ПК пришлось бы ставить две видеокарты. Но у базовых чипов пропускная способность в разы ниже, чем у старших, и на генерации это видно невооружённым глазом. От объёма памяти зависит, влезет ли модель вообще, а скорость её речи упирается уже в пропускную способность.

И ещё один класс, который ломает привычный расклад, - MoE, смесь экспертов. Общее число параметров большое, активных на каждом шаге - маленькое. Модель на 30B с 3B активных весит как большая, а считается как маленькая. На скромном железе это часто честнее плотной модели того же размера. Если у тебя 16 ГБ и обидно - смотри туда.

Эта статья закрывает один вопрос: как поднять модель у себя и чего от неё ждать. В общей картине локальный движок - всего лишь один из моторов под цифровым сотрудником, рядом с облачным API, базой знаний и регламентом, по которому сотрудник работает. Чтобы увидеть эту картину целиком, можно забрать бесплатное обучение: доступ по почте, материал открывается сразу.

Ollama или LM Studio: что ставить первым?

Ollama живёт фоновым сервисом: командная строка, HTTP-API, модель как деталь системы. У LM Studio характер другой - окно с кнопками, каталог моделей, графики загрузки. За вечер там становится ясно, что вообще тянет твоё железо.

Здоровый путь - поставить оба и не выбирать, пока не пощупал каждый.

Инструмент	Что делает	Когда не подходит
Ollama	Ставит модель одной командой, держит её в памяти, отдаёт OpenAI-совместимый API на localhost	Нет визуального контроля загрузки, тонкая настройка через Modelfile и переменные окружения
LM Studio	GUI с поиском моделей, ползунок выгрузки слоёв на GPU, встроенный локальный сервер, MLX на Mac	Тяжелее для сервера без графики, меньше подходит как системный демон
llama.cpp	Движок под капотом у обоих, максимум контроля над флагами и квантизацией	Собирать и настраивать руками, время на изучение параметров
vLLM	Высокая пропускная способность, батчинг, отдача модели на команду	Нужна серьёзная GPU и Linux, для одного ноутбука избыточен
Open WebUI	Веб-интерфейс поверх Ollama: чаты, роли, загрузка документов, доступы	Сам модель не крутит, нужен работающий бэкенд

Мой маршрут выглядел так: сначала LM Studio, где прямо видно, сколько слоёв ушло на видеокарту, сколько осталось на процессоре и сколько токенов в секунду из этого получается. За один вечер я перещупал там штук шесть моделей и понял про своё железо больше, чем за неделю чтения форумов.

Потом, когда модель выбрана, переезжаешь на Ollama. Она поднимается как сервис, держит веса в памяти между запросами и отдаёт эндпоинт, к которому цепляется всё остальное - скрипт, n8n, свой интерфейс. Логика ровно та же, что в разговоре про то, брать ИИ-агента под ключ или собирать самому: сначала пробуешь в готовом, потом переносишь в управляемое.

Как запустить первую модель за вечер?

Ставишь движок, качаешь модель среднего размера, меряешь скорость, поднимаешь контекст, включаешь API. Полтора часа, из которых час - скачивание весов.

Первое, что я сделал неправильно, - полез за самой большой моделью, какую нашёл. Она качалась сорок минут, запустилась, выдала полтора токена в секунду и заняла всю память, так что повторять этот путь не советую.

1. Поставь движок. На Mac и Windows обе программы ставятся обычным инсталлятором. На Linux Ollama - скриптом с официального сайта. После установки проверь, что сервис жив: ollama --version и ollama list.

2. Возьми модель на 7-14B в Q4. Огромная модель в тяжёлой квантизации сейчас только собьёт тебе ориентиры, а нужна точка отсчёта, от которой можно двигаться в любую сторону. Команда вида ollama run qwen3:8b скачает веса и сразу откроет диалог. В LM Studio то же самое через поиск в каталоге и кнопку загрузки.

3. Замерь скорость. Задай длинный вопрос и посмотри на токены в секунду. Ниже десяти диалог начинает раздражать, на трёх остаётся только ночная пакетная обработка. У меня на восьмимиллиардной в Q4, когда все слои ушли на карту, текст бежал быстрее, чем я успевал читать. Потом я из интереса поднял контекст до 32k, часть слоёв выдавило на процессор - и та же модель на том же железе поползла так, что я успел сходить за чаем.

4. Подними контекст руками. Вот здесь прячется главная ловушка: по умолчанию окно урезано до нескольких тысяч токенов, модель молча обрезает начало твоего документа и отвечает мимо. Я на этом потерял вечер - скармливал ей отчёт, получал уверенную чушь и грешил на модель. В Ollama контекст задаётся параметром num_ctx - в интерактиве через /set parameter num_ctx 16384, насовсем через Modelfile. В LM Studio это ползунок в настройках загрузки.

5. Зафиксируй системный промпт. Сделай свой вариант модели с прошитой ролью, чтобы не вставлять её руками каждый раз. В Ollama это Modelfile с блоками FROM, PARAMETER и SYSTEM, дальше ollama create мойаналитик -f Modelfile.

6. Включи API и проверь его. Ollama слушает на http://localhost:11434, LM Studio - на http://localhost:1234/v1. Оба отдают OpenAI-совместимый эндпоинт: любая библиотека, умеющая ходить в OpenAI, переключается сменой base_url и фиктивного ключа.

7. Поставь интерфейс, если нужен не только ты. Open WebUI поднимается в докере и даёт чат с историей, ролями и загрузкой файлов - чтобы к модели ходил не только человек из терминала.

Ну что, уже ставил? Или до сих пор читаешь про то, как другие ставят?

Какую модель брать под какую задачу?

Универсальной локальной модели нет. Попытка найти одну на всё - самая частая потеря времени, я сам потратил на эти поиски недели две.

Держи две-три под разные роли: маленькую быструю на конвейер, среднюю на текст и рассуждения, отдельную на код. Переключение стоит одной строки в запросе.

Класс модели	Под что	Когда не подходит
3-4B, инструкционная	Классификация, теги, извлечение полей, простые переписывания	Любые рассуждения в несколько шагов, длинные документы
7-9B общего назначения	Черновики, саммари, ответы по базе знаний, чат поддержки	Юридическая точность, сложная аналитика, тонкий стиль
12-32B общего назначения	Разбор документов, аналитика, редактура, рабочий русский	Задачи, где цена ошибки высокая и нужен контроль человека
Кодовые модели	Автодополнение, рефакторинг куска, разбор незнакомого файла	Проект целиком, архитектурные решения
MoE 30B+ с малым числом активных	Хороший компромисс скорости и качества на среднем железе	Требует много памяти под веса, хоть и считает быстро
Эмбеддинги (nomic-embed, bge)	Локальный поиск по своей базе, RAG	Только векторизация текста, генерации здесь нет

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

Отдельная история - лицензия. Часть открытых моделей идёт под Apache 2.0, где разрешено практически всё, тогда как у остальных прописаны собственные условия с ограничениями по способу использования. Встраиваешь модель в продукт, который продаёшь? Тогда лицензия перестаёт быть формальностью очень быстро.

Что такое квантизация и где теряется качество?

Квантизация - это сжатие весов с 16 бит до 8, 5, 4 или ниже. Модель худеет в разы, влезает в память и считается быстрее. Качество падает нелинейно: до Q4 включительно потери обычно малозаметны, ниже начинается деградация - модель путает факты, ломает формат, теряет нить.

Правило тут простое: начинай с Q4_K_M, это разумный баланс по умолчанию. Памяти чуть больше и хочется аккуратности - бери Q5_K_M. На маленьких моделях, где вес и так невелик, а точность важна, есть смысл в Q8. Q3 и Q2 остаются режимом отчаяния, когда иначе не влезает: модель там ещё говорит, но врёт чаще и структуру держит хуже.

Главную ошибку делают вот где: берут большую модель в жёсткой квантизации вместо средней в мягкой. Чаще выигрывает второе. Модель 14B в Q5 обычно ведёт себя стабильнее, чем 32B в Q3, особенно там, где нужен строгий формат вывода.

Как понять, что пережал? Признаки узнаваемые: модель перестаёт держать JSON, добавляет пояснения там, где её просили молчать, теряет инструкцию через два абзаца. У меня Q3 однажды доехала до середины русского ответа и спокойно продолжила по-английски, как будто так и было задумано.

Увидел такое - поднимай квантизацию на ступень. Промптом это не лечится, не трать вечер. Кстати, требование строгого формата вывода отлично ложится на дисциплину из фреймворка 4D: чем точнее описано задание, тем меньше у мелкой модели шансов уехать в импровизацию.

Как подключить локальную модель к рабочим инструментам?

Через OpenAI-совместимый эндпоинт. И Ollama, и LM Studio отдают привычный /v1/chat/completions, поэтому почти любой код, библиотека или платформа автоматизации подключаются заменой базового адреса и ключа-заглушки. В этом вся практическая ценность: локальная модель встаёт на место облачной без переписывания обвязки.

Что обычно цепляют:

• Свои скрипты на Python. Официальный клиент OpenAI работает с локальным адресом, менять надо только base_url и api_key. Если ты уже собирал что-то по мотивам разбора про автоматизацию рутины на Python, переключение займёт одну строку.
• Платформы автоматизации. В n8n есть отдельный узел под Ollama, в остальных случаях подойдёт обычный HTTP-запрос на локальный адрес.
• Поиск по своим документам. Локальная модель эмбеддингов плюс векторная база дают приватный RAG, который не выносит наружу ни одного абзаца. Как готовить сами документы, разобрано в материале про то, как дать нейросети базу знаний.
• Редактор кода. Многие плагины автодополнения умеют ходить в локальный эндпоинт. Полноценную агентскую работу они не заменят - разные весовые категории, и разница хорошо видна на фоне того, что умеет Claude Code.
• Структурированный вывод. Оба движка поддерживают ответ по JSON-схеме. Для конвейерных задач включай это всегда: схема дисциплинирует мелкую модель лучше любых вежливых просьб в промпте.

И ещё одна деталь, про которую забывают на радостях. Локальная модель обслуживает один запрос за раз, если специально не настроить параллелизм. Три человека, одновременно пишущих в общий чат, встанут в очередь и будут смотреть на курсор. Для команды это решается либо очередью на стороне обвязки, либо переездом на vLLM с нормальным батчингом.

Где локальная модель честно проигрывает облаку?

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

Длинный контекст. В карточке модели может стоять окно на сто тысяч токенов, но на твоём железе столько не влезет по памяти. А если влезет - внимание маленькой модели к середине документа проседает сильнее, чем у больших. Договор на сорок страниц она прочитает и пропустит ровно тот пункт, ради которого ты её звал. Как вычитывать документы аккуратно, разбирали в статье про Claude для договоров.

Многошаговые рассуждения. Задачи, где надо удержать пять условий и не потерять ни одного, ломают мелкие модели предсказуемо. Ответ выйдет правдоподобным ровно до первой проверки.

Агентская работа. Вызов инструментов, планирование, самопроверка, откат после ошибки - тут разрыв максимальный. Локальные модели умеют вызывать функции, но цепочка из пяти шагов рассыпается где-то на третьем. Про то, как устроены рабочие цепочки, есть подробный разбор агентов и субагентов.

Редкие знания. Специфика отрасли, свежие изменения, региональные нюансы. У маленькой модели этого просто нет в весах, и она добросовестно всё придумает. Границы, за которыми любая модель начинает сочинять, мы собирали в материале про честные границы нейросетей - у локальных они просто ближе.

Мультимодальность. Картинки и сканы локальные модели читают, но до уровня облачного зрения этому пока далеко.

Какие задачи отдавать локально, а какие оставить в облаке?

Вниз уходит то, что повторяется, имеет чёткий формат и не требует глубокого рассуждения. Облаку достаются задачи с высокой ценой ошибки, длинным контекстом и работой в несколько шагов. Всё спорное решается замером на твоих собственных данных; спор в комментариях тут не помогает никому.

Задача	Где делать	Почему
Классификация тикетов и лидов	Локально	Конвейер, короткий вход, проверяемый выход
Извлечение полей из документов	Локально	Строгая схема, много однотипных прогонов, чувствительные данные
Черновик поста или письма	Локально	Правится человеком в любом случае
Расшифровка и саммари встречи	Локально	Приватность разговора важнее пары процентов качества
Ответы поддержки по базе знаний	Локально с проверкой	Конвейер, но нужна страховка на спорных ответах
Разбор договора, юридический риск	Облако	Длинный контекст, высокая цена ошибки
Финансовая и продуктовая аналитика	Облако	Многошаговое рассуждение, надо удержать десяток условий
Агентские цепочки с инструментами	Облако	Локальные модели рассыпаются на длинных сценариях
Код проекта целиком	Облако	Требуется навигация по репозиторию и планирование
Стратегия, позиционирование, решения	Ты сам	Подписывать всё равно тебе

Тут легко перепутать уровни. Локальная модель работает движком, а роль, регламент, участок ответственности и проверка результата живут отдельно от того, какая железка крутит веса, - ровно об этом разбор цифрового сотрудника. Когда контур собран, смена движка сводится к правке одной настройки, а без контура локальная модель осядет очередной игрушкой в папке «Загрузки». У меня там таких лежало три штуки.

Что ломается на практике и как это чинить?

Почти всё, что ломалось лично у меня, сводилось к четырём причинам: модель не влезла в память целиком, контекст молча обрезается, шаблон промпта не совпал с тем, на котором модель училась, температура выставлена под творчество там, где нужна точность. Все четыре лечатся настройками, менять саму модель не приходится.

Скорость упала в разы. Проверь, сколько слоёв реально на GPU. В LM Studio это видно на индикаторе, в Ollama - через ollama ps, там показан процент выгрузки. Частая причина: поднял контекст, KV-кэш вырос, часть слоёв выдавило на процессор.

Модель отвечает не про то, что в документе. Почти всегда обрезанный контекст. Подними num_ctx и убедись, что документ помещается. Проверяется за минуту: вставь в начало текста метку вроде «кодовое слово ГРАНАТ» и попроси модель его назвать. Не назвала - она твоё начало не видела.

Ломается JSON. Включи структурированный вывод по схеме вместо просьбы «ответь только JSON». Движок не поддерживает - снижай температуру до 0-0.2 и дай два примера правильного ответа прямо в промпте.

Модель болтает и не выполняет инструкцию. Мелкие модели плохо держат многосоставные задания. Разбей на шаги, по одному действию за вызов. Вместо «проанализируй и напиши выводы с рекомендациями» проси «выпиши три факта из текста списком, без комментариев».

Ответы стали случайными. Проверь temperature, top_p и seed. Для конвейера ставь температуру около нуля и фиксируй seed. Тогда одинаковый вход даёт одинаковый выход, и ты начинаешь ловить регрессии вместо того, чтобы гадать.

Кончилась память при долгой работе. Ollama держит модель в памяти после запроса, время удержания настраивается. И если параллельно крутятся две модели, они делят видеопамять и обе работают плохо. Угадай, сколько я это искал.

Память течёт на Windows с несколькими GPU. Разнородные карты сплитятся отвратительно. Проще отключить вторую для задачи, чем бороться с распределением слоёв.

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

Ты извлекаешь данные из текста счёта. Отвечай только JSON по схеме.
Поля: номер, дата, поставщик, сумма_без_ндс, ндс, итого.
Если поля нет в тексте - ставь null. Ничего не додумывай.
Не добавляй пояснений до или после JSON.

Коротко, одна задача, явный запрет на самодеятельность, прямое указание, что делать с пропуском. Именно эти вещи мелкая модель теряет первыми.

Как проверить, что модель отвечает нормально?

Собери свой мини-набор из 20-30 реальных задач с эталонными ответами и прогоняй по нему каждую новую модель. Публичные бенчмарки показывают среднюю температуру по больнице, а твой набор - состояние конкретно твоей работы, и разница между этими двумя картинками принципиальная.

Как это делается руками:

1. Возьми реальные входы. Двадцать настоящих тикетов, накладных, писем - тех, что уже прошли через тебя.
2. Запиши эталон. Для каждого входа зафиксируй ответ, который считаешь правильным. Для классификации это метка, для извлечения - JSON, для текста - три критерия, которым он должен соответствовать.
3. Прогони и посчитай. Где ответ чёткий, точность считается напрямую. Тексты оценивай по критериям руками, это быстрее, чем кажется.
4. Зафиксируй время. Средняя скорость ответа именно на твоих задачах; синтетический тест тут ничего полезного не скажет.
5. Сравни с облаком. Тот же набор прогони через облачную модель. Разрыв может оказаться копеечным, а может зияющим - вот это и решает, стоит ли переезжать.
6. Повторяй при каждой смене. Новая версия движка, другая квантизация, обновлённые веса. Прогон занимает минуты и ловит регрессию раньше, чем её поймает клиент.

Скучно ли это? Ещё как, но после такого набора вопрос наконец звучит по-человечески: справляется эта модель с моими задачами при моих ограничениях или нет. Тот же подход лежит в основе разбора о том, какие вопросы задавать ИИ в бизнес-аналитике - сначала формулируешь проверяемый вопрос, потом ищешь инструмент.

Сколько это стоит и когда имеет смысл?

Софт бесплатный, модели бесплатные, платишь только за железо и электричество. Видеокарта на 16-24 ГБ или Mac с большой памятью - заметная разовая покупка, которую надо чем-то оправдать. Экономика сходится, когда есть постоянный поток однотипных задач или требование не выпускать данные наружу.

Считать имеет смысл по трём строкам, и цена токена среди них далеко не главная: разовые вложения в железо, твоё время на настройку и поддержку, стоимость ошибок, которые придётся вычищать руками. Третья строка обычно и решает. Модель, которая ошибается чаще, но работает бесплатно, съедает разницу человеко-часами редактуры - и ты этого не замечаешь, пока не начнёшь их считать.

Когда точно не окупается:

• задач мало, десятки в месяц;
• каждая задача уникальная и требует рассуждения;
• некому обслуживать, и при первой поломке всё встанет;
• данные не секретные, а подписка на облако уже оплачена.

А вот при каких условиях вложение себя оправдывает:

• регулярный конвейер на тысячи однотипных операций;
• работа с чувствительными документами и клиентскими данными;
• нужна независимость от чужого апдейта и стабильное поведение системы;
• есть человек, которому интересно это поддерживать.

У меня сейчас так: конвейер с накладными и тикетами внизу, разбор договоров и аналитика наверху, спорное - через свой набор из тридцати задач. Пересобираю раскладку примерно раз в квартал, потому что модели меняются быстрее, чем привычки.

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

А у тебя какая задача первой поедет вниз? Или уже поехала и что-то сломалось?

Источники

• Репозиторий и документация Ollama - установка, API, Modelfile, переменные окружения
• Каталог моделей Ollama - доступные модели, размеры и теги квантизации
• Документация LM Studio - GUI, локальный сервер, настройки загрузки моделей
• llama.cpp - движок под капотом большинства локальных запусков, форматы GGUF и типы квантизации
• Hugging Face Models - веса, карточки моделей и лицензии
• Документация vLLM - высокопроизводительная отдача моделей, батчинг и параллелизм
• Open WebUI - веб-интерфейс поверх локального бэкенда
• Анонс gpt-oss от OpenAI - открытые модели под Apache 2.0
• Блог Qwen про Qwen3 - линейка моделей, включая MoE-варианты
• Документация Gemma - открытые модели Google и условия использования
• Сайт Llama - модели Meta и текст лицензии
• lm-evaluation-harness - инструмент для воспроизводимой оценки моделей на своих задачах