Basetenレビュー【2026年】料金の読み方とGPU分単価の罠

Basetenは、モデルの推論と学習、そして実行環境を1つの契約にまとめた基盤です。公式サイトの題名は「The platform for inference, training, and execution」（2026年11月4日確認）。料金はBasicが0ドルで、使った分だけ支払う形になり、ProとEnterpriseは見積りです。GPUは分単位、Model APIは100万トークン単位という別々のものさしが同じ料金ページに並ぶため、比較のときは土台を揃える作業が要ります。この記事は実際の操作を行わず、2026年11月4日に確認できた公開情報だけを材料にした整理です。待ち時間、スループット、日本語の出力品質は未検証です。

Basetenとは何か。推論・学習・実行を1か所に寄せる基盤

Basetenは、モデルを動かすための土台をまとめて提供する製品です。公式の題名は「The platform for inference, training, and execution」で、推論だけの会社として名乗っていません。学習、配備、実行環境までを同じ請求の中に置くところが、APIを1本借りるサービスとの違いになります。2026年11月4日時点の公式ナビゲーションには、Dedicated Inference、Model APIs、Training、Sandboxes、Gridという5つの製品が並んでいます。

Dedicated Inferenceは、自社のモデルを専有のGPUで動かす製品です。Model APIsは、主要なモデルをそのままAPIで呼ぶための製品で、公式は「production-ready APIs for frontier models on day zero」と説明しています。Trainingは自前のコードか、Loopsという学習用のSDKでモデルを鍛える部分。Sandboxesはエージェントに安全な実行場所を渡す製品で、Gridはモデルへのアクセスを統制し、利用量を見て、要求を振り分ける層だと説明されています。

5つを並べると、狙いが見えてきます。モデルを預けて終わりではなく、学習させ、配り、動かし、統制するところまでを同じ契約で扱う形です。作業が分断されていると、学習したモデルを配る段で別の業者と契約し、統制の層でもう一段契約が増えます。そのたびに認証と請求の確認が発生するのが、現場では地味に重い負担になります。1か所に寄せる価値は、機能の数より、この契約の数を減らせることにあります。

一方で、5つの製品を全部使うチームは多くありません。公開情報を読む限り、実務で最初に触るのはDedicated InferenceかModel APIsのどちらかです。学習はモデルを自作しているチームに限られ、SandboxesとGridはエージェント運用が始まってから必要になる層です。全部を理解してから契約する必要はなく、入口を1つに絞ってよい製品だと考えます。

自前ホストに向く案件か、APIで足りるか

判断の材料は、モデルを自分で選ぶ必要があるかどうかです。業務の事情で特定のモデルを固定したい、微調整したモデルを使いたい、入力データを外に出したくない。この3つのどれかが必須なら、専有GPUの側に寄せたほうが設計は素直になります。逆に、汎用のモデルで足りて、品質より実装の速さを優先するなら、Model APIsから入るほうが短い道です。モデルを選ぶ権利が要るかどうかが、専有GPUとAPIの分かれ目になります。この問いに答えられないまま料金表を眺めると、単価の安いほうに引っ張られて、後から載せ替えることになります。

Basetenの料金はいくらか。3つの層に分けて読む

料金の入口は単純です。Basicは0ドルで、使った分だけ支払います。ProとEnterpriseは見積りで、公開された金額はありません（2026年11月4日確認）。ここで止まらずに中身を見ると、課金は3つの層に分かれています。専有GPUの時間、Model APIのトークン、SandboxesのCPUとメモリです。

専有GPUの単価は、すべて分単位で示されています。T4が0.01052ドル、L4が0.01414ドル、A10Gが0.02012ドル。A100 80GBが0.06667ドル、H100 MIG 40GBが0.0625ドル、H100 80GBが0.10833ドル、B200 180GBが0.16633ドルです。CPUだけは1分0.00058ドルからという書き方で、こちらはマシンの大きさごとに段が分かれています。

Model APIは100万トークン単位の表示です。GLM-5.3は入力1.40ドル、キャッシュ入力0.14ドル、出力4.40ドル。DeepSeek V4.1 Flashは入力0.30ドル、キャッシュ入力0.007ドル、出力1.20ドルです。入力と出力で単価が違う点、キャッシュを効かせると入力の単価が下がる点は、どこの事業者でも同じ考え方ですが、差が大きいので見積もりのときは3つの列を分けて計算する必要があります。

