Bài 13 — Foundation Models Landscape 2026

Mở đầu — vì sao bài này quan trọng

Nếu bạn là một AI Product Manager năm 2026, có một sự thật phũ phàng: lựa chọn foundation model (mô hình nền tảng) là một trong những quyết định kiến trúc tốn kém và khó đảo ngược nhất mà bạn sẽ đưa ra. Nó ảnh hưởng tới chi phí vận hành mỗi tháng, tới chất lượng đầu ra mà khách hàng cảm nhận, tới tốc độ phản hồi, tới rủi ro pháp lý về dữ liệu, và thậm chí tới việc sản phẩm của bạn có chạy được trong môi trường on-premise của ngân hàng hay không.

Vấn đề là thị trường foundation model đang biến động cực nhanh. Sáu tháng trước mô hình tốt nhất là một cái tên, hôm nay là cái khác, và giá đã giảm 40%. Nhiều PM Việt Nam mắc kẹt vì chọn model theo "model nào nổi tiếng nhất trên Twitter" thay vì hiểu bản chất từng nhóm nhà cung cấp, điểm mạnh điểm yếu, và cách định vị chiến lược của họ.

Bài này không phải để bạn thuộc lòng từng con số benchmark — chúng sẽ lỗi thời trong vài tuần. Mục tiêu là giúp bạn xây một bản đồ tư duy bền vững về landscape foundation model: ai là ai, họ chia làm những nhóm nào, mỗi nhóm phù hợp với loại sản phẩm gì, và làm sao đọc được landscape mới khi nó tiếp tục thay đổi. Đây là kỹ năng "đọc bản đồ", không phải "thuộc địa danh".

Khái niệm cốt lõi

Trước tiên cần thống nhất: foundation model là mô hình lớn được huấn luyện trên lượng dữ liệu khổng lồ, đa năng, có thể dùng làm nền cho nhiều ứng dụng downstream khác nhau (chat, tóm tắt, code, dịch...). Trong bài này ta tập trung vào LLM (large language model) và một phần multimodal, vì đó là loại foundation model mà PM sản phẩm phần mềm chạm tới nhiều nhất.

Cách hữu ích nhất để vẽ landscape 2026 là chia theo mức độ mở (openness) và mô hình phân phối (distribution). Có ba nhóm lớn.

Nhóm 1 — Closed-source, API-only (mô hình đóng, chỉ truy cập qua API)

OpenAI: dòng GPT-4o, GPT-4.1, và thế hệ "o-series" tập trung suy luận (reasoning) như o3/o4. Định vị: hệ sinh thái rộng nhất, tooling chín muồi, đa năng, mạnh về function calling và multimodal. Đây thường là lựa chọn mặc định khi bạn cần "an toàn về độ chín".
Anthropic Claude: dòng Claude 3.5/3.7 Sonnet và Claude 4 (Opus, Sonnet, Haiku). Định vị: mạnh về suy luận dài, viết code, tuân thủ hướng dẫn (instruction following) chặt chẽ, an toàn (safety) và context window lớn. Rất được ưa chuộng cho coding agent và workflow doanh nghiệp.
Google Gemini: dòng Gemini 2.x (Flash, Pro). Định vị: context window cực lớn (lên tới hàng triệu token), tích hợp sâu hệ sinh thái Google Cloud, multimodal native, giá Flash rất cạnh tranh cho khối lượng lớn.

Đặc điểm chung của nhóm này: chất lượng đỉnh cao, ít phải tự vận hành hạ tầng, nhưng bạn không kiểm soát dữ liệu, phụ thuộc nhà cung cấp (vendor lock-in), và chi phí tăng tuyến tính theo lượng dùng.

Nhóm 2 — Open-weight (mô hình mở trọng số)

Đây là nhóm bạn tải được trọng số về, tự host, tự fine-tune. Năm 2026 nhóm này đã thu hẹp khoảng cách chất lượng với nhóm đóng một cách đáng kinh ngạc.

