Ollama Cloud или свой сервер: в чем разница

Что меняет Ollama Cloud, а что остается прежним

Ollama Cloud запускает модель на серверах ollama.com вместо вашего собственного оборудования, сохраняя при этом ту же команду ollama и тот же REST API, который вы уже используете. Изменяются две вещи: имя запрашиваемой модели и место хранения учетных данных. Остальная часть вашего приложения остается без изменений, за одним задокументированным исключением, описанным ниже: структурированный вывод (structured outputs).

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

Если вы еще не настроили локальную часть, начните с запуска Ollama на собственном VPS. Все дальнейшие инструкции предполагают наличие работающего ollama на сервере под управлением Linux.

Два способа доступа к Ollama Cloud

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

Путь первый: ваш локальный демон пересылает запрос. Вы авторизуетесь один раз, а затем запрашиваете модель, имя которой заканчивается на -cloud.

ollama signin
ollama pull gpt-oss:120b-cloud
ollama run gpt-oss:120b-cloud

Некоторые облачные модели имеют вместо этого простой тег cloud, например gemma4:cloud; именно в таком виде документация Ollama по облаку теперь представляет их для приложения и CLI. Рассматривайте любое окончание, -cloud или :cloud, как признак облачной модели.

Команда ollama signin привязывает эту машину к вашей учетной записи ollama.com. ollama signout отменяет привязку. После входа в систему ваше приложение продолжает обращаться к локальному порту, который использовался всегда:

curl http://localhost:11434/api/chat -d '{
  "model": "gpt-oss:120b-cloud",
  "messages": [{"role": "user", "content": "Why is the sky blue?"}],
  "stream": false
}'

Внимательно прочитайте этот URL. В нем указано localhost, но вычисления происходят не там. Локальный демон распознает суффикс -cloud, пересылает запрос на ollama.com и передает ответ вам потоком. В этом и заключается суть первого пути: приложение, уже настроенное на Ollama API на порту 11434, сохраняет свой URL и клиентский код, а для обычного чата ему требуется лишь изменить строку с именем модели. Исключением являются структурированные ответы. В документации Ollama указано, что «облако Ollama в настоящее время не поддерживает структурированные ответы», поэтому приложению, которое передает JSON-схему в параметре format и ожидает соответствующий ответ, придется внести изменения перед переходом на облачную модель: выполняйте валидацию и повторные попытки в собственном коде или оставьте этот вызов для локальной модели.

Путь второй: ваш клиент обращается к ollama.com напрямую. Здесь локальный демон вообще не участвует. Создайте ключ на https://ollama.com/settings/keys, а затем отправьте его в качестве bearer-токена.

export OLLAMA_API_KEY=your_api_key
curl https://ollama.com/api/chat \
  -H "Authorization: Bearer $OLLAMA_API_KEY" \
  -d '{
    "model": "gpt-oss:120b",
    "messages": [{"role": "user", "content": "Why is the sky blue?"}],
    "stream": false
  }'

Посмотрите на имя модели. На втором пути это gpt-oss:120b, без суффикса -cloud. Суффикс нужен для того, чтобы сообщить локальному демону о необходимости пересылки запроса выше по цепочке, поэтому он относится только к первому пути. Когда вы обращаетесь к https://ollama.com, вы уже находитесь в облаке, поэтому указываете простое имя. Авторитетный список этих имен предоставляется самим хостом:

curl https://ollama.com/api/tags

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

Какие вызовы клиента меняются, а какие — нет

Официальные библиотеки Python и JavaScript принимают хост и заголовки при создании экземпляра клиента. После этой строки код не отличается. В первом варианте конструктор пуст, так как по умолчанию используется локальный демон:

from ollama import Client

client = Client()

messages = [{'role': 'user', 'content': 'Why is the sky blue?'}]

for part in client.chat('gpt-oss:120b-cloud', messages=messages, stream=True):
  print(part['message']['content'], end='', flush=True)

Во втором варианте конструктор содержит хост и токен:

import os
from ollama import Client

