GigaToken - tăng tốc token hóa mô hình ngôn ngữ khoảng 1.000 lần

 (github.com/marcelroed)
3 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Công cụ thay thế Tiktoken và HuggingFace Tokenizers, hỗ trợ nhiều CPU và các tokenizer phổ biến, xử lý văn bản ở mức GB/s
  • Tối ưu hóa SIMD cho bước tiền token hóa vốn do engine biểu thức chính quy đảm nhiệm, giảm rẽ nhánh, giao tiếp giữa luồng và tương tác với Python, đồng thời cache hiệu quả ánh xạ token của các từ đã gặp trước đó
  • Trong benchmark OpenWebText 11,9GB, thông lượng GPT-2 đạt 24.53GB/s trên AMD EPYC 9565, 8.79GB/s trên Apple M4 Max và 6.27GB/s trên Ryzen 7 9800X3D
  • Chế độ tương thích HuggingFace/Tiktoken gần như giữ nguyên code hiện có nhưng hiệu năng giảm do chi phí khớp đầu ra; Gigatoken API, nơi Rust đọc file trực tiếp, cung cấp mức song song tối đa và tốc độ cao nhất
  • Chưa hỗ trợ WordPiece và xuất ra file; tối ưu SentencePiece cũng như kiểm chứng trên Windows còn thiếu, nên hiện phù hợp hơn với BPE tokenizer và môi trường Linux/macOS hoặc WSL

Phạm vi hỗ trợ và cách sử dụng

  • Gigatoken là tokenizer tốc độ cao cho mô hình ngôn ngữ, nhắm tới các CPU x86/ARM hiện đại và gần như mọi tokenizer thông dụng
  • Cài đặt bằng pip install gigatoken, cung cấp API riêng và chế độ tương thích với HuggingFace Tokenizers/Tiktoken
  • Chế độ tương thích bọc tokenizer hiện có và chuyển đổi lần lượt bằng .as_hf() hoặc .as_tiktoken()
    • Áp dụng nhiều xử lý để đầu ra khớp chính xác với HuggingFace Tokenizers
    • Xử lý tương thích có chi phí hiệu năng đáng kể, nên không đạt mức tăng tốc khoảng 1.000 lần như API riêng, nhưng nhìn chung vẫn nhanh hơn các triển khai hiện có
  • API riêng nhận tên mô hình HuggingFace như "Qwen/Qwen3-8B" cùng TextFileSource và mã hóa file trực tiếp
    • Triển khai Rust đọc dữ liệu trực tiếp, bỏ qua overhead không cần thiết và tối đa hóa tính song song
    • Nếu truyền cấu trúc dữ liệu Python, chi phí đọc dữ liệu trong Python vẫn còn

Triển khai giúp tăng tốc

  • Cải thiện lớn nhất thường đến từ việc tự nâng cấp bước tiền token hóa bằng SIMD, thay vì giao cho engine biểu thức chính quy
  • Tối thiểu hóa rẽ nhánh và tập trung tối ưu cache ánh xạ token tiền token dùng để tìm token mã hóa của các từ đã thấy
    • Cache phình to nhanh và phân phối tiền token có dạng đuôi dài nên khó xử lý
  • Giảm tương tác với Python và giao tiếp giữa các luồng để đạt thêm hiệu năng
  • Đây không phải triển khai tối ưu cho một CPU hay một tokenizer cụ thể, mà tối ưu riêng cho các tổ hợp CPU x86/ARM hiện đại và nhiều tokenizer; kết quả cũng nhất quán trên nhiều CPU và tokenizer

Benchmark OpenWebText 11,9GB

  • Trên môi trường AMD EPYC 9565 144 nhân, thông lượng GPT-2 đạt 24.53GB/s, nhanh hơn 989 lần so với 24.8MB/s của HuggingFace Tokenizers và 681 lần so với 36.0MB/s của Tiktoken
    • Các dòng BPE chính nhìn chung đạt khoảng 15.49~24.00GB/s
    • Các mục dựa trên SentencePiece tương đối chậm hơn, khoảng 2.51~4.82GB/s
  • Trên Apple M4 Max 16 nhân, GPT-2 đạt 8.79GB/s, nhanh hơn 1.268 lần so với HuggingFace và 140 lần so với Tiktoken
    • OLMo 2/3 nhanh hơn 1.299 lần so với HuggingFace, Qwen 2/2.5 đạt 1.105 lần
  • Trên AMD Ryzen 7 9800X3D 16 nhân, GPT-2 đạt 6.27GB/s, nhanh hơn 106 lần so với HuggingFace và 68 lần so với Tiktoken
    • Các dòng BPE chính đạt khoảng 4.21~6.09GB/s, còn các dòng được tối ưu tương đối ít hơn đạt khoảng 1.12~2.84GB/s

