«Друзья не дают друзьям пользоваться Ollama»

Ниже — перевод статьи «Friends Don’t Let Friends Use Ollama», опубликованной на Sleeping Robots в апреле 2026 года. Поскольку за прошедшие месяцы Ollama успела заметно измениться, я добавил к переводу несколько комментариев и примечание в конце статьи, где обновил ключевые технические детали по состоянию на сентябрь 2026 года.

Ollama стала популярной потому, что первой предложила простой интерфейс поверх llama.cpp. А затем годами старалась лишний раз не напоминать, на чём на самом деле работает, вводила пользователей в заблуждение и в конце концов развернулась в сторону облака — всё это на венчурные деньги, привлечённые вокруг чужого движка.

Вот эта история целиком — и почему сегодня альтернативы выглядят лучше.

Ollama — самый популярный способ запускать большие языковые модели локально. И, пожалуй, не должна им быть.

Своим положением она обязана прежде всего тому, что оказалась первой: первым инструментом, который сделал llama.cpp доступным людям, не желавшим компилировать C++ или самостоятельно писать конфигурацию сервера. На тот момент это действительно был полезный вклад.

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

Это не попытка найти «правду где‑то посередине». Я пользовался Ollama. Потом перестал. Ниже — почему, на мой взгляд, вам стоит сделать то же самое.

Обёртка над llama.cpp, страдающая амнезией

Все возможности Ollama по инференсу изначально обеспечивал llama.cpp ^[1] — движок на C++, созданный Георгием Гергановым в марте 2023 года. Именно проект Герганова фактически сделал возможным запуск моделей LLaMA на обычных пользовательских ноутбуках. Первую версию он собрал за один вечер ^[2], положив начало всему движению локальных больших языковых моделей.

Сегодня у llama.cpp более 100 000 звёзд на GitHub, свыше 450 участников разработки, и именно он лежит в основе практически всей экосистемы инструментов, работающих с GGUF.

Ollama основали в 2021 году Джеффри Морган и Майкл Чианг, прежде работавшие над Kitematic ^[3] — графическим интерфейсом для Docker, который впоследствии приобрела Docker Inc. Они прошли зимний набор Y Combinator 2021 года, привлекли предпосевные инвестиции и публично запустили продукт в 2023-м.

С самого начала идея подавалась как «Docker для больших языковых моделей»: удобная обёртка, позволяющая одной командой скачать и запустить модель. Под капотом всю основную работу выполнял llama.cpp.

Больше года README Ollama вообще не упоминал llama.cpp ^[4]. Ни README, ни сайт, ни маркетинговые материалы. В бинарных сборках проекта не было и обязательного уведомления о лицензии MIT ^[5] для распространявшегося вместе с ними кода llama.cpp.

И это уже не вопрос хороших манер в мире открытого ПО. У лицензии MIT есть, по существу, одно главное условие: сохранить уведомление об авторских правах. Ollama его не выполняла.

Сообщество это заметило. В начале 2024 года появился тикет #3185 ^[5] с требованием привести распространение к условиям лицензии. Он более 400 дней оставался без ответа сопровождающих проекта.

Когда в апреле 2024 года открыли тикет #3697 ^[4] с прямой просьбой указать использование llama.cpp, уже через несколько часов появился подготовленный сообществом запрос на слияние #3700 ^[6]. В конце концов сооснователь Ollama Майкл Чианг добавил одну строку ^[7] в самый низ README:

«Проект llama.cpp основан Георгием Гергановым».

Ответ команды Ollama на запрос был ещё показательнее. Разработчики написали: «Мы тратим значительную часть времени на исправления и доработки, чтобы обеспечить пользователям Ollama беспроблемную работу… Со временем мы перейдём на более системно спроектированные движки».

Если перевести с корпоративного: заметного признания заслуг llama.cpp не будет, а со временем мы всё равно собираемся от него отойти.