client = Client(
    host="https://ollama.com",
    headers={'Authorization': 'Bearer ' + os.environ.get('OLLAMA_API_KEY')}
)

messages = [{'role': 'user', 'content': 'Why is the sky blue?'}]

for part in client.chat('gpt-oss:120b', messages=messages, stream=True):
  print(part['message']['content'], end='', flush=True)

Вызов client.chat(), цикл потоковой передачи, список сообщений и структура ответа идентичны в обоих случаях. Именно поэтому переход между облачной и локальной версией требует лишь изменения конфигурации, а не переписывания кода. Исключение составляют вызовы, зависящие от структурированного вывода, который облачная версия Ollama на данный момент не поддерживает. Совместимый с OpenAI интерфейс работает локально аналогичным образом: укажите OpenAI SDK адрес http://localhost:11434/v1/ и используйте api_key='ollama' — это обязательный для SDK заполнитель, который локальный сервер игнорирует.

Где хранятся учетные данные и кто может ими воспользоваться

На втором пути учетные данные находятся в OLLAMA_API_KEY вашей среды. Не допускайте их попадания в историю командной оболочки или в репозиторий. Если вы используете службу systemd, укажите их в строке Environment= или в файле окружения, владельцем которого является root, с правами доступа 600.

Первый путь часто вызывает удивление. Вход в систему принадлежит демону, а не вам. В FAQ Ollama задокументировано, что идентификатор службы в Linux находится по адресу /usr/share/ollama/.ollama/id_ed25519.pub и принадлежит пользователю службы ollama. В локальном API отсутствует аутентификация для каждого запроса, поэтому любой вызывающий объект, имеющий доступ к порту 11434, получает права вашей учетной записи и расходует вашу квоту. Это допустимо, пока демон прослушивает только loopback. Как только вы установите OLLAMA_HOST=0.0.0.0:11434 для доступа к нему с другого компьютера, открытый порт превращается в открытый доступ к вашему биллингу. Именно поэтому вам следует прочитать как настроить аутентификацию перед эндпоинтом Ollama, прежде чем расширять адрес привязки.

Почему одна и та же модель предоставляет меньше контекста при локальном запуске

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

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

[
  {
    "label": "Under 24 GiB VRAM",
    "default_context_tokens": "4,096"
  },
  {
    "label": "24 to 48 GiB VRAM",
    "default_context_tokens": "32,768"
  },
  {
    "label": "48 GiB VRAM or more",
    "default_context_tokens": "262,144"
  }
]

VPS без GPU находится в нижней категории, поэтому локальная модель начинает работу с 4,096 токенов контекста, в то время как машина с мощной видеокартой — с 262,144. Облачные модели игнорируют эти ограничения: согласно документации Ollama, для них по умолчанию установлена максимальная длина контекста, так как память, удерживающая этот контекст, не является вашей.

Таким образом, один и тот же промпт, который работает с gpt-oss:120b-cloud, может быть незаметно обрезан при использовании локальной модели на слабом оборудовании. Увеличьте локальный лимит явно:

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

В systemd установите его как Environment="OLLAMA_CONTEXT_LENGTH=32768" с помощью systemctl edit ollama.service, а затем выполните systemctl daemon-reload && systemctl restart ollama. Помните о последствиях: больший контекст означает увеличенный кэш ключей-значений (key-value cache), а этот кэш занимает оперативную память сверх того объема, который требуется для весов модели. Если установить слишком высокое значение, генерация замедлится или модель не сможет загрузиться. В правильной настройке num_ctx и OLLAMA_CONTEXT_LENGTH описаны расчеты, а в том, какие модели соответствуют имеющейся у вас памяти — вопросы, связанные с весами.

Что на самом деле покидает вашу машину

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

При локальном запуске данные не покидают машину. Политика конфиденциальности Ollama прямо гласит, что при локальном использовании: «Мы не собираем, не храним, не передаем и не имеем доступа к вашим промптам, ответам, взаимодействиям с моделями или другому контенту, который вы обрабатываете локально». Есть один нюанс: загрузка модели — это скачивание с ollama.com, и политика относит «метаданные загрузки моделей» и ваш IP-адрес к собираемой информации. Реестр узнает, какие модели вы скачали. Он не узнает, о чем вы их спрашивали.

