Tiếng Việt dùng AI "tốn Tokens" hơn tiếng Anh

Mình đang xây một hệ thống context knowledge base cho doanh nghiệp, nên tối ưu token là bài toán phải giải rất kỹ. Dùng ngôn ngữ gì để tốn ít token, một prompt nên dài bao nhiêu, mỗi token mang lại hiệu quả bao nhiêu, cái gì cũng phải đo và tính. Hôm nay mình ôn lại câu đầu và câu cuối trong ba câu đó.

Token là đơn vị các hãng tính tiền, cũng là đơn vị đo sức chứa của model. "Công ty trách nhiệm hữu hạn" tốn 7 token trên GPT-5 và 17 token trên Claude. Bản tiếng Anh "Limited liability company" tốn 3 và 6.

Chuyện này được đo từ năm 2023 ^[1]. Cuối tháng 9 vừa rồi, CLEAR, một nhóm nghiên cứu về công bằng ngôn ngữ trong AI, đo lại trên khoảng 200 ngôn ngữ và gọi nó là thuế tokenizer ^[2]. Cùng một nội dung, ngôn ngữ đắt nhất tốn gấp từ 2,7 tới 17 lần ngôn ngữ rẻ nhất, tuỳ model. Rest of World đưa tin ngày 26/10 ^[3]. Cả hai bài gần như không nói gì về tiếng Việt, nghiên cứu gốc chỉ nhắc tới nó trong đúng một ô của bảng.

Ai làm chatbot, tóm tắt văn bản hay knowledge base bằng tiếng Việt đều dính: hoá đơn cao hơn, và cùng một model đọc được ít nội dung hơn trong một lượt. Mình lấy dữ liệu thô của CLEAR ra tính riêng cho tiếng Việt ^[4]: trên 997 câu dịch chuyên nghiệp CLEAR dùng để đo, Claude cắt tiếng Việt ra gấp 1,83 lần số token tiếng Anh.

Phần chênh đó bao nhiêu là do tiếng Việt thật sự dài hơn, bao nhiêu là do tokenizer, cái bộ cắt chữ? Token nhiều hơn có làm model trả lời kém đi không thì là chuyện khác, mình chưa đo.

Token và tokenizer

Model ngôn ngữ chỉ nhận số. Trước khi vào model, văn bản đi qua tokenizer, một bộ cắt chữ thành từng mảnh gọi là token, mỗi mảnh ứng với một số trong một từ điển. Token có thể là một từ, nửa từ, một dấu câu, hay một mẩu lẻ không đọc được.

Từ điển này chốt trước khi train model. Train xong thì gần như đóng băng, vì mọi thứ model học được đều gắn với từng dòng của nó.

Hãng tính tiền theo số mảnh, mảnh to hay nhỏ cũng một giá. Context window, số token model đọc được trong một lượt, cũng đếm theo mảnh. Văn bản bị cắt càng vụn thì càng đắt và càng chiếm chỗ.

Vậy sao không cắt thành từng chữ cái cho đều? Vì model tốn một bước tính cho mỗi token. Mảnh càng to thì cùng số bước đọc được càng nhiều chữ. Người làm tokenizer vì thế muốn mảnh to nhất có thể, và đó là bài toán nén.

Cách dựng từ điển phổ biến là BPE, byte pair encoding, một thuật toán nén Philip Gage mô tả năm 1994 ^[5]. Đầu vào của nó là byte, đơn vị lưu trữ cơ bản của máy tính. UTF-8, cách máy tính lưu chữ, dùng 1 byte cho chữ a và 3 byte cho chữ ệ. BPE đếm xem cặp mảnh nào đứng cạnh nhau nhiều nhất, gộp thành một mảnh mới, rồi lặp lại. Tokenizer của GPT-2 train theo cách này trên byte, lặp tới khi từ điển đủ 50.257 dòng ^[6].

Nếu lúc train ít gặp tiếng Việt, 3 byte của chữ ệ không bao giờ được gộp, và chữ này tốn 3 token. GPT-2 làm vậy với "Công ty trách nhiệm hữu hạn".

CLEAR viết rằng tokenizer học bằng cách nén những dãy ký tự hay gặp, và phần lớn chỉ thấy tiếng Anh cùng vài ngôn ngữ nhiều dữ liệu.

Thuế nằm ở chỗ tokenizer khác file zip. File zip vừa nén vừa dựng từ điển từ chính nội dung đang nén, còn từ điển của tokenizer đóng băng từ lúc train, đưa tiếng gì vào nó vẫn dùng từ điển cũ. Và zip tính theo bit (8 bit là 1 byte), còn token tính theo số mảnh, mảnh vỡ một byte cũng tròn một token.

