AI-LECTURER 速報課|2026-07-23|約 26 分鐘

GigaToken:把「分詞」從喝咖啡的等待時間,壓縮成眨眼的瞬間

取材:GigaToken: ~1000x faster Language model tokenization(Hacker News(AI 高人氣))
📍 真實場景
阿凱,一家做企業內部知識庫(RAG)搜尋系統的新創資料工程師

正在把公司內部十幾萬份PDF與會議記錄轉換成向量資料庫前,要先跑一輪分詞前處理

😖 卡住的地方:光是分詞這一步,用HuggingFace tokenizers跑完幾十GB的文字檔就要好幾個小時,整條pipeline卡在這裡動不了,老闆一直問『今天能不能上線』
💡 這堂課會告訴他有個幾乎不用改程式碼的工具,可以把分詞速度衝高到幾百倍,以及這種『快幾百倍』的宣稱背後藏著什麼樣的權衡,讓他懂得怎麼判斷要不要換

🧭 這到底是什麼(白話版)

想像你要教電腦讀懂一句話,電腦沒辦法直接「看」文字,得先把句子切成一塊一塊的「代號」,這個切字的動作就叫 分詞(tokenization)讓電腦讀文字前,先把句子切成一小塊一小塊的「代號」,讓模型看得懂。每一個AI模型在訓練和使用前,幾乎都要先做這件事,資料量一大,分詞花的時間就很可觀。

目前業界最常用的分詞工具箱是 HuggingFace tokenizers目前最多AI模型專案使用的「分詞工具箱」,像業界標配的瑞士刀,OpenAI自家模型則常用 tiktokenOpenAI自己推出的分詞工具,GPT系列模型常用它。這兩套工具其實已經是用 Rust一種以「快」和「安全」聞名的程式語言,許多追求極致效能的工具都用它寫 寫成的 多執行緒(multithreaded)讓電腦同時動用很多顆運算核心一起處理同一件事,而不是一顆一顆慢慢做 版本,理論上已經不算慢。

但這篇文章的主角 GigaToken 宣稱,用同樣的硬體,它還能再快上幾百到上千倍,而且是 drop-in replacement不用大改原本程式碼,只要換一行「進口」的寫法,其他照舊還能動——意思是你原本用HuggingFace或tiktoken寫好的程式,幾乎不用改就能套用。它的關鍵賣點反映在 吞吐量(throughput)衡量「單位時間內能處理多少資料量」的指標,這裡用GB/s(每秒幾GB)來算 上:原本工具一秒鐘只能處理幾十MB文字,GigaToken能衝到一秒鐘20幾GB。

🎯 為什麼值得你花時間

前處理不再是隱形瓶頸資料前處理常常是整條AI開發流程裡最不被重視、卻最容易卡住工程排程的一段。當分詞從「好幾小時」變成「幾秒鐘」,整條pipeline的交付時程會被重新改寫。
不用重寫,風險最低的優化drop-in replacement的設計代表工程師不必冒著「改壞正式環境程式碼」的風險,就能享受加速效果,這是所有優化選項裡採用門檻最低的一種。
省下的是算力帳單和等待成本雲端運算資源越來越貴,能用更少的CPU核心、更短的時間做完同樣的前處理工作,直接反映在帳單金額和交付時程上,對小團隊尤其有感。

⚙️ 它是怎麼運作的

