Mở đầu — vì sao bài này quan trọng
Nếu bạn xây một sản phẩm AI năm 2026, quyết định "chọn foundation model nào" không còn là chuyện kỹ thuật thuần túy — nó là một quyết định chiến lược ảnh hưởng trực tiếp đến chi phí vận hành, trải nghiệm người dùng, tốc độ ra thị trường và cả rủi ro pháp lý. Tôi đã chứng kiến nhiều đội ở Việt Nam đốt hàng chục triệu đồng chi phí API mỗi tháng chỉ vì mặc định dùng model mạnh nhất cho mọi tác vụ, trong khi 70% việc họ làm chỉ cần một model rẻ hơn năm lần.
Foundation model — hay còn gọi là "mô hình nền tảng" — là những mô hình ngôn ngữ lớn được huấn luyện trên khối lượng dữ liệu khổng lồ, có khả năng tổng quát và làm nền cho vô số ứng dụng phía trên. Bạn không tự huấn luyện chúng; bạn "thuê" chúng qua API hoặc tự host bản mã nguồn mở. Ở bài trước (Bài 5), chúng ta đã phân biệt khi nào dùng LLM và khi nào dùng ML truyền thống. Bài này đi sâu hơn một bậc: giả sử bạn đã quyết định dùng LLM, thì trong cả rừng model đang cạnh tranh khốc liệt — GPT của OpenAI, Claude của Anthropic, Gemini của Google, Llama của Meta — bạn nên chọn cái nào, cho việc gì, và dựa trên tiêu chí gì?
Đây không phải bài để bạn học thuộc lòng model nào "tốt nhất" — vì bảng xếp hạng thay đổi mỗi vài tháng. Mục tiêu của tôi là trang bị cho bạn một khung tư duy so sánh bền vững: những trục đánh giá không đổi dù model có nâng cấp bao nhiêu lần.
Khái niệm cốt lõi
Bốn "gia đình" model bạn cần biết
Thị trường 2026 xoay quanh bốn nhà cung cấp lớn, mỗi bên có triết lý riêng:
OpenAI (dòng GPT và o-series): Người mở màn cuộc chơi. GPT-4.5 mạnh về khả năng tổng quát và hệ sinh thái công cụ (function calling, structured output, Assistants API) trưởng thành nhất. Dòng o3/o4 là các model "reasoning" — chúng dành thêm thời gian "suy nghĩ" trước khi trả lời, giỏi toán, lập trình và các bài toán logic nhiều bước. Điểm mạnh: hệ sinh thái, tài liệu, cộng đồng đông. Điểm yếu: giá cao ở dòng reasoning, và thỉnh thoảng "quá tự tin" khi bịa thông tin.
Anthropic (dòng Claude): Nổi tiếng về độ an toàn, khả năng viết dài mạch lạc và bám sát chỉ dẫn (instruction following). Claude thường được các đội làm sản phẩm nội dung, coding assistant và các lĩnh vực nhạy cảm (pháp lý, y tế) ưa chuộng vì ít "bịa" hơn và dễ kiểm soát hành vi qua system prompt. Cửa sổ ngữ cảnh (context window) rất lớn — có thể nạp cả một tài liệu dài hàng trăm trang. Điểm yếu: hệ sinh thái công cụ ra sau OpenAI một nhịp.
Google (dòng Gemini): Lợi thế cực lớn ở đa phương thức (multimodal) — xử lý ảnh, video, âm thanh và văn bản trong cùng một model một cách tự nhiên — và ở cửa sổ ngữ cảnh siêu dài (lên tới cả triệu token). Tích hợp sâu với hệ sinh thái Google Cloud, Workspace. Giá dòng Flash rất cạnh tranh. Điểm yếu: chất lượng đôi khi thiếu ổn định giữa các phiên bản, và trải nghiệm developer từng bị chê rườm rà.
Meta (dòng Llama): Ngôi sao của phe mã nguồn mở (open weights). Bạn tải trọng số về, tự host trên hạ tầng của mình, toàn quyền kiểm soát dữ liệu và không phụ thuộc API bên thứ ba. Đây là lựa chọn của các đội cần dữ liệu ở lại trong nước (data residency), cần fine-tune sâu, hoặc muốn tối ưu chi phí ở quy mô lớn. Điểm yếu: bạn phải tự lo GPU, vận hành, giám sát — chi phí ẩn không hề nhỏ. (Chi tiết về self-host sẽ có ở Bài 39.)
Sáu trục để so sánh bất kỳ model nào
Thay vì nhìn vào một con số benchmark, hãy đánh giá model theo sáu trục sau. Đây chính là khung tư duy tôi muốn bạn ghi nhớ:
- Chất lượng đầu ra (Quality): Model trả lời đúng, mạch lạc, đúng ý bạn muốn tới đâu? Chú ý: chất lượng phụ thuộc tác vụ cụ thể — một model giỏi coding chưa chắc giỏi viết marketing tiếng Việt.
- Chi phí (Cost): Tính theo giá 1 triệu token đầu vào và đầu ra. Đây là trục sống còn khi bạn scale. Chênh lệch giữa model flagship và model nhỏ có thể lên tới 20–50 lần.
- Độ trễ (Latency): Model trả lời nhanh hay chậm? Model reasoning trả lời chậm hơn nhiều vì phải "suy nghĩ". Với chatbot thời gian thực, latency quyết định trải nghiệm. (Sâu hơn ở Bài 12.)
- Cửa sổ ngữ cảnh (Context window): Model "nhớ" được bao nhiêu token trong một lần gọi? Quan trọng khi bạn cần nạp tài liệu dài, lịch sử hội thoại, hay nhiều đoạn tài liệu truy xuất (RAG).
- Đa phương thức (Multimodality): Model có xử lý được ảnh, âm thanh, video không? Cần cho các sản phẩm phân tích hóa đơn, kiểm duyệt ảnh, trợ lý giọng nói.
- Kiểm soát & tuân thủ (Control & Compliance): Bạn được fine-tune không? Dữ liệu có được dùng để huấn luyện lại không? Có bản self-host cho dữ liệu nhạy cảm không? Với Nghị định 13 về bảo vệ dữ liệu cá nhân ở Việt Nam, trục này ngày càng nặng ký.
Nguyên tắc vàng: "model routing"
Sai lầm lớn nhất là chọn một model cho toàn bộ sản phẩm. Đội trưởng thành dùng model routing: định tuyến từng loại tác vụ tới model phù hợp nhất về tỉ lệ chất lượng/chi phí. Ví dụ dùng model nhỏ rẻ để phân loại ý định người dùng, và chỉ gọi model flagship đắt tiền khi thật sự cần suy luận phức tạp.
Tình huống thực tế
Ví dụ 1: Startup fintech ở TP.HCM tối ưu chi phí bằng model routing
Một startup fintech giả định — gọi là VíThôngMinh — xây trợ lý tài chính cá nhân trong ứng dụng ví điện tử, phục vụ khoảng 200.000 người dùng hoạt động hằng tháng. Ban đầu họ dùng GPT-4.5 cho mọi yêu cầu: từ câu hỏi đơn giản "số dư của tôi là bao nhiêu" đến phân tích chi tiêu phức tạp. Hóa đơn API tháng đầu: gần 4.500 USD, tương đương hơn 110 triệu đồng.
Đội kỹ thuật ngồi lại phân loại truy vấn và phát hiện: 65% là câu hỏi tra cứu đơn giản, 25% là hỏi đáp về sản phẩm, chỉ 10% cần suy luận thực sự (lập kế hoạch tiết kiệm, phân tích dòng tiền). Họ triển khai model routing: một model nhỏ giá rẻ (Gemini Flash) xử lý nhóm 65%, Claude tầm trung xử lý nhóm 25% vì cần bám ngữ cảnh hội thoại tốt và diễn đạt tiếng Việt tự nhiên, và chỉ nhóm 10% mới đẩy lên model reasoning.
Kết quả sau một tháng: hóa đơn giảm xuống còn khoảng 1.300 USD — tiết kiệm hơn 70% — trong khi điểm hài lòng người dùng tăng nhẹ, vì các câu hỏi đơn giản nay được trả lời nhanh hơn hẳn (latency thấp hơn).
Bài học: Đừng dùng dao mổ trâu để giết gà. Phân loại tác vụ trước, chọn model theo từng loại. Chi phí AI có thể giảm nhiều lần mà chất lượng không giảm, thậm chí tăng.
Ví dụ 2: Công ty pháp lý chọn Claude vì độ tin cậy, không phải benchmark
Một công ty cung cấp dịch vụ soạn thảo hợp đồng tại Hà Nội muốn xây trợ lý rà soát điều khoản hợp đồng tiếng Việt. Họ chạy thử ba model trên cùng một bộ 50 hợp đồng mẫu. Về điểm benchmark công khai, model reasoning của OpenAI đứng đầu. Nhưng khi thử thực tế, đội pháp chế phát hiện một vấn đề nghiêm trọng: model đó thỉnh thoảng bịa ra các điều khoản luật không tồn tại một cách rất thuyết phục (hiện tượng hallucination). Trong ngành pháp lý, một lỗi như vậy đủ để mất khách hàng.
Họ chuyển sang Claude vì khi được yêu cầu "chỉ trích dẫn nội dung có trong văn bản, nếu không chắc thì nói không chắc", Claude bám chỉ dẫn tốt hơn và từ chối bịa. Cửa sổ ngữ cảnh lớn cũng cho phép nạp cả hợp đồng dài 80 trang vào một lần gọi mà không phải cắt nhỏ. Họ đánh đổi vài điểm benchmark lấy sự an toàn — và đó là đánh đổi đúng cho ngành của họ.
Bài học: Điểm benchmark cao không đồng nghĩa phù hợp với bài toán của bạn. Trong lĩnh vực nhạy cảm, độ tin cậy và khả năng kiểm soát quan trọng hơn điểm số. Luôn tự chạy eval trên dữ liệu thật của mình (chi tiết ở Bài 9).
Ví dụ 3: Đội sản phẩm chọn Llama tự host vì Nghị định 13
Một ngân hàng số ở Đông Nam Á muốn xây trợ lý nội bộ phân tích hồ sơ khách hàng. Vấn đề: dữ liệu chứa thông tin cá nhân nhạy cảm, và bộ phận pháp chế không cho phép gửi dữ liệu này ra API của bên thứ ba ở nước ngoài — vừa vì chính sách nội bộ, vừa vì các yêu cầu về bảo vệ dữ liệu cá nhân (tương tự Nghị định 13 tại Việt Nam).
Họ chọn Llama, tự host trên cụm GPU trong trung tâm dữ liệu của chính ngân hàng. Đúng là chất lượng thô của Llama thua model flagship đóng khoảng một bậc, và chi phí GPU ban đầu không rẻ. Nhưng đổi lại: dữ liệu không rời khỏi hạ tầng ngân hàng, họ được fine-tune model trên thuật ngữ nghiệp vụ riêng, và về lâu dài ở quy mô hàng triệu lượt gọi mỗi ngày, tổng chi phí sở hữu (TCO) còn thấp hơn trả API.
Bài học: Khi tuân thủ và quyền kiểm soát dữ liệu là ràng buộc cứng, mã nguồn mở tự host là lựa chọn chiến lược — kể cả khi phải hy sinh một chút chất lượng thô.
Hướng dẫn từng bước
Đây là quy trình chọn foundation model tôi khuyên bạn áp dụng cho mọi dự án mới:
Bước 1 — Liệt kê các loại tác vụ. Đừng nghĩ "sản phẩm cần model gì" mà nghĩ "sản phẩm có những loại tác vụ nào". Ví dụ: phân loại ý định, trích xuất dữ liệu, hội thoại, suy luận phức tạp, xử lý ảnh. Mỗi loại có yêu cầu chất lượng/chi phí khác nhau.
Bước 2 — Xác định ràng buộc cứng. Có yêu cầu dữ liệu phải ở lại trong nước không? Có ngân sách trần mỗi tháng không? Latency tối đa chấp nhận được là bao nhiêu? Những ràng buộc này loại bỏ ngay một số lựa chọn. Nếu bắt buộc self-host, danh sách rút gọn về phe mã nguồn mở.
Bước 3 — Chọn 2–3 ứng viên cho mỗi loại tác vụ. Dựa trên sáu trục ở trên. Đừng chọn theo lời đồn — chọn theo trục phù hợp với ràng buộc của bạn.
Bước 4 — Xây bộ eval nhỏ bằng dữ liệu thật. Lấy 30–100 ví dụ thực tế từ chính sản phẩm của bạn (hoặc mô phỏng sát nhất). Chạy cả các ứng viên trên cùng bộ này. Đây là bước quan trọng nhất và cũng hay bị bỏ qua nhất.
Bước 5 — Chấm điểm đa chiều, không chỉ chất lượng. Với mỗi model, ghi lại: chất lượng đầu ra, chi phí trung bình mỗi lượt gọi, latency trung bình. Lập bảng so sánh.
Bước 6 — Quyết định theo tỉ lệ chất lượng/chi phí, không theo chất lượng tuyệt đối. Model tốt nhất về chất lượng thường không phải lựa chọn tối ưu về kinh tế. Hãy hỏi: "Với ngân sách này, model nào cho trải nghiệm đủ tốt?"
Bước 7 — Thiết kế lớp trừu tượng (abstraction layer). Viết code sao cho việc đổi model chỉ là đổi một tham số cấu hình, không phải viết lại logic. Thị trường thay đổi mỗi quý — bạn cần đổi model dễ dàng. (Các framework như LangChain, LlamaIndex hỗ trợ việc này, xem Bài 23.)
Lỗi thường gặp & mẹo
Lỗi 1 — "Model mạnh nhất cho mọi thứ". Đây là lỗi tốn kém nhất. Kết quả: hóa đơn API phình to, latency tệ ở các tác vụ đơn giản. Mẹo: luôn bắt đầu bằng model nhỏ nhất đủ tốt, chỉ nâng cấp khi eval cho thấy cần.
Lỗi 2 — Chọn model theo bảng xếp hạng công khai. Benchmark công khai bị "học tủ" (model được tối ưu để ăn điểm benchmark) và không phản ánh tác vụ tiếng Việt hay ngữ cảnh riêng của bạn. Mẹo: luôn tự eval trên dữ liệu thật của mình.
Lỗi 3 — Khóa cứng vào một nhà cung cấp (vendor lock-in). Viết code bám chặt vào SDK và đặc thù của một hãng khiến việc đổi model tốn hàng tuần. Mẹo: dùng lớp trừu tượng ngay từ đầu.
Lỗi 4 — Quên yếu tố tiếng Việt. Nhiều model mạnh tiếng Anh nhưng diễn đạt tiếng Việt gượng gạo, sai dấu, dùng từ Hán-Việt lệch nghĩa. Mẹo: luôn có ví dụ tiếng Việt trong bộ eval, đặc biệt cho sản phẩm B2C.
Lỗi 5 — Bỏ qua điều khoản dữ liệu. Không đọc kỹ liệu nhà cung cấp có dùng dữ liệu của bạn để huấn luyện không. Mẹo: với dữ liệu nhạy cảm, dùng tier doanh nghiệp có cam kết không lưu/không huấn luyện, hoặc self-host.
Mẹo tổng quát: Coi việc chọn model là quyết định có thể đảo ngược. Đừng cầu toàn ở lần chọn đầu. Ship nhanh với lựa chọn hợp lý, đo lường thực tế, rồi tối ưu.
Bài tập thực hành
- Bản đồ tác vụ: Chọn một sản phẩm AI bạn đang hình dung. Liệt kê tất cả các loại tác vụ mà nó cần LLM xử lý. Với mỗi loại, đánh dấu mức độ ưu tiên của sáu trục (chất lượng, chi phí, latency, ngữ cảnh, đa phương thức, kiểm soát).
- Bảng so sánh: Chọn ba model từ ba nhà cung cấp khác nhau. Lập bảng so sánh chúng theo sáu trục cho một tác vụ cụ thể trong sản phẩm của bạn. Ghi rõ model nào bạn chọn và lý do.
- Mini-eval: Viết 10 câu hỏi/tình huống thật bằng tiếng Việt mà sản phẩm của bạn sẽ gặp. Nếu có điều kiện, chạy chúng qua hai model khác nhau và tự chấm điểm chất lượng theo thang 1–5. So sánh kết quả với cảm nhận ban đầu của bạn — có bất ngờ nào không?
- Kịch bản routing: Thiết kế một sơ đồ model routing đơn giản cho sản phẩm của bạn: tác vụ nào đi model rẻ, tác vụ nào đi model đắt, và tiêu chí phân luồng là gì.
Tóm tắt
- Foundation model là mô hình nền tảng bạn "thuê" qua API hoặc tự host; bốn gia đình lớn 2026 là GPT (OpenAI), Claude (Anthropic), Gemini (Google) và Llama (Meta), mỗi bên có thế mạnh riêng.
- Đừng học thuộc "model nào tốt nhất" — hãy nắm sáu trục so sánh bền vững: chất lượng, chi phí, độ trễ, cửa sổ ngữ cảnh, đa phương thức, kiểm soát & tuân thủ.
- OpenAI mạnh hệ sinh thái và reasoning; Claude mạnh độ tin cậy, bám chỉ dẫn và viết dài; Gemini mạnh đa phương thức và ngữ cảnh siêu dài; Llama mạnh ở tự host và kiểm soát dữ liệu.
- Nguyên tắc vàng là model routing: dùng model rẻ cho tác vụ đơn giản, dành model đắt cho suy luận phức tạp — có thể giảm chi phí nhiều lần mà không giảm chất lượng.
- Luôn tự chạy eval trên dữ liệu thật của mình, đặc biệt với tiếng Việt; đừng tin bảng xếp hạng công khai.
- Với dữ liệu nhạy cảm và ràng buộc tuân thủ (Nghị định 13), self-host mã nguồn mở có thể là lựa chọn chiến lược dù chất lượng thô thấp hơn.
- Thiết kế lớp trừu tượng để đổi model dễ dàng — vì thị trường thay đổi mỗi quý, và quyết định chọn model nên là quyết định có thể đảo ngược.