At a glance
- Did you know
- A shadow deploy copies live requests to a candidate model and compares its answers without showing them to users.
- Rule of thumb
- Mirror a small sample, and run the candidate on its own capacity.
- Watch out
- Mirroring 100% on shared capacity doubles the load and the bill.
Its settings in ScaleMySystems
What you can change on it in the lab, and what each number does.
- Concurrency (slots)
- Calls it can work on at once (per instance when autoscaling). Needed slots ≈ calls per second × seconds each takes. Extra calls wait in the queue, then are rejected.
- Queue capacity
- Calls allowed to wait for a free slot. A bigger queue absorbs bursts but adds waiting time; 0 rejects straight away.
- Latency (p50) (ms)
- Typical time one call takes here, before any calls it makes itself. Slots are held for this long.
- Latency (p99) (ms)
- The slowest 1% of calls. Callers must set their timeout above this or they cut off healthy calls.
- Mirrored share
- Share of live requests copied to the mirror target. The copies add load and cost; their answers are discarded.
Problems that start with it
- Shadowing the new model doubles the load A fine-tuned candidate model is deployed as an adapter on the production GPU pool, and a traffic mirror copies 100% of live requests to it to compare answers. Production is 60 requests a second on a pool that serves about 80.
Full lesson coming soon
Lessons are being added one component at a time: how it works, its settings, a live exercise to break and fix it, interview questions and a short check. See the Circuit breaker lesson for what one looks like.