Serverless 推論 — 共有 GPU を従量課金で使う

これは何か

Serverless 推論（Serverless Inference）とは、Fireworks が管理する GPU プールを複数の利用者が共有して使う、マルチテナント推論（multi-tenant inference、1 つのインフラを多数の利用者で同時に使い回す方式）のことである。エンドポイントは api.fireworks.ai の 1 つだけで、リクエストを送った分だけ課金され、GPU の台数を見積もる作業もオートスケーラの調整もコールドスタート（GPU が起動するまでの待ち時間）を待つ作業も要らない。第 2 章でこれまで送ってきた chat/completions へのリクエストは、実はこの Serverless 推論を経由していた。

Serverless は画面のあるコンソール機能ではなく、API から直接叩く機能である。「どこにあるか」を強いて言えば、第 3 章で扱った Model Library で Serverless タグが付いているモデルが目安になる（ただし一覧に出ないまま Serverless で動くモデルもある。第 3 章参照）。呼び出し方はモデル ID の指定だけで、通常モデルは accounts/fireworks/models/<id>、この章で説明する Fast variant や、米国内限定で推論する地域限定 variant（US-only Serverless）は accounts/fireworks/routers/<id> という別の名前空間を使う。前者はモデルそのもの、後者はモデルの手前に立つルーティング層を指していると考えるとよい。

いつ使うのか

Serverless が向くのは次のような場面である。

• プロトタイピングや検証段階 — GPU を確保せずに、人気のオープンモデルをそのまま試せる
• トラフィックが読めないアプリ — スパイクや閑散期があっても、スケーリングの設計をこちらでやらなくてよい
• Fireworks がホスト済みのモデルで足りる用途 — Kimi・GLM・DeepSeek・Qwen などの主要オープンモデルをカスタマイズせずに使う

一方で、隣接する 2 つの機能とは仕組みそのものが異なるので、使い分けが必要になる。

特に「学習済み LoRA モデルの推論は Serverless では提供されず、On-demand が必須」という制約は公式ドキュメントで明記されている一点なので覚えておきたい（LoRA アダプタの中身は第 11 章で扱う）。On-demand の詳細は第 9 章、Batch API の詳細は第 8 章で扱う。

仕組み（1）— 3 つのサービングパス

Serverless には Standard・Priority・Fast という 3 つのサービングパス（serving path、リクエストが辿る経路）がある。3 つとも同じ Serverless フレームワークの上で動き、レート制限のポリシーも共通だが、ルーティングと価格が違う。

Standard は既定のサービングパスで、service_tier パラメータは不要である。Priority は混雑時の信頼性を優先したいときに使う。リクエストに service_tier: "priority" を追加するだけで opt-in（明示的に指定したときだけ有効になる方式）でき、OpenAI 互換の chat completions と Anthropic 互換の messages API の両方で使える。

curl https://api.fireworks.ai/inference/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $FIREWORKS_API_KEY" \
  -d '{
    "model": "accounts/fireworks/models/glm-5p2",
    "service_tier": "priority",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Priority は Standard のトラフィックより優先され、混雑時に「載せ落とし（load shed、処理しきれないリクエストを切り捨てる挙動）」される確率が下がる。ただし対応モデルは限られており、どのモデルが Priority に対応しているかはpricing ページの料金表（主要モデルの一覧）が正本（source of truth）になる。後述する本章の料金表はその代表例の抜粋である。

Fast はパラメータではなく、model の ID そのものを Fast variant に差し替えて使う。ただし Fast の一覧は公式ドキュメントの中でも安定していない。Serving Paths ページが挙げる ID のうち、Kimi K2.6 Fast（kimi-k2p6-fast）は 2026-08-27 に serverless から退役済みで、標準の Kimi K2.6 へ移行している。GLM 5.1 Fast（glm-5p1-fast）も本章の料金表に対応する行が無く、現存を確認できない。2026-09 時点で確実に使えるのはGLM 5.2 Fast（accounts/fireworks/routers/glm-5p2-fast）である。

このほかServerless Pricing のページには Kimi K3 Fast という行があり、Fast variant が他にも存在すること自体は分かるが、そちらは価格しか載っておらず model ID は書かれていない。Fast の網羅一覧は変わりやすく個数を決め打ちできないので、使いたいモデルの ID は第 3 章で扱ったモデル詳細ページ（app.fireworks.ai/models/fireworks/<モデルID>）で確認するのが確実である。

Fast は生成スループット 100+ tokens/秒を狙う経路で、公式ドキュメントは「別のモデルではなく、品質は変わらない」と明記している。モデルそのものは同じで、変わるのは速度と値段（と、後述するレート制限の枠）だと捉えてよい。

仕組み（2）— 課金は 2 つの構造に分かれる