Sandboxesは、CPUが1時間0.0655ドル、メモリが1GBあたり1時間0.0211ドルです。エージェントを動かす時間が長いほど、この層が静かに積み上がります。推論の単価だけを見て見積もりを出すと、実行環境の費用を落としてしまいます。表示は地域・支払い周期・為替で変わるため、契約前に公式サイトの料金表を確認してください。

ProとEnterpriseの違いは、公開情報では金額から読み取れません。見積もりの場で確認したいのは、単価が下がるのか、サポートの応答が変わるのか、それとも統制の機能が増えるのかという3つです。この3つを聞かずに「上位プランはいくらか」とだけ尋ねると、金額は出ても判断の材料になりません。特にGPUの単価は、契約の規模で段が変わる可能性があるため、最初に聞くべき項目です。公開されているBasicの単価は、あくまで入口の数字だと考えるべきです。

専有GPUとModel APIのどちらを先に試すか

順序を間違えると、比較のための費用が無駄になります。先に試すべきは、自分たちの負荷の形が読めているかどうかで決まります。1日の呼び出し回数と、時間帯の偏りが説明できるなら、専有GPUの見積もりは計算できます。それができない段階なら、Model APIで実際の利用量を測るほうが先です。負荷の形が読めないうちに専有GPUを契約すると、遊んでいる時間を買うことになります。逆に、負荷が読めていて常時動かす前提なら、トークン課金より分課金のほうが上限を固定できます。

GPUの「分」とAPIの「トークン」は、何が違うのか

この2つを同じ表に入れて安い高いを論じると、ほぼ間違えます。分は時間、トークンは処理した量です。分母が違うので、単価をそのまま並べても意味を持ちません。揃えるべきなのは、同じ1か月の仕事を任せたときの総額です。その総額を出すには、両方の請求の形を理解しておく必要があります。

専有GPUは、動かした時間に対して請求が発生します。アクセスがゼロの時間も、GPUを確保していれば費用は動きます。その代わり、1分あたりいくらで上限が読めるので、予算の天井を作りやすい。Model APIは、処理したトークンに対してだけ請求が発生します。使われない時間の費用は乗りませんが、利用が伸びた月は青天井になります。

具体例で考えます。社内文書の検索を社員300人に配る場面を想定します。平日の9時から18時に集中し、夜間はほぼ使われないなら、専有GPUを24時間確保すると夜の分が無駄になります。逆に、海外拠点も含めてほぼ全時間帯に呼び出しがあるなら、時間での確保は読みやすい固定費になります。同じ製品でも、働く時間帯が違うだけで結論が変わります。

トークンの側にも落とし穴があります。入力が長い文書で、出力が短い要約のような処理は、入力の単価が効いてきます。反対に、短い質問に対して長い回答を返す処理は、出力の単価が支配的です。同じモデルでも、処理の形によって請求の重心が移動します。見積もりの前に、平均の入力長と出力長を実測しておく価値は大きいと考えます。

キャッシュ入力の列は、見落とされやすいですが効きます。GLM-5.3なら入力が1.40ドル、キャッシュ入力が0.14ドルで、桁が1つ違います。同じ長い指示文を毎回の呼び出しに添える設計なら、その部分がキャッシュに乗るかどうかで請求が変わります。逆に、毎回違う文書を読ませる処理では、キャッシュはほとんど効きません。処理の形を見ずに単価だけを比べると、この差を読み違えます。

分単位課金が向くチーム、向かないチーム

向くのは、稼働率を自分でコントロールできるチームです。夜間バッチのように動く時間を決められる処理、社内利用のように人数と時間帯が読める処理は、分単位と相性がいい。向かないのは、アクセスの山が読めず、閑散時間が長く続くサービスです。その形で専有GPUを持つと、使っていない時間の請求がそのまま残ります。稼働率を上げる施策を持っているかどうかが、分単位課金の損益を分けます。料金表の単価ではなく、1日のうち何時間動かすかを先に決めるべきです。

評価できるところ。請求の形が仕事の形に合わせてある

• 料金の単位が製品ごとに明示されている。分、トークン、CPU時間が混ざらずに読める
• 推論から学習、実行環境まで同じ請求に収まる。契約と認証の数を減らせる
• GPUの選択肢が広い。T4からB200まで、モデルの大きさに合わせて段を選べる
• Model APIの入力、キャッシュ入力、出力が分けて表示されている。見積もりの精度を上げやすい
• Sandboxesのように、エージェントの実行場所まで料金表に載っている
• Basicが0ドルで従量課金。小さく始めて、請求を見ながら判断できる

