Если вы ищете Z Image Turbo Image to Image LoRA API, проверьте совместимость, прежде чем копировать запрос из другого сервиса. Названия моделей, форматы адаптеров и параметры различаются в зависимости от поставщика. Начните с model catalog, затем используйте ссылку на выбранную модель для определения запроса.
В этом руководстве объясняется, как оценить рабочий процесс LoRA для преобразования изображения в изображение через OdiRouter. В нём не утверждается, что конкретная внешняя модель, цена, конечная точка или поле адаптера доступны на OdiRouter. Прежде чем строить решение вокруг именованной возможности, подтвердите актуальный каталог и документацию по маршруту.
Проверьте модель перед написанием вызова
Рабочий процесс преобразования изображения в изображение начинается с эталонного изображения и инструкции, описывающей изменение. Рабочий процесс LoRA может добавлять один или несколько адаптеров, влияющих на объект, стиль или другую изученную концепцию. Поля из примера другого поставщика недостаточно. Выбранный вами маршрут должен документировать этот входной параметр через OdiRouter.
Выберите в каталоге модель с поддержкой изображений и ознакомьтесь с её актуальной справочной документацией. Зафиксируйте идентификатор модели, допустимый источник изображения, поддерживаемый формат вывода, режим запроса и все элементы управления адаптером или преобразованием. Введение к OdiRouter охватывает ключи API, авторизацию, идентификаторы моделей, первые запросы и асинхронные многомодальные задачи. Это удобное место для начала интеграции.
Определите, что должен доказать первый тест.
Определите ожидаемое поведение до создания полезной нагрузки. Таким образом, вы сможете отличить ограничение модели от ошибки запроса.
Сохраните композицию или допустите более существенное визуальное изменение.
Определите, требуется ли выбранной модели адаптер, принимает ли она его или не поддерживает.
В первом тесте используйте один размер вывода и один формат вывода.
Определите, как ваше приложение распознаёт завершённую задачу, неудачную задачу и вывод, не прошедший проверку приемки.
Приведённый ниже пример — это схема планирования, а не схема запроса OdiRouter. Его названия полей приведены в качестве примера. Замените их документированным контрактом выбранной модели.
{
"model": "<current-model-id>",
"input_image": "<approved-image-source>",
"prompt": "<change-you-want-to-make>",
"adapter": "<only-if-the-model-documents-it>",
"output_format": "<supported-format>",
"task_id": "<your-trace-id>"
}Во время первого прохода не изменяйте эталонное изображение и промпт. Корректируйте по одному документированному элементу управления за раз. Если выбранная модель имеет настройку, аналогичную силе воздействия, сравните несколько значений с письменными критериями приемки. Схоже названный элемент управления может работать иначе в другой модели.
Проектируйте с учётом жизненного цикла задачи
Первоначальный мультимодальный запрос может создать задачу вместо возврата готового изображения. Сохраните идентификатор задачи, прочитайте документированный ответ о статусе и проверьте готовый результат, прежде чем показывать или сохранять его. Ответ на обработку не является результатом обработки изображения. Для неудачного ответа необходим путь обработки ошибки, сохраняющий достаточно контекста для повторной попытки или проверки.
Модуль getting-started documentation описывает настройку API-ключа, идентификаторы моделей, примеры первого запроса и асинхронные задачи для обработки изображений и других мультимодальных данных. Используйте справочную документацию для конкретной модели по полям статуса, выбору конечной точки и поддерживаемым входным данным. Это позволяет привязать код к выбранному вами маршруту, а не к универсальному примеру.
Начните с небольшого проекта по проверке концепции.
Используйте изображение, которое вы имеете право обрабатывать, один чёткий промпт и небольшой набор ожидаемых результатов. Записывайте идентификатор модели, время запроса, статус задачи, расположение возвращённого результата, сведения об ошибке и любую документированную информацию об использовании. Сравните результат с поведением, которое вы определили до теста.
Одновременно проверьте эксплуатационные ограничения. Выясните, как долго задача может оставаться в ожидании, безопасны ли повторные попытки, как следует обрабатывать URL-адреса результатов и когда изменение модели требует новой проверки. Один успешный результат не доказывает, что в production будут работать все входные данные, адаптеры или форматы изображений.
Выберите маршрут через OdiRouter
Изучите current OdiRouter models, выберите маршрут, документирующий возможности, необходимые вашему рабочему процессу, и следуйте этой документации перед началом реализации. Создайте API-ключ, затем используйте официальную документацию, чтобы перейти от небольшого теста к интеграции с мониторингом. Этот процесс остаётся полезным даже при изменении каталогов моделей и параметров.