自建大模型需要多少钱？硬件、人力与运维总投入估算

老板说「数据不能出内网，我们自己搭一个」，你拿着这句话去问预算，没人能给你一个数。自建的成本不在那张显卡报价单上，真正吃钱的是电力、运维人力、闲置率和上线后的持续投入。这篇给一套从上到下的估算顺序和对照表，让你能自己填数，而不是被供应商报价牵着走。

老板一句「数据不能出内网，我们自己搭一个」，预算就会砸到你头上。麻烦的是，你去问供应商，他报的是显卡和整机；你去问同事，他说要买卡、要找人、电费也不便宜。每个人说的都对，但拼起来不是一张能签字的预算表。

自建大模型的钱分三块：硬件、人力、运维。真正把预算撑爆的往往不是那张显卡报价单，而是电力、值班的人、卡买回来闲着的那部分时间，以及上线之后没完没了的升级和告警。下面给一套从上到下的估算顺序，你照着填，能得出一个自己站得住的区间，而不是被报价牵着走。

先说清楚：为什么没有一个标准报价

同一个模型，放在三个人的小团队和三十人的团队里跑，总投入能差出好几倍。硬件可能一样，但人力、值班方式、监控体系、故障响应速度完全不同，这些都会反映到预算上。所以任何开口就给你一个整数的说法，先打个问号。

• 决定价格的第一类变量是模型规模和量化档位：跑多大的模型、压到多低的精度，直接决定显存需求和卡的数量
• 第二类是你要求的并发：同时几个人用、高峰期多少请求，决定要不要多留几张卡做冗余
• 第三类是要不要 7x24：只在工作时间用，和承诺全天候可用，人力和冗余完全是两个量级
• 还有一类隐形变量是闲置率：按峰值买卡、按均值使用，中间那段就是白花的钱

先定边界：你到底要自建到什么程度

自建不是一个开关，是一段台阶。先写清楚这次到底走到哪一档，再谈钱，否则估算会无限膨胀。最常见的错误是把「以后可能要做训练」也算进第一期预算，结果为了一个还没影的需求多买一堆卡。

纯本地推理

只把已有模型跑在内网，对外提供问答或接口，不动模型本身

推理加微调

在推理基础上，用自家数据做小规模微调，需要额外的训练卡和数据流程

推理加自建 RAG

把内部文档接进来做检索增强，硬件增加有限，但数据清洗和向量库维护的人力明显上升

加上训练

从头训练或大规模继续预训练，这是另一个量级的投入，通常不该和前三档放在一起谈

同时把数据分两堆：哪些是「绝对不能出内网」的，哪些是「走外部接口也没关系」的。很多团队一紧张就全量自建，其实真正敏感的只有一部分。分完你会发现，需要本地承载的请求量可能远比想象中小。

硬件这笔账：卡、整机、网络和机房

硬件的算法顺序是反的：不是先看卡多少钱，而是先看模型需要多少显存。按参数量和量化档位反推显存，再根据你要的并发决定几张卡才够，具体口径可以到 几张卡够用：按模型算一遍（/compute/sizing） 对照着算。这里不要凭感觉，把峰值并发和单卡吞吐写下来，算出来的数字才经得起追问。

算完卡的数量，别急着乘单价。整机、交换机、存储、机柜、电力改造，这些加起来经常和卡本身一个量级。卡价往往只占硬件总投入的一半左右，剩下那一半在报价单上通常不显眼，但在付款时一样跑不掉。

买卡还是租卡要分开算，不要混在一起谈。自购的优势是长期单价低，前提是利用率够高；一旦卡大部分时间闲着，自购就比租卡贵。三年账怎么摊、闲置怎么折进去，可以到 买卡还是租卡：三年账怎么算（/compute/tco） 按同一套算法套一遍。

人力这笔账：最容易被低估的一块

硬件是一次性支出，人力是每个月都要付的。很多自建项目前半年顺利，后面卡在人身上：没人及时升级依赖、没人看监控、出了故障要等外部的人有空。这些不是意外，是预算里本来就该有的项。

