چگونه بهینه‌سازی SIMD سرعت توکن‌سازی را به ۲۴ گیگابایت رساند؟

تصور کنید تمام داده‌های وب‌سایت‌های جهان را در کمتر از ۷ ساعت آماده‌ی آموزش کنید. اگر امروز برای پیش‌پردازش مجموعه‌داده‌های عظیم (Dataset) هفته‌ها صبر می‌کنید، Gigatoken می‌تواند این زمان را به چند ساعت محدود کند. برای درک مقیاس این ابزار، باید به عدد ۱۳۰ تریلیون توکن نگاه کنیم؛ این تقریباً اندازه کل مجموعه‌داده Common Crawl است. پردازش چنین حجمی از داده‌ها روی سخت‌افزارهای سطح بالا، اکنون می‌تواند در کمتر از ۶.۵ ساعت انجام شود.

طبق اعلام توسعه‌دهنده، ابزار Gigatoken که در ۲۲ جولای ۲۰۲۶ منتشر شد، با پردازش متن در مقیاس گیگابایت بر ثانیه، توکن‌سازی (Tokenization) — یعنی تبدیل متن به تکه‌های کوچکی از داده که مدل می‌فهمد، شبیه بریدن یک کیک طولانی به برش‌های کوچک برای بلعیدن راحت‌تر — را از یک گلوگاه سخت به یک فرآیند سریع تبدیل کرده و عملاً مانع توکن‌سازی را در خطوط لوله‌ی آموزش مدل‌های زبانی عظیم از بین برده است.

توکن‌سازی اولین گام نامرئی در هر خط لوله‌ی مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — است. ابزارهای فعلی مانند HuggingFace (HF) tokenizers و tiktoken با اینکه از توابع چندرشته‌ای (Multithreaded) زبان Rust استفاده می‌کنند، اما اغلب در مواجهه با حجم عظیم داده‌های خام مورد نیاز برای مدل‌های پیشرو (Frontier Models) دچار مشکل می‌شوند. اکثر ابزارهای فعلی سربار زیادی را صرف موتورهای Regex (عبارات منظم) و ارتباطات بین پایتون و رست می‌کنند، که این امر باعث کند شدن پیش‌پردازش مجموعه‌داده‌هایی در مقیاس پتابایت می‌شود.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی زیرساختی مدل‌های بازمتن اشاره کردیم، سرعت استنتاج تنها نیمی از بازی است و آماده‌سازی داده‌ها اهمیت حیاتی دارد. این توجه به کارایی زیرساختی، مشابه رویکردی است که در بهینه‌سازی‌های بیزی برای کاهش تأخیر سیستم‌های RAG دیدیم تا بازیابی داده‌ها با سرعت و دقت بیشتری صورت گیرد. Gigatoken این مشکل را با دور زدن سربارهای پایتون و پیاده‌سازی یک هسته‌ی بسیار سریع با زبان Rust حل کرده است. این ابزار به‌طور خاص پردازنده‌های مدرن x86 و ARM را هدف قرار داده و برای SIMD (Single Instruction, Multiple Data) و سلسله‌مراتب بهینه شده‌ی حافظه (Cache) بهینه‌سازی شده است.

به نقل از مستندات پروژه در گیت‌هاب اثر Marcel Rød، این ابزار به عنوان یک جایگزین مستقیم (Drop-in replacement) برای جریان‌های کاری موجود عمل می‌کند و در عین حال دو حالت عملیاتی مجزا را ارائه می‌دهد.

زمینه و متدولوژی بنچمارک

برای اثبات این ادعاها، بنچمارک‌هایی با استفاده از مجموعه‌داده owt_train.txt به حجم ۱۱.۹ گیگابایت انجام شد که از OpenWebText مشتق شده است. این مجموعه‌داده به این دلیل انتخاب شد که نماینده‌ی متون معمولی استخراج شده از اسناد CommonCrawl باشد.