Serverless の課金は 3 つの軸で計算される。送った入力トークン（input tokens）、プロンプトキャッシュ（prompt cache、直前までのリクエストと共通する冒頭部分を再計算せずに使い回す仕組み。全 Serverless モデルで既定 ON になっており、使い回せた分は安く課金される。詳しくは第 7 章）から返したキャッシュ入力トークン（cached input tokens）、モデルが生成した生成トークン（generated tokens、= output tokens）である。実際に何が課金されたかの正本は、レスポンスに毎回入る usage オブジェクトで、prompt_tokens / completion_tokens / total_tokens の 3 つの数値が入る。キャッシュがどれだけヒットしたかは usage.prompt_tokens_details.cached_tokens（レスポンスヘッダの fireworks-cached-prompt-tokens と同じ値）で確認できる。

ここで注意したいのが、料金表が 2 つの異なる構造を持つ点である。個別モデル表に載っているモデル（Kimi・GLM・DeepSeek・Qwen など主要モデル）は、モデルごとに固有のキャッシュ入力レートを持つ。2026-09 時点の代表例を挙げる。

単位はいずれも USD / 100 万トークン。Priority 列が「—」のモデルは Priority 非対応である。対応可否の正本はpricing ページの個別モデル表で、本章の表はその代表例の抜粋にすぎない。ここに無いモデル（例: Kimi K3・GLM 5.3・MiniMax M3 など）を使うときは pricing ページで確認する。キャッシュ入力の割引率はモデルごとにばらばらで、GLM 5.2 は入力の約 1/10、DeepSeek V4 Pro (0813) は約 1/30 まで下がる。「キャッシュ入力は一律で入力の 50% 引き」という単純化はしない方がよい。個別モデル表に実レートが載っているモデルでは、そちらの数値が優先される。

一方、個別モデル表に載っていないモデルは、パラメータ数とアーキテクチャ（dense〔全パラメータを毎回使う通常の構成〕か MoE〔Mixture of Experts。入力ごとに一部の専門家ネットワークだけを動かす構成で、パラメータ総数のわりに計算量が小さい〕か）で決まる一律料金が適用される（2026-09 時点）。この一律料金は入力と出力に同一の値段が適用され、キャッシュ入力専用の割引レートは存在しないという、個別モデル表とは別の課金構造になっている。

• 4B パラメータ未満: $0.10 / 100 万トークン
• 4B〜16B パラメータ: $0.20 / 100 万トークン
• 16B パラメータ超: $0.90 / 100 万トークン
• MoE 56B パラメータ以下（例: Mixtral 8x7B）: $0.50 / 100 万トークン
• MoE 56.1B〜176B パラメータ（例: DBRX、Mixtral 8x22B）: $1.20 / 100 万トークン

なお Batch API（第 8 章）は、この個別モデル表・サイズ別一律表どちらの料金であっても、入力・出力とも標準 Serverless 料金の 50% で処理される。急がないリクエストをまとめて投げるだけで一律 50% 引きになる、という位置づけになる。

仕組み（3）— レート制限は TPM 3 本立て、429 と 503 は別物

Serverless のレート制限はアカウント × モデル単位でかかり、しかも固定値ではなく利用量に応じて自動で伸縮する「アダプティブ（adaptive）」な仕組みになっている。急にトラフィックを立ち上げると、伸びきる前に 429 が出ることがある。

ここで説明する TPM の 3 本立てとは別に、アカウント全体には固定の RPM（Requests Per Minute）上限もかかる。支払い方法を登録し、有効なクレジット残高がある状態であれば最大 6,000 RPM（2026-09 時点）で、これはスペンドティアを上げても動かず、Serverless かOn-demand Deploymentsかを問わずアカウント全体に適用される固定の天井である（支払い方法未登録、またはクレジット残高が無い場合は 10 RPM に制限される。詳しくは第 2 章と第 13 章）。RPM（回数）と TPM（トークン量）は単位の違う別々の制限で、どちらか一方でも超えれば弾かれる。本節で扱う TPM は、この固定の RPM 天井とは別に、利用量に応じて伸縮する。

計測に使われる指標は 3 つあり、2026-09 時点の既定上限（default ceilings）は次のとおりである。

• Total Prompt TPM（入力トークン/分、キャッシュ有無を問わない合計）: 21.6M（約 360k TPS 相当）
• Uncached Prompt TPM（キャッシュされていない入力トークン/分）: 5.4M（約 90k TPS 相当）
• Generated TPM（出力トークン/分）: 216k（約 3.6k TPS 相当）

Total と Uncached の比はちょうど 4:1（21.6M : 5.4M）になっている。つまりキャッシュヒット率が低いワークロードほど、実質的には内側の Uncached Prompt TPM（5.4M）の方が先に効いてくる。Total の枠が余っていても、キャッシュされていない入力だけで 5.4M/分に達すれば 429 になる。ヘッダに出る数値は「1 秒あたり」（tokens per second）換算だが、実際に制限として判定（enforcement）されるのは 1 分単位の TPM である点に注意する。

