宅配便の送料は、荷物の重さではなく箱の数で決まることがあります。LLM の世界でも、料金や処理の重さを決めるのは文字数ではなく、トークンという単位の数です。
トークンは、LLM が文章を読み書きするときに使う数え方の単位です。長い文章ほどトークンは増え、そのぶん料金も待ち時間も増えやすくなります。
同じ200文字でも数が違う
トークンは、文字と一対一には対応していません。同じ「200文字」でも、日本語か英語か、記号やプログラムのコード、URL が混ざっているかで、分け方が変わり、トークンの数も変わります。
しかも、数え方はモデルごとに違います。別のモデルに切り替えると、同じ文章でも料金や上限への届きやすさが変わります。文字数で見積もると外しやすいので、トークンで管理するのが基本です。
請求書と、途中で切れる答え
トークンの数は、こうした場面で効いてきます。
- チャットボットを運用していて、API の費用が想定より高くなった
- 回答が途中で切れる、要約が粗くなる
- RAG で、参照させる資料をどこまで増やすか決めたい
- 答えは短いのに、返ってくるまでが遅い(入力のトークンが大きすぎないかを疑う)
上限を決めて使った量を見える場所に
まず、入力と出力のトークンに上限を決めます。上限なしで運用すると、費用の事故につながります。長い資料はそのまま渡さず、要点を抜き出したり分割したりして、トークンを節約します。
使った量を月ごとに見える形にしておけば、プロンプトを直したときの効果も測れる。モデルを切り替えるときは、同じ入力で数え直してから本番に反映してください。