Как написал один из комментаторов Hacker News ^[8]: «Меня постоянно ставит в тупик их подход — они сами создают себе негативный пиар буквально на пустом месте. Строить продукт на llama совершенно нормально, тем более что они действительно добавляют удобство. Просто укажите вклад команды llama как положено».

Другой заметил: «О том, что Ollama старается преуменьшать свою зависимость от llama.cpp, в сообществе локальных больших языковых моделей известно уже давно».

Форк, который сделал всё только хуже

В середине 2025 года Ollama действительно продолжила дистанцироваться от llama.cpp. Разработчики отказались от него как от основного движка инференса и создали собственную реализацию непосредственно поверх ggml ^[9] — низкоуровневой библиотеки для работы с тензорами, которую использует и сам llama.cpp.

Официальной причиной назвали стабильность: llama.cpp развивается быстро и иногда ломает совместимость, а корпоративным клиентам Ollama нужна предсказуемость.

Получилось ровно наоборот.

Собственный движок Ollama вернул ошибки, которые в llama.cpp исправили ещё несколько лет назад ^[10]. Пользователи сообщали о сломанной поддержке структурированного вывода, проблемах с моделями компьютерного зрения ^[11] и аварийных остановках из‑за проверок GGML в нескольких версиях подряд.

Модели, нормально работавшие в оригинальном llama.cpp, ломались в Ollama ^[12]. Это касалось в том числе свежих моделей вроде GPT‑OSS 20B: в реализации Ollama не было поддержки типов тензоров, необходимых этой модели. Сам Георгий Герганов указал ^[13], что Ollama сделала форк GGML и внесла в него неудачные изменения.

Ирония тут почти неприлично очевидна. Годами они преуменьшали свою зависимость от llama.cpp, а когда наконец решили обойтись без него, получили ухудшенную версию того самого проекта, заслуги которого так не хотели признавать.

Результаты тестов тоже говорят сами за себя. В нескольких тестах сообщества llama.cpp оказался в 1,8 раза быстрее Ollama ^[14] на одном и том же оборудовании с одной и той же моделью: 161 токен в секунду против 89.

При работе на процессоре разница составляет 30–50% ^[15]. В недавнем сравнении на Qwen-3 Coder 32B ^[16] llama.cpp показал примерно на 70% большую пропускную способность.

Дополнительные издержки Ollama связывают с отдельным фоновым сервисом, неудачной логикой ^[17] переноса вычислений на графический процессор и собственной копией движка, которая отстаёт от основного проекта.

Названия моделей, вводящие в заблуждение

Когда в январе 2025 года DeepSeek выпустила семейство R1, Ollama разместила у себя уменьшенные дистиллированные версии — например DeepSeek‑R1-Distill‑Qwen-32B. Это дообученные модели Qwen и Llama, а вовсе не настоящая R1 на 671 миллиард параметров.

Однако в каталоге Ollama и командной строке они были представлены просто как «DeepSeek‑R1» ^[18].

Команда

ollama run deepseek-r1

скачивает восьмимиллиардную дистиллированную модель на основе Qwen, которая по поведению ^[19] совсем не равна настоящей R1.

Это трудно списать на случайную ошибку ^[20]. Сама DeepSeek дала этим моделям названия с приставкой R1-Distill. На Hugging Face они были обозначены правильно. Ollama различие убрала.

В результате социальные сети заполнили сообщения людей, утверждавших, что они запускают «DeepSeek‑R1» на обычном домашнем железе, а затем недоумевавших, почему модель показывает слабые результаты. Заодно это било по репутации DeepSeek ^[18].

В тикетах GitHub #8557 ^[21] и #8698 ^[22] пользователи просили разделить модели. Оба закрыли как дубликаты, ничего не исправив.

На сегодняшний день ollama run deepseek-r1 по‑прежнему запускает маленькую дистиллированную модель. В Ollama прекрасно знали о различии и предпочли его не подчёркивать — по всей видимости, потому что название «DeepSeek‑R1» привлекает больше скачиваний, чем «DeepSeek‑R1-Distill‑Qwen-32B».

