В мае 2026 года команда разработчиков из небольшой российской компании описала на Хабре сюжет, который мне потом приходилось слышать в разных вариациях ещё несколько раз. Их корпоративный AI-ассистент работал на Google Gemini API. Однажды в чат-бот пришло сообщение: «Меня зовут Дмитрий, наша компания ООО Ромашка, телефон +7 903 123-45-67». Сообщение ушло на серверы Google в США — в точности в таком виде.

Персональные данные гражданина России, обработанные за рубежом, без уведомления Роскомнадзора и без отдельного согласия субъекта. Формально — нарушение статьи 12 Федерального закона № 152-ФЗ «О персональных данных». Штрафы по ней начинаются от трёх миллионов рублей.

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

Я начинаю с этой истории, потому что она отвечает на вопрос, который встанет перед читателем после глав 1–4: «окей, я разобрался, что такое LLM (большая языковая модель) и что она умеет, — но на чьём сервере ей работать?». В 2026 году у этого вопроса нет одного ответа. Формула простая: облачные API (программные интерфейсы, через которые приложения общаются с моделью) дают доступ к самым сильным моделям сегодняшнего дня — ценой отправки данных провайдеру на его серверы. Локальный запуск даёт контроль над данными и предсказуемость расходов — ценой железа и инженерного времени. В этой главе я разберу, когда что выбирать, и дам пять рабочих рекомендаций, каждая опирается на факты.

ОБЛАКО ПРОТИВ ЛОКАЛЬНОЙ МОДЕЛИ: ЛОГИКА ВЫБОРА

Когда я спрашиваю знакомых руководителей «почему вы в облаке», самый частый ответ — «потому что так быстрее запустить». Пять минут на получение ключа API — и у вас работает GPT-5, Claude Opus 4.8 или Gemini 3 Pro. Когда спрашиваю «почему вы на локальном запуске», самый частый ответ — «потому что данные не должны уходить из компании». Оба ответа правильные, но оба неполные.

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

ПРОПУСКНАЯ СПОСОБНОСТЬ ПАМЯТИ ВАЖНЕЕ ОБЪЁМА VRAM

Первое и самое важное: скорость локальной модели определяет не объём VRAM (видеопамяти GPU), а пропускная способность памяти. На одной RTX 5090 пропускная способность памяти — 1 792 ГБ/с, на Mac Studio M4 Max — 546 ГБ/с, на Mac mini M4 Pro — 273 ГБ/с. Разница в 3,3 и 6,6 раза — и она решает, сколько токенов в секунду вы получите на одной и той же квантованной модели.

Когда компания покупает железо «под локальную LLM», она покупает не ядра CUDA и не терафлопсы. Она покупает ширину шоссе, по которому веса модели едут к GPU. Bizon Tech (поставщик AI-рабочих станций) формулирует это в начале 2026 года коротко: «Представьте шоссе: объём памяти — это парковка в конце, а пропускная способность — число полос».

Аналогия с шоссе объясняет неожиданный разворот: Mac Studio с 192 ГБ унифицированной памяти тянет Qwen 3.5 235B-A22B в Q4, но выдаёт всего четыре токена в секунду. А RTX 5090 с 32 ГБ на скромной модели 8B выдаёт 50+ токенов в секунду. Почему?

У шоссе с четырьмя полосами (RTX 5090) — высокая пропускная способность при ограниченной ёмкости. У шоссе с двумя полосами и большой парковкой (Mac Studio) — наоборот. Выбор железа — это выбор дистанции, на которую модель поедет с приемлемой скоростью.

СТЕК ИНСТРУМЕНТОВ: OLLAMA, VLLM И LLAMA.CPP

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

Ollama — обёртка вокруг llama.cpp, ставится одной командой ollama run llama3.1:8b. vLLM — production-grade решение на Python с PagedAttention, и это позволяет держать в памяти сотни одновременных сессий. На одной H100 vLLM выдаёт 1 450 токенов в секунду при 32 одновременных запросах, Ollama на той же нагрузке — 320 токенов в секунду, а после 40 запросов начинает падать в OOM (Out of Memory — нехватка видеопамяти). llama.cpp — низкоуровневая библиотека на C++, на которой стоят и Ollama, и LM Studio. Она работает везде (CPU — центральный процессор, Apple Silicon Metal, NVIDIA CUDA, AMD ROCm) и даёт максимальную производительность на Mac за счёт прямого доступа к Metal API.

Архитектурные различия между этими тремя инструментами разберём в следующем подразделе, а пока зафиксируем практический вывод от Spheron (компания строит децентрализованную облачную инфраструктуру для AI/ML): выбор инструмента запуска часто важнее выбора модели. Одна и та же Llama 3.1 8B выдаёт 62 токена в секунду в Ollama и 71 в vLLM на одном пользователе. На 50 одновременных пользователях разница вырастает до 155 против 920 токенов в секунду.

TCO: ИНЖЕНЕРНОЕ ВРЕМЯ КАК СКРЫТАЯ СТАТЬЯ РАСХОДОВ

Третье: скрытая статья TCO (Total Cost of Ownership, полная стоимость владения) — инженерное время, а не электричество.

По данным MPT Solutions за сентябрь 2025 года, аудит реальных корпоративных развёртываний показал следующее. Если команда из трёх DevOps-инженеров тратит на локальный запуск LLM по 20% рабочего времени при ставке 5 000 долларов в месяц, это 3 000 долларов «в тени» — не отражается ни в счёте за электричество, ни в строке «GPU». SitePoint (онлайн-издание и консалтинговая площадка для веб-разработчиков) в марте 2026 года построил полную 12- и 36-месячную TCO-модель и пришёл к выводу: для большинства стартапов с переменной нагрузкой облачные API остаются выгоднее, пока устойчивая загрузка не превышает 20% мощности. За этим порогом локальное развёртывание выигрывает по экономике токенов и окупается за 18–24 месяца. По данным технического документа Lenovo Press за 2026 год, точка безубыточности при высокой загрузке — менее 4 месяцев, а модель расчёта «Token Economics» (экономика токенов) даёт до 18-кратного преимущества по стоимости на миллион токенов.

Три числа на разных условиях сходятся в одну картину: при идеальной загрузке локальное развёртывание окупается за 4 месяца, при типичной — за 18–24 месяца. А как только в смету попадает реальная стоимость инженерного времени — почти никогда. Разброс большой, но он отражает разные сценарии, а не противоречие в источниках. В реальности для команды 3–6 человек с объёмом 200–300 млн токенов в месяц прямые расходы на локальный запуск окупаются за 7–8 месяцев, но как только в смету попадает реальная стоимость инженерного времени, эта экономия размывается до тонкой плёнки.

ПРАВОВАЯ РАМКА: 152-ФЗ И EU AI ACT

Четвёртое: регуляторная рамка в 2026 году давит в сторону локального развёртывания сильнее, чем год назад. Статья 12 Федерального закона № 152-ФЗ требует уведомления Роскомнадзора и согласия субъекта при трансграничной передаче персональных данных. С 1 июля 2025 года ужесточаются требования по локализации данных граждан РФ.

Для компаний с европейскими клиентами или филиалами дополнительно начинает действовать EU AI Act. С 2 августа 2026 года он становится полностью применимым для большинства обязательств, включая Статью 10 о качестве данных, риск-менеджменте, прозрачности и человеческом контроле. Для систем высокого риска провайдеры обязаны продемонстрировать качество данных, техническую документацию, логирование и пост-маркетинговое наблюдение на всём протяжении конвейера.

Облачный API со сторонним логированием существенно усложняет аудиторский след. Для регулируемых отраслей в ЕС суверенная инфраструктура или локальное развёртывание с документированной цепочкой хранения — это уже не выбор, а обязательное требование.

MindStudio в обзоре мая 2026 года формулирует это без обиняков: «Не важно, насколько хороши политики обработки данных у OpenAI, — если у юридического отдела есть сомнения, локальный инференс снимает проблему на уровне архитектуры». Юридический слой остаётся за юристами, но техническая архитектура должна им помогать. Локальный запуск снимает 152-ФЗ и EU AI Act на уровне железа, а не на уровне договора с провайдером.

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

Первый миф: «облако дешевле локального запуска». Он верен только на старте, при малых объёмах и переменной нагрузке. При стабильных 200+ миллионах токенов в месяц локальная инфраструктура дешевле по прямым расходам — но дороже по полной стоимости с учётом инженерного времени. Компании либо переплачивают за облако при больших объёмах, либо влезают в скрытые расходы на локальное развёртывание при малых, не понимая, в какой точке они находятся.

