TokenDagger – โทเคไนเซอร์ที่เร็วกว่า Tiktoken ของ OpenAI

 (github.com/M4THYOU)
5 คะแนน โดย GN⁺ 2025-07-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โทเคไนเซอร์ประสิทธิภาพสูงที่เข้ากันได้กับ TikToken ของ OpenAI ได้ 100% โดยให้ ทรูพุตมากกว่า 2 เท่าและความเร็วในการโทเคไนซ์โค้ดเร็วขึ้น 4 เท่า สำหรับการประมวลผลข้อความขนาดใหญ่
  • ใช้ เอนจินแยกวิเคราะห์ regular expression ความเร็วสูงที่อิงตาม PCRE2 เพื่อเพิ่มความเร็วในการจับคู่แพตเทิร์นของโทเค็นให้สูงสุด
  • ใช้ อัลกอริทึม BPE แบบเรียบง่าย เพื่อลดการลดลงของประสิทธิภาพให้เหลือน้อยที่สุดเมื่อต้องจัดการ special token จำนวนมาก
  • จากเบนช์มาร์กจริง การโทเคไนซ์โค้ดเร็วขึ้นมากกว่า 4 เท่า และสามารถนำไปใช้แทนโค้ดเดิมที่ใช้ TikToken ได้ทันที
  • รองรับ Python 3.8+ ติดตั้งได้ง่ายผ่าน PyPI ด้วย pip install tokendagger และมีการพึ่งพา PCRE2

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-07-01
ความคิดเห็นบน Hacker News
  • รู้สึกว่าในระยะสั้นยังมีช่องให้ปรับประสิทธิภาพได้อีกมากในโครงสร้างพื้นฐาน AI/ML ด้วยแนวทางแบบนี้ คือแก้คอขวดหลักด้วย C++ ไม่ใช่เขียนทั้งหมดใหม่เป็น C++ แต่การแลกเปลี่ยนเชิงวิศวกรรมอย่างชาญฉลาดมักนำไปสู่การเพิ่มประสิทธิภาพจริง โดยเฉพาะวิศวกรจีนดูเหมือนจะเก่งงานลักษณะนี้มาก
    • เมนเทอร์ของฉันเคยสอนมุมมองเรื่องการพัฒนาซอฟต์แวร์ไว้ว่า: ขั้นที่ 1 ทำให้มันใช้งานได้, ขั้นที่ 2 ทำให้มันเร็ว, ขั้นที่ 3 ทำให้มันสวยงาม และตอนนี้ทรานส์ฟอร์เมอร์กับ LLM ก็มาถึงขั้นที่ใช้งานได้ค่อนข้างดีแล้ว เลยรู้สึกว่านี่เป็นช่วงเวลาที่ความก้าวหน้าครั้งใหญ่จะเกิดขึ้นด้านการเพิ่มประสิทธิภาพ
    • ในระยะยาวคิดว่าการขยับออกจากการยึด Python เป็นศูนย์กลางมีความหมาย ถ้าใช้เพียงเพราะวิศวกร ML คุ้นเคย มันก็ไม่ค่อยเป็นการมองไปข้างหน้าเท่าไร
    • จริง ๆ แล้ว TikToken เขียนด้วย Rust อยู่แล้ว เลยสงสัยว่าการปรับปรุงครั้งนี้เกิดจากการพอร์ตเป็น C++ จริงหรือไม่
    • ที่จริงการ tokenizing ไม่ใช่คอขวดที่ใหญ่ที่สุด และการคำนวณส่วนใหญ่อยู่ที่การรัน CUDA kernel จริง ๆ Python overhead น้อยมาก (VLLM เองก็เขียนด้วย Python เป็นหลัก) การเขียนใหม่ด้วย C++ แทบจะหมายถึงการเขียน CUDA kernel ใหม่ให้มีประสิทธิภาพกว่าเดิมเสมอ
  • รู้สึกว่าการสร้างสิ่งทดแทนแบบ drop-in ที่ช่วยเพิ่มประสิทธิภาพของระบบเดิมได้มากเป็นเรื่องที่งดงามทีเดียว ทำให้นึกถึง ScyllaDB
    • จริง ๆ ถ้าไม่ใช่ของแทนแบบนี้ก็คงไม่มีใครใช้
  • สงสัยว่าตัว tokenizer สำคัญมากแค่ไหนต่อประสิทธิภาพโดยรวมของ LLM สนใจการ optimize tokenizer อยู่แต่ยังไม่ได้วัดจริง เดิมคิดว่าต้นทุนส่วนใหญ่เกิดจาก matmul แต่ดูจากתגובותแล้ว tokenizer ก็ดูมีนัยสำคัญอยู่
    • ปกติ tokenizing ทำบน CPU และไม่ค่อยเป็นคอขวดของการเทรนหรืออินเฟอเรนซ์ ส่วนใหญ่เวลาไปอยู่ที่ GPU kernel และมีแค่โมเดลเล็กมาก ๆ เท่านั้นที่เป็นข้อยกเว้น latency ของ tokenizer ยังสามารถ “ซ่อน” ได้ด้วยวิธีที่ CPU เตรียม batch ถัดไปไว้ล่วงหน้า
    • ประสิทธิภาพของ tokenizing ค่อนข้างซับซ้อน แต่สถาบันที่มีทั้งความสามารถและทรัพยากรจริง ๆ มักเขียน tokenizer ที่เร็วมากขึ้นมาเอง SentencePiece และ tiktoken เป็นตัวอย่างเด่นของการยอมรับทั้งความซับซ้อนและภาระในการดีพลอยเพื่อแลกกับสิ่งนี้ ผู้เชี่ยวชาญตัวจริงจะดูคอขวดผ่าน flame graph และในการรันขนาดใหญ่ก็มัก pre-tokenize กันล่วงหน้า อีกอย่างยังสัมผัสได้ถึงความตึงเครียดในอุตสาหกรรมต่อการที่ C++ กลับมาถูกพูดถึงอีกครั้ง ต่างจาก narrative ของ Rust เลยหวังว่าจะมีเหตุผลหรืออินไซต์ใหม่ ๆ อยู่เบื้องหลัง
    • เหมือนกับคอมเมนต์อื่น ๆ tokenizer ไม่ได้เป็นคอขวดจริง ๆ เพียงแต่เป็นขั้นแรกของ inference pipeline เลยถูกหยิบมาทำก่อน
    • การ tokenize ข้อความมีสัดส่วนเล็กน้อยมากเมื่อเทียบกับการคำนวณทั้งหมด แต่ถ้าต้องประมวลผลข้อมูลระดับเพตะไบต์ เร็วขึ้นอีกนิดเดียวก็คุ้มเสมอ
  • ถ้าจะให้เข้ากับ tiktoken ตอนนี้ยังต้องแปลงฟอร์แมต vocab ซึ่งถ้าตัดข้อกำหนดนี้ออกได้ก็จะเป็นตัวแทนแบบ drop-in ที่เข้ากันได้สมบูรณ์และน่าใช้ยิ่งขึ้น อีกอย่างอยากเห็นตัวอย่างแบบสองทางที่หลังจาก initialize tiktoken แล้ว initialize tokendagger ต่อเพื่อตรวจว่าผลลัพธ์เหมือนกัน
    • ตั้งแต่เวอร์ชัน 0.1.1 ก็เป็น drop-in replacement ที่แท้จริงแล้ว และมีแผนจะเพิ่มตัวอย่างในเร็ว ๆ นี้
    • ชี้ประเด็นได้ดีมาก เลยอัปเดตให้ทันที
  • สงสัยว่าโปรเจกต์นี้เทียบกับ BPE crate อย่างไร จุดแข็งของ crate นั้นคือความสามารถในการ re-tokenize ข้อความแบบ incremental และยังเร็วกว่า tiktoken
    • รอบหน้ามีแผนจะเพิ่มฟีเจอร์ incremental re-tokenization และทำ benchmark เทียบกับ crate นั้นด้วย
  • สงสัยว่ามีวิธีหา local tokenizer สำหรับ LLM ตัวอื่นไหม เช่น Gemini เปิดให้ใช้แค่ remote API เลยสงสัยว่านี่เป็นของปิดเฉพาะหรือสามารถเดา token mapping ได้ด้วยการเรียก API จำนวนมาก
    • Gemini ใช้ SentencePiece และแชร์ tokenizer vocabulary เดียวกับ Gemma (อ้างอิง1, อ้างอิง2, อ้างอิง3) ในบรรดาแล็บใหญ่ มีแค่ Anthropic ที่ใช้ Claude 3 ขึ้นไปเท่านั้นที่ไม่มี local tokenizer
    • tokenizer ของแต่ละโมเดลส่วนใหญ่ใช้ core algorithm ร่วมกัน เช่น SentencePiece หรือ Byte-pair encoding(BPE) โดยต่างกันแค่ระดับ wrapper เช่นการจัดการ special token, tiktoken กับ TokenDagger ก็เป็น implementation ของ BPE เช่นกัน ถ้าระดับไลบรารีรองรับลักษณะเฉพาะของแต่ละโมเดล ก็จะช่วยเพิ่มประสิทธิภาพได้เล็กน้อยและทำให้รวมเข้าระบบง่ายขึ้น งานไม่ได้ใหญ่โตมากนักจึงไม่เป็นภาระมากในการตามโมเดลใหม่ ตัวอย่างอ้างอิงคือ tokenizer.py ของ llama, Mistral tokenizer
    • ฉันก็เข้าใจว่า Gemini ใช้ SentencePiece SentencePiece
  • เคยลองทำอะไรคล้าย ๆ กันมาก่อน: tokie จริง ๆ แล้วต้นทุนส่วนใหญ่ของการรัน tokenizer อยู่ที่ pre-tokenizing (regex) ดูเหมือนว่าคุณจะเจอวิธีทำ regex ให้เร็วขึ้น เลยสงสัยว่าเคยเทียบไหมว่าถ้าเปลี่ยนแค่ regex engine แล้วคง BPE ของ tiktoken เดิมไว้ ประสิทธิภาพเปลี่ยนไปแค่ไหน ถ้าเป็นอย่างนั้นอาจส่ง contribution กลับ upstream ได้ด้วยหรือเปล่า
    • โปรเจกต์เจ๋งมาก ฉันได้ติดต่อคนที่ดูแล tiktoken ไว้แล้ว
  • อยากให้มีการเทียบประสิทธิภาพกับ Huggingface tokenizers ด้วย เพราะ benchmark ใน readme ของ tiktoken เป็นข้อมูลที่เก่ามากแล้ว
    • โดยส่วนตัว tiktoken ช้ากว่า huggingface tokenizers สำหรับฉันเสมอ แม้จะยังไม่ได้ลงลึกดู tiktoken มากนัก แต่ในฐานะผู้ใช้ HF Rust tokenizer ก็ให้ความรู้สึกแบบนั้น
  • อยากเห็น WASM binding ของ tiktoken ด้วย หรือไม่ก็สงสัยว่าจะนำการเพิ่มประสิทธิภาพจาก "b" ไปใช้กับ implementation แบบ pure js ได้ไหม
  • เป็นโปรเจกต์ที่ยอดเยี่ยมจริง ๆ พวกเราก็ใช้ tiktoken อยู่ ถ้าเข้ากันได้แบบ drop-in แล้วยังเร็วขึ้นด้วยก็น่าสนใจมาก การเลือกแนวทางแบบ drop-in นี่เยี่ยมเลย