本地部署大模型多少钱

老板或者客户丢来一句「模型放我们自己机器上」，你就要在几天内给出一笔预算。这时候最容易犯的错是只算显卡钱，把机柜、电、人力和后续运维全漏掉，报出去的数跟一年后真实花的钱差一大截。这篇把本地部署的投入拆成硬件、人力、运维三块，给出逐项核对的顺序和什么情况下这笔账根本不成立。

老板或者客户丢来一句「模型放我们自己机器上」，你通常只有几天时间给预算。最容易犯的错是只算显卡钱，把机柜、电、人力和后续运维全漏掉，报出去的数和一年后真实花的钱能差一大截。

这篇把本地部署的投入拆成硬件、人力、运维三块，给你一套能逐项填写的估算顺序，以及什么情况下这笔账根本不成立。全文不谈具体数字，凡是需要看行情的地方，都指到站内页面让你自己核对当时的数。

硬件投入：不止是显卡那笔钱

先按要跑的模型和并发反推显存与卡数，而不是先定预算再挑卡。显存、量化档位、并发三者互相牵制：量化压得狠省显存但可能掉质量，并发提上去又要更多余量。这一步别口头估，到 /models/deploy 按参数算一遍再回头谈钱。

• 整机清单要写全：卡、主板与 CPU 平台、内存、本地盘、电源、机箱散热，多机还要交换机与光模块。这些加起来往往能到卡价的相当一部分，具体占比按配置到 /compute/gpus 对照规格再估。
• 买还是租要分开看：三年账和按量租的账真的不一样，别拿租卡单价直接乘时间当自建成本，去看 /compute/tco 那套算法。
• 一次性支出和每月支出分两栏记：卡的采购是一次性，电费和机柜是每月，混在一张表里最后一定对不上。

不适用的情况：只有一两个人偶尔跑跑、要求随时换新卡、或者模型半年就换一代的团队，自建硬件大概率不划算。这类需求租卡或直接调官方 API 更省心，可先看 /compute/platforms 的几种形式再决定。判断标准很简单：你需要的算力是不是长期稳定、且能自己压住利用率。

人力投入：谁装、谁调、谁值班

部署不是装完就完事。至少要有人负责环境与驱动、推理框架选型、权重转换与量化、接口封装、权限与日志。把这些角色按人头折算工时，比按「一个工程师兼职搞搞」估要靠谱得多，因为兼职意味着这件事永远排在别的活后面。

能力门槛

能不能自己处理权重加载失败、并发压不上去、显存碎片这些事，决定了你是招人还是买服务

框架选型

拿不准时先看 /compute/providers 里各家对外提供的支持范围，再决定自己啃还是外包

两段人力

上线当月是高峰，之后转为值班和迭代，这两段的数字不能混在一张表里

不适用的情况：如果团队里已经有人长期做推理服务，这部分可以按增量算，也就是只算他额外花掉的时间；反之如果是第一次碰，宁可按外部支持报价预留，别按零成本估。第一次做的人最容易低估的，是排查线上问题的时间。

运维与持续投入：上线之后才开始花钱

电和机房这两项最容易被漏。按卡的功耗和机房报价单独算一行，到 /compute/power 核对当时的算法。本地部署也不等于高可用，兜底要么是备机，要么是临时切到云端接口，两条路的钱都要提前想好，别等出事再临时采购。

一份可填的估算顺序

1. 第一步 定需求模型规模、量化档位、日均请求量、可接受的延迟上限。这四个数没定下来，后面所有数字都是猜。
2. 第二步 算卡按需求反推显存与卡数，得到硬件基数。到 /models/deploy 和 /compute/sizing 把这一步数字化，不要口头估。
3. 第三步 加外围机柜、电、网络、备件、存储，逐项列出一次性与每月两栏。
4. 第四步 加人上线期工时加常态值班工时，按当地人力单价折算。别只算招人的钱，还要算管理时间。
5. 第五步 做敏感性检查把参数量、并发、是否要备机各上下浮动一档，看总预算会不会翻倍。翻倍的那一项，就是你最该先和老板谈清楚的前提。

如果做完第五步发现有两项同时翻倍，这笔账基本就超出了一开始的预期，应当回头砍需求而不是硬凑预算。先砍并发、再砍高可用、最后才考虑换小模型，顺序反过来会很难受。想知道同规模团队一般选租还是买，可以看 /rankings 里按场景归纳的对照，再结合自己的利用率判断。