AIエージェント on KnightLiブログ

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

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 に引き渡すかを明確に判断できます。

ローカルエージェントの Windows WSL 導入チュートリアル: Ollama、Codex OSS および権限制御

Sat, 11 Jul 2026 09:42:40 +0800

Windows にローカルエージェントをデプロイする場合、通常、最も安心できる構造は、モデルサービス、Docker、ターミナル、コーディングツールを Windows、WSL、および複数の仮想環境に分散させるのではなく、それらを同じ WSL2 Ubuntu ディストリビューションに配置することです。

Windows
└─ WSL2 Ubuntu
   ├─ Ollama：本地模型服务
   ├─ 本地模型：聊天、代码、Embedding
   ├─ Codex OSS：Agent 客户端
   └─ 项目目录：代码、Git、测试命令

このように、Ollama とエージェントは WSL の localhost を通じて直接通信し、パス、権限、ログはすべて Linux 環境にあります。 Windows 側は、Windows ターミナル、VS Code リモート WSL、またはエクスプローラーを使用してプロジェクトに引き続きアクセスできます。

まず結論から話しましょう

利用可能な最小ルートは次のとおりです。

安装 WSL2 Ubuntu
-> 在 Ubuntu 安装 Ollama 和一个小模型
-> 在 Ubuntu 内验证 ollama run
-> 用 codex --oss --local-provider ollama 启动 Agent
-> 先执行只读任务
-> 再逐步允许修改、测试和工具调用

最初からローカルエージェントに完全な権限を与えたり、最大のモデルを最初に追求したりしないでください。複雑なエージェント、リモートポート、およびマルチエージェントオーケストレーションを最初に扱うよりも、安定して実行できるモデル検証プロセスを最初に使用することが重要です。

ステップ 1: WSL2 と Ubuntu をインストールする

Windows 上の管理者 PowerShell で実行します。

`1`	`wsl --install`

再起動後、デフォルトで Ubuntu がインストールされます。初めて Ubuntu を開いたときは、プロンプトに従って Linux ユーザー名とパスワードを作成します。

ディストリビューションが WSL2 を使用していることを確認します。

`1`	`wsl -l -v`

古いディストリビューションがまだバージョン 1 である場合は、次のように変換できます。

`1`	`wsl --set-version Ubuntu 2`

Ubuntu を入力します。

wsl

後続のコマンドのほとんどは、PowerShell ではなく Ubuntu ターミナルで実行されます。

ステップ 2: Ubuntu 基本環境を準備する

WSL に入ったら、まずシステムを更新します。

1
2
3

sudo apt update
sudo apt upgrade -y
sudo apt install -y curl git ca-certificates

環境を確認します:

1
2
3

uname -a
pwd
git --version

プロジェクトを Linux ファイルシステムに配置することをお勧めします。次に例を示します。

1
2

mkdir -p ~/projects
cd ~/projects

/mnt/c/... では、高頻度の Git、Node.js、Python 仮想環境および大規模な依存関係を実行しないでください。一部の開発タスクではファイルシステム間のアクセスが遅くなり、権限やファイルリスニングの違いが発生する可能性が高くなります。 Windows からプロジェクトを開く必要がある場合は、VS Code のリモート WSL 機能を使用できます。

ステップ 3: WSL 内で Ollama をインストールして検証する

Ollama Linux のインストール方法に従います。

`1`	`curl -fsSL https://ollama.com/install.sh \| sh`

まず、現在のターミナルでサービスを開始します。

`1`	`ollama serve`

別の WSL ターミナルを開き、モデルをダウンロードしてテストします。

1
2

ollama pull qwen3:8b
ollama run qwen3:8b

モデルの選択は、GPU メモリまたは CPU/メモリによって決定する必要があります。使用可能な GPU がない場合は、より小さいモデルを使用して最初にプロセスを検証します。「大きなモデルファイルをダウンロードできる」ことを「このマシンはスムーズな推論を実行できる」と誤解しないでください。

サービスとモデルのステータスを確認します。

1
2

ollama ls
ollama ps

