打算自建推理环境的团队，最容易犯的错是只算显卡钱：卡买回来才发现电源不够、机箱塞不下、机房没位置、一年电费比卡还贵，还有人得专门盯着。这篇不报具体数字，只给一套成本科目表、测算顺序和「什么情况下这笔钱不该花」的判断标准，你按自己场景把数填进去就能出预算。
打算自建推理环境的团队，最容易犯的错是只算显卡钱：卡买回来才发现电源不够、机箱塞不下、机房没位置、一年电费比卡还贵，还得有人专门盯着。这篇不报具体数字，只给一套成本科目表、测算顺序和「什么情况下这笔钱不该花」的判断标准，你按自己场景把数填进去就能出预算。
下面所有涉及价格的地方，都只讲怎么算、去哪核对，具体数字请到站内价格与部署测算页面看当时的行情。先把科目列全，再谈金额，顺序反了只会反复返工。
先把成本科目列全，再谈钱
本地部署的总成本拆成四块：算力硬件、配套硬件（电源、机箱、散热、存储、网络）、运行开销（电费、机位、带宽）、人力与时间（部署调试、监控、升级）。只列第一块是常见错误，后三块往往半年内追上来，团队越小越明显。
| 成本块 | 典型性质 | 容易漏的点 |
|---|---|---|
| 算力硬件 | 一次性 | 显卡之外的整机配置 |
| 配套硬件 | 一次性+少量更换 | 电源功率、散热方案、存储扩容 |
| 运行开销 | 按月/按年 | 整机功耗、机位、带宽 |
| 人力与时间 | 按年 | 部署调试、监控、版本升级 |
算的时候把「一次性」和「按月」分开记，别把一次性支出直接摊进月成本，否则会低估前几个月的现金流压力，也会高估长期月均开销。建议用一张表分三栏：一次性、按月、按年。
第一步不是选卡，是算你需要多少显存
显存需求由四项决定：模型参数量、量化档位、上下文长度、并发数。缺任何一项都会估偏，尤其是并发——单人试跑和团队同时用，需要留的余量差很多。先把这四项写下来，再去挑卡。
- 模型参数量：你打算跑的几个模型，最大那个决定下限
- 量化档位：同一模型不同量化，显存占用差别明显，先定可接受的精度
- 上下文长度：长文档、长对话场景要额外留缓存空间
- 并发数：按峰值并发估，别按平均并发估
- 余量：给模型并行、缓存和系统占用留出空间，别卡着上限选
单机能跑和「跑得舒服」是两回事。刚好塞进去的配置，在并发上来或上下文变长时就会爆显存，最后还是要加卡。显存算不出来，先去站内部署测算页按你的模型跑一遍，再回头挑卡，比凭感觉选卡靠谱。
买卡之前先做一道选择题：这钱该不该花
判断标准看四条：日均推理时长、负载是否稳定、数据是否必须不出内网、要不要长期保留自有环境。四条里满足得越多，自建越合理；只满足一两条，先别急着采购。
| 情形 | 更适合自建 | 更适合租卡/调 API |
|---|---|---|
| 日均推理时长 | 长时间持续跑 | 每天只跑几小时 |
| 负载稳定性 | 峰值可预估、波动小 | 忽高忽低、说不准 |
| 数据要求 | 必须不出内网 | 可以用托管或专有云 |
| 运维人手 | 有人能长期盯 | 没人专职负责 |
把买卡的三年账和租卡账并排放，别只比首年。首年自建看起来划算，是因为还没遇到电费、更换和人力；三年拉平后结论经常反过来。不适用的情况也要写清：项目还在验证期、模型换代快、团队没有运维人手，这几种情况下租卡或直接调 API 大概率更省。
最容易被漏算的配套硬件
高功耗卡不是插上就能跑。电源功率、供电线路、UPS、机箱风道、散热方案都要单独算，而且这些往往在采购清单之外。放办公室和放机房的方案成本差很多，噪音和散热尤其明显。
- 电源与配电：按整机峰值功耗选电源，线路和插座也要核一遍
- 散热与噪音：办公室方案要考虑噪音，机房方案要考虑风道和温度
- 存储：模型权重、多个量化版本、数据集、日志，按保留策略估容量
- 网络：内网访问、并发请求、跨机房调用的带宽
- 备件：电源、风扇、硬盘这类易损件留一点余量
这一块的排查顺序建议：先算整机功耗，再看现有供电能不能扛，然后定散热方案，最后估存储和网络。顺序反了会在买完卡之后才发现要改电，返工成本很高。
跑起来之后每个月还在花什么
电费按整机功耗算，不是单卡功耗，要把散热和电源损耗算进去。机位和托管是另一笔：自有办公室和托管机房，科目完全不同，前者算场地和空调，后者算机位费和带宽。
- 电费
- 整机功耗乘以运行时长，再乘当地电价，按满载和日常两档分别估
- 机位
- 自有场地算场地与空调，托管算机位费和带宽费
- 折旧
- 按使用强度估更换周期，别假设卡是永久的
- 对比基线
- 同等工作量按量调用的成本，这才是判断自建值不值的分界线
把月度运行成本和同等工作量的按量调用成本放在一起比。如果自建的月运行成本已经接近按量调用，那自建的意义就只剩数据不出内网这一条，决策会清楚很多。实际电价和托管报价差异大，到站内价格追踪页面核对当时的数字。
人力这块别装看不见
部署调试、版本升级、故障排查、监控告警，都需要有人认领。小团队常见做法是指定一个人兼任，代价是他的其它工作被挤占，而且一旦他休假，环境就没人管。
- 列出要做的事把部署、升级、监控、排障四类事写出来，标注频率是每天、每周还是每季度
- 指定认领人每类事必须有名字，没有名字的事等于不会做
- 折算工时按频率乘单次耗时，算出每月占用多少人力工时
- 计入总账把这部分工时折算进成本，再看「自建更便宜」的结论是否还成立
一份可以直接套的预算测算顺序
顺序很重要：定场景与并发 → 算显存 → 选卡与整机 → 配配套硬件 → 估电费与机位 → 加人力 → 和租卡、调 API 对比。每一步的输出是下一步的输入，跳步会导致反复改预算。
| 步骤 | 输出 | 验收标准 |
|---|---|---|
| 定场景与并发 | 峰值并发、上下文长度 | 业务方确认过 |
| 算显存 | 显存下限和舒适区间 | 含余量 |
| 选卡与整机 | 整机配置单 | 功耗、尺寸、接口都核过 |
| 配套硬件 | 电、散热、存储、网络清单 | 供电能力已确认 |
| 运行与人力 | 月度和年度支出 | 已与按量调用对比 |
每一项标上「必须 / 可延后 / 可砍」：必须的先算完，可延后的排在第二阶段，可砍的直接从预算里去掉。结论写成区间而不是单点，给模型换代和负载增长留余地。
什么情况下这笔钱不该花
下面几种情形，先别采购：只做验证与演示、需求还在变；日均调用量很低，按量付费更划算；团队没有运维能力，自建后停机损失可能超过省下的钱；合规要求可以用专有云或私有化托管满足。
- 项目还在验证期，模型和需求都可能换
- 日均调用量低，按量付费明显更省
- 团队没人能长期负责运维
- 停机损失大于自建省下的差额
- 合规可以靠专有云或私有化托管满足
自建的门槛不是买得起卡，而是买完之后有人能一直把它跑稳。下一步按模型和并发去跑一遍部署测算，再看各家价格与中转站可信度，把预算落到区间上。→
常见问题
本地部署一定要买新卡吗？
不一定。二手卡、租赁整机、先用现有工作站试跑都是常见路子。判断标准是负载是否长期稳定、对停机容忍度多高。短期验证阶段用租的或二手的更稳；一旦确认要长期跑且数据不能出内网，再考虑采购，别一上来就按满配买。
只算显卡钱够不够？
不够，而且差得不少。电源、机箱、散热、存储、机位、电费、人力都属于真实支出，其中电费和人力是持续性的。建议至少把「一次性硬件」和「每月运行」两张表分开列，再看总账，否则很容易低估半年后的负担。
小团队怎么判断该自建还是调 API？
看三件事：日均推理量、数据能不能出内网、有没有人负责运维。量小或波动大就调 API；数据必须留内网且量稳定，再考虑自建。三条里只要有一条明显不满足，自建的经济性就要打问号，具体可以拿站内算力总览的租用价格做一次对照。
预算算出来是区间，怎么报给老板？
按「必须项、可延后项、可砍项」三档报，并附上对应的工作量假设（并发多少、上下文多长、保留多久）。同时给一条替代路径的成本，比如同等负载全走 API 的月度开销，让决策者看到两条路的差别而不是一个孤零零的数字。
模型换代快，硬件会不会很快过时？
会。显存和内存这类硬指标过时慢，算力和互联规格过时快。稳妥做法是把钱压在显存容量上，算力需求用租的补；采购时优先考虑能加卡、能扩内存的整机结构，别一次买死。
