GPU 集群的容量规划：从卡时到业务增长

容量规划在算什么账

FLOPS、卡时这些算力单位怎么定义怎么换算，「算力度量衡」一篇已经立过规矩；本篇用这套单位回答一个经营问题：业务要增长，GPU 什么时候缺、缺多少、缺口怎么补。容量规划做不好有两种死法：一种是被流量打死——高峰排队爆表，业务方骂上门来才发现缺卡；另一种是被账单打死——按想象中的峰值囤了一堆卡，利用率常年两位数，成本报表自己会说话。好的规划是中间那条窄路：在正确的时间，备正确数量的卡。

规划的第一步是统一单位。业务方说「日活涨五成」，平台说「集群两千张卡」，两个数没法直接比，统一折算成卡时（一张卡运行一小时）才能对齐：需求侧把业务量折成需要的卡时，供给侧把集群折成能供给的卡时，缺口一目了然。

缺口出现时，应对动作分两个时间尺度：分钟级的运营手段（排队、限流、降级到小模型、缩短上下文）与月级的扩容手段——本篇的规划管后者，前者是运营层的安全垫。两类需求还要分开记账：推理需求是持续流量型，随业务涨落；训练需求是项目制的大块申请（一次要几百卡跑几周）。两种形状的账混在一张表里，高峰叠加时谁都说不清谁挤了谁。

从 QPS 到卡时的换算链

正向换算：四步算出卡数

从业务指标到卡数的换算链有四步。第一步，定峰值流量：拿到业务预测的峰值 QPS（每秒请求数）与平均每请求的输出 token 数，两者相乘得到每秒 token 需求——注意规划主口径是峰值不是均值，后面细说。第二步，定单卡吞吐：目标模型在目标卡型上的实测吞吐（每卡每秒能稳定输出的 token 数），这一项必须用实测值或同构环境数据，论文数字与厂商宣传只能当天花板参考。第三步，相除得到裸卡数：每秒 token 需求除以单卡吞吐。第四步，除以目标利用率得到实际备卡数。

用一个自洽的示例走一遍（数字为演示口径）：假设峰值 QPS 为 20，平均每请求输出 500 token，每秒需求就是 1 万 token；若单卡实测吞吐为每秒 2000 token，裸算 5 张卡；按 75% 的利用率目标一除，约 7 张。再留一份冗余应对单卡故障与发布窗口，容量答案就出来了。这个算术简单，容易错的是输入：峰值 QPS 用了均值、吞吐用了理想值、利用率目标拍了脑袋——三处偏差叠起来，规划可以差出一倍。

「平均每请求输出 token」这个输入也值得单独交代：不同业务形态差异极大——问答、摘要、代码生成的输出长度不在一个量级，最好按业务线从历史日志里统计输出长度的分布，取均值再乘峰值系数，而不是拍一个整数。还有一点常被忽略：单卡吞吐不是常数，它随并发量与批大小变化——实测要在业务的目标并发区间内测，取保守值；引擎参数调整后吞吐会变，规划假设要跟着重测。

吞吐实测还有个正确姿势：测吞吐的同时记录批大小、并发数与显存水位——吞吐数字脱离运行条件就没有意义。报告里写清「某模型在某卡型、某并发区间、某上下文长度下的吞吐」，这份实测档案本身就是平台资产，下次规划直接引用，而不是每轮重新踩坑。

反向校验：显存与并发

token 吞吐之外还要做一道反向校验：并发容量。每秒 1 万 token 的需求若以「每请求 500 token、持续 30 秒」的形态到达，同时在跑的请求数就有几百个，每个请求的 KV Cache 都要占显存（KV Cache 的显存账在「KV Cache」两篇里算过），并发上限乘单请求显存占用不能顶到显存墙。吞吐够而并发不够的服务，表现为高峰期排队而不是变慢，容易误诊成「算力不足」，其实该扩显存或压上下文长度。正向算吞吐、反向校并发，两条都过才算数。给个演示口径感受反向校验：假设并发四百路、每路 KV Cache 峰值 1GB，显存需求就是四百 GB 量级——按单卡 80GB 算，光 KV 就要五六张卡，还不算权重。上下文长度是这里的乘数：业务若要支持长上下文，并发能力断崖式下降，容量规划必须按业务的上下文长度分布加权，而不是拿最长会话拍上限。