Приложение с закрытым исходным кодом

В июле 2025 года Ollama выпустила настольное приложение ^[23] для macOS и Windows. Его разрабатывали в закрытом репозитории (github.com/ollama/app), распространяли без лицензии, а исходный код публично доступен не был.

Для проекта, выстроившего репутацию на открытом исходном коде, ход получился, мягко говоря, странным.

Участники сообщества сразу подняли этот вопрос ^[24]. Тикет о лицензировании набрал 40 голосов. Разработчики обнаружили в бинарном файле возможные зависимости под AGPL-3.0 ^[24].

При этом на сайте кнопка загрузки находилась рядом со ссылкой на GitHub, создавая впечатление ^[25], будто пользователь скачивает открытый инструмент под лицензией MIT, хотя фактически ему предлагалось закрытое приложение вообще без указанной лицензии.

Сопровождающие проекта несколько месяцев молчали. В ноябре 2025 года код наконец влили в основной репозиторий ^[26], но первоначальный запуск довольно хорошо показал, какой выбор для проекта оказывается естественным, когда приходится выбирать между прозрачностью и удобством для бизнеса.

Как сформулировали в XDA ^[10]: «Если ваш проект строит репутацию на открытом исходном коде, нельзя при запуске невнятно объяснять, что именно у вас открыто, а что нет».

Modelfile: заново изобретаем уже решённую проблему

Формат моделей GGUF, созданный Георгием Гергановым, проектировался вокруг одного основного принципа ^[27]: всё необходимое должно помещаться в один файл.

Первый пункт спецификации GGUF гласит: «Полная информация: все сведения, необходимые для загрузки модели, содержатся в файле модели, и пользователь не должен предоставлять никаких дополнительных данных».

Шаблоны диалога, стоп‑токены, метаданные модели — всё находится внутри файла. Указываете llama.cpp файл GGUF — и он работает.

Ollama добавила поверх этого Modelfile. Это отдельный конфигурационный файл, вдохновлённый — разумеется — Dockerfile. В нём указываются базовая модель, шаблон диалога, системный промпт, параметры сэмплирования и стоп‑токены.

Большая часть этой информации уже находится внутри GGUF.

Как выразился один из комментаторов Hacker News ^[28]: «Мы буквально только что избавились от всего этого бардака с кучей файлов — и тут Ollama добавила его обратно».

Дальше проблемы начинают быстро наслаиваться друг на друга.

Ollama автоматически распознаёт только те шаблоны диалога, о которых уже знает ^[29], сверяясь с жёстко заданным списком. Если в метаданных GGUF находится корректный шаблон Jinja, но он не совпадает ни с одним из известных Ollama вариантов, система молча переключается на примитивный шаблон {{ .Prompt }}, ломая формат инструкций модели.

Пользователю приходится вручную извлекать шаблон диалога из GGUF, переводить его в синтаксис шаблонов Go — который отличается от Jinja, — и записывать результат в Modelfile.

А llama.cpp тем временем просто читает шаблон из файла и использует его.

С изменением параметров всё ещё веселее.

Если вы хотите поменять температуру или системный промпт у модели, загруженной из реестра Ollama, порядок действий такой: выгрузить Modelfile командой ollama show --modelfile, отредактировать его, а затем выполнить ollama create, чтобы создать новую запись модели.

Пользователи сообщали ^[28], что ради изменения одного параметра при этом копируется вся модель — от 30 до 60 ГБ.

Один из них описал процесс так: «Работа через modelfile — та ещё боль ^[30]. Паттерн отвратительный, я его ненавижу. Некоторые модели занимают 30–60 ГБ, и копировать всё целиком ради изменения одного параметра — просто идиотизм».

Для сравнения: в llama.cpp параметры передаются обычными ключами командной строки.

Нужна другая температура? Передайте --temp 0.7.

