Chi phí gọi API mô hình ngôn ngữ phụ thuộc chủ yếu vào ba thứ: số token gửi vào, số token sinh ra, và đơn giá của mô hình bạn chọn; độ trễ thì phụ thuộc phần lớn vào độ dài câu trả lời và kích cỡ mô hình. Vì vậy bốn đòn bẩy hiệu quả nhất là: chọn mô hình vừa đủ cho từng việc, gửi vào ít hơn, bắt sinh ra ngắn hơn, và không gọi lại những gì đã có kết quả.
Bài này dành cho lập trình viên và trưởng nhóm sản phẩm sắp mở tính năng AI cho nhiều người dùng, hoặc vừa nhận hoá đơn tháng đầu cao hơn dự tính. Bài viết không nêu giá của hãng nào, vì bảng giá đổi thường xuyên; mọi con số là ví dụ giả định để minh hoạ cách tính. Bạn tra đơn giá hiện hành trên trang chính thức của nhà cung cấp mình dùng.
Tiền đi đâu trong một lần gọi
Phần lớn nhà cung cấp tính tiền theo token, chia hai loại: token đầu vào gồm câu lệnh hệ thống, lịch sử trò chuyện, tài liệu đính kèm, mô tả công cụ và câu hỏi; token đầu ra là những gì mô hình sinh. Đơn giá token đầu ra thường cao hơn đầu vào vài lần. Mô hình lớn đắt hơn mô hình nhỏ cùng hãng, có khi chênh nhau hàng chục lần.
Điều người mới hay bỏ sót là phần đầu vào lặp lại. Một trợ lý trò chuyện gửi lại toàn bộ lịch sử ở mỗi lượt, nên lượt thứ mười tốn đầu vào gấp nhiều lần lượt đầu. Một câu lệnh hệ thống dài hai nghìn token đi kèm mọi lần gọi; với trăm nghìn lượt mỗi tháng, chỉ riêng phần đó đã là hai trăm triệu token đầu vào. Trợ lý RAG đưa thêm vài đoạn tài liệu mỗi lần; trợ lý có công cụ gửi lại danh sách công cụ ở mỗi vòng.
Với mô hình suy luận, có thêm một khoản nữa: token suy nghĩ nội bộ trước khi trả lời, thường tính như token đầu ra dù người dùng không thấy. Nếu bạn dùng loại mô hình này, kiểm phản hồi API để biết số token suy nghĩ được báo ở đâu, và xem hãng có cho đặt giới hạn mức suy nghĩ không.
Ước tính chi phí tháng trước khi ra mắt
Bảng dưới là cách tính bằng biến, đi kèm số ví dụ giả định. Thay đơn giá thật của hãng bạn và số liệu dự kiến của sản phẩm vào là ra con số để trình bày với người quyết định ngân sách.
| Đại lượng | Cách xác định | Ví dụ giả định |
|---|---|---|
| Số lượt gọi mỗi tháng | Số người dùng hoạt động nhân số lần dùng trung bình | 2.000 người nhân 30 lần, ra 60.000 lượt |
| Token đầu vào mỗi lượt | Đo thật trên mẫu câu hỏi, cộng câu lệnh hệ thống, tài liệu, lịch sử | 2.500 token |
| Token đầu ra mỗi lượt | Đo thật, không lấy giới hạn tối đa | 400 token |
| Đơn giá vào, đơn giá ra | Trang giá hiện hành của hãng, theo mô hình đã chọn | Gọi là a và b đồng cho mỗi triệu token |
| Chi phí tháng | Lượt nhân (token vào nhân a cộng token ra nhân b) chia một triệu | 60.000 nhân (2.500a cộng 400b) chia một triệu |
| Hệ số an toàn | Nhân thêm cho thử lại, người dùng dùng nhiều hơn dự kiến | Nhân 1,5 đến 2 cho tháng đầu |
Hai dòng token phải lấy từ đo thật, không phải đoán. Chạy bộ câu hỏi kiểm qua đúng câu lệnh sản phẩm, đọc số token phản hồi báo về, lấy trung bình và cả mức cao. Rồi nhìn vào phép tính: thường bạn sẽ thấy đầu vào chiếm phần lớn, và đó là nơi tối ưu đáng làm trước.
Chọn mô hình theo việc, không dùng một mô hình cho tất cả
Việc phân loại, trích xuất, gắn nhãn. Thường mô hình nhỏ làm tốt, nhanh và rẻ hơn nhiều. Chạy bộ kiểm trên mô hình nhỏ trước; chỉ nâng lên khi tỉ lệ đạt không đủ.
Việc viết, tóm tắt cho người đọc. Mô hình cỡ vừa thường là điểm cân bằng. Người dùng nhận ra chênh lệch chất lượng văn rõ hơn chênh lệch trong việc phân loại.
Việc suy luận nhiều bước, phân tích phức tạp. Mô hình lớn hoặc mô hình suy luận, nhưng chỉ cho đúng những lượt cần. Có thể dùng mô hình nhỏ để định tuyến: đọc câu hỏi, quyết định câu này đơn giản hay phức tạp, rồi chuyển sang mô hình tương ứng.
Đặt tên mô hình trong cấu hình theo từng tính năng. Mỗi tính năng một dòng cấu hình, để đổi mô hình cho một tính năng mà không đụng tính năng khác, và để so chi phí theo tính năng trong nhật ký.
Quyết định bằng bộ kiểm, không bằng cảm giác. Chạy cùng bộ câu hỏi qua hai mô hình, đặt kết quả cạnh nhau không ghi tên mô hình, nhờ người trong nghề chọn bản tốt hơn. Nếu họ không phân biệt được, mô hình rẻ hơn là lựa chọn đúng cho việc đó.
Lưu đệm: hai loại khác nhau, đừng nhầm
Loại thứ nhất là lưu đệm kết quả ở phía bạn. Nếu cùng một đầu vào sẽ cho kết quả dùng lại được, ví dụ tóm tắt một bài viết cố định hay mô tả một sản phẩm, hãy lưu kết quả với khoá là mã băm của toàn bộ đầu vào và tên mô hình. Trong Python, khoá có thể tính bằng hashlib.sha256((ten_mo_hinh + cau_lenh).encode("utf-8")).hexdigest(). Lần sau gặp đúng khoá đó thì trả kết quả cũ, không gọi API. Nhớ đặt thời hạn và xoá khi dữ liệu gốc thay đổi.
Loại thứ hai là lưu đệm phần đầu câu lệnh ở phía nhà cung cấp, có hãng gọi là prompt caching. Phần đầu câu lệnh lặp lại y nguyên giữa các lần gọi, như câu lệnh hệ thống dài, tài liệu cố định, danh sách công cụ, được hãng giữ lại một thời gian và tính phí thấp hơn khi dùng lại, đồng thời thường xử lý nhanh hơn. Cách bật, độ dài tối thiểu, thời gian giữ và mức giảm khác nhau giữa các hãng, có hãng tự động, có hãng phải đánh dấu; tra tài liệu hiện hành.
Để tận dụng loại thứ hai, sắp xếp câu lệnh theo thứ tự từ ít thay đổi tới hay thay đổi: phần cố định ở đầu, dữ liệu theo người dùng và câu hỏi ở cuối. Chèn ngày giờ hiện tại hay tên người dùng vào ngay dòng đầu câu lệnh hệ thống là phá lưu đệm cho mọi lần gọi.
Trả về dần (streaming) để người dùng thấy nhanh hơn
Độ trễ người dùng cảm nhận không phải tổng thời gian sinh câu trả lời, mà là thời gian tới chữ đầu tiên. Một câu trả lời mất tám giây để sinh xong nhưng chữ đầu xuất hiện sau một giây, chạy dần trên màn hình, cho cảm giác nhanh hơn hẳn so với vòng xoay tám giây rồi hiện cả khối.
Phần lớn API hỗ trợ trả về dần qua kết nối giữ mở, thường theo chuẩn server-sent events. Máy chủ của bạn nhận từng mẩu và chuyển tiếp xuống giao diện; ở trình duyệt có thể đọc bằng fetch với luồng của phản hồi. Cần để ý cấu hình của máy chủ web và lớp proxy đứng trước: nhiều cấu hình mặc định gom đệm phản hồi, khiến luồng bị giữ lại rồi trả một lần, mất hết tác dụng.
Trả về dần không hợp mọi việc. Với đầu ra JSON cần kiểm hợp lệ trước khi dùng, bạn vẫn phải chờ đủ rồi mới kiểm. Với câu trả lời cần lọc nội dung trước khi hiện, cũng phải cân nhắc chuyện người dùng đã thấy phần đầu trước khi bộ lọc kịp chặn.
Rút gọn đầu vào và chuyển việc không gấp sang chạy nền
Sau khi chọn đúng mô hình và bật lưu đệm, phần còn lại là cắt những gì không cần gửi:
- Cắt lịch sử trò chuyện: chỉ giữ vài lượt gần nhất, phần cũ hơn tóm tắt thành vài câu, hoặc bỏ nếu không liên quan.
- Gửi đúng phần dữ liệu cần: hỏi về một đơn hàng thì gửi đơn đó, không gửi cả lịch sử mua hai năm.
- Rút gọn câu lệnh hệ thống: đọc lại, xoá quy tắc trùng, quy tắc không còn tác dụng theo bộ kiểm.
- Giới hạn độ dài đầu ra và dặn độ dài mong muốn trong câu lệnh; người dùng điện thoại hiếm khi cần câu trả lời năm trăm chữ.
- Chạy nền việc không cần ngay: tóm tắt phản hồi khách cuối ngày, gắn nhãn kho bài viết. Một số hãng có chế độ xử lý theo lô với mức phí thấp hơn đổi lấy thời gian trả kết quả lâu hơn; kiểm điều kiện hiện hành.
- Theo dõi theo tính năng: ghi token và chi phí ước tính theo từng tính năng, từng ngày, để biết chỗ nào đang tốn và phát hiện bất thường sớm.
Mỗi thay đổi ở trên đều có thể làm giảm chất lượng. Chạy lại bộ câu hỏi kiểm sau mỗi lần tối ưu; tiết kiệm một nửa chi phí mà tỉ lệ trả lời đúng tụt mạnh thì chưa chắc đã là lời.
Ví dụ giả định: một trợ lý hỗ trợ cắt gần nửa chi phí
Một phần mềm kế toán nhỏ ở Đà Nẵng có trợ lý hướng dẫn sử dụng. Nhật ký tháng đầu cho thấy mỗi lượt trung bình khoảng bốn nghìn token đầu vào, trong đó câu lệnh hệ thống kèm toàn bộ tài liệu hướng dẫn chiếm phần lớn, lịch sử trò chuyện chiếm phần còn lại; đầu ra trung bình ba trăm token. Tất cả chạy trên mô hình lớn nhất của hãng.
Nhóm làm ba việc trong hai tuần. Thứ nhất, sắp lại câu lệnh để phần tài liệu cố định nằm đầu và bật lưu đệm phía nhà cung cấp, phần đầu vào lặp lại được tính ở mức thấp hơn. Thứ hai, chỉ giữ bốn lượt trò chuyện gần nhất. Thứ ba, chạy bộ ba mươi câu hỏi kiểm trên mô hình cỡ vừa, thấy tỉ lệ đạt ngang nhau với câu hỏi thao tác, nên chuyển loại câu này sang mô hình vừa và chỉ giữ mô hình lớn cho câu hỏi về nghiệp vụ kế toán phức tạp.
Kết quả trong ví dụ giả định này là chi phí mỗi lượt giảm khoảng một nửa, thời gian tới chữ đầu tiên cũng ngắn hơn, mà bộ kiểm không tụt. Điều đáng học không phải con số, vì con số của bạn sẽ khác, mà là thứ tự: đo trước, tìm phần chiếm nhiều nhất, sửa phần đó, kiểm lại chất lượng.
Câu hỏi thường gặp
Làm sao biết một đoạn văn bản tiếng Việt tốn bao nhiêu token?
Cách chắc nhất là gửi thử và đọc số token API báo về, hoặc dùng công cụ đếm token mà hãng cung cấp. Tiếng Việt có dấu thường tốn nhiều token hơn tiếng Anh cùng độ dài ý, và mỗi mô hình tách token một khác, nên đừng dùng hệ số chung.
Có nên tự chạy mô hình mã nguồn mở để tiết kiệm không?
Chỉ khi lưu lượng đủ lớn và đều, và nhóm có người vận hành được máy có card đồ hoạ. Chi phí phần cứng, điện, người trực và thời gian tối ưu thường bị đánh giá thấp. Với sản phẩm mới, gọi API thường rẻ hơn khi tính đủ mọi khoản.
Lưu đệm kết quả có rủi ro gì?
Rủi ro lớn nhất là trả kết quả của người này cho người khác khi khoá lưu đệm không chứa đủ thông tin phân biệt. Nếu đầu vào có dữ liệu riêng của người dùng, khoá phải chứa phần đó, hoặc đừng lưu đệm dùng chung. Rủi ro thứ hai là trả kết quả cũ sau khi dữ liệu gốc đã đổi.
Giới hạn độ dài đầu ra quá thấp thì sao?
Câu trả lời bị cắt ngang giữa câu, và với JSON thì hỏng hẳn. Kiểm lý do dừng trong phản hồi; nếu dừng vì hết độ dài, ghi nhật ký và xử lý riêng. Đặt giới hạn cao hơn độ dài cần một khoảng, rồi dặn độ dài mong muốn trong câu lệnh.
Có nên đặt hạn mức chi tiêu cứng ở tài khoản nhà cung cấp không?
Nên, ở mức cao hơn dự kiến một khoảng an toàn, cùng với cảnh báo ở các mốc thấp hơn. Hạn mức cứng chặn được sự cố khoá bị lộ hay vòng lặp lỗi, nhưng khi chạm thì tính năng ngừng, nên phải có thông báo lỗi tử tế ở giao diện.
Độ trễ bao nhiêu là chấp nhận được?
Tuỳ việc. Gợi ý trong ô nhập cần gần như tức thì; trả lời trò chuyện chấp nhận vài giây nếu chữ chạy dần; báo cáo chạy nền có thể vài phút. Đo thời gian tới chữ đầu tiên và tổng thời gian riêng, và đặt mục tiêu theo từng tính năng.