民生用グラフィックカードでエージェントを実行するコストの計算方法: 電気代、減価償却費、およびタスクあたりのコスト

Sat, 11 Jul 2026 10:30:00 +0800

コンシューマーグレードのグラフィックスカードがローカルエージェントを実行する価値があるかどうかを知りたい場合、「グラフィックスカードのコスト」だけを調べることはできません。また、API の 100 万トークンあたりの単価を比較することもできません。エージェントはモデル、ツール、ブラウザを繰り返し呼び出します。長いコンテキスト、失敗した再試行、およびアイドル状態のスタンバイはすべて、実際のコストを変更します。

最も現実的な方法は、コストを電気代、ハードウェア減価償却費、サポート機器、手動メンテナンスの 4 つの項目に分割し、同時に「成功した各タスク」と「100 万個の出力トークンあたり」に従って計算することです。

まず計算したいコストを決定します

口径	答えるのに適した質問	見逃しやすいアイテム
増分コスト	私はすでにゲーム機を持っています。空き時間にエージェントを実行するとどれくらいの費用がかかりますか?	グラフィックスカードはすでにあるのですが、減価償却費に含まれますか?
全額負担	地元代理店専用のマシンを購入するのは費用対効果が高いですか?	ホスト、メモリ、SSD、冷却および減価償却
タスクあたりのコスト	ドキュメントとコードのタスクを自動化するにはどれくらいの費用がかかりますか?	失敗、再試行、および手動レビュー
スループットコスト	自己構築の推論サービスを構築するための 100 万トークンあたりのコストはいくらですか?	トークン、KV キャッシュ、アイドル時間を入力します

グラフィックスカードが元々ゲームやその他の作業に使用されていた場合は、最初に増分コストを計算する方が正確です。エージェント用にマシン全体を購入した場合にのみ、マシン全体の減価償却費が全額含まれます。

月額合計費用の計算式

まず、月次キャリバーを使用します。データを取得するのが最も簡単です。

月度总成本 = 电费 + 硬件月折旧 + 配套服务费 + 人工维护成本

电费 = 实测整机平均功耗(kW) × 实际运行小时数 × 电价(元/kWh)
硬件月折旧 = (购入总价 - 预估残值) ÷ 使用月数
单次成功任务成本 = 月度总成本 ÷ 月成功任务数
每百万输出 token 成本 = 月度总成本 ÷ 月输出 token 数 × 1,000,000

「マシン全体の平均消費電力」は、グラフィックスカードの公称 TBP だけを調べるのではなく、ソケットの電力メーターまたは UPS から可能な限り取得する必要があります。エージェントは、CPU、メモリ、SSD、ファン、モニターでも実行されます。 GPU の消費電力のみを使用すると、電気代が過小評価されます。逆に、マシンがスタンバイ状態であってもタスクを処理していない期間は、純粋な推論コストに混入すべきではなく、別個に記録するのが最善です。

置換可能なパラメータの例

実際のエージェントのワークロードでマシンの平均消費電力が 280 W と測定され、1 日 6 時間、1 か月に 30 日稼働すると仮定します。現地の電力料金は 0.8 元/kWh として計算されます。この目的のために購入したハードウェアは 7,000 元、36 か月で償却され、残存価値は無視されます。

1
2
3

电费 = 0.28 × 6 × 30 × 0.8 = 40.32 元/月
硬件折旧 = 7,000 ÷ 36 = 194.44 元/月
月度基础成本 = 234.76 元/月

今月、受け付けたタスクが 600 件完了した場合、基本コストはタスクあたり約 0.39 元となります。ここでの「完了」はモデルの返却としてのみカウントされるものではありません。スクリプトの実行の成功、作業指示の完了、手動検査の合格などのビジネス結果に基づく必要があります。

これは単なる計算例であり、普遍的な価格ではありません。消費電力量、使用時間、電気料金、購入金額、タスク量などを自分のデータに置き換えてこそ意味があります。

エージェントの見積もりが通常のチャットよりも難しいのはなぜですか?

チャットモデルはトークンによって請求されることが多く、エージェントのコストは実行パスにも影響されます。

タスクには、計画、検索、ツールの呼び出し、結果の読み取り、および複数回の修正が含まれる場合があります。
コンテキストが長くなるほど、より多くの KV キャッシュが占有されます。ビデオメモリが不足すると、速度が低下し、CPU/RAM がアンロードされ、さらには再試行が発生します。
ブラウザの自動化、コードテスト、ファイル処理により、GPU が常に完全に負荷されていない場合でも、タスク時間が長くなる可能性があります。
マルチエージェントの並列化によりスループットは向上しますが、メモリ競合、キューイング、および障害率も増加する可能性があります。
最初のトークンの遅延を減らすために、常駐モデルではアイドル時の消費電力が増加します。

したがって、エージェントのコストを表すために短い質問と回答のトークンを使用しないでください。少なくとも一連の実際のタスクを選択し、それらを 1 週間連続して実行し、入出力トークン、成功率、再試行回数、実時間、およびマシン全体の電力消費量を記録します。

同時に見るべき2つのユニット

成功したすべてのタスク

これはビジネス上の意思決定に最も近いものです。「現地エージェントがPRを自動処理する」「データを一括収集する」「カスタマーサービスドラフト作成」などの固定プロセスを比較するのに適しています。

`1`	`每个成功任务成本 = (本周期全部成本) ÷ 成功且验收通过的任务数`

失敗したタスクは分子から削除できません。それらが消費する電力、推論時間、および手動のトラブルシューティングが、ローカルシステムの実際の運用コストとなります。

100万トークンあたり