برخلاف ابزارهای رقیب، Gigatoken کل فایل را بدون پیش‌تقسیم (Pre-splitting) کدگذاری می‌کند. این بدان معناست که Gigatoken کارهای اضافی مربوط به یافتن مرزهای تقسیم و اتوماسیون موازی‌سازی را خودش انجام می‌دهد. در مقابل، به توکن‌سازهای HF (encode_batch_fast) و tiktoken (encode_ordinary_batch) داده‌هایی داده شد که قبلاً با توکن <|endoftext|> تقسیم شده بودند. حتی با وجود این مزیت برای رقبا، توان عملیاتی Gigatoken چندین مرتبه بالاتر است.

بنچمارک‌های عملکرد

بیشترین افزایش سرعت در API بومی Gigatoken دیده می‌شود، جایی که Rust می‌تواند داده‌ها را مستقیماً از فایل‌ها بخواند. در بنچمارک‌های انجام شده روی پردازنده ۷۲ هسته‌ای AMD EPYC 9565 (با مجموع ۱۴۴ هسته در ۲ سوکت)، این ابزار به اعداد خیره‌کننده‌ای رسید:

• GPT-2: ۲۴.۵۳ گیگابایت بر ثانیه (۹۸۹ برابر سریع‌تر از HF؛ ۶۸۱ برابر سریع‌تر از tiktoken)
• Phi-4: ۲۴.۰۰ گیگابایت بر ثانیه (۸۰۱ برابر سریع‌تر از HF)
• GPT-OSS: ۲۳.۹۶ گیگابایت بر ثانیه (۴۸۲ برابر سریع‌تر از HF؛ ۵۶۰ برابر سریع‌تر از tiktoken)
• OLMo 2 / 3: ۲۳.۰۶ گیگابایت بر ثانیه (۸۳۳ برابر سریع‌تر از HF)
• Nemotron 3: ۲۲.۷۹ گیگابایت بر ثانیه (۴۶۲ برابر سریع‌تر از HF)
• Qwen 3: ۲۲.۱۶ گیگابایت بر ثانیه (۶۴۸ برابر سریع‌تر از HF)
• Llama 3 / 3.1 / 3.2: ۲۲.۱۵ گیگابایت بر ثانیه (۴۵۷ برابر سریع‌تر از HF)
• GLM 5: ۲۰.۹۷ گیگابایت بر ثانیه (۲۸۰ برابر سریع‌تر از HF)
• Llama 3.3: ۲۰.۸۲ گیگابایت بر ثانیه (۴۳۱ برابر سریع‌تر از HF)
• Llama 4: ۲۰.۷۷ گیگابایت بر ثانیه (۲۸۶ برابر سریع‌تر از HF)
• GLM 4: ۲۰.۶۱ گیگابایت بر ثانیه (۲۸۵ برابر سریع‌تر از HF)
• Phi-4-mini: ۲۰.۰۵ گیگابایت بر ثانیه (۷۲۶ برابر سریع‌تر از HF)
• DeepSeek V3 / R1 / V4: ۱۹.۶۹ گیگابایت بر ثانیه (۷۵۰ برابر سریع‌تر از HF)
• Qwen 2 / 2.5: ۱۹.۱۲ گیگابایت بر ثانیه (۶۹۱ برابر سریع‌تر از HF)
• Kimi K2: ۱۸.۸۵ گیگابایت بر ثانیه
• Qwen 3.5 / 3.6: ۱۵.۴۹ گیگابایت بر ثانیه (۵۵۸ برابر سریع‌تر از HF)

حتی در سخت‌افزارهای مصرف‌کننده، این تفاوت چشم‌گیر است. آزمایش روی Apple M4 Max (با ۱۶ هسته) نشان داد که توکن‌سازی GPT-2 با سرعت ۸.۷۹ گیگابایت بر ثانیه انجام می‌شود که تقریباً ۱۲۶۸ برابر سریع‌تر از خط مبنای HF (یعنی ۶.۹ مگابایت بر ثانیه) است. دیگر نتایج روی M4 Max شامل Phi-4 با سرعت ۷.۷۶ گیگابایت بر ثانیه (۱۰۱۲ برابر HF) و OLMo 2/3 با سرعت ۷.۵۶ گیگابایت بر ثانیه (۱۲۹۹ برابر HF) بود. حتی روی یک پردازنده AMD Ryzen 7 9800X3D (۱۶ هسته)، Gigatoken داده‌های Phi-4 را با سرعت ۶.۰۹ گیگابایت بر ثانیه پردازش کرد که ۱۱۰ برابر برتری نسبت به HF دارد.

