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

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

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

先確定你要算哪一種成本

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

月度總成本公式

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

1
2
3
4
5
6

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

电费 = 实测整机平均功耗(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，並保持同一統計口徑。

如何採集自己的數據

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

先用 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。