Serving Machine Learning Models Efficiently at Scale at Zillow

Zillow · 2022 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

• Nhiều tính năng của Zillow (Zestimate, gợi ý nhà, floor plan, semantic search) chạy bằng model ML. Đưa một model đã train lên làm web service cần nhiều logic nghiệp vụ quanh nó: tiền xử lý request, trích feature tức thời, làm giàu bằng feature đã tính sẵn, hậu xử lý, có khi gọi thêm model thứ hai tuỳ kết quả model đầu.
• Theo Zillow, việc này sinh ra "ba lực cản": người làm ML không muốn sa vào chi tiết web service nhưng vẫn phải theo sát để hành vi model không đổi ở production; engineer phải viết lại nhiều code và học hành vi model; team sản phẩm chịu tiến độ dài và rủi ro mỗi lần có model mới.
• Theo Zillow, các giải pháp mã nguồn mở và của vendor đều trừu tượng hoá việc dựng server bằng file cấu hình hay CLI, nhưng vẫn lộ khái niệm cấp thấp (ví dụ biến môi trường), hoặc ép đóng gói model theo định dạng riêng; load test của Zillow cho thấy p90/p95 của chúng kém vì đặc điểm riêng của ML serving.

Thay đổi chính

• Lớp người dùng: "service là một online flow". Cùng cú pháp Python của Metaflow (Zillow có bản riêng zillow-metaflow) dùng cho batch: lớp OnlineFlowSpec khai báo các bước bằng @step/self.next (có thể rẽ nhánh để xử lý song song); decorator ở mức class khai báo endpoint, tài nguyên, autoscaling; Parameter thay cho đọc biến môi trường; hàm load làm warmup (tải model, artifact); self.input/self.output chuyển thẳng sang Pandas DataFrame. Flow offline gọi online_publish để deploy flow online, và truyền con trỏ base_run tới artifact vừa train, nên model train định kỳ được deploy lại tự động. Code online và offline chung repo, chung container. Theo phản hồi người dùng, tiết kiệm ít nhất 60% thời gian làm việc hạ tầng.
• Lớp backend, dựa trên đặc điểm của ML serving mà Zillow liệt kê:
  • CPU-bound (có khi GPU) chứ không I/O-bound: mỗi replica chạy được ít worker, async I/O ít lợi, context switch và CPU throttling ảnh hưởng latency nặng hơn web service thường.
  • Tải mỗi request chênh nhau rất nhiều (có cái chỉ tra cứu, có cái chiếm hết CPU), nên autoscale theo CPU utilization dễ báo nhầm cả hai chiều.
  • Request nặng (gần mức timeout 1 phút) làm health/liveness probe tới replica đang bận bị timeout, replica bị giết oan; request khác bị dồn vào replica bận rồi chờ tới timeout.
  • Chi phí cao nên có lợi khi scale về 0 cho model có giờ thấp điểm rõ.
• Knative Serving + KServe trên Kubernetes/Istio: autoscaler trung tâm scale theo concurrency hay RPS và scale về 0; activator trung tâm giữ request thừa và chỉ gửi tới replica còn chỗ; sidecar queue-proxy cạnh mỗi model server làm proxy cho probe (cấu hình TCP probe thay HTTP để ứng dụng không bị ngắt) và làm thêm một lớp đệm; chia traffic và rollout dần. KServe thêm model server cơ sở, gom request (request batching), transformer tách riêng cho tiền/hậu xử lý.
• Kết quả, theo Zillow: so với các giải pháp vendor, p50 và latency đuôi tốt hơn 20–40%; cùng với các tối ưu tài nguyên khác, chi phí phục vụ cùng lượng traffic giảm 20–80%. Deploy qua GitLab CI/CD; Serving SDK nối sẵn vào Datadog, Splunk.

Vì sao

• Theo Zillow, kiến trúc web hiệu năng cao vốn tối ưu cho I/O-bound; với workload CPU-bound, cân bằng tải hoàn hảo là bất khả, nên cần một lớp ở giữa giữ request thừa thay vì đẩy vào hàng đợi của replica đang bận.

Bài học cho SWE

• Chọn tín hiệu autoscale theo bản chất tải: request chênh nhau nhiều thì CPU là tín hiệu nhiễu, concurrency đang bay là tín hiệu gần đúng hơn.
• Probe đi chung đường với request nặng sẽ nói dối: tách đường probe (proxy, TCP probe) để replica bận không bị giết.
• Đệm request ở một lớp biết replica nào còn chỗ, thay vì để hàng đợi dồn trong từng replica.
• Trừu tượng cho người dùng nên mượn mô hình họ đã quen (flow batch), không bắt học khái niệm web service.

Liên quan

• Nền tảng ML (feature, training, serving, giám sát model) · Load shedding, rate limit và backpressure
• Cùng công ty: Zillow 2016 · Zillow 2018
• Cùng bài toán: Reddit 2021 · Together AI 2026 (scale theo in-flight cho LLM, cùng kết luận về tín hiệu utilization)