Điều kiện đo và cách diễn giải

  • OWT(OpenWebText) được chọn làm dữ liệu benchmark vì đại diện tương đối cho văn bản thu được sau khi trích xuất tài liệu Common Crawl
  • Gigatoken xử lý mà không chia trước toàn bộ file, nên tự thực hiện cả tìm ranh giới phân đoạn và song song hóa tự động
  • Các đối tượng so sánh xử lý dữ liệu đã được chia trước theo <|endoftext|>
    • HuggingFace encode_batch_fast dùng 100MB đầu tiên
    • Tiktoken encode_ordinary_batch dùng 1GB đầu tiên
    • Cả hai triển khai đều không cache, nên tốc độ trong quá trình xử lý nhìn chung ổn định; vì vậy điều kiện so sánh này được sử dụng
  • Kết quả Tiktoken chỉ được đưa vào với các tokenizer được hỗ trợ chính thức
  • Mỗi hàng đại diện cho một tokenizer duy nhất có cùng từ vựng, phép merge và pre-tokenizer
    • Nhiều phiên bản và mô hình phái sinh của các dòng Llama, Qwen, DeepSeek, GLM, Nemotron, Kimi, Phi, Gemma được gom vào cùng một hàng tokenizer
  • Các mục chậm nhất là tokenizer dựa trên SentencePiece chưa được Gigatoken tối ưu đầy đủ

Kiểm chứng hỗ trợ và xử lý quy mô lớn

  • Có thể kiểm chứng token hóa của kho mô hình HuggingFace và đo thời gian mà không cần cài đặt bằng lệnh uvx --with tokenizers gigatoken bench
  • Trong ví dụ kiểm chứng GPT-2, đầu ra của 20.401 tài liệu khớp nhau
    • Trên Apple M4 Max, xử lý 11,920.51MB trong 1.432 giây, đạt 8,327.05MB/s, nhanh hơn HuggingFace 1,353.13 lần
    • Trên AMD EPYC 9565, xử lý cùng dữ liệu trong 0.486 giây, đạt 24,532.45MB/s, nhanh hơn 989.21 lần
  • Với tốc độ xử lý của EPYC, có thể token hóa toàn bộ Common Crawl quy mô 130 nghìn tỷ token trong dưới 6,5 giờ
  • Ví dụ sử dụng mẫu OWT Stanford CS336; CLI mặc định dùng 100MB đầu tiên của file để kiểm chứng và so sánh với HuggingFace
  • Lần chạy đầu trên macOS có thể làm code Rust chậm do kiểm tra bảo mật, nên có thể cần chạy lệnh hai lần để đo chính xác
  • Tác giả đề nghị báo cáo các trường hợp đầu ra không khớp hoặc chậm qua GitHub Issue

Hạn chế đã biết

  • Việc lặp Python được thực hiện trong Rust nhưng dùng ABI3, chậm hơn API theo từng phiên bản CPython nội bộ
    • Đã có kế hoạch chuyên biệt hóa theo từng phiên bản Python; trong thử nghiệm ban đầu, các trường hợp bị overhead chi phối nhanh hơn 2 lần
  • Gigatoken API hiện chưa triển khai sink xuất file
  • Không hỗ trợ WordPiece
  • Token hóa dựa trên SentencePiece có mức tối ưu thấp hơn BPE thông thường
    • Hiện cũng có mức ưu tiên thấp vì chủ yếu được các mô hình Google và dòng BERT sử dụng
  • Do kiểm thử Windows chưa đủ, hiện khuyến nghị dùng WSL

Phạm vi sử dụng AI

  • Phần lớn codebase được viết trực tiếp không dùng AI, có thể xác nhận qua lịch sử Git của dự án
  • Ở giai đoạn cuối của dự án, AI được dùng cho các việc sau
    • Triển khai API dành cho người dùng
    • Tổng quát hóa/port pre-tokenizer cho nhiều tokenizer hơn và mở rộng tương thích
    • Hỗ trợ padding, cắt ngắn và chuẩn hóa Unicode
    • Port chiến lược SIMD giữa AVX512, AVX2 và NEON
    • Cải thiện hiệu năng khoảng 4 lần cuối cùng thông qua loại bỏ rẽ nhánh và cải tiến tầng cache tiền token
    • Refactor và cải thiện tái sử dụng code

