Как получать streaming output из Replicate API без потери финального результата

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

• Поток нужен для раннего показа текстового или иного поддерживаемого результата, но объект prediction остается источником конечного статуса.
• SSE следует разбирать как события, а не произвольные строки TCP.
• Клиент обязан обрабатывать разрыв соединения и не считать его успешным завершением.
• Сохраненный prediction id позволяет позже запросить итоговое состояние.

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

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

1. Определите один критерий успеха. Для изображения это не только наличие URL, но и ненулевой файл, декодируемый формат, ожидаемые размеры и отсутствие служебной ошибки. Для текста — конечный статус, непустая строка и проверяемая структура.
2. Создайте отдельный токен для окружения и поместите его в REPLICATE_API_TOKEN на сервере. Не передавайте постоянный секрет в браузер, мобильный пакет, query string или журнал запроса.
3. На официальной странице модели скопируйте endpoint и точную схему input. Зафиксируйте model/version рядом с тестовым набором, чтобы обновление не смешалось с изменением кода.
4. Выполните минимальный пример ниже без очереди, ORM и автоматических retry. Сохраните HTTP-код, prediction id, status, error и время каждого перехода. Содержимое prompt логируйте только после обезличивания.
5. Сравните результат с ожиданием: Пользователь видит части ответа по мере поступления, но запись помечается готовой только после проверки prediction: status=succeeded и финальный output согласуются с отображенным содержимым.
6. Проведите отрицательный тест: испорченный файл, неверное поле, просроченная подпись или искусственный сетевой обрыв — в зависимости от сценария. Система должна завершиться контролируемо и не выдать частичный результат за готовый.
7. После приемки добавьте очередь, ограниченные повторы с задержкой, метрики и алерт. Повторяйте безопасный GET; новый POST создавайте лишь когда подтверждено, что предыдущая prediction не была создана или ее повтор допустим бизнес-логикой.

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

# Псевдокод транспорта: точный create-body берите со страницы API модели.
prediction = create_prediction_with_stream_enabled(input={"prompt": "Напиши три коротких пункта о резервном копировании"})
save(prediction["id"])
with open_sse(prediction["urls"]["stream"]) as events:
    for event in events:
        if event.type == "output": append_to_ui(event.data)
        elif event.type == "error": show_error(event.data)
final = get_prediction(prediction["id"])
assert final["status"] in {"succeeded", "failed", "canceled", "aborted"}
if final["status"] != "succeeded": rollback_partial_ui()

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

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

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

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

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

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

Ожидаемый результат: Пользователь видит части ответа по мере поступления, но запись помечается готовой только после проверки prediction: status=succeeded и финальный output согласуются с отображенным содержимым.

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

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

• поддержка streaming подтверждена у модели
• prediction id сохранен
• SSE разобран библиотекой
• обрыв переводит UI в неопределенное состояние
• финальный статус перепроверен

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