Chi phí vận hành AI tạo sinh: cách tính tiền token, hạ tầng và tổng chi phí sở hữu

Chi phí vận hành một ứng dụng AI tạo sinh gồm bốn khối: tiền gọi mô hình (tính theo token đầu vào và đầu ra, hoặc tiền máy nếu tự lưu trữ), hạ tầng xung quanh (cơ sở dữ liệu vector, lưu trữ, giám sát), nhân sự vận hành và cải tiến, và chi phí kiểm soát chất lượng (kiểm thử, người duyệt, xử lý sự cố). Tiền token thường là khối dễ thấy nhất nhưng hiếm khi là khối lớn nhất trong năm đầu.

Công thức cốt lõi cho phần token: chi phí mỗi tháng = số lượt gọi × (token vào × đơn giá vào + token ra × đơn giá ra). Cái khó là ước đúng số token mỗi lượt, vì RAG, lịch sử hội thoại và tác tử nhiều bước làm token đầu vào phình gấp nhiều lần câu hỏi của người dùng. Bài này đi qua cách ước từng khối, một phép tính mẫu và các đòn bẩy giảm chi phí.

Token là gì và vì sao đầu vào, đầu ra tính giá khác nhau

Mô hình ngôn ngữ không đọc chữ mà đọc token — các mảnh từ do bộ tách từ của từng mô hình quy định. Một token tiếng Anh trung bình khoảng ba đến bốn ký tự; tiếng Việt có dấu thường tốn nhiều token hơn cho cùng lượng nội dung, tuỳ bộ tách từ. Vì vậy, khi ước tính chi phí cho ứng dụng tiếng Việt, đừng dùng tỷ lệ quy đổi của tiếng Anh; hãy lấy một mẫu văn bản thật của bạn, đếm token bằng công cụ của nhà cung cấp và tính hệ số riêng.

Hầu hết nhà cung cấp tính giá token đầu ra cao hơn đầu vào, thường gấp vài lần. Lý do kỹ thuật: đầu vào được xử lý song song trong một lượt, còn đầu ra phải sinh tuần tự từng token, mỗi token một lượt tính toán qua toàn bộ mô hình. Hệ quả thực tế là ứng dụng sinh văn bản dài (soạn báo cáo, viết bản nháp hợp đồng) có cấu trúc chi phí khác hẳn ứng dụng đọc nhiều trả lời ngắn (phân loại, trích xuất trường thông tin).

Một yếu tố nữa là chênh lệch giá giữa các hạng mô hình trong cùng một nhà cung cấp có thể lên tới hàng chục lần. Chọn đúng hạng mô hình cho từng việc thường là đòn bẩy chi phí lớn nhất, lớn hơn mọi kỹ thuật tối ưu khác.

Những thứ làm token đầu vào phình to

Câu hỏi của người dùng chỉ là phần nhỏ. Mỗi lượt gọi mô hình thực tế mang theo nhiều thành phần khác:

• Câu lệnh hệ thống: hướng dẫn vai trò, quy tắc, định dạng — thường vài trăm đến vài nghìn token, lặp lại ở mọi lượt.
• Ví dụ mẫu: mỗi ví dụ đầu vào–đầu ra đưa vào để mô hình bắt chước đều tốn token mỗi lần gọi.
• Đoạn tài liệu truy xuất (RAG): lấy năm đến mười đoạn, mỗi đoạn vài trăm token, là đã vài nghìn token một lượt.
• Lịch sử hội thoại: mỗi lượt mới gửi lại toàn bộ các lượt trước, nên chi phí cuộc trò chuyện dài tăng nhanh hơn tuyến tính theo số lượt.
• Mô tả công cụ và kết quả công cụ của tác tử: một tác tử chạy năm bước là năm lượt gọi, mỗi lượt mang theo kết quả của các bước trước.
• Token "suy nghĩ" của mô hình suy luận: một số mô hình sinh chuỗi suy luận nội bộ được tính như token đầu ra, có khi nhiều hơn câu trả lời cuối.

Vì vậy, trước khi chốt ngân sách, hãy ghi lại phân bố token thật của vài trăm lượt gọi trong giai đoạn thử nghiệm, tách theo từng thành phần trên. Ước tính trên giấy thường thấp hơn thực tế đáng kể, đặc biệt với hội thoại nhiều lượt và tác tử.

Phép tính mẫu cho một trợ lý tra cứu nội bộ

Ví dụ giả định, đơn giá quy ước theo "đơn vị tiền" để không phụ thuộc bảng giá cụ thể: đầu vào 1 đơn vị/triệu token, đầu ra 5 đơn vị/triệu token. 500 nhân viên, mỗi người trung bình 10 câu hỏi/ngày làm việc, 22 ngày/tháng.

