AI、推論、トークンって何だろう！

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

さて皆さん、ここでいったん立ち止まりましょう。「トークン」や「モデル」といった用語が、TikTok動画で使われるZ世代のスラングのように飛び交っていますが、その使い方はほとんどの場合、完全に間違っています。

言いたいことは言いました。

推論ベースのアプリケーションがどのように構築され、どこでトークンが生成・消費され、さまざまな要素がどう組み合わさるのかを整理する時期は、とうに来ています。コーヒーを片手に、さっそく見ていきましょう。

推論サーバーとは

本来ならここから説明する必要はないはずですが、あえて説明します。「推論」とは、実際には大規模言語モデル（LLM）が膨大なデータを基に答えを導き出すプロセスを指します。LLMを直接呼び出すわけではありません。実のところ「LLM API」なるものは存在しません。そう呼んだら、母親のようにじろりとにらみますよ。

推論の呼び出しに使用するAPIは、なんと、推論サーバーを経由します。

推論サーバーはAIモデルのランタイムです。アプリケーションサーバーがJavaをはじめとする多くの開発言語のランタイムであるのと同様です。通常、推論サーバーを使用せずにモデルをローカルで実行することはありません。一般的な選択肢には、Ollama、vLLM、NVIDIA Triton、HuggingFace Text Generation Interface（TGI）があります。

アプリケーションサーバーに通常アプリケーションパッケージをデプロイするのと同様に、推論サーバーには「AIパッケージ」（モデル）をデプロイします。推論サーバーは、テキスト生成、トークン化、埋め込みなどのモデル推論タスクに特化した最小限のAPIエンドポイント（RESTまたはgRPCの/generate、/completions、/embeddingsなど）を介して、AIモデルの機能を提供します。

推論サーバーとやり取りするには、アプリを構築します。そう、従来型のアプリケーションです（もちろん、モダンなアプリケーションの場合もあります）。そして、そのアプリが推論サーバーと通信します。

ユーザー側にも、ブラウザまたはスマートフォンで利用するアプリがあり、通常はごく一般的なAPIを介して、構築したアプリと通信します。これで、クライアントからアプリ、推論サーバーへと進み、再びクライアントに戻る一連のメッセージフローが完成します。

そう、実のところ、3層Webアプリケーションのデータ層を推論層に置き換えた新しい形にすぎません。期待外れもいいところですよね。

最もシンプルなAIアプリは、データ層を推論サーバーに置き換えた3層Webアプリケーションです。

1. JSONリクエストを受信し、必要に応じて検索拡張生成（RAG）を実行してから、JSONで推論サーバーを呼び出します。RAGでは通常、ユーザークエリの埋め込みを作成し、ベクトルインデックスまたは検索インデックスで類似コンテンツを検索して、そのスニペットをプロンプトに組み込みます。これらはすべて、依然としてJSON形式のトラフィックです。モデルのトークンはまだ生成されていません。
2. 推論サーバーはJSONを解析し、テキストをトークン化してモデルのトークンに変換します。次に、コンテキストとクォータを確認し、互換性のあるリクエストをバッチ処理してモデルを実行した後、出力トークンをデコードしてテキストに戻します。その後、呼び出し元にJSONレスポンスを返します。ストリーミングの場合、トークンは生成されるたびにデコードされ、送信されます。ほとんどのAPIには、入力トークン数と出力トークン数を示す使用量ブロックも含まれます。

これが推論です。これまで重視してきた運用規律が同じように成果につながる、新しい種類のアプリケーションワークロードにすぎません。ただし、今度はセッション、Cookie、クエリではなく、トークン、コンテキスト、ストリームという形で表されます。

では、トークンはどこにあるのでしょうか？

通常、ここで混乱が生じ、用語の最重要原則に反する言葉の使い方をしてしまいがちです。トークンは、LLMが処理する単語の単位です。正式には、推論サーバー上のトークナイザーによって生成されます。

コスト予測やローカルでのレート制限のために、アプリにトークナイザーを組み込み、事前にトークン数をカウントできます。ただし、最終的なトークン数は推論スタックで確定します。トークンはモデル内の表現であり、ネットワークトラフィックではありません。ネットワーク上で送受信されるのはJSONテキストです。トークンIDが確認できるのは、APIが明示的に返す場合に限られます。

デフォルトでは、インフラストラクチャからトークンは見えず、見えるのはJSONです。トークンはネットワーク上を流れません。インフラストラクチャでトークンに基づく処理を行うには、同じトークナイザーを使用してゲートウェイでトークン数をカウントするか、モデルサーバーが出力するカウントを利用する必要があります。トークンはAIにおける通貨のようなものですが、明示的に外部へ公開しない限り、その大半は推論スタック内にとどまります。

推論がインフラストラクチャに与える影響

推論は不可思議なものではありません。新たな調整項目を伴うアプリケーションワークロードです。トラフィックはJSON、トークンはモデルの処理単位、埋め込みはベクトルです。これらを混同すると、誤った制御を設計し、誤った対象に価格を設定し、誤ったレイヤーをデバッグすることになります。たとえば、トークン数ではなくJSONサイズに基づいてルーティングすると、長いコンテキストを含むリクエストによってモデルが過負荷になる可能性があります。

インフラストラクチャでトークンに基づく処理を行うには、その仕組みを組み込む必要があります。ゲートウェイにトークナイザーを配置するか、モデルサーバーが出力するカウントを利用してください。そうしなければ、ルーターが認識するのはトークンではなくテキストであるため、料金はトークン単位で加算される一方、判断はテキスト単位で行われます。正確にカウントするには、トークナイザーをモデルに合わせる必要があります（たとえば、GPT-4とLLaMAではトークナイザーが異なります）。トークナイザーが一致していないと、コストや上限の計算が不正確になる可能性があります。

可用性は、単に稼働しているだけでなく、利用可能で正しく動作している状態として捉えてください。これまで1秒あたりのクエリ数やキャッシュヒット数を追跡していたのと同様に、1秒あたりのトークン数、最初のトークンが生成されるまでの時間、コンテキスト関連のエラー（コンテキストウィンドウの上限超過や、コンテキストの飽和による一貫性のない出力など）を追跡します。ログは確実に記録してください。明示的に指定しない限り、推論トラフィックはトレーニングデータではありません。プロンプトと出力を保存する場合は、適切に保護してください。

物事を正しく捉え、適切なレイヤーを測定しましょう。コスト超過を防ぐためにゲートウェイでトークンベースのクォータを設定するなど、重要な箇所に制限を設けます。そうすれば、推論はスタックの他の部分と同様に、予測可能で、手頃なコストで運用でき、良い意味で平凡なものになります。トークンが担うのはモデル内部の判断であり、ネットワーク帯域幅ではありません。対象を正しく認識することで、ユーザーの満足度を維持し、請求額を抑えられます。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事