On-premise LLM hay cloud: chọn gì khi dữ liệu nhạy cảm
01/10/2026
Có một buổi họp tôi nhớ mãi. Phía bệnh viện hỏi một câu rất ngắn: dữ liệu bệnh án của chúng tôi có đi ra khỏi tòa nhà này không? Cả bàn im vài giây. Câu hỏi đó, chứ không phải chuyện model to hay nhỏ, mới là thứ quyết định kiến trúc. Bài này bàn về việc chọn on-premise LLM hay cloud khi dữ liệu nhạy cảm, từ góc nhìn của một đơn vị làm LLM tiếng Việt tại Việt Nam.
Tôi không có đáp án chung cho mọi nơi. Có những doanh nghiệp nên chạy hoàn toàn nội bộ, có những nơi dùng cloud là hợp lý hơn nhiều. Thứ tôi muốn làm là cho bạn bộ câu hỏi để tự quyết, thay vì nghe theo trào lưu.
Dữ liệu nhạy cảm thực sự là gì
Nhiều người nghe chữ “nhạy cảm” là nghĩ ngay đến bí mật quốc gia. Thực tế hằng ngày khiêm tốn hơn nhiều. Đó là hồ sơ bệnh án, đơn thuốc, hợp đồng với khách hàng, bảng lương, nội dung cuộc gọi tổng đài có số căn cước, báo cáo tài chính chưa công bố. Chỉ cần một đoạn ghi âm cuộc gọi của khách hàng là đã chứa tên, địa chỉ, đôi khi cả số tài khoản.
Trước khi chọn hạ tầng, hãy phân loại dữ liệu thành vài nhóm: công khai, nội bộ, bảo mật, và bị ràng buộc bởi luật hoặc hợp đồng. Mỗi nhóm có thể đi một đường khác nhau. Tôi từng thấy một công ty ép toàn bộ vào một giải pháp duy nhất, rồi mất ba tháng để gỡ ra vì 80% dữ liệu của họ thực ra chẳng nhạy cảm gì.
On-premise: được gì, mất gì
Chạy model trong hạ tầng của chính mình, hoặc trong một vùng riêng biệt lập, cho bạn quyền kiểm soát rõ ràng nhất. Dữ liệu không rời mạng nội bộ, nhật ký truy cập nằm trong tay bạn, và khi kiểm toán viên hỏi dữ liệu đi đâu, câu trả lời ngắn và dễ chứng minh.
Cái giá cũng thật. Bạn cần GPU, mà GPU thì đắt và có thời gian chờ. Bạn cần người vận hành: cập nhật driver, theo dõi nhiệt độ, xử lý khi một node chết lúc 2 giờ sáng. Model cũng phải được cập nhật thủ công, nên nếu không có đội đủ mạnh, hệ thống on-premise rất dễ già đi sau một năm. Tôi thấy nhiều dự án bắt đầu hào hứng rồi chết dần vì không ai chịu trách nhiệm vận hành.
- Hợp với: bệnh viện, ngân hàng, cơ quan có quy định chặt về nơi lưu dữ liệu, doanh nghiệp có lượng truy vấn lớn và ổn định.
- Không hợp với: đội nhỏ, nhu cầu thử nghiệm, lượng dùng thất thường.
Cloud: khi nó hợp lý hơn bạn nghĩ
Cloud cho bạn khả năng co giãn. Cần thử một ý tưởng trong hai tuần thì thuê GPU hai tuần, không phải mua cả hệ thống. Nhà cung cấp lớn cũng đầu tư vào bảo mật nhiều hơn mức một doanh nghiệp vừa có thể tự làm. Nói thẳng, một server đặt trong phòng kỹ thuật không có người trực chưa chắc an toàn hơn một vùng cloud được cấu hình tử tế.
Vấn đề nằm ở chỗ khác: dữ liệu rời khỏi tầm tay trực tiếp của bạn, bạn phải tin vào hợp đồng, vào cấu hình, và vào việc nhà cung cấp không dùng dữ liệu để huấn luyện thứ gì khác. Với dữ liệu bị ràng buộc bởi quy định về lưu trữ trong nước, câu chuyện còn phụ thuộc vào việc vùng cloud đó nằm ở đâu. Nhờ pháp chế đọc kỹ chỗ này, đừng để đội kỹ thuật tự đoán.
Phương án lai thường là đáp án thực tế
Trong thực tế, cách tôi thấy hiệu quả nhất là chia theo mức nhạy cảm. Phần xử lý dữ liệu bị ràng buộc chạy trên model đặt nội bộ. Phần ít nhạy cảm, như soạn nội dung marketing hay tóm tắt tài liệu công khai, chạy trên cloud. Ở giữa là bước ẩn danh hóa: thay tên, số điện thoại, mã bệnh nhân bằng ký hiệu trước khi gửi đi.
Cách này đòi hỏi một lớp điều phối, và lớp đó có thể sai. Nếu bước ẩn danh hóa bỏ sót một số điện thoại, bạn vừa đẩy dữ liệu thật ra ngoài. Vì vậy cần kiểm thử bước này nghiêm túc, chứ đừng coi nó là phép màu.
| Tiêu chí | On-premise | Cloud |
|---|---|---|
| Kiểm soát dữ liệu | Cao | Phụ thuộc hợp đồng và cấu hình |
| Chi phí ban đầu | Lớn | Nhỏ |
| Chi phí khi dùng nhiều, ổn định | Thường có lợi về dài hạn | Có thể tăng nhanh |
| Gánh nặng vận hành | Nặng | Nhẹ |
| Tốc độ thử nghiệm | Chậm | Nhanh |
Vấn đề tiếng Việt khiến câu chuyện phức tạp hơn
Model mở có sẵn thường mạnh tiếng Anh, còn tiếng Việt thì có vấn đề riêng: dấu thanh, từ địa phương, cách viết tắt của dân văn phòng, thuật ngữ chuyên ngành như y khoa hay dược. Muốn model hiểu đúng lĩnh vực của mình, bạn thường phải finetune LLM trên dữ liệu nội bộ. Và đây chính là chỗ chuyện on-premise trở nên quan trọng: dữ liệu dùng để finetune lại là loại nhạy cảm nhất, vì nó phản ánh đúng cách doanh nghiệp làm việc.
AIVISION là đơn vị AI tại Việt Nam, huấn luyện LLM trên cụm 24x NVIDIA H200 và 8x NVIDIA B300, đã phát hành model speech-to-text E1.0 và model LLM L1.0 cho tiếng Việt, đồng thời làm training và finetune cho các lĩnh vực như healthcare, dược. Chúng tôi biết rõ nhu cầu giữ dữ liệu ở lại với khách hàng, nên mục tiêu của chúng tôi là trao đổi cụ thể từng trường hợp thay vì áp một mô hình triển khai cho tất cả. Bạn có thể xem thêm về hướng làm của AIVISION trên website.
Năm câu hỏi nên hỏi trước khi quyết
- Dữ liệu nào bị luật hoặc hợp đồng ràng buộc nơi lưu trữ, và nó chiếm bao nhiêu phần trăm tổng dữ liệu?
- Lượng truy vấn mỗi ngày là bao nhiêu, và có ổn định không?
- Ai sẽ trực khi hệ thống gặp sự cố ngoài giờ?
- Nếu dữ liệu lộ, thiệt hại lớn đến mức nào, về pháp lý lẫn uy tín?
- Bạn có cần finetune trên dữ liệu nội bộ không, và dữ liệu đó có được phép rời khỏi mạng không?
Nếu trả lời xong mà thấy phần lớn dữ liệu nằm ở nhóm bị ràng buộc, lượng dùng đều và bạn có hoặc sẵn sàng thuê đội vận hành, on-premise đáng được cân nhắc nghiêm túc. Nếu bạn chỉ mới thử nghiệm và dữ liệu phần lớn là công khai, bắt đầu bằng cloud rồi chuyển dần cũng không phải điều đáng xấu hổ.
Một lời khuyên cuối cho đội kỹ thuật: đừng chọn hạ tầng trước khi có một bài toán cụ thể và vài trăm mẫu dữ liệu thật để chạy thử. Nhiều quyết định đắt tiền trong ngành này được đưa ra khi chưa ai đo được model chạy chậm hay nhanh trên đúng dữ liệu của mình.