Số lượt mỗi tháng: 500 × 10 × 22 = 110.000 lượt. Token đầu vào: 110.000 × 7.600 ≈ 836 triệu; đầu ra: 110.000 × 400 = 44 triệu. Chi phí token: 836 × 1 + 44 × 5 = 1.056 đơn vị/tháng. Đáng chú ý: câu hỏi của người dùng chỉ chiếm khoảng 1% token đầu vào, còn đầu vào chiếm khoảng 80% tổng chi phí dù đơn giá thấp hơn.

Đổi một tham số là thấy độ nhạy: giảm số đoạn truy xuất từ 8 xuống 4 cắt khoảng một phần tư chi phí; chuyển sang mô hình hạng rẻ hơn mười lần cho câu hỏi đơn giản có thể cắt phần lớn chi phí còn lại. Đây là lý do mọi quyết định thiết kế nên đi kèm một bảng tính như thế này.

Các khối chi phí ngoài token mà ngân sách hay bỏ sót

Nhân sự vận hành. Ai cập nhật tài liệu, sửa câu lệnh khi người dùng phàn nàn, theo dõi chất lượng, xử lý khi nhà cung cấp đổi phiên bản? Một ứng dụng chạy thật thường cần ít nhất một phần thời gian của một kỹ sư và một người nghiệp vụ, kéo dài vô thời hạn.

Kiểm thử và đánh giá. Mỗi lần đổi câu lệnh, đổi mô hình, đổi cách truy xuất đều phải chạy lại tập kiểm thử. Nếu dùng mô hình làm giám khảo chấm tự động, bản thân việc chấm cũng tốn token; nếu dùng người chấm thì tốn giờ công.

Người kiểm duyệt trong quy trình. Ứng dụng có bước người duyệt trước khi gửi khách thì chi phí thật gồm cả thời gian duyệt. Lợi ích phải tính trên chênh lệch thời gian, không phải giả định máy làm hết.

Hạ tầng xung quanh. Cơ sở dữ liệu vector, lưu trữ nhật ký, công cụ giám sát, cổng kiểm soát truy cập, môi trường thử nghiệm. Từng khoản nhỏ, cộng lại không nhỏ.

Chi phí sai sót. Câu trả lời sai dẫn tới khiếu nại, làm lại, rủi ro pháp lý. Khoản này khó định lượng nhưng nên có một dòng dự phòng và một chỉ số theo dõi.

Bảy đòn bẩy giảm chi phí, xếp theo hiệu quả thường gặp

Thứ tự dưới đây là kinh nghiệm phổ biến, bạn nên đo trên ứng dụng của mình:

1. Định tuyến theo độ khó: câu hỏi đơn giản đi mô hình nhỏ rẻ, chỉ ca khó mới chuyển lên mô hình lớn. Một bộ phân loại nhẹ đứng trước là đủ.
2. Bộ nhớ đệm câu lệnh (prompt caching): nhiều nhà cung cấp giảm giá mạnh cho phần đầu vào lặp lại giống hệt giữa các lượt, như câu lệnh hệ thống và ví dụ mẫu. Sắp phần cố định lên đầu để tận dụng.
3. Xử lý theo lô: việc không cần trả lời tức thì (phân loại phản hồi cuối ngày, tóm tắt hồ sơ qua đêm) thường được giá rẻ hơn ở chế độ lô.
4. Cắt gọn ngữ cảnh: truy xuất ít đoạn mà đúng hơn, tóm tắt lịch sử hội thoại dài thay vì gửi nguyên văn.
5. Giới hạn độ dài đầu ra: yêu cầu định dạng ngắn, có cấu trúc; đặt trần số token đầu ra.
6. Đệm câu trả lời cho câu hỏi lặp lại: câu hỏi phổ biến có thể trả lời từ kho đã duyệt, vừa rẻ vừa nhất quán.
7. Tinh chỉnh mô hình nhỏ cho việc khối lượng lớn: chỉ khi khối lượng đủ lớn để bù chi phí tinh chỉnh và vận hành.

Tối ưu chi phí không được đánh đổi chất lượng một cách mù quáng. Mỗi thay đổi phải chạy qua tập kiểm thử; tiết kiệm 30% token mà tỷ lệ trả lời đúng giảm vài điểm có thể là một giao dịch lỗ.

Gắn chi phí với giá trị: chỉ số chi phí trên một đơn vị công việc

Con số tổng chi phí tháng không nói được ứng dụng đáng hay không. Chỉ số hữu ích hơn là chi phí trên một đơn vị công việc hoàn thành: chi phí trên một yêu cầu khách hàng được giải quyết, trên một hồ sơ được trích xuất đúng, trên một bản nháp được chấp nhận không phải sửa nhiều. Chỉ số này tính cả token, hạ tầng phân bổ và thời gian người duyệt, rồi đặt cạnh chi phí làm cùng việc theo cách cũ.

