Deployments — 専用 GPU でモデルを動かす

これは何か

On-demand Deployments（専有デプロイ）とは、自分専用の GPU を確保してモデルを動かす仕組みである。第 5 章で扱った Serverless 推論が「他の利用者と GPU を共有するマルチテナント」だったのに対し、専有デプロイは文字どおり GPU を専有し、他の利用者の負荷に性能が左右されない。コンソールでは app.fireworks.ai/dashboard/deployments の Deployments 画面から一覧・作成・管理でき、一覧には GPU 種別・台数が表示される。詳細ページにはモデルヘッダー、Playground へのクイックアクション、Edit・Delete・Enable/Disable のボタンがあり、作成中のレプリカ（同じモデルを載せた GPU サーバの複製 1 台分。台数を増やすと同時に捌けるリクエストが増え、そのぶん課金も増える）は pending → downloading → initializing → ready の 4 段階でライブ表示される。

操作の主役はコンソールではなく firectl（Fireworks の CLI）である。最小のデプロイ作成は次の 1 行で済む。

# accounts/<ACCOUNT_ID>/deployments/<DEPLOYMENT_ID> が返る。クエリ時に必要なので控えておく
firectl deployment create accounts/fireworks/models/<MODEL_NAME> --wait

作成したデプロイへは、モデル ID の代わりにこの accounts/<ACCOUNT_ID>/deployments/<DEPLOYMENT_ID>という参照名を model フィールドに渡してクエリする。呼び出し方自体は第 2 章・第 5 章で使ってきた chat/completions と同じで、エンドポイントも Serverless と同じ https://api.fireworks.ai/inference/v1 である。違うのは「どの GPU で処理されるか」だけだと考えてよい。

いつ使うのか

Serverless は便利だが、次の 4 つのいずれかに当てはまったら専有デプロイへの切り替えを検討する。

逆に言えば、この 4 条件のどれにも当てはまらないうちは Serverless のままで十分なことが多い。両者の違いを表にまとめる。

ここで「専有デプロイにはレート制限が無い」と早合点しないでほしい。アカウント全体に固定でかかる 6,000 RPM の上限は、デプロイ形態を問わず適用される。詳しくは後述の「レート制限と LoRA」節で扱う。

GPU の選び方とデプロイメントシェイプ

専有デプロイの GPU は --accelerator-type で指定する（NVIDIA_A100_80GB / NVIDIA_H100_80GB / NVIDIA_H200_141GB）。小型の A100 は単価が安く低ボリューム用途向き、H100 は高スループット向き、H200 は DeepSeek V3・DeepSeek R1 のような大型モデル（公式が案内する最小構成は 8 × H200）向き、という棲み分けが公式ドキュメントに明記されている。これに加えて B200 180GB が一部リージョンで提供されており、GPU クォータも既定で 8 枚割り当てられる。

GPU の時間単価は docs.fireworks.ai 上には掲載がなく、公式 pricing ページ（fireworks.ai/pricing）が正本になる。2026-09 時点の 1 時間あたり単価は次のとおり。

A100 は 2026-09 時点の公式 pricing ページの表に掲載が無いため、単価はここに書けない。

課金は GPU 秒単位（GPU-second）で、サーバがリクエストを受け付け始めた時点から始まり、API 呼び出しが 0 回でもレプリカが立っていれば課金され続ける。レプリカを 1 台から 2 台に増やせば GPU コストは単純に 2 倍、1 レプリカあたり 2 GPU を使う構成なら 1→2 レプリカで 4 GPU 分の課金になる、というようにレプリカ数 × レプリカあたり GPU 数にそのまま比例する。デフォルトの GPU クォータ（quota。アカウントごとに確保できる GPU 枚数の上限）は A100・H100・H200・B200 いずれも 8 枚（LoRA は 100 個）なので、8 × H200 が最小構成のモデルはデフォルトのクォータでちょうど 1 レプリカ分しか確保できない計算になる。

個別に --accelerator-type や精度を指定する代わりに、公式が「設定の primary な手段」と位置づけているのがデプロイメントシェイプ（deployment shape）である。ハードウェア・量子化・その他のチューニングをまとめたテンプレートで、3 種類ある。

• Fast — 対話向けの低レイテンシを狙うシェイプ
• Throughput — 高ボリューム向けにトークン単価を抑えるシェイプ
• 3 つ目は最軽量・コスト重視のシェイプ（呼称の表記がドキュメントによって揺れるため、ここでは機能で呼ぶ）。検証や軽い負荷向けに最も安い構成になる

# ショートハンドで指定
firectl deployment create accounts/fireworks/models/deepseek-v3 --deployment-shape throughput

# フル ID で指定
firectl deployment create accounts/fireworks/models/llama-v3p3-70b-instruct \
  --deployment-shape accounts/fireworks/deploymentShapes/llama-v3p3-70b-instruct-fast

