Menu
ESC

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

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

Đang tải...

Bài 5 — Build vs Buy và hiệu quả năng lượng

AI Infrastructure Product Manager: Hạ tầng AI Bài 5/6

Quyết định lớn nhất: tự làm hay đi mua

Câu hỏi build-vs-buy quyết định phần lớn cấu trúc chi phí và tốc độ của bạn. Ba lựa chọn phổ biến:

  • Buy (API bên thứ ba) — gọi API mô hình có sẵn (OpenAI, Anthropic, v.v.). Nhanh ra mắt, không lo hạ tầng, trả theo lượng dùng.
  • Rent (self-host trên cloud) — thuê GPU, tự chạy mô hình mở. Kiểm soát nhiều hơn, chi phí biên rẻ hơn ở quy mô lớn.
  • Build (on-prem/tự sở hữu GPU) — mua phần cứng. Rẻ nhất/đơn vị ở quy mô rất lớn và ổn định, nhưng vốn đầu tư và vận hành nặng.

Khung quyết định build-vs-buy

Đánh giá theo các trục:

  • Quy mô & độ ổn định tải. Tải nhỏ/thất thường → Buy. Tải lớn/ổn định → Rent hoặc Build.
  • Điểm hòa vốn (break-even). API rẻ khi lượng thấp; tới một ngưỡng volume, self-host rẻ hơn hẳn. Hãy tính điểm giao nhau.
  • Tốc độ ra thị trường. Cần ship tuần này → Buy. Có thời gian → Rent/Build.
  • Kiểm soát & tùy biến. Cần fine-tune sâu, kiểm soát dữ liệu, độ trễ ổn định → nghiêng self-host.
  • Bảo mật & tuân thủ. Dữ liệu nhạy cảm không được rời hạ tầng → on-prem/private.
  • Năng lực đội ngũ. Không có kỹ sư MLOps → Buy để tránh gánh nặng vận hành.
Mẫu hình phổ biến: bắt đầu bằng Buy để xác thực nhu cầu và học workload, rồi chuyển sang Rent/Build khi volume đủ lớn để tiết kiệm vượt chi phí kỹ thuật. Đừng build sớm khi chưa biết chắc có người dùng.

Ví dụ điểm hòa vốn

Giả sử API tính 0,60 USD/1K request. Self-host cần một GPU 3 USD/giờ (~2.160 USD/tháng) nhưng xử lý được 5 triệu request/tháng. Chi phí self-host ≈ 0,00043 USD/request — rẻ hơn API tới hơn 1.000 lần ở mức tải cao. Nhưng nếu bạn chỉ có 50.000 request/tháng, GPU vẫn tốn 2.160 USD trong khi API chỉ 30 USD. Bài học: break-even phụ thuộc hoàn toàn vào volume.

Hiệu quả năng lượng: trục ngày càng quan trọng

GPU ngốn điện. Điện là chi phí thật (và với on-prem còn là giới hạn vật lý về công suất/tản nhiệt). Ngoài tiền, nhiều tổ chức có cam kết phát thải carbon, biến hiệu quả năng lượng thành yêu cầu sản phẩm chứ không chỉ kỹ thuật.

Chỉ số PM nên biết:

  • Tokens/joule hoặc inferences/watt — bao nhiêu công việc trên mỗi đơn vị năng lượng.
  • PUE (Power Usage Effectiveness) — hiệu quả năng lượng của data center (càng gần 1 càng tốt).
  • Carbon-aware scheduling — dời workload không gấp (batch) sang khung giờ/vùng có điện sạch, rẻ hơn.
Tin vui: các đòn bẩy tối ưu chi phí ở Bài 2–3 thường đồng thời cải thiện năng lượng. Quantization, batching, tăng GPU utilization đều làm nhiều việc hơn trên mỗi watt. Hiệu quả chi phí và hiệu quả năng lượng phần lớn cùng chiều.

Khung tư duy tổng hợp

Khi trình bày quyết định hạ tầng, luôn gói trong ba câu: (1) đây là điểm hòa vốn theo volume; (2) đây là đánh đổi độ trễ/kiểm soát/bảo mật; (3) đây là tác động chi phí và năng lượng. Ba câu này thuyết phục được cả CFO lẫn CTO.

Checklist build-vs-buy

  • [ ] Ước tính volume hiện tại và dự phóng 12 tháng.
  • [ ] Tính điểm hòa vốn giữa API và self-host.
  • [ ] Đánh giá năng lực MLOps của đội.
  • [ ] Kiểm tra ràng buộc bảo mật/tuân thủ dữ liệu.
  • [ ] Đưa chi phí năng lượng (và carbon nếu có) vào bài toán.
  • [ ] Mặc định: Buy để học, chuyển self-host khi break-even rõ ràng.

Sai lầm thường gặp

  • Build quá sớm. Đầu tư hạ tầng khi chưa xác thực nhu cầu → chôn vốn.
  • Buy mãi ở quy mô lớn. Bỏ lỡ khoản tiết kiệm khổng lồ sau điểm hòa vốn.
  • Quên chi phí ẩn của self-host. Vận hành, on-call, cold start, khấu hao — không chỉ giá GPU.
  • Bỏ qua năng lượng. Vừa mất tiền điện vừa vi phạm cam kết carbon.