Второй миф: «локальный запуск привязывает к поставщику». На деле он эту привязку снимает. Смена поставщика облака — это смена API и промптов, она стоит команде недель миграции. Локальная модель снимает привязку к чужому API на уровне архитектуры: open-weights модели (модели с открытыми весами) скачиваются, переносятся между серверами, обходятся без подписки. Переключение с Ollama на vLLM не требует переписывать ни одного запроса. OpenAI, Anthropic, Google не дадут унести GPT-5 или Claude Opus 4.8 на свою флешку. Meta, Alibaba, Google DeepMind дают скачать Llama 4, Qwen 3.5, Gemma 4. Это структурная разница, и она не в пользу облака.

ВЫБОР ИНСТРУМЕНТА ПОД КОНКРЕТНУЮ ЗАДАЧУ

Команды, которые запускают первую локальную модель, обычно задаются одним вопросом: «что ставить, Ollama или vLLM?». Типичный сценарий выглядит так. Небольшой отдел — аналитик, разработчик, иногда руководитель проекта — берёт корпоративный MacBook на 32 ГБ, ставит Ollama за пять минут, гоняет 8B-модель, радуется скорости. Потом зовёт коллег. И в этот момент очередь запросов встаёт: Ollama обрабатывает их по одному.

После этого команда делится на два лагеря: те, кто возвращаются в облако, и те, кто разворачивают vLLM на сервере с GPU. Правильный ответ на вопрос «что ставить» зависит не от инструмента, а от задачи: Ollama — для одного пользователя или маленькой команды, vLLM — для десятков одновременных сессий, llama.cpp — там, где нет дискретной видеокарты. У каждого своя задача, и ставить один вместо другого бессмысленно.

OLLAMA: ПРОСТОТА КАК ПРИОРИТЕТ

Ollama — это «Docker для LLM». Идея простая: одна команда ollama run llama3.1:8b, через полторы минуты модель отвечает в терминале, через 5 минут работает локальный API на порту 11434, через 10 минут к нему подключается Open WebUI с интерфейсом «как у ChatGPT». Сильная сторона Ollama — удобство без архитектурных деталей: её устанавливают те, кто не хочет вникать в GPU. Цена удобства — отсутствие оптимизации под многопользовательский режим: запросы обрабатываются последовательно, через очередь, и под нагрузкой латентность между токенами (Inter Token Latency, ITL) становится нестабильной с резкими пиками.

На тесте SitePoint с RTX 4090 и Llama 3.1 8B при 50 одновременных пользователях Ollama удерживает потребление VRAM (видеопамяти GPU) на уровне 5,4 ГБ. Причина простая: она обрабатывает запросы по одному. Это не дефект — это архитектурное решение. Один медленный запрос блокирует всю очередь. vLLM с этим справляется лучше, но Ollama проще в развёртывании.

VLLM: ИНСТРУМЕНТ ДЛЯ ПРОМЫШЛЕННОЙ НАГРУЗКИ

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

Ключевая идея, которая делает vLLM быстрым, называется PagedAttention. Если не вдаваться в детали, идея такая: модель во время работы держит в памяти «промежуточные заметки» по каждому запросу (в технической терминологии — KV-кеш). Без умной организации эти заметки занимают память неэффективно. PagedAttention разбивает их на маленькие блоки, как страницы в книге, и собирает по мере надобности. За счёт этого видеокарта загружается на 85–92% вместо обычных 60–70%, и в неё влезает в 4–5 раз больше одновременных запросов.

Чтобы вы почувствовали разницу: vLLM на одной карте H100 80 ГБ держит 180+ параллельных запросов. Ollama на той же карте — 40, после чего падает. Это не «немного быстрее», это другой порядок величины.

Но за это приходится платить. vLLM требует развёртывания в Docker-контейнере (это такая стандартная «упаковка» для серверных приложений) и ручной настройки параметров видеокарты. Время от нуля до работающего сервера — от пяти минут до двух часов в зависимости от модели и опыта. Для офисной команды, в которой нет DevOps-инженера, это серьёзный барьер. Итог: vLLM — это для команд, которые понимают, что делают, и готовы вложиться в настройку один раз, чтобы потом обслуживать десятки пользователей.

LLAMA.CPP: МИНИМАЛИЗМ НА СЛУЖБЕ ЛОКАЛЬНОГО ЗАПУСКА

