Гайд · TNWS AI

Как создать deployment в Replicate API и ограничить масштабирование

12 сентября 2026 6 мин—

Создание deployment через интерфейс или POST /v1/deployments: model, version, hardware, min_instances, max_instances и проверка конфигурации.

Задача и применимость

Материал отвечает на запрос «как создать deployment Replicate API». Факты и названия параметров сверены 12 сентября 2026 года с официальной документацией Replicate. Цель — получить проверяемый технический результат, а не просто увидеть успешный HTTP-код.

Собственные или доступные версии моделей Replicate, которым нужен управляемый deployment. Hardware и допустимые границы масштабирования выбирают из актуальных значений интерфейса/API, а не из примера статьи.

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

Что подтверждает документация

В интерфейсе deployment создается в replicate.com/deployments через Create a new deployment.
На Settings настраиваются hardware и autoscaling.
API создания — POST https://api.replicate.com/v1/deployments.
Тело содержит name, model, version, hardware, min_instances и max_instances.

Объект prediction нужно считать отдельной сущностью со своим id, status, output, error и ссылками управления. Сохраняйте id сразу после создания: без него невозможно надежно выяснить, завершилась ли задача после сетевого таймаута. Не создавайте вторую prediction только потому, что клиент перестал ждать первую.

Пошаговая настройка

Определите один критерий успеха. Для изображения это не только наличие URL, но и ненулевой файл, декодируемый формат, ожидаемые размеры и отсутствие служебной ошибки. Для текста — конечный статус, непустая строка и проверяемая структура.
Создайте отдельный токен для окружения и поместите его в REPLICATE_API_TOKEN на сервере. Не передавайте постоянный секрет в браузер, мобильный пакет, query string или журнал запроса.
На официальной странице модели скопируйте endpoint и точную схему input. Зафиксируйте model/version рядом с тестовым набором, чтобы обновление не смешалось с изменением кода.
Выполните минимальный пример ниже без очереди, ORM и автоматических retry. Сохраните HTTP-код, prediction id, status, error и время каждого перехода. Содержимое prompt логируйте только после обезличивания.
Сравните результат с ожиданием: Ответ описывает deployment, его owner/name совпадают с запросом, current_release указывает на нужную model/version, а configuration отражает проверенные hardware и границы instances.
Проведите отрицательный тест: испорченный файл, неверное поле, просроченная подпись или искусственный сетевой обрыв — в зависимости от сценария. Система должна завершиться контролируемо и не выдать частичный результат за готовый.
После приемки добавьте очередь, ограниченные повторы с задержкой, метрики и алерт. Повторяйте безопасный GET; новый POST создавайте лишь когда подтверждено, что предыдущая prediction не была создана или ее повтор допустим бизнес-логикой.

Минимальный рабочий пример

curl -s -X POST \
+  -H "Authorization: Bearer $REPLICATE_API_TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"name":"catalog-captioner","model":"<ORG>/<MODEL>","version":"<VERSION_ID>","hardware":"<HARDWARE_SLUG>","min_instances":0,"max_instances":2}' \
+  https://api.replicate.com/v1/deployments

Пример намеренно не содержит настоящего токена. Для модели, версии, hardware или имени поля используйте только актуальную страницу API. Если ответ отличается от примера, сначала сравните endpoint и schema, затем версию клиентской библиотеки, и лишь потом меняйте обработчик.

Готовый шаблон проверки с ИИ

Роль: инженер по приемке Replicate API.
Проверь сценарий: как создать deployment Replicate API.
Вход: приложенный JSON запроса, HTTP-код, объект prediction и локальные метрики.
Верни таблицу: проверка | фактическое значение | PASS/FAIL | исправление.
Не считай HTTP 200 достаточным. Не выдумывай отсутствующие поля; отмечай их как MISSING.

