System DesignMLOps

Designing an MLOps Pipeline for a B2B SaaS with 10k Monthly Models

A B2B SaaS needs an MLOps pipeline to deploy and manage 10,000 models monthly. The challenge is balancing cost and latency while ensuring observability.

Aug 24, 20264 min readOriginal analysis
Fig. 01 — Architecture
Data flows from client requests through model serving, with observability tools monitoring performance.
01

The scenario

A B2B SaaS company offers custom AI solutions to its clients, each requiring bespoke models. They plan to deploy and manage 10,000 models monthly, with each model updated on average once a week. The team consists of 10 engineers, and they must operate within a $50,000/month budget for cloud infrastructure.

The system must ensure models are deployed with minimal latency while maintaining high availability and observability. Failure to meet these requirements could lead to SLA breaches and client dissatisfaction, impacting revenue and reputation.

02

Requirements

  • R1Support 10,000 model deployments monthly
  • R2Average model update latency under 2 minutes
  • R3Cloud infrastructure budget under $50,000/month
  • R499.9% availability for model serving
  • R5Full observability with latency and error metrics
03

The design

3.1Model Training and Versioning

Training is conducted on AWS SageMaker using Ray-2.58.0 for distributed processing, taking advantage of its new token-aware request routing to optimize resource allocation. Model artifacts are stored in S3, with metadata tracked in a PostgreSQL database for versioning and audit trails.

3.2Deployment and Serving

Deployments are managed with KubeRay on Amazon EKS. Each model is containerized and deployed as a microservice using Kubernetes, allowing for easy scaling and isolation. Ray Serve is used for model inference, benefiting from its KV cache to reduce latency in repeated requests.

3.3Monitoring and Observability

Datadog is integrated for monitoring, providing metrics on request latency, error rates, and system health. Logs are centralized in Elasticsearch, enabling real-time anomaly detection using Databricks' AI-enhanced incident investigation tools.

04

Capacity math

MetricValue
Monthly Model Deployments10,000 models
Average Update Latency1.5 minutes
Infrastructure Budget$50,000/month
Availability99.9%
05

Trade-offs

Model Serving Framework

Picked

Ray Serve

Passed on

TensorFlow Serving

Ray Serve's KV cache reduces latency for repeated requests, crucial for our SLA.

Monitoring Tool

Picked

Datadog

Passed on

Prometheus

Datadog offers out-of-the-box integrations and anomaly detection which are essential for rapid response.

Deployment Platform

Picked

KubeRay on EKS

Passed on

Self-managed Kubernetes

Amazon EKS reduces operational overhead, aligning with our small team size.

06

Failure modes

What breaksSymptomMitigation
Model Deployment FailureIncreased error ratesAutomatic rollback using Kubernetes health checks.
Latency SpikesAlerts from DatadogRay Serve's KV cache and token-aware routing help mitigate by optimizing request paths.
Budget OverrunMonthly AWS bill exceeds $50kRegular cost audits and using AWS cost management tools to alert on budget thresholds.

Editor's Verdict

This MLOps pipeline is deliberately straightforward, prioritizing proven tools like Ray Serve and Datadog to meet specific latency and observability requirements. At 10x scale, the architecture would need a more sophisticated cost management strategy and potentially alternative serving solutions to handle increased concurrency. The most common oversight teams make is underestimating the operational complexity of managing thousands of models, which this design addresses through automation and integrated observability.

Related MLOps coverage

One design a week

The next blueprint lands Tuesday.

Plus the week's AI/ML data engineering news, curated. Free.