Главное про AI - Вадим Жартун Страница 25

— 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 ГБ.