Ollama healthcheck: как проверить API, модель и ответ

Что считать готовностью Ollama?

Для операционного healthcheck нужны три разных ответа: сервер принимает соединение по ожидаемому адресу; нужный локальный тег есть в каталоге /api/tags; запрос к этому тегу возвращает завершённую генерацию. В документации Ollama локальный адрес — http://localhost:11434/api, а локальные запросы не требуют API-ключа; прямой облачный адрес — другой endpoint с другой схемой доступа. Не подменяйте адрес автоматически, если приложение работает в контейнере или на удалённом хосте. s1 s2 s4

/api/ps отвечает на четвёртый, отдельный вопрос: какие модели загружены в память сейчас. Пустой список до первого запроса может быть нормальным: FAQ описывает предзагрузку и политику keep_alive. И наоборот, запись в /api/ps ещё не подтверждает, что ваш промпт выполняется без ошибок. size_vram в API — поле текущего состояния, не минимальное требование к видеопамяти. s3 s6

Маршрут решения: задача приложения → точный тег подходящей модели → доступное устройство → локальный сервер Ollama → тестовый ответ → проверка качества на своих данных. Проверка доступности сервера — только начало этого маршрута, а не его конец. s1 s2 s4

Как проверить локальный API по шагам?

Предусловия. Ollama должен быть установлен и запущен на вашем устройстве; команды ниже обращаются к уже работающему серверу и не скачивают модели. В официальном Docker-примере порт контейнера публикуется как 11434:11434; на хосте с другой конфигурацией подставьте фактический адрес. Не открывайте порт на внешнюю сеть без отдельного контроля доступа. s1 s7

1. Сервер и список тегов. На машине, которая видит API, выполните curl -fsS --max-time 5 http://localhost:11434/api/tags. При доступном сервере вы получите JSON с массивом models. HTTP 200 с пустым массивом означает, что API отвечает, но из этого нельзя сделать вывод о наличии нужной локальной модели. При ошибке соединения проверьте адрес, процесс Ollama и проброс порта. Флаг -f заставляет curl считать ошибкой HTTP 4xx/5xx; --max-time ограничивает ожидание на этом этапе. s1 s2 s5
2. Точный тег. Найдите в models[].name нужный локальный тег, например llama3.2, не подменяя его на произвольный latest: строку из вашего ответа скопируйте как есть. Список /api/tags сообщает о локально доступной модели и её метаданных, но не о текущей загрузке в память и не о пригодности для вашей задачи. Если тега нет, скачайте заранее выбранную модель по процедуре /api/pull или вернитесь к вводному гайду Ollama; загрузка может требовать сеть и свободное место. s2 s8
3. Пробная генерация. Подставьте существующий тег вместо ВАШ_ТЕГ и отправьте curl -fsS --max-time 120 http://localhost:11434/api/generate -H 'Content-Type: application/json' -d '{"model":"ВАШ_ТЕГ","prompt":"Ответь одним словом: готов","stream":false}'. В JSON проверьте done: true, отсутствие error и содержимое response; не проверяйте точное совпадение со словом «готов», поскольку ответ модели не детерминирован. Параметр stream:false даёт единый JSON вместо последовательности событий; длительность ожидания следует выбирать под своё устройство и холодную загрузку. Успех подтверждает выполнение этого запроса, а не стабильность сервиса под параллельной нагрузкой. s4 s5 s6
4. Состояние после запроса. Выполните curl -fsS --max-time 5 http://localhost:11434/api/ps и посмотрите models[].name и expires_at. Модель может быть выгружена по keep_alive, а параметр запроса способен переопределить настройку сервера. Поэтому мониторинг /api/ps не должен автоматически трактовать пустой список как отказ inference: для проверки готовности необходим фактический пробный запрос. s3 s4 s6

Выбирайте тег и размер по задаче и совместимости устройства в разделе Ollama. Время загрузки, RAM/VRAM и качество русских ответов нельзя вывести только из названия тега либо размера файла; здесь они не измерены. s2 s4

Что меняется в Docker Compose и при мониторинге?

Официальная Docker-инструкция показывает публикацию порта контейнера 11434. localhost внутри другого контейнера означает сам этот контейнер, а не автоматически контейнер Ollama. Адрес теста должен соответствовать реальной сети приложения: на хосте с опубликованным портом это может быть localhost:11434, в общей Docker-сети — имя сервиса и порт 11434. Это следствие топологии вашей установки, не универсальная готовая Compose-конфигурация. Не предполагается, что образ Ollama содержит curl или что Docker healthcheck сам скачает нужные веса. s7

Для внешнего мониторинга разделите лёгкий сигнал «процесс/API доступны» и дорогой прикладной сигнал «модель ответила». Частый запрос /api/generate может загружать веса и создавать работу даже без пользовательского трафика; подбирайте частоту, timeout и модель под свою систему. Это редакционная рекомендация, не измеренное пороговое значение. Если важны задержки и очередь, проверяйте их отдельным нагрузочным сценарием, а не одним ответом healthcheck; документация описывает очередь и возможный HTTP 503 при перегрузке. s4 s6

Что делать при ошибке?

• Соединение не устанавливается. Сначала проверьте доступность именно того адреса/порта, к которому подключается ваше приложение; в контейнерном сценарии сверьте публикацию порта и сеть. Не отправляйте запросы в прямой облачный API вместо локального только потому, что он доступен. s1 s7
• API отвечает, но нужного тега нет. models из /api/tags — локальный перечень. Уточните написание имени и при необходимости выполните осознанную загрузку через /api/pull; успешный HTTP списка не означает успешной генерации. s2 s8
• Модель есть, но генерация возвращает ошибку. Смотрите HTTP-статус и поле error в JSON. Документация отдельно описывает 400, 404, 429, 500, 502 и ошибки в середине потокового ответа; для stream:false не надо объявлять HTTP 200 единственным критерием, проверяйте тело и done. Точный способ устранения зависит от сообщения и вашей конфигурации. s4 s5
• /api/ps пустой после ожидания. Это список текущих загруженных моделей. Проверьте фактический тестовый ответ и срок keep_alive; не делайте вывод о неисправности сервера по одному пустому списку. s3 s6

Итоговый критерий перед передачей нагрузки: сохраните адрес сервера, точный тег, HTTP-статус и тело пробного ответа, время/дату проверки и условия устройства. На своих репрезентативных запросах затем отдельно проверьте качество и поведение при конкуренции; Modelium такой прогон не проводил. s2 s4 s6