状態遷移とオートスケール

デプロイメントの状態（state）は Gateway API 上、次の 6 つで定義されている。CREATING（作成中）→ READY（利用可能）→ UPDATING（設定変更の反映中、完了すると READY に戻る）という流れが基本で、削除時は READY → DELETING（削除中）→ DELETED（ソフト削除済み）と進む。作成に失敗すると FAILED になる。

ここで注意したいのが、コンソールに表示される「Inactive」「Scaled to 0」というラベルである。これらはバックエンドの state の列挙値ではなく、state == READY であることを前提に、レプリカ数のフィールドから UI が計算して出す表示ラベルにすぎない。API 上の state は両方とも READY のままなので、監視スクリプトを書くときは state ではなくレプリカ数（desired_replica_count / ready_replica_count）を見る必要がある。

オートスケールは firectl deployment create（または update）のフラグで設定する。無トラフィックが一定時間続いたときにレプリカ数を 0 まで落として GPU 課金を止める仕組みをゼロスケール（scale-to-zero）と呼ぶ。既定値は次のとおりで、特に --max-replica-count の既定は 1 であることに注意したい。何も指定しないと、負荷が上がってもレプリカは水平にスケールしない。

ゼロスケール中に届いたリクエストは、キューされずに即座に 503 エラー（エラーコード DEPLOYMENT_SCALING_UP）で返り、その裏でスケールアップが始まる。アプリ側は指数バックオフでリトライする実装が必須になる。さらに、--min-replica-count 0 のデプロイメントは、無トラフィックが 7 日間続くと自動的に削除される点も覚えておきたい。

リージョンの選び方

リージョンは --region で指定し、GLOBAL・US・EUROPE・APAC という 4 つのマルチリージョンから選ぶのが基本である。マルチリージョンは複数のシングルリージョン（データセンター）をまとめた高レベルのグルーピングで、Fireworks がその中でレプリカを必要に応じて動かし、弾力的なスケーリングと局所障害への耐性を提供する。シングルリージョンは全部で 19 拠点あり、米国 14・欧州 3・APAC 2 という内訳である。

ここに 執筆時点で最大級の落とし穴がある。--region は作成時にしか設定できず、後から変更できない。省略すると単一データセンターに固定され、後から自動的に広げられることもない。本番用途では必ず明示的に --region GLOBAL を付けるべきだと公式が Warning として案内している（日本から近づけたいだけなら --region APAC でもよい）。配置を変えたくなったら、新しいリージョンでデプロイを作り直し、切り替えてから旧デプロイを削除する以外に手段は無い。

新規ユーザーに自動付与されるクォータは GLOBAL マルチリージョン分のみで、特定のシングルリージョン（例えば東京固定）を使いたい場合は Fireworks への問い合わせが必要になる。データレジデンシー要件がある案件では、この申請が前提作業になる点も覚えておきたい。なお公式 pricing ページには、リージョンを限定したデプロイは 1.5 倍のプレミアム価格になる旨の但し書きがある（2026-09 時点）。どこまでを「限定」と数えるか（シングルリージョン固定のみか、US / APAC の指定を含むか）は但し書きからは読み取れないため、リージョンを絞る前に見積もりを確認するのが安全である。

本番運用が視野に入ったら、名前だけでも知っておきたい機能が 2 つある。Router（firectl router create で作る、複数デプロイメント間でトラフィックを分割する仕組み。A/B テストや無停止でのモデル入れ替えに使うが、マルチリージョンのデプロイメントでしか使えないという制約がある）と、Reserved capacity（予約容量。Enterprise アカウント向けに 1 年契約が典型で、容量保証・クォータ引き上げ・GPU 時間単価の値引きが得られるが、購入には Fireworks のアカウントマネージャーへの連絡が要る）である。どちらも本章では深入りしないが、「そういう選択肢がある」ことだけ覚えておき、必要になったら公式ドキュメントを参照してほしい。

速く安くする 2 つのつまみと、レート制限・LoRA の扱い

量子化と speculative decoding

専有デプロイには、性能とコストを調整する 2 つの独立したつまみがある。

量子化（quantization）は、モデルを扱うビット数を減らして推論を速くし、コストを 30〜50% 削減する仕組みである。ただし数値表現（numerics）が変わるため、出力にわずかな違いが出ることがある。firectl prepare-model で FP8 への変換を実行でき、これは加算的な処理なので元の FP16 チェックポイントは残ったまま、FP8 の構成を追加で選べるようになる。

# FP8への変換をリクエスト
firectl prepare-model <MODEL_ID>

# 準備ができたらFP8でデプロイ（量子化デプロイメントはH100専用）
firectl deployment create <MODEL> --accelerator-type NVIDIA_H100_80GB --precision FP8