جزئیات فنی و مکانیزم‌ها

بر اساس بررسی فنی، سه تصمیم معماری کلیدی باعث این جهش شده است:

۱. پیش‌توکن‌سازی SIMD: این ابزار پیش‌توکن‌سازی استاندارد مبتنی بر Regex را که معمولاً به یک موتور Regex خارجی سپرده می‌شود، با یک پیاده‌سازی بهینه‌ی SIMD جایگزین کرده است تا میزان شاخه‌بندی (Branching) را به حداقل برساند.
۲. کشینگ پیشرفته: ایجاد یک سلسله‌مراتب تهاجمی برای نگاشت پیش‌توکن‌ها؛ اگر کلمه‌ای قبلاً دیده شده باشد، ابزار توکن‌های کدگذاری شده آن را به‌طور بهینه بازیابی می‌کند. این یک مسئله دشوار است زیرا کش به سرعت رشد می‌کند و توزیع پیش‌توکن‌ها دارای دم بلند (Long-tailed) است.
۳. API بومی Rust: استفاده از gt.TextFileSource به پیاده‌سازی Rust اجازه می‌دهد داده‌ها را مستقیماً بخواند و ساختارهای داده‌ای پایتون و ارتباطات بین رشته‌ها (Threads) را حذف کند، که این امر سربار تعامل را به حداقل می‌رساند.

سازگاری و یکپارچه‌سازی

برای کاربرانی که نمی‌خواهند کل خط لوله خود را به API بومی منتقل کنند، Gigatoken حالت‌های سازگاری (Compatibility Mode) را فراهم کرده است تا به عنوان یک جایگزین مستقیم در جریان‌های کاری موجود عمل کند:

• سازگاری با HF: با استفاده از gt.Tokenizer(hf_tokenizer).as_hf()، توکن‌ساز می‌تواند در همان محیط‌های توکن‌سازهای استاندارد HuggingFace استفاده شود.
• سازگاری با Tiktoken: با استفاده از gt.Tokenizer(tiktokenizer).as_tiktoken()، ابزار مانند یک شیء استاندارد tiktoken رفتار می‌کند.

اگرچه این حالت تضمین می‌کند که خروجی‌ها دقیقاً یکسان باشند، اما هزینه‌ی عملکردی غیرقابل چشم‌پوشی دارد. کاربران همچنان سرعت بسیار بیشتری نسبت به HF/tiktoken استاندارد خواهند دید، اما به آن افزایش سرعت ۱۰۰۰ برابری که در API بومی Gigatoken یافت می‌شود، دست نخواهند یافت.

پشتیبانی از مدل‌ها

این ابزار طیف گسترده‌ای از واژگان (Vocabularies) حیاتی صنعت را پشتیبانی می‌کند:

• خانواده Llama: پشتیبانی کامل از نسخه‌های 3, 3.1, 3.2 و 3.3. این شامل Llama 3, DeepSeek-R1-Distill-Llama, Hermes 3, Saiga, Llama-3.1-Nemotron-Nano-VL, SmolLM3, Kanana 1.5, jina-embeddings-v5 و Ultravox می‌شود.
• خانواده Qwen: پشتیبانی از Qwen 2, 2.5 (شامل Coder و VL)، Qwen 3 (شامل Embedding و Reranker)، Qwen3-Coder, Qwen3-VL, DeepSeek-R1 Qwen distills, MiMo V2.5, MiniCPM-o 2.6, InternVL3, Qwen2.5-Omni و pplx-embed.
• DeepSeek: بهینه‌سازی شده برای V3, V3.1, V3.2, R1, V4 Flash/Pro و DeepSeek-VL2.
• GLM و سایرین: پشتیبانی کامل از GLM 4.1V, 4.5, 4.7, GLM 5, 5.2 و GLM-4.7-Flash. همچنین شامل Nemotron 3 Nano/Super/Ultra و Kimi K2 تا K2.7 است.
• Phi و Gemma: پشتیبانی از Phi-4, Phi-4-mini, Phi-4-multimodal, Gemma 1 تا 4 (dense, MoE و سری E) و DiffusionGemma.