Другой системный промпт? Передайте его в запросе к API.

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

Кроме того, Modelfile привязывает пользователя к синтаксису шаблонов Go, который отличается от Jinja ^[31], используемого авторами моделей.

LM Studio принимает шаблоны Jinja напрямую. llama.cpp читает их из GGUF. Только Ollama заставляет переводить шаблоны с одного языка на другой — причём ошибается достаточно часто, чтобы расхождениям между шаблонами из каталога Ollama и исходными метаданными GGUF ^[31] посвящались отдельные тикеты на GitHub.

Реестр как бутылочное горлышко

Когда выходит новая модель — очередной вариант Qwen, Gemma или DeepSeek, — файлы GGUF обычно появляются на Hugging Face уже через несколько часов. Участники сообщества вроде Unsloth или Bartowski быстро готовят квантованные версии.

С llama.cpp такую модель можно запускать сразу:

llama-server -hf unsloth/Qwen3.5-35B-A3B-GGUF:Q4_K_M

Одна команда. Напрямую с Hugging Face. Без посредника.

С Ollama приходится ждать.

Кто‑то из команды должен упаковать модель для собственного реестра, решить, какие варианты квантования опубликовать — обычно только Q4_K_M и Q8_0 ^[32], без Q5, Q6 и IQ ^[33], — преобразовать шаблон диалога в формат Go и всё это загрузить.

До тех пор для мира Ollama модели как будто не существует — если, конечно, вы не готовы самостоятельно устраивать танцы с Modelfile.

Из‑за этого на r/LocalLLaMA регулярно повторяется один и тот же сценарий ^[34]: выходит новая модель, люди пробуют её через Ollama, получают ошибки, низкую скорость или сломанный шаблон диалога — и обвиняют модель, а не среду выполнения.

В недавнем сообщении под заголовком «Если хотите тестировать новые модели, используйте llama.cpp/transformers/vLLM/SGLang» было показано, как у моделей Qwen возникают проблемы с вызовом инструментов и бессмысленные ответы, которые «происходят только в Ollama» из‑за собственной копии движка и неправильной обработки шаблонов.

Один из комментаторов сформулировал это предельно кратко:

«Друзья не дают друзьям пользоваться Ollama».

Особенно раздражают ограничения на квантование.

Ollama умеет самостоятельно создавать только Q4_K_S, Q4_K_M, Q8_0, F16 и F32 ^[35]. Если вам нужен Q5_K_M, Q6_K или любой вариант IQ, которые llama.cpp поддерживает уже много лет, — не повезло. Придётся выполнять квантование самостоятельно за пределами Ollama.

Когда пользователь спросил о поддержке Q2_K ^[35], ответ по существу свёлся к «используйте другой инструмент».

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

Позднее Hugging Face добавил поддержку команды ollama run hf.co/{repo}:{quant}, на лету создавая манифест в стиле Docker. Это частично решает проблему доступности моделей.

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

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

Разворот в облако

В конце 2025 года Ollama добавила к локальному каталогу модели, работающие в облаке.

Инструмент, название которого практически стало синонимом локального и приватного инференса, начал отправлять запросы сторонним облачным провайдерам ^[36].

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

Пользователи подняли вопрос о маршрутизации данных ^[37]. Когда вы запускаете закрытую модель вроде MiniMax‑m2.7 через «Ollama Cloud», ваши промпты могут пересылаться внешнему поставщику, который фактически размещает модель.

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

Однако там ничего не говорится о том, что с этими данными делает сторонний поставщик. В случае моделей, размещённых в Alibaba Cloud, пользователи отмечали отсутствие гарантии нулевого хранения данных ^[38].

Ситуацию усугубила CVE-2025-51471 ^[39] — уязвимость, позволяющая похитить токен аутентификации и затрагивающая все версии Ollama.

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

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

Венчурный сценарий

Всё это становится понятнее, если посмотреть на систему стимулов.