• 推理工程：负责模型部署、性能调优、量化和版本切换
• 平台运维：负责机器、网络、存储、监控和故障响应
• 数据与语料处理：负责资料清洗、切分、向量化，工作量常被低估
• 业务侧对接：把业务问题翻译成模型能处理的任务，并定义验收标准
• 在小团队里这些角色常常一人兼多职，但兼的前提是服务等级要求不高

估人力时要拆成两段：上线前的一次性投入，和上线后每月的持续投入。后者才是长期负担。一个人能不能兼，取决于你的服务等级：只要对外承诺了 7x24 可用，就必须有人值班或至少有人能随时响应，这条不能靠「大家辛苦一下」糊过去。

上线之后的运维与持续支出

上线不是终点，是每月账单的开始。电费、带宽、机位租金属于固定开销，卡越多、机房条件越差，这部分越明显。电力这笔账怎么估，可以参考 租卡之外别忘了电费这笔账（/compute/power） 里的口径，别拿家用电脑的电费去类比机柜。

1. 列出每月固定项电费、带宽、机位或机房租金、软件授权、监控工具，逐项写清楚谁在付、付给谁
2. 估算每月工时模型更新、依赖升级、告警处理、故障排查，按每月多少工时乘人力成本，不要写「少量」
3. 补上安全与合规日志留存、访问控制、数据脱敏、审计接口，这些通常在上线后被要求补，越晚补越贵
4. 留出更新预算模型和框架都在动，至少预留一笔用于版本切换和兼容性验证的费用

闲置率：自建成本里最大的隐形变量

自建的典型模式是按峰值买卡，按均值使用，高峰之外的时间卡就在那里耗电、占机位、折旧。这部分钱不掉在发票上，但确实花掉了。很多团队的估算失败，不是因为算错了单价，而是根本没算闲置。

所以在上预算之前，先量两个数：真实平均利用率和峰值利用率。平均利用率决定你实际需要多少算力，峰值决定你要留多少冗余。两个数差得越远，自建越不划算。低利用率场景下，租卡或按量调用往往更省，分界线在哪、有哪些隐藏成本，可以到 租卡还是按量调 API：两条路的分界线与三个隐藏成本（/rent-gpu-vs-api） 里对一遍。

一份能直接填的估算表：从需求到总数

把前面几节的内容收进一张表，横向是支出类别，纵向按三年摊。一次性投入除以期数，加到每月支出上，得到一个月度化的总成本，这样才好和租用、按量付费去做比较。每一项都要写数据来源，是报价单、实测还是经验值，后面复核时才知道该查哪里。

填完之后做一次对照：把月度化总成本除以你实际的月请求量，得到一个单请求成本，再和外部接口的单价对比。外部接口的当期数字可以到 价格追踪（/price-watch） 页面看，模型资料可以到 模型资料库（/models） 核对。对比时记得把闲置和运维都算进去，只比卡价会得出错误结论。

什么情况下自建不划算

自建不是技术先进与否的问题，是成本结构匹配不匹配的问题。下面几种情况，建议先不要碰自建，或者只做很小的一期验证。

• 数据敏感度不高：既然可以走外部接口，自建带来的合规收益有限，固定成本却实打实
• 用量波动大：峰值很高但平时很低，按峰值买卡等于长期养闲置
• 团队没有运维底子：机器、网络、监控、故障响应都需要人，临时学来不及
• 需求还没稳定：业务形态还在变，此时上自建等于用固定成本赌一个变化中的方向

更稳的做法是混合：真正敏感的数据走内网小模型，一般任务走外部接口。这样既守住合规底线，又不用为全部流量买单。具体怎么分、接口怎么选，可以到 中转站导航（/sites） 看各家能力，再到 测速工具（/tools/speed-test） 实测延迟和稳定性，用数据决定分流比例。

自建的成本大头不在显卡报价单上，而在电费、值班的人，以及卡闲着的那段时间里。