Phiên bản: Tiếng Việt · English

Có một câu truyền miệng trong cộng đồng dev Việt dùng LLM: “viết prompt bằng tiếng Việt tốn hơn gấp đôi token so với English, nên tốt hơn cứ English cho rẻ.” Chú ý: community không nói “đúng gấp đôi”, họ nói “hơn 2x” (và thực tế benchmark công khai cho thấy Vietnamese multiplier khoảng 2.8x, tức vượt 2x rõ rệt). Nghe có lý, vì tokenizer train trên corpus English-dominant, tiếng Việt có dấu thì BPE phải cắt nhỏ hơn. Logic chặt chẽ.

Nhưng khi tôi scan toàn bộ session Claude Code cá nhân (5626 user messages, 555 sessions) rồi đo lại, kết quả đi ngược trực giác: style mix tiếng Việt không dấu + English technical terms của tôi còn hiệu quả hơn pure English trên messages dài (tiết kiệm 39% token/char), chiếm tới 49% tổng lượng prompt, và là default của 71% sessions. Claim “x2 token” chỉ đúng với pure tiếng Việt có dấu, nhưng style đó chỉ chiếm 2.9% usage thực tế.

Bài này walkthrough benchmark đó: dataset, methodology, kết quả, tại sao, và recommendation cho ai đang phân vân nên optimize token ở đâu.

Claim “x2 token” đến từ đâu

Cơ sở kỹ thuật của claim này là thật. BPE (Byte Pair Encoding) tokenizer mà cả OpenAI GPT-4 (cl100k_base) và Claude dùng đều được train trên corpus internet English-dominant. Hệ quả:

  • Từ tiếng Việt có dấu bị split nhiều token hơn (vì chuỗi byte UTF-8 của dấu không match sẵn trong vocabulary).
  • Cùng một ý nghĩa, message tiếng Việt có dấu thường tốn 2.5-3x token so với English tương đương.

Benchmark công khai cho thấy Vietnamese multiplier dao động 2.8x trên cùng câu test, Thai 3.7x, Tamil/Bengali 6-7x. Các ngôn ngữ Latin gần English như Spanish, Polish quanh 1.5-2x.

Nhưng có một điểm paper và blog ít để ý: không ai đo trên usage thực tế. Các benchmark đó dịch cùng một câu sang nhiều thứ tiếng rồi count token. Dev Việt dùng LLM hàng ngày có viết như vậy không? Tôi ngờ là không. Tôi nhìn thấy mình mix ngôn ngữ, bỏ dấu khi gõ nhanh, nhét đầy technical terms English vào câu tiếng Việt. Chưa ai đo cái đó.

Có một finding khác từ paper Lost in the Mix (arxiv 2506.14012) còn thú vị hơn: khi researcher embed English tokens vào non-English matrix language (Arabic, German, French, Chinese), LLM hiểu tốt hơn so với pure non-English. Hiệu ứng ngược lại (nhét foreign vào English) thì làm giảm performance. Tức là mix-lang theo hướng “VN matrix + English technical” là pattern mà model thực sự thích, không phải workaround.

Benchmark pipeline

Dataset của tôi là toàn bộ ~/.claude/projects/. Claude Code lưu mỗi session dưới dạng JSONL, mỗi dòng là một event (user message, assistant message, tool result, system reminder). Tôi scan toàn bộ, filter ra user messages, classify theo language style, tokenize text, và aggregate metrics theo style.

Token benchmark pipeline Four-stage pipeline: ingest JSONL sessions, filter user messages, classify language style, tokenize, compute metrics. # benchmark pipeline :: raw sessions -> classified metrics [1/4] INGEST source: jsonl files: 1811 events: full log user role [2/4] FILTER drop: tool_result drop: system_msg keep: 5626 msgs rules [3/4] CLASSIFY signal: diacritic signal: markers output: 5 styles cl100k [4/4] METRICS m1: tok/char m2: out/prompt m3: dist % + tokenizer: tiktoken cl100k_base (GPT-4); Claude dùng tokenizer riêng, BPE behavior tương đương ±5% + classifier rule-based: detect diacritics + match against VN marker list (~180 từ) + EN tech list (~140 từ) + 5 styles: pure_english, mixed_no_diacritic, vn_no_diacritic, mixed_diacritic, pure_vn_diacritic

Classifier logic đơn giản: với mỗi message, check xem có ký tự tiếng Việt có dấu không, count số marker words của tiếng Việt không dấu (toi, la, cua, khong, de, lam, …), và số English technical terms (api, deploy, config, agent, …). Từ đó phân 5 nhóm.

