Hugging Face ปล่อย tokenizers v1 RC — encode เร็วกว่า v0.23 ราว 3–30 เท่าบนเธรดเดียว token ID ตรงกันทุกตัว แต่ตัวเลขทั้งหมดวัดจาก Rust ไม่ใช่ Python

tokenizers ของ Hugging Face คือไลบรารีที่อยู่ใต้ transformers และ pipeline ของโมเดลเปิดแทบทุกตัว เมื่อ 21 ก.ย. 2026 ทีม (Arthur Zucker, Simon Brandeis, Luc Georges และ Lysandre) ปล่อย 1.0.0-rc.2 ขึ้นทั้ง crates.io และ PyPI พร้อมบทความ “tokenizers v1: encode, decode and scaling, measured” ที่อธิบายว่าเวอร์ชันใหม่ encode เร็วกว่า v0.23 ประมาณ 3 ถึง 30 เท่าบนเธรดเดียว โดยยังได้ token ID ชุดเดิมทุกตัว

ประโยคหลักจากบทความคือ “Across the ten model families v1’s encode path covers, it encodes text 3 to 30 times faster than v0.23 with one thread on an Apple M4 Max.” ตัวเลขต่ำสุดมาจาก t5-base ส่วนสูงสุดมาจาก gpt2 และเมื่อเพิ่มเป็น 8 worker ประสิทธิภาพ scale ได้ 76% ของเส้นตรง

ทำไมถึงเร็วขึ้น

ทีมตั้งเป้าว่าจะไม่เปลี่ยนผลลัพธ์ API vocabulary หรือลำดับ merge แต่ปรับทุกอย่างที่ปรับได้ การเปลี่ยนแปลงที่มีผลจริงคือ:

• bitcannon แทน regex: การแบ่ง pre-token ของ BPE เดิมใช้ regex engine ทั่วไป แต่ pattern ของแต่ละโมเดลตายตัว v1 จึงเขียนฟังก์ชันแบ่งเฉพาะ pattern ด้วย SIMD ที่มองไบต์เป็น bitstream แล้วตัดสินขอบเขตครั้งละ 64 ไบต์ต่อหนึ่งการดำเนินการกับ register (แนวคิดเดียวกับ simdjson) ตอนนี้รองรับ pattern ของ GPT-2, cl100k, o200k, Tekken และ DeepSeek
• Word cache: cache ต่อเธรดที่จำว่า pre-token นี้ได้ ID อะไร คำที่ซ้ำจึง merge แค่ครั้งแรก
• Merge loop ใหม่: ใช้ scratch buffer ของผู้เรียก ไม่ allocate เลย ชิ้นที่กำลัง merge เก็บเป็น linked list อยู่ใน buffer เดียว คู่ที่รอ merge ถูกอัดเป็นค่า 64-bit ที่มีลำดับ merge อยู่ในบิตบน ทำให้การเปรียบเทียบกลายเป็นการเทียบจำนวนเต็มแบบไม่มี branch
• Native parallelism: tokenizer ตัวเดียวถูกเรียกจากหลายเธรดได้ แต่ละเธรดดึง buffer กับ cache จาก sub-pool ของตัวเอง ไม่ต้องรอ lock ตัวเดียวกันอีก
• แยก crate: tk-encode เป็น runtime หลัก ส่วน tk-serialize, tk-convert และ tk-train ลิงก์เข้ามาเฉพาะเมื่อจำเป็น

ข้อควรรู้คือถ้า tokenizer ใช้ pattern ที่ bitcannon ยังไม่รู้จัก จะกลับไปใช้ regex และไม่ได้ความเร็วส่วนนี้ ซึ่งเป็นเหตุผลที่ตัวเลขกระจายตั้งแต่ 3 ถึง 30 เท่า

วิธีวัดที่ควรชม

ทีมทำ benchmark ด้วย repo ชื่อ tokbench และประกาศกติกาไว้ชัด เช่น ทุก engine ใช้ timing loop เดียวกัน ไม่รวมเวลาโหลด vocabulary ตรวจ hash ของ token ID ให้ตรงกับ baseline ทุกครั้ง pin worker ไว้กับ physical core 8 ตัวที่ไม่ใช่ SMT sibling และตัวเลขหลักใช้ เอกสารที่ไม่ซ้ำกัน ไม่ใช่การ encode เอกสารเดิมซ้ำจนอยู่ใน cache ทั้งหมด บทความยังเตือนด้วยว่า “Tokenizer benchmarks should identify which workload they use because the choice can dominate the result” ซึ่งเป็นกับดักที่ benchmark ของไลบรารี tokenizer หลายตัวเคยตกลงไป

