LyftLearn: ML Model Training Infrastructure built on Kubernetes
Bài tóm tắt Lyft 2021 3. Quy mô lớn Độ khó: Trung bình
Lyft · 2021 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc
Bài thứ hai của một cặp; bài trước về Feature Service: Lyft 2021.
Bối cảnh
- Mỗi team ở Lyft (dispatch, định giá, chống gian lận, hỗ trợ) dùng kỹ thuật mô hình riêng, nhưng đều cần cùng các việc: môi trường phát triển, train song song, theo dõi các lần chạy, xem hiệu năng, train lại theo lịch, deploy model đã train. LyftLearn là nền tảng chung cho training và batch prediction.
Thay đổi chính
- Nguyên tắc thiết kế, theo Lyft: lặp nhanh là thứ phân biệt phát triển ML với phần mềm thường; không giới hạn thư viện và phiên bản (sklearn, LightGBM, XGBoost, PyTorch, TensorFlow, mỗi team một phiên bản), trừ ngoại lệ vì bảo mật; nhiều lớp truy cập (API ở dưới, CLI và GUI xây trên API); chi phí của mỗi lần train phải thấy được để người dùng tự cân với lợi ích kỳ vọng; tự phục vụ kể cả distributed training và hyperparameter tuning.
- Phát triển: chọn cấu hình phần cứng (GPU/CPU, RAM) và base image rồi mở notebook Jupyter hoặc R-studio trên cụm Kubernetes riêng của LyftLearn, lên trong vài giây; notebook không dùng vài giờ thì tự lưu và tự tắt để đỡ tiền, vì mở lại nhanh nên không phiền người dùng. Save Model đóng code và dependency thêm vào lớp trên base image thành một container model, gắn version (có thể là SHA commit). Làm ở máy cá nhân thì dùng CLI.
- Training và batch prediction: container model nhận hyperparameter và tham số cấu hình, chạy song song nhiều bộ, ví dụ train một model cho mỗi vùng địa lý bằng cách truyền vùng làm tham số. Job chạy dạng Kubernetes job, lên lịch để train lại định kỳ; song song hoá qua Flyte, Spark hoặc Fugue. Model cần dự đoán điểm (định giá mỗi chuyến) đi sang hệ phục vụ riêng; model chạy theo lô (incentive hằng tuần) thì LyftLearn tự lên lịch.
- Image Build là lớp bọc docker build; team thường tự tạo base image cho mọi model của mình. Dữ liệu train từ warehouse (Hive, Presto, Spark); metadata model ở RDS Aurora; image ở ECR; dữ liệu tạm trên EFS gắn làm volume cho mỗi người.
- Lúc viết: hàng chục team, hàng trăm model được dựng mỗi tuần.
Vì sao
- Theo Lyft, chọn Kubernetes vì container cho mỗi team dùng thư viện và phiên bản riêng mà vẫn chung một nền, và vì môi trường mới lên trong vài giây nên lặp nhanh được.
Bài học cho SWE
- Container hoá cả môi trường (code + dependency) là cách nền tảng chung không phải chọn một phiên bản thư viện cho mọi team.
- Khởi động nhanh làm chính sách tiết kiệm (tự tắt khi không dùng) trở nên chấp nhận được với người dùng.
- Cho người dùng thấy chi phí của từng lần chạy thì quyết định "có đáng không" nằm ở đúng người.
Liên quan
- Nền tảng ML (feature, training, serving, giám sát model) · Chi phí hạ tầng và build vs buy
- Cùng công ty: Lyft 2021 · Lyft 2019
- Cùng bài toán: Yelp 2026 · Spotify 2022
#LyftLearn#ML training#Kubernetes#notebook#base image#model container#batch prediction#Flyte#Spark#Fugue#cost visibility#EFS#ECR
Được nhắc tới trong
Công ty (1)
Bài tóm tắt (4)