Tokenizer dùng cl100k_base của GPT-4, không phải Claude. Claude tokenizer của Anthropic không public full, nhưng BPE behavior đủ gần để so sánh relative (±5%). Key là comparing giữa các style trong cùng tokenizer, không phải tính absolute cost.

Kết quả 1: Distribution, tôi viết thế nào?

Breakdown theo style trên 5626 user messages:

StyleN messagesShareAvg chars/msg
mixed_no_diacritic276349.1%1167
pure_english101818.1%120
vn_no_diacritic99417.7%50
mixed_diacritic3736.6%1417
pure_vn_diacritic1632.9%86
unknown (slash commands, ảnh)3155.6%5

Gần một nửa messages là mixed_no_diacritic, tức tiếng Việt không dấu kèm English technical terms. Đây là main working mode. Pure English chỉ 18%, và pure tiếng Việt có dấu (style “đắt nhất” theo claim x2) chỉ 2.9%, hầu như không dùng trong thực tế coding.

Điểm đáng chú ý: mixed_no_diacritic có average 1167 ký tự/message (messages substantive, nhiều context), còn pure_english chỉ 120 chars/message (toàn short commands). Hai mode khác nhau về bản chất, không chỉ ngôn ngữ.

Kết quả 2: Length-matched tok/char

Đây là bảng quan trọng nhất. Metric: tokens per character, càng thấp càng efficient. So sánh trong cùng bucket độ dài để bỏ length bias (longer text giúp tokenizer BPE merge nhiều hơn, không phải do ngôn ngữ).

Length (chars)pure_englishmixed_no_diavn_no_diapure_vn_dia
0-500.2620.2980.3250.425
50-1500.3830.2900.3080.392
150-5000.3180.2970.3040.376
500-15000.3380.3090.300-
1500-50000.4480.275-0.476
5000+0.2550.266--

Reading the table:

  • Messages rất ngắn (<50 chars): pure_english thắng (0.262) vs mixed_no_dia (0.298). Gap = 14%. Reason: short commands không có prose để BPE merge, mỗi language đơn thuần đấu nhau ở byte-level.
  • Medium & long (50-5000 chars): mixed_no_diacritic thắng pure English ở mọi bucket. Ở bucket 1500-5000 chars (prompt substantive), mixed efficient hơn English 39% (0.275 vs 0.448).
  • pure_vn_diacritic luôn worst, dao động 0.376-0.476, tệ hơn pure English 1.2-1.5x. Đây là style “x2 token” của claim gốc. Nhưng nhớ rằng style này chỉ 2.9% usage.

Tại sao mixed beat English trên prompt dài? Mấy lý do:

  1. Technical terms English tokenize siêu dense. config, deploy, endpoint, file paths, tên lệnh: BPE đã merge sẵn thành 1-2 token/từ. Prompt càng nặng technical thì English càng efficient.
  2. VN connector words ngắn merge cheap. la, cua, de, tu, cho, con, thi: thường 1 token/từ sau BPE. Không có cost phạt.
  3. Long coherent text cho BPE merges tốt hơn. Chuỗi dài có nhiều opportunity cho tokenizer nhận pattern và merge. Short commands không có benefit này.
  4. Pure English của dev Việt thường là short commands có path/ID lạ, nên fragment nhiều. Cùng 50 chars English thuần prose sẽ efficient hơn 50 chars mixed “show me config X-Y-Z-internal-id”.

Kết quả 3: Session-level signal-to-cost

Mỗi session gán “dominant style” nếu >60% messages cùng style. Đo trung bình prompt/output tokens per session + ratio:

Dominant styleSessionsAvg prompt tok/sessAvg out tok/sessOut÷Prompt
mixed_no_diacritic240125913881.1x
vn_no_diacritic415296318.6x
pure_english31502304.6x
mixed_diacritic1339512933.3x
pure_vn_diacritic54190722.2x

Metric Out÷Prompt hay: nó cho biết assistant phải tự generate bao nhiêu token để trả lời so với token user đã viết.

  • 1.0x: dialogue cân bằng, user cung cấp đủ context, assistant trả lời có target. Efficient.
  • 20x+: user viết 1 câu ngắn, assistant phải mò ý, giải thích dài. Inefficient về “signal per turn”.

mixed_no_diacritic là style duy nhất có ratio ≈ 1.0x, và cũng là dominant style của 71% sessions (240/340 có dominant). Đây là pattern làm việc thực tế: substantive prompt kèm context, assistant trả lời có mục tiêu.

Ví dụ thực (fabricated, giữ nguyên pattern)

Cùng intent “migrate một S3 bucket”, 5 style khác nhau:

