Gemini 3.5の速度を実測した：TTFT・TPSでGPT-4.1と比較

AIアプリの「LLM 応答速度 改善」を左右する最新モデル最速ランキング

AIアプリケーションの開発現場において、「モデルの賢さ」と並んで重要視されるのが「応答の速さ」です。ユーザーからの入力に対して即座に反応を返せるかどうかは、プロダクトのUX（ユーザー体験）を大きく左右します。OpenAI公式 APIドキュメントなどでも、ユーザー体験向上のための速度最適化の重要性がたびたび言及されています。LLM 応答速度 改善は、現代のMLエンジニアやAI開発者にとって喫緊の課題と言えるでしょう。

LLMの世代が上がるにつれて、回答の品質や推論精度は向上している一方で、応答速度は低下する傾向があります。GPT-4.1 はその中でも速度を維持したモデルとして注目されており、「速さが必要な用途での基準」となっていました。そこへ新たに登場した Gemini 3.5 が、この GPT-4.1 と速度面でどう渡り合えるのかを検証したのが本記事の趣旨です。Gemini 系（3.1 / 3.5）と GPT-4.1 系を対象に、ストリーミング応答のレイテンシを定量的に計測・比較しました。

結論から申し上げると、「初動速度（TTFT）」はGemini 3.5 系と比べてGPT-4.1系の方が相対的に速い結果となりました。gpt-4.1 では平均 625ms という立ち上がりを見せています。

本記事では、計測の指標についての解説を交えながら、どのようなユースケースでどのモデルを選ぶべきか、データに基づく具体的な選定ガイドを提示します。

評価指標：Gemini GPT-4 TTFT 速度とTPSとは？

詳細なベンチマーク結果を見る前に、今回の検証で採用した4つの重要な指標（TTFT、Total、OutTok、TPS）について解説します。これらはAPIの性能を測る上で、それぞれ異なる意味を持ちます。Gemini GPT-4 TTFT 速度の違いを正確に理解するための前提知識となります。

TTFTとTotal：チャットUIの沈黙時間を決める

TTFT（Time To First Token） 最初のストリームチャンクが返ってくるまでの時間（ms）です。今回はストリームAPIを呼び出した瞬間から、ループ処理に最初のチャンクが届くまでを計測しています。 ユーザーが「送信ボタンを押してから、画面に最初の文字が出始めるまで」の待ち時間に直結する最重要指標です。この時間が長いほど、ユーザーはシステムがフリーズしたようなストレスを感じやすくなります。

Total（総時間） ストリーム完了までの全所要時間（ms）です。生成全文が揃うまでの時間であり、バッチ処理や非ストリーミングUIにおいては、実質的にこれが体感時間となります。全体の処理完了までの長さを測るために不可欠な数値です。

TPSとOutTok：LLM トークン生成速度の指標

OutTok（出力トークン数） モデルが生成したトークン数です。各チャンクの利用メタデータから取得した値を用いています。モデルによる回答の冗長さを示すと同時に、APIの課金単位にも直結する重要な要素です。

TPS（Tokens Per Second） 出力トークン数 ÷ 総時間（tokens/秒）で算出される、LLM トークン生成速度を見るための純粋なデコード指標です。計算式は outputTokens / totalMs * 1000 となります。 ただし、総時間（Total）にはTTFTも含まれるため、短文出力の際はTTFTのウェイトが大きくなり、TPSが低く出やすい点に注意してデータを見る必要があります。

LLM API スループット 比較と総合的な速度比較

それでは、全プロンプト（短文・中文・長文）を統合した総合的な結果を見ていきましょう。LLM API スループット 比較としても、各モデルの特性が明確に表れるデータが得られています。

全モデルの平均値集計

まずは全体のスループットとレイテンシの平均値です。

全体を通じて、GPT-4.1系の応答の早さ（avgTTFT）が際立っています。さらに、軽量モデルである gpt-4.1-nano や gemini-3.1-flash-lite のスループット（avgTPS）の高さも目立つ結果となりました。

TTFTランキング：体感応答速度のトップは？

チャットUIでの体感速度に直結する、TTFTのみを抽出してランキング化したものが以下です。

TTFTの観点では、GPT-4.1系の3モデルがトップ3を独占する結果となりました。最速の gpt-4.1 は平均 625ms と、1秒を大幅に下回る立ち上がりを見せます。一方のGemini系は、最速の思考無効化モデルでも 1,086ms と、GPT-4.1系に比べると一歩譲る形となりました。 ユーザーを待たせないリアルタイム性を重視するなら、GPT-4.1系が有力な選択肢となります。