ลองใช้ได้อย่างไร

ฝั่ง Rust:

cargo add tokenizers --pre
# ถ้าใช้แค่ encode ไม่ต้องเทรน ตัด dependency C++ ออกได้
cargo add tokenizers --pre --no-default-features --features http

ฝั่ง Python มี 1.0.0rc1 และ rc2 อยู่บน PyPI แล้ว (อัปโหลด 21 ก.ย.) ติดตั้งได้ด้วย pip install --pre tokenizers แต่บทความเขียนไว้ชัดว่า “Python bindings wrap the same code … but they add per-call overhead that none of these measurements include” ดังนั้นอย่าคาดหวังตัวเลข 30 เท่าใน Python ตามนั้น การปรับ Python binding ให้เบาลง (ลด lock และ wrapper รวมถึงรองรับ free-threaded CPython) อยู่ในรายการงานก่อนออก 1.0.0

งานที่เหลือก่อน 1.0.0 ยังรวมถึงการย้ายตระกูลโมเดลอื่นมาใช้ merge loop ใหม่ การคำนวณ offset และ mask เฉพาะเมื่อขอ และ binding C/C++ สำหรับ inference เพื่อ ExecuTorch และ llama.cpp ส่วนหลัง 1.0.0 ทีมจะสำรวจการ encode และ decode บน GPU (tok-devices) นอกจากนี้ release candidate รอบนี้ยังมี Node.js binding อยู่แล้ว

มุมมอง AI Curator

ในช่วงที่ทุกคนพูดถึง GPU แทบไม่มีใครมอง tokenizer จนกระทั่งงานเปลี่ยนเป็น agent ที่ส่ง context ยาวหลายหมื่น token ซ้ำ ๆ ทุกเทิร์น ตอนนั้นเวลาที่ CPU ใช้ตัดคำก่อนป้อน GPU ถึงเริ่มเห็นได้ ชื่อ corpus ที่ทีมใช้ทดสอบ cache คือ agentic_swe ก็บอกอยู่แล้วว่าเป้าคืองานแบบไหน สิ่งที่มีค่าที่สุดของ v1 จึงไม่ใช่ตัวเลข 30 เท่า แต่เป็นการรับประกันว่า token ID ตรงกับของเดิม ซึ่งทำให้อัปเกรดได้โดยไม่ต้องกลัวว่าโมเดลที่ deploy อยู่จะเห็น input เปลี่ยนไป

อีกเรื่องที่ควรสังเกตคือบทความให้เครดิต tiktoken, gigatoken และไลบรารีเล็ก ๆ อีกหลายตัวว่าเป็นที่มาของไอเดีย ซึ่งตรงไปตรงมาดี และยอมรับว่า “before this refactor, tokenizers was nowhere near the performance it could have had” สำหรับทีมไทยที่เทรนหรือเสิร์ฟโมเดลภาษาไทย ข้อสังเกตคือ word cache ได้ประโยชน์เต็มที่เมื่อ pre-token ซ้ำกันเยอะ ข้อความไทยไม่มีช่องว่างระหว่างคำ ขอบเขต pre-token จึงต่างจากภาษาอังกฤษมาก ตัวเลขเร่งความเร็วที่วัดบนข้อความอังกฤษอาจไม่ตรงกับข้อความไทย ก่อนย้าย pipeline ควรรัน tokbench บน corpus ภาษาไทยของตัวเองก่อน (บทความมีคำสั่งให้รันซ้ำบนเครื่องตัวเองได้) และตอนนี้ยังเป็น release candidate ยังไม่ควรใช้ใน production

แหล่งข่าว

• tokenizers v1: encode, decode and scaling, measured — Hugging Face Blog (21 ก.ย. 2026)
• huggingface/tokenizers — GitHub
• huggingface/tokbench — ชุด benchmark ที่ใช้ในบทความ
• tokenizers 1.0.0rc2 — PyPI