很多人听别人说本地跑模型不要钱，插上机器就开始 ollama，月底交电费才发现账单变了。问题不是本地不省钱，而是你只把钱算在了显卡上，漏掉了持续通电这一项。这篇给一套估算顺序：先量功率，再折电价，然后跟你平时云调用的用量对一遍，最后决定哪些活留在本地、哪些丢回云端。全程只需要电表、插座功率计和一份用量记录。
很多人听说本地跑模型不要钱，装上 ollama 就开始跑，月底看电费才发现账单变了。问题不在本地不省钱，而在于只算了显卡，漏掉了持续通电这一项。本地跑模型的成本是「硬件摊销 + 电费 + 你的时间」，电费只是其中一项，但它是最容易被忽略、也最容易测出来的那一项。
这篇给一套可落地的估算顺序：先用插座功率计量整机功率，再按自己账单上的真实电价折算，然后拿本地电费和平时云调用的花费放在同一口径上对一遍，最后决定哪些活留本地、哪些丢回云端。全程只需要功率计、电费账单和一份简单的用量记录，不依赖任何厂商提供的估算。
先别算钱，先把功率量出来
别拿显卡标称功耗当整机功耗。CPU、主板、内存、风扇，加上电源自身的转换损耗，实际插在插座上的功率往往比显卡铭牌高出一截。用带计量的插座功率计读数，才是你真正要付钱的那部分。没有功率计的话，先用系统内的功耗读数做参考，但要清楚它测不到电源转换损耗。
- 空闲待机：开机挂着不跑任务时的读数，这部分是纯隐形成本，本地长期开机的最大变量
- 加载模型：把模型拉进显存/内存那一刻的瞬时峰值，通常只持续几秒到几十秒
- 持续推理：连续发请求时的稳定读数，这个数才是折算每千 token 成本的基础
- 断电重测：换一个时间段、换一个任务再测一遍，确认读数稳定，避免单次误差当成结论
通电时长要单独记
功率测出来之后，下一步是时长。不要直接按 24 小时估，先老老实实记一周：每天开机几小时、其中真正跑任务几小时。这两个数字差别很大，决定了你是「用得多」还是「只是开着」。记满一周再乘以功率，比一次性拍脑袋准得多。
把度数换成钱：电费折算的三步
折算本身不复杂，但有两个坑。第一，用你账单上的真实单价，不要用网上看来的均价，家庭阶梯电价和商用峰谷电价结果差很多。第二，阶梯电价用户跨档之后单价会跳，跑得越久边际成本越高，长时间批量任务必须把跨档部分单独算，否则会低估。
- 算度数功率（千瓦）× 通电时长（小时）= 度数，把待机、推理两段分开算，别混在一起
- 折电价度数 × 你账单上的实际单价，阶梯电价要判断本次用量是否跨档，跨档部分用新单价重算
- 换成可比口径把结果除以此期间完成的输出量，得到「每千 token 折算成本」，才方便和云价格横向比；具体换算到站内工具做，别手算
| 用电状态 | 怎么测 | 折算时怎么处理 |
|---|---|---|
| 空闲待机 | 功率计直接读 | 全额计入成本，不能省略 |
| 加载模型 | 观察峰值持续时长 | 折算成极短时段，影响很小 |
| 持续推理 | 连续发请求稳定后读数 | 除以同期输出量，得到单位成本 |
| 跨档增量 | 对比本次与上次账单档位 | 超出部分用高单价重算 |
这里不写任何具体电价和折算结果，因为各地电价、时段政策、家庭档位都不同。你需要的数字在你自己账单上，或者在站内成本相关页面按你当地参数代入核对，写死在文章里的数字对你没有意义。
本地电费和云调用摆在一起怎么比
对比要放在同一口径上：同一个任务、同样的输出量、同样的时间窗。否则本地要么显得便宜到不真实，要么贵得离谱。最稳的做法是挑一周，本地跑一批任务并记下电费和输出量，同时查一下这批任务如果走云调用大概什么价位，两边都取同一周的数据再比。
- 本地只省下了调用费，没省下硬件折旧、占用的时间和维护精力，小规模使用里这几项可能比电费更贵
- 云调用的价格会随厂商和档位变动，比对时到站内价格追踪页看当时的数字，别用记忆里的旧价
- 什么情况下本地不划算：调用量很低、任务很零散、模型需要频繁更换、或者你根本不需要数据不出本机
- 什么情况下本地明显合适：每天稳定跑批、模型固定、数据敏感、机器本来就是常开的
本地和云端不是二选一，是分工问题：让贵的活去贵的地方，让闲着的机器去跑不赶时间的活。
本地也要留用量记录，否则没法对账
ollama 不会给你账单，你得自己记。最省事的做法是按周记三列：通电时长、估算度数、完成的输出量。就这三列，足够月底和云账单放在一起看，判断该不该把某些任务迁走。字段怎么设计、日志放哪，可以参考站内用量日志那篇的思路，别自己发明一套记两天就放弃的格式。
| 记录项 | 记录频率 | 用途 |
|---|---|---|
| 通电时长 | 每天 | 区分待机与推理，避免按 24 小时瞎估 |
| 估算度数 | 每周 | 乘以当地电价得到本周折算电费 |
| 完成输出量 | 每周 | 换算出单位成本，和云价格同口径对比 |
| 异常备注 | 按需 | 换模型、跑长任务时标注，避免污染对比 |
当某一周的电费折算已经接近同期云调用的花费时，就是一个明确的重新评估信号。具体临界点是多少，取决于你当地电价和云侧当时的报价，到站内成本计算器把参数代进去看，别拿别人说的比例当标准。
一张留在本地还是切云端的判断清单
不用追求一个通吃的答案。绝大多数人最后都是混合跑：一部分任务固定留本地，一部分随时切云端。下面这张清单按任务特征来分，对着你的实际任务勾一遍就行。
- 优先留本地：高频重复、数据敏感、模型固定、机器反正要开着、不赶时间
- 优先切云：低频突发、需要更大参数模型、要快速换模型试效果、偶尔才用一次
- 混合做法最省心：批量离线任务放本地夜间跑，交互式、赶时间的活走云端
- 拿不准的任务：先用本地跑一周并记电费，再和云侧同期花费对一遍，用数据决定
- 每次换模型或换任务类型，重新对一次，别沿用上个月的结论
常见问题
本地跑模型真的比云 API 便宜吗？
看用量密度。持续高负载、机器本来就常开的情况下，本地只多花电费，通常比按量调用划算；但如果一天只跑几次、任务零散，电费之外还要摊硬件折旧和占用的时间，反而不如按量付费。先把你的通电时长和任务量记一周，再拿站内成本计算器代入当地电价比一遍。
怎么知道我的机器跑 ollama 一小时耗多少电？
最准的是买一个插座功率计，串在主机电源前面读整机功率，分别记空闲、加载、持续推理三种状态。没有功率计就用显卡功耗加一个余量粗估，但要注意电源转换损耗和整机其他部件，粗估只能用来判断量级，别拿来算精细预算。
本地跑和云调用应该按什么口径放在一起比？
固定同一个任务、同样的输出规模、同样的统计周期。本地这边把电费折算成每千 token，云端那边用你真实的用量记录反推花费，两边都换算到统一单位再比。注意本地还要把机器折旧和占用时间考虑进去，只比电费会得出偏乐观的结论。具体单价到站内官方 API 价格页面核对当时的数字。