Meta Llama (dòng Llama 3.x, 4): mở rộng rãi, hệ sinh thái công cụ phong phú, được cộng đồng tin dùng làm "xương sống" để fine-tune.
Mistral (Mistral Large, Mixtral, các bản nhỏ): công ty Pháp, mạnh ở các model gọn nhẹ hiệu quả, giấy phép thân thiện.
DeepSeek và Qwen (Alibaba): nhóm model từ Trung Quốc gây chấn động vì hiệu năng/chi phí. DeepSeek nổi bật với khả năng suy luận giá rẻ; Qwen mạnh đa ngôn ngữ, bao gồm tiếng Việt khá tốt.

Lưu ý quan trọng: "open-weight" không đồng nghĩa "open-source thực sự". Phần lớn chỉ công bố trọng số chứ không công bố dữ liệu huấn luyện, và nhiều giấy phép có điều khoản hạn chế (ví dụ giới hạn số người dùng). PM phải đọc license kỹ trước khi đưa vào sản phẩm thương mại.

Nhóm 3 — Mô hình chuyên biệt và khu vực

Ngoài hai nhóm chính còn có các model tối ưu cho ngách hoặc cho ngôn ngữ địa phương — bao gồm các model tiếng Việt như PhoGPT, ViGPT, Vistral (sẽ học sâu ở Bài 51). Ở góc độ landscape, bạn chỉ cần nhớ: khi sản phẩm phục vụ thị trường Việt Nam với yêu cầu chủ quyền dữ liệu (data sovereignty) hoặc đặc thù ngôn ngữ, các model khu vực có thể là mảnh ghép quan trọng bên cạnh model toàn cầu.

Hai trục bạn luôn phải cân khi đọc landscape

Trục mở/đóng: đóng cho chất lượng cao và ít vận hành; mở cho kiểm soát dữ liệu, tùy biến và chi phí dài hạn thấp ở quy mô lớn.
Trục năng lực/chi phí: mỗi nhà cung cấp đều có "phân tầng" — model flagship đắt và mạnh (Opus, GPT cao cấp, Gemini Pro) và model nhỏ rẻ nhanh (Haiku, Flash, các bản mini). Sản phẩm trưởng thành hầu như luôn dùng nhiều tầng chứ không phải một model duy nhất.

Tình huống thực tế

Ví dụ 1 — Startup fintech Việt chọn nhầm tầng model

Một startup ở TP.HCM xây chatbot tư vấn vay tiêu dùng. Đội kỹ thuật mê chất lượng nên dùng model flagship đắt nhất của OpenAI cho mọi truy vấn — kể cả câu đơn giản như "lãi suất bao nhiêu?". Khi traffic tăng lên 200.000 lượt hỏi/tháng, hóa đơn API vọt lên khoảng 9.000 USD/tháng, ăn sạch biên lợi nhuận.

PM vào cuộc, phân tích log và phát hiện 70% câu hỏi thuộc loại đơn giản, lặp lại. Họ tái kiến trúc theo tầng: câu đơn giản đẩy sang model nhỏ rẻ (loại Haiku/Flash), chỉ câu phức tạp về điều kiện vay mới gọi flagship. Kết quả: chi phí giảm còn khoảng 2.500 USD/tháng, chất lượng cảm nhận gần như không đổi vì người dùng không phân biệt được ai trả lời câu dễ.

Bài học: Đừng chọn "một model cho tất cả". Landscape có nhiều tầng là để bạn định tuyến (route) thông minh. Chọn model là quyết định danh mục, không phải quyết định đơn lẻ. (Chi tiết về routing sẽ ở Bài 41.)

Ví dụ 2 — Ngân hàng yêu cầu dữ liệu không rời khỏi Việt Nam

Một ngân hàng tầm trung muốn xây trợ lý nội bộ đọc tài liệu tín dụng. Yêu cầu compliance: dữ liệu khách hàng tuyệt đối không được gửi ra API nước ngoài. Điều này lập tức loại bỏ toàn bộ Nhóm 1 (closed API-only) cho phần xử lý dữ liệu nhạy cảm.

