GPU在推理场景下的调度与分配，本质上是围绕显存、算力和时延三者的持续平衡，实用策略是按模型切“算力块”，而非按物理卡切。 先把这一条想清楚,后面的配置与调优才有方向。
为什么GPU节点分配在推理场景如此棘手
训练阶段追求的是把整张卡的算力“吃干榨净”，能跑多大batch就跑多大，推理阶段恰恰相反，在线业务看重P99时延，离线批量任务看重吞吐,两者对调度的要求几乎相反。
显存占用与计算峰值之间的错位
推理时一张卡的显存占用往往很高，但计算单元大部分时间在闲置，原因是权重参数、KV Cache、中间激活层都要驻留显存，而单次请求只触发一次前向计算，计算密度远低于训练，多数情况下，一块80GB显存的A100/H100部署一个7B模型，利用率可能不到30%，这不是硬件不行，而是分配逻辑没把“显存分配”和“算力分配”分开看。
业内专家指出，推理场景的调度瓶颈通常不在GPU算力本身，而在于显存墙和PCIe/NVLink带宽。
GPU节点怎么分配才能不浪费算力
这就引出核心问题：怎样才能让分配方案同时兼顾资源利用率和响应速度，答案是引入细粒度的算力切分,而不是整卡分配。
三种主流切分方式
- MIG（多实例GPU）：把物理GPU切成多个独立实例，每个实例拥有专属显存和计算核心，适合A100/H100等数据中心卡，隔离性强,适合多租户场景。
- 时间片共享：多个推理任务轮流使用整张卡的计算资源，显存共享但算力竞争，适合负载波动大、对隔离性要求低的内部业务。
- vGPU/算力虚拟化：通过软件层把GPU资源抽象成可动态调整的池子，细粒度更高,但会引入少量性能损耗。
实操层面怎么选
- 如果业务方明确要求“互不干扰”，优先MIG,每个实例切分后显存和算力都物理隔离。
- 如果模型较小（如7B以下）且部署密度要求高，优先时间片共享配合进程级显存隔离。
- 如果集群资源池很大、业务多样，用vGPU统一纳管,按需动态扩缩。
分配策略上补一刀
分配后还需要把“显存配额”和“算力配额”分开设置，显存配额决定能放多少个并发请求，算力配额决定每个请求的响应速度，两者耦合分配，容易出现显存够用但算力排队、或者算力空闲但显存不够的尴尬局面。
多卡推理场景下的调度策略对比
当单个模型超过单卡显存容量，就必须走多卡，此时调度问题从“用哪块卡”升级为“怎么组织多块卡”。
张量并行与流水线并行的取舍
- 张量并行：把一层网络切开放到多张卡上，卡间通信量巨大，对NVLink带宽极其敏感，8卡A100的张量并行效率通常低于单卡4倍,通信开销吃掉相当一部分算力。
- 流水线并行：按层切分，卡间通信量小得多，但存在流水线气泡，GPU空闲率上升，适合超大模型,不适合对时延敏感的在线推理。
数据并行与批处理
小模型常用的方式是数据并行，多张卡各部署一份完整模型，请求按负载均衡策略分发，这种方式最简单，但显存利用率最低,因为每张卡都要存一份完整权重。
一张对比表看清选型方向
| 场景 | 推荐策略 | 原因 |
|---|---|---|
| 7B以下模型，高并发在线推理 | 数据并行+动态批处理 | 部署简单，单卡吞吐足够 |
| 13B-70B模型，P99时延要求严格 | 张量并行（2-8卡） | 单请求时延最低，但需高带宽互联 |
| 100B以上模型，离线批量生成 | 流水线并行+微批次调度 | 吞吐优先，时延可以放宽 |
| 混合负载，高峰期突发流量 | vGPU池化+弹性扩缩容 | 资源利用率最高，但需平台支撑 |
从调度到底层算力，谈一谈普惠的推理节点
讨论调度策略的时候，很多团队忽略了一个前置条件：你手上的GPU节点硬件基础是否适配这些策略,这就涉及到选型问题。
推理服务器的硬件配置逻辑
推理不像训练那样“无脑堆算力”,反而要重点看三个维度：
- 显存容量：决定能放下多大模型、多少并发上下文。
- 内存带宽：影响KV Cache读写速度,直接决定解码阶段的速度。
- 卡间互联方式：多卡推理的必要条件，NVLink优于PCIe，PCIe Swtich优于直连。
按预算与场景分层配置
中小团队起步阶段不必追求顶配，
两张性价比更高的卡比一张昂贵旗舰卡更实用，例如部署Qwen2.5-14B这类模型，双卡方案可以走张量并行，成本和单张顶级卡差不多，但能留出更多显存存放长上下文，新建集群时留意下不同地域的管线差异，问清楚本地机房是否支持高功率密度机柜,这直接影响后期扩展难度。
实操：Kubernetes里如何调度GPU推理节点
多数生产环境用K8s管GPU资源,这里说说真正有用的操作细节。
第一步：启用Device Plugin
默认K8s不认识GPU，必须安装NVIDIA Device Plugin，注意开启nvidia.com/gpu.mig支持,这样才能在Pod级别申请MIG切片。
第二步：给节点打上正确的标签
标记节点时不要只写gpu=rtx4090或gpu=a100这种宽泛标签,应该拆细：
gpu-model=nvidia-a100-80ggpu-shared=允许或gpu-shared=禁止gpu-memory=80Gigpu-zone=机房A
有了这些标签,调度器才能做出更优决策。
第三步：设置Pod的显存与算力申请
一个比较推荐的写法是：
- 主容器申请完整的
nvidia.com/gpu: 1 - 用InitContainer做一次探活，确认MIG实例可用后再启动主服务
- 给容器配置足够大的
/dev/shm，否则大batch下容易OOM
第四步：配置动态批处理策略
在推理框架侧（如Triton Inference Server），开启Dynamic Batching,核心参数有三个：
max_queue_delay_microseconds：控制请求等待时间preferred_batch_size：设置目标batch大小max_batch_size：设置上限
动态批处理能直接把GPU利用率拉高一倍以上，但代价是单个请求的时延会小幅上升,需要调参找到平衡点。
业务场景驱动的分配口诀
不同业务对GPU的消耗模式完全不同，一种分配策略很难覆盖所有场景,分开处理更实际。
高并发低延迟场景（大模型API服务）
分配原则是宁拆勿整，把一张A100切成2-4个MIG实例，每实例部署一个低并发副本，前端用负载均衡分发流量，这样可以避免单点热点,一个实例被打满时其他实例还能正常响应。
长文本/大上下文场景（RAG应用、代码分析）
这类业务最大的痛点是KV Cache暴涨。分配时要按上下文长度预留显存，而不是按模型参数大小评估，建议在推理框架里开启PagedAttention或类似机制，把KV Cache按页管理,减少碎片。
批量离线任务（数据处理、评测、批量生成）
这类任务对时延不敏感，适合尽量打满整卡资源，可以把多个离线Job在时间片上混部，白天跑在线服务，凌晨切到离线模式，显存里只保留一个模型,批量数据轮番喂入。
特殊情况预处理
推理前对输入做一次长度裁剪和估算，能帮助调度器更准确地预估显存需求，多数框架支持传入max_tokens预估，调度系统可以据此提前把请求路由到显存余量足够的节点,避免OOM重试浪费算力。
关于GPU节点分配的常见问题
GPU推理节点显存占满了但利用率很低，怎么排查
先看KV Cache是否设置过大，再看动态批处理参数是否生效，用nvidia-smi观察显存占用与SM利用率的时间曲线（可以用nvidia-smi dmon -s pucvmet -d 1持续输出到日志文件），如果SM利用率持续低于40%而显存接近上限,大概率是并发并发度不够或批处理窗口太短。
多卡推理需要多大的卡间带宽才够用
张量并行场景下，每增加一块卡，通信量都会非线性上升，业界共识是至少需要NVLink级别互联，同时注意看NVLink的实际吞吐，例如A100的NVLink带宽在600GB/s上下，但实际吞吐受拓扑结构影响较大，若用PCIe，则基本只能做数据并行或流水线并行,张量并行性能衰减明显。
GPU云服务器价格差异大，低价实例适合做推理节点吗
低价实例通常意味着共享型或上一代芯片，显存带宽和卡间互联较弱，如果模型很小（3B以下）、并发要求不高，低价实例完全够用，但涉及多卡并行或长上下文场景时，低价实例的时间被拉长带来的成本反而可能高于高性能实例，选型时应按“每Token成本”而非“每小时价格”衡量性价比。
回到最开始那句话，推理场景里的GPU调度与分配，核心不在“分卡”而在“分能力”，显存配额、算力配额、卡间互联带宽、节点拓扑位置，都是决定推理服务质量的变量，把分配粒度从“物理卡”下钻到“算力切片”，再结合动态批处理与场景化配置,资源利用率与业务稳定性自然能同时拿住。