При использовании облачного пути полный промпт и полный ответ передаются третьей стороне. Здесь нет промежуточных вариантов. Каждый токен, который вы отправляете, и каждый токен, который вы получаете, обрабатывается на ollama.com. В политике указано, что компания обрабатывает «ваши промпты и ответы транзитно для предоставления сервиса», «не использует ваши входные и выходные данные для обучения каких-либо моделей ИИ» и описывает «технические меры, направленные на минимизацию хранения контента промптов и ответов». Это разумное обязательство. Тем не менее, это обязательство другой стороны относительно данных, которые вы передали, а не свойство вашей собственной машины. Оценивайте его так же, как оценивали бы обещание любого поставщика, и перечитайте его перед отправкой чего-либо, что вы обязаны по договору или закону хранить на собственной инфраструктуре.

Ловушка кроется в первом пути. Ваш код содержит http://localhost:11434, правила вашего файрвола не изменены, а ваш промпт все равно уходит в интернет, потому что суффикс -cloud в имени модели управляет маршрутизацией. URL localhost ничего не говорит о том, где именно происходил вывод (inference). Об этом говорит имя модели. Это наиболее важно, когда промпт содержит данные, которые вы размещаете на своем сервере специально для обеспечения конфиденциальности: если вы используете локальный трекер местоположения, чтобы история ваших перемещений никогда не попала к третьим лицам, то запрос к модели -cloud с просьбой проанализировать неделю этих данных все равно отправит эту историю на ollama.com.

На сервере, который ни при каких обстоятельствах не должен пересылать промпты, исключите такую возможность полностью. Ollama документирует режим «только локально»: установите OLLAMA_NO_CLOUD=1 в окружении сервиса или "disable_ollama_cloud": true в ~/.ollama/server.json, а затем перезапустите его. Демон потеряет доступ к облачным моделям и веб-поиску, поэтому случайное имя облачной модели не сможет привести к утечке данных.

Использование локальной модели в качестве резервного варианта

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

Самый простой вариант вообще не требует изменения кода. Настройте приложение на работу с локальным демоном и укажите имя модели в конфигурации. Установите значение llama3.2, и вы будете работать на своей машине. Установите gpt-oss:120b-cloud, и тот же демон перенаправит запрос на ollama.com. Одна переменная окружения, никакой повторной сборки.

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

import os
from httpx import ConnectError
from ollama import Client, ResponseError

LOCAL_MODEL = os.environ.get("LOCAL_MODEL", "llama3.2")
CLOUD_MODEL = os.environ.get("CLOUD_MODEL", "gpt-oss:120b")

local = Client(host="http://127.0.0.1:11434")
cloud = Client(
    host="https://ollama.com",
    headers={"Authorization": "Bearer " + os.environ["OLLAMA_API_KEY"]},
)

def chat(messages):
    try:
        return local.chat(LOCAL_MODEL, messages=messages)
    except (ConnectError, ResponseError) as err:
        print(f"local inference failed ({err}); sending this prompt to ollama.com")
        return cloud.chat(CLOUD_MODEL, messages=messages)

httpx является зависимостью пакета ollama, поэтому ничего дополнительно устанавливать не нужно. ConnectError обрабатывает ситуацию, когда демон не запущен. ResponseError обрабатывает случай, когда демон запущен, но отклоняет запрос, например, если локальная модель не была загружена.

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

Еще один фактор, делающий локальный вариант надежным решением по умолчанию: держите модель в оперативной памяти. «Холодная» загрузка на VPS только с CPU может занимать десятки секунд, что и заставляет пользователей переходить на облачные решения. Удержание модели в памяти с помощью keep_alive устраняет задержку при первом запросе.

Что сравнить перед принятием решения

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