PM lập bản đồ và chọn hướng open-weight: triển khai một model dòng Llama hoặc Qwen tự host trên hạ tầng trong nước, fine-tune nhẹ trên thuật ngữ ngân hàng tiếng Việt. Phần không nhạy cảm (ví dụ soạn email marketing chung) thì vẫn được phép dùng API ngoài để tiết kiệm công vận hành.

Kết quả là kiến trúc lai (hybrid): model mở tự host cho dữ liệu nhạy cảm, model đóng cho tác vụ chung. Họ chấp nhận chất lượng model mở thấp hơn flagship một chút để đổi lấy tuân thủ pháp lý.

Bài học: Ràng buộc về dữ liệu và pháp lý đôi khi quyết định nhóm model trước cả chất lượng. PM phải đưa compliance vào ma trận lựa chọn ngay từ đầu, không phải sửa sau.

Ví dụ 3 — Đội sản phẩm bị "đứng hình" vì model mới ra mỗi tháng

Một công ty SaaS ở Singapore phục vụ thị trường Đông Nam Á liên tục đổi model vì cứ thấy benchmark mới là muốn nhảy sang. Mỗi lần đổi tốn 2-3 tuần test lại prompt, đánh giá lại chất lượng, gây trễ roadmap.

PM thiết lập một quy trình đánh giá định kỳ thay vì phản ứng bốc đồng: mỗi quý đánh giá lại landscape một lần, dùng bộ test cố định (eval set) gồm 200 ca thực tế của sản phẩm, chỉ đổi model khi có cải thiện rõ rệt về chất lượng/chi phí vượt ngưỡng đặt trước (ví dụ tốt hơn 15% hoặc rẻ hơn 30%). Họ cũng thiết kế lớp trừu tượng (abstraction layer) để đổi model chỉ cần sửa cấu hình, không sửa code.

Bài học: Landscape biến động nhanh là tính năng chứ không phải bug. Đừng đuổi theo từng bản phát hành; hãy có quy trình và lớp trừu tượng để việc đổi model trở nên rẻ và có kỷ luật.

Hướng dẫn từng bước

Đây là quy trình để bạn lập bản đồ và chọn nhóm foundation model cho một sản phẩm cụ thể.

Liệt kê ràng buộc cứng trước. Trả lời: Dữ liệu có được phép rời khỏi hạ tầng của mình không? Có yêu cầu chủ quyền dữ liệu/đặt máy chủ trong nước không? Có ngân sách hạ tầng để tự host không? Những "không" ở đây sẽ loại bỏ cả nhóm model ngay lập tức, giúp bạn thu hẹp nhanh.

Phân loại tác vụ theo độ khó. Chia các use case của sản phẩm thành tầng: đơn giản/lặp lại (rẻ), trung bình, và phức tạp/cần suy luận sâu. Việc này quyết định bạn cần mấy tầng model.

Lập shortlist 2-3 nhà cung cấp cho mỗi tầng. Với tầng cao chọn các flagship (GPT cao cấp, Claude Opus/Sonnet, Gemini Pro); tầng thấp chọn các model nhỏ (Haiku, Flash, mini, hoặc Llama/Qwen nhỏ nếu tự host).

Xây eval set của riêng bạn. Lấy 100-200 ca thật từ sản phẩm (hoặc giả lập sát thực tế), kèm tiêu chí chấm điểm. Benchmark công khai chỉ để tham khảo; điều thật sự quyết định là model chạy thế nào trên dữ liệu của bạn.

Chạy thử song song và đo 4 chỉ số. Với mỗi model trong shortlist, đo: chất lượng (theo eval set), độ trễ (latency), chi phí mỗi 1.000 lượt dùng, và độ ổn định/tỷ lệ lỗi. Lập bảng so sánh trực quan.

Quyết định kiến trúc tầng và tạo abstraction layer. Chọn model cho từng tầng, nhưng cô lập việc gọi model sau một interface chung để sau này đổi nhà cung cấp không phải viết lại sản phẩm.

