本地模型并非“一次买显卡，以后免费”，云端 API 也并非“长期一定更贵”。本地成本以前期硬件和维护时间为主，云端成本随 Token 用量增长；两者提供的模型能力、延迟、隐私边界和可用性并不相同。公平比较必须先说明工作负载，再把一次性成本、持续成本和隐藏成本放进同一张账本。
先建立两套成本模型
本地部署可用下面的月度核算框架：
本地月成本 ≈（硬件购置价 − 预计残值）÷ 使用月数 + 电费 + 维护时间成本 + 备份/存储成本云端 API 的框架则是：
云端月成本 ≈ Input Token 费 + Cached Input 费 + Output Token 费 + 工具/存储附加费 + 重试浪费两个公式的最大区别是成本曲线。本地硬件买下后，短期多生成一些 Token 的边际电费通常较低，但机器有吞吐上限；云端低用量时几乎没有固定硬件成本，流量增长时账单近似跟着用量增长，却更容易临时扩容。实际选择取决于用量是否稳定，以及本地可运行的模型是否已经达到任务质量底线。
硬件与显存门槛
本地推理先受 VRAM 或统一内存限制。仅估算权重时，可以从参数量和量化位数开始：
权重占用（Bytes）≈ 参数量 × 每参数 bit ÷ 8例如，同一参数量下，FP16 权重理论占用约为 INT8 的两倍、INT4 的四倍。但“权重能装下”不等于“模型能稳定运行”。推理还需要 KV Cache、运行时缓冲、量化元数据、图形界面或系统占用；上下文越长、并发越高，额外内存通常越大。部分内存还能卸载到系统 RAM，但速度可能明显下降。
不要按理论权重刚好卡满预算。先把参数量、精度、上下文和并发输入LLM 显存计算器，再给运行时留余量。Mac 的统一内存与独立 GPU 的 VRAM 架构不同，也不能只拿显存数字机械对照。
| 本地硬件项 | 为什么要计入 | 常见遗漏 |
|---|---|---|
| GPU / 整机购置 | 决定可运行模型规模与吞吐 | 只算显卡，不算电源、主板、内存和散热 |
| 存储 | 量化版本、Embedding、数据集都会占空间 | 多个模型版本重复占用 SSD |
| 折旧与残值 | 把一次性支出分摊到使用周期 | 把购置价当作永久资产或把残值当作确定收益 |
| 维护时间 | 驱动、推理框架、模型格式和服务都要更新 | 把自己的排障时间当作零成本 |
电费怎样计算
电费应使用整机插座功耗的实测值，而不是 GPU 标称功耗。简单公式为：
月电费 = 平均整机功率（kW）× 每天运行小时 × 每月天数 × 电价（元/kWh）教学假设：硬件购置 ¥6,000.00，按 36 个月直线分摊且暂不计残值；推理时整机平均 220W，每天使用 6 小时，每月 30 天，电价 ¥0.70/kWh。由此月耗电约 39.6 kWh，月电费约 ¥27.72，硬件月分摊约 ¥166.67，两项合计约 ¥194.39。
这些数字只是演示公式，不是硬件报价或电价结论。待机功耗、满载比例、地区电价、硬件残值、散热和是否本来就拥有设备，都会改变结果。已有电脑的“新增成本”可能主要是电费，但仍有性能占用和机会成本。
云 API 成本案例
云端侧以 DeepSeek V4 Pro 当前默认文本费率举例：Input $0.435、Cached Input $0.0036、Output $0.87，均为每 1M Tokens，价格核验于 2026-08-13。假设每月使用 100,000,000 Input Tokens 和 20,000,000 Output Tokens、无缓存，模型 Token 成本约为 $60.90，按本站参考汇率折算约 ¥438.48。
在完全沿用上述教学假设时，若只比较硬件购置、电费和这份 API 账单，静态回收期约为 14.6 个月。 这不是购买建议，也不是本地与云端的性能等价比较：本地可运行模型未必具备 DeepSeek V4 Pro 的能力、吞吐或上下文特性，工作负载变化也会立即改变回收期。
更合理的做法是把自己的真实月 Token 输入API 成本计算器，分别测试无缓存、实际缓存命中和高峰流量。还要加上多模态、长上下文阶梯、外部搜索、Embedding、失败重试和税费；默认文本价格不能覆盖所有 API 功能。
隐私、易用性与运维
| 维度 | 本地模型 | 云端 API | 核对问题 |
|---|---|---|---|
| 数据路径 | 可让原始数据不离开设备或内网 | 请求会发送给服务商处理 | 是否含个人、学校、客户或保密数据？ |
| 部署速度 | 需下载权重、配置运行时和接口 | 取得 Key 后通常能较快接入 | 你愿意花多少时间维护环境？ |
| 离线可用 | 模型与依赖准备好后可离线运行 | 依赖网络与 Provider 可用性 | 断网时是否必须继续工作？ |
| 扩容 | 受单机显存、功耗和并发限制 | 通常更容易应对短时峰值，但有限流 | 流量稳定还是突然爆发？ |
| 更新维护 | 自己管理模型、驱动、安全补丁和服务 | 服务商维护基础设施，模型规则可能变化 | 能否承担回归测试与替换模型？ |
“本地”会减少内容传给外部模型服务商的需要，但不自动等于安全。桌面前端可能记录历史，日志可能包含提示词，浏览器插件、同步盘、遥测和备份仍可能把数据带出设备。应检查完整数据流、访问权限、磁盘加密和删除策略。
云 API 也不能用一句“不隐私”概括。不同服务、账号等级、区域和协议可能有不同的数据保留、训练使用与零保留选项。处理敏感数据前，应阅读当前官方条款并取得所需授权；不要把消费级聊天产品的规则直接套到 API，也不要假设付费就自动满足所有合规要求。
性能不能只看参数量
性能至少包含答案质量、首 Token 延迟、生成速度、并发、上下文长度、工具调用和稳定性。本地小模型在固定分类、私有文档检索、离线写作等窄任务上可能足够，并能提供可控的局域网延迟；云端通常更容易获得大型前沿模型、高并发和托管工具，但受网络波动、限流和服务变更影响。
量化会降低内存占用，但不同量化方法、模型和任务的质量损失不一致。不要把“INT4 可运行”推导成“INT4 与高精度输出完全一样”。最可靠的验证仍是：在目标硬件上，用自己的样本测一次通过率、每秒 Tokens、首 Token 延迟、峰值内存和长时间稳定性。
模型跑得起来只是门槛；能在你的质量、延迟和成本约束内持续跑，才是可用。
按场景做选择
更值得优先测试本地的情况
- 已有合适硬件，新增资本支出很低，而且任务用量长期稳定。
- 必须离线，或数据策略明确要求内容不发送给第三方模型服务。
- 任务相对固定，可用自己的数据验证本地模型已达到质量底线。
- 能够维护驱动、模型服务、访问控制、日志和备份。
更值得优先测试云 API 的情况
- 项目刚起步、用量低或波动大，不想先投入硬件。
- 任务需要较强推理、长上下文、多模态或成熟工具调用。
- 需要快速上线，并愿意用预算上限、脱敏和供应商条款管理风险。
- 短时需要较高并发，本地单机扩容不经济。
需要先做实验、不能凭直觉决定的情况
当月用量接近成本交叉点，或隐私要求与模型能力互相冲突时，做一周小规模对照：同一批任务分别跑本地候选和云模型，记录质量、Token、耗时、功耗、故障与维护时间。不要只用理论显存和官方单价下结论。
混合方案通常更灵活
选择不必是二选一。常见混合方式是：敏感资料先在本地做脱敏或检索，必要的最小上下文再交给云模型；简单高频任务本地处理，困难样本升级云端；日常开发用 API 快速迭代，工作负载稳定后再评估本地化。混合架构增加了路由和运维复杂度，因此也要设置清晰的失败策略和审计日志。
最终顺序可以很朴素：先用显存计算器判断本地候选能否合理运行，再用API 成本计算器代入真实用量，最后用同一批样本比较质量与延迟。成本结论必须建立在“任务效果可接受”的前提上；不等价的模型，不能只用月费做一列数字就宣布胜负。