• Доступность моделей. Запустите curl https://ollama.com/api/tags для просмотра текущего каталога облачных моделей. Модели, которые вы можете запустить локально, зависят от объёма вашей RAM и VRAM.
• Ограничения контекста. Облачные модели по умолчанию используют свои максимальные значения. Локальные модели используют значения по умолчанию в зависимости от уровня VRAM, как указано выше. Если ваша рабочая нагрузка включает длинные документы, этот фактор является решающим.
• Ограничения скорости (Rate limits). Облачный инференс тарифицируется по токенам: на странице цен Ollama указано: «Использование измеряется в токенах по тарифам каждой модели». Платные тарифы включают ежемесячный кредит, и Ollama «сначала использует кредиты, включенные в тариф, а затем списывает средства с баланса купленных кредитов». Параллельность запросов ограничена в зависимости от тарифа (3 параллельных запроса на тарифе $0 Pay as you go и Pro, 10 на тарифах Max и Team по состоянию на 27 октября 2026 года), запросы сверх лимита ставятся в очередь, а отклоняются только после заполнения очереди. Ваш собственный сервер не имеет счётчика использования, только предел параллельности, обусловленный аппаратным обеспечением, что является другим типом сбоя и зачастую более критичным.
• Политика хранения данных. Прочитайте текст актуальной политики, зафиксируйте дату прочтения и перепроверьте её перед любым продлением услуг.

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

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

Третий вариант — это маршрутизатор, прокси-сервер, который взаимодействует с вашим приложением через единый API и распределяет запросы между несколькими бэкендами. Эту задачу решают как self-hosted прокси, например LiteLLM, так и облачные сервисы вроде OpenRouter. Преимущества очевидны: одна конфигурация клиента, доступ к нескольким моделям и отказоустойчивость на случай сбоев у провайдера. Это естественное развитие описанной выше схемы резервирования, обобщенное для работы более чем с двумя бэкендами. Однако учитывайте стоимость. Облачный маршрутизатор — это еще один оператор, который видит ваши промпты, поэтому вопрос о хранении данных, который вы задавали одному вендору, теперь нужно адресовать двоим. Self-hosted маршрутизатор оставляет этот этап обработки на вашей стороне, но добавляет еще один сервис, который нужно запускать, обновлять и мониторить. Маршрутизаторы решают вопросы выбора модели и доступности. Они не решают вопросы конфиденциальности, так как промпт в конечном итоге попадает туда, куда его направит маршрут.

Ошибки, с которыми вы столкнетесь на практике

API документирует коды состояния, и каждый из них указывает на конкретную проблему. 429 Too Many Requests означает, что вы превысили лимит запросов (rate limit), поэтому следует приостановить активность и повторить попытку, а не пытаться переподключиться в бесконечном цикле. 502 Bad Gateway — это код, специфичный для данной темы: он возвращается, когда облачная модель недоступна. В первом сценарии это означает, что ваш демон работает исправно, а проблема на стороне вышестоящего узла. 404 Not Found при указании имени модели означает, что такой модели нет на хосте, к которому вы обратились: обычно это -cloud имя, отправленное напрямую в https://ollama.com, либо локальная модель, которую вы не загрузили. Авторизация здесь ни при чем, так как локальный API не требует аутентификации. Ошибки приходят в формате JSON, а при потоковой передаче они отображаются как строка вида {"error":"an error was encountered while running the model"} внутри ответа NDJSON. Именно поэтому простой клиент потоковой передачи может вывести частичный ответ и остановиться без объяснения причин. Выполняйте парсинг каждой строки потока и проверяйте наличие ключа error.

На локальной стороне классической ошибкой является connection refused на порту 11434, что означает отсутствие процесса, прослушивающего этот порт: проверьте systemctl status ollama, и если демон запущен, проверьте, не перенес ли его OLLAMA_HOST на другой порт. Другая классическая проблема — запрос, который работает из вашей оболочки (shell), но завершается ошибкой из контейнера, поскольку localhost контейнера отличается от хостового.

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

Когда каждый выбор оправдан

Используйте Ollama Cloud, если нагрузка носит эпизодический характер, если модель слишком велика для вашего VPS или если вы еще не решили, стоит ли строить решение на базе конкретной модели. Оплата за токен выгоднее, чем оплата простаивающего GPU, который работает двадцать минут в день, а модель со 120 миллиардами параметров не поместится на сервере, который вы арендуете по цене обеда.