これは、オンプレミスの推論サービスとクラウド API を比較しながら、入力と出力を区別するのに適しています。多くのエージェントの入力には長いツールログと履歴コンテキストが含まれており、入力トークンは出力トークンよりもはるかに多くなります。出力トークンのみで割ると、数値は大きくなります。より信頼性の高いアプローチは、入力、出力、および合計トークンを同時に記録し、同じ統計的精度を維持することです。

自分のデータを収集する方法

最初から複雑な監視システムを構築する必要はありません。まずテーブルを作成し、実行ごとに次のフィールドを記録します。

分野	記録方法
開始時間と終了時間	エージェントログまたはタスクキュー
マシン全体の消費電力	スマートコンセント、電力メーターまたはUPS
入出力トークン	推論サービスのログまたはクライアント統計
成功、失敗、再試行	タスクのステータスとエラーログ
手動レビュー時間	作業命令、PR、または抜き打ち検査記録
モデルと定量化されたバージョン	同じデータセット内に異なるモデルを混在させないでください。

ベースラインとして 20 ～ 50 の代表的なタスクから始めます。次に、短いコンテキスト、長いコンテキスト、多くのツール呼び出し、および多くの再試行を含むタスクを個別にテストして、メモリとモデルの選択がコストに与える影響を確認します。ビデオメモリの計画は、ローカルモデルの定量化とビデオメモリの選択と組み合わせて判断できます。

誤解を招かないように減価償却を計算する方法

減価償却に対する唯一の答えはありませんが、まず前提条件を書き留める必要があります。

既存のグラフィックスカード: 電気代と追加のメンテナンスは増分コストとしてのみ計算できます。グラフィックスカードの機会費用を、より控えめな全額費用として設定することもできます。
新しく購入した機器: グラフィックスカード、ホスト、メモリ、SSD、ラジエーターが一緒に含まれている必要があります。グラフィックスカードの価格をただばら撒かないでください。
寿命: 24、36、または 48 か月が有効です。重要なのは、同じ仮定を使用してオンプレミスとクラウドを比較することです。
残価: 機器の再販が見込まれる場合、推定残価を購入価格から差し引くことができます。不確実な場合は 0 に設定すると、結論はより保守的になります。

NAS または小規模ホストは通常、消費電力が少なくなりますが、メモリ、冷却、拡張機能によってモデルと同時実行性も制限されます。このルートを検討する場合は、まず NAS 導入 Ollama の性能判断を読んでください。

クラウド API と比較する場合は、単価だけを比較しないでください

クラウド側はタスクあたりのコストに変換することもできます。

`1`	`云端每任务成本 = 模型 API 费用 + 工具/API 费用 + 必要的存储与网络费用 + 人工复核成本`

通常、ローカルは次のような状況に適しています。

毎日安定して予測可能なワークロードがあり、マシンの使用率は高くなります。
データを外部サービスに送信できないか、送信することが期待されていません。
すでに動作する GPU があるため、追加コストは主に電気代になります。
自己保守可能なモデル、ドライバー、サービス、およびクラッシュ回復は許容されます。

多くの場合、クラウドは次のような状況に適しています。

負荷は散発的であり、マシンはほとんどの時間アイドル状態になります。
タスクには、ローカルビデオメモリをはるかに超える大規模なモデル、非常に長いコンテキスト、またはピーク同時実行性が必要です。
チームはドライバー、モデルのアップグレード、監視、トラブルシューティングを引き受ける気はありません。
タスクの結果は価値が高く、最も強力なモデルまたはマルチモーダル機能が最初に必要です。

ローカル展開は、2 つのオプションから選択するだけではありません。安定したプライバシーに配慮したステップはローカルに配置されます。複雑で低頻度のステップ、またはより強力なモデルを必要とするステップはクラウドに呼び出され、多くの場合、総コストの制御が容易になります。

実際的な決定ライン

ローカルの毎月の固定コストを F として記録し、タスクごとの変動電力およびメンテナンスコストを v として、クラウドのタスクごとのコストを c として記録します。 c > v の場合、ローカル損益分岐点を達成するために必要なタスクのおおよその量は次のとおりです。

`1`	`每月盈亏平衡任务数 = F ÷ (c - v)`

c が v 未満またはそれに近い場合、規模の関係でローカルの料金が大幅に安くなるわけではありません。現時点では、プライバシー、遅延、制御性、オフライン機能をさらに考慮する必要があります。この計算式は単なる財務フィルターであり、依然として失敗率と手動によるレビュー時間が必要です。

よくある誤解

グラフィックスカードの消費電力のみに注目してください: マシン全体の電力、スタンバイ、および冷却にも支払う必要があります。
名目上のトークン/秒をスループットと考えてください: 実際のエージェントは、コンテキスト、ツール、ネットワーク、テストステップによって速度が低下します。
失敗したタスクを無視する: 最も頻繁に再試行されるプロセスは、多くの場合コストブラックホールです。
モデル料金のみが計算されます: ブラウザー、検索、ベクターライブラリ、ストレージ、人間によるレビューの料金も適用される場合があります。
異なるモデルのデータの混合: 量子化バージョン、コンテキストの長さ、同時実行性が異なるため、結果を水平方向に比較することはできません。

要約する

消費者向けのグラフィックカードでエージェントを実行するコストは、「1 時間あたり数キロワット時の電力」だけで答えられるべきではありません。まずマシン全体の測定された電力消費量を使用して電気コストを計算し、次に独自の減価償却の仮定に従ってハードウェアコストを追加し、最後に成功したタスクの数と償却するトークンの量を使用します。実際のワークロードの期間を継続的に記録した後、ローカルでの実行を継続するか、ビデオメモリを拡張するか、一部のステップをクラウド API に引き渡すかを明確に判断できます。

コスト計算 on KnightLiブログ

民生用グラフィック カードでエージェントを実行するコストの計算方法: 電気代、減価償却費、およびタスクあたりのコスト