ollama run 自体が安定して出力できない場合は、機種、ビデオメモリ、ドライバ、メモリの問題を解決してからエージェントに接続してください。

ステップ 4: WSL GPU が実際に利用可能かどうかを確認する

NVIDIA GPU を使用している場合は、WSL 内で実行します。

`1`	`nvidia-smi`

グラフィックスカードを表示できるということは、Ollama が GPU を使用したことを意味するわけではありませんが、少なくとも WSL がドライバーを認識していることを証明しています。モデルを開始した後、次を実行します。

1
2

ollama ps
nvidia-smi

モデルが GPU を使用しているかどうか、およびビデオメモリが増加しているかどうかを観察します。

nvidia-smi が存在しない場合、またはエラーが報告された場合は、まず NVIDIA ドライバー、WSL バージョン、および Windows の GPU サポートを確認してください。急いで Ubuntu にデスクトップ Linux ドライバーを繰り返しインストールしないでください。 WSL の GPU サポートには独自のドライバーリンクがあります。

ステップ 5: Codex にローカルの Ollama を使用させる

Codex は、ローカルプロバイダーとして Ollama または LM Studio のオプションを備えた OSS モードを提供します。 Codex がインストールされ、WSL 内で実行可能になったら、プロジェクトディレクトリに移動します。

`1`	`cd ~/projects/your-project`

初めて読み取り専用権限で開始することをお勧めします。

`1`	`codex --oss --local-provider ollama --sandbox read-only`

まず、ファイルを変更しないタスクを与えます。

`1`	`阅读当前仓库的 README 和目录结构，说明启动、测试和构建命令。不要修改任何文件。`

ローカルモデルがウェアハウスを理解でき、答えが安定していることを確認したら、必要に応じてワークスペースの書き込み権限を使用します。ローカルモデルだからといって、Git、テスト、権限を無視しないでください。

Ollama をデフォルトのローカルプロバイダーとして使用する場合は、ユーザーレベルの Codex 構成に ~/.codex/config.toml を追加します。

`1`	`oss_provider = "ollama"`

次に、次のコマンドを使用します。

`1`	`codex --oss`

プロバイダー関連の構成は、プロジェクト内の .codex/config.toml ではなく、ユーザーレベルの構成に配置する必要があることに注意してください。プロジェクト構成では、マシンのモデルプロバイダーを密かに変更しないでください。

ステップ 6: 常駐サービスが必要な場合に systemd を有効にする

WSL Ubuntu の新規インストールでは通常、デフォルトで systemd がすでに使用されています。最初のチェック:

`1`	`systemctl status`

現在のディストリビューションで systemd が有効になっていない場合は、次を編集します。

`1`	`sudo nano /etc/wsl.conf`

参加してください:

1
2

[boot]
systemd=true

次に、Windows PowerShell に戻ります。

`1`	`wsl --shutdown`

Ubuntuに再起動した後、systemctl statusを再度確認してください。

Ollama を常駐サービスにするかどうかは、インストール方法とバックエンド API が必要かどうかによって異なります。初めて学習を開始するときは、ollama serve ターミナルを保持してログを確認するのが最も簡単です。安定していることが確認できたら、systemd を使用してサービスを管理します。

WSL 内のパス、ポート、および API

デフォルトでは、Ollama サービスは以下を使用します。

`1`	`http://localhost:11434`

エージェント、スクリプト、および Ollama がすべて同じ WSL ディストリビューション内にある場合、このローカルアドレスが最初に使用されるため、最初に LAN ポートを開く必要はありません。

テストAPI:

`1`	`curl http://localhost:11434/api/tags`

Windows プログラム、携帯電話、またはローカルエリアネットワーク上のその他のデバイスで呼び出す必要がある場合は、ネットワーク公開方法、リバースプロキシ、および認証を個別に設計する必要があります。公開されたローカルモデルポートをパブリックネットワークに直接マッピングしないでください。

推奨されるリソースの評価