Theo cách tiếp cận FinOps — thực hành quản trị chi phí đám mây theo hướng mỗi nhóm chịu trách nhiệm về chi phí mình tạo ra — nên gắn nhãn mỗi lượt gọi mô hình theo ứng dụng, bộ phận và tính năng. Khi đó báo cáo hằng tháng trả lời được câu "tính năng nào tốn tiền nhất và đem lại gì", thay vì một hoá đơn tổng không ai nhận.

Cuối cùng, đặt hạn mức và cảnh báo ở cả tầng tài khoản lẫn tầng ứng dụng. Một vòng lặp lỗi của tác tử, hoặc một kịch bản bị gọi tự động hàng loạt, có thể tiêu hết ngân sách tháng trong vài giờ. Hạn mức theo người dùng và theo ngày là lớp bảo vệ rẻ nhất.

Khi tự lưu trữ mô hình: tính theo giờ máy thay vì theo token

Nếu chạy mô hình trọng số mở trên máy chủ riêng hoặc máy thuê có GPU, đơn vị chi phí đổi từ token sang giờ máy. Câu hỏi then chốt là thông lượng: một máy phục vụ được bao nhiêu token mỗi giây ở độ trễ chấp nhận được, với độ dài ngữ cảnh thực tế của ứng dụng. Con số này phụ thuộc kích thước mô hình, mức lượng tử hoá, phần mềm phục vụ và mức độ gộp nhiều yêu cầu cùng lúc, nên phải đo thử chứ không lấy từ quảng cáo.

Từ thông lượng đo được, chi phí quy đổi trên mỗi triệu token bằng chi phí máy mỗi giờ chia cho số triệu token máy xử lý được mỗi giờ ở mức sử dụng thực tế. Chữ "thực tế" là mấu chốt: ứng dụng nội bộ thường bận vào giờ hành chính và gần như rảnh ban đêm, cuối tuần. Một máy chỉ dùng trung bình một phần ba công suất có chi phí quy đổi gấp ba lần con số tính ở công suất đầy.

Ngoài tiền máy còn có công kỹ sư dựng và giữ hệ thống, chi phí dự phòng khi máy hỏng, và chi phí cơ hội khi mô hình tự lưu trữ tụt hậu so với mô hình mới trên thị trường. Vì vậy so sánh công bằng giữa tự lưu trữ và API phải đặt cạnh nhau tổng chi phí sở hữu một năm, cùng chất lượng đầu ra đo trên cùng một tập kiểm thử.

Câu hỏi thường gặp

Tự lưu trữ mô hình có rẻ hơn gọi API không?

Chỉ rẻ hơn khi khối lượng đủ lớn và đều để máy chủ được dùng gần hết công suất. Máy chủ GPU tính tiền cả khi rảnh, cộng thêm công vận hành. Với khối lượng nhỏ hoặc dao động mạnh theo giờ, API thường rẻ hơn. Hãy tính điểm hoà vốn bằng phân bố lượt gọi thật trong vài tuần thử nghiệm.

Làm sao dự toán chi phí khi chưa biết người dùng sẽ dùng bao nhiêu?

Lập ba kịch bản thấp, trung bình, cao dựa trên số người dùng mục tiêu và tần suất giả định, rồi cập nhật sau hai đến bốn tuần thí điểm bằng số liệu thật. Đặt hạn mức cứng ở mức kịch bản cao để tránh bất ngờ, và xem lại dự toán mỗi tháng trong quý đầu.

Chi phí có giảm theo thời gian không?

Xu hướng nhiều năm qua là giá trên mỗi đơn vị năng lực mô hình giảm nhanh, nhưng doanh nghiệp thường dùng tiền tiết kiệm được để chuyển sang mô hình mạnh hơn hoặc mở thêm tính năng. Vì vậy đừng lập kế hoạch dựa trên giả định tổng chi phí tự giảm; hãy dựa trên chi phí trên đơn vị công việc.

Có nên tính chi phí AI vào ngân sách công nghệ hay ngân sách bộ phận sử dụng?

Cách bền vững là phân bổ về bộ phận sử dụng theo lượng dùng thực tế, còn phòng công nghệ giữ phần hạ tầng chung. Khi bộ phận thấy hoá đơn của mình, họ có động lực dùng đúng chỗ và đòi hỏi kết quả, thay vì coi AI là dịch vụ miễn phí.

Token tiếng Việt có thực sự đắt hơn tiếng Anh?

Với nhiều bộ tách từ, cùng một nội dung tiếng Việt có dấu cần nhiều token hơn tiếng Anh, nên chi phí và độ dài ngữ cảnh bị ảnh hưởng. Mức chênh khác nhau giữa các mô hình và đang thu hẹp ở các thế hệ mới. Cách duy nhất chắc chắn là đếm token trên mẫu văn bản thật của bạn với từng mô hình đang cân nhắc.