プロンプト長別の横並び比較と「長文デコード」の落とし穴

全体平均だけでなく、要求する出力の長さ（Short / Medium / Long）によってモデルのパフォーマンスはどう変わるのでしょうか。詳細なLLM APIレイテンシ比較を行う中で、特に実務に影響を与えうる2つの重要なポイントを解説します。

gpt-4.1-nanoが示すGemini同等の高いスループット

注目すべきは gpt-4.1-nano のスループット（TPS）の高さです。 中長文デコードにおいて、gpt-4.1-nano の avgTPS は 115.7 に達し、軽量モデルの対抗馬である gemini-3.1-flash-lite (avgTPS: 105.4) とほぼ互角の性能を叩き出しています。さらに長文（Long）のみのTPSに目を向けると、両者とも 222 tokens/秒 という非常に高い生成速度を記録しています。 軽量で高速なモデルを求める場合、gpt-4.1-nano はコストパフォーマンスと速度のバランスに優れた有力な選択肢です。

gpt-4.1-miniに見られる長文デコード時の遅延リスク

一方で、実務上の落とし穴も確認されました。gpt-4.1-mini を長文（Long）で実行した場合、総時間（Total）が 29,531ms（約29.5秒）と突出して遅くなる現象が発生しました。 複数回の計測すべてで同様のオーダーで遅延したため、一時的なネットワーク要因ではなく、OpenAI側の長文デコード時のレート制限や可変キャパシティの影響である可能性が高いと考えられます。バッチ処理等で一度に大量のテキストを生成させる用途に gpt-4.1-mini を採用する場合は、この遅延リスクを考慮したアーキテクチャ設計が必要です。

Gemini 3.5の思考モード検証：Thinking有無でのレイテンシ差

Geminiの最新モデル gemini-3.5-flash の最大の特徴は、高度な推論を可能にする「思考ステップ（Thinking）」機能です。この機能が速度に対してどのような影響を与えるのかを検証しました。

推論モード（thinkingConfig）とは

Gemini API では、専用のパラメータを用いることで、思考ステップの強度を任意に調整できます。複雑な推論を必要とするタスクにおいて精度向上が期待できる一方で、最初の回答を返すまでに「思考」のための計算リソースと時間を消費します。

思考を無効化した場合の初動速度改善

今回は、デフォルト設定のままのモデルと、思考ステップを完全に無効化したモデルを比較しました。 デフォルト（thinkingあり）のTTFTが 5,329ms だったのに対し、思考無効化（nothinking）では 1,086ms という結果になりました。

結果として、思考を無効化することで初動速度（TTFT）が約5倍も改善しました。 内部で思考ステップを処理している分だけ最初のトークンが遅れるため、リアルタイムな応答性が求められるシーンでは、タスクの難易度に応じて思考の予算を制限するチューニングが不可欠です。

まとめ：ユースケース別・最適なLLM APIレイテンシ比較と選定ガイド

今回のLLM APIレイテンシ比較の結果を踏まえ、実務におけるユースケース別の最適なモデル選定指針をまとめます。プロダクトの要件に合わせて適切なモデルを選択してください。

チャットUIなど応答の速さ優先ならGPT-4.1系

カスタマーサポートのチャットボットなど、応答の速さを重視するストリーミングUIでは、今回の計測でTTFTが速かった GPT-4.1系（gpt-4.1, gpt-4.1-mini, gpt-4.1-nano）を選択肢として検討できます。沈黙時間を短くすることで、より自然な対話UXに近づけられるでしょう。

非ストリーミング・コスト重視ならgpt-4.1-nanoやGemini系

裏側でドキュメントの要約を一括処理したり、構造化データを生成したりするバッチ処理・非ストリーミング用途では、純粋な生成速度（TPS）とコストが鍵となります。 この領域では、非常に高いスループットを叩き出した gpt-4.1-nano や、gemini-3.1-flash-lite が最適です。 また、複雑な論理推論が必要なタスクであれば、初動の遅延を許容した上で gemini-3.5-flash の思考モードを有効にしてバッチ的に利用するアプローチも強力です。

次のステップ：自社プロダクトでのPoC検証

LLMの選定は、「賢さ」の評価だけでなく、プロダクトが求める「速さ」を明確に定義することが成功の鍵となります。本記事の定量データを参考に、ぜひご自身の開発プロジェクトに最適なモデルでAPIのPoC検証を開始し、実際のワークロードでのパフォーマンスを確認してみてください。