1
把原本的tokenizer包起來(相容模式)你把原本HuggingFace或tiktoken的tokenizer丟進去,GigaToken用 `.as_hf()` 或 `.as_tiktoken()` 把自己「偽裝」成跟原本工具一樣的介面。
2
用Rust重新實作同一套分詞規則GigaToken底層用Rust重新寫了一套分詞引擎,並且花了大量力氣確保輸出結果跟原本工具逐字元一致,讓你換工具不會換出不同的結果。
3
把資料平行拆給多顆CPU核心文字資料被切成很多份,同時丟給機器上的每一顆運算核心處理,核心數越多,理論上能榨出的速度就越快。
4
(進階)用原生API跳過Python搬資料的開銷如果你願意改用GigaToken自己的API直接讀取檔案,Rust引擎可以自己讀資料,不必透過Python一筆一筆傳遞,因此比相容模式再快上一截。
5
吐出跟原本格式相同的token結果不管走哪種模式,最後輸出的token id格式都跟原本工具一樣,後面接的模型訓練或推論程式完全不用改。
同一份11.9GB文字檔,不同分詞工具處理速度比較(AMD EPYC 9565,72核心x2,節錄自原始benchmark)
模型系列GigaTokenHuggingFace tokenizers相對HF的倍數
GPT-224.53 GB/s24.8 MB/s989×
Llama 3 / 3.1 / 3.222.15 GB/s48.5 MB/s457×
DeepSeek V3 / R1 / V419.69 GB/s26.2 MB/s750×

🔍 程式碼漫遊(點有 ● 的行看白話講解)

這段程式示範怎麼用「相容模式」,幾乎不改原本程式碼就把HuggingFace tokenizer換成GigaToken加速版

import gigatoken as gt
💬 先把GigaToken這個工具箱借進來,取個好打的名字gt
from transformers import AutoTokenizer
💬 這行完全不用改,還是用你原本熟悉的HuggingFace載入方式
hf_tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen3-8B")
💬 照舊,先用HuggingFace載入你原本要用的分詞規則
tokenizer = gt.Tokenizer(hf_tokenizer).as_hf()
💬 整段程式唯一多出來的關鍵一行——把原本的tokenizer「包」進GigaToken,並要求它「假裝自己還是原本的HuggingFace tokenizer」,讓後面接的程式碼完全不用改
texts = ["這是一段測試文字", "這是另外一段"]
💬 準備要分詞的一批文字
tokens = tokenizer.encode_batch(texts)
💬 呼叫方式跟原本一模一樣,但背後是Rust在多核心平行運算,速度差了好幾百倍
print(tokens)
💬 印出結果,格式跟原本HuggingFace輸出的token id完全相同

🛠️ 動手做:在你的電腦上實測:比較GigaToken與HuggingFace tokenizers的分詞速度

這是一個真實小專案:下載(或複製)檔案,照步驟在你電腦上跑起來。

📄 benchmark_compare.py ⬇ 下載
"""
比較 HuggingFace tokenizers 與 GigaToken 的分詞速度
使用方式:python benchmark_compare.py
"""
import time
from transformers import AutoTokenizer
import gigatoken as gt

MODEL_NAME = "gpt2"
SAMPLE_TEXT = "AI 教案工廠正在測試分詞速度。" * 5000  # 造一份夠大的測試文字


def run_huggingface():
    tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME)
    start = time.perf_counter()
    tokenizer.encode(SAMPLE_TEXT)
    return time.perf_counter() - start


def run_gigatoken():
    hf_tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME)
    fast_tokenizer = gt.Tokenizer(hf_tokenizer).as_hf()
    start = time.perf_counter()
    fast_tokenizer.encode(SAMPLE_TEXT)
    return time.perf_counter() - start


if __name__ == "__main__":
    hf_time = run_huggingface()
    print(f"HuggingFace tokenizers 花費:{hf_time:.4f} 秒")

    gt_time = run_gigatoken()
    print(f"GigaToken(相容模式)花費:{gt_time:.4f} 秒")

    if gt_time > 0:
        print(f"加速倍數:約 {hf_time / gt_time:.1f} 倍")
  1. 開啟PowerShell,確認已安裝Python 3.12(可執行 py -3.12 --version 檢查)
  2. 建立虛擬環境:py -3.12 -m venv .venv
  3. 啟用虛擬環境:.venv\Scripts\Activate.ps1
  4. 安裝需要的套件:pip install gigatoken transformers
  5. 把上面的 benchmark_compare.py 存到你的專案資料夾
  6. 執行程式:python benchmark_compare.py
  7. 觀察輸出的秒數與『加速倍數』,實際感受一下差距有多大