llama.cpp — это «движок-основа», на котором стоят Ollama и LM Studio. Он умеет запускать модели там, где Ollama и vLLM не справляются: на обычном процессоре (CPU) без видеокарты, на старых ноутбуках, на Raspberry Pi, на граничных устройствах вроде кассовых аппаратов или промышленных контроллеров. На Mac с чипами M-серии llama.cpp напрямую работает с Metal (встроенный графический API Apple) и часто обгоняет Ollama по скорости.

Сильная сторона llama.cpp — поддержка квантования в широком диапазоне, от 1.5 до 8 бит. Квантование — это способ уменьшить размер модели за счёт потери точности вычислений. Модель в 8-битном квантовании занимает вдвое меньше памяти, чем оригинал, и работает быстрее, но иногда чуть хуже отвечает. На llama.cpp есть целая линейка квантов: Q4, Q5, Q6, Q8 с разными суффиксами — для разных задач подходят разные. Подробно про квантование — в разделе «Квантование» ниже.

Слабое место llama.cpp — линейная очередь. Когда запросы идут один за другим от разных пользователей, каждый следующий ждёт, пока предыдущий не закончится. Это работает для одного человека или маленькой команды, но при многопользовательской нагрузке vLLM обгоняет в десятки раз.

Три инструмента — три разных рынка. Ollama — для офисной команды без DevOps-инженера, как норма. vLLM — для команды с DevOps, которая обслуживает десятки пользователей с SLA (соглашением об уровне сервиса, где зафиксировано максимальное время ответа). llama.cpp — для граничных устройств и Apple Silicon. У каждого своя ниша, и подменять один другим — значит тратить ресурсы не на ту задачу.

ЛОКАЛЬНЫЕ МОДЕЛИ 2026 ГОДА: ЧТО РЕАЛЬНО ЗАПУСКАЕТСЯ НА ПРАКТИКЕ

Рынок открытых моделей в 2026 году делится на пять семейств, и в апреле этого же года произошло событие, которое я бы назвал переломным: пять крупных релизов открытых весов за 21 день. 2 апреля Google DeepMind выпустил Gemma 4 под Apache 2.0, впервые без кастомной проприетарной лицензии. 7 апреля Z.ai выложил веса GLM-5.1. 11 апреля на Hugging Face появились контрольные точки MiniMax M2.7. 16 апреля Alibaba выкатила Qwen3.6-35B-A3B. 23 апреля DeepSeek выпустил V4-Pro с 1,6 триллиона параметров и V4-Flash.

По оценке обзора AI-моделей Modem Guides, это «даже по стандартам 2026 года необычно», и это мягкая формулировка: открытые модели перестали быть «отстающей альтернативой проприетарным», они стали параллельным стеком, который обновляется быстрее, чем проприетарный флагман успевает пройти ревью безопасности.

ЛИНЕЙКА СОВМЕСТИМОСТИ: ЧТО ЗАПУСТИТСЯ НА ЧЁМ

Что забираем из этого раздела — линейка «что запустится на чём». Шесть конфигураций памяти, от ноутбука до рабочей станции, и модель, которая на каждой запустится с приемлемой скоростью.

АРХИТЕКТУРНЫЙ СДВИГ 2026 ГОДА: СМЕСЬ ЭКСПЕРТОВ (MOE)

Архитектурный сдвиг 2026 года — Mixture of Experts. Это архитектура, в которой для каждого токена активна только часть параметров модели. Четыре модели с разным балансом общих и активных параметров показывают, как MoE даёт «большой мозг при маленьком аппетите»: качество 200B+ модели при скорости 20B-модели без разреженной активации (dense).

AI Magicx в обзоре 2026 года сформулировал это так: «интеллект большой модели при ресурсных требованиях маленькой». Именно MoE позволяет запускать «большие» модели на потребительском железе. Именно поэтому открытые веса впервые в истории конкурируют с проприетарными флагманами на реальных задачах, а не на синтетических бенчмарках. Саймон Уиллисон (Simon Willison) в блоге 16 апреля 2026 года показал: Qwen3.6-35B-A3B (20,9 ГБ на диске) на MacBook побил Claude Opus 4.7 на известном «пеликан-тесте» (тест на длинные ответы).

