モ。〜モデル選定のヒントについて〜

はじめに

はじめまして。
SapeetでSWEをやっている淺井です。

昨今のAIブームを皮切りに、LLMを使ったサービスのリリース報告は枚挙にいとまがありません。
エンタープライズはもちろん、個人開発の領域でもこれらの仕組みを組み込んだ新規サービスに挑戦したい、という声は多く見かけるかと思います。

私自身もLLMサービスを使ったサービス開発の経験が増えてきました。しかし、実際に運用を考えると「性能以外の落とし穴」に悩まされることが多く、今回はその中でも 特にハマりやすい落とし穴を紹介したいと思います。

Trap1: 利用規約における年齢制限

LLMモデルの技術選定というテーマにおいては、次々と高性能なモデルが登場し、つい「性能」で技術選定したくなりますよね。

しかし、まず最初に見るべきは利用ユーザーの年齢です。

というのも、LLMのサービス提供会社は利用規約内で年齢制限を設けているためです。

利用モデル	年齢制限	参考
OpenAI系列	13歳以上	https://openai.com/ja-JP/policies/terms-of-use/
Gemini系列	18歳以上	https://ai.google.dev/gemini-api/terms
Claude系列	18歳以上	https://www.anthropic.com/legal/consumer-terms
Mistral系列	13歳以上	https://legal.mistral.ai/terms
Grok系列	13歳以上または居住国での最低年齢に達していること	https://x.ai/legal/terms-of-service
Llama系列	法的に同意可能な年齢であること	https://huggingface.co/meta-llama/Meta-Llama-3-70B/blob/main/LICENSE

自分の場合、元々gemini-2.5-flashを利用しようとしていたのですが提供サービスが主に若者向けであることから、年齢制限の兼ね合いでOpenAI系列のモデルに切り替える必要が生じました。

さて、次に以下のような疑問が生じるかと思います。

年齢制限がないLLMモデルはないのか？

まず、例外の１つ目としては「Google Workspace for Education」を利用することです。
https://support.google.com/a/answer/6356441

これは教育機関向けに提供されている特別なプランで、一般の利用は不可です。
弊社でも使えないか探ってみたのですが、ダメでした。

次に、これらの議論の中でよく話題になるのが、「Microsoft Azure経由でLLMモデルを呼び出すなら年齢制限なしで大丈夫」という論です。

たしかに、ネット上ではそういった記述をしているサービスも見かけます。

これを検証するべく、実際にMicrosoftの関係者などへヒアリングを行いましたが、規約に関する明確な回答は得られず、代替としてMicrosoftオフィシャルのAzureコミュニティサイトに直接投稿してみました。

結論、年齢制限がない、とは言い切れないということでした。

Microsoft Azureの規約には制限がなくても、利用するモデルの提供会社の規約に則る、というのが現状の考え方のようです。法的解釈次第かもしれませんが、解釈の方向性を模索していくのはなかなか現実的ではないので、性能やoptoutなどの指標を考慮する前にまずは年齢制限をクリアしたLLMモデルかどうかで足切りしていくのが良いかと思います。

Trap2: 同時処理可能数

古典的なWebアプリケーションにおいては、同時アクセス数、同時接続数などシステムの性能を表す指標がいくつかありました。

一方で、LLMを利用したアプリケーションにおいては、TPMやRPMといった指標をベースとしてシステムの性能を考えていく必要があります。

TPM(Token Per Minute)制限
１分間に扱えるトークンの上限

RPM(Requests Per Minute)制限
１分間に扱えるリクエスト数の上限

Microsoft Azureを経由してgpt-4o-miniを利用する場合：

デプロイの種類	TPM制限	RPM制限
Standard	450,000	270,000
Global Standard	2,000,000	12,000

例えば、Standardデプロイの場合、１分間にどれだけの処理をこなすことが出来るでしょうか？
仮に１回のセッションに係る総消費トークン数を n とします。私が関わっていたサービスだと、ざっくり20,000tokenほど消費する想定でしたので、当初は以下のような計算をしていました。

