この章で分かること
- Fireworks AI が何を提供するプラットフォームか(オープンモデル向けの推論・学習クラウド)
- Serverless・専用デプロイ(Dedicated Deployments)・Batch・Fine-Tuning という 4 つの実行方式がそれぞれ何をするものか
- 料金がどういう単位でかかるか(トークン従量・GPU 稼働時間・支出ティアの全体像)
- OpenAI 互換/Anthropic 互換 API として使えるという設計
- コンソール(app.fireworks.ai)の画面構成と、本ガイドのどの章がどの画面を扱うか
これは何か
Fireworks AI は、公式ドキュメントのトップページで次のように自己定義している。
Fireworks AI is the fastest platform for building with open source AI models. Get production-ready inference and training with best-in-class speed, cost and quality.
「オープンソースの AI モデルで開発するための最速プラットフォーム」であり、推論(inference)と学習(training)の両方を production-ready な品質で提供する、という位置づけである。自社でモデルを一から訓練するのではなく、DeepSeek・Kimi・GLM・Qwen・GPT-OSS といった公開済みのオープンウェイト(open-weight)モデル(モデルの重み=学習結果のパラメータが公開されていて、誰でも自分の環境で動かせるモデル)を、動かす場所(推論)と鍛え直す場所(学習)の両方として使うのが Fireworks の役割になる。
4 つのドメインと 5 つのインターフェース
Fireworks は用途ごとに 4 つのドメインに分かれている。
| ドメイン | 役割 |
|---|---|
app.fireworks.ai | Web コンソール本体。モデル・デプロイ・学習ジョブなどを画面から操作する |
fireworks.ai | 公開マーケティングサイト。モデル一覧や料金ページの一部もここにある |
docs.fireworks.ai | 本ガイドが参照しているドキュメント本体 |
api.fireworks.ai | 推論・学習を実行する API のエンドポイント |
そして、これらに触れる手段(インターフェース)は公式ドキュメントの Concepts ページで 5 つに整理されている。
- The web app at https://app.fireworks.ai
- the
firectlCLI- OpenAI compatible API
- Anthropic compatible API
- Python SDK
Web コンソール・firectl(コマンドラインツール)・OpenAI 互換 API・Anthropic 互換 API・Python SDK の 5 つである。本ガイドはコンソール・OpenAI/Anthropic 互換 API・Python SDK を中心に扱い、firectl は第14章でまとめて紹介する。
3 つの始め方
ドキュメントのトップページは、迷ったときの動線を「モデル選定ガイド → Serverless で試作 → Deployments で本番最適化 → 必要なら Training で品質向上」の順に案内している。入口となるカードは次の 3 つ。
- Serverless — 人気モデルを即座に、トークン従量課金で使う(トークンとは、モデルが文章を処理する際の最小単位。日本語ならおおむね 1 文字〜数文字で、課金も速度もこの個数で数える)。プロトタイピングと品質の当たり確認向け
- Deployments(専用 GPU) — 高速なオートスケール(負荷に応じて GPU の台数を自動で増減させる仕組み)とコールドスタート最小化。速度・スループットを最適化した本番運用向け
- Training — 教師あり学習(SFT)と強化学習(RFT)による品質向上。1 兆パラメータ超のモデルまで学習でき、学習後すぐにデプロイできる
加えて、モデルの入出力は text に限らない。ドキュメントの「What you can build」には次の 7 項目が並ぶ。
- 100 を超える公開モデル(text / vision / audio / image / embeddings、2026-09 時点)
- OpenAI からの移行(推論・学習とも drop-in replacement。同じ API、同じ SFT データ形式)
- Function Calling(モデルをツールや外部 API に接続する)
- Structured Outputs(エージェント向けの確実な JSON 出力)
- Vision Models(画像・文書の解析)
- Embeddings & Reranking(検索・文脈取得向け)
- Batch Inference(大量の非同期推論を安く速く回す)
つまり Fireworks は「モデルを 1 つ選んで終わり」の製品ではなく、同じアカウントの下で、同じモデルを 3 通りの経路(Serverless/専用デプロイ/Batch)のどれかで動かし、必要なら自社データで鍛え直す(Fine-Tuning)ところまでを一気通貫でカバーするプラットフォームだと理解しておくとよい。
いつ使うのか
「Fireworks を使う」というのは実際には「Serverless・専用デプロイ・Batch・Fine-Tuning のどれを使うか」を選ぶことに等しい。4 つは同じモデルに対する別々の実行方式であり、課金の単位も GPU の管理責任もまったく異なる。
| 経路 | 課金の単位 | GPU の管理 | 適した用途 | 本ガイドの章 |
|---|---|---|---|---|
| Serverless | トークン従量(input/cached input/generated) | 不要(Fireworks 管理の共有 GPU) | 人気モデルをすぐ試す・プロトタイピング | 第 5 章 |
| 専用デプロイ(Dedicated Deployments) | GPU 稼働時間 | 自分でハードウェア・オートスケールを設定 | 本番の性能保証、独自モデルや学習済み LoRA の実行 | 第 9 章 |
| Batch Inference | トークン従量(Serverless レートの 50%) | 不要 | 急がない大量リクエストをまとめて処理 | 第 8 章 |
| Fine-Tuning(学習) | トークン従量(共有プールでの学習)または GPU 時間(専有トレーナー)。第 11 章で扱う | 不要(学習は Fireworks 管理。配信は専用デプロイ) | 自社データでモデルの振る舞いそのものを調整する | 第 11 章 |
この使い分けで特に押さえておきたいのが、Serverless と専用デプロイの比較表として公式ドキュメントが挙げている次の対比である。
| Serverless が向く条件 | On-demand(専用デプロイ)が向く条件 |
|---|---|
| Pay per token, only for what you use | Pay per GPU-hour for dedicated capacity |
| You're using popular base models that Fireworks already hosts | You're running custom base models or trained LoRA models (LoRA requires On-demand) |
| You don't want to manage scaling, replicas, or hardware sizing | You have custom latency requirements and want control over hardware and replicas |
とりわけ重要なのは「LoRA requires On-demand」の一文である。Fine-Tuning で学習した LoRA(Low-Rank Adaptation。元のモデル本体はそのままに、差分だけを小さな追加ファイルとして学習する方式。第 11 章で扱う)アダプタは、Serverless では動かせない。学習済みモデルを配信する段階になったら、必ず専用デプロイが必要になるという制約は、第9章・第11章で扱う内容の前提として今のうちに押さえておきたい。
もう少し具体的なユースケースで考えると、次のように整理できる。
- 「このモデル、自分のユースケースでどれくらい使えそうか当たりを付けたい」→ Serverless。API キーさえあればすぐ呼べる
- 「本番でレイテンシ(応答が返るまでの時間)を安定させたい/同じモデルの重みを固定して運用したい」→ 専用デプロイ。Serverless モデルは更新・廃止されることがあり(削除の少なくとも 2 週間前に告知、人気モデルはより長い)、長期的にモデルの重みを固定したい運用には向かない
- 「夜間バッチでレポートを大量生成したい、多少遅くてもよい」→ Batch Inference
- 「汎用モデルでは自社の言い回し・フォーマットに合わない」→ Fine-Tuning(学習後は専用デプロイで配信)
プラットフォームの全体像
同じモデルであっても、通す経路によって課金の単位も、GPU をどれだけ自分で管理するかも変わる。「モデルは 1 つ、出口は 3 つ」という構造を図にすると次のようになる。
モデル自体は共通の名前空間で管理されている。名前は accounts/<ACCOUNT_ID>/models/<MODEL_ID> の形式で、Fireworks 提供モデルは accounts/fireworks/models/... となる。たとえば GLM 5.2 は accounts/fireworks/models/glm-5p2 のように、バージョン番号のドットが p に置き換わる(5.2 → 5p2)という命名規則も覚えておくと、後の章でモデル ID を読むときに戸惑わない。
コンソールの地図
ここまでは概念の話だったが、実際にはコンソール(app.fireworks.ai)を触りながら進めることになる。公式ドキュメントにはコンソールの画面構成を通しで説明したページが存在しないため、本ガイドはドキュメント各所に散らばった URL や操作手順の記述から画面地図を組み立てた。確証のある画面だけを、本ガイドのどの章で扱うかと合わせて一覧にする。
| 画面 | 何をする画面か | 本ガイドの対応章 |
|---|---|---|
Model Library(/models) | モデルの一覧・検索・フィルタ | 第3章 |
モデル詳細ページ(/models/<namespace>/<MODEL_ID>) | モデル ID・コンテキスト長・キャッシュ割引率の確認 | 第3章 |
| Playground | ブラウザ上でモデルに質問し、パラメータを試す | 第4章 |
Deployments(/dashboard/deployments) | 専用デプロイの作成・監視・削除 | 第9章 |
Datasets(/dashboard/datasets/<ID>) | 学習・バッチ用データセットのアップロードと管理 | 第10章 |
Fine-Tuning(/dashboard/fine-tuning/...) | SFT・DPO・RFT ジョブの作成と監視 | 第11章 |
Evaluations(/dashboard/evaluators/<ID>) | Evaluator の作成・実行、評価ジョブの管理 | 第12章 |
| Batch Inference タブ | 非同期の大量推論ジョブの作成と監視 | 第8章 |
Users(/account/users) | ユーザー・サービスアカウントとロールの管理 | 第13章 |
Billing(/account/billing) | 支払い方法・請求書・支出ティアの確認 | 第13章 |
Usage(/account/usage) | 利用量の集計とグラフ表示 | 第13章 |
API Keys(/settings/users/api-keys) | API キーの発行・管理 | 第2章・第13章 |
Usage limits(/settings/usage-limits) | ユーザー単位の支出上限の設定(申請制) | 第13章 |
Governances → Model Access(/settings/governances/model-access) | モデルごとの利用可否ポリシー設定(Enterprise 限定) | 第13章 |
| Audit Logs | API アクティビティの監査ログ検索(Enterprise 限定) | 第13章 |
Fire Pass(/fire-pass) | 対象のオープンウェイトモデルをトークン課金なしで使えるパス(招待制・実験的機能) | 第14章 |
コンソールのサイドバーには CREATE / EXPLORE / MANAGE という 3 つのグループ見出しがあることは公式の変更履歴から確認できるが、上の表のどの画面がどのグループに属するかまでは公式ドキュメントに記述がない。コンソールの UI は更新が速く、画面の並びや名称は本ガイド執筆時点(2026-09)から変わることがある。迷ったら、この章の一覧を手がかりに検索するか、画面上部の検索を使うとよい。
料金のかかり方の全体像
Fireworks の料金は、どの経路を使うかによって課金の単位そのものが変わる。細かい単価は各機能の章に譲るが、全体像として次の 3 つを押さえておく。
- Serverless はトークン従量課金。「input(送ったトークン)」「cached input(プロンプトキャッシュから配信された入力トークン。既定で input より割引)」「generated(生成トークン)」の 3 つの軸で課金される。実際に何が課金されたかは、レスポンスの
usageオブジェクト(prompt_tokens/completion_tokens/total_tokens)が正本になる。単価は第5章で扱う。 - 専用デプロイは GPU 稼働時間の従量課金。用語集は「GPU hours」を dedicated deployment の課金単位と定義しており、レプリカが起動している時間分だけ GPU 単位で課金される。単価は第9章で扱う。
- Batch Inference は Serverless の 50% 引き。入力・出力トークンとも標準 Serverless レートの半額で課金される(2026-09 時点)。急がない処理はまず Batch を検討する価値がある(第8章)。
これとは別に、アカウント全体の支出を管理する仕組みとして「支出ティア(Spending Tier)」がある。クレジットの追加や実際の利用実績に応じてティアが上がると、サーバーレスの利用可能キャパシティ(TPM 上限の天井)が広がる。月次の支出上限は別のアカウント制御で、下表の上限額はレガシーの後払いアカウントにのみ適用される(Fireworks は原則プリペイドのクレジット制で、プリペイドアカウントはティアと独立に上限を設定できる)。(金額はいずれも 2026-09 時点)
| ティア | 昇格の条件 | 月次支出上限(レガシー Postpaid) |
|---|---|---|
| Tier 1 | 有効な支払い方法とビリングプロフィールの登録 | 50 USD |
| Tier 2 | 50 USD の利用またはクレジット追加 | 500 USD |
| Tier 3 | 500 USD の利用またはクレジット追加 | 5,000 USD |
| Tier 4 | 5,000 USD の利用またはクレジット追加 | 50,000 USD |
| Unlimited | 問い合わせが必要 | 無制限 |
クレジットを追加してティアを上げると、新しいティアは数分以内に反映される。月次の支出上限は、既定で 80% 到達時に警告メールが送られ、100% に達すると Serverless・専用デプロイ・学習を含む全 API リクエストが自動的に一時停止する(Enterprise アカウントを除く)。上限の確認・変更は firectl quota list / firectl quota update monthly-spend-usd で行う。Billing 画面からは、80% 以外の通知しきい値を追加できる(第13章)。「料金がどうかかるか」を最初に大枠でつかんでおくと、後の章で単価の話が出てきたときに迷わない。
ハンズオン 1-1 モデル選定ガイドとコンソールのモデル一覧を照らし合わせる
- ブラウザで Which model should I use?(docs.fireworks.ai)を開き、「Choose by Use Case」の表から自分が作りたいものに近いユースケース(例: 「AI agents with tool use」)を 1 つ選ぶ。ここまでは公式ドキュメントを読むだけなので、アカウントは不要。
- 選んだユースケースの推奨モデルのうち 1 つ(例: Kimi K2.6)のモデル ID をメモする。ID は
accounts/fireworks/models/kimi-k2p6のようにaccounts/<ACCOUNT_ID>/models/<MODEL_ID>の形になっている。 - 次に Fireworks Model Library(公開サイト)(fireworks.ai/models)を開き、一覧で同じモデルに「Serverless」タグが付いているかを確認する。モデル名をクリックして詳細ページに移動し、コンテキストウィンドウの長さとモデル ID を確認する。サインイン済みなら
app.fireworks.ai/modelsでも同じ一覧を見られる(公開サイト側はサインイン前でも開けることが多いが、公式ドキュメントに明記は無い。開けなければアカウント作成は第 2 章)。 - Build with Fireworks AI のトップページに戻り、「What you can build」に並ぶ 7 つのカード(Function Calling・Structured Outputs・Vision・Embeddings & Reranking など)をひと通り眺め、自分のユースケースに関係しそうな項目を 1〜2 個メモしておく。
モデル ID の形式・コンテキスト長・Serverless タグの有無をメモできていれば OK。実際に API を呼び出す手順(API キーの発行を含む)は 第 2 章 で行う。
つまずきポイント
Model Library はモデルの完全な一覧ではない。legacy な BERT や sentence-transformers 系の embedder(例: BAAI/bge-small-en-v1.5、nomic-ai/nomic-embed-text-v1.5)は Model Library(fireworks.ai/models / app.fireworks.ai/models)には表示されないが、Hugging Face 形式の ID をそのまま model フィールドに渡せば Serverless で動く。「一覧に無いから使えない」と思い込まないこと。
Fireworks Python SDK は alpha 段階。pip install fireworks-ai のように --pre を付けずにインストールすると最新版が入らない。公式の手順は pip install --pre fireworks-ai(poetry / uv も同様に --pre が必要)。詳しい実行例は第2章で扱う。
モデル ID の名前空間を混同しやすい。通常モデルは accounts/fireworks/models/<id> だが、Fast variant は accounts/fireworks/routers/<id>-fast、US-only エンドポイントは accounts/fireworks/routers/<id>-us のように、いずれも models/ ではなく routers/ という別の名前空間になる。さらにバージョン番号のドットは p に置き換わる(5.2 → 5p2)。コピー元のコード例と自分が使いたい variant が食い違っていないか、確認する癖をつけるとよい。
理解度チェック
Q1. Fireworks AI は何を提供するプラットフォームですか?
オープンソースの AI モデルを対象に、推論(inference)と学習(training)の両方を production-ready な品質で提供するプラットフォーム。Serverless・専用デプロイ・Batch という 3 つの推論経路と、SFT・RFT による学習を、同じアカウントの下で扱える。
Q2. Serverless・専用デプロイ(Dedicated Deployments)・Batch Inference は、それぞれ何を基準に使い分けますか?
GPU の管理を自分で行うかどうか、課金がトークン従量か GPU 稼働時間か、レイテンシがどれだけ求められるかで選ぶ。学習済みの LoRA アダプタを動かす場合は Serverless では実行できず、専用デプロイが必須になる。
Q3. Model Library(fireworks.ai/models / app.fireworks.ai/models)に載っていないのに Serverless で使えるモデルがあるのはなぜですか?どう指定すればよいですか?
legacy な BERT や sentence-transformers 系の embedder は Model Library の一覧には表示されないが、serverless では引き続き提供されている。accounts/fireworks/models/... 形式ではなく、Hugging Face 形式の ID(例: BAAI/bge-small-en-v1.5)を model フィールドに直接渡せば呼び出せる。
Q4. Fireworks Python SDK をインストールするとき、忘れると失敗の原因になるフラグは何ですか?
--pre フラグ。SDK は現在 alpha 段階のため、pip install --pre fireworks-ai(poetry add --pre fireworks-ai / uv add --pre fireworks-ai)のように明示的に pre-release を指定してインストールする必要がある。
まとめ
- Fireworks AI は、オープンモデルの推論と学習を 1 つのプラットフォームで提供する。入口は Serverless/専用デプロイ/Training の 3 つ
- 推論の実行経路は Serverless・専用デプロイ・Batch の 3 通り。課金の単位(トークン従量/GPU 稼働時間/50% 引き)と GPU 管理責任がそれぞれ異なり、学習済み LoRA を動かすには専用デプロイが必須
- コンソール(app.fireworks.ai)は
/models・/dashboard・/account・/settings・/fire-passの 5 系統のパスに分かれており、本ガイドの各章はそれぞれ異なる画面を担当する - アカウント全体の支出は支出ティアで管理され、ティアが上がるほどサーバーレスの利用可能キャパシティが広がる。月次の支出上限は別のアカウント制御で、レガシーの後払いアカウントのみティアと連動する
次の 第 2 章 では、実際にアカウントを作成し、API キーを発行して、はじめての API 呼び出しを行う。