很多人一搜「本地化部署多少钱」，看到的都是别人报一个总价，但你照着买完发现不够用或者白买了。问题在于成本不是一个数，而是硬件、人力、运维三笔账加一起，而且随并发量、上下文长度、要不要微调变化很大。这篇不讲答案，讲怎么自己算，以及去哪查当时的行情数字。
很多人搜「本地化部署多少钱」，看到的都是别人报一个总价，你照着买完，要么发现不够用、要么发现白买了。问题在于成本根本不是一个数，而是硬件、人力、运维三笔账加在一起，而且随并发量、上下文长度、要不要微调变化很大。这篇不讲一个固定答案，讲怎么自己算，以及去哪查当时的行情。
先说一句实话：任何直接给你一个总价的说法，都要问清它的前提——跑多大模型、扛多少并发、要不要对外服务、团队里有没有人懂推理框架。这四个条件换一个，预算能差出一大截。所以下面给的是测算顺序和清单，数字你自己套。
先把成本拆成三条线，别混成一个总价
- 硬件线
- 卡、整机、存储、网络、机房或托管，属于一次性投入加折旧；显存决定能跑多大模型和多长上下文，卡数决定并发上限
- 人力线
- 环境搭建、推理框架调优、接口封装、监控告警，以及后续模型换代时重做一遍，这部分最容易被严重低估
- 持续线
- 电费、带宽、机房托管或云上租卡月费、备份与灾备，按月发生，不会因为部署完就消失
怎么把三条线落到自己的场景上？关键动作是先写清用途，再谈预算。内部几十人试用的问答助手，和企业对外提供服务的推理接口，成本量级完全不是一回事。选型前至少写清楚三个数：并发峰值、日均调用量、最长对话长度。
- 用途先定死：内部工具、对外服务、还是离线批处理，三者的卡数和冗余要求不同
- 并发峰值按「最忙那一小时」估，别按平均值买卡，平均值会让你买少
- 日均调用量决定持续线里的带宽和电费量级
- 最长对话长度直接影响上下文缓存占用，这一项很多人算的时候直接漏掉
- 把这三条写成一页纸，再往下算，后面每一步都拿它对照
按「显存 → 卡数 → 整机 → 托管方式」的顺序倒推
顺序很重要，从显存倒推，而不是先去挑卡。显存不够，模型加载都加载不起来；显存够了但卡数不够，并发一上来就排队。所以先算显存，再算卡数，最后才决定买什么整机、放哪里。
- 第一步：估显存占用模型权重占用是一块，上下文缓存（KV Cache）是另一块，后者随并发数和对话长度近似线性增长。把「权重 + 单请求缓存 × 目标并发」估出来，你才知道单卡够不够。
- 第二步：反推卡数拿你要的并发数乘单请求占用，去除以单卡可用显存，向上取整，再留一张冗余。验算方法：拿这个数跑一轮压测，看队列积压是不是在可接受范围。别按「模型能加载」来买卡，要按「并发能扛住」来买。
- 第三步：选整机同代里消费级卡和面向长期服务的卡，在稳定性、散热、驱动支持上差别很大。长期跑线上服务，别只看单卡单价，要看连续跑几周会不会掉卡、驱动好不好跟。
- 第四步：定托管方式自建机房、托管、云上租卡三条路的现金流节奏不一样。用三年口径把它们拉平再比，不然容易被「首月很便宜」这种结构带偏。
- 第五步：核对当时行情卡型规格和租赁价格会变，算到这里去站内页面核对当前数字，别用记忆里的老价格。
这一步算完，去 /compute/gpus 看当前能租到的卡型和规格，再用 /compute/sizing 对着自己的并发参数过一遍容量口径，最后到 /compute/tco 把三条路的三年总成本拉平。
最容易漏算的几项
很多人预算超支，不是主项算错了，是这些零碎项没算进去。下面这几项，按出现概率排序，前两项基本每个团队都会撞上。
| 漏算项 | 为什么会漏 | 怎么提前算进去 |
|---|---|---|
| 冗余卡 | 只按能跑起来买，没考虑单点故障 | 按总卡数预留一张备用，写进预算 |
| 带宽与出口 | 只算内网，没算对外服务的公网流量 | 对外的服务把上行带宽和流量单独列一项 |
| 模型换代 | 假设部署一次就长期不变 | 按年预留一笔换卡或换框架的预算 |
| 人力持续投入 | 以为部署完就结束 | 把版本升级、OOM 排查折算成每月工时 |
| 微调算力 | 只算推理，没算训练 | 走微调路线要单独算，参考 /compute/finetune 与 /compute/training-cost 的口径 |
- 冗余：没有备用卡，故障时只能停服，平时不产出但必须占预算
- 带宽：对外推理服务，上行和公网流量经常是第二笔意外支出
- 换代：权重变大或结构变化，可能要重新买卡或换推理框架
- 人力：框架版本升级、显存碎片、OOM 排查都要人长期跟
- 微调：训练算力和推理算力是两笔账，别混在一起估
算完再和走 API 比一遍，别只比单价
自建和走 API 比，最常犯的错是拿自建的单位成本去比 API 的单价。正确口径是：自建要把硬件折旧、人力工时、电费、机房全摊进单位 token 成本，这样才和 API 可比。摊完你可能会发现，某些量级下自建并不便宜。
| 判断维度 | 更适合自建 | 更适合走 API 或中转 |
|---|---|---|
| 调用量 | 长期稳定且大 | 波动大、早期还在验证需求 |
| 数据边界 | 数据不允许出内网 | 数据出内网可接受 |
| 延迟要求 | 需要固定延迟或深度定制 | 对延迟不敏感 |
| 团队人手 | 有懂推理框架运维的人 | 没有专职运维算力的人 |
| 合规成本 | 能承担等保、审计、日志留存的额外投入 | 希望这部分由服务方承担 |
还有一条中间路线：核心数据场景自建，边缘场景走 API，两条腿走路。这样既守住数据边界，又不用为了波峰买一堆平时闲置的卡。比价的时候去 /official-api 看当时的价目，别用旧截图。
- 比的是全口径单位成本，不是卡价对比 token 单价
- 调用量长期稳定且大、数据不能出内网、需要固定延迟，这三条同时成立时自建更划算
- 调用量波动大、需求还在验证、团队没人懂运维，这三条里占两条就先走 API
- 合规不是免费的，等保、审计、日志留存都会带来额外投入，先确认边界
- 两条路可以混着走，核心自建、边缘走 API
本地化部署的成本不是一个数，是一组随并发、上下文和用途变化的数；先写清前提，再谈预算。下一步把你自己的并发峰值、上下文长度、用途写下来，然后去站内核对当时的卡型、租赁行情与 API 价目，再决定自建还是走接口。→
常见问题
私有部署 DeepSeek 一定要买很贵的卡吗？
取决于你要跑什么规模。只给几个人内部试用，消费级卡配量化权重往往能跑起来；要对几十上百并发提供稳定服务，就得按并发反推卡数，单卡单价的思路会失效。建议先按峰值并发和上下文长度算显存占用，再去 /compute/sizing 对照当时的卡型与规格。
人力成本一般占多大比例？
没有固定比例，但小团队最容易在这里翻车。部署本身可能几天，麻烦的是后面：推理框架升级、显存溢出排查、监控告警、模型换代重来一遍。如果团队里没人长期跟算力，要么预留出这部分工时，要么认真考虑走 API 而不是自建。
怎么判断该自建还是继续用 API？
看三条：调用量是否长期稳定且足够大、数据是否必须留在内网、是否有人能长期维护。三条都满足，自建的经济性和可控性才会体现；只满足一条甚至一条都不满足，先用 API 验证需求更划算。具体口径可看 api-vs-self-host-decision。
