OrcaRouter 上で Gemini 3.6 Flash（google）と google/gemini-flash-latest（google）を直接比較——価格、コンテキストウィンドウ、レイテンシ、スループット、benchmark 品質を並べて示し、ワークロードに最適なモデルを選べます。
結論
価格面では google/gemini-flash-latest の方が安価で——入力 tokens で Gemini 3.6 Flash より約 67% 低いです。 レイテンシに敏感なワークロードでは、google/gemini-flash-latest の方が最初の token を早く返します。 benchmark 品質では、Gemini 3.6 Flash が総合指数で先行します。 google/gemini-flash-latest はコストと中央値レイテンシの両方で優れているため、既定の選択肢になります。ワークロードが重視する指標で Gemini 3.6 Flash が上回る場合に切り替えてください。
無料で開始 · 1 つのキーで両モデル · プロバイダー原価、トークン手数料ゼロ
Gemini 3.6 Flash と google/gemini-flash-latest はいずれも同じ OrcaRouter エンドポイント経由でプロバイダー原価・token 加算ゼロで利用できるため、両者の切り替えは 1 行の変更で済み、以下の数値がそのまま実際の支払額になります。
この比較はライブ料金、公表されている context window、そして OrcaRouter 自身が測定した latency と throughput を取得しており、ベンダーの宣伝用 benchmark に頼るのではなく、あなた固有のワークロードに対してコストとパフォーマンスを比較検討できます。適切な選択はほぼ常にトラフィックの形——プロンプト長、生成するテキスト量、ユーザーがどれだけ latency に敏感か、そして推論の難しさ——に左右されるため、以下のセクションでは 1 つの次元ずつこの判断を分解し、具体的な推奨で締めくくります。二つのモデルのいずれかで指標が欠けている場合、その行は推測せずに省いてあるので、ここでのすべての主張は実際の数値に裏づけられています。
ひと目で比較
| 指標 | Gemini 3.6 Flash | google/gemini-flash-latest | 結論 |
|---|---|---|---|
| 入力 $/100万 | $1.50 | $0.50 | 入力 tokens では、google/gemini-flash-latest は Gemini 3.6 Flash より 67% 安価です。 |
| 出力 $/100万 | $7.50 | $3.00 | 出力 tokens では、google/gemini-flash-latest は Gemini 3.6 Flash より 60% 安価です。 |
| コンテキスト | 1M | — | — |
| p50 レイテンシ | 4143 ms | 1856 ms | 中央値で、google/gemini-flash-latest は Gemini 3.6 Flash より 55% 速く応答します。 |
| スループット | 727 tok/s | 531 tok/s | Gemini 3.6 Flash は google/gemini-flash-latest より 37% 速く tokens をストリーミングします。 |
| 品質 | 8.0 | 6.0 | 総合品質指数で、Gemini 3.6 Flash は google/gemini-flash-latest より 33% 高いスコアです。 |
価格面では google/gemini-flash-latest の方が安価で——入力 tokens で Gemini 3.6 Flash より約 67% 低いです。 レイテンシに敏感なワークロードでは、google/gemini-flash-latest の方が最初の token を早く返します。 benchmark 品質では、Gemini 3.6 Flash が総合指数で先行します。 google/gemini-flash-latest はコストと中央値レイテンシの両方で優れているため、既定の選択肢になります。ワークロードが重視する指標で Gemini 3.6 Flash が上回る場合に切り替えてください。
両モデルを 1 つの API キーで。どちらから始めても、文字列を 1 つ変えるだけで切り替えられます。
API キーを取得どちらか一方を選ぶ必要はありません。両モデルとも OrcaRouter の同じ OpenAI 互換エンドポイントで提供され、上流プロバイダーの料金そのままでトークン手数料はゼロです。切り替えはモデル名の変更だけ — 2 つ目のアカウントも SDK も別の認証情報も不要です。
だからこそ、上のトレードオフを本番で扱えます。重視する指標で優れているモデルに大半のトラフィックを流し、もう一方は本当に必要なリクエストに温存し、数値が変われば配分を変えればよいのです。
# 1 つのキー、1 つのエンドポイント、両方のモデル。
curl https://api.orcarouter.ai/v1/chat/completions \
-H "Authorization: Bearer $ORCAROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "google/gemini-3.6-flash",
"messages": [{"role":"user","content":"..."}]
}'
# 文字列を 1 つ変えるだけでモデルを切り替えられます。
# "model": "google/gemini-flash-latest"入力 token では Gemini 3.6 Flash が 100 万あたり $1.50、google/gemini-flash-latest が $0.50、出力では 100 万あたり $7.50 対 $3.00 です。
請求額はたいてい出力 token で決まります。長い応答を生成するチャットや agent のワークロードは出力レートに支配されるため、入力では安く見えるモデルでも、エンドツーエンドではより高くつくことがあります。価格だけで選ぶ前に、実際の入力対出力の比率を見積もってください。検索が多く回答が短いプロンプトと、プロンプトが短く生成が長いケースは、この表の正反対に位置します。実用的な見積もり方法は、代表的なプロンプトのサンプルを取り、平均の入力・出力 token を数え、それぞれを両モデルの各レートに掛けることです。あなたの実際のミックスで blended(混合)コストが低いモデルこそ、超えるべき基準です。ここでの両価格は生のプロバイダーレート——OrcaRouter は一切加算しません——なので比較は同一基準であり、計算した節約はそのまま手元に残る節約です。
どちらの料金もプロバイダーの原価です。OrcaRouter は上乗せしないので、計算した節約額がそのまま手元に残ります。
無料で始めるトークン単価の比較
100万 tokens あたり
latency と throughput は、本番環境でのモデルの体感を左右します。中央値(p50)の応答 latency は、典型的なリクエストが最初の token を受け取るまでの待ち時間であり、throughput(1 秒あたりの token 数)は開始後に応答がストリーミングされる速さを決めます。
対話型チャットや agent ループでは、ユーザーが最初の token を待っているため低い p50 latency が最も重要です。バッチ生成や長文出力では、応答が長いため throughput が全体の所要時間を支配します。上の 7 日間トレンドチャートは、各モデルの latency が安定しているか変動しているかを示し、単一の宣伝数値では隠れてしまう点を明らかにします——平均は優秀でもテールがばらつくモデルは、厳格な p95 SLA を満たせないことがあります。製品に latency の予算があるなら、中央値と曲線の形の両方を読み、エンドツーエンドの latency にはネットワークのホップや、モデルの周りで行う検索・ツール呼び出しも含まれることを忘れないでください。
過去7日間で、google/gemini-flash-latest の方が中央値応答レイテンシが低く保たれています。
benchmark スコアは能力を近似しますが、自分のプロンプトでのテストの代わりにはなりません。ここに表示される総合品質指数は複数の公開評価を集約したもので、パーセンタイルは各モデルがカタログ内の比較可能な全モデルの中でどこに位置するかを示します——有用な絞り込みの目安であり、あなたのタスクでの保証ではありません。
汎用知能指数で先行するモデルでも、あなたの領域(コーディング、抽出、多言語、長 context 推論)では劣ることがあります。benchmark で候補を絞り込んだうえで、代表的なトラフィックの一部で両モデルを実際に走らせてください。トップラインの数値ではなく、あなたのユースケースに合う具体的な指数に注目してください。コーディング中心の製品はコーディング指数を、リサーチアシスタントは推論指数を重視すべきです。benchmark はモデルが更新されると古くなるため、自分の評価セットで確認する出発点の仮説として扱ってください。
コストが決定的な制約なら、実際の入力対出力の比率で安いモデルから始め、品質が届かない場合にのみ上位へ移してください。応答性が優先なら——ユーザー向けチャット、agent、誰かが待っているあらゆる場面——わずかな価格差よりも p50 latency と throughput を重視してください。
最も負荷の高い推論、コーディング、長 context の作業に取り組むなら、benchmark と context window の勝者を主役にし、割に合う場面では高いレートを受け入れてください。両モデルは同じ API の背後にあるため、低リスクな手は、実トラフィックの一部を両者に振り分け、自分のプロンプトでコスト・latency・回答品質を比較してから決めることです。よくあるパターンは階層化(tier)です。簡単で大量のリクエストの大半を安いか速いモデルに送り、より強力なモデルは本当に必要なリクエストのために取っておくことで、コストのごく一部で品質の恩恵の大半を得られます。どれを選んでも、切り替えは可逆に保ってください——数値や要件が変わった瞬間にトラフィックを元に戻せます。
あるいは選ばないという手も — 1 つのキーと 1 つのエンドポイントで、リクエストごとに振り分けられます。
両方を使うおすすめ用途
1 つのキー。両方のモデル。40 以上のプロバイダー。
プロバイダー原価で請求、トークン手数料はゼロ。無料で始めて、文字列 1 つでモデルを切り替え、決定はいつでも巻き戻せます。