Ước tính chi phí token trước khi ký hợp đồng: đếm tiếng Việt bằng đúng tokenizer

Gõ “tiếng Việt tốn bao nhiêu token” lên mạng, kết quả bạn hay gặp nhất là: gấp 4,54 lần tiếng Anh. Tác giả một bài trên Viblo không tin và tự đo lại bằng 13 tokenizer trên cùng một bộ văn bản song ngữ. Với các tokenizer đời mới, mức chênh chỉ nằm trong khoảng 1,05x đến 2,14x.

PhoBERT thậm chí xuống 0,87x, tức là ít token hơn cả bản tiếng Anh. Nhưng PhoBERT không phải model API mà bạn có thể báo giá theo token cho khách, nên con số này chỉ cho thấy tokenizer quyết định nhiều đến đâu.

Khoảng cách giữa hai con số đó quyết định một bản báo giá. Nếu bạn là FDE và cầm hệ số 4,54 đi gặp khách, bạn có thể báo cao gấp ba, khách thấy đắt và không ký. Còn nếu đoán đại một hệ số thấp, dự án sẽ lỗ ngay tháng đầu chạy production.

Lo ngại này đã có từ lâu. Từ cuối 2022, trên diễn đàn của OpenAI đã có nhà phát triển Việt than rằng tokenizer đếm tiếng Việt ra quá nhiều token. Người đó viết rằng dự án mới bắt đầu mà chi phí đã trông quá cao. Các bước dưới đây giúp bạn biến nỗi lo đó thành một con số kiểm chứng được.

Chuẩn bị: một script, một file dữ liệu, một trang giá

Bạn sẽ có một script nhỏ làm hai việc: đếm token trên dữ liệu mẫu của khách, và tính chi phí theo tháng có tách input với output. Bạn cần Python, một file văn bản tiếng Việt thật của khách (hoặc văn bản bạn tự soạn giống với của khách) và trang giá của nhà cung cấp model mở trên một tab.

Trước hết cần nắm hai khái niệm. Token là những đơn vị dữ liệu nhỏ có được khi chia nhỏ một khối thông tin lớn hơn. Model xử lý văn bản theo token và nhà cung cấp tính tiền cũng theo token.

Quá trình chia văn bản thành token gọi là tokenization, nên cùng một câu tiếng Việt đi qua hai tokenizer khác nhau sẽ ra hai con số khác nhau.

Bước 1: lấy dữ liệu thật, và tách input khỏi output

Hãy xin khách một mẫu đúng loại dữ liệu sẽ đưa vào hệ thống, chẳng hạn 50 ticket hỗ trợ, 20 hợp đồng hoặc 100 câu hỏi của người dùng. Lưu phần sẽ gửi vào model ở một file và phần câu trả lời mong muốn ở một file khác.

Giá API thường tính riêng cho token đầu vào và token đầu ra, nên ngay từ đầu dữ liệu của bạn cũng phải chia theo hai phần đó.

Kiểm tra: mở hai file và xem có phải tiếng Việt có dấu, đúng định dạng khách dùng hay không. Nếu bạn lấy văn bản dịch máy, hoặc tiếng Việt không dấu, kết quả đếm sẽ không phản ánh thực tế.

Bước 2: đếm bằng đúng tokenizer của model

Đây là bước quan trọng nhất. Đoạn code dưới đây là bản rút gọn để minh họa, dùng thư viện tiktoken với hai encoding mà benchmark trên Viblo đã đo. Trước khi dùng thật, bạn nên kiểm tra cách cài đặt và tên hàm trong tài liệu của thư viện.

# Minh họa (rút gọn): đếm token với hai thế hệ tokenizer
import tiktoken

moi = tiktoken.get_encoding("o200k_base")   # GPT-4o / 4.1
cu  = tiktoken.get_encoding("cl100k_base")  # GPT-3.5 / 4

van_ban = open("input_mau.txt", encoding="utf-8").read()
print("o200k_base:", len(moi.encode(van_ban)))
print("cl100k_base:", len(cu.encode(van_ban)))

Kiểm tra: số token của cl100k_base phải cao hơn hẳn. Trong benchmark trên Viblo, o200k_base đo được 1,34x, còn cl100k_base là 2,14x. Theo cùng benchmark đó, chỉ cần chuyển sang thế hệ tokenizer mới là chi phí có thể giảm tới 37%, prompt giữ nguyên.

Hai encoding trên chỉ dành cho model của OpenAI. Nếu khách chọn model của nhà cung cấp khác, model đó dùng tokenizer riêng, nên hãy đếm bằng công cụ đếm token của chính nhà cung cấp ấy thay vì mượn o200k_base.

Một hệ số sai làm lệch cả bản báo giá ra sao?

Thử hình dung một tình huống giả định. Khách có lưu lượng mà nếu viết bằng tiếng Anh sẽ tương đương 10 triệu token input mỗi tháng. Nhân với hệ số 4,54 theo lời đồn, bạn sẽ báo 45,4 triệu token. Dùng 2,14 của cl100k_base thì ra 21,4 triệu, còn 1,34 của o200k_base chỉ là 13,4 triệu.