Граница «фронтира» в 2026 году проходит не между открытым и закрытым, а между тем, кто умеет запускать локально, и тем, кто платит за API. Это правда, но с оговоркой. MindStudio в обзоре мая 2026 года добавляет нюанс: открытые веса в среднем отстают от передовых проприетарных моделей на 3–6 месяцев. Этот разрыв критичен для задач со сложным многошаговым рассуждением, генерацией кода на уровне продакшна, плотным разбором юридических контрактов. Для рутинных офисных задач — резюмирование, черновики писем, извлечение данных из таблиц — разрыв практически незаметен.

И ещё один миф, который удерживает людей на облачных подписках: «если модель большая, её нельзя запустить локально». Для офисных задач 70B-модель в Q4 запускается на двух картах по 24 ГБ или на одной с 48 ГБ VRAM (например, RTX 6000 Ada или A6000), а 35B-A3B MoE умещается в 20,9 ГБ одной карты. Размер перестал быть ограничением. Вопрос теперь не «потянет ли мой ноутбук», а «какой квант и какая скорость меня устроят».

Один и тот же сотрудник в одной компании может параллельно использовать локальный Llama 4 Scout 109B для черновиков и облачный Claude Opus 4.8 для юридических заключений. Это нормальная гибридная архитектура, а не «нерешительность»: локальный запуск закрывает рутину, облако — критичные по качеству задачи.

КВАНТОВАНИЕ: СЖАТИЕ МОДЕЛИ БЕЗ ПОТЕРИ КАЧЕСТВА

Представьте, что модель — это книга, в которой десятки миллиардов чисел (так называемые «веса», параметры нейросети). Каждое число занимает память. Квантование — это способ записать эти числа менее точно, но сэкономить место.

Простой пример. Число 3,14159265 можно записать как «3» (один знак), и это квантование с потерей точности. Для большинства задач «3» достаточно, а не «3,14159265». В квантовании нейросетей работает та же логика: вместо 16-битного числа (огромная точность) записываем 4-битное (16 возможных значений), и точность хранения падает, но для большинства задач это незаметно.

Вот что это даёт на практике. Модель размером 8 ГБ в 16-битном формате после 4-битного квантования превращается в 4 ГБ. На ту же видеокарту влезает модель вдвое большего размера, или та же модель работает вдвое быстрее, или обслуживает вдвое больше пользователей одновременно.

Миф, который стоит развеять сразу: «квантованная модель — это плохо». На практике 4-битное квантование для большинства офисных задач неотличимо от 16-битного оригинала. Качество страдает только в двух сценариях: сложные многошаговые рассуждения (математика, логические цепочки на пять и более шагов) и редкие узкоспециальные термины. Для первого есть метод цепочки рассуждений (когда модель сначала показывает ход мысли, а потом даёт ответ) и приём «несколько примеров» (когда в промпт добавляют 2–5 готовых образцов «вопрос-ответ», и модель продолжает по образцу). Для второго — поиск по вашей базе документов с генерацией ответа (когда модель сначала находит релевантные фрагменты, а потом отвечает по ним). Исследование «Quantization Hurts Reasoning?» (COLM 2025) даёт офисному читателю главное — таблицу дозволенного:

Это значит, что для модели с 7 миллиардами параметров 3-битный квант даёт ошибки, превышающие 10%, и качество становится неприемлемым, а 8-битный — приемлемое.

ВЫБОР КВАНТА ПОД ЗАДАЧУ

Самый популярный квант в экосистеме GGUF — Q4_K_M, и это не случайность. Обзор Kaitchup за октябрь 2025 года формулирует правило прямо: Q4_K_M — рабочая лошадка для 4-битных развёртываний, Q5_K_M — высококачественная настройка с почти незаметной деградацией для большинства задач, Q6_K — выбор, когда нужно «почти без потерь», но всё ещё сэкономить память.

Для офисного пользователя, который открывает Ollama и выбирает тег по умолчанию, Q4_K_M закрывает 90% запросов. Переходить на Q5_K_M или Q6_K имеет смысл, только если вы замерили провал на конкретной задаче. Не «на всякий случай», а по факту.

ЖЕЛЕЗО КАК ОГРАНИЧИТЕЛЬ ВЫБОРА КВАНТА

