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

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

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

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

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

月額合計費用の計算式

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

1
2
3
4
5
6

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

电费 = 实测整机平均功耗(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 を比較しながら、入力と出力を区別するのに適しています。多くのエージェントの入力には長いツール ログと履歴コンテキストが含まれており、入力トークンは出力トークンよりもはるかに多くなります。出力トークンのみで割ると、数値は大きくなります。より信頼性の高いアプローチは、入力、出力、および合計トークンを同時に記録し、同じ統計的精度を維持することです。

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

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

ベースラインとして 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 に引き渡すかを明確に判断できます。