Bài viết liên quan

1 bình luận

 
GN⁺ 3 giờ trước
Ý kiến trên Hacker News

  • Việc nói rằng “phần lớn mã được viết trực tiếp, không dùng AI, và có thể kiểm chứng trong lịch sử Git” khiến tuyên bố lập trình của con người đã kết thúc trở nên nhạt nhòa

  • Đây không phải là tối ưu hóa cho một CPU cụ thể và một tokenizer cụ thể, mà là tối ưu hóa quá mức trên toàn bộ các tổ hợp x86·ARM hiện đại và nhiều tokenizer để đạt hiệu năng ổn định
    Họ tự tối ưu bằng SIMD bước tiền token hóa vốn thường giao cho engine biểu thức chính quy, giảm tối đa rẽ nhánh, đồng thời cải thiện cache ánh xạ token từ vựng để nhanh chóng tìm kết quả mã hóa của các từ đã thấy. Cache trong lĩnh vực này phình to rất nhanh và có đuôi phân phối dài nên khá khó xử lý
    Họ cũng giảm thiểu tương tác với Python và giao tiếp giữa các luồng

  • Điều này gợi nhớ đến simdjson, thứ đạt tốc độ khó tin nhờ lập trình sáng tạo. Nếu được dùng rộng rãi, nó có thể giảm đáng kể điện năng, chi phí và phát thải carbon, nên sẽ rất tốt nếu phát hành cả crate Rust; nếu cần thì tôi muốn trực tiếp giúp đỡ

    • Token hóa hầu như chưa từng là nút thắt cổ chai đáng kể, và tuần tự hóa JSON nhìn chung cũng vậy. I/O và thiết bị lưu trữ tiêu tốn nhiều năng lượng hơn hẳn so với tuần tự hóa và token hóa
      Nếu xét về kinh tế và môi trường, xử lý yêu cầu theo lô có tác động lớn hơn. Vấn đề đắt đỏ nhất là mức sử dụng GPU thấp; nếu điều chỉnh công việc theo dạng xử lý theo lô, ngay cả với OAI hiện nay cũng có thể tiết kiệm 50%. Không phải mọi câu trả lời đều cần ngay lập tức; một số có thể chờ vài ngày, các lệnh gọi công cụ sẽ không bị timeout, và bản thân LLM không có thời gian đồng hồ treo tường

  • Tôi đã clone kho mã về xem, và thay thế regex tiền token hóa cùng tối ưu cache là các hướng tiếp cận hữu ích nói chung. Đây là một công trình xuất sắc đến mức cả cộng đồng token hóa hẳn sẽ muốn học bí quyết tăng tốc như vậy

    • Sắp tới sẽ làm bài giải thích kỹ thuật và paper của dự án, cùng video thuyết trình, rồi chia sẻ trên Discord
    • Nó có giá trị lớn không chỉ cho suy luận mà cả huấn luyện với các bộ dữ liệu độc quyền; việc một người làm được tất cả những điều này cũng rất ấn tượng

  • Thành quả rất hay, nhưng token hóa thường chiếm dưới 0,1% tổng thời gian suy luận. Tuy vậy, nó sẽ rất hữu ích cho các ứng dụng cần chính bản thân việc token hóa

    • Tùy cách suy luận, tỷ trọng token hóa cũng có thể trở nên đáng kể. Trong đo đạc ban đầu khi chạy 8B Qwen3 trên một B200 đơn, việc chuyển sang gigatoken làm thời gian tạo token đầu tiên (TTFT) giảm trung bình 5,5% ở độ dài đầu vào 2.048, 8,4% ở 8.192 và 7,8% ở 32.768
      Mô hình càng nhỏ hoặc GPU càng nhanh thì hiệu quả càng lớn, và cần kiểm chứng thêm trước khi đưa vào README. Nguồn benchmark là fastokens
    • Trên các nền tảng AI, cần token hóa nhanh ở đầu yêu cầu để quyết định định tuyến, giới hạn tốc độ và các bước sau. Dù tỷ lệ trong tổng thời gian yêu cầu nhỏ, hiệu quả vẫn quan trọng
    • Token hóa phần lớn được xử lý tuần tự, nên nếu prompt ban đầu lớn, nó có thể chiếm tỷ trọng lớn trong thời gian xử lý đầu vào. Bởi sau khi chuyển sang suy luận mô hình, mọi token đều có thể được xử lý song song
    • Dù chỉ bằng 1/1.000 phép tính suy luận, khi quy mô lớn lên cũng khó bỏ qua. Gartner ước tính chi tiêu cho suy luận năm 2026 khoảng 28 tỷ USD, nên nếu áp dụng giả định trên thì tương đương 28 triệu USD mỗi năm
      Nguồn: https://www.gartner.com/en/newsroom/press-releases/2026-07-2...
    • Đặc biệt với các mô hình nhỏ, có thể giảm mạnh độ trễ tạo token đầu tiên. Với các nhà cung cấp suy luận như Groq hay Cerebras, độ trễ cũng quan trọng không kém tổng thông lượng

  • Có vẻ hữu ích hơn ở khâu chuẩn bị dữ liệu tiền huấn luyện ngoại tuyến so với thời điểm suy luận. Khi token hóa nhiều terabyte văn bản cho corpus huấn luyện, nó có thể tiết kiệm thời gian và chi phí, đồng thời rút ngắn chu kỳ lặp khi điều chỉnh bộ dữ liệu

  • Dồn năng lực kỹ thuật để làm cho phần chỉ chiếm 0,1% tổng thời gian chạy trở nên nhanh hơn 1.000 lần chính là hành động đậm chất lập trình viên phần mềm nhất

    • Tôi từng tạo word cloud độ phân giải cao bằng Rust trong khoảng 100ms, rồi tối ưu thêm xuống khoảng 16ms. Thế giới không cần một trình tạo word cloud nhanh đến thế, nhưng nếu đã làm thì nó nên nhanh nhất có thể
    • “Việc theo đuổi sự xuất sắc không cần biện minh”
      https://x.com/mitchellh/status/2074225453217505494
    • Còn tùy quy trình làm việc. Cũng có những trường hợp chỉ thực hiện token hóa mà không đưa văn bản ngay vào mô hình
    • Ngay cả một thành phần con, nếu được cải thiện 1.000 lần, cũng có thể mở ra các tính năng mới về chất. Việc phần đó chỉ chiếm 0,1% tổng thể nhiều khi cũng là kết quả của thái độ lặp đi lặp lại trong toàn dự án rằng “không ảnh hưởng đến hiệu năng tổng thể thì làm tử tế làm gì”
      LLM gần với giới hạn cải thiện 1.000 lần hơn nhiều, nhưng các phép toán PyTorch cơ bản cũng thường chậm hơn 2 lần so với việc viết lại đơn giản, và các thuật toán lập lịch tốt hơn đôi khi đem lại cải thiện 5–10 lần. Token hóa nhanh có thể mở ra những tính năng khác từng bị bỏ qua vì trước đây không khả thi
    • Nếu token hóa để chạy một mô hình ngôn ngữ siêu nhỏ (SLM) dùng cho định tuyến, tỷ trọng có thể lớn hơn 0,1% rất nhiều. Điều này giống lối nghĩ “PC phần lớn thời gian chỉ nằm ở màn hình desktop, nên tối ưu driver GPU không quan trọng”

  • Đây là hiệu năng khó tin đến mức phải nhìn biểu đồ khá lâu mới hiểu được các con số

  • Đây cũng chính xác là tính năng ClickHouse cần, nên dự định sẽ thử tại https://github.com/ClickHouse/ClickHouse/issues/108247
    Sẽ tốt hơn nếu README nhấn mạnh hơn hiệu năng trên mỗi lõi, và tôi cũng tò mò liệu matching bằng bảng băm hoàn chỉnh có hữu ích trong thuật toán thực tế hay không

  • Nếu vậy thì lại khiến tôi tự hỏi trong các phần khác của pipeline suy luận vẫn còn bao nhiêu cơ hội tối ưu 1.000 lần

    • Khác với tầng token hóa, các thay đổi khác trong suy luận khó có thể phán định đơn giản là đúng hay sai
    • Có rất nhiều phần như vậy, và gần như mọi thành phần đều có đội ngũ chuyên trách cùng nghiên cứu riêng. Khả năng cao trong tương lai vẫn sẽ có nhiều đột phá lớn
    • Những phần chiếm tỷ trọng lớn hơn trong thời gian suy luận hẳn đã được đầu tư tối ưu nhiều hơn rất nhiều