Đo lượng thông tin bằng bộ nén

Tiếng Việt vốn dài hơn mà, tốn hơn là đúng rồi?

Bộ 997 câu kia tên là FLORES-200 ^[7]. Bản tiếng Anh có 126.191 ký tự, bản tiếng Việt có 132.988 ký tự, dài hơn 5%. Đếm byte thì dài hơn 39%. Vậy dài hơn 5% hay 39%?

Cả hai đều không phải lượng thông tin. Chữ ệ tốn 3 byte, nhưng thấy byte đầu là gần như đoán được byte thứ hai. Mình lấy luôn một bộ nén làm thước.

PPMd, một biến thể của PPM, là bộ nén đoán byte kế tiếp từ chính những gì vừa đọc trong file ^[8]. Nó không mang theo từ điển nào, nên không có định kiến gì với tiếng Việt hay tiếng Anh. Đoán càng trúng thì tốn càng ít bit, nên kích thước sau nén bám theo lượng thông tin trong file.

Nén hai file, tiếng Anh ra 41.678 byte, tiếng Việt ra 41.871 byte, chênh 0,5%. Số này còn tuỳ cách chỉnh: đổi số byte PPMd nhìn lại để đoán, hay cho nó đọc trước vài MB Wikipedia cùng tiếng, tỉ lệ dao động từ 0,98 tới 1,10. Tiếng Việt có nhỉnh hơn thì cũng trong khoảng 10%.

Lệch nhất là Brotli, bộ nén các trang web hay dùng, ở 1,22. Nó là bộ duy nhất ở đây mang theo một từ điển soạn sẵn, 122.784 byte ghi cứng trong chuẩn ^[9]. zstd và xz không mang từ điển nào, cho khoảng 1,09. Mình xáo chữ cái của hai file bằng ROT13, đổi a thành n, b thành o, để từ điển hết khớp mà thống kê giữ nguyên, rồi nén lại: Brotli về đúng 1,09. Chưa cần tới tokenizer, riêng một từ điển đóng băng đã nới khoảng cách thêm 11%.

Đổi từ điển

Nếu thuế do từ điển thì đổi từ điển phải thấy ngay. Mình train BPE tối đa 200.000 mảnh trên 60 MB Wikipedia, ba lần: toàn tiếng Anh, toàn tiếng Việt, và nửa nọ nửa kia. Model thật train trên dữ liệu riêng lớn hơn nhiều, nên số này chỉ để ước chừng. Rồi mình đếm lại 997 câu kia.

Từ điển tiếng Anh làm tiếng Việt tốn gấp 3,42 lần tiếng Anh. Sang từ điển tiếng Việt, số token tiếng Anh tăng 17%: từ điển thiên vị thứ nó thấy lúc train. Nhưng ngay trên từ điển của chính mình, tiếng Việt vẫn tốn gấp 1,12 lần tiếng Anh.

Từ điển trộn cho 1,30. Mình đếm lại 997 câu qua API của 8 model mới nhất tháng 11/2026: thấp nhất là Qwen 3.8, đúng 1,30, cao nhất là Kimi K3.1 với 2,78. Qwen 3.8 dùng chung tokenizer với Qwen 3.6, GPT-6.1 với GPT-5. Lấy 1,30 của từ điển nửa Anh nửa Việt làm mốc, phần trên mốc chủ yếu là từ điển và cách cắt riêng của từng hãng, và đó là lựa chọn của người làm tokenizer: cùng nhà Meta, Llama 2 là 2,85, Llama 4 và Muse Spark là 1,32.

Dấu cách

Từ điển trộn rồi mà vẫn 1,30. Phần này từ đâu ra? Phần lớn không do tiếng Việt, vì PPMd vừa đo hai bản chênh nhau cùng lắm 10%.

Trong tiktoken, thư viện đếm token của OpenAI ^[10], một regex, tức một dòng quy tắc mô tả thế nào là một từ, cắt văn bản thành từng từ trước khi tra từ điển, rồi BPE chỉ gộp bên trong từng từ. Cách cắt này có từ GPT-2 ^[6]. Dòng comment ngay trên regex ghi rằng có thể phân bổ token giữa các ngôn ngữ hiệu quả hơn.

Regex cắt ở dấu cách, nên BPE không bao giờ gộp được qua dấu cách. Mình quét từ điển của GPT-2, cl100k của GPT-4 và o200k của GPT-5, rồi từ điển công khai của Qwen, DeepSeek và GLM: không mảnh nào chứa dấu cách giữa hai chữ cái.