ここで必ず押さえておきたい制約がある。量子化したデプロイメントは H100 でしか動かない。H200 や B200 で FP8 を使いたくなっても、docs 上ではその構成は案内されていない。何も指定しなければ既定の FP16 のまま動く。

Speculative decoding（投機的デコーディング）は、複数トークンをドラフトモデルに提案させ、本体（target model）が並列に検証することで生成レイテンシを縮める手法である。target model が最終的に全トークンを検証するため、出力品質そのものは劣化しない。多くの対応モデルにはデフォルトのドラフタと draft token 数がすでに設定されており、何も付けずにデプロイすれば既定のドラフタをそのまま継承する。公式は「まずデフォルトのままデプロイし、ベンチマークしてから変更を検討する」ことを推奨している。独自のドラフトモデルを使いたいときは --draft-model="accounts/fireworks/models/<DRAFT_MODEL_ID>" と --draft-token-count を指定する。

--draft-token-count の推奨開始値は 4 で、そこからベンチマークして近傍の値を試す。ドラフトモデルの相性が悪いと、かえって生成が遅くなることもあるため、「デフォルト」「候補のドラフタ」「--disable-speculative-decoding で無効化した状態」の 3 構成を同じ target モデル・同じシェイプで比較するのが公式の推奨手順である。量子化と speculative decoding は独立した設定なので、併用も可能である。

レート制限と LoRA の扱い

専有デプロイには、Serverless のような TPM ベースのアダプティブなレート制限は存在しない。GPU が飽和していない限り、確保したキャパシティの範囲でリクエストを処理できる。ただし「専有デプロイなら無制限」ではない点に注意が必要である。アカウント全体には固定で 6,000 RPM（1 分あたりリクエスト数、2026-09 時点）の上限があり、これは Serverless 専用の制限ではなく、専有デプロイを含むどのデプロイ形態でも免れられない。専有デプロイで 429 を受け取った場合、その多くは TPM 上限ではなくデプロイメントの飽和（GPU がビジー）を意味し、対処はスケールアウトやレプリカ増設になる。

もう 1 つの重要な事実が LoRA（Low-Rank Adaptation、少ないパラメータでモデルを微調整する手法）の扱いである。学習済みの LoRA アダプタを推論に使えるのは専有デプロイのみで、Serverless 推論では提供されない。アップロードした LoRA アダプタも、Fireworks の Managed Training で学習した LoRA も同様である。コンソールの Deployments 画面には LoRA を確認するための「LoRA Addons」タブがあり、LoRA アダプタの rank（r）は 4〜64 の整数、既定の on-demand クォータは 100 個までとなっている。学習方法そのものの詳細は第 11 章で扱う。

firectl deployment create accounts/fireworks/models/qwen3-0p6b \
  --accelerator-type NVIDIA_H100_80GB \
  --region GLOBAL \
  --wait

curl https://api.fireworks.ai/inference/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $FIREWORKS_API_KEY" \
  -d '{
    "model": "accounts/<ACCOUNT_ID>/deployments/<DEPLOYMENT_ID>",
    "messages": [{"role": "user", "content": "専有デプロイの利点を50字で説明して"}]
  }'

firectl deployment delete <DEPLOYMENT_ID>

firectl deployment create accounts/fireworks/models/qwen3-0p6b \
  --accelerator-type NVIDIA_H100_80GB \
  --region GLOBAL \
  --min-replica-count 0 \
  --max-replica-count 3 \
  --scale-to-zero-window 5m \
  --wait

firectl deployment get <DEPLOYMENT_ID>

firectl deployment get <DEPLOYMENT_ID>

firectl deployment delete <DEPLOYMENT_ID>

つまずきポイント

理解度チェック

まとめ

• 専有デプロイへの切り替えどころは「モデルが Serverless に無い」「学習済み LoRA を使いたい」「性能要件が厳しい」「リージョンを指定したい」の 4 条件のいずれか
• 課金は GPU 秒単位でレプリカ数に比例し、GPU の時間単価は docs ではなく公式 pricing ページが正本（2026-09 時点で H100・H200 = $8.00/時間、B200 = $13.00/時間）
• デプロイメントの state は 6 種類のみ。「Inactive」「Scaled to 0」は READY 状態から UI が計算する表示ラベル
• --region と --preemptible は作成時にしか決められない。特にリージョン省略の「単一データセンター固定」は本番で事故りやすい
• 量子化（H100 専用・30〜50% のコスト削減）と speculative decoding（品質を落とさずレイテンシ短縮）は独立した 2 つのチューニングつまみ

次章では、この専有デプロイの土台となる学習データ — Datasets の管理と JSONL 形式の作法を見ていく。

参考リンク

• Deployments（On-demand Deployments）
• Autoscaling
• Regions
• Speculative Decoding
• Quantization
• Account quotas
• Serverless Inference Overview
• Fireworks Pricing