Lên lịch tái đánh giá. Đặt nhịp xem lại landscape (ví dụ mỗi quý) với ngưỡng đổi model rõ ràng để tránh đổi theo cảm tính.

Lỗi thường gặp & mẹo

Lỗi: Chọn model theo benchmark trên mạng. Benchmark công khai dễ bị "tối ưu để thi" và không phản ánh dữ liệu của bạn. Mẹo: luôn tin eval set riêng hơn bảng xếp hạng.
Lỗi: Dùng một model flagship cho tất cả. Đốt tiền vô ích cho các câu đơn giản. Mẹo: nghĩ theo "danh mục model nhiều tầng" ngay từ đầu.
Lỗi: Bỏ qua tổng chi phí sở hữu của model mở. Open-weight "miễn phí license" nhưng GPU, vận hành, MLOps không hề rẻ. Mẹo: tính TCO (total cost of ownership) gồm cả nhân sự và hạ tầng, đừng chỉ so giá token.
Lỗi: Không đọc kỹ license của model mở. Nhiều giấy phép có giới hạn thương mại bất ngờ. Mẹo: để legal duyệt license trước khi đưa vào production.
Lỗi: Vendor lock-in chặt. Gọi API trực tiếp khắp codebase khiến đổi model rất đau. Mẹo: luôn có abstraction layer ngay từ MVP.
Mẹo định vị nhanh: cần độ chín và đa năng → OpenAI; cần suy luận dài, coding, an toàn doanh nghiệp → Anthropic Claude; cần context siêu lớn và giá Flash cho khối lượng → Gemini; cần kiểm soát dữ liệu/tự host/chi phí quy mô lớn → Llama, Qwen, Mistral, DeepSeek.

Bài tập thực hành

Chọn một sản phẩm cụ thể (có thể là sản phẩm bạn đang làm hoặc một ý tưởng giả định: ví dụ "chatbot chăm sóc khách hàng cho một sàn TMĐT Việt Nam").

Viết ra 3 ràng buộc cứng của sản phẩm đó (dữ liệu, ngân sách, pháp lý) và xác định ràng buộc nào loại bỏ nhóm model nào.
Phân loại các use case của sản phẩm thành 2-3 tầng độ khó, kèm ước lượng tỷ lệ phần trăm lượng truy vấn mỗi tầng.
Lập một bảng so sánh gồm ít nhất 3 model thuộc các nhóm khác nhau (1 closed API, 1 open-weight, 1 model nhỏ giá rẻ), với 4 cột: chất lượng dự kiến, độ trễ, chi phí, mức kiểm soát dữ liệu.
Đề xuất kiến trúc tầng cho sản phẩm: model nào cho tầng nào, và vì sao.
Viết một đoạn 5-7 câu giải thích quy trình tái đánh giá mà bạn sẽ áp dụng để không bị cuốn theo mỗi bản model mới.

Hãy trình bày như một slide one-pager để thuyết phục ban lãnh đạo — đây chính là kỹ năng PM thật sự cần.

Tóm tắt

Landscape foundation model 2026 chia làm ba nhóm: closed API-only (OpenAI, Anthropic Claude, Google Gemini) đỉnh về chất lượng và độ chín nhưng bạn không kiểm soát dữ liệu; open-weight (Llama, Mistral, Qwen, DeepSeek) cho kiểm soát, tùy biến và chi phí quy mô lớn nhưng phải gánh vận hành; và các model chuyên biệt/khu vực phục vụ ngách hoặc ngôn ngữ địa phương. Đừng học thuộc benchmark — hãy xây bản đồ tư duy theo hai trục mở/đóng và năng lực/chi phí. Sản phẩm trưởng thành gần như luôn dùng nhiều tầng model, có abstraction layer để đổi model rẻ, và một quy trình tái đánh giá có kỷ luật. Quyết định bắt đầu từ ràng buộc cứng (dữ liệu, pháp lý, ngân sách), rồi đến eval set của riêng bạn — chứ không phải từ cái tên đang hot. Đó là tư duy giúp lựa chọn của bạn vẫn đúng kể cả khi landscape tiếp tục thay đổi.