Tiếng Anh viết liền cả từ, "science" là một cụm. Tiếng Việt viết cách từng âm tiết, "khoa học" là hai cụm. Với tokenizer cắt kiểu này, "khoa học" có phổ biến tới đâu cũng tối thiểu 2 token. Trên 997 câu, tiếng Anh có 20.954 cụm, tiếng Việt có 29.193 cụm, gấp 1,39 lần.

Thử bỏ regex đi, train lại trên cùng dữ liệu trộn, cho BPE gộp thoải mái. Tỉ lệ còn 1,09, ngang mức PPMd đo được khi đã đọc trước Wikipedia. Regex còn cắt cả ở dấu câu và chữ số, nhưng chỉ giữ phần cắt ở dấu cách thì tỉ lệ vẫn 1,33.

Khoảng 70% phần chênh biến mất mà không cần thêm dòng từ điển nào. Cái regex cắt theo dấu cách kiểu tiếng Anh đó là một khoản phí mà từ điển nào cũng không gỡ được.

SuperBPE, một cách train tokenizer công bố năm 2025, cho các mảnh đã học gộp tiếp qua dấu cách ^[11]. Model 8 tỉ tham số train bằng tokenizer này cao hơn bản BPE thường trung bình 4 điểm trên 30 bài kiểm tra, thắng 25 bài.

Họ chỉ train và đo trên tiếng Anh. Tiếng Việt thì từ nào hai âm tiết trở lên cũng bị dấu cách chặn giữa chừng: trong thí nghiệm của mình, bỏ regex làm tiếng Anh bớt 20% token, tiếng Việt bớt 33%. PhoBERT, model riêng cho tiếng Việt VinAI công bố năm 2020, đã nối các âm tiết của một từ bằng dấu gạch dưới trước khi cắt ^[12], để model hiểu tiếng Việt tốt hơn.

NFD và viết không dấu

Phần dấu cách thì người dùng không làm gì được. Hai cái bẫy này thì được.

Chữ ệ lưu được hai kiểu. NFC là một ký tự dựng sẵn. NFD là chữ e, cộng dấu nặng, cộng dấu mũ, 3 ký tự xếp chồng ^[13]. Nhìn trên màn hình giống hệt nhau.

Từ điển chỉ học dạng dựng sẵn, nên 997 câu tiếng Việt dạng NFD trên GPT-5 tốn 96.408 token so với 37.806, gấp 2,55 lần cho cùng những chữ đó. API đếm token của OpenAI không đổi NFD về NFC trước khi đếm. Claude và Qwen 3.6 đổi về NFC trước nên số giữ nguyên. Năm 2004, một người phụ trách Unicode ở Apple viết rằng hệ thống file là nguồn NFD lớn nhất trên Mac, và vài bàn phím, như tiếng Việt, gõ ra chữ tách một phần ^[14]. Chữ lấy từ tên file hay dữ liệu cũ nên chạy qua unicodedata.normalize("NFC", text) trước khi gửi.

Bẫy thứ hai là mẹo viết không dấu cho đỡ token.

Mẹo này đúng với cl100k, giảm từ 62.913 xuống 46.196. Từ điển đã học chữ có dấu thì ngược lại: GPT-5 tăng 6,5%, Qwen 3.6 tăng 17%, vì chữ không dấu giờ mới là chữ lạ. Claude giảm 9%, DeepSeek V4 giảm 16%, đổi lại model phải tự đoán "ban" là bàn, bạn hay bán.

Hoá đơn

Lấy PPMd làm thước, chia số bit thông tin cho số token Claude cắt ra, thì một token chở 8,2 bit tiếng Anh nhưng chỉ chở 4,5 bit tiếng Việt, và hãng tính cùng một giá cho hai token đó.

Fable 5.1 của Anthropic, cùng tokenizer với Opus 5.5, giá tháng 11/2026 là 10 USD mỗi triệu token vào và 50 USD mỗi triệu token ra ^[15]. Nạp 1 triệu ký tự tài liệu tiếng Việt vào context tốn khoảng 5,6 USD, cùng nội dung bằng tiếng Anh khoảng 3,1 USD. Câu trả lời tiếng Việt cũng tốn gấp 1,83 lần, mà token ra đắt gấp 5 lần token vào. Cùng 1 triệu token context, tiếng Việt chứa được khoảng 55% nội dung so với tiếng Anh.