利用率目标的悖论

利用率目标定多少，是容量规划里最反直觉的一题。直觉说卡越满越省钱，排队论说利用率逼近一，排队延迟就发散——利用率九成以上的系统，高峰期一点小抖动就能让队列长度翻倍，延迟毛刺击穿 SLA。堆满等于排队，留余量等于烧钱，目标区间只能在两害相权里取。业界常见口径是把在线服务的稳态利用率目标放在七八成的区间（具体值按业务延迟预算实测校准），把最后那两三成算力不留给常态流量，留给突发。

这个悖论还有一个漂亮的解法：分级填谷。在线服务按低利用率目标保延迟确定性，省出来的余量不是闲着，而是调度可抢占的离线任务（批量评测、数据预处理、蒸馏造数据）进去填——高峰一来离线让路，高峰过去离线回填。余量从「烧钱的保险」变成「赚钱的缓冲池」，利用率悖论就化解了大半。离线任务的抢占与回收机制，是这套玩法的工程前提。

给排队延迟一个直觉数字，免得目标区间显得武断：按排队论的常识口径，利用率八成五时，平均排队延迟已经是服务时间的数倍；逼近九成五，队伍长度对到达率的微小扰动极其敏感——白天一场流量抖动就能让等待时间翻几倍。这就是为什么利用率目标不能只看「平均省了多少钱」，要看高峰分位的用户体验：省下的卡钱与丢掉的用户，两本账要并排放。

利用率目标还要分服务定级：核心交易链路的目标压低些保确定性，边缘功能与内部工具的目标抬高些提密度——同一批卡上不同等级的服务共享余量。这其实是「分级填谷」的微观版本，只是颗粒从集群级缩到了服务级；两级的道理相同，都在问同一个问题：这份算力余量，值多少钱的确定性来换。

峰值与均值：潮汐与错峰

业务流量几乎都有潮汐：白天高夜里低，工作日高周末低，业务节奏还会叠加长周期峰谷。按峰值规划稳但贵——为每天只出现几小时的峰值养着全量算力；按均值规划省但崩——每天高峰都排队。破局的常规武器是错峰：不同业务把高峰错开，轮流用同一批卡。训推一体是最大的一处错峰——训练任务填夜谷，白天的峰值留给推理，「训推一体资源错峰」一篇专门算过这笔账；推理服务内部的弹性伸缩（按潮汐跟量缩扩容，「弹性伸缩 KPA」一篇讲过机制）是另一处。规划时把各业务线的潮汐曲线画在同一张时间轴上：重叠的峰才是真需求，错开的峰可以共享同一批卡——这一眼常常能看出两三成的节省空间。

错峰还有跨地域的玩法：业务出海后，国内白天型业务与欧美时区业务天然互补，同一批卡轮流服务两个「白天」；时差叠加得好的组合，峰值重叠部分很小。另外别漏了事件型峰值：大促、发布会、新品上线这类计划内的脉冲不在常规潮汐里，要有专项预案——临时租赁加一张降级清单（哪些非核心功能在峰值时让路），事件结束供给回收。

潮汐曲线的取数也有讲究：用最近几周的流量画像，而不是拿历史峰值外推——业务结构变了，旧曲线会骗人；画像本身做成月度刷新的例行项，曲线跟着业务走，规划才贴得住现实。

提前期与规划方法

交付周期决定规划视野