Như vậy cùng một khách, cùng một lượng công việc, mà con số ước tính chênh nhau hơn ba lần chỉ vì hệ số. Vì thế các hệ số trên chỉ nên dùng để giải thích cho khách hiểu. Khi tính tiền, hãy lấy số token bạn đếm được ở Bước 2 trên chính dữ liệu của họ.

Bạn cũng nên biết vì sao tiếng Việt không phải trường hợp tệ nhất. Một nghiên cứu trên arXiv năm 2025 so sánh nhiều ngôn ngữ và thấy những ngôn ngữ không dùng chữ Latin, hoặc có hình thái từ phức tạp, bị đội token nhiều hơn đáng kể. Tiếng Việt dùng chữ Latin.

Nhóm tác giả cũng cho rằng cách tính giá theo token làm khoảng chênh lệch giữa các ngôn ngữ càng lớn hơn.

Bước 3: dựng công thức chi phí theo tháng

Khi đã có số token trung bình cho mỗi request, bạn nhân với lưu lượng và áp giá. Đoạn dưới đây giả định giá được niêm yết theo 1 triệu token. Nếu trang giá dùng đơn vị khác, bạn đổi lại cho khớp.

def chi_phi_thang(so_request, tok_in, tok_out,
                  gia_in, gia_out, phu_troi=0.0):
    # gia_in, gia_out: giá cho 1 triệu token, tra vào ngày báo giá
    co_ban = so_request * (tok_in * gia_in + tok_out * gia_out) / 1_000_000
    return co_ban * (1 + phu_troi)

# phu_troi=0.10 nếu khách cần data residency (xem Bước 4)

Kiểm tra: chạy thử với tok_out bằng 0 và xem kết quả có đúng bằng phần input tính tay hay không. Sau đó tăng tok_out lên và xem phần output thay đổi tổng chi phí nhiều đến đâu. Đây là phần khách hay quên hỏi.

Bước 4: ghi rõ tầng giá, ngày tra giá và các khoản phụ trội

Bảng giá của OpenAI thay đổi nhanh và chia thành nhiều tầng: Standard, Batch, Flex, Fast. Ngay trong năm 2026 tầng ưu tiên đã đổi tên: Priority processing thành Fast mode từ ngày 30/7/2026. Một bản báo giá không ghi ngày và tầng giá sẽ không còn chính xác sau vài tháng.

Có một khoản rất dễ bị sót. Với các model phát hành từ ngày 5/3/2026, endpoint xử lý theo vùng (data residency) bị tính thêm 10%. Vì thế, hãy hỏi khách ngay từ đầu xem dữ liệu có phải nằm ở một vùng nhất định hay không; nếu có, bạn đặt phu_troi=0.10 trong công thức.

Những lỗi khiến bản báo giá bị trả lại

Lỗi đầu tiên là dùng một hệ số chung chung, dù là 4,54 hay bất kỳ con số nào đọc trên mạng, thay vì tự đếm. Lỗi thứ hai là gộp input với output thành một con số “token mỗi request”. Khi khách đổi yêu cầu, chẳng hạn muốn câu trả lời dài hơn, bạn sẽ không biết phải sửa phần nào.

Lỗi thứ ba là đếm bằng tokenizer của một model rồi lại báo giá cho model khác. Chênh lệch giữa 1,34x và 2,14x đủ để biến một dự án có lãi thành lỗ. Lỗi cuối cùng là đếm trên văn bản mẫu “sạch sẽ” do bạn tự viết, trong khi dữ liệu thật của khách có bảng biểu, mã sản phẩm và lỗi chính tả.

Khách sẽ hỏi “mỗi tháng tốn bao nhiêu” sớm hơn bạn nghĩ

Vì giá API tính theo token, câu hỏi “chạy cái này tốn bao nhiêu một tháng” sớm muộn gì cũng sẽ đến, nên bạn nên chuẩn bị câu trả lời từ trước. Một bảng gồm ba dòng là token input, token output và tầng giá kèm ngày tra sẽ thuyết phục hơn nhiều so với câu “khoảng vài trăm đô”.

Nếu bạn đang chuẩn bị chuyển sang vai trò FDE, hãy đưa kỹ năng này vào CV một cách cụ thể. Chẳng hạn: “đo token trên dữ liệu tiếng Việt của khách, chọn tokenizer thế hệ mới, giảm chi phí ước tính X%”, với X là con số bạn thực sự đo được.

Khi đọc job description, hãy để ý những dòng nhắc tới ước tính chi phí hay xác định phạm vi giải pháp; đó là chỗ bạn có thể đem ví dụ này ra kể trong buổi phỏng vấn.

Lời đồn 4,54 lần vẫn sẽ còn trên mạng. Nhưng ở bàn đàm phán, bên nào mang theo số token đo trên chính dữ liệu của khách thì bên đó có lý hơn.