Подключая Seedance к бизнесу, многие команды сначала выбирают релей или прокси: поменять base URL и ключ кажется проще, чем идти напрямую. Но видеогенерация асинхронна, и цепочка через релей добавляет к текстовому интерфейсу сохранение задачи, сопоставление статусов, перенос результата и callback. Если любой участок сделан слабо, это выглядит как «задача отправлена успешно, а видео не получить».

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

Примечание: Seedance — название модели видеогенерации Volcengine, принадлежащей ByteDance; соответствующие товарные знаки принадлежат правообладателям. Статья носит технический характер и не подразумевает аффилированность или сотрудничество с ByteDance; интерфейсы, модели и цены определяются официальной документацией и ценами на модели на сайте.

1. Четыре вида «релея»

Тип Что делает Основной риск Сценарий
Обратный прокси Пересылает запросы к официальному интерфейсу Единая точка, полоса выхода, настройка аутентификации Команды с эксплуатационной экспертизой
Агрегирующий шлюз Единый вход, объединяет несколько моделей Сопоставление статусов, различия параметров Мультимодельный бизнес
Дистрибуция/пополнение Перепродажа квоты upstream или оплата за клиента Стабильность upstream, условия обслуживания Небольшие тесты, разовые задачи
Собственный шлюз Самостоятельное развёртывание и обслуживание пересылки Вся ответственность на вас Техническая команда, контроль данных

Что вы покупаете — «технический сервис» или «квоту модели» — определяет, кто отвечает за сбой. Договор, счёт и условия обработки данных нужно обсуждать исходя из этого различия.

2. Какие этапы добавляются у асинхронной задачи в релее

Ваш сервис
  → вход релея (аутентификация, лимиты, биллинг)
  → upstream создаёт задачу, возвращает task_id
  → релей сохраняет связь task_id и номера заказа
  → релей опрашивает upstream или принимает callback
  → после сопоставления статуса отдаёт вашему опросу или webhook
  → вы скачиваете результат и сохраняете

Каждый дополнительный переход — ещё одно место, где можно потерять состояние:

  • Релей перезапустился или сменил экземпляр, и связь задач в памяти потерялась.
  • Upstream ответил тайм-аутом, но задача уже создана; релей вернул ошибку, клиент повторил и получил две задачи.
  • У upstream статус expired, а релей сопоставил только успех и сбой, и бизнес ждёт бесконечно.
  • Релей закешировал URL результата под своим адресом, но после истечения кеша не сходил к источнику.
  • Повтор webhook без ключа идемпотентности приводит к дубликату в базе.

Оценивая релей, не спрашивайте только «поддерживает ли Seedance»; уточните, как сохраняется ID задачи, как сопоставляются статусы и как компенсируются сбои.

3. Статусы задач и срок хранения результатов

По документации Volcengine Ark статусы задачи Seedance обычно включают queued, running, succeeded, failed, cancelled, expired; записи задач доступны около 7 дней, а ссылка на видео в успешном результате обычно очищается через 24 часа.

Релей должен добавить слой над этими ограничениями:

  • Сохраняет ли он записи задач? Как долго? Можно ли проверить после 7 дней?
  • Скачивает ли он видео сам? Если хранит, сколько дней и берёт ли доплату?
  • Возвращает временный URL upstream или собственный долгоживущий адрес?
  • Как отображаются отмена, тайм-аут и отказ модерации?

Если релей только «прозрачно пересылает», ответственность за сохранение в течение 24 часов остаётся на вас; если он «хостит», уточните место хранения, права доступа и механизм удаления. Оба варианта допустимы, недопустима неопределённость.

4. Как проверить прозрачность биллинга

Споры по видео возникают чаще, чем по тексту, потому что сбои, повторы и отмены происходят на асинхронном этапе. До подписания уточните:

  • Единица тарификации: длительность, разрешение, задача или пересчёт в токены.
  • Платны ли сбой, тайм-аут, отмена и отказ модерации.
  • Списываются ли повторная отправка и повторы дважды, есть ли дедупликация по идемпотентности.
  • Есть ли минимальный расход, порог предоплаты, правила возврата и тип счёта.
  • Содержит ли детализация ID задачи, модель, длительность, разрешение, статус и сумму списания.

Не смотрите только на скидку на рекламной странице. Прогоните 20–50 задач небольшими партиями в течение недели и сверьте успешные, неуспешные задачи и счёт построчно — это надёжнее любых обещаний. Конкретные цены — на странице цен на модели.

5. Ключи и риски upstream