缺口算出来了，补缺口的动作有提前期。自购扩容的周期以月计：高端 GPU 从下单、交付、上架、装驱动验健康到进调度池，整条链走完动辄数月（具体周期随供货行情波动，规划按保守口径预留）；租赁把提前期压缩到天级，代价是单价高且长期租不划算——「算力租赁与二手 GPU」一篇对比过两条路的经济账。组合策略因此清晰：基线负载用自持资产扛，峰值与临时需求用租赁补，自持规模按「去掉峰值后的基线」规划，租赁弹性按「峰值减基线」规划。提前期按自购交付周期倒推——想在某月用上卡，倒退数月就要下决策，容量规划因此必须是滚动的前瞻工作，不是月底补作业。

交付链路值得拆成分项预算，首次扩容尤其慢：下单与合同、物流与上架、组网与驱动、烧卡验收（新卡要跑满负载测试几天筛出早期故障件）、进调度池，每一环都有时间与人力成本；首次部署还要搭机柜供电与散热，比后续扩容慢得多。把上次的实际交付周期记下来当本次的基准，比任何经验公式都准。

扩容决策还受资产残值的隐性约束：买卡要考虑技术迭代让旧卡加速贬值——新架构的性价比碾压是行业常态，三年后的旧卡可能租不出价钱；租约要考虑长期租的总成本逼近购入价。两种资产形态的选择，本质是对「这批卡两年后还值多少」的判断，规划文档里应该有这一行判断及其依据。

表格化的滚动方法

落地为方法，就是三张表按月滚动。需求表：业务线、模型、峰值 QPS、平均 token 数，外加业务方的增长预测；供给表：各集群各卡型的卡时供给，扣掉故障率与维护窗口的实际可用率；缺口表：两表按月对齐，正缺口标扩容动作（采购或租赁、各多少、几月到位），负缺口标优化动作（降级模型、压上下文、提升利用率）。三张表每月用真实利用率数据校准一次——尤其单卡吞吐的假设值，实测偏差是最常见的规划失准来源。规划文档本身也要版本化，事后复盘「当时为什么这么算」全靠它。

三张表的运转还要配沟通节奏：每月与业务方对齐一次增长预测，预测数字由业务方确认而不是平台方代猜——预测错了板子打谁不重要的，重要的是预测误差会被记录并用于校准下次预测。卡型混布的账要分开算：不同卡型吞吐不同，业务需求要按目标卡型分别换算，不能拿一张表混着除；跨卡型的迁移（业务从老卡迁到新卡）是规划里的主动作，迁移计划本身也占提前期。

缺口表里的动作还要带验收口径：扩容动作的完成定义不是「卡到货」，而是「卡进调度池且跑过验收负载」——每一行动作都要能被事后判定成或没达成，这是规划闭环的最后一环，也是「规划是否真的管用了」的唯一检验方式。

小结

GPU 容量规划是一门翻译学：把业务增长翻译成 token 需求，把 token 需求翻译成卡时缺口，把缺口翻译成采购、租赁与优化的时间表。换算链四步（峰值需求、实测吞吐、裸卡数、利用率修正）简单但处处是坑，正向算完吞吐还要反向校并发显存；利用率目标卡在排队论与成本的两害相权，用离线填谷把余量变成缓冲池；潮汐曲线叠图找错峰空间，训推错峰与弹性伸缩是两件现成武器；提前期决定规划视野，基线自持、峰值租赁的组合让钱花在确定性上，三张表按月滚动让规划活起来。

这门手艺的价值不在公式复杂度——公式只有乘除——而在输入的诚实：峰值别用均值糊弄，吞吐必须实测，利用率目标要有延迟预算支撑。容量规划做得好的平台，业务方的感觉是「要资源时总有一点点余量，成本报表却没失控」；做得差的平台则交替经历两种噩梦：高峰排队的骂声与月底账单的惊吓。区别不在运气，在有没有把这本卡时账按月认真记下去。