ハードウェアの状況	推奨される開始方法
専用グラフィックスなし、8GB ～ 16GB メモリ	小さなモデル、読み取り専用の分析、要約、および単純なスクリプト
8GBビデオメモリ	7B/8B 量子化モデル、シングルユーザーの短期から中程度のコンテキスト
12GB～16GBのビデオメモリ	8B の方が快適です。注意してより大きな定量モデルを試すことができます
24GB以上のビデオメモリ	より大きなモデル、より長いコンテキスト、またはより複雑なローカルエージェントタスクを検討してください。

モデルが大きいほど、エージェントの信頼性が高いというわけではありません。ローカルエージェントの場合、コマンド実行の安定性、コンテキスト、ツール呼び出し機能、タスク分割方法も結果に影響します。

最も陥りやすい罠

1. Windows と WSL はそれぞれ Ollama のセットを実行します

これにより、エージェントが実際にどのサービスに接続しているかを判断することが困難になります。初期展開では、WSL 内で Ollama のセットを 1 つだけ実行し、すべてのテストを同じ WSL 端末で完了することをお勧めします。

2. `/mnt/c` ですべての開発タスクを実行します。

アクセス可能ですが、インストール、ファイルのリスニング、Git のパフォーマンス、Linux 権限の動作によっては理想的ではない可能性があります。 ~/projects 内のアクティブなプロジェクトに優先順位を付けます。

3. ローカルモデルなので最初からファイルを書き込むことが可能

まず --sandbox read-only を使用して、モデルがタスクを理解しているかどうかを確認します。変更フェーズに入ったら、差分を確認し、テストを実行し、Git を使用してフォールバックポイントを保持する前に、計画について説明させる必要もあります。

4. ポートを開いた後は認証は行われません。

ローカル API に LAN アクセスが許可されると、それは単なる「自分のコンピュータ上のサービス」ではなくなります。ファイアウォールソースを最小限に制限し、必要に応じてリバースプロキシ層で認証と HTTPS を追加します。

5. インストールが成功すると、自動的にバックグラウンドで実行されると考えます。

WSL が閉じられるか、ディストリビューションが停止されると、フォアグラウンドプロセスは終了します。長期的なAPIが必要な場合は、まずsystemd、サービスの状態、Windows/WSLの運用ポリシーを確認してください。

要約する

Windows WSL はローカルエージェントを展開します。最も信頼性の高い最初のバージョンは次のとおりです。

WSL2 Ubuntu
-> Ollama 跑通小模型
-> Codex OSS 模式只读分析仓库
-> Git 和测试验证
-> 再增加写权限、服务常驻和局域网 API

モデル、エージェント、コードを同じ WSL 環境に維持すると、パス、ポート、権限の問題を半分以下に減らすことができます。 Docker、マルチモデルルーティング、RAG、またはリモートアクセスを検討する前に、最小限のプロセスが安定するまで待ってください。

参照:

AIエージェント on KnightLiブログ

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

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

月額合計費用の計算式

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

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

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

成功したすべてのタスク

100万トークンあたり

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

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

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

実際的な決定ライン

よくある誤解

要約する

ローカル エージェントの Windows WSL 導入チュートリアル: Ollama、Codex OSS および権限制御

まず結論から話しましょう

ステップ 1: WSL2 と Ubuntu をインストールする

ステップ 2: Ubuntu 基本環境を準備する

ステップ 3: WSL 内で Ollama をインストールして検証する

ステップ 4: WSL GPU が実際に利用可能かどうかを確認する

ステップ 5: Codex にローカルの Ollama を使用させる

ステップ 6: 常駐サービスが必要な場合に systemd を有効にする

WSL 内のパス、ポート、および API

推奨されるリソースの評価

最も陥りやすい罠

1. Windows と WSL はそれぞれ Ollama のセットを実行します

2. /mnt/c ですべての開発タスクを実行します。

3. ローカルモデルなので最初からファイルを書き込むことが可能

4. ポートを開いた後は認証は行われません。

5. インストールが成功すると、自動的にバックグラウンドで実行されると考えます。

要約する

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

ローカルエージェントの Windows WSL 導入チュートリアル: Ollama、Codex OSS および権限制御

2. `/mnt/c` ですべての開発タスクを実行します。