Mô hình AI nguồn mở và nguồn đóng khác nhau thế nào?

Sự khác biệt cốt lõi giữa mô hình AI nguồn đóng và mô hình AI nguồn mở nằm ở quyền truy cập trọng số (weights) và khả năng kiểm soát hạ tầng vận hành.

Với các hệ thống nguồn đóng như GPT-5.6 Sol hay Claude Fable 5, bạn chỉ có thể tương tác qua giao diện API, nơi nhà cung cấp nắm toàn quyền kiểm soát các tham số mô hình. Ngược lại, các mô hình nguồn mở cho phép bạn tải trọng số về để chạy trực tiếp trên hạ tầng riêng, can thiệp sâu vào cấu trúc bên trong thay vì chỉ dừng lại ở kỹ thuật câu lệnh.

Chọn bên nào là một bài toán tối ưu hóa hệ thống dựa trên dữ liệu thực tế. Khi triển khai, bạn cần cân nhắc giữa tính tiện dụng "nhấp và chạy" của API so với quyền tự chủ hoàn toàn của giải pháp tự vận hành. Sự phân hóa này đang tái định hình cách doanh nghiệp tiếp cận AI, đặc biệt trong bối cảnh các dòng mô hình có khả năng lập luận (reasoning models) đang dần chiếm lĩnh thị trường vào giai đoạn đầu năm 2026.

Trong môi trường doanh nghiệp, sự đánh đổi giữa chi phí cố định (Capex) và chi phí biến đổi (Opex) quyết định tính bền vững của dự án AI. Một kỹ sư hệ thống giỏi sẽ không nhìn vào các lời hứa quảng cáo mà tập trung vào các thông số như VRAM, throughput (lưu lượng) và độ trễ để xác định điểm hòa vốn.

Khi quy mô vượt ngưỡng hàng triệu token mỗi ngày, mô hình mở thường thắng về chi phí — với điều kiện bạn đủ người để vận hành nó.

Hai thế giới mô hình AI đối lập: một bên khoá kín sau API của nhà cung cấp, một bên cho phép tải trọng số về chạy trên hạ tầng của chính bạn

Mô hình AI nguồn đóng và nguồn mở khác nhau ở chỗ nào?

Sự khác biệt rõ rệt nhất nằm ở quyền kiểm soát dữ liệu và hạ tầng. Với mô hình nguồn đóng (API-only), toàn bộ dữ liệu đầu vào (prompts) và đầu ra phải đi qua máy chủ của bên thứ ba, kéo theo rủi ro rò rỉ thông tin hoặc vi phạm các quy định như HIPAA và GDPR. Ngược lại, mô hình nguồn mở (self-hosted) cho phép bạn triển khai hoàn toàn trong VPC (mạng riêng ảo) hoặc hạ tầng on-premise riêng. Quyền riêng tư dữ liệu ở đây mang tính nhị phân (binary): hoặc là bạn kiểm soát hoàn toàn, hoặc là bạn gửi nó đi và hy vọng nhà cung cấp giữ đúng cam kết.

Ba khác biệt cốt lõi giữa mô hình nguồn đóng và nguồn mở: quyền kiểm soát dữ liệu, mô hình chi phí Opex so với Capex, và mức độ can thiệp kỹ thuật vào mô hình

Về mô hình tài chính, hai bên đại diện cho hai triết lý chi phí khác nhau. Nguồn đóng vận hành theo mô hình chi phí biến đổi (Opex), tính phí trên mỗi triệu token tiêu thụ. Đây là lựa chọn tối ưu cho giai đoạn prototyping nhanh hoặc các tác vụ khối lượng thấp dưới 100.000 token/ngày. Trong khi đó, nguồn mở đòi hỏi chi phí cố định (Capex) lớn cho phần cứng GPU (như H200 hoặc A100) và đội ngũ kỹ thuật vận hành. Tuy nhiên, khi lưu lượng ổn định ở quy mô lớn, chi phí cận biên trên mỗi request của nguồn mở gần như bằng không, giúp tiết kiệm từ 5-10 lần so với API.

Cuối cùng là khả năng can thiệp kỹ thuật. Với API nguồn đóng, bạn chỉ dùng được các tính năng có sẵn và phải chấp nhận tình trạng "vendor lock-in" (phụ thuộc nhà cung cấp). Với mô hình mở, bạn có quyền can thiệp vào từng tham số, tinh chỉnh sâu (full fine-tuning) hoặc triển khai các adapter LoRA chuyên biệt. Điều quan trọng nhất là bạn có quyền quyết định khi nào cần cập nhật mô hình, tránh tình trạng ứng dụng bị lỗi đột ngột do nhà cung cấp API thay đổi phiên bản (model deprecation).

Vì sao gần như không mô hình nào thực sự là "nguồn mở"?