[pure_english]                    ~14 tokens
Migrate dev bucket to prod region.

[mixed_no_diacritic]              ~42 tokens
Spawn 2 agents de migrate dev bucket sang prod region,
giu nguyen lifecycle rule, report lai status dang bang.

[vn_no_diacritic]                 ~16 tokens
Di migrate bucket dev sang prod giup.

[mixed_diacritic]                 ~56 tokens
Migrate bucket dev sang prod region giúp, giữ nguyên
lifecycle rule và báo lại trạng thái dạng bảng nhé.

[pure_vn_diacritic]               ~50 tokens
Bạn có thể giúp tôi di chuyển bucket từ môi trường
phát triển sang sản xuất không?

Quan sát:

  • pure_vn_diacritic 50 tokens cho ~35 chars ý nghĩa. Thực sự đắt, và mơ hồ (không có technical term, model phải đoán “môi trường phát triển” = dev).
  • pure_english 14 tokens, rẻ nhất nhưng ngắn, thiếu context phụ (“lifecycle rule”, “report bảng”).
  • mixed_no_diacritic 42 tokens, dài gấp 3x English nhưng chứa tất cả requirement (agents, lifecycle rule, output format). Assistant có thể làm 1 lượt, không cần clarify.

Tính per-unit-of-intent, mixed rẻ hơn: 1 round-trip hoàn chỉnh ~42 tokens, vs English 14 tokens + clarify rounds thêm.

Tại sao mix-lang là sweet spot

Gộp mấy signal từ data + research:

  1. Tokenizer level: technical English terms đã merge sẵn; VN connector không dấu cũng merge cheap. Hai thành phần bù nhau.
  2. Semantic level: technical concept (deploy, migrate, endpoint, agent) giữ nguyên ngữ nghĩa khi dùng English, không loss to translation. VN cho context/intent, native precision.
  3. Research level: embedding English vào non-English matrix language improve LLM comprehension (Lost in the Mix, Mohamed et al. 2025, confirmed với Arabic/German/French/Chinese). Không test riêng Vietnamese nhưng VN cùng nhóm analytic language nên extrapolate được.
  4. Training distribution level: LLM hiện đại pre-train trên web corpus khổng lồ. Common Crawl (300B+ pages, seed của hầu hết pretrain dataset hiện đại) và các variant multilingual như mC4 (Xue et al. 2020, 101 ngôn ngữ, 6.3 nghìn tỉ token, dùng cho mT5). Content dev-heavy trong đó tự nhiên code-switch: Stack Overflow answers với comment native + code English, GitHub issues của dev Á-Âu, blog technical của non-English speaker, forum như diendan.net, r/LocalLlama, Qiita, tất cả mix native language + English technical terms. Model pre-train đã “nhìn” pattern này hàng triệu lần. Mix-lang của dev Việt không phải workaround, là surface form gần với training distribution nhất. Lưu ý methodology: không có paper public nào đo tỷ lệ chính xác code-switching trong training corpus của Claude/GPT (các lab không publish composition chi tiết), nhưng các thành phần nguồn công khai (Common Crawl, OSCAR, mC4, code repos) thì minh bạch và empirically mixed.
  5. Cognitive level: dev Việt nghĩ bằng tiếng Việt, gõ nhanh hơn. Round-trip giảm, clarify ít hơn.

Zoom out: token là phương tiện, không phải mục tiêu

Bài này đang đi sâu vào benchmark per-character, per-message, per-session. Dễ lạc trong số. Câu hỏi anchor cần giữ: mở LLM lên đầu tiên là để làm gì?

Không phải để viết prompt rẻ nhất có thể. Là để hoàn thành việc nhanh hơn và đúng hơn so với tự làm tay. Token là phương tiện, matter chỉ trong 2 case:

  1. API pay-per-token volume cao: mỗi 1M input token thành tiền thật, ROI optimize rõ ràng.
  2. Context window sắp đầy: prompt hiện tại đẩy conversation quá limit, cần compress để fit.

Ngoài 2 case trên:

  • Subscription flat-rate (Claude Pro/Max, Codex Pro, GLM Coding Plan, các coding plan khác): token không ra tiền trực tiếp. Optimize token ở đây = optimize metric không liên quan đến cost thực. Quota có giới hạn, nhưng giới hạn đó rộng hơn nhiều so với usage typical của 1 dev.
  • Usage cá nhân thường ngày: output quality + số round-trip mới là cost thực. Prompt 300 token ra đúng ý trong 1 lượt rẻ hơn prompt 50 token phải clarify 3 lần (cộng dồn context duplicate + thời gian anh + 3x model call).

