Mở đầu — vì sao bài này quan trọng
Khi đội ngũ của bạn quyết định đưa AI vào sản phẩm, câu hỏi đầu tiên — và cũng là câu hỏi tốn tiền nhất — không phải là "model nào thông minh nhất", mà là "chúng ta nên mua hay tự xây?". Đây là một trong những quyết định kiến trúc có sức nặng lớn nhất mà một AI Product Manager phải tham gia, bởi vì nó quyết định cấu trúc chi phí, tốc độ ra thị trường, khả năng kiểm soát, và cả lợi thế cạnh tranh dài hạn của sản phẩm.
Điều khiến nhiều PM mắc kẹt là họ nghĩ đây là một lựa chọn nhị phân: hoặc gọi API của OpenAI/Anthropic, hoặc tự huấn luyện một model từ đầu. Thực tế, giữa hai cực đó là cả một phổ lựa chọn (spectrum) với nhiều nấc trung gian, mỗi nấc có một sự đánh đổi riêng. Một quyết định sai ở đây không giết chết sản phẩm ngay, nhưng nó âm thầm bào mòn: đội ngũ tốn sáu tháng tự huấn luyện một model mà API thương mại làm tốt hơn với một phần mười chi phí, hoặc ngược lại, doanh nghiệp bị khoá chặt vào một nhà cung cấp và trả hóa đơn token gấp năm lần khi quy mô tăng lên.
Trong bài này, chúng ta sẽ đi qua toàn bộ phổ lựa chọn từ "Buy" thuần tuý đến "Build" thuần tuý, các tiêu chí ra quyết định mà một PM cần cầm trong tay, và một quy trình từng bước để bạn không phải quyết định bằng cảm tính. Lưu ý: bài này tập trung vào trục build-vs-buy ở tầng model. Việc chọn model cụ thể nào, định tuyến giữa các model, hay khi nào fine-tune sẽ được đào sâu ở các bài sau — ở đây ta nhìn bức tranh chiến lược tổng thể.
Khái niệm cốt lõi
Phổ lựa chọn — không phải nhị phân
Hãy hình dung một thanh trượt từ trái (Buy hoàn toàn) sang phải (Build hoàn toàn). Có bốn nấc chính:
Nấc 1 — Use API (Buy thuần tuý). Bạn gọi API của các nhà cung cấp foundation model: OpenAI, Anthropic, Google (Gemini), hay các nhà cung cấp khu vực. Bạn không sở hữu model, không vận hành hạ tầng GPU, không lo việc model được huấn luyện ra sao. Bạn trả tiền theo lượng token tiêu thụ (input + output). Ưu điểm lớn nhất: zero infrastructure, instant scale — bạn có thể đưa tính năng AI ra thị trường trong vài ngày, và khả năng mở rộng gần như vô hạn vì gánh nặng hạ tầng nằm ở phía nhà cung cấp. Nhược điểm: chi phí biến đổi theo từng request, phụ thuộc nhà cung cấp, và dữ liệu của bạn đi ra ngoài hệ thống của họ (dù hầu hết đều có cam kết không dùng dữ liệu API để huấn luyện).
Nấc 2 — API + tuỳ biến nhẹ. Vẫn dùng API, nhưng bạn thêm các lớp tuỳ biến của riêng mình: prompt engineering có hệ thống, RAG để bơm tri thức nội bộ, function calling để kết nối công cụ. Model lõi vẫn là của nhà cung cấp, nhưng "bộ não ứng dụng" quanh nó là của bạn. Đây là nơi 80% sản phẩm AI thực tế đang đứng, vì nó cân bằng tốt giữa tốc độ và khả năng kiểm soát.
Nấc 3 — Self-host open model (Build một phần). Bạn lấy một model mã nguồn mở (Llama, Mistral, Qwen, hoặc các model Việt như PhoGPT, Vistral) và tự vận hành trên hạ tầng của mình — cloud GPU thuê hoặc server riêng. Bạn không huấn luyện model từ đầu, nhưng bạn sở hữu toàn bộ chuỗi suy luận (inference): dữ liệu không rời khỏi hệ thống, chi phí chuyển từ "theo token" sang "theo giờ GPU", và bạn kiểm soát hoàn toàn phiên bản model. Có thể kèm fine-tuning để model hợp với miền dữ liệu của mình.
Nấc 4 — Train from scratch (Build thuần tuý). Bạn huấn luyện một foundation model từ con số không, hoặc pre-train trên dữ liệu chuyên ngành rất lớn. Đây là lựa chọn cực kỳ tốn kém — hàng triệu đến hàng chục triệu USD, đội ngũ research chuyên sâu, và nhiều tháng tính toán. Trên thực tế, chỉ một số rất ít tổ chức (các phòng lab AI, một vài tập đoàn công nghệ lớn) đi tới nấc này. Với 99% sản phẩm thương mại, đây là lựa chọn sai.
Các trục đánh đổi mà PM phải cân
Mỗi nấc trên phổ được đánh giá qua năm trục:
- Chi phí: API là chi phí biến đổi (OPEX, scale tuyến tính theo lượng dùng), self-host là chi phí cố định cao trả trước nhưng đơn vị rẻ dần khi quy mô lớn.
- Tốc độ ra thị trường (time-to-market): Buy nhanh nhất (vài ngày), Build chậm nhất (vài tháng đến vài năm).
- Kiểm soát & tuỳ biến: càng về phía Build càng kiểm soát sâu hành vi model.
- Quyền riêng tư & tuân thủ dữ liệu: với dữ liệu nhạy cảm (y tế, tài chính, dữ liệu cá nhân theo Nghị định 13/2023 về bảo vệ dữ liệu cá nhân ở Việt Nam), self-host thường là lựa chọn an toàn hơn.
- Lệ thuộc nhà cung cấp (vendor lock-in): Buy đặt bạn vào tay một bên thứ ba — về giá, về tính khả dụng, về lộ trình.
Tình huống thực tế
Ví dụ 1 — Startup fintech tại TP.HCM: bắt đầu bằng Buy là đúng
Một startup fintech giả định tên PayNhanh xây trợ lý ảo hỗ trợ khách hàng trong app ví điện tử. Giai đoạn đầu họ có khoảng 5.000 lượt hỏi mỗi ngày. Đội kỹ thuật ban đầu hào hứng muốn self-host một model Llama để "làm chủ công nghệ".
Hãy tính nhanh như một PM. Mỗi cuộc hội thoại tiêu khoảng 2.000 token, chi phí qua một API tầm trung rơi vào khoảng 0,003 USD/cuộc. 5.000 cuộc/ngày × 30 ngày ≈ 150.000 cuộc/tháng × 0,003 = 450 USD/tháng. Trong khi đó, để self-host một model 13 tỷ tham số chạy ổn định 24/7, họ cần ít nhất một GPU A100 thuê cloud (~1.500–2.500 USD/tháng) cộng lương một kỹ sư MLOps. Tổng chi phí self-host vượt 4.000 USD/tháng mà chất lượng chưa chắc bằng API thương mại.
Bài học: ở quy mô nhỏ và giai đoạn cần tìm product-market fit, Buy gần như luôn thắng. Tốc độ và chi phí thấp quan trọng hơn việc "làm chủ". PayNhanh chọn API, ra mắt trong ba tuần, và dành nguồn lực kỹ thuật cho việc cải thiện trải nghiệm chứ không phải vận hành GPU.
Ví dụ 2 — Sàn TMĐT khu vực: điểm giao xuất hiện khi scale
Lấy một sàn thương mại điện tử quy mô Đông Nam Á (giả định, kiểu Tiki/Shopee). Họ dùng AI để tự động tóm tắt và phân loại hàng triệu đánh giá sản phẩm mỗi ngày — một tác vụ khối lượng lớn nhưng đơn giản, không cần model thông minh nhất thế giới.
Khi khối lượng đạt 20 triệu request/tháng, hóa đơn API phình lên hàng chục nghìn USD/tháng. Đội ngũ tính lại: với một model open-source 7-8 tỷ tham số đã fine-tune cho riêng tác vụ phân loại, chạy trên một cụm GPU thuê, chi phí cố định khoảng 8.000-10.000 USD/tháng nhưng không tăng theo lượng request. Điểm giao đã bị vượt qua từ lâu. Họ chuyển tác vụ khối lượng lớn này sang self-host, đồng thời vẫn giữ API cho các tác vụ phức tạp, ít gặp (như trả lời câu hỏi mở của khách).
Bài học: quyết định build-vs-buy không nhất thiết áp dụng cho toàn bộ sản phẩm. Bạn có thể chia theo từng tác vụ: tác vụ khối lượng lớn, ổn định, đơn giản thì self-host để cắt chi phí; tác vụ phức tạp, đa dạng thì giữ API. Đây gọi là kiến trúc lai (hybrid).
Ví dụ 3 — Bệnh viện và dữ liệu nhạy cảm: privacy ép buộc Build
Một hệ thống bệnh viện ở Hà Nội muốn dùng LLM để hỗ trợ bác sĩ tóm tắt bệnh án. Khối lượng thực ra không lớn, và xét thuần về chi phí thì API rẻ hơn. Nhưng dữ liệu bệnh án là dữ liệu cá nhân nhạy cảm — đưa ra API nước ngoài là rủi ro tuân thủ pháp lý và đạo đức nghiêm trọng.
Ở đây, trục chi phí không phải là trục quyết định — trục quyết định là quyền riêng tư và tuân thủ. Họ buộc phải self-host một open model trên hạ tầng nội bộ, chấp nhận chi phí cao hơn và tốc độ triển khai chậm hơn, đổi lấy việc dữ liệu không bao giờ rời khỏi mạng nội bộ bệnh viện.
Bài học: đừng để một mình con số chi phí dẫn dắt. Với một số ngành (y tế, ngân hàng, quốc phòng, khu vực công), yêu cầu pháp lý và quyền riêng tư có thể ghi đè hoàn toàn lập luận kinh tế, đẩy bạn về phía Build dù quy mô nhỏ.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn áp dụng khi đứng trước quyết định build-vs-buy:
Bước 1 — Phân rã sản phẩm thành các tác vụ AI riêng lẻ. Đừng hỏi "build hay buy cho cả sản phẩm". Hãy liệt kê từng tác vụ AI: chatbot hỗ trợ, phân loại nội dung, tóm tắt, sinh ảnh... Mỗi tác vụ sẽ có câu trả lời khác nhau.
Bước 2 — Với mỗi tác vụ, ước lượng khối lượng và độ phức tạp. Bao nhiêu request/tháng? Mỗi request bao nhiêu token? Tác vụ cần trí thông minh tổng quát (cần model mạnh nhất) hay chỉ là việc lặp đi lặp lại đơn giản? Tác vụ đơn giản + khối lượng lớn là ứng viên số một cho self-host.
Bước 3 — Tính chi phí của cả hai phương án ở quy mô hiện tại VÀ quy mô dự phóng 12 tháng tới. Với API: token/request × số request × đơn giá. Với self-host: chi phí GPU + lương vận hành + chi phí ban đầu để fine-tune. Vẽ hai đường chi phí theo khối lượng và tìm điểm giao.
Bước 4 — Kiểm tra các ràng buộc cứng. Có yêu cầu pháp lý/quyền riêng tư buộc dữ liệu phải ở nội bộ không? Có yêu cầu độ trễ (latency) thấp đến mức API không đáp ứng được không? Có yêu cầu hoạt động offline/on-device không? Nếu có, các ràng buộc này có thể loại bỏ một phương án ngay lập tức.
Bước 5 — Đánh giá năng lực đội ngũ một cách trung thực. Self-host và fine-tune đòi hỏi kỹ năng MLOps, vận hành GPU, giám sát model. Nếu đội bạn chưa có năng lực này, chi phí thực của Build cao hơn nhiều so với con số trên bảng tính, vì bạn phải tuyển người và chấp nhận rủi ro vận hành.
Bước 6 — Mặc định bắt đầu bằng Buy, thiết kế để dễ chuyển đổi. Trừ khi ràng buộc cứng ép bạn Build ngay, hãy khởi đầu bằng API để xác thực nhu cầu thị trường nhanh. Nhưng thiết kế kiến trúc với một lớp trừu tượng (abstraction layer) giữa ứng dụng và model, để sau này chuyển sang self-host mà không phải viết lại toàn bộ.
Bước 7 — Đặt lịch xem xét lại theo cột mốc khối lượng. Quyết định hôm nay không vĩnh viễn. Đặt một ngưỡng (ví dụ: khi hóa đơn API vượt 5.000 USD/tháng) làm tín hiệu để đánh giá lại việc chuyển sang self-host.
Lỗi thường gặp & mẹo
Lỗi 1 — Tự huấn luyện model từ đầu vì "muốn làm chủ công nghệ". Đây là cái bẫy của nhiều đội kỹ thuật có tham vọng. Train from scratch tốn hàng triệu USD và gần như không bao giờ tạo ra model tốt hơn foundation model thương mại cho mục đích chung. "Làm chủ" thực sự nằm ở dữ liệu và lớp ứng dụng của bạn, không phải ở việc tự pre-train.
Lỗi 2 — Chỉ tính chi phí token mà quên chi phí ẩn của self-host. Khi so sánh, nhiều người chỉ thấy "GPU rẻ hơn token". Họ quên lương kỹ sư MLOps, chi phí giám sát, downtime, chi phí cập nhật khi có model mới ra. Tổng chi phí sở hữu (TCO) của self-host luôn cao hơn con số GPU đơn thuần.
Lỗi 3 — Bỏ qua vendor lock-in cho đến khi quá muộn. Nếu bạn viết code gắn chặt vào API của một nhà cung cấp duy nhất, khi họ tăng giá hoặc ngừng model bạn đang dùng, bạn mắc kẹt. Mẹo: luôn chèn một lớp trừu tượng để có thể đổi nhà cung cấp hoặc chuyển sang self-host với chi phí thấp nhất.
Lỗi 4 — Quyết định một lần cho cả vòng đời sản phẩm. Build-vs-buy là quyết định động. Câu trả lời đúng ở giai đoạn 5.000 request/ngày khác hẳn ở 5 triệu request/ngày. Hãy gắn quyết định với cột mốc khối lượng.
Mẹo vàng: với phần lớn sản phẩm, lộ trình tối ưu là Buy trước để học, Build sau để tối ưu. Dùng API để tìm ra đúng nhu cầu và đúng hành vi model, rồi mới đầu tư self-host cho những tác vụ đã chứng minh được khối lượng và giá trị.
Bài tập thực hành
- Bài tập tính điểm giao: Giả sử tác vụ của bạn tiêu 1.500 token/request, đơn giá API là 0,002 USD/request. Self-host tốn 7.000 USD/tháng cố định. Hãy tính: ở mức bao nhiêu request/tháng thì self-host bắt đầu rẻ hơn API? (Gợi ý: giải phương trình 0,002 × N = 7.000.)
- Bài tập phân rã: Chọn một sản phẩm AI bạn biết (hoặc đang xây). Liệt kê tất cả các tác vụ AI trong đó. Với mỗi tác vụ, đề xuất nấc nào trên phổ (Use API / API + RAG / self-host / train from scratch) là phù hợp nhất, kèm một câu lý do.
- Bài tập ràng buộc cứng: Hình dung một sản phẩm AI cho lĩnh vực ngân hàng tại Việt Nam. Liệt kê ít nhất ba ràng buộc (pháp lý, quyền riêng tư, độ trễ) có thể ảnh hưởng đến quyết định build-vs-buy, và giải thích mỗi ràng buộc đẩy quyết định về phía nào.
- Bài tập phản biện: Một đồng nghiệp đề xuất tự train một LLM từ đầu cho công ty 50 người của bạn. Viết một đoạn ngắn (5-7 câu) phản biện hoặc ủng hộ, dựa trên các trục đánh đổi đã học.
Tóm tắt
Build-vs-buy không phải lựa chọn nhị phân mà là một phổ với bốn nấc: dùng API (Buy), API kèm tuỳ biến, self-host open model (Build một phần), và train from scratch (Build thuần tuý). Mỗi nấc đánh đổi giữa năm trục: chi phí, tốc độ ra thị trường, kiểm soát, quyền riêng tư, và lệ thuộc nhà cung cấp.
Nguyên tắc cốt lõi: API là chi phí biến đổi rẻ ở quy mô nhỏ nhưng có một điểm giao mà tại đó self-host trở nên rẻ hơn — nhiệm vụ của PM là ước lượng điểm giao này trước khi mở rộng. Quyết định nên được đưa ra ở cấp từng tác vụ, không phải cả sản phẩm, và phải được xem xét lại theo cột mốc khối lượng. Với 99% sản phẩm, hãy mặc định bắt đầu bằng Buy để học nhanh và tìm product-market fit, thiết kế kiến trúc có lớp trừu tượng để dễ chuyển đổi, rồi mới Build cho những tác vụ đã chứng minh được khối lượng — trừ khi ràng buộc pháp lý hoặc quyền riêng tư buộc bạn Build ngay từ đầu.