AI、推論、トークンの世界へようこそ！
さて、みなさん、ここで一旦止めましょう。 「トークン」や「モデル」という言葉がまるでTikTokの若者言葉のように飛び交っていますが、多くの場合、それは誤解されています。
言ったことは変えません。
推論をベースにしたアプリケーションの構築方法、トークンの生成と利用場所、そしてその全要素がどのように連携しているのかを明確にお伝えします。 どうぞコーヒーを用意して、さっそく始めましょう。
推論サーバーとは何か、ご説明します。
本当はここから始めるべきではないのですが、あえてそうします。 「推論」と言うとき、大規模言語モデル（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を使ってあなたが作ったアプリとやり取りします。 さあ、完成です！ クライアントからアプリ、推論サーバーへ、そして戻るまでのメッセージ通信が完結しています。
そうです、実はデータ層を推論層に置き換えた三層ウェブアプリケーションの新しい形に過ぎません。 きっと期待外れに感じますよね。
AIアプリの最も基本的な形は、データ層を推論サーバーに置き換えた3層のWebアプリケーションです。
- JSONリクエストを受け取り、必要に応じて検索強化生成（RAG）を行い、その後JSONで推論サーバーを呼び出します。 RAGとは通常、ユーザーのクエリの埋め込みを作成し、ベクターまたは検索インデックスで類似のコンテンツを検索し、それらの断片をプロンプトに組み込むことを指します。 これらすべてがまだJSONとしてのトラフィックのままです。 モデルのトークンはまだ生成されていません。
- 推論サーバーは JSON を解析し、テキストをモデルのトークンに分割し、コンテキストやクォータを確認して、互換性のあるリクエストをまとめ、モデルを実行し、その後出力トークンをテキストに復号します。 結果の JSON 応答を呼び出し元に返します。 ストリーミング中は、トークンを生成しながら順次復号して送信します。 ほとんどの API は、入力および出力のトークン数を示す使用状況情報を提供します。
それが推論です。 従来から私たちが大切にしてきた運用の規律に叶う、新しいタイプのアプリケーションワークロードであり、セッションやCookie、クエリではなく、トークンやコンテキスト、ストリームで示しています。
では、トークンはどこにあるのでしょうか？
多くの方がここでつまずき、用語の基本原則に反する使い方をしてしまいます。 トークンとは、LLMが処理する単語の単位です。 トークンは推論サーバ上のトークナイザーによって正式に生成されます。
コストの予測やローカルレート制限のために、アプリにトークナイザーを組み込み事前にトークン数をカウントできますが、最終的なトークン数の判定は推論スタックで行います。 トークンはモデル内の表現であり、ネットワーク トラフィックではありません。通信はJSONテキストで行われます。 APIが明示的に返さなければ、トークンIDは表示されません。
インフラはデフォルトでトークンを認識しません。 代わりにJSONを扱います。 トークンは通信経路に現れません。 インフラにトークンを処理させたいなら、同じトークナイザーでゲートウェイでカウントするか、モデルサーバーが出すカウントを利用してください。 トークンはAIの通貨ですが、あなたが取り出さなければほとんどが推論スタック内にとどまります。
インフラストラクチャにおける推論の影響
推論は不思議なものではありません。 新しい調整項目を持つアプリケーションワークロードです。 トラフィックはJSON形式です。 トークンはモデルの単位です。 埋め込みはベクトルです。 これらを混同すると、誤った制御を設計し、誤った料金を設定し、誤ったレイヤーを解析することになります。 例えば、トークン数ではなくJSONサイズでルーティングすると、長いコンテキストのリクエストでモデルが過負荷になる可能性があります。
インフラをトークンに基づいて動かしたいなら、その方法を教えてください。 ゲートウェイにトークナイザーを設置するか、モデルサーバーが出すカウントを利用しましょう。 そうしなければ、ルーターはテキストとして認識し、テキスト単位で判断するため、請求はトークン単位で積み重なってしまいます。 トークナイザーはモデルに合わせる必要があります（例：GPT-4のトークナイザーはLLaMAのものと異なります）ので、正確なカウントのために必ず一致させてください。 トークナイザーが合わないと、コストや制限の計算が誤ってしまいます。
可用性を単なる稼働状態としてではなく、実際に使える正しい状態として扱いましょう。 1秒あたりのクエリ数やキャッシュヒットと同じように、1秒あたりのトークン数、最初のトークンまでの時間、コンテキスト障害（コンテキストウィンドウの制限超過や飽和による一貫性のない出力など）を追跡してください。 ログは本気で管理しましょう。 推論トラフィックは、明示しない限りトレーニングデータではありません。 プロンプトや出力を保存するなら、しっかり保護しましょう。
正確に名前を付けましょう。 適切なレイヤーを計測しましょう。 コスト超過を防ぐために、ゲートウェイでのトークンベースのクォータのように、意味のある部分に制限を設けましょう。 そうすれば推論は、スタックの他の部分と同様に予測可能で手頃な費用となり、快適な環境を実現できます。 トークンはネットワーク帯域ではなく、モデル内の意思決定を購入するためのものです。 正しい名前で呼ぶことで、ユーザーは満足し、請求もすっきりします。