一番の評価は、料金表の作りです。分単位とトークン単位という性質の違うものを、同じページに混ぜずに並べています。混ぜて1つの表にされると、読み手は単価の数字だけを比べてしまいます。分けて示してあるおかげで、どこを揃えて比べるかに気づけます。料金表の分かりやすさは、そのまま見積もりの作りやすさになります。

二つ目は、学習と推論が同じ場所にあることです。モデルを鍛えて、配って、動かして、統制する。この流れが1つの契約でつながると、どこかで止まったときに原因を追う範囲が狭くなります。別々の業者をまたぐ構成では、遅いのか、落ちているのか、設定が違うのかの切り分けに時間が取られます。運用の初動で差が出る部分だと考えます。

三つ目は、GPUの段の刻み方です。H100 MIG 40GBとH100 80GBが分かれているので、大きなモデルに必要なメモリを見積もったうえで、少し小さい段に落とせる余地があります。MIGは1枚のGPUを分割して使う考え方で、小さいモデルを複数動かすときに効きます。この段があるかないかで、月の固定費は変わります。

気になるところ。単価は見えるが、総額は見えない

• ProとEnterpriseの金額が非公開。比較表を作るには見積もりを待つ時間が要る
• 分単位の課金は、稼働率が低いと割高になる。閑散時間の請求が読みにくい
• GPUの単価に、ストレージや通信の扱いが含まれるかが公開情報では分からない（未検証）
• モデルAPIの一覧が頻繁に更新される。同じ名前で単価が変わる可能性を前提に置く必要がある
• Sandboxesの費用は、エージェントの設計次第で大きく動く。初期の見積もりに載せ忘れやすい

正直に書くと、一番の引っかかりは総額の見えにくさです。単価は丁寧に公開されています。ところが、実際にいくらになるかは、稼働率、入力長、出力長、キャッシュの効き方、Sandboxesの使い方で決まります。5つの変数が揃わないと総額が出ません。単価の透明さと、総額の読みやすさは別の話だということは、はっきり書いておきます。

二つ目は、分単位課金の性質です。使っていない時間にも費用が動く設計は、予測可能な代わりに、稼働率が低いと割高になります。試作の段階で専有GPUを契約すると、検証の時間より待ち時間のほうが長くなり、その分が請求に乗ります。試作はModel API、負荷が読めてから専有GPUという順序が無難です。この順序を逆にすると、最初の1か月で予算の感覚が狂います。

三つ目は、公開情報の粒度です。GPUとトークンの単価は細かく出ていますが、ストレージ、通信、サポートの扱いは公式の料金ページだけでは読み切れません。ProとEnterpriseの違いも、金額が非公開なぶん、機能の線引きが見えにくい。ここは未検証と明記して、見積もりの場で質問する項目になります。資料の美しさに引っ張られず、請求書の項目を想像しながら読むほうが安全です。

どんなチームに向き、どこで止まるか

向くのは、モデルを自前で選ぶ必要があり、稼働の形を説明できるチームです。社内利用で人数と時間帯が読める、夜間バッチで動く時間が決まっている、そういう案件は判断が速い。向かないのは、まず動くものを見たい段階のチームと、アクセスの山が読めない外向けサービスです。前者はModel APIで足り、後者はトークン課金のほうが被害が小さい。専有GPUは、稼働率の設計図が描けてから契約する製品です。この順序を守れるかどうかで、同じ単価でも結果が変わります。

Groq・Replicate・Together AIとの違いは？選び分けの軸

推論の受け皿は、Basetenだけではありません。公開情報で並べられるのは、料金の単位、モデルの選び方、運用の負荷、そしてどの層まで自分で持つかという4つの見方です。品質の優劣を同じ条件で並べた比較はできないため、ここでは構造の違いだけを扱います（未検証）。先に自社の条件を決めてから、候補の名前を減らす順序が現実的です。

モデルを配る相手として、GroqやReplicate、Together AIの名前が挙がります。どれも推論を提供する点は同じですが、料金の単位と、どこまで自分で触れるかが違います。速度を売りにする事業者、モデルの数で選ばせる事業者、専有に寄せる事業者と、性格が分かれます。並べるときは、単価ではなく、同じ1か月の仕事を任せた総額に直してから比べてください。