Железо определяет выбор кванта сильнее, чем выбор модели. На Apple M3 Ultra 96 ГБ разница между Q4_K_M и Q8_0 у Qwen3-14B видна невооружённым глазом: 70,33 токена в секунду против 41,51. Q8 замедляет генерацию почти вдвое. Файл вырастает с 8,32 ГБ до 15,71 ГБ. На 32B-моделях картина жёстче: Q4_K_M даёт 33,88 токена в секунду, Q8_0 — 20,11, а BF16 (16-битный формат, отличается от FP16 расширенным диапазоном) падает до 10,76.

Скорость — не второстепенный параметр. Когда бухгалтер ждёт от модели ответа на «разнеси платёжки по контрагентам», разница между 33 и 11 токенами в секунду превращается из «удобно» в «невозможно работать». Сначала определитесь с железом, потом подбирайте квант под него.

Если задача — «найти баг в распределённой системе по логам», квантование даст о себе знать. В этом случае либо переходите на Q5_K_M / Q6_K, либо возвращайтесь в облако для критичных задач. Для рутинных офисных задач — резюме, черновики, классификация, извлечение данных — локальная 70B-модель в Q4_K_M неотличима от облачной.

НАДСТРОЙКИ ПОВЕРХ ЛОКАЛЬНОЙ МОДЕЛИ

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

VPS: КОМПРОМИССНЫЙ ПРОМЕЖУТОЧНЫЙ ВАРИАНТ

Между «облаком провайдера» и «локальным сервером в офисе» есть третий путь, и для команды 3–6 человек он часто оказывается самым практичным. Это виртуальный частный сервер (VPS, Virtual Private Server) — арендованная виртуальная машина у российского или зарубежного провайдера (Selectel, Timeweb Cloud, Hetzner, AWS Lightsail), где Ollama или vLLM разворачивается как в офисе, но без покупки собственного железа и без отправки данных в публичное облако уровня OpenAI.

По цене в 2026 году типичный VPS с одной дискретной GPU уровня RTX 4090 обходится в 18–30 тысяч рублей в месяц. Для команды с устойчивыми 100+ млн токенов в месяц это дешевле подписки на облачный API и не требует отдельного инженера в штате — провайдер берёт на себя замену дисков, резервное питание и сетевую связность.

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

Выбор между VPS, локальным сервером и облачным API — это выбор между фиксированной ежемесячной ценой (VPS), капитальной затратой с нулевой абонентской платой (локальный сервер) и поштучной оплатой по объёму (облачный API). Подробное сравнение стоимости и требований к железу для VPS раскроем в следующем разделе.

ЛОКАЛЬНЫЕ АГЕНТЫ НА СОБСТВЕННОЙ ИНФРАСТРУКТУРЕ

Над локальной моделью — агенты. Они не просто отвечают на запрос, а сами вызывают инструменты, читают файлы и принимают решения. Локальный агент в 2026 году — это комбинация из LLM (через Ollama или vLLM), фреймворка (LangGraph, CrewAI, AutoGen — библиотеки для построения многошаговых AI-агентов) и набора инструментов (поиск в файлах, доступ к API, запуск скриптов). Все три компонента работают локально, без обращения к облаку. Это полноценная альтернатива облачным агентам типа ChatGPT agent или Claude Computer Use (агент Anthropic, который управляет компьютером как человек — кликает, водит мышью), с одним принципиальным отличием: данные остаются в офисе.

Агенты 2026 года делятся на три класса, и смешение их в одну кучу — типовая ошибка выбора. Универсальные агенты (Hermes Agent, Claude Code) — ассистенты общего профиля, которые умеют читать почту, бронировать встречи, вызывать API, генерировать код. Специализированные агенты для кодинга (Cursor CLI, Aider) — узкие инструменты с глубокой интеграцией в IDE (Integrated Development Environment, интегрированная среда разработки — редактор кода типа VS Code или JetBrains), Git, файловую систему и тестовые фреймворки. Узкие агенты под конкретные вертикали: поддержка (Decagon), продажи (Clay), извлечение данных из документов (Agentic Document Extraction). Три класса — три разных рынка: цена, лицензия, модель под капотом, аудитория — всё разное.

