Why does on-device inference have a one-time cost instead of a per-inference cost like cloud APIs?

Because the expensive part of on-device inference is building it, not running it. Quantizing a model down to a size that fits on a phone, converting it to Core ML or a TensorFlow Lite / NNAPI format, testing it across device tiers, and shipping it inside the app binary or as a downloadable asset is a fixed engineering project with a fixed price tag, paid once regardless of whether one user or ten million users end up running it. A cloud API instead bills per request because the provider's GPU time is a real marginal cost on every single call. Once the on-device model is quantized and shipped, running one more inference on a user's own phone costs the app owner essentially nothing beyond a sliver of the user's battery and compute — no server, no per-call bill — which is exactly what turns the one-time setup cost into something worth amortizing over months rather than expensing per call.

What happens if my on-device-capable percentage is low — does on-device ever stop being worth it?

Yes, and this calculator is built to show exactly where that line is. As the on-device-capable percentage drops, more of your user base falls back into the cloud-only bucket, so the residual monthly cloud bill climbs back toward the pure-cloud baseline while you are still paying to amortize the setup cost on top of it — at some low enough capable percentage, the hybrid approach can cost more than pure cloud ever would have, not less. The other lever that matters just as much is total inference volume: the same setup cost that pays for itself in under a month at 100,000 monthly active users can take many months, or effectively never break even within a product's lifetime, at a few thousand users, because there simply are not enough inferences being deflected off the cloud bill to recoup the build cost. Before committing engineering budget to an on-device build, it is worth plugging in your actual MAU and your best real estimate of device capability rather than assuming the economics scale down linearly.

Why is there still a cloud bill even for users running on-device?

Because on-device capability is never all-or-nothing in practice. Even on a phone that is fully capable of running the local model, some fraction of queries still need to go to the cloud: a query too complex or too far outside the local model's scope for a compressed on-device version to handle well, a low-battery or thermal-throttling situation where the OS restricts on-device compute, a cold-start window before the local model asset has finished downloading after install or update, or simply a local inference that comes back low-confidence and needs a cloud model to double-check it. This calculator models that as a cloud-fallback percentage applied only to on-device-capable users' queries, on top of the full cloud bill still owed by the users whose devices cannot run on-device inference at all — so the residual cloud line item in the hybrid total is never zero, even at very high device-capability rates.

How is this different from the self-hosted LLM vs API calculator already on this site?

Both the Self-Host vs API Calculator and the Self-Hosted LLM vs API Calculator already on this site model server-side self-hosting: renting your own GPU instance or cloud box and running inference there yourself, compared against paying a cloud provider per token or per call — the cost shape in both cases is still a server somewhere with a hosting bill, just yours instead of a vendor's. This calculator models something structurally different: client-side on-device inference running directly on the end user's own phone hardware, where there is no server to rent and the marginal cost per inference is effectively zero once the model ships. What replaces the hosting bill here is a one-time engineering cost to build and quantize the model, amortized over months, plus a capped ceiling on how much cloud spend you can actually deflect — set by what fraction of your users own capable-enough devices and how often even those devices still need to fall back to the cloud.

エッジ/オンデバイス AI 推論とクラウド API の比較 |モバイルアプリの損益分岐点

品目	推論/月	月あたりのコスト
純粋なクラウドのベースライン (100% クラウド、オンデバイスなし)	—	—
— クラウド専用ユーザー (オンデバイス対応ではない)	—	—
— オンデバイス対応ユーザーからのクラウドフォールバック	—	—
= ハイブリッドクラウドの請求書	—	—
+ 償却後のオンデバイスセットアップコスト	—	—
= ハイブリッドの月額総コスト	—	—

これが他のツールにどのように接続されるか

このサイトにはすでに 2 つの計算ツールがあり、関連するものの構造的に異なる決定の価格を決定しています。のセルフホストと API のコスト計算ツールそしてセルフホスト型 LLM と API の計算ツール両方のモデル サーバー側 セルフホスティング — トークンごとまたは呼び出しごとにプロバイダーに支払うのと比較して、独自の GPU またはクラウドインスタンスをレンタルし、そこで推論を自分で実行します。どちらのコスト形態でも、実際のホスティング料金がかかるサーバーはどこかにあり、ベンダーのものではなくあなたが管理するものにすぎません。この計算機は代わりにモデルを作成します クライアント側 オンデバイス推論はエンドユーザーの電話ハードウェア上で直接実行されます。サーバーをレンタルする必要はなく、モデルの出荷後は推論あたりの限界コストが事実上ゼロになります。また、まったく別のボトルネックがあります。GPU 時間ではなく、十分な機能を備えたデバイスを所有しているユーザーの割合と、それらのデバイスでさえクラウドにフォールバックする必要がある頻度です。 GPU ボックスをレンタルするか、クラウド API に料金を支払うかを決定する場合は、セルフホスト型の計算ツールを使用してください。量子化モデルをモバイルアプリ自体の内部で出荷するかどうかを決定している場合、これがそのコスト形状に一致するものになります。

数字の読み方

デフォルトでは、月間アクティブユーザー数 100,000 人、ユーザーあたり 1 日あたり 50 回の推論、クラウド推論あたり 0.001 ドル、1 回限りのオンデバイスビルド、40,000 ドルの 1 回限りのデバイス上でのユーザー、60% のユーザーが対応デバイス、これらの対応ユーザーの 5% のクラウドフォールバック率、12 か月で償却される場合、純粋なクラウドのベースラインは月額 150,000 ドルとなります。ハイブリッドに移行すると、クラウドの残りの請求額は月額 64,500 ドル (クラウドのみのユーザーからの推論 60,000,000 回と、有能なユーザーからのフォールバック推論 4,500,000 件) に下がり、償却セットアップ費用が月額約 3,333 ドル追加され、ハイブリッドの合計は月額約 67,833 ドルに達します。つまり、月額約 82,167 ドルの節約となります。 ピュアクラウドのベースラインから 55% オフ。 40,000 ドルのセットアップコスト自体は、この量であれば、半月もかからずに元に戻ります。毎月のクラウド費用 (約 85,500 ドル/月) によって、1 回限りの構築コストがすぐに小さくなってしまうからです。この計算は、より低いスケールでは急速に変化します。同じ入力を 100,000 ユーザーではなく 5,000 ユーザーで実行すると、損益分岐点は約 20 倍に伸びます (半月未満ではなく約 9.4 か月)。これは、構築コストをすぐに回収するのに十分な月あたりの偏向推論が存在しないためです。オンデバイスビルドにエンジニアリング予算を投入する前に、野心的な MAU ではなく、アプリの実際の MAU を組み込みます。

エッジ/オンデバイス AI 推論とクラウド API の計算ツール

使用量とクラウドの料金

デバイスの機能とフォールバック

コストの内訳

これが他のツールにどのように接続されるか

数字の読み方

この計算機の仕組み

よくある質問

クラウド API のような推論ごとのコストではなく、オンデバイス推論に 1 回限りのコストがかかるのはなぜですか?

オンデバイス対応のパーセンテージが低い場合はどうなりますか? オンデバイスの価値がなくなることはありますか?

オンデバイスで実行しているユーザーに対してもクラウド料金が発生するのはなぜですか?

これは、このサイトにすでにあるセルフホスト型の LLM と API の計算ツールとどう違うのですか?