Có một failure mode phổ biến: dev optimize prompt length, viết tắt, bỏ context, model đoán sai, clarify rounds tăng, tổng token cao hơn prompt “dài” từ đầu. Anh đang trade off 1 dimension (prompt size) đổi lấy dimension khác (round-trip count) mà thường không aware.

Tóm: goal là kết quả, token là kế toán. Đừng để kế toán lái goal. Optimize token khi nó thực sự là bottleneck, không phải reflex default.

Recommendation: leverage ở đâu?

Dựa trên cùng data set, phân tier theo impact thực tế:

TierActionSaving
1. StructuralMatch model to task (Haiku/Sonnet/Opus)40-80%
Delegate heavy reads to subagents40-70%
One topic per session + /clear20-40%
/compact trước khi context bloat30-50%
2. ScopingPoint to specific files25-50%
.claudeignore + trim CLAUDE.md15-30%
CLI commands vs MCP (output scoped)5-20%
3. ProseStructured output (JSON)30-50%
System prompt tightening15-25%
Switch VN → English prompt~13% trên short msg

Language choice ở Tier 3 và trên prompt ngắn. Structural ở Tier 1 và 2-5x leverage. Ưu tiên sai thứ tự là thua. Một người viết English hoàn hảo nhưng load cả repo vào context sẽ tốn hơn người mix-lang mà scope đúng file.

Cho ai đang debate

Nếu bạn đang nghe “tiếng Việt đắt hơn gấp đôi, cứ viết English đi cho rẻ”, có thể đúng trong narrow case (pure tiếng Việt có dấu, prompt ngắn, dùng API pay-per-token volume cao). Nhưng với workflow typical của dev Việt:

  • Chỉ 2.9% messages của tôi là style “đắt”, phần còn lại không bị tax đó.
  • Mixed no diacritic (49% usage) còn efficient hơn pure English trên prompt dài, có data length-matched chứng minh.
  • Session-level, mixed có signal-to-cost ratio 1.0x, best trong tất cả style về dialogue efficiency.
  • Subscription plan (Claude Pro/Max, Codex Pro, coding plans khác) flat-rate, token count không ra tiền trực tiếp, nên optimize token = sai metric.

Token là phương tiện, goal là kết quả đúng trong ít round-trip. Prompt 42 token chạy 1 lượt đúng ý > prompt 14 token phải clarify 3 lượt.

Methodology notes & caveats

  • Single-user dataset. 5626 messages từ 1 người, cụ thể là tôi, làm DevOps-heavy, AWS-oriented. Pattern có thể khác với người làm frontend, data science, hoặc dùng primarily coding task. Nếu bạn làm benchmark tương tự trên bản thân, kết quả có thể shift.
  • Tokenizer là cl100k_base. Claude dùng tokenizer riêng; absolute token count khác ±5%. Relative ranking giữa các style vẫn valid.
  • Classifier rule-based. Marker word list ~180 VN + ~140 EN tech. Có 5.6% messages fall vào unknown (slash commands, attachments). Không ảnh hưởng finding chính.
  • “Out/Prompt ratio” là proxy, không phải metric hoàn hảo. Có thể bias bởi task complexity. Nhưng trên 555 sessions thì signal đủ mạnh.

Script reproducible, bạn chạy trên sessions của mình được. Logic chính:

# 1. Scan ~/.claude/projects/**/*.jsonl
# 2. Filter event where type == "user" AND role == "user"
# 3. Drop tool_result + system_reminder
# 4. Classify by diacritic + marker words
# 5. Tokenize with tiktoken cl100k_base
# 6. Aggregate per style: tok/char, out_tokens, session-level stats

Nếu bạn test xong và pattern ra khác, tôi muốn biết. Có thể user base Việt có nhiều cohort khác nhau, và “đừng switch sang English vì token” có thể chỉ đúng cho một vài cohort.

Kết

Benchmark thực tế cho 3 kết luận chính:

  1. Claim “Việt tốn hơn x2 token” đúng technical, sai framing. Chỉ áp dụng cho 2.9% usage thực của một dev coding hàng ngày.
  2. Mix-lang (Việt không dấu + English technical terms) là optimal cho medium/long prompts. Có data length-matched chứng minh; research về code-switching ủng hộ.
  3. Token optimization nằm ở structural layer (model, scope, session hygiene), không phải language choice. Leverage 40-80% vs 10-15%.

Nếu bạn định switch sang English để tiết kiệm token, hãy đo trên session của mình trước. Có thể bạn đang optimize cho số nhỏ hơn số mình đang mất ở chỗ khác.