Релей означает, что содержимое запроса проходит через третью сторону. Как минимум уточните:

  1. Сохраняются ли промпты, первый кадр и сгенерированное видео, как долго.
  2. Используются ли данные для обучения или улучшения сервиса.
  3. Можно ли ограничить ключ по квоте, IP и сроку действия.
  4. Как уведомляют об утечке или злоупотреблении и как блокируют.
  5. Один канал у upstream или несколько, как мигрировать при снятии модели.
  6. Допускают ли условия перепродажу или агентскую схему и где границы ответственности.

Production-ключ не должен попадать во фронтенд или публичный репозиторий. Для особо чувствительных материалов выбирайте поставщика с отказом от записи на диск или готовностью подписать соглашение об обработке данных; если это не подтверждено, не загружайте необезличенные клиентские материалы.

6. Шаги миграции с прямого подключения на релей

  1. Инвентаризируйте текущие вызовы: ID моделей, параметры, параллелизм, среднюю длительность и типы сбоев.
  2. Уточните пути интерфейса релея, аутентификацию и различия полей, составьте таблицу соответствия.
  3. В тестовой среде пройдите четыре пути: создание, проверка, отмена и скачивание.
  4. Запустите теневой режим на одной партии: прямое подключение и релей параллельно, только сравнение без переключения.
  5. Сравните успешность, P95 времени, долю скачиваемых результатов и стоимость одной задачи.
  6. Переводите трафик постепенно, 5–20%, сохраняя переключатель возврата на прямое подключение.
  7. Наблюдайте 3–7 дней и убедитесь, что счёт и детализация задач сходятся.
  8. После полного перехода оставьте резервный двойной канал и упрощайте архитектуру только после подтверждения стабильности.

Во время миграции не удаляйте ключ прямого подключения и не записывайте две задачи под одним номером заказа, иначе сверка станет невозможной.

7. Как проверить релей-сервис

# 1. Отправить минимальную задачу, записать task_id и время отправки
curl -X POST "$RELAY_BASE_URL/contents/generations/tasks" \
  -H "Authorization: Bearer $RELAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"ID модели из документации релея","content":[{"type":"text","text":"Кот зевает у окна"}]}'

# 2. Проверять раз в 10 секунд, фиксируя полную смену статусов
curl "$RELAY_BASE_URL/contents/generations/tasks/$TASK_ID" \
  -H "Authorization: Bearer $RELAY_API_KEY"

Специально создавайте аномалии: отмените сразу после отправки, передайте неверный ID модели, отправьте параллельно, оборвите скачивание. Смотрите, совпадают ли статусы, сообщения об ошибках и счёт. Через 24 часа снова обратитесь к адресу результата и проверьте, скачивается ли он; через 7 дней проверьте, сохранилась ли запись задачи.

8. Мониторинг и откат после миграции

  • Считайте задачи по статусам, отдельно наблюдая долю failed, cancelled, expired.
  • Фиксируйте общее время от отправки до успеха, а также время в очереди и генерации.
  • Мониторьте долю успешных скачиваний; для неудачных нужна очередь компенсации.
  • Считайте 401, 404, 429, 5xx, разделяя проблемы ключа, модели и лимитов.
  • Считайте «стоимость одного успешного видео», а не только ставку за запрос.
  • Задайте порог отката: например, если успешность два часа подряд заметно ниже базовой, вернуться на прямое подключение.

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

Возможности модели через релей такие же, как напрямую?

Зависит от того, пересылает ли релей тот же upstream и те же параметры. ID модели, длительность, разрешение и аудио могут отличаться; до подключения сравните вывод и поддержку параметров на одном промпте.

Релей сохраняет мои видео?

У разных сервисов по-разному. Уточните, пишется ли результат на диск, сколько хранится, где, кто имеет доступ и как удаляется. Для клиентских материалов выбирайте поставщика с понятными условиями.

Что делать, если задача потерялась на стороне релея?

Сначала проверьте локальную запись по номеру заказа, затем журналы релея и задачу upstream. Если восстановить нельзя, остаётся отправить заново; поэтому до миграции уточните, сохраняет ли релей связь задач и поддерживает ли поиск по номеру заказа.

Почему счёт не сходится с числом задач?

Частые причины: повторная отправка, повторы после сбоев, разные правила отмены, минимальный расход или попадание в кеш. Запросите детализацию списаний по ID задач и сверяйте построчно, а не только итог.

Нужно ли менять код при миграции?

Если релей совместим с OpenAI или официальным интерфейсом задач, обычно достаточно поменять base URL, ключ и несколько полей; если отличается сопоставление статусов или формат callback, придётся менять опрос и запись в базу. Теневой режим заранее выявит большинство различий.

Следующий шаг

Создайте тестовый ключ в ZSQH AI Gateway, проверьте на минимальной задаче четыре цепочки — создание, опрос, скачивание и счёт — и только затем мигрируйте постепенно. Модели и цены — на странице цен на модели.

Что читать дальше: