Practice — Case Study: Virtual Try-On for Fashion E-commerce (6 questions)

A teammate proposes simplifying the virtual try-on architecture: "We already have a solid TryOnDiffusion-style cascaded model for personal mode. Let's just use it for catalog-mode rendering too — one model, one service, less to maintain, and it's the higher-quality option anyway."

1. Using the latency and quality axes from the GAN-vs-diffusion comparison table (generative-adversarial-networks-and-face-generation), explain what this proposal gets wrong about personal mode specifically.
2. Is the proposal's choice of model actually wrong for catalog mode? Explain why or why not, referencing each mode's latency budget from Step 1.
3. Propose the correct architecture split and explain what would actually be lost (if anything) by not standardizing on one model.

An engineer proposes: "Instead of building a general try-on model, let's fine-tune a diffusion model per garment using a DreamBooth-style approach — a handful of reference images per SKU, a few GPU-minutes of fine-tuning, then we can generate that garment on any shopper's photo by prompting for it."

1. Explain, with a back-of-envelope calculation, why this doesn't survive the catalog's scale and churn rate from Step 1.
2. Beyond the raw compute cost, explain the second, structural reason this approach fails — what does DreamBooth actually solve, and what does it not solve that virtual try-on specifically needs?
3. Is there any part of this product where a DreamBooth-style per-subject fine-tune genuinely is the right tool? If so, name it and explain why the constraints differ.