Theo định nghĩa của Open Source Initiative (OSI), một hệ thống AI nguồn mở thực thụ phải cung cấp đầy đủ mã nguồn huấn luyện, thông tin về dữ liệu huấn luyện và các tham số mô hình dưới giấy phép cho phép tự do sử dụng, nghiên cứu, sửa đổi và chia sẻ. Thực tế hiện nay, các mô hình như Llama 3 hay Mistral chỉ nên được gọi là "Open Weights" (Trọng số mở). Các nhà phát triển chia sẻ trọng số cuối cùng để bạn vận hành bằng các khung như vLLM, nhưng họ giữ kín "công thức nấu ăn" đằng sau, khiến việc tái lập hoàn toàn mô hình là bất khả thi.

Sự thiếu minh bạch về dữ liệu tạo ra rào cản lớn khi kiểm định các sai lệch (bias) hoặc lỗ hổng an ninh tiềm ẩn. Nếu không có tập dữ liệu huấn luyện, kỹ sư hệ thống chỉ có thể đánh giá mô hình dựa trên kết quả đầu ra (black-box testing) mà không thể hiểu tại sao nó lại đưa ra kết luận đó. Bạn chỉ có quyền "tinh chỉnh" bề mặt chứ không phải "xây dựng lại từ đầu", và đó là thứ biến các mô hình mở hiện nay thành những sản phẩm "mở một nửa".

Bảng dưới đây so sánh sự khác biệt giữa hai khái niệm dựa trên tiêu chuẩn của OSI:

Đặc điểm	Open Weights (Trọng số mở)	Open Source AI (Nguồn mở thực thụ)
Trọng số & Biến số	Được công bố	Được công bố
Mã nguồn huấn luyện	Thường giữ kín	Phải chia sẻ toàn bộ
Tập dữ liệu huấn luyện	Không công bố/Chỉ công bố một phần	Phải minh bạch nguồn và cách xử lý
Quyền tự do tái lập	Bị hạn chế	Hoàn toàn tự do

Việc thiếu truy cập vào mã nguồn huấn luyện cũng ảnh hưởng đến khả năng tối ưu hóa sâu cho phần cứng. Trong khi các mô hình nguồn mở thực thụ cho phép cộng đồng cùng vá lỗi và cải thiện kiến trúc, các mô hình Open Weights khiến người dùng phụ thuộc vào lộ trình cập nhật của công ty chủ quản. Bạn có thể sử dụng chúng để xây dựng ứng dụng, nhưng quyền kiểm soát phần lõi của mô hình vẫn nằm trong tay những ông lớn công nghệ.

Giấy phép mới là thứ quyết định bạn được làm gì

Việc tải mô hình từ Hugging Face không đồng nghĩa với việc bạn có toàn quyền thương mại không giới hạn. Giấy phép Cộng đồng của Llama 3 là một ví dụ điển hình về "bẫy" pháp lý: nếu ứng dụng của bạn đạt ngưỡng 700 triệu người dùng hàng tháng, bạn buộc phải xin một giấy phép riêng từ Meta. Quan trọng hơn, giấy phép này cấm việc sử dụng đầu ra của Llama để huấn luyện các mô hình đối thủ, một điều khoản nhằm bảo vệ lợi thế cạnh tranh của Meta.

So sánh ràng buộc giấy phép giữa các mô hình mở: ngưỡng người dùng của Llama, quyền ngắt truy cập từ xa của Gemma, ngưỡng doanh thu của Mistral và quyền vĩnh viễn của Apache 2.0

Một rủi ro vận hành khác thường bị bỏ qua là cơ chế "Remote kill switch" (ngắt quyền truy cập từ xa) xuất hiện trong điều khoản của Google Gemma. Google bảo lưu quyền hạn chế sử dụng từ xa nếu họ tin rằng bạn vi phạm thỏa thuận sử dụng. Đây là một rủi ro về tính liên tục của doanh nghiệp (business continuity) mà các giấy phép nguồn mở thực thụ như Apache 2.0 không bao giờ áp dụng, vì Apache 2.0 cấp quyền vĩnh viễn và không thể thu hồi.

Ngay trong nhóm "mở", mức độ ràng buộc cũng chênh nhau rất xa. Mistral phát hành phần lớn mô hình dưới Apache 2.0 thực thụ, nhưng vẫn có những mô hình dùng giấy phép MIT sửa đổi kèm ngưỡng doanh thu. Meta thì vừa đảo chiều: Muse Glimmer, mô hình 30B công bố tháng 8/2026, ra mắt dưới Apache 2.0 thay vì giấy phép cộng đồng Llama quen thuộc. Kimi K3 dùng giấy phép MIT sửa đổi, kèm điều khoản ghi nhận nguồn khi ứng dụng của bạn vượt 100 triệu người dùng hàng tháng. Do đó, việc kiểm định giấy phép (license audit) là bước bắt buộc trước khi nhúng bất kỳ mô hình nào vào hệ thống sản xuất. Bạn cần hiểu rõ liệu mình có đang xây lâu đài trên mảnh đất mà chủ sở hữu có quyền thu hồi bất cứ lúc nào hay không.