Ollama — стартап из Y Combinator, выпуск зимнего набора 2021 года, основанный инженерами, которые до этого сделали графический интерфейс для Docker, а затем продали его Docker Inc.

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

Последовательность получается почти образцовой:

1. Запуститься на базе открытого ПО — построить продукт на llama.cpp и завоевать доверие сообщества

2. Свести упоминание основы к минимуму — создать впечатление самостоятельного продукта

3. Привязать пользователей к собственной экосистеме — свой реестр моделей, хешированные имена файлов, неудобные для других инструментов

4. Выпустить закрытые компоненты — настольное приложение

5. Добавить облачные сервисы — основу для монетизации

Отдельно стоит посмотреть на устройство реестра моделей.

Ollama хранит загруженные модели в собственном хранилище под именами, представляющими собой хеши. Если вы несколько месяцев скачивали модели через Ollama, просто указать llama.cpp или LM Studio на эти файлы уже не получится — потребуется дополнительная возня.

Свои GGUF‑файлы в Ollama можно импортировать через Modelfile. А вот обратный путь заметно менее удобен.

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

Чем пользоваться вместо Ollama

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

llama.cpp ^[1] — собственно движок. В нём есть сервер с API, совместимым с OpenAI (llama-server), встроенный веб‑интерфейс, полный контроль над размером контекста и параметрами сэмплирования, а производительность стабильно выше, чем у Ollama.

В феврале 2026 года компания Герганова ggml.ai ^[40] присоединилась к Hugging Face ^[41], чтобы обеспечить проекту долгосрочное развитие. llama.cpp распространяется под лицензией MIT, активно развивается сообществом и насчитывает более 450 участников.

Проект Mozilla llamafile ^[42] развивает идею единственного файла ещё дальше: модель вместе со средой выполнения упаковывается в один исполняемый файл, который работает в шести операционных системах вообще без установки.

Скачал. Запустил. Готово.

llama‑swap ^[43] занимается оркестрацией нескольких моделей: загружает и выгружает их и позволяет переключаться между ними по запросу через единый адрес API.

В паре с LiteLLM ^[44] получается единый прокси, совместимый с API OpenAI, который умеет маршрутизировать запросы между несколькими движками и нормально работать с псевдонимами моделей.

Если нужен настольный графический интерфейс, есть действительно открытые варианты.

Jan ^[45] под лицензией AGPLv3 — локальное приложение для общения с моделями с аккуратным интерфейсом и полностью открытым исходным кодом.

koboldcpp ^[46] под AGPL — форк llama.cpp со встроенным веб‑интерфейсом и широкими возможностями настройки, полностью открытый и пригодный для аудита.

Оба — настоящие проекты свободного ПО, а не обёртки, скрывающие закрытый код за открытым движком.

Есть и закрытые обёртки.

LM Studio ^[47] — проприетарная программа поверх llama.cpp и самая популярная альтернатива Ollama не без причины: она предлагает примерно то же удобство «в один клик», нормальный графический интерфейс, принимает любые GGUF и предоставляет доступ ко всем основным настройкам.

Что важнее, разработчики LM Studio ведут себя по отношению к экосистеме добросовестно. У них есть отдельная страница благодарностей ^[48], где прямо указаны llama.cpp и его лицензия, и они не пытаются делать вид, будто непонятно, что находится под капотом.

Это закрытый продукт. Но не паразитический.

Msty ^[49] — ещё один закрытый графический интерфейс поверх открытых движков инференса, с поддержкой нескольких моделей и встроенным поиском по базе знаний.

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

Но стоит честно называть вещи своими именами: такие инструменты — коммерческие продукты, существующие благодаря llama.cpp, а не какие‑то независимые альтернативы ему.

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

LM Studio — уважает.

Ollama — нет.

Стоит посмотреть и на ramalama ^[50] от Red Hat — ориентированный на контейнеры инструмент для запуска моделей, который прямо и на видном месте перечисляет проекты, на которых основан ^[51].

