GLM API không phải sản phẩm "trả một lần rồi dùng cả tháng" mà tính phí theo mức sử dụng thực tế. Nhiều đội lần đầu xem hóa đơn thường thắc mắc: số lượng yêu cầu không nhiều, vì sao chi phí lại cao hơn dự kiến? Nguyên nhân thường không phải đơn giá, mà là đầu vào quá dài, đầu ra không được kiểm soát, bộ nhớ đệm không trúng, hoặc thử lại sau lỗi lại sinh thêm một lần nội dung.
Bài viết này không liệt kê đơn giá cụ thể, vì giá thay đổi theo mô hình, bậc ngữ cảnh và chương trình khuyến mãi. Chúng tôi làm rõ cấu trúc tính phí, chi phí phát sinh từ đâu, cách ước tính và giảm chi phí, cuối cùng là danh sách kiểm soát có thể thực thi. Để xem giá hiện tại, vui lòng tham khảo giá mô hình trên trang và trang giá của Zhipu.
Ghi chú: Zhipu, GLM và BigModel là nhãn hiệu của các chủ sở hữu quyền tương ứng. Bài viết chỉ nhằm mục đích giải thích kỹ thuật và không đại diện cho Zhipu. Quy tắc tính phí và giá có thể thay đổi; vui lòng đối chiếu tài liệu gốc và trang hóa đơn trước khi đặt hàng.
1. Đơn vị tính phí cơ bản
Mô hình văn bản lấy token làm đơn vị cơ bản. Tài liệu của Zhipu đưa ra quy đổi kinh nghiệm khoảng 1 token tương ứng 1,6 ký tự Hán, nhưng số lượng thực tế phụ thuộc vào bộ tách từ và nội dung văn bản; cuối cùng lấy trường usage do API trả về làm chuẩn. Nói cách khác, ước tính chỉ dùng để lập ngân sách, không thể thay thế hóa đơn.
Không phải mô hình nào cũng tính phí theo token. Tạo hình ảnh, tạo video, tổng hợp giọng nói, nhân bản giọng nói, âm thanh hình ảnh thời gian thực, phân tích kho tri thức… có thể tính theo lần, theo phút, theo ký tự hoặc theo trang. Khi làm sản phẩm đa phương thức, hãy xác nhận đơn vị tính phí trước, rồi mới bàn đến đơn giá.
2. Vì sao đầu vào và đầu ra tính riêng
Một yêu cầu thường gồm token đầu vào và token đầu ra, hai phần được định giá riêng và đầu ra thường đắt hơn. Mô hình ngữ cảnh dài còn có thể chia bậc theo độ dài đầu vào, ví dụ lấy 32K làm mốc, vượt qua mốc sẽ vào bậc cao hơn; một số mô hình cũng chia bậc theo độ dài đầu ra. Điều này có nghĩa "cùng một mô hình" nhưng cách dùng khác nhau có thể có chi phí đơn vị khác nhau.
Yếu tố ảnh hưởng chi phí chủ yếu không phải số yêu cầu, mà là ngữ cảnh mang theo trong mỗi yêu cầu. Nhét toàn bộ kho tri thức, toàn bộ lịch sử hội thoại và hàng chục định nghĩa công cụ vào câu lệnh thì đầu vào sẽ tăng rất nhanh. Lãng phí phổ biến hơn nằm ở đầu ra: không đặt độ dài đầu ra tối đa, mô hình nói liên tục, chi phí đương nhiên tăng.
| Khoản chi phí | Cách tính | Tình huống thường gặp | Cách kiểm soát |
|---|---|---|---|
| Token đầu vào | Tính theo đầu vào không trúng bộ nhớ đệm | Câu lệnh dài, lịch sử nhiều lượt, định nghĩa công cụ | Tinh gọn ngữ cảnh, tóm tắt |
| Token đầu ra | Tính theo nội dung sinh ra | Viết văn bản dài, sinh mã nguồn | Đặt độ dài đầu ra tối đa |
| Trúng bộ nhớ đệm | Phần trúng tính theo giá chiết khấu | Câu lệnh hệ thống cố định, tiền tố kho tri thức | Giữ tiền tố ổn định |
| Bậc ngữ cảnh dài | Đơn giá thay đổi sau khi vượt ngưỡng | Tài liệu dài, phân tích kho mã | Chia nhỏ, tóm tắt, tải theo nhu cầu |
| Thử lại và thất bại | Phần đã sinh có thể vẫn bị tính phí | Hết thời gian, ngắt luồng, gửi trùng | Idempotent, lùi thời gian, loại trùng |
| Đa phương thức và công cụ | Tính theo lần, phút, trang… | Tạo ảnh, giọng nói, tìm kiếm, phân tích | Hạch toán riêng, giới hạn gọi |
3. Trúng bộ nhớ đệm: tiết kiệm phần tiền tố lặp lại
Zhipu cung cấp khả năng bộ nhớ đệm ngữ cảnh, tài liệu chủ yếu giới thiệu bộ nhớ đệm ngầm: hệ thống tự nhận diện nội dung lặp lại, không cần đánh dấu điểm đệm thủ công. Nó phù hợp với tình huống "câu lệnh hệ thống cố định + kho tri thức cố định + câu hỏi thay đổi".
Muốn tăng tỷ lệ trúng, cần ít nhất ba điều kiện: tiền tố lặp đủ dài, tài liệu khuyến nghị từ 500 token trở lên; nội dung tiền tố hoàn toàn nhất quán, chỉ thêm một dấu cách cũng có thể khiến không trúng; bộ nhớ đệm được tạo bất đồng bộ, sau yêu cầu đầu tiên nên chờ một chút rồi gửi yêu cầu tiếp theo. Có thể xem tình trạng trúng qua usage.prompt_tokens_details.cached_tokens.
Bộ nhớ đệm không phải vạn năng. Câu lệnh ngắn, nội dung thay đổi mỗi lần, kho tri thức sửa thường xuyên đều khó trúng. Việc lưu bộ nhớ đệm có tính phí riêng hay không, mức chiết khấu bao nhiêu, lấy trang giá của nhà cung cấp làm chuẩn. Hãy coi bộ nhớ đệm là hạng mục tối ưu, không phải tiền đề mặc định của mô hình chi phí.
4. Ngữ cảnh dài, xử lý theo lô và đa phương thức
Ngữ cảnh dài rất hữu ích nhưng cũng là nơi dễ vượt ngân sách nhất. Khi xử lý hợp đồng, luận văn, kho mã, hãy hỏi ba câu trước: có thực sự cần đưa toàn bộ nội dung vào một lần không? Có thể truy xuất trước rồi ghép lại không? Có thể xử lý theo đoạn rồi tổng hợp không? Nhiều tác vụ chỉ cần "truy xuất + tóm tắt" là xong, chi phí thấp hơn nhiều so với nhét cả kho vào.
Với tác vụ theo lô, có thể quan tâm giao diện Batch. Tài liệu cho biết các mô hình được hỗ trợ thường có chiết khấu khi dùng Batch, phù hợp với gán nhãn ngoại tuyến, tóm tắt hàng loạt, làm sạch dữ liệu… những việc không yêu cầu trả về tức thời. Cái giá phải trả là độ trễ cao hơn và việc điều phối tác vụ phức tạp hơn, phù hợp với đội đã có hàng đợi và kiểm tra kết quả.
Năng lực đa phương thức phải hạch toán riêng. Tạo ảnh tính theo số ảnh, hiểu ảnh thường tính theo token; tổng hợp giọng nói tính theo ký tự hoặc phút, phân tích kho tri thức tính theo trang. Trộn các chi phí này vào ngân sách văn bản thì cuối tháng chắc chắn không khớp sổ.
5. Thử lại, ngắt luồng và chi phí ẩn
Yêu cầu thất bại không chắc miễn phí. Nếu máy chủ đã sinh một phần nội dung rồi mới hết thời gian, phần sử dụng đó có thể vẫn bị tính phí; khi kết nối luồng bị ngắt, phần đã sinh cũng có thể vào hóa đơn. Vì vậy chiến lược thử lại cần tiết chế: chỉ thử lại với giới hạn tần suất, lỗi 5xx và hết thời gian mạng, dùng lùi thời gian theo cấp số nhân và đặt số lần tối đa.
Một chi phí ẩn khác là gửi trùng. Người dùng bấm nút liên tục, giao diện tự gửi lại khi hết thời gian, hàng đợi tiêu thụ trùng, đều tạo thêm yêu cầu. Dùng mã yêu cầu để giữ tính idempotent, hoặc loại trùng ở tầng cổng, hiệu quả hơn nhiều so với đối soát sau.
Còn phải tính chi phí kỹ thuật: ghi log, giám sát, đánh giá, kiểm tra thủ công. Phí gọi mô hình chỉ là một phần tổng chi phí; đừng vì tiết kiệm một chút phí gọi mà bỏ ra gấp nhiều lần nhân lực để vá thủ công.
6. Cách ước tính ngân sách hàng tháng
Ước tính gồm bốn bước: thống kê lượng gọi hàng tháng, ước tính đầu vào đầu ra trung bình, ước lượng tỷ lệ trúng bộ nhớ đệm, áp đơn giá hiện tại. Nếu muốn quản lý số dư và mức sử dụng của nhiều mô hình ở một nơi, có thể đăng ký ZSQH AI Gateway để xem thống nhất; giá cụ thể vẫn lấy trang giá mô hình làm chuẩn. Đoạn mã dưới đây chỉ là khung tính toán, đơn giá hãy đọc từ trang giá của nhà cung cấp rồi điền vào.
# Mô hình ngân sách: mọi đơn giá đều là giá trị giữ chỗ, hãy thay bằng giá hiện hành
monthly_calls = 300_000
avg_input_tokens = 1_200
avg_output_tokens = 300
cache_hit_rate = 0.35
input_rate = 0.0 # Đơn giá đầu vào, xem trang giá của nhà cung cấp
output_rate = 0.0 # Đơn giá đầu ra
cache_rate = 0.0 # Đơn giá phần trúng bộ nhớ đệm
uncached_input = avg_input_tokens * (1 - cache_hit_rate)
cached_input = avg_input_tokens * cache_hit_rate
per_call = (
uncached_input * input_rate
+ cached_input * cache_rate
+ avg_output_tokens * output_rate
)
print(f"Chi phí tháng ước tính: {monthly_calls * per_call:.2f}")
Khi ước tính nên để dư. Đầu vào thực tế của nghiệp vụ mới thường dài hơn thiết kế, thử lại và thất bại cũng làm tăng mức sử dụng. Nên chạy lưu lượng nhỏ trong hai tuần, thay giả định bằng dữ liệu usage thật rồi mới quyết định ngân sách.
7. Danh sách kiểm soát ngân sách
- Đặt hạn mức riêng cho từng môi trường và từng dịch vụ.
- Đặt độ dài đầu ra tối đa và thời gian chờ cho mọi yêu cầu.
- Cố định thứ tự câu lệnh hệ thống để tăng tỷ lệ trúng bộ nhớ đệm.
- Tài liệu dài nên truy xuất, tóm tắt trước rồi mới quyết định có đưa vào ngữ cảnh dài hay không.
- Chỉ thử lại với lỗi có thể thử lại, đặt lùi thời gian và giới hạn số lần.
- Xem mức sử dụng mỗi ngày, xem hóa đơn mỗi tuần, phát hiện tăng bất thường ngay lập tức.
- Tác vụ ngoại tuyến ưu tiên Batch, tác vụ thời gian thực mới dùng giao diện trực tuyến.
8. Câu hỏi thường gặp (FAQ)
1. GLM API cụ thể giá bao nhiêu?
Giá thay đổi theo mô hình, bậc ngữ cảnh và chương trình khuyến mãi; bài viết không đưa con số cố định. Vui lòng xem giá mô hình trên trang hoặc trang giá của Zhipu, và lấy hóa đơn trong bảng điều khiển làm chuẩn.
2. Trúng bộ nhớ đệm được tính phí thế nào?
Phần trúng bộ nhớ đệm tính theo giá chiết khấu, phần đầu vào không trúng tính theo giá đầu vào tiêu chuẩn. Mức chiết khấu và phí lưu trữ cụ thể lấy trang giá của nhà cung cấp làm chuẩn; lượng trúng có thể xem từ trường usage.
3. Yêu cầu thất bại có bị trừ tiền không?
Phụ thuộc vào giai đoạn thất bại. Nếu đã sinh một phần nội dung, có thể bị tính theo mức sử dụng thực tế; lỗi tham số, lỗi xác thực thường không phát sinh phí sinh nội dung. Lấy chi tiết hóa đơn làm chuẩn.
4. Ngữ cảnh dài có chắc chắn đắt hơn không?
Thường đắt hơn. Nhiều mô hình chia bậc theo độ dài đầu vào, sau ngưỡng thì đơn giá tăng. Những tác vụ có thể giải quyết bằng chia nhỏ hoặc truy xuất thì không cần ép dùng ngữ cảnh dài.
5. Làm sao nhanh chóng giảm chi phí hiện tại?
Trước tiên làm ba việc: giới hạn độ dài đầu ra tối đa, nén câu lệnh hệ thống, tăng tỷ lệ trúng bộ nhớ đệm. Ba việc này thường có hiệu quả nhanh hơn đổi mô hình và cũng dễ kiểm soát hơn.