Khoảng cách năng lực giữa hai bên còn bao xa?

Dữ liệu từ Epoch AI cho thấy khoảng cách giữa mô hình mở và đóng đang thu hẹp nhanh. Tính từ đầu năm 2026, các mô hình mở tiên tiến nhất chỉ còn tụt hậu trung bình 4 tháng so với các mô hình đóng dẫn đầu thị trường. Khoảng cách trên chỉ số ECI (Epoch Capabilities Index) hiện chỉ còn 8 điểm, tương đương với sự khác biệt giữa hai phiên bản nâng cấp nhẹ (như GPT-5 và GPT-5.5).

Khoảng cách năng lực giữa mô hình mở và mô hình đóng: mô hình mở đi sau khoảng 4 tháng, tương đương 8 điểm trên chỉ số ECI

Tuy nhiên, con số 4 tháng này có thể bị đánh giá thấp. Các mô hình mở thường có xu hướng tối ưu hóa quá mức cho các bộ kiểm tra công khai (public benchmarks) để đạt thứ hạng cao, nhưng thực tế vận hành trên các bài toán nội bộ (private benchmarks) lại kém hiệu quả hơn so với mô hình đóng. Vì thế các kỹ sư hệ thống phải tự đánh giá thực tế (side-by-side) thay vì chỉ tin vào các bảng điểm trên mạng.

Sự trỗi dậy của các siêu mô hình nguồn mở như Kimi K3 (2,8 nghìn tỷ tham số) đã chứng minh rằng kiến trúc Mixture-of-Experts (MoE) quy mô lớn không còn là đặc quyền của nguồn đóng. Trên chỉ số Artificial Analysis Intelligence Index, Kimi K3 đạt khoảng 57 điểm và xếp thứ 3 toàn cầu. Khoảng cách thu hẹp ở phân khúc siêu lớn cho thấy cộng đồng và các phòng thí nghiệm AI đang bám sát các "ông lớn" công nghệ.

Thị trường thực tế đang chạy mô hình nào?

Dựa trên nghiên cứu 100 nghìn tỷ token của OpenRouter, thị trường hiện đang chia theo tỷ lệ khoảng 70% nguồn đóng và 30% nguồn mở. Điểm đáng chú ý nhất là sự trỗi dậy của Agentic Inference (suy luận tác nhân). Người dùng đang chuyển từ hỏi đáp đơn giản sang các mô hình có khả năng lập luận sâu (reasoning models) để chạy những chuỗi tác vụ phức tạp, gọi công cụ và tự động sửa lỗi.

Thị phần thực tế theo lượng token: khoảng 70% thuộc về mô hình nguồn đóng và 30% thuộc về nguồn mở, cùng xu hướng dịch chuyển sang nhóm mô hình cỡ trung

Trong phân khúc nguồn mở, thị trường đang trải qua hiện tượng "Glass Slipper Effect" (Hiệu ứng Chiếc giày thủy tinh). Nghĩa là người dùng có xu hướng bám trụ (retention) rất lâu với mô hình đầu tiên giải quyết được bài toán cụ thể của họ, ngay cả khi có mô hình mới tốt hơn ra đời. Các dòng mô hình như DeepSeek và Qwen đã tạo ra được sự gắn kết này nhờ vào khả năng giải quyết các tác vụ ngách rất tốt.

Xu hướng "Medium is the new Small" cũng đang định hình lại hạ tầng. Người dùng đang dịch chuyển mạnh mẽ từ các mô hình cực nhỏ sang phân khúc 15B-70B tham số. Đây là "điểm ngọt" (sweet spot) về hiệu năng trên chi phí: đủ thông minh để xử lý logic phức tạp nhưng vẫn có thể vận hành hiệu quả trên các cụm GPU phổ thông thay vì cần tới các siêu máy tính.

Chi phí và đánh đổi khi tự vận hành mô hình mở

Vận hành các mô hình mở quy mô lớn là một thách thức về kỹ thuật hạ tầng. Ví dụ, mô hình GLM-5.2 (744B tham số) cần hơn 1 TB VRAM, tương đương với một cụm 8 card H200 để chạy ổn định. Các mô hình như Kimi K3 thì đòi hỏi từ 64 card tăng tốc trở lên cho tác vụ suy luận. Vì thế, tự vận hành gần như không có ý nghĩa kinh tế với những ứng dụng khối lượng thấp, nơi giá API vẫn rẻ hơn nhiều.

