Qwen-Image-2.1 open source: RGBA, 10 refs і research license — що реально для Bubble bulk через BIAIG

Контекст

У digest з’явився реліз Qwen-Image-2.1 (20.09.2026): open weights на GitHub/Hugging Face/ModelScope — один пайплайн text-to-image і image editing, 7B DiT, encoder Qwen3-VL 8B, 64-channel RGBA VAE. У документації: native RGBA (prompt-guided), до 10 reference images в одному edit/composition call, локальні правки через маски/анотації, пресети aspect ratio близько 2K, за замовчуванням 40 inference steps, опційні prompt-rewriter (PE-T2I / PE-I2I). Day-0 інтеграції: Diffusers (QwenImage21Pipeline), ComfyUI, vLLM-Omni, SGLang.

Питання від Bubble-розробників звучить просто: чи це альтернатива closed API для catalog/ad variants? Коротка відповідь для production bulk через BIAIG: технічно self-host можливий, але legal/compliance gate стоїть раніше за GPU. Схожий розбір: Qwen-Image-2.1 до 28.09 UTC+8: freeze. Про це окремо: ComfyUI 0.40 і Qwen-Image 2.1. Схожий розбір: Qwen-Image-2.1 до 28.09 UTC+8: freeze.

Research license — не footnote

Ваги йдуть під Qwen Research License Agreement (effective 2026-09-20): use/modification/redistribution — лише non-commercial; commercial use потребує окремої ліцензії (у LICENSE — контакт [email protected]). Є вимоги до notice, marking modifications, attribution («Built with Qwen» / «Improved using Qwen» у певних сценаріях), export-control compliance.

Для revenue-generating Bubble catalog/ad bulk на публічних weights без commercial license Scout-пакет класифікує це як material legal risk, а не питання «скільки VRAM». POC, internal R&D, демо без монетизації — інша розмова; клієнтський bulk — ні, поки права не формалізовані.

Self-host: що реально по ops

README описує повний стек (7B + 8B VL + VAE). VRAM у публічних джерелах розходиться: framework-доки з VRAM management — порядку ~7GB minimum; незалежні setup guides часто вказують ~16–24GB class GPU для типових int8/bf16; розмір завантаження компонентів — порядку 15–30GB. Throughput для bulk залежить від serving (один GPU Diffusers vs vLLM/SGLang batching), опційного prompt-rewrite і дефолтів 2K/40 steps — vendor-neutral bulk SLA Scout не знайшов.

Тобто «підключити Qwen напряму в Bubble» — це не один API Connector call, а GPU capacity, serving, monitoring, patching, плюс можливий другий inference stage на PE-rewrite.

RGBA і 10 refs vs те, що вже в оркестрації

Qwen-Image-2.1 (документація моделі):

• hard cap 10 reference images на один call;
• native RGBA generation/editing in-model (64-channel VAE).

Порівняння лише з primary API docs (не BIAIG-specific):

• OpenAI images/edits для GPT Image — до 16 input images; RGBA в API акцентовано для masks (alpha), не як «native transparent output» на рівні Qwen README.
• Google Gemini 3.x image — до 14 reference images з role splits (напр. gemini-3.1-flash-image: до 10 object + 4 character refs); native RGBA-as-output у тих же сторінках не описано еквівалентно Qwen VAE.

Fal і інші aggregators у цьому Scout-pass не верифіковані.

Практичний висновок для multi-asset catalog compositions: 10 refs може бути вузьким місцем порівняно з 16 (OpenAI edit) або 14 (Gemini). Native RGBA цікавий, якщо прозорість — частина продуктового контракту, а не post-process; neutral A/B проти background removal у наявних BIAIG/GPT/Gemini pipelines Scout не знайшов — не продавайте RGBA як перемогу без власного заміру.

Hosted API path для 2.1

QwenCloud Images FAQ (контекст 22.09.2026) перелічує моделі сімейства qwen-image-2.0 / 3.0 з per-image billing; Qwen-Image-2.1 by name у переглянутому FAQ не фігурує — немає verified self-serve DashScope SKU для 2.1. HF demos, ModelScope Civision, wuli.art — не замінюють production licensing terms. Схожий розбір: Qwen-Image-2.1 vs closed models: vendor. Схожий розбір: Qwen-Image-2.1 vs closed models: vendor.

Коли лишатися на BIAIG над GPT Image 2.5 / Gemini / fal

Ця нотатка не дублює checklist по GPT Image 2.5 refs чи статтю про Gemini як третій провайдер; вона про місце Qwen-2.1 у стеку.

Залишайтеся на оркестрації BIAIG над commercial APIs, коли:

• потрібні production rights і SLA зараз;
• bulk уже налаштований під GPT Image / Gemini / fal з вашими retry, QA і ref-ролями;
• composition потребує >10 refs або змішаних провайдерів;
• команда не готова тримати self-hosted diffusion ops. Схожий розбір: Tencent Hy Image 3.5 Preview.

Qwen-Image-2.1 має сенс як:

• research / POC (прозорість, 10-ref edits, локальні експерименти);
• future backend candidate після (1) commercial license або hosted API з прийнятними ToS/pricing, (2) виміреного throughput/cost на вашому serving stack, (3) product integration в BIAIG (якщо абстракція взагалі покриває self-hosted backends — публічного BIAIG architecture doc у Scout не було).

«Підключити Qwen напряму» стає реалістичним не від digest-hype, а після явного commercial licensing або hosted SKU — і окремої інженерної лінії, а не заміни одного API key.

Benchmarks — обережно

Alibaba Cloud Community посилається на Qwen-Image-Bench; secondary press згадує числа на кшталт ~60.28 — methodology і independent replication Scout не верифікував. Не будуйте roadmap на «перемогу на bench» без власного eval на ваших catalog/ad tasks.

Checklist перед рішенням

1. Legal: commercial license або чіткий ToS hosted route — до будь-якого paid bulk.
2. Product: чи 10 refs + RGBA закривають ваш variant matrix, чи orchestration з 14–16 refs дешевше по rework.
3. Ops: measured latency/failure rate на vLLM/SGLang vs managed APIs при ref count близько 10.
4. Compliance: export controls і attribution, якщо fine-tune або embed weights.

Відкриті питання (з Scout)

Published pricing commercial license; чи з’явиться 2.1 на DashScope як 2.0/3.0; чи research license обмежує саме customer-facing outputs чи лише weights — потрібен qualified legal review; economics bulk 2K/40-step; RGBA fidelity vs post-process у ваших пайплайнах.

---

Джерела: Qwen-Image-2.1 GitHub README, HF LICENSE/model card, Alibaba Cloud Community post, QwenCloud Images FAQ, OpenAI/Gemini image API docs, DiffSynth-Studio framework doc; secondary — LaoZhang blog, GadgetsNow press. Не legal advice.