Запускайте решение самостоятельно, если промпты не должны покидать вашу инфраструктуру, если машина должна работать в офлайн-режиме или если нагрузка достаточно стабильна, чтобы арендованный GPU был постоянно занят. Стабильная нагрузка — это четкий индикатор: тарифицируемый инференс становится дорогим именно тогда, когда он работает постоянно. Если вы достигли такого уровня и пропускная способность Ollama при обработке одиночных запросов становится узким местом, vLLM справляется с параллельной нагрузкой лучше, чем Ollama, и это вопрос смены движка, а не хостинга. Если вы предпочитаете купить готовую частную установку, а не собирать её самостоятельно, сравнение стоимости частного AI-сервера по запросу с самостоятельной сборкой на арендованном GPU показывает, что на самом деле включает в себя такая сборка и когда обычный API является более выгодным приобретением.

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

FAQ

Видит ли Ollama Cloud мои промпты?

Да. При использовании облачного пути полный промпт и полный ответ отправляются на ollama.com и обрабатываются там. Политика конфиденциальности Ollama гласит, что компания обрабатывает «ваши промпты и ответы временно для предоставления услуги» и «не использует ваши входные или выходные данные для обучения каких-либо моделей ИИ», а также описывает меры по минимизации хранения данных. Это обязательство поставщика в отношении данных, которые вы уже передали. Для локальных моделей та же политика гласит, что компания «не собирает, не хранит, не передает и не имеет доступа к вашим промптам, ответам, взаимодействиям с моделями или другому контенту, который вы обрабатываете локально». Если требование заключается в том, чтобы контент никогда не покидал вашу инфраструктуру, ему соответствует только локальный путь.

Почему мое приложение все еще указывает на localhost, когда модель работает в облаке?

Потому что локальный демон работает как прокси. Когда вы запускаете ollama signin, а затем запрашиваете облачную модель (имя которой заканчивается на -cloud или :cloud), ваш демон пересылает этот запрос на ollama.com и транслирует ответ обратно через порт 11434. URL вашего приложения не меняется, в этом и смысл: для обычных запросов чата не требуется правка кода, хотя вызовы, полагающиеся на структурированный вывод, требуют доработки, так как облако Ollama их сейчас не поддерживает. Это также означает, что адрес localhost ничего не говорит о том, где происходил вывод. Проверяйте имя модели, а не URL. Тег cloud в имени означает, что промпт передавался через интернет.

Почему одна и та же модель дает мне гораздо меньший контекст локально?

Ollama выбирает локальное значение по умолчанию исходя из доступной видеопамяти: около 4k токенов при объеме менее 24 GiB VRAM, 32k при объеме от 24 до 48 GiB и 256k при 48 GiB и выше. VPS без GPU попадает в нижнюю категорию. Облачные модели по умолчанию настроены на максимальную длину контекста, так как память, в которой он хранится, принадлежит провайдеру. Увеличьте локальное значение с помощью OLLAMA_CONTEXT_LENGTH — либо как OLLAMA_CONTEXT_LENGTH=32768 ollama serve, либо как строку Environment= в разделе systemctl edit ollama.service. Помните, что для большего контекста требуется больший кэш ключей-значений в оперативной памяти, поэтому увеличение этого параметра на небольшом сервере может замедлить генерацию или привести к тому, что модель не загрузится.

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

Да, это делается несколькими строками кода, так как оба пути используют один и тот же API. Создайте два объекта Client: один без аргумента host для локального демона и второй с host="https://ollama.com" и заголовком Authorization: Bearer, затем перехватывайте исключения httpx.ConnectError и ollama.ResponseError при первом вызове. Принимайте решение о переключении осознанно. Локальный запуск с резервным облачным вариантом означает, что промпт, который вы хотели сохранить в тайне, может покинуть машину во время плановой перезагрузки демона. Поэтому логируйте каждое переключение, а для критически важных задач лучше выводите ошибку вместо автоматического переключения.