Такой промпт можно передать модели для первичной ревизии логов, но секреты и персональные данные предварительно удаляются. Итог PASS/FAIL рассчитывает код по явным условиям. Нейросеть не должна решать, считать ли failed успехом или можно ли проигнорировать неверную подпись.

Контрольный вход и ожидаемый результат

Контрольный вход указан в примере: короткий prompt или локальный файл с заранее известными свойствами. До вызова API сохраните SHA-256 входного файла либо точную строку prompt, идентификатор модели и схему ожидаемого результата. Это позволяет воспроизвести тест и отделить изменение модели от ошибки транспорта.

Ожидаемый результат: Ответ описывает deployment, его owner/name совпадают с запросом, current_release указывает на нужную model/version, а configuration отражает проверенные hardware и границы instances.

Проверьте и негативный вход. Пустой prompt, отсутствующий файл, недоступный URL или неверная подпись должны привести к понятному отказу. Не заменяйте отсутствующие поля пустыми строками: MISSING, null, пустой output и сетевой таймаут означают разные состояния и требуют разных действий.

Критерии приемки

name уникален и понятен
version зафиксирована
hardware выбран из актуального списка
min не больше max
конфигурация ответа совпала с запросом

Дополнительно измерьте время до создания prediction, время в starting, время в processing и полную длительность. Эти величины помогают отличить запуск worker от длительного выполнения модели. Для файлов сохраняйте число байтов, MIME после декодирования и хеш. Для webhook фиксируйте результат проверки подписи и дедупликации.

Типичные ошибки и что не делать

Копировать gpu-t4 из демонстрационного запроса, не проверив доступность и требования модели.
Ставить min_instances выше нуля без оценки постоянной нагрузки.
Менять version без регрессионного набора входов.

Не делайте бесконечные повторы на 4xx: неправильный токен, неизвестное поле или неподдерживаемая версия требуют изменения запроса. Для временных 5xx и сетевых ошибок используйте ограниченный retry с jitter. Перед повторным POST проверьте, не существует ли уже prediction с сохраненным id, иначе пользователь получит несколько результатов и лишние вычисления.

Еще одна ошибка — принимать URL результата за постоянное хранилище. Если файл нужен позже, переносите его в собственный объектный storage, проверяйте размер и хеш, а в базе храните стабильный адрес. Политика хранения должна учитывать исходные данные, output и диагностические логи отдельно.

Проверка на реальных данных

Соберите 20 обезличенных тестов: минимальный корректный input, кириллица, длинный prompt, файл на границе допустимого размера, поврежденный файл, недоступный URL и принудительный таймаут. Для каждого задайте машинное условие, а не эталонную красивую картинку: статус, формат, обязательные поля, диапазон размера и отсутствие ошибки.

Запускайте набор при смене version, SDK или инфраструктуры. Отдельно считайте технический успех и содержательное качество. Prediction со статусом succeeded, но пустым или недекодируемым output, не должна проходить приемку. И наоборот, клиентский таймаут не доказывает, что серверная задача завершилась ошибкой.

FAQ

Можно ли считать HTTP 200 доказательством успешной генерации?

Нет. Нужно проверить конечный status, отсутствие error, форму output и критерии содержимого.

Где брать точные поля input?

На странице API конкретной модели и версии Replicate. Схема другой модели может быть несовместима.

Что сохранить для диагностики?

Prediction id, model/version, status, error, временные метрики и результат локальной валидации — без токена и лишних персональных данных.

Нужно ли повторять POST после сетевого таймаута?

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

Официальный источник

Документация Replicate

Частые вопросы

Достаточно ли HTTP 200?

Нет, проверьте конечный status, error и валидность output.

Где брать схему input?

На странице API конкретной модели и версии Replicate.

Можно ли хранить токен в браузере?

Нет, постоянный токен должен оставаться на backend.

Что делать после сетевого таймаута?

Проверить исходную prediction по сохраненному id, а не сразу создавать новую.