同じモデルを2社で見積もると、差の理由が見えます。片方が安いのは、単価が低いからなのか、含まれる範囲が狭いからなのか。この区別がつかないまま安いほうを選ぶと、後から足りない機能を買い足すことになります。見積もりの比較表は、金額の列より、含まれる範囲の列を広く取るほうが役に立ちます。

画像生成のように、モデルごとに課金の形が変わる用途ではRunwareのような選択肢もあります。オープンウェイトのモデルを自分で選びたいならFalcon LLMやUpstageのように、モデルそのものを提供する側を先に決める道もあります。モデルが決まったら、次に置き場所を決める。この順序なら、候補が増えすぎて比較が発散する事態を避けられます。

周辺の部品も、一緒に決まります。検索のためにPineconeやQdrantのような保存先を組み合わせ、処理の流れはLangChainやLlamaIndexで組む構成が一般的です。この層を先に固定すると、推論基盤の乗り換えが難しくなります。逆に、この層を薄く作っておけば、推論の置き場所は後から替えられます。最初から全部を1社に寄せないほうが、後年の選択肢は残ります。

他の推論基盤と何で選び分けるか

軸は3つに絞れます。自前のモデルを持ち込む必要があるか、稼働の形が読めているか、そして統制の層まで製品に求めるかです。3つとも当てはまるなら、Basetenの構成は筋が通ります。1つも当てはまらないなら、マネージドAPIで十分です。持ち込み、稼働、統制。この3つのうち2つ以上が要るなら、専有型を検討する価値があります。1つだけなら、その1つを別の手段で満たせないかを先に考えたほうが安く済みます。

導入前に決めること。最初の1か月の進め方

契約の前に確認したいのは、データの置き場所です。入力した文書や会話のログがどこに保存され、誰が見られ、学習に使われるのか。削除の依頼にどう応じるのか。この3つは料金表ではなく、契約書とプライバシー関係の文書に書かれています。単価の比較より先に、この3つを読む工程を置いてください。

試す順序は4段です。任せる処理を1つに絞る。その処理の入力長と出力長を、過去の記録から100件ほど数える。同じ100件をModel APIで流し、トークンの消費と待ち時間を記録する。その記録をもとに、専有GPUに置き換えた場合の月額を、稼働時間から逆算する。この順序なら、専有GPUを契約する前に、総額の当たりを付けられます。

見積もりの書式は、自分たちで作るほうが早いです。項目は、GPUの時間、トークンの消費、Sandboxesの時間、そして人件費。この4つを1枚に並べれば、どの層が重いかが一目で分かります。事業者が出す見積もりは、どうしても自社の製品を中心に組まれます。自社の様式で並べ直す作業が、そのまま交渉の材料になります。

撤退の条件も先に決めます。待ち時間が目標に届かない、単価が想定の範囲を超える、運用に人が取られすぎる。この3つのどれかに当たったら戻る、という線を引いておくと、判断が感情から離れます。乗り換えを前提に、モデルの呼び出しを1か所にまとめておく設計も有効です。この備えがあるだけで、最初の契約の重さが変わります。

社内を通すときは、単価ではなく総額の表を持っていきます。「毎分0.10833ドル」と書いた資料は、経理の前で止まります。「1か月に何時間動かすので、いくら」という形に直す必要があります。稼働時間の前提を資料に明記しておけば、前提が変わったときの議論も短くなります。数字の見せ方で、承認までの日数は変わります。

最初の1か月で測る3つ

初月の目標は、総額の予測を当てられるようになることです。測るのは、処理したトークンの量、GPUを動かした時間、そして人が介在した回数。この3つが揃えば、2か月目以降の請求はほぼ読めます。初月に単価を下げる交渉をするより、総額の予測を当てるほうが後の費用を下げます。数字が読めれば、どの層を削るかの議論ができます。読めないまま単価だけ下げても、使い方が変わるだけで総額は戻ります。

よくある質問

まとめ：単価ではなく稼働の設計図で選ぶ

主な参照元：Baseten公式サイト「The platform for inference, training, and execution」（2026年11月4日確認。製品構成、Basic 0ドル、Pro／Enterpriseの見積り、GPUの分単価、Model APIのトークン単価、SandboxesのCPU・メモリ単価はここによります）。料金ページ（2026年11月4日確認）。実機検証は未実施です。