🧠 工程思維透鏡(資深工程師看到的是什麼)

🔭 為什麼GigaToken敢說『跟HF輸出幾乎一模一樣』,卻又承認相容模式『沒有原生API快』?
這是典型的「正確性 vs 效能」權衡。要保證跟HuggingFace輸出逐字元一致,就得在Rust引擎裡重現HF原本分詞規則的每一個小怪癖(例如特殊字元的處理順序),這些相容性檢查會吃掉一部分效能。資深工程師看到這種說明,會知道相容模式和原生API其實是同一套引擎開了兩個不同嚴謹程度的門,選哪個要看你是想穩穩接軌舊系統,還是願意重寫換取極致速度。
🔭 為什麼標題敢寫『1000x』,但benchmark表格裡實際看到的多半是幾百倍?
這反映了行銷數字與你實際會拿到的數字之間的落差——1000x是在最理想條件(原生API、特定模型GPT-2、144核心伺服器)測出來的峰值,一般人用相容模式接舊系統,實際拿到的常常是四五百倍。工程師讀效能宣稱時,要養成先找「最保守情境」數字的習慣,而不是被封面數字牽著走。
🔭 為什麼作者特別強調『HF tokenizers和tiktoken本來就已經是多執行緒Rust』,還能贏對方幾百倍?
這句話其實是在提前堵住讀者的疑問:『你們該不會只是比單執行緒版本快吧』。它暗示真正的效能差距不是來自有沒有平行化,而是演算法設計、記憶體配置、以及I/O路徑(例如原生讀檔 vs 透過Python搬資料)的整體最佳化。這提醒工程師:看效能比較時要先確認兩邊的起跑點公不公平,作者主動說明起跑點相同,可信度就高一截。

📝 隨堂考(點選答案,立即回饋)

Q1. GigaToken的『相容模式(compatibility mode)』主要用途是什麼?
✅ 相容模式犧牲一點點效能,換取跟原本工具『分詞結果一模一樣』,這樣舊程式碼才能直接換過來用而不出錯。
Q2. 根據原文benchmark,GigaToken的『原生API』和『相容模式』相比,效能上有什麼差異?
✅ 原文提到用GigaToken自己的API可以讓Rust直接讀資料、跳過額外開銷,達到接近1000x;但透過Python資料結構傳遞(相容模式)仍會有開銷。
Q3. 文中benchmark測試機器是144核心的伺服器,這對我們判讀『1000x』這個數字有什麼提醒?
✅ 效能數字很依賴測試環境的硬體規格,核心數越多,平行化能榨出的加速效果通常越明顯,換到自己機器上實測結果可能會不同。
Q4. 為什麼GigaToken可以宣稱自己是『drop-in replacement』?
✅ drop-in replacement的關鍵是提供相容包裝(as_hf()、as_tiktoken()),讓呼叫方式跟原本工具幾乎一樣,降低採用門檻。
Q5. 分詞(tokenization)在AI開發流程中主要負責什麼?
✅ 分詞是語言模型讀取文字前必經的前處理,把句子拆成token(代號),才能轉成數字送進模型運算。

🃏 翻牌記憶卡(先想答案,再點開對答)

Tokenization(分詞)點我翻面
把文字切成模型看得懂的最小單位「token(代號)」的前處理步驟
Drop-in replacement點我翻面
幾乎不用改程式碼、只要換一行載入方式,就能直接替換掉原本工具的設計
相容模式 vs 原生API點我翻面
相容模式求穩,輸出跟舊工具一致但較慢;原生API最快,但要改寫呼叫方式
吞吐量(throughput)點我翻面
單位時間內能處理的資料量,這裡用GB/s衡量分詞速度
為什麼還能贏『已經是多執行緒Rust』的對手點我翻面
差距來自演算法與記憶體、I/O路徑的整體最佳化,不是單純有沒有平行化

✅ 離開前自測(全勾=這課真的學會了)

0%