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

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

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

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

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

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

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

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

ollama signin
ollama pull gpt-oss:120b-cloud
ollama run gpt-oss:120b-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 и передает ответ вам потоком. В этом и заключается суть первого пути: приложению, которое уже настроено на API Ollama на порту 11434, не требуется никаких изменений в коде, достаточно лишь указать другую строку модели.

Путь второй: ваш клиент обращается к 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(), цикл потоковой передачи, список сообщений и структура ответа идентичны в обоих случаях. Именно поэтому переход между облачной и локальной версией требует изменения конфигурации, а не переписывания кода. Интерфейс, совместимый с OpenAI, работает локально аналогичным образом: укажите OpenAI SDK адрес http://localhost:11434/v1/ с ключом api_key='ollama', который локальный сервер запрашивает, но игнорирует.

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

На втором пути учетные данные находятся в 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 ничего не говорит о том, где именно происходят вычисления. Об этом говорит имя модели.

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

Поскольку оба пути используют один и тот же 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). Облачный инференс тарифицируется. При превышении лимита API возвращает 429 Too Many Requests. На собственном сервере ограничений по частоте нет, но существует жесткий предел параллельных соединений, что приводит к иному типу сбоев, зачастую более критичному.
• Политика хранения данных. Прочитайте текст политики, зафиксируйте дату ознакомления и перепроверяйте её перед каждым продлением услуг.

Что касается финансовой стороны, не пересчитывайте экономику здесь. В статье Когда 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, либо что «голое» имя отправлено демону, в котором вы не авторизовались. Ошибки приходят в формате JSON; при потоковой передаче они выглядят как строка вида {"error":"an error was encountered while running the model"} внутри ответа NDJSON. Именно поэтому простой потоковый клиент может вывести частичный ответ и остановиться без объяснения причин. Разбирайте каждую полученную строку и проверяйте наличие ключа error.

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

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

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

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

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

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

FAQ

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

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

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

Потому что локальный демон выступает в роли прокси. Когда вы запускаете ollama signin, а затем запрашиваете модель, имя которой заканчивается на -cloud, ваш демон пересылает этот запрос на ollama.com и транслирует ответ обратно через порт 11434. URL вашего приложения не меняется, в этом и смысл: редактирование кода не требуется. Это также означает, что адрес 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 при первом вызове. Принимайте решение о переключении осознанно. Вариант «сначала локально, затем облако» означает, что промпт, который вы хотели сохранить в тайне, может покинуть машину во время плановой перезагрузки демона, поэтому логируйте каждое переключение, а для критически важных задач лучше вызывать ошибку вместо автоматического переключения.