大模型部署到本地要多少钱

想在自己机器或公司服务器上跑大模型，先卡住的往往不是装不装得上，而是「这事到底要花多少钱」。有人只算了显卡，装完才发现电源、机箱、内存、电费、折腾时间全没进账。这篇给一套按规模递进的估算顺序，让你在买之前先把总账框出来，再决定要不要动手。

想在自己机器或公司服务器上跑大模型，先卡住的往往不是装不装得上，而是这件事到底要花多少钱。很多人一上来只盯显卡，等装完才发现电源、机箱、内存、电费、折腾进去的时间全没进账，实际支出比最初的预算高出一截。

下面给一套按规模递进的估算顺序：先确认自己属于哪一档，再从显存反推硬件，最后把运行和人工这些容易漏掉的钱补上。整篇只讲怎么算，不报死数字，凡是会随行情变的金额，都到站内对应页面核对当时的数值再落到你自己的表里。

先分清你是哪一档：三种典型规模

估算之前先给自己归个档。跨档比价没有意义，因为体验档关心的是「能不能跑起来」，生产档关心的是「能不能稳定在线、扛住并发」，两边的钱花在完全不同的地方。档位定错了，后面所有数字都是白算。

体验档

只想跑个能对话的模型，用已有电脑加一块中端卡；成本重心在显卡和内存，不一定要换整机。

团队档

几个人共用、要接知识库或内网服务；显卡之外还要算主机、存储、电源与机柜位置。

生产档

要并发、要稳定在线，得按吞吐和冗余算卡数，成本里会出现集群、网络与运维人工。

分档没有绝对标准，靠几个问题就能判断：是只有你自己用，还是几个人同时连；是偶尔问几句，还是要求全天在线不能停；数据能不能出内网。三个问题里有两个偏「重」，就往上一档算。具体分档金额到 /models/deploy 和 /compute/sizing 按你的模型算一遍，比拍脑袋靠谱。

第一笔钱从显存反推：模型规模 × 量化档位

显存是硬门槛。先把模型参数量和量化方式定下来，得到一个显存下限，再去看显卡型号。低于这个下限根本跑不起来，高于下限只是更快、能开更长上下文，不是「更值」。所以顺序永远是先定模型和量化，再选卡，别反过来先买卡再挑模型。

• 量化越狠显存越省，但输出质量和长上下文表现会打折，怎么取舍参考 /ai-dict/category/tech 里的概念页
• 同一模型的不同量化档位对应不同档位的显卡，可以先按最省显存的档位估下限，再往上加余量
• 多模态、长上下文场景的显存占用明显高于纯文本，估算要往上留一截
• 操作系统和推理框架自己也要占一部分显存，别把卡容量刚好卡在模型需求线上
• 用 /models/deploy 的部署测算，按你的模型与量化档位过一遍，拿到当下的参考区间

什么情况下这条不适用？如果你只是想验证效果、跑通流程，那没必要按生产下限配卡，用现有设备加上按量调用先跑一段时间，反而能验证清楚再决定买不买。

显卡之外的钱：主机、电源、散热、存储

显卡只是清单里的一项。大功率显卡往往意味着要换电源和机箱，老机器升级经常就卡在这里：机箱塞不下、电源接口不够、主板通道不匹配，一项不满足就得整套换。这部分开支在预算表里要单列，不能默认「已经有电脑了就不用花钱」。

二手卡便宜，但功耗、保修和稳定性都要单独算账，别只看单价。判断标准很简单：如果你没法接受它突然坏掉之后再花时间重买重装，就别为省下的那点钱冒这个风险。

跑起来之后：电费、散热与常驻开销

本地部署不是一次性支出。机器开着就耗电，而且大模型推理通常是长时间满载或者间歇性满载，不能按待机功率估。算法很朴素：满载功率乘以每天实际运行小时数，再乘以你自己的电价，就是月电费的大致量级。具体功率和电价输入，到 /compute/power 按你的参数算，别用别人的数字套自己。

