消費級顯卡跑 Agent 成本怎麼算：電費、折舊與每任務成本

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

想知道一張消費級顯卡跑本地 Agent 值不值，不能只看“顯卡買了多少錢”，也不能只拿 API 的每百萬 token 單價對比。Agent 會反覆調用模型、工具和瀏覽器；長上下文、失敗重試、空閒待機都會改變實際成本。

最實用的做法是把成本拆成四項：電費、硬件折舊、配套設備與人工維護，然後同時按“每個成功任務”和“每百萬輸出 token”覈算。

先確定你要算哪一種成本

口徑	適合回答的問題	容易漏掉的項目
增量成本	已有遊戲主機，閒時跑 Agent 多花多少錢？	顯卡本來就有，是否計入折舊
全成本	爲本地 Agent 專門購買機器是否划算？	主機、內存、SSD、散熱和折舊
單任務成本	自動處理一份文檔、一次代碼任務要多少錢？	失敗、重試和人工複覈
吞吐成本	自建推理服務每百萬 token 的成本？	輸入 token、KV cache 和閒置時間

如果顯卡原本用於遊戲或其他工作，先算增量成本更誠實；只有爲了 Agent 新購整機時，才把整機折舊完整計入。

月度總成本公式

先用月度口徑，數據最容易獲得：

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

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

“整機平均功耗”應儘量來自插座功率計或 UPS，而不是隻看顯卡標稱 TBP。Agent 運行時還有 CPU、內存、SSD、風扇和顯示器；只用 GPU 功耗會低估電費。反過來，機器待機但沒有處理任務的時段，也不應混進純推理成本，最好單獨記錄。

一個可替換參數的示例

假設一臺機器在實際 Agent 工作負載下，插座實測平均功耗爲 280W，每天運行 6 小時，每月運行 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 元/任務。這裏的“完成”不能只算模型返回；應該以腳本執行成功、工單關閉、人工抽檢通過等業務結果爲準。

這只是演算示例，不是通用價格。把功耗、使用時長、電價、購機金額和任務量替換成自己的數據，纔有意義。

Agent 爲什麼比普通聊天更難估算

聊天模型常按 token 計費，而 Agent 的成本還受執行路徑影響：

一次任務可能包含計劃、檢索、調用工具、讀取結果和多輪修正。
上下文越長，KV cache 佔用越多；顯存不足時會降速、CPU/RAM 卸載，甚至觸發重試。
瀏覽器自動化、代碼測試和文件處理會拉長任務時間，即使 GPU 沒有持續滿載。
多 Agent 並行會提高吞吐，也可能讓顯存爭用、排隊和失敗率上升。
爲了降低首 token 延遲而常駐模型，會增加空閒功耗。

因此，不要用一次簡短問答的 tokens/s 代表 Agent 成本。至少選一組真實任務，連續跑一週，記錄輸入/輸出 token、成功率、重試次數、牆鍾時間和整機耗電量。

兩個必須同時看的單位

每個成功任務

這最貼近業務決策。適合比較“本地 Agent 自動處理 PR”“批量整理資料”“客服草稿生成”等固定流程。

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

失敗任務不能從分子中刪掉。它們消耗的電力、推理時間和人工排障，正是本地系統真實的運營成本。

每百萬 token

這適合對比本地推理服務和雲端 API，但要區分輸入與輸出。很多 Agent 的輸入包含長工具日誌和歷史上下文，輸入 token 遠多於輸出 token；若只除以輸出 token，數字會偏高。更穩妥的做法是同時記錄輸入、輸出和總 token，並保持同一統計口徑。

如何採集自己的數據

不需要一開始就搭建複雜的監控系統。先建立一個表格，每次運行記錄以下字段：

字段	記錄方式
開始與結束時間	Agent 日誌或任務隊列
整機耗電量	智能插座、功率計或 UPS
輸入/輸出 token	推理服務日誌或客戶端統計
成功、失敗、重試	任務狀態與錯誤日誌
人工複覈時間	工單、PR 或抽檢記錄
模型與量化版本	避免不同模型混在同一組數據裏

先用 20 到 50 個有代表性的任務做基線。隨後分別測試短上下文、長上下文、工具調用多和重試多的任務，才能看出顯存和模型選擇對成本的影響。顯存規劃可結合本地模型量化與顯存選擇一起判斷。

折舊該怎麼算纔不會誤導自己

折舊沒有唯一答案，但必須先把假設寫下來。

已有顯卡：可以只算電費和額外維護，作爲增量成本；也可以給顯卡設一個機會成本，作爲更保守的全成本。
新購設備：顯卡、主機、內存、SSD 和散熱器應一起納入；不要只攤顯卡價格。
使用壽命：用 24、36 或 48 個月都可以，關鍵是用同一假設比較本地與雲端。
殘值：預計設備能轉賣時，可從購入價中扣除預估殘值；不確定就設爲 0，結論更保守。

NAS 或小主機通常功耗較低，但顯存、散熱和擴展能力也會限制模型與併發。若考慮這條路線，可先看NAS 部署 Ollama 的性能判斷。

與雲端 API 比較時，不要只比單價

可以把雲端側也換算成每任務成本：

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

本地通常更適合這些情況：

每天有穩定、可預測的任務量，機器利用率較高。
數據不能或不希望發往外部服務。
已經擁有可用 GPU，增量成本主要是電費。
可接受自行維護模型、驅動、服務和故障恢復。

雲端通常更適合這些情況：

負載是偶發的，機器大部分時間會閒置。
任務需要遠超本地顯存的大模型、超長上下文或峯值併發。
團隊不願承擔驅動、模型升級、監控和故障排查。
任務結果價值高，優先需要最強模型或多模態能力。

本地部署也不是隻能二選一。穩定、隱私敏感的步驟放本地；複雜、低頻或需要更強模型的步驟調用雲端，往往更容易控制總成本。

一個實用的決策線

把本地每月固定成本記爲 F，每個任務的可變電力與維護成本記爲 v，雲端每任務成本記爲 c。當 c > v 時，本地達到收支平衡的大致任務量爲：

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

如果 c 小於或接近 v，本地不會因爲規模而明顯更省錢；此時應更多考慮隱私、延遲、可控性和離線能力。這個公式只是財務篩選，仍要加入失敗率和人工複覈時間。

常見誤區

只看顯卡功耗：整機電力、待機和散熱同樣要付費。
把標稱 tokens/s 當吞吐：真實 Agent 會被上下文、工具、網絡和測試步驟拖慢。
忽略失敗任務：重試最頻繁的流程，往往纔是成本黑洞。
只計算模型費用：瀏覽器、搜索、向量庫、存儲和人工審覈也可能收費。
混用不同模型的數據：量化版本、上下文長度和併發不同，結果無法橫向比較。

總結

消費級顯卡跑 Agent 的成本，不應只回答“每小時幾度電”。先用實測整機功耗算電費，再按自己的折舊假設加入硬件成本，最後用成功任務數和 token 量分攤。連續記錄一段真實工作負載後，你就能清楚判斷：是繼續本地運行、擴容顯存，還是把部分步驟交給雲端 API。

成本計算 on KnightLi的博客