Model chạy tốt trong notebook không đồng nghĩa sẵn sàng cho production — cần xử lý thêm: độ trễ (latency) đủ nhanh cho use case thực tế, khả năng chịu tải nhiều request đồng thời, và cơ chế fallback khi model lỗi. Đây là chủ đề nhà tuyển dụng dùng để phân biệt kinh nghiệm thực chiến với kinh nghiệm học thuật.
"Model có độ trễ inference cao, làm sao tối ưu?" — Nhiều hướng tiếp cận: model quantization (giảm độ chính xác số học, vd. float32 xuống int8, giảm kích thước và tăng tốc độ với đánh đổi nhỏ về accuracy), batching request (gộp nhiều request xử lý cùng lúc để tận dụng GPU hiệu quả hơn), hoặc dùng model nhỏ hơn/distillation (model học lại từ model lớn nhưng nhẹ hơn nhiều).
"Làm sao xử lý khi traffic tăng đột biến vượt khả năng serving hiện tại?" — Horizontal scaling (thêm instance serving), request queue để xử lý tuần tự thay vì làm sập hệ thống, và circuit breaker để bảo vệ hệ thống downstream nếu model serving bị quá tải.
Ngoài so sánh business metric (conversion rate...), cần theo dõi thêm model-specific metric (độ chính xác thực tế trên dữ liệu mới, độ trễ inference) — và cần đủ traffic/thời gian để kết luận đáng tin cậy về sự khác biệt giữa model cũ và mới.
"Shadow deployment là gì?" — Chạy model mới song song với model cũ trên traffic thật, nhưng chỉ model cũ trả kết quả cho user — model mới chỉ ghi log để so sánh offline, không ảnh hưởng trải nghiệm thật. Đây là cách kiểm tra model mới an toàn trước khi chính thức chuyển traffic.
Nếu từng deploy model thật, kể rõ: latency yêu cầu là bao nhiêu (SLA), cách đo lường/giám sát sau khi deploy, và 1 lần gặp vấn đề performance ở production và cách giải quyết — con số cụ thể (giảm latency từ Xms xuống Yms) luôn thuyết phục hơn mô tả chung chung.