関連するヘッダは次のとおり。

もう 1 つ理解しておきたいのが、429 Too Many Requests と 503 Service Overloaded は原因も対処もまったく別だという点である。

429 は自分のアダプティブなレート制限を超えたときに起きる。まず試すべきは exponential backoff（再試行の間隔を指数的に伸ばす方式）で、それでも足りなければ Spending Tier（利用額に応じて上がるアカウントの階級）を上げる、または後述の Reserved Throughput を検討する。503 はデプロイが混雑しているときの load shed で、レート制限の枠内に収めていても成功が保証されるわけではない。503 の発生確率を下げたいときに使うのが Priority tier である。

スコープの整理も重要である。レート制限はアカウント単位 × モデル単位でかかる。3 つのサービングパスは適用されるルール（ポリシー）は同じだが、消費する枠は同じとは限らない。Fast variant は通常 variant と別枠を持つ一方、Priority tier は通常リクエストと同一モデルについて同じレート制限枠を共有する。Priority を使っても TPM の上限自体が増えるわけではなく、増えるのは混雑時に優先される度合いだけである。

本番投入前に知っておくこと

継続的にトラフィックが増えるサービスでは、レート制限の伸びを待つだけでは足りない場合がある。そのための仕組みがReserved Throughput（予約スループット）である。購入単位は GPU 台数でもトークン数でもなく「1 分あたりのドル額（dollar-per-minute）」で、予約額の範囲内は throughput SLA（可用性の保証）付きで処理され、超過分は標準の Serverless 料金・標準のアダプティブレート制限で処理される。ここが誤解しやすい点だが、Reserved Throughput は値引きではない。単価は標準の Serverless リスト価格のままで、買っているのは SLA と、アダプティブレート制限に「上乗せ」される枠である。しかも未使用分は繰り越されない（use-it-or-lose-it、毎分リセット）。詳しくは Reserved Throughput のページを参照してほしい。

もう 1 つ押さえておきたいのが、Serverless モデルのライフサイクルである。Serverless で提供されるモデルは Fireworks 側の管理下にあり、新しいモデルが出れば更新・廃止（deprecation）されることがある。モデルを削除する場合は最低 2 週間前の事前告知があり（2026-09 時点）、利用の多い人気モデルほど告知期間は長くなる。長期にわたってモデルのバージョンを固定したい本番ワークロードには、第 9 章で扱う On-demand Deployments の方が向いている。

from fireworks import Fireworks

client = Fireworks()

stream = client.chat.completions.create(
    model="accounts/fireworks/models/glm-5p2",
    messages=[{"role": "user", "content": "Serverless推論の利点を50字で説明して"}],
    stream=True,
)

for chunk in stream:
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")
    if chunk.usage:
        print(f"\n\ninput={chunk.usage.prompt_tokens} "
              f"output={chunk.usage.completion_tokens} "
              f"total={chunk.usage.total_tokens}")

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ.get("FIREWORKS_API_KEY"),
    base_url="https://api.fireworks.ai/inference/v1",
)

response = client.chat.completions.with_raw_response.create(
    model="accounts/fireworks/models/glm-5p2",
    messages=[{"role": "user", "content": "Hello"}],
)

for header in [
    "fireworks-prompt-tokens",
    "fireworks-cached-prompt-tokens",
    "X-Ratelimit-Limit-Tokens-Prompt",
    "X-Ratelimit-Limit-Tokens-Cache-Adjusted-Prompt",
    "X-Ratelimit-Limit-Tokens-Generated",
]:
    print(header, "=", response.headers.get(header))

completion = response.parse()
print(completion.choices[0].message.content)

つまずきポイント

理解度チェック

まとめ

• Serverless 推論は共有 GPU プールをトークン従量課金で使う仕組みで、Standard・Priority・Fast という 3 つのサービングパスを持つ
• 課金には「個別モデル表」と「サイズ別一律表」という 2 つの異なる構造があり、キャッシュ入力の割引率は一律ではない
• レート制限は Total Prompt・Uncached Prompt・Generated という TPM 3 本立てで、429（レート制限超過）と 503（混雑による load shed）は別の現象として切り分ける
• 本番の長期運用では、モデルの非推奨化サイクルと Reserved Throughput（割引ではなく SLA + 上乗せ枠）も判断材料に入れる

次章では、Serverless と同じ API を使いながら、テキスト以外の入出力 — 画像・音声・Embeddings — をどう扱うかを見ていく。

参考リンク

• Serverless Inference Overview
• Serverless Serving Paths
• Serverless Pricing
• Serverless Rate Limits
• Reserved Throughput
• Querying Text Models
• API Reference: Create Chat Completion