"Token-space font": Công cụ tạo font chữ nơi mỗi token LLM có cùng độ rộng

Trong thế giới của các mô hình ngôn ngữ lớn (LLM), văn bản không được xử lý theo từng ký tự hay từng từ, mà theo token — những đơn vị nhỏ hơn từ nhưng lớn hơn ký tự. Một dự án mới có tên "Token-space font compiler" đang thu hút sự chú ý của cộng đồng công nghệ khi cho phép tạo ra font chữ trong đó mỗi token chiếm đúng một độ rộng bằng nhau, bất kể token đó đại diện cho một ký tự, một phần của từ hay cả một cụm từ.

Ý tưởng đằng sau Token-space font

Công cụ này hoạt động theo nguyên lý: font + tokenizer → token-space font. Thay vì hiển thị văn bản theo cách thông thường, font được biên dịch sao cho trong mỗi "shaping run" (đoạn xử lý của trình duyệt), mỗi token do tokenizer tạo ra sẽ chiếm 3 em — tức là cùng một độ rộng cố định.

Điều này tạo ra một hiệu ứng thị giác thú vị: những câu ngắn nhưng bị chia thành nhiều token sẽ trông dài hơn hẳn so với câu dài nhưng ít token. Chẳng hạn, một câu tiếng Anh đơn giản có thể "giãn" ra hoặc "co" lại tùy theo cách tokenizer của từng mô hình phân tách.

"Bạn không có gì để mất ngoài những chuỗi suy nghĩ của mình" — một trong những câu mẫu được dùng để minh họa hiệu ứng token hóa.

Hỗ trợ nhiều mô hình và tokenizer phổ biến

Công cụ hỗ trợ một loạt tokenizer từ các mô hình lớn, bao gồm:

• DeepSeek V4.1 Flash, Kimi K3, Qwen 3.6, GLM-5.3 (thử nghiệm), Llama 3 (thử nghiệm)
• Các bộ mã hóa của OpenAI như o200k_base, cl100k_base, p50k_base, r50k_base
• Các mô hình thử nghiệm khác như Trinity Large Thinking, Laguna M.1, Gemma 4, Gemini 3.5 Flash
• Hỗ trợ tải lên tokenizer từ Hugging Face hoặc tệp tokenizer.json cục bộ

Người dùng cũng có thể chọn font nền đa dạng: Inter, gg sans (Discord), Roboto, Lora, SF Mono, Ubuntu Mono, JetBrains Mono, Bebas Neue, Caveat, và nhiều font khác.

Ứng dụng thực tế: Discord và Slack

Một trong những điểm hấp dẫn của dự án là khả năng áp dụng font này vào Discord thông qua Vesktop hoặc Slack thông qua userscript. Cụ thể:

• Với Discord, người dùng có thể nhập ID người dùng cụ thể để chỉ áp dụng font token hóa cho tin nhắn của người đó — ví dụ, bạn có thể chọn chỉ hiển thị tin nhắn của một trợ lý AI theo phong cách token.
• Với Slack, công cụ cung cấp một userscript hoạt động trong trình duyệt, tự động phát hiện tên hiển thị hoặc member ID của "agent" và áp dụng font tương ứng.

Điểm đáng chú ý là toàn bộ quá trình biên dịch diễn ra ngay trong trình duyệt. Các tệp của bạn không bị tải lên máy chủ nào. Với những tokenizer lớn, quá trình này có thể mất vài phút do phải xử lý bằng Pyodide và fontTools.

Những hạn chế đáng lưu ý

Dù ý tưởng độc đáo, công cụ này vẫn còn nhiều hạn chế được chính tác giả ghi nhận:

• Không phải là công cụ đếm token chính xác: Font chỉ mô phỏng trực quan, không phản ánh đúng số token thực tế mà API sẽ tính phí. Các token đặc biệt, chat template, nội dung đa phương tiện và phần "khung" tin nhắn không được thể hiện đầy đủ.
• Lỗi với khoảng trắng trong DeepSeek: Các ký tự điều khiển U+001C–U+001F bị phân loại sai là khoảng trắng, khiến hai dấu cách cộng với U+001C bị gộp thành một token khoảng trắng. Lỗi này vẫn chưa được khắc phục.
• GLM-5.3 và Llama 3 có giới hạn 64 byte / 32 vòng lặp cho một số đoạn văn bản, hiển thị [BPE limit] nếu vượt quá.
• Claude / ctok chỉ là xấp xỉ không chính thức, không phải triển khai tokenizer thực sự của Claude. Các phiên bản v3, v4.7 và v4.8 vẫn còn lỗi về chuẩn hóa khoảng trắng đầu dòng và khung trích dẫn.
• Ký tự vô hình như zero-width space, word joiner, BOM và soft hyphen có thể phá vỡ ranh giới từ, làm tăng số token.
• Trình duyệt có thể chuẩn hóa văn bản trước khi font xử lý, thay đổi ranh giới token. Các ngắt dòng cứng, thay đổi script, văn bản hai chiều và font dự phòng cũng có thể chia nhỏ "shaping run".

Vì sao điều này đáng quan tâm?

Với người dùng Việt Nam đang ngày càng tiếp xúc nhiều với các trợ lý AI như ChatGPT, Claude, Gemini hay các mô hình nội địa, việc hiểu cách LLM "nhìn" văn bản có ý nghĩa thực tiễn. Tiếng Việt với dấu thanh và ký tự Unicode đặc thù thường bị tokenizer chia nhỏ hơn tiếng Anh, khiến chi phí API và độ dài ngữ cảnh tăng lên.

Công cụ này, dù chỉ mang tính trình diễn, giúp trực quan hóa vấn đề đó — và có thể truyền cảm hứng cho các nhà phát triển Việt Nam quan tâm đến việc tối ưu tokenizer cho tiếng Việt hoặc nghiên cứu sâu hơn về cách các mô hình xử lý ngôn ngữ có dấu.

Tác giả dự án cũng thẳng thắn mời gọi cộng đồng: nếu ai có chuyên môn sâu hơn về cách font hoạt động, hãy triển khai dự án này một cách bài bản hơn. Đây rõ ràng là một thử nghiệm mang tính khám phá, không phải sản phẩm hoàn thiện.