Именно так Ollama и следовало поступить с самого начала.

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

Если посмотреть шире

В марте 2023 года Георгий Герганов за один вечер собрал первую версию llama.cpp и фактически запустил революцию локального искусственного интеллекта.

Он и сотни участников сообщества затем годами работали над тем, чтобы всё более мощные модели можно было запускать на обычном пользовательском железе. Это действительно важная работа. Именно она остаётся фундаментом, благодаря которому локальный инференс остаётся открытым и доступным.

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

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

Экосистеме локальных больших языковых моделей Ollama не нужна.

Ей нужен llama.cpp.

Всё остальное — упаковка. И упаковка получше уже существует.

---

Примечание переводчика: что изменилось с апреля 2026 года

Оригинал этой статьи был опубликован 15 апреля и обновлён 18 апреля 2026 года. За прошедшие месяцы Ollama успела заметно изменить несколько вещей, о которых пишет автор.

Самое существенное изменение касается llama.cpp. В июне Ollama 0.30 вернула llama.cpp в качестве backend для GGUF‑моделей. В актуальном исходном коде Ollama закрепляет конкретную версию llama.cpp, собирает из неё llama-server и накладывает собственный слой совместимости. Поэтому описанный выше период собственного GGML‑backend — уже история, а не текущее состояние проекта.

Это, однако, не полностью снимает вопрос об отставании от upstream. Ollama использует не текущий HEAD llama.cpp, а зафиксированную версию. Весной 2026 года это, например, приводило к заметной разнице в производительности Vulkan на AMD из‑за отсутствующих upstream‑оптимизаций. Сейчас версии обновляются гораздо регулярнее: например, 15 сентября Ollama обновила llama.cpp до b10969. Сам механизм возможного отставания от upstream при этом никуда не исчез.

Изменилось и несколько деталей вокруг Modelfile. Параметры вроде температуры можно задавать непосредственно во время работы, а системный промпт — менять без создания отдельной копии модели; API также позволяет передавать параметры в запросе. Кроме того, при создании производных моделей Ollama использует content‑addressed layers, поэтому упомянутое выше копирование десятков гигабайт ради одного изменённого параметра не следует считать актуальным поведением ^[52]. При этом Modelfile по‑прежнему остаётся отдельным слоем конфигурации поверх модели, а вопрос совместимости шаблонов с остальной GGUF‑экосистемой никуда полностью не исчез.

История с названием DeepSeek‑R1 изменилась меньше. По состоянию на сентябрь 2026 года короткое имя deepseek-r1 по‑прежнему не означает автоматически полноразмерную 671-миллиардную R1: разные размеры доступны отдельными тегами. При этом нынешняя страница библиотеки Ollama уже значительно яснее показывает, какая именно модель стоит за каждым вариантом. Поэтому претензия автора к первоначальному именованию остаётся понятной, но современный интерфейс стал прозрачнее.

Наконец, облачное направление за это время не исчезло, а, наоборот, превратилось в полноценную часть бизнеса Ollama. 9 июля компания объявила о привлечении ещё $88 млн и сообщила о 8,9 млн разработчиков, одновременно прямо назвав облако одним из ключевых направлений развития. 31 августа новые планы Pro, Max и Team перевели на прозрачную тарификацию по токенам с включённым ежемесячным объёмом кредитов. Это уже не побочная экспериментальная функция, а полноценный коммерческий сервис.

С другой стороны, претензии автора к облачной приватности сегодня требуют существенной оговорки. Действующая с марта 2026 года политика конфиденциальности Ollama прямо утверждает, что содержимое запросов к облачным моделям обрабатывается только транзитно, не используется для обучения ^[53] и не сохраняется после выполнения запроса. В описании новых тарифов Ollama также заявляет Zero Data Retention и отсутствие журналирования промптов. Поэтому часть приведённой выше критики отражает состояние и прозрачность сервиса именно на момент написания оригинальной статьи, а не нынешнюю публично заявленную политику Ollama.