Mở đầu — vì sao bài này quan trọng
Có một câu hỏi mà bất kỳ đội ngũ nào xây dựng sản phẩm AI cũng phải trả lời, thường là trong tuần đầu tiên: "Chúng ta tự làm cái này, hay dùng dịch vụ có sẵn?" Nghe thì đơn giản, nhưng đây chính là quyết định định hình toàn bộ tốc độ, chi phí, và khả năng cạnh tranh của sản phẩm bạn trong nhiều năm sau đó.
Tôi đã chứng kiến nhiều đội ở Việt Nam mắc kẹt vì trả lời sai câu hỏi này theo cả hai hướng. Có đội dành sáu tháng tự huấn luyện một model phân loại văn bản tiếng Việt, để rồi nhận ra một prompt gọi API GPT-4 làm tốt hơn với chi phí bằng một phần mười. Ngược lại, có đội xây toàn bộ lõi sản phẩm trên một API bên ngoài, rồi hoảng loạn khi nhà cung cấp tăng giá gấp ba hoặc thay đổi điều khoản sử dụng chỉ sau một email thông báo.
Build vs Buy không phải là quyết định "một lần rồi thôi". Nó là một khung tư duy bạn phải áp dụng lặp đi lặp lại cho từng thành phần của sản phẩm: model ngôn ngữ, vector database, hệ thống eval, giao diện chat, hạ tầng monitoring. Mỗi mảnh đều có một điểm cân bằng riêng giữa quyền kiểm soát và tốc độ. Bài học này cho bạn công cụ để đưa ra quyết định đó một cách có kỷ luật, thay vì theo cảm tính hay theo trào lưu kỹ thuật.
Khái niệm cốt lõi
Phổ quyết định (decision spectrum)
Đừng nghĩ Build vs Buy là công tắc bật/tắt hai trạng thái. Trên thực tế nó là một dải liên tục (spectrum), và với AI dải này rõ ràng hơn bất kỳ lĩnh vực phần mềm nào khác:
Mua giải pháp trọn gói → Cấu hình SaaS → Xây trên API → Tự host model → Huấn luyện từ đầu
(Buy off-shelf) (Configure SaaS) (Build on API) (Self-host) (Train from scratch)Càng sang phải: kiểm soát nhiều hơn, chi phí kỹ thuật cao hơn, thời gian ra thị trường chậm hơn.
Càng sang trái: nhanh hơn, rẻ hơn ban đầu, nhưng phụ thuộc và ít khác biệt hóa hơn.
Cùng điểm qua từng nấc:
- Mua trọn gói (Buy off-shelf): Bạn mua một sản phẩm hoàn chỉnh, ví dụ dùng luôn Intercom Fin làm chatbot chăm sóc khách hàng, hay Notion AI để tóm tắt tài liệu. Không cần code, triển khai trong vài giờ.
- Cấu hình SaaS (Configure SaaS): Bạn dùng một nền tảng cho phép tùy chỉnh sâu hơn nhưng vẫn không tự viết lõi AI — ví dụ dựng bot trên Voiceflow hay Dify, kéo thả luồng hội thoại và cắm knowledge base của mình.
- Xây trên API (Build on API): Đây là điểm ngọt của đa số sản phẩm AI năm 2026. Bạn viết code gọi API của OpenAI, Anthropic, Google, hoặc VinAI/FPT.AI, tự kiểm soát prompt, orchestration, dữ liệu và trải nghiệm, nhưng "bộ não" model do nhà cung cấp vận hành.
- Tự host model (Self-host): Bạn tải model mã nguồn mở (Llama, Qwen, Mistral) về và tự vận hành trên GPU của mình hoặc thuê. Kiểm soát tối đa về dữ liệu, độ trễ, chi phí biên, nhưng gánh toàn bộ gánh nặng vận hành (bài 39 đi sâu về khi nào self-host hợp lý).
- Huấn luyện từ đầu (Train from scratch): Tự xây model nền. Với 99% công ty, đây là lựa chọn sai — chi phí hàng triệu đô và đòi hỏi đội ngũ nghiên cứu. Chỉ có nghĩa với những tổ chức mà model chính là sản phẩm.
Ba câu hỏi quyết định
Để định vị mỗi thành phần trên phổ này, hãy hỏi ba câu:
1. Đây có phải là lợi thế cạnh tranh cốt lõi (core differentiator) của bạn không? Nếu thành phần này là thứ khiến khách hàng chọn bạn thay vì đối thủ, hãy nghiêng về "build". Nếu nó chỉ là hạ tầng ai cũng cần (như xác thực người dùng, gửi email), hãy "buy". Không ai thắng thị trường nhờ tự viết lại hệ thống gửi email.
2. Tổng chi phí sở hữu (TCO) thực sự là bao nhiêu? Đây là chỗ đa số tính sai. Chi phí "build" không chỉ là lương lập trình viên trong giai đoạn xây dựng, mà còn là chi phí bảo trì, vá lỗi, trực đêm, cập nhật model, và chi phí cơ hội của những tính năng bạn KHÔNG làm được vì đang bận tự xây hạ tầng.
3. Bạn có thể đảo ngược quyết định này dễ đến mức nào? Đây là câu hỏi bị bỏ qua nhiều nhất nhưng lại quan trọng nhất với AI. Nếu bạn "buy" hôm nay và muốn chuyển sang "build" sau, chi phí chuyển đổi (switching cost) là bao nhiêu? Kiến trúc tốt luôn giữ cho các quyết định có thể đảo ngược được — ta sẽ nói kỹ ở phần hướng dẫn.
Đặc thù của AI làm phép tính khác đi
Với phần mềm truyền thống, "build vs buy" khá tĩnh. Nhưng AI có hai đặc thù làm cân bằng nghiêng mạnh về phía "buy trên API", ít nhất trong giai đoạn đầu:
Thứ nhất, model nền tiến hóa cực nhanh. Nếu bạn tự host một model vào tháng 1, đến tháng 6 có thể đã có model mới mạnh gấp đôi, rẻ một nửa. Đội "build on API" chỉ cần đổi một dòng cấu hình để nâng cấp; đội "self-host" phải làm lại toàn bộ quy trình triển khai.
Thứ hai, chi phí API đang giảm theo thời gian. Giá token của các model nền đã giảm hàng chục lần trong hai năm. Nghĩa là lý do "tự host để tiết kiệm chi phí" ngày càng yếu đi, trừ khi bạn ở quy mô rất lớn.
Tình huống thực tế
Ví dụ 1: Startup EdTech ở TP.HCM — chấm điểm bài luận tiếng Việt
Một startup luyện thi IELTS tại TP.HCM muốn xây tính năng tự động chấm và góp ý bài luận tiếng Anh của học viên. Đội kỹ thuật (4 người) tranh luận: tự fine-tune một model chấm điểm, hay gọi API?
Người CTO ban đầu muốn "build" — anh lập luận rằng chấm bài chính xác là lợi thế cốt lõi, và dữ liệu bài luận của học viên là tài sản riêng. Kế hoạch: thu thập 20.000 bài đã chấm bởi giáo viên, fine-tune một model. Ước tính 4 tháng và khoảng 300 triệu đồng cho nhân sự và GPU.
Trước khi cam kết, đội làm một thử nghiệm nhỏ trong hai ngày: viết prompt chi tiết mô tả rubric IELTS, gọi API Claude, chấm thử 200 bài. Kết quả: mức độ đồng thuận với giáo viên đạt khoảng 88%, gần bằng mức đồng thuận giữa hai giáo viên với nhau (91%). Chi phí mỗi bài chấm khoảng 900 đồng.
Bài học: Đội quyết định "build on API" thay vì fine-tune. Họ nhận ra phần khác biệt hóa của mình KHÔNG nằm ở model, mà ở chất lượng rubric, ở trải nghiệm phản hồi trực quan, và ở lộ trình học cá nhân hóa. Model chỉ là công cụ. Họ dồn 4 tháng đó vào việc xây trải nghiệm học viên, và ra mắt sớm hơn dự kiến ba tháng. Dữ liệu bài luận vẫn được lưu lại — để sau này, khi có quy mô, họ có thể cân nhắc fine-tune (bài 8 và 28 nói về data flywheel này).
Ví dụ 2: Ngân hàng số — vì sao "buy" API thuần lại bất khả thi
Một ngân hàng số tại Việt Nam muốn xây trợ lý AI trả lời câu hỏi về sản phẩm tín dụng. Về mặt kỹ thuật, gọi thẳng API GPT-4 là nhanh nhất. Nhưng bộ phận pháp chế chặn lại: dữ liệu khách hàng và giao dịch không được rời khỏi hạ tầng do ngân hàng kiểm soát, theo Nghị định 13 về bảo vệ dữ liệu cá nhân (bài 31 đi sâu về tuân thủ).
Ở đây, câu hỏi "build vs buy" bị chi phối bởi ràng buộc pháp lý, không phải kỹ thuật thuần túy. Đội chọn phương án lai (hybrid): tầng RAG và điều phối (orchestration) tự build và chạy trên hạ tầng nội bộ, còn phần suy luận dùng model mã nguồn mở (một biến thể Llama tiếng Việt) self-host trong data center của ngân hàng. Đắt hơn và chậm triển khai hơn nhiều so với gọi API công cộng — mất khoảng 7 tháng — nhưng đó là cái giá bắt buộc.
Bài học: Với một số ngành (tài chính, y tế, khu vực công), ràng buộc dữ liệu và tuân thủ đẩy bạn về phía "self-host" bất kể phép tính chi phí thuần túy nói gì. Hãy đưa pháp chế vào bàn quyết định TỪ ĐẦU, không phải sau khi đã xây xong prototype trên API công cộng.
Ví dụ 3: Đội SaaS B2B — mua vector database thay vì tự dựng
Một công ty SaaS ở Singapore làm công cụ tìm kiếm nội bộ cho doanh nghiệp cần một vector database để lưu embeddings. Một kỹ sư đề xuất tự dựng: chạy pgvector trên PostgreSQL sẵn có, "chỉ vài dòng SQL thôi mà". Một người khác muốn mua Pinecone (dịch vụ vector DB có sẵn).
Họ phân tích theo ba câu hỏi. Vector search có phải lợi thế cốt lõi không? Không — khách hàng trả tiền cho chất lượng kết quả tìm kiếm và tích hợp, không quan tâm DB nào chạy bên dưới. TCO ra sao? Với quy mô dưới một triệu vector, pgvector gần như miễn phí và đủ nhanh; Pinecone tốn khoảng 70 USD/tháng nhưng tiết kiệm công vận hành. Khả năng đảo ngược? Cao — nếu họ bọc phần truy vấn sau một interface riêng, đổi backend sau này khá dễ.
Đội chọn pgvector cho giai đoạn đầu, nhưng viết một lớp trừu tượng (abstraction layer) để nếu vượt quá vài triệu vector thì chuyển sang Pinecone chỉ mất vài ngày.
Bài học: "Build" và "buy" không loại trừ nhau theo thời gian. Bạn có thể build đơn giản lúc nhỏ, và chuyển sang buy khi quy mô đòi hỏi — miễn là bạn thiết kế điểm chuyển đổi có chủ đích ngay từ đầu.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng cho từng thành phần AI trong sản phẩm:
Bước 1 — Phân rã sản phẩm thành các thành phần. Đừng hỏi "build hay buy toàn bộ sản phẩm". Hãy liệt kê từng mảnh: model suy luận, embeddings, vector store, orchestration/RAG, eval, guardrails, giao diện chat, monitoring. Mỗi mảnh có một quyết định riêng.
Bước 2 — Đánh dấu mảnh nào là lợi thế cạnh tranh cốt lõi. Thường chỉ có một đến hai mảnh thực sự là "core". Với đa số sản phẩm AI, đó là logic nghiệp vụ, chất lượng prompt/RAG, và trải nghiệm người dùng — chứ hiếm khi là bản thân model. Ưu tiên nguồn lực "build" cho đúng những mảnh này.
Bước 3 — Chạy thử nghiệm rẻ trước khi cam kết build. Trước khi bỏ vài tháng tự xây, luôn dành một đến hai ngày làm prototype trên API có sẵn. Nếu API giải quyết được vấn đề ở mức chấp nhận, gánh nặng chứng minh nằm ở phía "tại sao phải build".
Bước 4 — Tính TCO đầy đủ, không chỉ chi phí ban đầu. Với "build", cộng cả bảo trì, trực vận hành, cập nhật model, chi phí cơ hội. Với "buy", cộng cả rủi ro tăng giá, rủi ro nhà cung cấp thay đổi điều khoản, và chi phí chuyển đổi nếu phải rời đi (bài 53 về quan hệ với nhà cung cấp).
Bước 5 — Thiết kế cho khả năng đảo ngược. Bọc mọi dịch vụ bên ngoài sau một interface do bạn kiểm soát. Đừng để lời gọi API OpenAI rải rác khắp codebase; đặt chúng sau một lớp trừu tượng để có thể đổi sang Anthropic, Google, hay model self-host mà không phải viết lại nửa hệ thống. Đây là nguyên tắc quan trọng nhất trong toàn bài.
Bước 6 — Đặt lại câu hỏi định kỳ. Mỗi 6 tháng, xem lại từng quyết định. Model rẻ đi, quy mô của bạn lớn lên, ràng buộc pháp lý thay đổi — cân bằng có thể đã dịch chuyển.
Lỗi thường gặp & mẹo
Lỗi 1 — Build vì "cho vui" hoặc vì kỹ sư muốn. Kỹ sư thường thích tự xây vì thú vị hơn. Nhưng "thú vị về kỹ thuật" không phải là lý do kinh doanh. Hãy tỉnh táo phân biệt mong muốn cá nhân với nhu cầu sản phẩm.
Lỗi 2 — Đánh giá thấp chi phí bảo trì của "build". Xây một hệ thống chỉ là 20% công việc; 80% còn lại là giữ nó chạy ổn định qua các thay đổi model, tải tăng, và lỗi bất ngờ. Nhiều đội chỉ tính phần 20%.
Lỗi 3 — Bỏ qua rủi ro tập trung vào một nhà cung cấp (vendor lock-in). Nếu 100% sản phẩm phụ thuộc vào một API duy nhất và họ tăng giá gấp ba, bạn không có đòn bẩy nào. Mẹo: luôn giữ khả năng chuyển đổi sang ít nhất một nhà cung cấp thay thế, kể cả khi hiện tại bạn chỉ dùng một.
Lỗi 4 — Fine-tune hoặc self-host quá sớm. Đây là cái bẫy phổ biến nhất với đội AI Việt Nam. Trước khi có bằng chứng rằng API không đủ tốt, tự huấn luyện model là tối ưu hóa sớm. Hãy để dữ liệu và tín hiệu người dùng dẫn dắt quyết định này, không phải trực giác.
Mẹo — Quy tắc "buy để học, build để thắng". Dùng "buy" (API) để nhanh chóng kiểm chứng thị trường và học xem khách hàng thực sự cần gì. Chỉ khi đã biết rõ đâu là lợi thế cạnh tranh và có đủ quy mô, mới "build" phần đó để bảo vệ và khác biệt hóa (liên quan bài 48 về xây moat).
Bài tập thực hành
- Phân rã sản phẩm của bạn. Lấy một ý tưởng sản phẩm AI bạn đang ấp ủ hoặc đang làm. Liệt kê ít nhất 6 thành phần kỹ thuật của nó. Với mỗi thành phần, định vị nó trên phổ Build ↔ Buy và viết một câu lý do.
- Chấm điểm ba câu hỏi. Với thành phần quan trọng nhất, trả lời cụ thể: (a) Đây có phải lợi thế cạnh tranh cốt lõi không? (b) TCO của build so với buy trong 12 tháng ước tính bao nhiêu? (c) Chi phí đảo ngược quyết định là bao nhiêu?
- Thiết kế điểm thoát. Chọn một dịch vụ bên ngoài bạn dự định dùng (ví dụ API model). Phác thảo một interface trừu tượng bọc quanh nó, sao cho bạn có thể đổi sang nhà cung cấp khác chỉ bằng cách thay phần triển khai bên trong. Viết ra các hàm mà interface đó phơi ra.
- Thử nghiệm hai ngày. Chọn một tính năng AI bạn nghĩ "phải tự build". Dành đúng hai ngày làm prototype bằng API có sẵn. Ghi lại: nó giải quyết được bao nhiêu phần trăm vấn đề? Điều này có thay đổi quyết định build/buy của bạn không?
Tóm tắt
Build vs Buy không phải là công tắc hai trạng thái mà là một phổ liên tục: từ mua trọn gói, cấu hình SaaS, xây trên API, tự host model, đến huấn luyện từ đầu. Với AI năm 2026, hai đặc thù — model tiến hóa nhanh và giá API giảm liên tục — khiến "build on API" trở thành điểm ngọt cho đa số sản phẩm ở giai đoạn đầu.
Ba câu hỏi dẫn đường: đây có phải lợi thế cạnh tranh cốt lõi không, tổng chi phí sở hữu thực sự là bao nhiêu, và quyết định này đảo ngược dễ đến đâu. Hãy phân rã sản phẩm thành từng thành phần và quyết định riêng cho mỗi mảnh — thường bạn chỉ nên "build" một đến hai mảnh thực sự tạo khác biệt, và "buy" phần còn lại.
Nguyên tắc thực hành quan trọng nhất: luôn thiết kế cho khả năng đảo ngược, bọc mọi dịch vụ bên ngoài sau một interface bạn kiểm soát, chạy thử nghiệm rẻ trước khi cam kết build, và tránh fine-tune hay self-host quá sớm. Hãy "buy để học, build để thắng" — dùng API để kiểm chứng thị trường nhanh, rồi mới tự xây đúng phần bảo vệ được lợi thế của bạn.