大模型推理服务资源分配策略：从显存账本到弹性扩缩容的工程实践

1. 为什么模型服务的资源分配会变成一门“手艺活”做AI应用开发和模型部署的人前两年可能还觉得“资源分配”就是个启动参数的事--tensor-parallel-size 8一写模型拉起来能跑就行。但到了2026年这个节点情况完全不一样了——模型服务已经是生产环境里的基础设施单机单卡的玩法早就撑不住线上流量。我接触过的不少团队模型跑通了、POC验证也过了结果一到灰度上线就被打回原型原因几乎都出在资源分配策略上要么GPU显存爆炸导致OOM要么并发一上来延迟飙到不可用要么卡着满配买结果预算三个月烧穿。先说一个很多人忽视的底层事实大模型推理服务的资源瓶颈不是“算力”而是“显存带宽”和“显存容量”的双重约束。像70B这种规模的模型光BF16权重就有140GB一张H100是80GB这就意味着至少两张卡起步而推理过程中的KV Cache又随并发请求数动态增长这部分内存如果不做策略性管理系统会以一个极其难看的方式死掉——不是慢是直接OOM。所以所谓的“资源分配策略”本质上是在回答三个问题模型放得下吗请求挤得进去吗算力用得上吗这篇文章我会从请求链路、并发调度、多卡编排、弹性伸缩、过载保护、量化适配这几个角度把我在实际部署和调优中沉淀下来的经验完整拆开讲。内容面向的是正在做模型服务工程化、推理系统优化、AI应用上线的开发者和运维同学也适合准备从单卡demo走向生产架构的团队参考。先说结论资源分配策略不是一次性的配置项而是一套围绕“显存账本”“调度策略”“扩缩容时机”持续迭代的工程体系。下面从头开始把每一环讲透。2. 请求链路里的资源流向先把显存账本算清楚2.1 一张卡上的显存到底被谁吃掉了很多人在优化资源分配时第一反应是“加卡”但加卡之前应该先回答一个问题现有显存用在哪了我拆过一份线上服务的显存分配数据说实话和大多数人的直觉不一样——模型权重只占一部分真正吃显存的往往是KV Cache和运行时开销。一次正常的LLM推理请求显存消耗可以拆成四块模型权重和参数量、精度强相关。比如7B模型用BF16就是约14GB用INT8是7GBINT4则压缩到3.5GB左右。KV Cache每个请求在生成过程中都需要缓存历史的Key和Value张量这和“序列长度 × 层数 × 注意力头数 × 单头维度”直接挂钩并随并发数线性增长。激活值Activation前向计算过程中产生的中间张量。在长序列场景下这部分开销不容小觑峰值可能额外吃掉几个GB。CUDA context与运行时预留这个属于“固定税”经常被忽略但多卡并行时每张卡都得留出大约几百MB到1GB左右的余量。所以一个常见的估算公式是总显存 权重 KV Cache × 并发请求数 激活值峰值 预留余量。举个例子一个13B的BF16模型权重是26GB假设单请求KV Cache峰值1.2GB、同时16个并发那么光KV Cache就要约19GB总量接近50GB。这意味着单张80GB卡看似“勉强能塞”但一旦并发增加到32总量立刻逼近80GB红线OOM风险极高。2.2 KV Cache分配策略预分配还是按需增长围绕KV Cache的第一层资源策略是在“预分配”和“动态增长”之间做选择。早期的推理框架偏向静态预分配做法是在启动时按max_seq_len × max_batch_size预留KV Cache的显存空间。好处是稳定坏处是浪费——线上请求的实际序列长度和并发水平波动很大按峰值预留意味着低峰期大量显存被空耗。现在主流方案基本转向动态分配配合“按需申请、显存不足则阻塞或排队”的策略让显存利用率明显提升。这里有一个关键概念叫KV Cache的显存复用。在做动态分配时各个请求占用的缓存空间反复申请和释放会产生碎片。框架级解决思路通常是维护一个显存块池Block Pool以固定大小的块为单位分配流程类似操作系统里的内存分页管理。请求结束之后块不直接归还给CUDA而是归还到空闲块链表里供下一个请求复用。这个设计极大降低了频繁申请显存的开销也是vLLM这类框架PagedAttention的核心思路之一。实操中的一条经验是不要盲目调大KV Cache上限。有些团队为了让模型支持超长上下文把KV Cache预留卡到最大结果把激活值和CUDA context的余量挤没了一跑就OOM。我一般建议KV Cache动态上限控制在整个显存的40%~50%以内给调度和运行时留足缓冲。3. 并发调度策略吞吐和延迟之间的那杆秤3.1 Continuous Batching与动态批处理资源分配做好“空间账本”之后接下来要解决的是“时间账本”——GPU的算力每秒都在流逝如果一批请求中有的生成完了、有的还在算传统的静态批处理会把空闲算力白白浪费掉等整批跑完才放下一批进来。2026年的主流推理框架基本都采用Continuous Batching持续批处理只要一个请求完成了生成它的位置立即让给排队中的新请求不需要等整批结束。这个机制直接提升了GPU的利用率代价是调度器的复杂度上来了——每个判断周期都要对存量请求和增量请求做一次资源匹配决定谁能进入本轮计算。实际生产中影响批处理调度的不只是“新增请求进来了没有”还包括请求的序列长度差异长序列和短序列混在一起对KV Cache的压力差异巨大。请求所处生成阶段同样在批里的请求有的在预填充阶段有的在逐个token的解码阶段两者对算力和显存的需求特征不同。优先级差异线上交互请求和后台异步任务如果混跑必须通过队列策略做隔离。3.2 决定并发上限的关键参数链搞推理服务的人一定绕不开几个参数max_num_seqs、max_model_len、gpu_memory_utilization。这三个参数互相牵制构成了并发上限的“不可能三角”——显存总量固定按需取舍。以vLLM的启动参数为例python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --tensor-parallel-size 4 \ --max-model-len 8192 \ --max-num-seqs 64 \ --gpu-memory-utilization 0.9max-num-seqs决定单次调度最多同时处理的序列数取值越大吞吐越高但超过KV Cache可承载上限就会OOM。max-model-len限制单条序列的最大长度这是个隐性并发杀手——两条4096长度的请求和一条8192长度的请求KV Cache占用差了近一倍。gpu-memory-utilization控制KV Cache可用的显存比例。很多人喜欢拉到0.95但如果跑的是高并发短请求场景留给激活值的余量不足会导致批处理被频繁打断。我踩过的一个典型坑是为了追求吞吐把max-num-seqs调到了128KV Cache用满结果单请求延迟从800ms飙到3秒。原因很简单——并发上去了但显存带宽是固定的每个token的解码延迟被拉长了。最后把并发压回48P95延迟降到1.2秒吞吐反而提升了22%因为减少了显存争抢带来的无效等待。所以这里要强调一个原则吞吐和延迟不一定同向变化找到拐点是关键。理想做法是先从低并发开始压测逐步加压并监控每token解码时延和显存水位找到延迟拐点后把并发上限卡在拐点附近。4. 单机多卡与多节点并行策略的选型逻辑4.1 张量并行、流水线并行、数据并行的适用边界模型大到单卡放不下时并行策略就成了资源分配的核心话题。行业里常说的“3D并行”指的是三种维度的组合但很多初接触分布式推理的人容易混我按实际选型经验拆开讲。张量并行Tensor Parallelism, TP把模型权重和计算按层内维度切成多份分布在多张卡上每张卡各算一部分卡之间频繁做AllReduce同步。这是推理场景下最常用、也是性能最好的并行方式因为单batch内一个层的计算可以通过NVLink高效协同。缺点是通信开销大跨节点走以太网做TP通常会严重掉速所以TP一般只推荐在单机内、且用高速互联的卡之间使用。流水线并行Pipeline Parallelism, PP按层切分每个设备负责连续的若干层请求像流水线一样依次经过各阶段。PP的通信量比TP小很多但存在流水线气泡设备空闲等待前序阶段数据的问题延迟比TP高。适合模型极大、单机塞不下的场景。数据并行Data Parallelism, DP每张卡放全量模型各自处理不同请求是最简单、容错最好的方式。推理场景下只要单卡能放下模型通常优先考虑DP因为它天然线性扩展吞吐且无通信瓶颈。多副本配合负载均衡就是最朴素的弹性伸缩方案。下面这张表是我常用的选型对照并行方式核心机制通信需求适用模型规模主要代价张量并行TP层内切分权重极高依赖NVLink单卡放不下但单机可容纳通信带宽瓶颈流水线并行PP按层分段较低可跨机超大模型跨机部署流水线气泡、延迟升高数据并行DP每卡全量副本低仅同步状态单卡可容纳显存冗余、成本翻倍4.2 我建议的初版配置路径如果你对并行策略没有头绪可以参考这个循序渐进的原则先做数据并行多副本不够再用张量并行单机内再不够才考虑流水线并行跨机。原因很简单多副本是“加机器就能解决”的方案逻辑改动小风险最低TP能解决“单卡放不下”的问题但如果TFLOPS上不去加TP维度只会增加通信损耗。PP通常用在百亿到千亿参数级别、非上不可的场景同时也意味着要接受更高的工程复杂度。举个实际例子部署一个70B模型在8卡H800的机器上常规选择是TP4或者TP8。TP8时单batch吞吐更高但小并发场景下TP4反而延迟更低因为同步等待少了。如果是交互式应用、请求以小批量为主我倾向TP4如果是离线批量推理吃吞吐那TP8更合适。没有绝对的对错只有场景的匹配度。5. 弹性扩缩容与混合负载别让GPU闲着也没被挤爆5.1 扩缩容触发条件不能只看CPU做在线推理服务最担心的两个时间是“流量洪峰来了扛不住”和“流量低谷时成本还在烧”。弹性扩缩容就是用来平衡这两头的。但很多团队的触发策略做得过于粗糙——只看CPU使用率这在大模型推理场景下基本是误导性指标。推理服务真实的饱和度信号应该看三个排队队列深度如果请求进入队列到真正开始处理的时间持续变长说明后端容量不够。KV Cache水位或批处理饱和度显存中KV Cache占比长期在85%以上且持续有排队就是扩容信号。解码延迟变化率每token解码时间一旦出现斜率陡增往往意味着显存带宽逼近极限。我在K8s环境中常用的做法是结合自定义指标做HPA。Prometheus Adapter从推理服务暴露的指标中抓取vllm:num_requests_waiting和vllm:gpu_cache_usage_perc转化为HPA可消费的指标配置示例大致如下apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: llm-inference spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: llm-inference minReplicas: 2 maxReplicas: 10 metrics: - type: External external: metric: name: llm_inference_queue_depth target: type: AverageValue averageValue: 16 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80一个很重要的细节是扩容触发后新副本启动加载模型可能需要几十秒到几分钟。所以“扩容阈值”必须结合模型加载耗时来定不能等队列真堵死了才扩容。我通常建议“响应延迟P95超过目标值的一半时就开始扩容”宁可多备一个副本也别让用户体验先受损。5.2 在线离线混部时间片错峰和资源池隔离很多平台会同时跑两类负载一类是面向用户的在线交互延迟敏感另一类是批量离线任务比如评测、数据清洗、离线生成延迟不敏感。把两者混在同一批GPU上能显著提高资源利用率但混部不当会出现“离线任务把KV Cache占满在线请求排队到超时”的灾难场景。主流的做法是“错峰调度 显存水位隔离”定义两个逻辑资源池在线服务所在的池子保留最低水位保护线。比如GPU显存分配时保留20%的KV Cache空间不接受离线任务请求。离线批次任务只有在线池的显存水位低于阈值时才被允许调度一旦水位上升就暂停或降级。在K8s中用PriorityClass区分两类Pod的优先级离线Pod设置较低的抢占优先级并搭配PodDisruptionBudget防止大规模驱逐。这套方案的收益是实打实的我见过一个团队把评测集群和在线推理共用同一批8卡节点的资源利用率从35%提升到70%以上同时在线服务P99延迟没有明显劣化。关键不在于技术有多深而在于是否愿意花精力去设计“隔离 兜底”的机制。6. 过载保护与兜底策略资源分配的最后一道防线6.1 排队策略和超时熔断资源分配策略做得好不等于系统永远不会过载——流量有时就是会突然涨到设计容量之外。这时候决定系统能不能“体面失败”的是过载保护设计。我归纳了三个必需的兜底机制有界队列。请求进来先排队但队列长度必须有限。无界队列在过载时会把内存打爆比拒绝请求严重得多。生产上一般用有界队列加“拒绝新请求并返回503”的策略。请求超时熔断。每个请求在队列中的等待时间必须有上限。我常用的配置是“排队超过2秒直接返回错误”或“总耗时超过10秒触发客户端重试”避免大量请求堆积放大下游压力。对于长上下文生成场景超时阈值要按预估生成token数动态调整不能一刀切。按用户/任务分级限流。内部任务和外部用户请求要分开配额高优先级客户要单独兜底。否则一个批量任务就能把整个集群的排队队列塞满影响所有在线用户。6.2 降级响应比失败更优雅的答案在模型服务资源紧张时还有一层比“硬拒绝”更聪明的策略——降级。换成小模型兜底大模型流量超限时在网关层把部分非核心请求转发给小模型或缓存服务。减少生成长度高峰期动态把max_tokens从2048降到512投递效率影响不大但单请求资源消耗降了一个数量级。启用语义缓存对高频相似请求做embedding检索命中缓存就跳过模型生成。这些降级策略在资源分配优化里经常被忽略但恰恰是它们让服务在“资源不够”时还能维持基本可用性。降级逻辑要提前设计好不是等故障发生再临时写代码那样基本来不及。7. 量化与硬件适配给模型“减重”后资源账本重新算7.1 不同精度的显存占用和精度代价资源分配不只是“管好现有模型”还包括“让模型变得更小”。量化是把模型精度从FP16/BF16压到INT8、INT4甚至是FP8的过程它直接改变资源分配的天花板。这里列一组直观的对比数据以7B模型为例精度格式权重显存KV Cache相对开销质量损失适用场景BF16~14GB基准无高质量离线推理、基座服务FP8~7GB约一半极小权衡型在线服务INT8~7GB约一半较小一般在线服务INT4~3.5GB约四分之一有明显损失低成本高吞吐场景我自己在线上环境用得比较多的是FP8和INT8。FP8在Hopper及更新架构上有原生加速支持质量损失极小几乎是白捡的显存红利。INT4则要谨慎——虽然显存占用低但推理质量下降在复杂推理任务上很直观只适合对结果质量要求不高的场景。7.2 量化与并发、延迟的联动效应量化的意义不止在于“模型塞得下单卡”它会连锁影响并发上限和延迟表现。同一个7B模型在单张H100上BF16权重占14GBKV Cache可用显存约58GB按90%利用率算同时跑32个长上下文请求显存就很紧张。INT8权重降到7GBKV Cache可用显存多了约7GB并发上限提升约20%。INT4权重降到3.5GB单卡甚至可以跑原来近两倍的并发请求。但是要注意量化把权重变小了不等于计算变快了。解码过程依然是带宽密集型INT4虽然能减少显存读取量但在部分硬件上反卷积的额外开销反而会拖慢速度。所以选量化精度不能只看显存报表必须实测每token解码延迟。一个稳妥的建议是先跑量化模型的标准benchmark确认TPOTTime Per Output Token没有恶化再切线上。8. 可观测性建设与资源分配的“复盘闭环”资源分配策略不能“配完就不管”。线上流量、模型版本、请求分布都在变策略必须持续迭代。而这个迭代的起点是可观测性数据。我认为推理服务的核心监控指标至少包含四类吞吐类每分钟请求数、生成token总数、批处理大小分布。延迟类首token延迟TTFT、每token延迟TPOT、端到端延迟的P50/P95/P99。资源类GPU利用率、显存使用率、KV Cache水位、排队等待数。成本类每千token的成本、单位GPU小时的产出token数。这些指标的价值在于联动分析。举个例子如果你看到GPU利用率很高但TPOT却在上涨别高兴太早很可能是批处理过深导致每个token的响应变慢。反过来GPU利用率不高但排队很长说明调度策略或副本数出了问题。只是单看一张图是诊断不出来的必须把延迟曲线、批处理深度、显存水位放在同一条时间线上做“复盘式分析”。我在实践中还有一个习惯每次变更资源分配参数并发上限、并行度、量化精度都会先跑一个固定的压测场景集做A/B对比。场景集包含短请求、长上下文、高并发三类典型负载跑完直接对比TPOT、TTFT和吞吐三个数。改配置靠数据说话不靠“手感”这是资源调优能持续收敛的前提。最后再说一点个人体会。AI模型服务的资源分配策略本质上不是一道“最大并发设多少”的填空题而是一套持续观测、反复调优的动态工程。不同团队卡在最痛点的地方也不一样——有的是显存管理粗糙有的是并行策略选错有的是扩缩容响应不及时。但只要把“账算清楚、调度做细、兜底留好、反馈闭环”这四件事落实到位无论换什么模型、什么硬件这套方法都能复用到新场景上不会过时。