450,000 TPM / n tokens = 450,000 / 20,000 = 22.5(セッション/分)

これは間違いであり、答えは「計算できない」が回答となります。
（理由は、Standard デプロイでは同一リージョン内の他ユーザーの利用状況によって、実効的な TPM が変動してしまうためです。この点については、後述のセクションで詳しく触れます。）

Microsoft AzureにおけるStandardデプロイとGlobal Standardデプロイに関して

Standardデプロイの問題点

事前に指定したリージョン内でLLMへのリクエストを処理する方式です。
例えば、japaneastを指定してデプロイされたLLMモデルは、japaneastで処理を実行します。

これの何がまずいのでしょうか？

前提として、我々はLLMを実行するためのGPUリソースを奪い合う関係にあります。
そのため、japaneastリージョンで膨大な量のLLM処理を実行しているユーザーがいる場合、他ユーザーの利用状況の影響を受けてしまい、TPM、RPMが設定値よりも低い上限でレートリミットに達してしまいます。

先ほど計算例を出してみましたが、これに他ユーザーの利用状況が加わってくるため、「計算できない」というわけです。

Global Standardデプロイの問題点

指定したリージョン内でLLMへのリクエストが発生した場合、世界中のデータセンターからGPUリソースが空いているリージョンを探してそこにリクエストを転送して処理させる方式です。

Standardでは他ユーザーの利用状況により、TPM、RPMが設定値よりも低い上限でレートリミットに達する可能性がありましたが、Global Standardではこの問題が解消されており、リソースが空いているリージョンをあらかじめ計算してから処理を行うのでレートリミットが上がる可能性があります。

ただし、どのリージョンで処理されるかは事前に確認することができないという問題があり、セキュリティが厳しい大手や官公庁といった組織で採用する際は一定のコミュニケーションが必要になってくるはずです。

PTUについて

確実なトークン消費に備える場合、選択肢に入ってくるのが PTU(Provisioned Throughput Units) です。
これは、予め指定されたスループット（一定時間内に処理出来るリクエストの量）を予約しておく仕組みとなっており、他社の利用状況などの変数に影響されない形でサービスを提供することが出来るようになります。

ただし、購入の際は「最小PTU」といって最低数が決まっているほかそれなりに値段も張るので、まだ実運用に乗せていないサービスなど、実際の消費トークン数が未知数の場合は「従量課金->PTU」、すでに消費されるトークン数がわかっており確実に備えたい場合は「PTU」といった使い分けをするのが良いかと思います。

Trap3: TPM、RPM、対応リージョン数の差について

セキュリティ要件が厳しいクライアントでは 処理リージョンを固定できる Standard が好まれます。

しかし、性能面では以下の落とし穴があります。

StandardではGlobal StandardよりもTPM, RPM, 対応リージョン数上限が低くなりがち

以下に例を掲載しましたが、StandardデプロイはGlobal Standardの3分の1、もしくはそれ以下でTPM, RPMが提供されていることが多いため、セキュリティ要件を満たすためにStandardを採用した場合、利用可能な全てのリージョンでの負荷分散したとしても上限のレートリミットが低くなるケースがあります。

例. Microsoft Azureを経由してgpt-4o-miniを利用する場合

デプロイの種類	TPM	RPM	対応リージョン数
Global Standard	2M	12K	28
Standard	450K	2.7K	7

これらを踏まえ、StandardとGlobal Standardのどちらを使うかを検討した方が良いでしょう。

まとめ

LLMモデルの技術選定というテーマは最近出てきたこともあり、なかなか議論が煮えきっていないところがあるかと思います。まず最初に「性能」に飛びつくのではなく、「利用ユーザー要件」「サービス要件」「セキュリティ要件」「SLO要件」などをしっかりと整理した上で、それに合致した機能を提供しているLLMモデルを選択する、ということがより良い選択に近づく一歩になるかと思います。