GigaToken ra mắt: Tăng tốc phân tách từ vựng lên 1000 lần, thay thế hoàn hảo cho HuggingFace

Nhanh hơn khoảng 1000 lần so với các trình tokenizer của HuggingFace, có thể thay thế trực tiếp (drop-in replacement).

Tokenize dữ liệu văn bản của bạn ở tốc độ GB/s!

Lưu ý rằng cả HF tokenizers và tiktoken đều đã chạy đa luồng bằng Rust!

Gigatoken là gì?

Gigatoken là trình tokenizer nhanh nhất dành cho mô hình ngôn ngữ. Nó hỗ trợ nhiều loại phần cứng CPU và gần như tất cả các trình tokenizer phổ biến hiện nay. Xem phần Benchmarks để biết số liệu thông lượng chi tiết trên các loại tokenizer và CPU khác nhau.

Cài đặt

Cách sử dụng

Gigatoken có thể được sử dụng với API riêng của nó, hoặc ở chế độ tương thích với HuggingFace Tokenizers hoặc Tiktoken.

Chế độ tương thích (Dễ nhất)

Một nỗ lực đáng kể đã được thực hiện để đảm bảo đầu ra khớp chính xác với những gì bạn nhận được từ HuggingFace Tokenizers trong thiết lập này, nhưng điều này đi kèm với chi phí hiệu năng không hề nhỏ. Bạn vẫn có thể kỳ vọng hiệu năng nhanh hơn đáng kể trên diện rộng, nhưng không đạt mức 1000 lần như khi sử dụng Gigatoken API.

Gigatoken API (Nhanh nhất)

Sử dụng Gigatoken API cho phép triển khai Rust đọc dữ liệu trực tiếp và bỏ qua nhiều chi phí vận hành (overhead) nhất có thể, đồng thời cho phép song song hóa tối đa. Hãy nhớ rằng việc truyền các cấu trúc dữ liệu Python qua API này vẫn phát sinh chi phí đọc từ Python.

Benchmarks (Điểm chuẩn)

OWT (openwebtext) được chọn vì nó đại diện tương đối cho văn bản bạn nhận được sau khi trích xuất từ các tài liệu CommonCrawl. Gigatoken mã hóa toàn bộ tệp mà không chia nhỏ, do đó nó thực hiện nhiều công việc hơn các trình tokenizer khác để tìm ranh giới phân tách và tự động song song hóa. HuggingFace tokenizers (encode_batch_fast) lấy 100 MB đầu tiên và tiktoken (encode_ordinary_batch) lấy 1 GB đầu tiên, cả hai đều được chia tách trước trên <|endoftext|>. Điều này là công bằng vì không trình tokenizer nào được so sánh sử dụng bộ nhớ đệm (caching), nghĩa là tốc độ gần như đồng nhất trong suốt quá trình xử lý. Các hàng của Tiktoken hiện chỉ được điền cho các trình tokenizer có hỗ trợ chính thức.

Các hàng chậm nhất là các trình tokenizer dựa trên SentencePiece, vốn chưa được tối ưu hóa tốt trong Gigatoken.

Mỗi hàng là một trình tokenizer riêng biệt (có vocab/merges/pretokenizer giống hệt nhau), được đo lường trên một repo đại diện. Nếu bạn không thấy trình tokenizer của mình ở đây, có khả năng nó dựa trên một trình tokenizer hiện có. Ví dụ:

Câu hỏi thường gặp (FAQ)

H: Có phải bạn chỉ tối ưu hóa quá mức cho một CPU và trình tokenizer cụ thể không? Tại sao nó lại nhanh như vậy?

Không, tôi đã tối ưu hóa quá mức cho mọi sự kết hợp của chúng! Kết quả rất nhất quán trên các CPU (x86 và ARM hiện đại) và trên các trình tokenizer cụ thể.

Những cải tiến chính nằm ở việc tối ưu hóa mạnh mẽ quá trình triển khai vốn thường được giao cho công cụ Regex (pretokenization) bằng cách sử dụng SIMD, giảm thiểu phân nhánh và các thủ thuật khác, cũng như tối ưu hóa mạnh mẽ việc lưu bộ nhớ đệm cho các ánh xạ pretoken (nếu một từ đã được nhìn thấy trước đó, hãy tra cứu các token đã mã hóa của nó một cách hiệu quả). Caching là một vấn đề rất khó trong lĩnh vực này vì bộ nhớ đệm tăng trưởng rất nhanh và phân phối pretoken có đuôi rất dài (long-tailed).

Một số lợi ích cũng đạt được từ việc giảm thiểu tương tác với Python và tránh giao tiếp giữa các luồng.

H: Làm thế nào để tôi kiểm tra nhanh xem trình tokenizer của mình có được hỗ trợ không?

Bạn có thể dùng thử mà không cần cài đặt bất cứ thứ gì! Lệnh sau đây sẽ xác thực và đo thời gian tokenization cho một repo mô hình HuggingFace nhất định:

Với tốc độ chúng ta thấy trên CPU EPYC, bạn có thể tokenize toàn bộ Common Crawl (thường được coi là toàn bộ internet, 130 nghìn tỷ token) trong chưa đầy 6,5 giờ!

Ví dụ này sử dụng mẫu train từ tập dữ liệu này và CLI mặc định tập hợp con 100MB đầu tiên của tệp để xác thực và so sánh với HF. Bạn có thể xem trợ giúp cho các cờ này với lệnh uvx gigatoken bench --help. Bạn có thể cần chạy lệnh hai lần trên macOS để có kết quả đo tốt, vì lần chạy đầu tiên sẽ luôn thực hiện quét bảo mật, điều này sẽ làm chậm mã Rust.

H: Tôi đã tìm thấy một trường hợp không khớp/chậm, liệu điều này có bình thường không?

Rất có thể là không! Mặc dù đã thử nghiệm khá rộng rãi, tôi không có sẵn mọi trường hợp sử dụng, vì vậy vui lòng báo cáo bất kỳ vấn đề nào bạn tìm thấy trong GitHub Issue để tôi có thể giải quyết sớm nhất có thể.

Trích dẫn

Nếu bạn sử dụng Gigatoken trong nghiên cứu của mình, vui lòng trích dẫn nó như sau:

Các vấn đề đã biết