• 按每天实际运行时长估，别默认 24 小时，除非你真的需要一直在线
• 把制冷和通风算进去：机器散的热，最后还是要靠空调或者风扇排出去
• 备份、监控、断电保护这些小件加起来也是一笔钱，跑在内网的模型一旦挂了，业务会直接停
• 硬件会折旧，按你计划用几年分摊到每年，这笔钱在账上比电费更容易被忘掉
• 电费和折旧这两项最容易被漏掉，却往往是长期成本的大头

什么时候这笔账不成立？如果你本来就是 7×24 在线的业务，电费和折旧会被摊薄，账更好看；但如果只是白天偶尔用，硬撑着不关机就是纯浪费。更完整的自建与租用对比，看 self-host 那篇，这里只算你自己的账。

软件与人工：最容易被低估的一块

推理框架、部署工具本身多数免费，但选型、调试、版本适配都要吃工时。一次环境踩坑可能耗掉好几天，而这几天本来是有产出的。这部分不进现金支出，进的是机会成本，估算时不能当它不存在。

1. 列动作把要做的事拆开：装驱动、选推理框架、导模型、调量化、接接口、做监控，每一项都写出来。
2. 估小时每项先给一个偏保守的小时数，宁可高估，遇到没做过的环节直接翻倍。
3. 折算成本按自己或同事的时薪乘以小时数，得到一个模糊但能对账的人工量级。
4. 加上二开接知识库、做权限、接内部系统属于二次开发，工作量常超过硬件本身，要单独列一项。
5. 定期回看实际花了多少小时记下来，下次估算就有你自己的基准，不用再猜。

如果只是做验证，先用现有设备或按量调用跑通再决定买不买，比先买后试省得多。判断标准是：你连模型效果都还没确认，就不该先为它配一台机器。

什么情况下这笔账不划算

自建的动机通常是数据不出内网，而不是省钱。如果你的用量小、任务零散，买卡的钱够按量调用很久，硬要自建就是花钱买了个安静。这话不是劝你别买，是提醒你先想清楚买它的理由是什么。

• 用量小、任务零散：按量调用更合适，除非有合规硬要求
• 需要更大模型、更高并发：消费级机器很快到天花板，硬撑不如租卡
• 模型换代快：硬件还在保修期，手上的模型可能已经不流行，折旧速度要按换代节奏算
• 没人维护：坏了谁修、升级谁做，如果没有明确的人，先别买
• 判断标准是「稳定负载 + 数据合规要求」，两个都不占就别急着下手

想算租卡和自建的临界点，到 /compute/tco 对齐口径。注意口径要一致：自建这边要把电费和人工摊进去，租用那边要按实际使用时长算，否则两边比出来的结论一定是歪的。

一套可照着走的估算流程

把前面几节串起来，就是一个可以重复执行的流程。好处是模型一换，只要重算前两步，后面的清单照旧能复用，不用每次都从零开始纠结。

1. 定模型与量化档位先明确要跑什么模型、用什么量化，这是后面所有估算的输入。
2. 算显存下限按 /models/deploy 的测算过一遍，拿到当下参考区间，再往上留余量。
3. 定档位体验、团队、生产三选一，档位决定后面清单的粗细。
4. 列硬件清单显卡、内存、硬盘、电源、机箱、散热逐项填当前市价，缺项的补上。
5. 加运行项电费、折旧、维护时间按前面的方法算进去，别只算一次性支出。
6. 对总预算和目标总预算比一遍，超了就降模型规模或考虑租卡，而不是硬砍配件。

把每一项写成表格比记在脑子里靠谱。改动模型时只需要重算前两步，硬件清单可以留着下次复用，这也是为什么建议一开始就把结构搭好。

下单前的自查清单

最后过一遍下面这几条。任何一条答不上来，就说明账还没算完，先别付款。清单不保证你花得少，但能保证你花得明白。

• 模型跑得起来的显存下限留出余量了吗
• 电源、机箱、内存、散热是否同步升级，还是只换了卡
• 月电费和硬件折旧算进去了吗
• 有没有考虑模型换代后的迁移与重买成本
• 准备自己维护还是有人能接手，出问题谁来修
• 这笔支出对应的数据合规或稳定负载要求，真的成立吗

如果这几条你都答得上来，且理由站得住，那就可以动手了。反之，先按量调用验证一段时间，把真实用量摸清楚，再回来重算一遍，通常能省掉不少冤枉钱。