Среди open-source агентов для разработчиков в 2026 году выделяются три имени, которые чаще других попадаются в обзорах и в практике команд. Claude Code от Anthropic — терминальный агент для разработчиков, запускается в директории проекта, читает код и пишет тесты. Минус — облако Anthropic, локально не запускается, и весь код уходит на серверы. OpenClaw (Питер Штейнбергер, Peter Steinberger, MIT) — самохостируемый open-source агент с поддержкой 50+ мессенджеров и проверкой безопасности сценариев работы через NVIDIA SkillSpector. Режим автономных действий требует явного согласия пользователя, и критичные операции проходят только через human-in-the-loop. Hermes Agent от Nous Research (MIT, февраль 2026) — самохостируемый агент, работающий с любой моделью (model-agnostic), со встроенным циклом обучения, который «растёт» со временем и создаёт навыки из собственного опыта. Подробное сравнение этих трёх платформ как инструментов для разработчика — ниже в этой главе.

ОБЁРТКИ НАД LLM: СЛОЙ МЕЖДУ МОДЕЛЬЮ И ПОЛЬЗОВАТЕЛЕМ

Отдельная история — обёртки над агентами и моделями, псевдоприложения и псевдоагенты, которые в 2025–2026 году появились в большом количестве. На Хабре в мае 2025 года обсуждался типичный сюжет того периода: «AI-пузырь — стартапы получают миллионы за обёртку над чужим ИИ». В качестве яркого примера приводился Cursor AI: «AI-помощник для программистов», который на поверке «просто пересылает запросы к GPT и Claude, без собственных моделей». По формулировке одного из обзоров, компания получила десятки миллионов долларов инвестиций. За что? «За UX (User Experience, пользовательский опыт) и маркетинг». В обсуждениях того периода формулировались три риска: зависимость от одного-двух поставщиков API делает бизнес хрупким; раздуваются оценки компаний, которые ничего не создают; настоящие исследовательские команды получают меньше внимания.

В январе 2026 года на Хабре параллельно обсуждалась обратная сторона: AI-агент на платформе n8n (платформа автоматизации без программирования) за 50 долларов в месяц заменяет маркетинг-аналитика за 50 тысяч долларов в год, AI-агент проверяет олимпиадные задачи за 0,10 доллара за работу против 20 у PhD-студентов.

Так «обёртка» бывает двух видов. Пустая — интерфейс вокруг чужого API без добавленной стоимости. Продуктивная — интерфейс плюс рабочий процесс, интеграции и данные, которые превращают общий API в специализированный инструмент. Разница — в добавленной стоимости.

Практический критерий простой: потратьте 15 минут на регистрацию и задайте тот же вопрос, который задали бы ChatGPT. Если ответ точнее, быстрее или закрывает интеграцию, которой у компании нет, — обёртка полезная. Если ответ такой же, а сервис стоит 20 долларов в месяц, — это пустышка.

БЕЗОПАСНОСТЬ ЛОКАЛЬНОЙ ИНФРАСТРУКТУРЫ

Локальная модель безопасна в смысле «данные не уходят в облако», но уязвима в смысле «плохо настроена, нет аудита, нет обновлений безопасности». Облачный провайдер отбивается от атак командой из 200 человек, ваш сервер в серверной под лестницей — это ваш личный центр реагирования на инциденты (incident response). Ollama по умолчанию ведёт ограниченный журнал запросов, и без явной настройки логирования вы не узнаете ни о том, что модель начала галлюцинировать регулярно, ни о том, что бывший сотрудник выгрузил базу клиентов.

Безопасность — не свойство «локальное» или «облачное», а свойство «правильно настроенное». И в обоих случаях цена этой настройки сопоставима с ценой самой модели.

РЕЗЮМЕ

Выбор между облаком и локальным запуском — вопрос «когда», а не «или». Облако даёт быстрый старт, локальный запуск — контроль данных и предсказуемость расходов.

Миф «облако дешевле локального запуска» верен только на старте. При стабильных объёмах локальная инфраструктура дешевле по прямым расходам, но дороже по полной стоимости из-за инженерного времени.

Регуляторика (152-ФЗ, EU AI Act, ФЗ-187 для КИИ) делает локальный запуск или сертифицированное частное облако нормой для регулируемых отраслей — независимо от объёма.

Стек инструментов важнее выбора модели. Ollama подходит для одного пользователя или маленькой команды, vLLM — для десятков одновременных сессий, llama.cpp — там, где нет дискретной видеокарты. Для офисной команды без DevOps-инженера Ollama на старте — рабочая норма, не компромисс.

Безопасность — свойство правильной настройки, а не облака или локалки. В обоих случаях цена настройки сопоставима с ценой самой модели. Границу задаёт не тариф, а то, какие данные готовы отдать и какие риски готовы принять.

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