Arguing Against a One-Model, One-Latency-Target Design
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."
- 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. - 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.
- Propose the correct architecture split and explain what would actually be lost (if anything) by not standardizing on one model.
1. What's wrong for personal mode:
Personal mode has a sub-5-second interactive latency budget with a shopper actively watching the screen. TryOnDiffusion's cascade is inherently iterative — a base-resolution diffusion pass followed by super-resolution refinement stages — which costs meaningfully more wall-clock time per request than a single forward pass through a warp-and-composite GAN. Running the diffusion cascade as the default synchronous path for every personal-mode request risks blowing the latency budget on ordinary traffic, not just edge cases, trading away the interactive feel of the single most common shopper action (tap a garment, see it on me) for a quality gain most requests don't need to look convincing.
2. Is the model choice wrong for catalog mode?
No — for catalog mode specifically, using the diffusion cascade is the right choice, not the mistake. Catalog mode's latency budget is hours (a batch job triggered by SKU ingestion or update), so the cascade's extra cost per render is essentially free relative to that budget, and catalog mode is exactly where the diffusion lineage's quality ceiling — better handling of large pose/garment misalignment via implicit cross-attention correspondence — pays off most, since every shopper who views that product page sees the same precomputed render. The proposal isn't wrong to reach for diffusion for catalog rendering; it's wrong to conclude from that correctness that the same model belongs on personal mode's request path too.
3. The correct split, and what's actually lost:
Keep the fast GAN warp-and-composite lineage as personal mode's default synchronous path, and use the diffusion cascade for catalog mode's batch rendering (and, per the scalability deep-dive, as an optional async refine step in personal mode for shoppers who linger). What's lost by not standardizing on one model is real but bounded: two model families to train, evaluate and version instead of one, and two serving paths instead of one. What's preserved is the thing that actually matters to the business — personal mode stays inside its latency budget on the common case, and catalog mode gets the highest quality the budget allows — which is a better trade than a single "simpler" architecture that quietly fails one mode's core constraint to save maintenance overhead.
Share this question