Điểm hòa vốn giữa gọi API và tự vận hành mô hình mở: chi phí đảo chiều khi lưu lượng token mỗi ngày tăng dần

Điểm hòa vốn là thông số sống còn. Đối với Llama 3.1 70B, điểm hòa vốn so với API thường nằm ở mức 3-5 triệu token mỗi ngày. Nếu lưu lượng của bạn thấp hơn mức này, chi phí thuê GPU và vận hành sẽ cao hơn việc trả tiền cho API. Nhưng khi vượt qua ngưỡng đó, chi phí cho mỗi token giảm dần theo quy mô, và ở mức trên 50 triệu token mỗi ngày thì khoảng cách trở nên rất lớn.

Ngoài tiền điện và phần cứng, bạn phải tính đến các chi phí ẩn của hệ thống. Bạn cần kỹ sư MLOps để quản lý các khung vận hành như vLLM, cấu hình PagedAttention để tối ưu bộ nhớ đệm KV và thiết lập continuous batching để đạt throughput tối đa. Giám sát sức khỏe GPU, xử lý lỗi tràn bộ nhớ và cập nhật các bản vá bảo mật thủ công là những gánh nặng vận hành mà các dịch vụ API đã giúp bạn loại bỏ. Chi phí thật của một cụm tự vận hành vì thế cao hơn đáng kể so với con số thuê GPU theo giờ.

Vì sao cuộc tranh cãi này lan tới tầm chính sách?

Cuộc đối đầu giữa nguồn đóng và mở đã trở thành vấn đề địa chính trị căng thẳng. Chính phủ Mỹ bày tỏ lo ngại về các mô hình mở từ Trung Quốc như Kimi K3 và DeepSeek, không chỉ vì rò rỉ dữ liệu mà còn vì chúng cho phép người dùng gỡ bỏ các rào cản an toàn (guardrails) mà phương Tây thiết lập. Khi trọng số đã công khai, bất kỳ ai cũng có thể huấn luyện lại để loại bỏ bộ lọc an toàn, và không ai thu hồi được bản đã phát hành.

Các phòng thí nghiệm tiên phong lập luận rằng mô hình mở làm giảm hiệu quả đầu tư vốn. Họ cho rằng việc bỏ ra hàng tỷ USD huấn luyện rồi để đối thủ cung cấp năng lực tương đương với giá rẻ hơn nhiều sẽ bào mòn biên lợi nhuận và triệt tiêu động lực đẩy tiếp giới hạn công nghệ. Ngược lại, những tiếng nói như Clem Delangue của Hugging Face tin rằng hạn chế mô hình mở không làm AI an toàn hơn — nó chỉ giấu rủi ro đi và làm quyền lực tập trung hơn.

Cuộc tranh luận này vì thế xoay quanh vấn đề tập trung quyền lực nhiều hơn là an toàn thuần túy. Nếu chỉ một vài công ty nắm giữ các mô hình mạnh nhất, họ sẽ định hình toàn bộ hạ tầng AI mà phần còn lại của thế giới phải xây dựng bên trên. Mã nguồn mở là đối trọng, đảm bảo các doanh nghiệp nhỏ, tổ chức phi lợi nhuận và nhà nghiên cứu độc lập vẫn còn đường tiếp cận. Kết quả của cuộc tranh cãi này sẽ quyết định trực tiếp việc bạn còn được tải trọng số chất lượng cao về máy nữa hay không.

Nên chọn nguồn mở hay nguồn đóng cho công việc của bạn?

Cách quyết định thực dụng là chấm điểm sáu chiều: khả năng, riêng tư, chi phí, vận hành, tinh chỉnh và độ trễ. Chọn nguồn đóng khi bạn cần kiểm chứng ý tưởng trong 24 giờ, khi khối lượng còn dưới 100.000 token mỗi ngày, hoặc khi tác vụ đòi hỏi năng lực đa phương thức cao nhất. Chọn nguồn mở khi dữ liệu không được rời khỏi VPC vì HIPAA hay GDPR, khi lưu lượng đã vượt vài triệu token mỗi ngày, hoặc khi bạn cần tinh chỉnh sâu trên chính dữ liệu của mình.

Hướng dẫn chọn bên: khi nào nên dùng mô hình nguồn đóng, khi nào nên dùng nguồn mở, và cách kết hợp cả hai theo từng tác vụ

Với hầu hết đội ngũ, câu trả lời đúng không phải là chọn một bên rồi trung thành mãi mãi, mà là định tuyến theo từng tác vụ: để mô hình đóng lo phần lập luận khó ở tầng đầu, đẩy phần việc lặp lại và khối lượng lớn sang mô hình mở tự vận hành. Ranh giới giữa hai bên đang dịch chuyển mỗi vài tháng, nên hãy thiết kế hệ thống sao cho việc đổi mô hình là một dòng cấu hình, chứ không phải một dự án di trú.