مشکلات شناخته شده و محدودیت‌ها

• SentencePiece: توکن‌سازهای مبتنی بر SentencePiece (که توسط مدل‌های گوگل و BERT استفاده می‌شوند) به اندازه نسخه‌های BPE بهینه نشده‌اند و در حال حاضر اولویت پایینی دارند.
• WordPiece: این استاندارد هنوز پشتیبانی نمی‌شود.
• پشتیبانی از سیستم‌عامل: ویندوز به‌طور گسترده تست نشده است و توسعه‌دهنده توصیه می‌کند از WSL استفاده شود.
• ABI پایتون: تکرار فعلی در Rust از طریق ABI3 مدیریت می‌شود. نسخه‌های آینده قصد دارند برای APIهای خاص CPython تخصصی شوند تا احتمالاً سربار را کاهش داده و در موارد محدود به سربار (Overhead-bound)، بهبود سرعت ۲ برابری ایجاد کنند.
• خلاء‌های API: سینک‌های فایل (File sinks) هنوز در API بومی Gigatoken پیاده‌سازی نشده‌اند.

فرآیند توسعه

نکته جالب این است که این پروژه تا حد زیادی به‌صورت دستی کدنویسی شده است. توسعه‌دهنده تنها در مراحل نهایی برای وظایفی چون پیاده‌سازی API کاربر-محور و گسترش سازگاری (مانند پورت کردن پیاده‌سازی‌های پیش‌توکن‌ساز)، توسعه ویژگی‌های کم‌اهمیت‌تر مانند Padding، Truncation و نرمال‌سازی یونیکد، پورت کردن استراتژی‌های SIMD بین AVX512, AVX2 و NEON، و در نهایت پروفایلینگ و حذف شاخه‌ها برای استخراج آخرین ۴ برابرِ افزایش سرعت از طریق سلسله‌مراتب کش، از هوش مصنوعی کمک گرفته است. این روند بهینه‌سازی دقیق در لایه‌های پایین، یادآور رقابت‌های سخت‌افزاری است که در آن ابزارهایی نظیر Inkling در عملیات‌های عامل‌محور با بهینه‌سازی‌های مشابه سعی در پیشی گرفتن از رقبا دارند.

وقتی توکن‌سازی کل اینترنت در عرض چند ساعت ممکن شود، گلوگاه اصلی از پردازش متن به سرعت خواندن از دیسک (Disk IO) و پهنای باند شبکه منتقل می‌شود. برای متخصصان، این یعنی زمان کمتری در انتظار خوشه‌های پیش‌پردازش و هزینه‌های محاسباتی پایین‌تر برای سازمان‌دهی داده‌ها.

برای تایید این دستاوردها، کاربران می‌توانند بنچمارکی را با دستور uvx --with tokenizers gigatoken bench در مقابل هر ریپازیتوری مدل HuggingFace اجرا کنند. این به توسعه‌دهندگان اجازه می‌دهد پیش از تغییر خطوط لوله تولیدی خود، تایید کنند که خروجی‌ها دقیقاً یکسان هستند. برای مثال، یک تست روی openai-community/gpt2 در M4 Max نشان داد که Gigatoken برابر با ۱۳۵۳.۱۳ برابر سریع‌تر از HF بود و ۲۰,۴۰۱ سند را به‌طور کامل و دقیق تطبیق داد.

گام بعدی شما

• اگر از مدل‌های Llama 3 یا DeepSeek استفاده می‌کنید، ابزار را با دستور uvx --with tokenizers gigatoken bench روی ریپازیتوری مدل خود تست کنید.
• خروجی‌های Gigatoken را با نسخه‌های HuggingFace تطبیق دهید تا از صحت ۱۰۰ درصدی توکن‌ها مطمئن شوید.
• در صورت استفاده از محیط ویندوز، حتماً از WSL برای بهره‌مندی از حداکثر سرعت SIMD استفاده کنید.

اما داستان سخت‌افزاری این تحولات حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell برای درک مقیاس جدید محاسبات مراجعه کنید.