部署一套满血版 deepseek 要多少钱

很多团队在估算自建成本时只看显卡报价，结果预算批下来才发现电费、机房、运维人力、备用件都没算进去，实际支出翻倍。这篇不讲模型原理，只讲钱怎么算：把一次性投入和每月固定支出分开放，列出容易漏掉的科目，给一个从需求反推配置的排查顺序，并说明哪些场景下自建根本不划算。

很多团队做自建预算时，第一步就是去查加速卡报价，然后拿这个数字乘几张卡，得出一个「总投入」就报上去了。等真正落地才发现，机房要改造、电费按月扣、还得有人盯着服务别挂，实际支出比当初那张报价单高出一大截。这篇不讲模型原理，只讲钱怎么算。

核心思路就一句话：把一次性投入和每月固定支出彻底分开，别混在一张表里看。自建的成本曲线是前期陡、后期平，用月租的思维去对比单价，结论一定是错的。下面按四类科目拆开，再给一个从需求反推配置的顺序。

先把钱分成四类：一次性、按月、按量、隐性

为什么强调分类？因为不同类别的钱，决策逻辑完全不同。一次性投入批下来就花掉了，按月支出是持续流血，按量支出跟着业务波动，隐性成本则往往在立项时被当成「应该不会有吧」而忽略。混在一起看，很容易低估长期负担。

• 一次性投入看的是现金流能不能扛住，不是总价高低；
• 按月支出看的是业务低谷期还能不能养得起；
• 按量支出反而是最灵活的，但依赖外部服务稳定性；
• 隐性成本最容易被漏，建议单独立一行而不是塞进「其他」。

从并发和上下文反推配置，而不是从卡型正推

另一个常见错误是先在采购目录里挑一张卡，再想「几张够用」。正确顺序反过来：先量化需求，再反推配置。需要量化的是三件事——峰值并发请求数、单次请求的平均输入输出长度、可接受的延迟上限。这三项基本决定了显存、算力和带宽的需求量级。

1. 第一步：估真实并发别用平均值，用历史日志里的 P95 甚至 P99 峰值。平均值会严重低估配置需求，导致上线后一排队就超时。
2. 第二步：算显存门槛权重本身占用的显存是硬门槛，权重之外还要给 KV 缓存留量。长上下文场景这块涨得很快，具体系数到 /models/deploy 按模型和上下文长度试算。
3. 第三步：定卡数拿着并发分布和上下文长度去 /compute/sizing 看几张卡够用，这一步出来的才是配置，不是拍脑袋。
4. 第四步：挑型号最后才去 /compute/gpus 挑具体型号，这时候你已经有明确的显存和算力下限，不会被参数表带跑。

什么情况下这个顺序不适用？如果你的流量是每天几次的批处理任务，延迟不敏感，那配置逻辑完全不同——按吞吐量选而不是按并发选，甚至可以排队慢慢跑，卡数能压得很低。

硬件账单：卡之外的支出比你想的多

加速卡只是整机的一部分。CPU、内存、系统盘与数据盘、电源冗余、机箱风道都要算进去。高功耗卡对供电和散热的要求会连带抬高整机成本，甚至可能需要改造机柜供电，这笔钱在报价单上看不到，但会真实发生。

三条路各自的现金流形态不同，去 /compute/gpu-rental 对比当时的租用口径，别只比单张卡的对标价格。如果考虑国产卡替代，可行性与限制要去 /compute/domestic 核一遍——别只看参数表，要看驱动成熟度、推理框架兼容性，以及实际能不能稳定拿到货。

电费、机房与运维：每月都在流血的部分

这部分是自建和调用外部接口最本质的差别。外部接口是按量付费，业务量掉下来账单就降；自建的月度支出是刚性的，设备通电就在烧钱，业务停了电费照付。立项时如果只算了硬件，这部分会让预算在半年后失控。

• 电费：按整机功耗乘 24 小时乘天数估，再乘上机房 PUE 系数，去 /compute/power 看当时的电价与功耗口径；
• 带宽与机房：内网自建、IDC 托管、云上租用三种形态的网络成本和合规限制差别很大，涉及数据不出内网的要单独确认；
• 人力：至少要有一个人能处理驱动问题、显存溢出、推理服务重启、模型更新，建议按半个人力折算进月度成本；
• 别默认「现有同事顺手就干了」，运维是有学习曲线的，出故障时的时间成本要算进去。

什么情况下这部分可以压低？如果你的业务量本身很小、延迟要求宽松，一台机器就能扛住，那电费和人力都能压到很低；但只要并发上去了，这部分就是刚性支出，降不下来。

最容易漏掉的六笔钱

下面这六项，几乎每个自建项目都会遇到其中几项，但很少有团队把它们写进立项表格。每一笔都标了触发条件，评审时逐条过，别笼统写「可能有」。

• 备件与冗余：卡坏了等维修的那段时间服务怎么办，要不要常备一张，这是真实开支；
• 版本升级成本：模型或推理框架换代带来的重新适配与回归测试工时；
• 监控与日志存储：推理服务的指标采集、日志留存，长期跑下来是笔固定开销；
• 灰度期重复支出：迁移阶段自建和外部接口并行跑，两份钱同时在花；
• 安全与合规审计：涉及敏感数据时的额外评估与整改成本；
• 人员培训与文档：轮到第二个人接手时，没有文档的代价会翻倍体现。

建议做法是：把这些列进立项表格的独立行，而不是塞进「其他」一栏。评审会上逐条问「这项什么时候会真的发生」，答不上来的先按最坏情况估。

混合路线：不是非黑即白

自建和外部接口不是二选一。常见组合是：日常低峰走外部接口，敏感数据或高峰走自建；或者核心业务自建，长尾任务外部兜底。这种模式的关键在于路由和降级逻辑写在业务层，而不是靠人工手动切。

成本上要算的是「自建固定成本 + 外部按量成本」的总和，而不是只比调用单价。如果外部调用占比很低，自建的固定成本可能永远摊不平——这时候纯自建反而不如继续用外部接口加少量自建。

什么情况下混合路线不成立？如果数据完全不能出内网，那就只能纯自建，预算要按纯自建的口径算，别用混合的数字去批纯自建的预算。备选外部来源可以去 /sites 和 /rankings 挑，选的时候注意服务稳定性和数据合规要求。

决策清单：先回答这七个问题再谈预算

在进入采购环节之前，先回答下面七个问题。三个以上答不上来，说明需求还没量化清楚，这时候谈预算就是拍脑袋。

• 数据能不能出内网；
• 峰值并发是多少，用 P95 而不是平均值；
• 延迟要求是秒级还是分钟级；
• 业务量是稳定曲线还是脉冲式；
• 团队里有没有人能长期维护推理服务；
• 预算是一次性投入还是按月支出；
• 三年内这个需求会不会消失或大幅变化。

最后提醒一句：外部接口价格在变，自建成本也在变——电费、卡价、二手残值都会动。建议每季度重算一次，而不是算一次管三年。判断标准会过时，现金流不会骗人。