Sarghaby Araghatta
Home / Knowledge Base / Deployment patterns (blue-green, canary, shadow)
LLMOps · AI Engineering

Deployment patterns (blue-green, canary, shadow)

Progressive-delivery strategies for swapping models/prompts. Blue-green: two full environments, flip all traffic. Canary: send a small % to the new version, ramp up. Shadow: mirror real traffic to the new version but don't serve its responses.

Route TrafficRoute TrafficMonitor QualityMirror TrafficOld Version(Production)New Version(Candidate)Traffic Split(Blue-Green)Traffic Monitoring(Canary)Shadow Traffic(Validation)
Deployment Patterns Overview

How it works

Blue-green deployment maintains two complete environments: one running the current version and the other hosting the new version. When you're ready to switch, you simply flip all traffic to the new version. This setup keeps the old version hot, allowing for an instant rollback if any issues arise. For example, if you have a language model that generates text, you can switch users to the updated model without downtime, ensuring a smooth transition.

Canary deployment takes a more gradual approach. You start by routing a small percentage of traffic, say 1%, to the new version. You monitor key metrics like quality, error rates, and cost. If everything looks good, you incrementally increase the traffic to 5%, then 50%, and eventually to 100%. This method allows you to catch regressions early and roll back automatically if you detect any performance drop, which is crucial for models that might produce subtle but significant errors.

Shadow deployment runs the new version in parallel with the old one, mirroring real traffic but not serving its responses to users. Instead, it logs the outputs for offline comparison against the production version. This approach is the safest way to validate changes to a language model using live inputs without exposing users to potential issues. You can analyze how the new model performs against the old one, ensuring that any adjustments improve output quality before making them public.

  • Use Blue-Green for instant rollback.
  • Use Canary for gradual rollout.
  • Use Shadow for risk-free validation.

The software-engineering analogue

These deployment patterns are similar to traditional software service deployment strategies. In both cases, you want to ensure that your users have a stable experience while introducing new features or improvements. However, the key difference lies in what constitutes a 'healthy' deployment. In software, you might focus on metrics like response times and error rates. In AI, especially with language models, you also need to consider output quality, which is where shadow mode excels. It allows you to capture and analyze the new model's responses without impacting user experience.

Why not the obvious alternative

A naive approach might be to simply switch to the new model all at once, assuming that if it passes initial tests, it will perform well in production. However, this hard cutover can be risky. Any regression hits 100% of users immediately, and with language models, regressions often manifest as subtle declines in answer quality rather than outright failures. This can lead to user dissatisfaction and loss of trust.

Progressive exposure through blue-green, canary, or shadow deployments mitigates this risk. By limiting the blast radius, you can catch issues early and gather real-traffic evidence about the new model's performance. This way, you protect your users from potential regressions while still pushing forward with improvements.

When to use which

Use shadow deployment when you want to validate a candidate model against production inputs without any risk to users. This is ideal for ensuring that the new model performs well in real-world scenarios. Canary deployment is suitable for actual gradual rollouts, allowing you to monitor live quality and cost metrics as you increase traffic to the new version. Blue-green deployment is best when you need an instant and clean rollback option and can afford the additional capacity required to run both environments simultaneously.

Subtle Regressions Matter In LLMs, regressions can be subtle and not crash the system. Monitor output quality closely.

In production: when it breaks

The scenario During a blue-green deployment, 30% of users report increased latency.
High Latency ReportsCheck Traffic RoutingCheck Resource AllocationCheck Model PerformanceFix Traffic MisroutingScale Up ResourcesOptimize Model
Debugging deployment patterns

Why it happens. The new model may not handle certain edge cases or input distributions effectively, leading to a higher error rate. This could be due to insufficient training data or differences in feature handling between the old and new versions.

  • Check the logs for error messages and stack traces from the new model.
  • Compare the input features of the requests sent to both models to identify discrepancies.
  • Review the training dataset for the new model to ensure it includes representative samples.
The call Rollback to the previous model to restore stability while investigating. The tradeoff is a temporary loss of new features or improvements. Monitor the error rates and user feedback closely to identify any further issues with the new model before redeploying.

What it delivers

These deployment patterns deliver safe upgrades for models and prompts, using evidence gathered from real traffic to make informed decisions. They provide a fast escape hatch if something goes wrong, ensuring that you can maintain user trust while continuously improving your AI systems.