トークンとトークナイザー

トークンは、LLMが文章を処理する最小単位です。コンテキスト長も生成速度(tokens/秒)もAPI料金も、すべてこの単位で数えられます。そして日本語ユーザーには重要な事実がひとつ — 日本語は英語よりトークン効率が悪いのです。

トークナイザーの仕事

トークナイザーは文章をトークン列に切り、番号に変換します。単語単位でも文字単位でもなく、頻出パターンをまとめた「よく出る部品」単位(BPE系)で切るのが現代の主流です。例えば英語の "the" は1トークン、"tokenization" は2〜3トークンに分かれます。各モデルは固有の語彙表(数万〜25万種)を持ち、モデルが違えば同じ文章でもトークン数は変わります。

日本語の効率問題

語彙表は学習データの頻度で決まるため、英語中心に作られたトークナイザーでは日本語が細切れになります。目安として日本語はおおよそ1〜2文字で1トークン(モデルによる)。英語なら1トークンで単語1個運べるところ、日本語は同じ内容を伝えるのに1.5〜2倍のトークンを使いがちです。これは実用上3つの意味を持ちます:

• 実効コンテキストが目減りする — 「8Kトークン」は日本語だと体感4〜6K文字程度
• 体感速度が割引される — 同じ20 tokens/秒でも、届く日本語の文字数は英語より少ない
• 日本語向けモデルの意義 — 国産モデルや多言語語彙の大きいモデル(Qwen系など)は日本語のトークン効率が良く、同じ設定でも実質的に長く・速く感じられます

tokens/秒の体感目安

当サイトの実測ベンチマークで使っている目安をそのまま載せます: 6〜10 t/s ≒ 人が黙読する速度 / 15 t/s以上 = 快適な対話 / 30 t/s以上 = 非常に快適。生成速度はメモリ帯域律速なので、モデルの重みサイズ(=量子化後のGB数)にほぼ反比例します。

マニアック小ネタ

• 語彙表が大きいほど埋め込み層も大きくなり、小型モデルではパラメータの1〜2割が語彙関連ということもあります(VRAMにも効く)
• 「9.11と9.9はどちらが大きい?」系の失敗は、数値が桁ごとに不自然なトークンに切られることが一因と考えられています(諸説あり)
• 同じ理由で、文字数指定(「50文字で」)はLLMが苦手です。トークンは数えられても文字は「見えて」いません

関連用語

• コンテキスト長 — モデルが一度に覚えていられる会話・文書の長さ。長いほどKVキャッシュがVRAMを食う
• KVキャッシュ — 会話の文脈を保持する作業メモリ。GQA・MLA・ハイブリッド注意でサイズが数十倍変わる
• Transformer — 現代のLLMほぼ全ての土台となるアーキテクチャ。注意機構(Attention)で文脈を読む

参考資料(出典)

• https://huggingface.co/docs/transformers/tokenizer_summary

▶ あなたのPCで動くモデルを自動判定する(スペック送信なし・ブラウザ内完結)