Claude cắt nhỏ với gần như mọi ngôn ngữ, trang giá ghi tokenizer từ Claude 4.7 tạo nhiều hơn khoảng 30% token. So giữa các hãng còn phải tính giá từng token. Tỉ lệ trong cùng một model mới trả lời được câu dùng ngôn ngữ nào.

Cả hoá đơn không tăng đủ 1,83 lần. Prompt của coding agent phần lớn là code và system prompt tiếng Anh, thuế chỉ đánh trên phần tiếng Việt. Chatbot chăm sóc khách hàng hay tóm tắt hợp đồng tiếng Việt thì dính gần hết.

CLEAR đề nghị các hãng công bố tỉ lệ giữa ngôn ngữ đắt nhất và rẻ nhất, và chuẩn hoá giá theo ký tự hoặc theo ngôn ngữ. Phần từ điển thì đã có cách gỡ: Liquid AI mở rộng từ điển của một model đã train xong từ khoảng 65.000 lên 128.000 mảnh rồi train thêm, số token tiếng Việt giảm khoảng 2,6 lần so với tokenizer gốc ^[16]. Phần dấu cách thì SuperBPE và BoundlessBPE ^[17] đã cho mảnh gộp qua dấu cách, nhưng mới đo trên tiếng Anh.

Dịch "Công ty trách nhiệm hữu hạn" sang tiếng Anh tiết kiệm 11 token trên Claude. Trên Claude, lưu cả knowledge base bằng tiếng Anh thì rẻ gần gấp đôi. Nhưng hợp đồng tiếng Việt qua tay dịch máy rồi có còn đúng nghĩa pháp lý không thì token không đo được, và đó là thứ mình phải đo tiếp.

Đào sâu: regex của tiktoken

Đây là regex mà o200k, tokenizer của GPT-5, dùng để cắt văn bản trước khi tra từ điển ^[10]:

[^\r\n\p{L}\p{N}]?[\p{Lu}\p{Lt}\p{Lm}\p{Lo}\p{M}]*[\p{Ll}\p{Lm}\p{Lo}\p{M}]+(?i:'s|'t|'re|'ve|'m|'ll|'d)?|[^\r\n\p{L}\p{N}]?[\p{Lu}\p{Lt}\p{Lm}\p{Lo}\p{M}]+[\p{Ll}\p{Lm}\p{Lo}\p{M}]*(?i:'s|'t|'re|'ve|'m|'ll|'d)?|\p{N}{1,3}| ?[^\s\p{L}\p{N}]+[\r\n/]*|\s*[\r\n]+|\s+(?!\S)|\s+

Mỗi nhánh nối bằng dấu | là một kiểu cụm. Hai nhánh đầu bắt một từ: tối đa một ký tự không phải chữ hay số đứng trước, thường là dấu cách, rồi một dãy chữ cái, cuối cùng là đuôi 's, 't, 're của tiếng Anh viết cứng ngay trong regex. \p{...} là cách regex gọi một nhóm ký tự Unicode: \p{Lu}, \p{Ll} là chữ hoa, chữ thường, \p{M} là các dấu đứng rời như dấu nặng, dấu mũ của dạng NFD, để chữ thường có dấu dạng NFD không bị cắt khỏi từ. Dấu cách chỉ được đứng ở đầu cụm, nên không cụm nào chứa dấu cách ở giữa.

Chạy regex này trên "Công ty trách nhiệm hữu hạn" ra 6 cụm: Công, ␣ty, ␣trách, ␣nhiệm, ␣hữu, ␣hạn, nên từ điển to tới đâu cũng không xuống dưới 6 token. Bản tiếng Anh ra 3 cụm.

Bỏ regex, từ điển trộn mình train cắt cụm này còn 3 token, bằng tiếng Anh. Mảnh giữa ␣trách␣nhiệm␣ ôm luôn dấu cách mở đầu từ sau. BPE thấy cặp nào hay gặp thì gộp trước, nên cho gộp qua dấu cách ngay từ đầu thì nó học ra nhiều mảnh vắt ngang ranh giới từ như vậy. Nhóm SuperBPE gặp đúng chuyện này và chia việc train làm hai giai đoạn: giai đoạn đầu giữ regex cho tới khi từ điển có 180.000 mảnh, giai đoạn sau bỏ phần cắt ở dấu cách, vẫn tách số, để 20.000 mảnh cuối gộp được qua dấu cách, mỗi mảnh tối đa 4 từ ^[11]. Chuyển giai đoạn sớm, ở 80.000 mảnh, thì bớt tới 33% token nhưng model kém hơn. Bản chuyển ở 180.000 cho model tốt nhất của họ, bớt khoảng 27% token so với BPE thường.

Bình