Chi phí ẩn của điện toán đám mây
Dịch tự động từ tiếng Ý · đọc bản gốc
Chương 5 — Chi phí ẩn của điện toán đám mây
Câu chuyện phổ biến trong năm năm qua là điện toán đám mây tiết kiệm chi phí, có khả năng mở rộng và đơn giản. Điều này hoàn toàn đúng với nhiều khối lượng công việc. Nhưng với các ứng dụng RAG (Retrieval-Augmented Generation) của doanh nghiệp, ngày càng thường xuyên, điều đó không đúng. Và thời điểm bạn nhận ra điều đó thường là vào cuối quý đầu tiên, khi hóa đơn đến.
Hãy xem xét hạng mục bị đánh giá thấp nhất trong chi phí: API của các mô hình thị giác. Khi một công ty đưa kho ảnh của mình vào một RAG hiện đại, mỗi ảnh cần phải được "mô tả" bởi một mô hình đa phương thức để trích xuất nội dung, đối tượng, ngữ cảnh, bất kỳ văn bản nào chồng lên, tâm trạng, bố cục. Một nhà cung cấp mô hình lớn của châu Âu — vẫn chưa được công bố tên — đã cung cấp vào năm 2025 một mô hình xuất sắc thuộc họ Qwen với 32 tỷ tham số, với mức giá hấp dẫn cho mỗi hình ảnh. Vấn đề, chỉ được phát hiện trong thực tế và sau nhiều tháng sản xuất: khi chịu tải, nhà cung cấp đã cắt ngắn các phản hồi. Không phải lúc nào cũng vậy, không theo cách dự đoán được, không khi có đội ngũ kiểm thử trước mặt: một cách ngẫu nhiên. Một trên mười ảnh, đôi khi một trên năm ảnh, sẽ trả về một JSON bị cắt đôi, phân tích cú pháp kém, với siêu dữ liệu không đầy đủ hoặc null. Thời gian tăng vọt từ mười giây lên hai trăm giây cho mỗi hình ảnh, không có quy luật. Hóa đơn thử lại — bởi vì các lần thử lại phải trả tiền, mỗi lần gọi, ngay cả khi máy chủ cắt ngắn — cao hơn dự kiến. Cơ sở dữ liệu không đồng nhất: một số ảnh rất giàu siêu dữ liệu, những ảnh khác bị cắt xén. Và nhóm không thể tái tạo vấn đề trong môi trường kiểm thử, vì trong kiểm thử tải thấp và mọi thứ đều hoạt động.
Giải pháp đến trong ba phần: một lời nhắc ngắn gọn hơn (các câu trả lời ngắn hơn ít bị cắt xén hơn), một logic thử lại thông minh (nếu câu trả lời mất hơn năm mươi giây và trả về trống, hãy thử lại ngay lập tức) và — khi khối lượng đủ lớn — khả năng bỏ qua hoàn toàn đám mây và chạy mô hình thị giác trên GPU cục bộ, chậm hơn nhưng xác định. Kiến trúc phù hợp, từ kinh nghiệm này, không phải là "luôn đám mây" cũng không phải là "luôn cục bộ". Đó là "chọn cho mỗi lần gọi, dựa trên những gì cần thiết vào thời điểm đó".
Sau đó là chương về các truy vấn. Mỗi tìm kiếm của người dùng, trong một RAG bản địa đám mây cổ điển, sẽ kích hoạt một loạt các cuộc gọi API trả phí. Một cho việc nhúng câu hỏi. Một cho việc phân loại ý định (câu hỏi thuộc loại gì?). Một cho việc xếp hạng lại tài liệu. Một cho việc tạo câu trả lời cuối cùng. Mỗi cái có giá một phần của xu. Đối với một dịch vụ nội bộ với năm mươi người dùng và mười nghìn truy vấn mỗi ngày — không phải là ít nhưng cũng không phải là một con số khổng lồ đối với một công ty trung bình — hóa đơn hàng tháng lên đến các con số thậm chí cả CFO khoan dung cũng phải nhăn mặt. Và sự tăng trưởng là tuyến tính: tăng gấp đôi số lượng người dùng, tăng gấp đôi hóa đơn. Không có lợi thế kinh tế theo quy mô về các token đã tiêu thụ, không phải cho bạn.
Còn một vấn đề mà năm 2025 vẫn còn tiềm ẩn, nhưng đến năm 2026 đã trở nên trung tâm: mỗi truy vấn riêng lẻ đều gửi các mảnh tài liệu doanh nghiệp — đôi khi bí mật, đôi khi được bảo mật bởi NDA, đôi khi tuân theo các quy định của ngành — đến máy chủ của nhà cung cấp bên ngoài, ở các khu vực pháp lý không phải lúc nào cũng trùng khớp với khu vực pháp lý của bạn, với các chính sách lưu giữ nhật ký không phải lúc nào cũng rõ ràng. Hơn một công ty châu Âu, trong mười tám tháng qua, chỉ phát hiện ra trong quá trình kiểm toán — thường do khách hàng lo ngại hoặc kiểm tra ISO — rằng hợp đồng, bảng giá và thông số kỹ thuật của họ đã được xử lý (và có khả năng được ghi lại cho mục đích "cải thiện dịch vụ") bởi cơ sở hạ tầng ngoài Liên minh châu Âu. Sự ngạc nhiên này thường tốn kém hơn số tiền tiết kiệm được từ việc tránh mua phần cứng cục bộ.
Giải pháp thay thế không phải là giáo điều đối lập. "Không đám mây, chỉ cục bộ" sai lầm không kém "luôn luôn đám mây". Giải pháp thay thế là một kiến trúc cho phép bạn lựa chọn, cho từng phần riêng lẻ của quy trình — nhúng, phân loại, xếp hạng lại, thị giác, tạo cuối cùng — liệu có nên sử dụng mô hình đám mây hay mô hình cục bộ, và có thể thay đổi ý kiến trong một ngày, chứ không phải một quý. Điều này đòi hỏi một thiết kế mà ở đó các nhà cung cấp có thể thay thế được, nơi không có phần nào bị gắn chặt với tên của một công ty cụ thể, nơi việc chuyển từ Regolo sang Ollama (hoặc ngược lại) chỉ là một dòng cấu hình, chứ không phải là viết lại. Và điều này, cho đến gần đây, còn hiếm gặp. Các khung phổ biến, bất chấp vẻ ngoài "không phụ thuộc vào nhà cung cấp", thực tế lại gắn bó chặt chẽ với ai đó.
Có nhận xét? Hãy viết cho chúng tôi
Tin nhắn này chỉ dành cho chúng tôi. Nếu bình luận của bạn hay, chúng tôi có thể đăng ở cuối bài viết sau khi xem xét.
Trong khi bạn nhập liệu, trình duyệt sẽ tự động giải một bài toán nhỏ – đây là cách chúng tôi chặn thư rác mà không cần dịch vụ bên ngoài hay yêu cầu bạn chọn đèn giao thông. Bạn không cần thực hiện thao tác nào và không có dữ liệu rời khỏi trang web này.