Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 1 — AI Infrastructure PM là ai và tư duy nền tảng

AI Infrastructure PM là ai?

AI Infrastructure Product Manager (AI Infra PM) là người quản lý sản phẩm cho lớp hạ tầng phục vụ mô hình AI: hệ thống inference (suy luận), pipeline training, GPU cluster, serving gateway, và các công cụ giúp đội ngũ khác build ứng dụng AI nhanh, rẻ, ổn định. Bạn không trực tiếp huấn luyện mô hình, nhưng bạn quyết định mô hình chạy ở đâu, tốn bao nhiêu, nhanh cỡ nào, và có đáng tin không.

Hãy hình dung một ứng dụng chatbot của công ty. PM ứng dụng lo về trải nghiệm hội thoại. Còn bạn — AI Infra PM — lo về: một request tốn bao nhiêu đồng, độ trễ p99 là bao nhiêu mili-giây, khi 10.000 người dùng đổ vào lúc cao điểm thì hệ thống có sập không, và tháng này hóa đơn GPU vì sao tăng 40%.

Vì sao vai trò này bùng nổ

Mô hình lớn (LLM, diffusion, multimodal) đắt đỏ khi vận hành. Một GPU H100 thuê cloud có thể tốn 2–4 USD/giờ; một cluster nhỏ đã ngốn hàng chục nghìn USD/tháng. Chi phí inference thường vượt xa chi phí training theo thời gian, vì training làm một lần còn inference chạy 24/7. Ai kiểm soát được đường cong chi phí này chính là người tạo ra lợi thế cạnh tranh.

Bốn trục đánh đổi cốt lõi

Mọi quyết định của bạn xoay quanh việc cân bằng bốn trục, thường xung đột nhau:

  • Chi phí (Cost) — USD mỗi 1.000 token hoặc mỗi 1.000 request.
  • Throughput — số request/token xử lý được mỗi giây (thông lượng).
  • Độ trễ (Latency) — thời gian phản hồi, đo bằng p50/p95/p99 và TTFT (time to first token).
  • Chất lượng & Độ tin cậy — độ chính xác mô hình + uptime/SLO.
Bạn gần như không bao giờ tối ưu được cả bốn. Giảm chi phí bằng cách gom batch lớn → độ trễ tăng. Giảm độ trễ bằng cách chạy nhiều bản sao → chi phí tăng. Công việc của bạn là chọn điểm cân bằng phù hợp với use case.

Khung tư duy: bắt đầu từ workload, không phải từ công nghệ

Sai lầm phổ biến của người mới là mê công nghệ ("dùng quantization đi!") trước khi hiểu workload. Hãy dùng khung 4 câu hỏi này cho mọi dự án hạ tầng:

  • Ai dùng và cần gì? Chatbot thời gian thực (nhạy độ trễ) hay xử lý batch ban đêm (nhạy chi phí)?
  • Hình dạng tải ra sao? Ổn định, có đỉnh theo giờ, hay bùng nổ bất ngờ?
  • Ngân sách và ràng buộc? Giới hạn USD/tháng, yêu cầu on-prem vì bảo mật, hay ràng buộc năng lượng?
  • Định nghĩa "đủ tốt"? SLO nào là ranh giới thành/bại (ví dụ p95 < 800ms, uptime 99.9%)?

Ví dụ cụ thể

Công ty fintech có 2 workload. Workload A: gợi ý sản phẩm real-time trong app — nhạy độ trễ, cần p95 < 300ms. Workload B: chấm điểm rủi ro tín dụng hàng loạt lúc 2h sáng — không ai chờ, chỉ cần xong trước 6h sáng, ưu tiên chi phí thấp nhất.

Nếu bạn dùng cùng một cấu hình hạ tầng cho cả hai, bạn sẽ hoặc trả quá nhiều tiền cho B, hoặc làm A quá chậm. Đúng đắn: A dùng bản sao "nóng" luôn sẵn sàng + batch nhỏ; B dùng spot instance rẻ + batch cực lớn, chạy xong thì tắt.

Checklist khởi động một dự án AI Infra

  • [ ] Viết một dòng mô tả workload và người dùng cuối.
  • [ ] Xác định trục ưu tiên số 1 (chi phí / độ trễ / throughput / tin cậy).
  • [ ] Đặt 2–3 SLO đo được (con số cụ thể, có ngưỡng).
  • [ ] Ước tính tải đỉnh và tải trung bình.
  • [ ] Ghi rõ ràng buộc cứng (ngân sách, bảo mật, năng lượng).

Sai lầm thường gặp

  • Tối ưu khi chưa đo. Không có baseline thì không biết mình cải thiện được gì.
  • Coi mọi workload như nhau. Real-time và batch cần chiến lược hoàn toàn khác.
  • Bỏ qua chi phí inference dài hạn. Chỉ nhìn chi phí training là nhìn phần nổi của tảng băng.
  • Chạy theo hype công nghệ. Chọn giải pháp trước khi hiểu bài toán là công thức lãng phí ngân sách.
Bài tiếp theo, ta đi sâu vào trục chi phí quan trọng nhất: kinh tế học của GPU.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi