私有化部署大模型算力怎么估?先问清三个变量

估算私有化大模型算力,应先明确用途,再拆清模型规模、同时使用人数、单次资料长度三个变量,先小规模跑通后再扩容,同时核对机柜功率与散热。

要点速览

• 算力估算应从业务用途倒推,而不是先定硬件
• 模型规模、同时提问人数、资料长度三者叠加决定显存与速度
• 先以优先场景小规模跑通,按真实调用数据再扩容
• 机柜功率、散热、网络与上架环境要和硬件同步核对
• 向供应商索要估算依据,而不是只要一份配置单

私有化部署大模型的算力,不能先定“买几张卡”再找用途,而要从业务倒推。先说清要跑什么任务,再拆开模型规模、同时使用的人数、单次处理的资料长度这三个变量,判断它们对显存和响应速度的影响。之后先小规模跑通,按真实使用情况再扩容。机柜功率、散热、网络和上架环境要和硬件一起评估。“几张卡够用”没有统一答案,但有一套能问清楚、能复核的估算方法。

常见误区:先买硬件,再找用途

不少企业在预算阶段的做法是:先听说某款服务器配置不错,或者参照别家的采购清单定下硬件规格,再回头想这些算力拿来做什么。结果常见两种情况。一种是买多了,大部分时间算力闲置,预算压在设备上。另一种是买少了或买偏了,模型跑得起来,但多几个人同时用就排队,资料一长就卡顿。

问题不在硬件本身,而在顺序。算力是为业务服务的,业务需求不清楚,任何配置都只是猜测。所以估算的第一件事不是看参数表,而是把用途、人数和资料情况问清楚。下面按四步展开。

第一步:先说清楚要跑什么

同样叫“部署大模型”,不同用途对算力的要求差别很大。建议先把计划上线的场景逐一列出来,常见的有四类:

• 对话问答:员工日常提问、写作辅助、内容整理。单次输入通常较短,但使用人数可能多,高峰时段集中。
• 知识库检索问答:先从企业资料里检索相关段落,再交给模型组织回答。检索到的内容会拼进输入,单次处理的长度会明显增加。
• 文档处理:合同、报告、制度文件的整理、摘要、初步审核与风险标记。单份资料可能很长,对上下文长度更敏感,但同时使用的人数往往不多。
• 代码辅助:代码解释、生成、排查。需要读取较多代码上下文,对响应速度的体感要求较高。

列清用途之后,再给每个场景标上优先级:哪个先上、哪个后上、哪个只是“以后可能要”。估算以先上的场景为主,后续场景作为扩容依据,不要一开始就按所有场景叠加采购。另外,在法律、财税这类场景中,模型只做资料整理、初步审核、风险标记与提示,判断和确认仍由专业人员完成,这一点也会影响对响应速度和并发的实际要求。

第二步:拆开三个变量,看清各自影响

用途明确后,算力估算可以拆成三个变量。这里只讲思路和影响方向,具体数值需要结合所选模型和硬件实测。

模型规模

模型参数越多,加载模型本身占用的显存越大,每生成一段内容需要的计算也越多,响应会相应变慢。规模更大的模型通常能力更强,但不是每个场景都需要。日常问答、格式整理这类任务,较小的模型往往已经够用;复杂推理、长文审阅可能才需要更大的模型。量化等手段可以降低显存占用,但可能影响输出质量,是否采用需要在真实任务上对比验证。

同时使用的人数

这里要区分三个数:开通账号的人数、同一时段在线的人数、同一时刻真正在等模型回答的人数。影响算力的主要是第三个。每一个正在处理的请求,除了共用模型权重,还要单独占用一部分显存来保存上下文缓存。同时处理的请求越多,这部分占用越大;超出能力范围的请求就会排队,用户感受到的是“等得久”。所以要问清业务的高峰时段、高峰时大约多少人同时提问,而不是只报一个员工总数。

单次要处理的资料长度

输入越长,单个请求占用的缓存越多,模型开始输出前的等待时间也越长。知识库检索会把多段资料拼进输入,文档处理可能一次放进整份合同或报告,代码辅助需要读取多个文件,这些都会把长度推高。估算时要问清:典型资料有多长,偶尔出现的长资料有多长,是否允许把长资料拆分处理。

三个变量不是各算各的,而是相互叠加。大致可以理解为“模型本身的占用”加上“每个请求的缓存 × 同时请求数”,而每个请求的缓存又随资料长度增长。任何一个变量估高或估低,都会让整体结果偏离。所以供应商只问一句“多少人用”就给配置,往往不够。

第三步:先跑通,再按真实使用扩容

即使三个变量都问清楚了,估算结果仍然是假设。员工实际怎么用、高峰有多集中、资料平均多长,往往要上线一段时间才看得清。比较稳妥的做法是:

• 以优先级靠前的一两个场景为范围,先部署能满足这部分需求的算力,留出适度余量;
• 上线后持续记录调用量、高峰并发、平均输入长度、排队与响应情况;
• 根据记录判断瓶颈在哪里,是显存不足、并发不够还是模型选得偏大,再决定加卡、换模型还是调整用法。

这样做的前提是硬件和系统支持平滑扩容。采购前要确认:服务器是否预留了加卡位置,机柜空间和供电是否留有余量,增加算力后能否不大改应用就接上。一次买满看上去省事,实际上是把不确定性全部压成了预算。

第四步:算力之外,机房条件要一起算

GPU 服务器的功耗和发热明显高于普通服务器。很多项目卡住,不是因为卡不够,而是上不了架、散不了热。硬件选型时,至少要同步核对:

• 机柜功率:单台设备满载功耗、单柜可承载的功率上限、是否需要拆分到多个机柜。具体方法可参考服务器托管机柜功率怎么选。
• 散热:机房制冷能力是否匹配高密度设备,冷热通道如何组织。
• 网络:内部用户访问、多台服务器之间的互联、模型和资料的更新方式。
• 上架环境:设备尺寸与重量、电源接口、运维人员进出与远程协助方式。上架前的逐项核对可参考GPU服务器托管要看哪些条件。

如果企业自有机房条件有限,可以考虑托管。润迅在深圳自建并运营前海云与田心两个数据中心。前海云按 T3+ 标准建设,拥有 1400+ 机柜;田心有 400+ 机柜。两处都可为算力设备提供上架与运维环境。

硬件、系统与模型管理一起交付,估算可以按业务倒推

前面四步的难点在于,硬件、系统、模型分属不同环节。分开采购时,每一方只对自己那部分负责,三个变量的估算容易在交接中走样。润迅的 MaxDeploy 交付方案把基座分为三层一起交付:R30 私有化硬件提供算力;XunOS 是其中的 AI 操作系统;MaxModel 是模型统一管理平台,用一个 Key 接入所需的大模型,并提供多模型路由与调用审计。

放在算力估算这件事里,它解决两个具体问题。一是选型可以从用途出发,由同一方把场景、模型和硬件放在一起评估,不用各自报配置。二是上线后可以借助 MaxModel 的调用审计查看调用情况,扩容和换模型有实际数据作依据,不只凭感觉。在此之上还可以运行 MaxKnow 企业知识库等应用。完整的落地环节可以延伸阅读企业私有化部署 AI 怎么落地。

行动建议:向供应商提这几个问题

询价或做预算时,可以把下面这份清单发给供应商,看对方能否逐条给出依据,而不是直接报一个配置:

1. 用途:按我们列出的场景,分别建议什么规模的模型,理由是什么?
2. 并发:配置是按多少人同时提问估算的,高峰排队时如何表现?
3. 资料长度:按多长的输入估算,遇到长文档时如何处理?
4. 扩容方式:是否预留加卡空间,加卡后系统和应用需要做哪些调整?
5. 散热与机柜要求:单台满载功耗多少,需要怎样的机柜功率和制冷条件?
6. 模型切换与调用审计:能否在不改应用的情况下更换模型,调用记录能否留存和查询?
7. 验收口径:以哪些场景、哪些指标作为验收依据,由谁来确认?

这些问题问清楚了,算力估算就从“猜一个数”变成了“有依据的判断”。如需结合具体场景评估,可拨打润迅业务热线 400-854-5566。

→ 联系润迅,聊聊你的场景,获取适合的方案