Solarex搞AI推理的人，多少都经历过这种场景：模型在单卡上跑得挺欢，一上生产就卡成幻灯片；显存看着够用，并发一上来直接OOM；四张卡摆在那儿，一查利用率不到30%。我花了不少时间专门折腾推理侧的GPU调度，从底层CUDA特性到上层服务框架都摸过一遍，这篇文章把核心思路和能直接落地的方案整理一下，给正在做推理服务优化、模型部署的同行做个参考。
先说结论：推理场景下的GPU调度优化，和训练完全是两码事。训练追求的是把GPU算力吃满，吞吐越大越好；推理拼的是延迟和成本的平衡，你既要让单次请求足够快，又要在有限的显存里塞下尽可能多的并发，还得处理不同模型、不同大小请求带来的碎片化问题。这里面的核心矛盾，在于GPU资源怎么分配、怎么复用、怎么在请求级别做切分。
1. 推理场景下GPU到底在忙什么：先搞清瓶颈在哪
很多人一上来就调框架参数，结果改了半天没效果，原因在于根本没看清推理请求在GPU上的真实执行路径。推理和训练不一样，训练是成批的数据灌进去，权重更新是固定的迭代模式；推理则是单个或多个请求进来，走一遍前向传播，输出结果返回。这导致GPU在推理时的利用率天然就上不去，尤其是小batch请求，kernel启动开销、显存带宽、算子调度延迟占比非常高。
1.1 为什么推理的GPU利用率普遍偏低
打个不严谨的比方：训练像是装满货物的重卡在高速上跑，载荷大、路线固定、引擎效率高；推理更像是出租车跑市区，走走停停，每单就拉一两个人，时间都花在等红灯和起步上了。
放到GPU上具体拆解，主要有三个原因。第一个是kernel启动开销，PyTorch默认的CPU侧调度会让每个GPU kernel都有微秒级的启动延迟，请求量小的时候，这部分延迟能占到端到端的30%以上。第二个是显存带宽的瓶颈，推理主要是访存密集型操作，尤其是Decoder阶段，每次只生成长度有限的token，但模型权重和KVCache都得从显存里过一遍，带宽不够，算力再多也是浪费。第三个是请求间的资源争抢，多个并发请求如果没有统一调度，很容易互相挤占显存带宽和SM资源，谁都快不了。
我早期优化的一个项目，刚开始看nvidia-smi，GPU利用率有80%多，以为优化空间不大了，后来用NVIDIA Nsight一测才发现，SM的活跃计算占比其实不到40%，大量时间花在数据搬运和kernel等待上。优化显存访问路径之后，单卡吞吐直接翻了一倍还多。
1.2 推理优化的核心指标：吞吐、延迟、显存的三方博弈
推理GPU调度优化，始终是在三件事之间找平衡：吞吐量（Throughput）、延迟（Latency）和显存占用（Memory Footprint）。这三者通常是互斥的，你不可能同时做到极致。
| 指标 | 追求方向 | 典型代价 |
|---|---|---|
| 吞吐量 | 每秒处理的请求数最大化 | 单请求延迟上升，显存占用增加 |
| 延迟 | 单请求响应时间最小化 | batch size受限，吞吐下降 |
| 显存占用 | 单卡承载更多模型和并发 | 需要量化/切分，精度和速度受影响 |
实际业务里，这三者的优先级由场景决定。像实时对话助手，延迟是生命线，你不可能因为要提吞吐就把batch塞到128，用户等不了；像离线批量分析、内容审核这类，延迟要求低，可以放心开大batch冲吞吐。
所以做GPU调度优化，第一步不是调参，是明确业务指标：P99延迟红线是多少？单卡QPS需要到多少？模型数量有多少、模型切换频繁吗？这些答案决定了后续所有的技术选型。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. GPU环境搭建与验证：地基打不稳，后面全白搭
调度优化跑在GPU环境之上，但环境本身就有很多坑。我在多台服务器上配过CUDA、PyTorch、容器环境，踩过的坑能列一长串，这里说几个和调度优化直接相关的。
2.1 CUDA、驱动、PyTorch的版本匹配陷阱
GPU环境最让人头疼的就是版本匹配问题。很多人装完PyTorch发现跑不了，第一反应是代码写错了，其实八成是CUDA版本和显卡驱动版本对不上。
先记住一个结论：显卡驱动决定CUDA运行时的上限，PyTorch内置的CUDA runtime只要不高于驱动的最大支持版本就行。也就是说，更新驱动能向下兼容旧版CUDA，但反过来不行。
具体到安装流程，我的建议是这样的：
- 先确认显卡型号和驱动版本，用
nvidia-smi查看右上角的CUDA Version，注意这里显示的是驱动支持的最高版本，不代表你环境里实际用的版本。 - PyTorch的安装。到PyTorch官网选对应CUDA版本，比如当前常用的是cu118、cu121、cu124。选择标准是：你的驱动版本必须大于等于这个CUDA版本号。
- 装完验证。这时不要急着跑模型，先跑个小例子确认GPU真的能用：
python复制import torch
print(torch.__version__)
print(torch.cuda.is_available())
print(torch.cuda.device_count())
print(torch.cuda.get_device_name(0))
如果cuda.is_available()返回False，最常见的原因是驱动版本太老，或者PyTorch的CUDA版本和驱动不兼容，而不是显卡坏了。
有个很容易踩的坑：torch.cuda的显存分配用的是caching allocator，也就是PyTorch默认会缓存显存块，不立刻释放给其他进程。当你用多进程跑推理时，明明某个进程任务结束了，nvidia-smi里显存还是被占着，这不是泄漏，而是PyTorch故意为之，为了下次分配更快。处理方式是在进程退出前调torch.cuda.empty_cache()，或者设置环境变量PYTORCH_CUDA_ALLOC_CONF=backend:cudaMallocAsync换用异步分配策略。
2.2 多GPU环境下的显存可见性与调度初始验证
服务器上插了多张卡，第一件事不是直接跑模型，而是搞清楚系统能看到几张卡、每张卡的状态如何。推荐几个排查命令：
bash复制# 查看GPU整体状态，包括利用率、显存、温度、功耗
nvidia-smi
# 实时刷新查看
watch -n 1 nvidia-smi
# 查看GPU拓扑，确认NVLink/NVSwitch连接方式
nvidia-smi topo -m
nvidia-smi topo -m这个命令容易被忽略，但对多卡调度特别重要。它会显示GPU之间的连接方式，是NVLink直连、PCIe交换机还是走CPU。多卡做张量并行（Tensor Parallel）时，卡和卡之间的通信带宽直接影响推理性能，如果两张卡之间走的是PCIe而非NVLink，那么TP的通信开销可能大到你怀疑人生。
验证完多卡可见性，接着做一个小测试：分别在不同GPU上跑同一个模型，对比延迟和吞吐差异。实操时我用过一段简单的脚本，循环指定cuda:0、cuda:1、cuda:2，观察各自的执行时间。有时候同一批卡，因为散热位置、供电设计不一样，性能会有几个百分点的差异，调度策略如果能感知到这种差异，可以把高负载请求优先调度到性能更好的卡上。
另外，如果机器上装了容器环境，比如Docker或者Kubernetes，GPU的透传方式也影响调度。默认的--gpus all是直接把整卡透传给容器，简单粗暴，但一个容器占一张卡，没法做更细粒度的共享。想实现多个推理服务共享一张卡，需要用NVIDIA MPS（Multi-Process Service）或者CUDA MPS，后面章节详细讲。
3. 显存切分与模型加载：把资源用干净的底层功夫
GPU调度优化的第一个层面，是让显存和算力真正被"用干净"。这里包括模型本身的显存占用、推理过程中的中间激活值，以及最关键的自回归生成带来的KVCache增长。
3.1 模型显存占用的精确计算
模型加载到GPU上，显存主要花在三个地方：权重参数、优化器状态（推理时不需要但框架可能默认带上）、KVCache和激活值。以前碰到过一个案例，一个7B模型，FP16精度下权重占用大概14GB，但有人告诉我他用一张24GB的卡跑不起来，怀疑是显存不够。后来排查发现，问题出在模型加载时没有切到推理模式，PyTorch默认保留了梯度计算相关的中间结果和CUDA缓存，白白多了好几个GB。
精确控制模型显存的方法有两个。第一个，加载后立刻调用model.eval()并包裹推断模式：
python复制model.eval()
with torch.no_grad():
output = model(input_ids)
第二个，如果用了Hugging Face Transformers，直接指定torch_dtype=torch.float16，把模型从FP32（约为FP16两倍显存）降到FP16。
权重占了显存的头一大块，推理时的动态增长则主要来自KVCache。自回归模型每生成一个token，都需要把之前的Key和Value缓存下来，这个缓存随序列长度线性增长。以7B模型为例，层数32、注意力头数32、头维度128，batch为1、序列长度2048时，KVCache的显存占用大约是32×32×128×2（Key和Value）×2字节×2048，算下来约1GB左右。别看单个请求不多，并发进来几十个，这就是几十GB的增量。
3.2 推理部署中打破显存瓶颈的实用手段
显存不够，常规思路是加卡，但更聪明的做法是在调度层面把显存用好。
第一招是torch.compile。PyTorch 2.0之后的编译模式，不仅加速计算，还能减少内存分配和释放的开销。实测在LLM推理场景下，模型编译后显存峰值能降10-20%，同时吞吐提升20-30%。代价是首次运行需要几秒到几十秒的编译时间，服务启动变慢，可以在部署时预热。
第二招是模型量化。把FP16的权重压成INT8甚至INT4，显存直接砍半或砍到四分之一。对大多数推理场景，INT8量化精度损失很小，INT4结合AWQ、GPTQ这类算法也能控制在可接受范围内。vLLM原生支持这些量化格式，加载时指定对应参数即可。
第三招是更激进的：使用torch.cuda.memory_stats()接口，在运行过程中监控显存分配情况，找出哪个环节分配了不该分配的显存。我曾经用这个方法，发现某个开源的推理框架在每次请求时都会重新分配激活缓冲区，而不是复用已有的，导致高并发下显存峰值飙高。定位之后改成预分配缓冲区池，显存占用从19GB降到15GB左右，效果很明显。
这些手段解决了单卡显存问题，但模型更大或者并发更高时，单卡怎么都不够，这时候就要上多卡方案了。
4. 多卡推理的切分策略：TP、PP、DP各自适合什么场景
多卡推理的调度，本质是把一张卡放不下的模型拆开，或者把流量分到多张卡上。选择哪种切分方式，取决于模型大小、卡间带宽和延迟要求。
4.1 三种并行策略的对比与选择逻辑
| 并行策略 | 原理 | 适合场景 | 关键限制 |
|---|---|---|---|
| 数据并行（DP） | 每张卡放完整模型副本，请求分发到不同卡 | 模型单卡能放下，需要横向扩展吞吐 | 需要同步或异步梯度/结果聚合 |
| 张量并行（TP） | 把每层的权重矩阵切分到多张卡，协同计算同一层 | 单卡放不下的大模型 | 卡间通信量巨大，需要NVLink |
| 流水线并行（PP） | 按层切分，卡1算前几层，卡2算中间层，卡3算后几层 | 超深模型，但GPU间通信带宽有限 | 存在流水线气泡，利用率不饱和 |
训练场景中，这三者可以叠加使用（3D并行），但推理场景的选择逻辑不一样。推理时我们以延迟为主，PP会引入串行依赖，请求要依次经过所有卡，延迟差不多等于所有段时间之和，不太划算。DP的问题在于每张卡都放全量模型，显存成本随并发卡数线性增长。
因此推理场景下，TP是主流选择，尤其对于单卡放不下的模型。以常见的7B、13B模型为例，两张80GB的A100/H100（或者4090做低成本推理）用TP=2切分后，延迟通常比单卡多不到10%，但可以承载单卡放不下的模型。对于70B级别的模型，TP=4甚至TP=8也常见，前提是卡间有NVLink。
4.2 大模型推理框架的并行配置实操
现在做LLM推理，基本不会手写并行逻辑，直接用vLLM、TensorRT-LLM、SGLang这些框架就行，它们内置了TP和调度能力，比自己造轮子靠谱得多。
以vLLM为例，多卡推理的启动方式很简单：
bash复制# TP=2，两张卡跑一个7B模型
python -m vllm.entrypoints.openai.api_server \
--model /path/to/model \
--tensor-parallel-size 2 \
--gpu-memory-utilization 0.9 \
--max-num-seqs 256
这里面有个关键参数--gpu-memory-utilization，默认值是0.9，意思是vLLM会预留90%的显存用来做KV Cache池和推理缓冲。如果你要跑的服务还有其他显存需求，或者希望给系统留更多余量，需要手动调低。
另一个容易忽略的是--max-num-seqs，这决定了最多并发多少个序列共享一张卡。设置太小，并发上不去，GPU利用率低；设置太大，每个请求都要等别人的KVCache释放，延迟和OOM风险都上升。我的建议是先从64开始压测，观察显存和延迟曲线，再逐步上调到128、256，找到拐点。
TensorRT-LLM的话，优势是推理速度极致，但构建engine的过程比较繁琐，需要先把PyTorch模型转换成ONNX再编译成TensorRT engine。它提供的in-flight batching（飞行中批处理）功能，在动态请求调度上比vLLM更灵活，适合对性能要求极高的场景。用之前要确认GPU型号在官方支持列表里。
4.3 NVIDIA MPS：多服务共享GPU的关键技术
很多人不知道NVIDIA官方的MPS（Multi-Process Service），它允许不同的进程共享同一块GPU。默认情况下，GPU是被独占的，哪怕一个进程只用了一小块显存，其他进程也无法抢占剩余资源。MPS把CUDA kernel的执行从多个进程合并成单个上下文，这样多个推理服务可以共享同一GPU的算力和显存，利用率大幅提升。
正常情况下，用nvidia-smi能看到的进程限制其实很少，但MPS能让显存分配更灵活。要在容器里启用MPS，可以参考以下步骤：
bash复制# 在宿主机上启用MPS控制守护进程
nvidia-smi -pm 1
nvidia-smi -am 1
mkdir -p /tmp/nvidia-mps
export CUDA_MPS_PIPE_DIRECTORY=/tmp/nvidia-mps
export CUDA_MPS_LOG_DIRECTORY=/tmp/nvidia-mps
nvidia-cuda-mps-control -d
之后每个容器里只要设置了相同的两个环境变量，就能加入同一个MPS共享域：
bash复制export CUDA_MPS_PIPE_DIRECTORY=/tmp/nvidia-mps
export CUDA_MPS_LOG_DIRECTORY=/tmp/nvidia-mps
MPS的典型使用场景是：一张A100，跑一个小的推理服务只用了30%的算力，剩余70%浪费。用MPS把两三个模型服务都挂上去，让它们共享这张卡，实际效果可以把整体利用率提到80%以上。但MPS也有局限，比如显存是共享的，单进程OOM可能影响其他进程；不同进程的kernel调度有额外开销，不是所有场景都能线性增益。
5. 动态批处理与调度队列：让GPU吃满的关键设计
很多推理服务的GPU利用率上不去，根本原因不是GPU慢，而是请求到达的模式和GPU的执行模式不匹配。推理请求是稀疏的、随机的，GPU是批处理的、密集的，两者之间需要一个"蓄水池"来缓冲，这就是调度队列的职责。
5.1 Continuous Batching范式：传统批处理的重大改进
传统的静态批处理是收集一批请求，等凑够数量再统一推理。缺点很明显：如果请求来得慢，系统就一直空等；如果请求大小差异大，大请求会把整批的完成时间拖成最慢的那个，后面所有小请求都跟着遭殃。
现在的LLM推理框架普遍采用Continuous Batching（连续批处理），核心思路是：不再以"整批完成"为单位，而是以"每个token生成"为单位。某个请求的某个token生成完了，它就从当前batch中移出，新来的请求立刻补位，不需要等整个batch结束。
用大白话说：以前是班级统一放学，大家必须一起走；现在是每个学生写完作业就自己回家，教室随时有新的学生进来坐下。
vLLM的PagedAttention就是围绕这个思想设计的。它还借鉴了操作系统的虚拟内存分页机制，把KVCache分成固定大小的块，按需分配给请求，减少显存碎片。实测中，Continuous Batching能让GPU利用率提升2-4倍，这是推理框架能配得上"调度调度优化"这个说法的核心原因之一。
5.2 调度策略的层次：从请求排队到优先级的完整链路
完整的推理调度链路分为三层，每一层都有对应的优化手段：
第一层是请求级别的排队策略。进入推理服务的请求先放进队列，队列的长度和排序方式直接影响响应时间。常见的做法是设置最大队列长度，超过长度直接拒绝或返回降级响应，保护后端不被冲垮。排序方式可以按FIFO，也可以按请求的优先级（如付费用户优先）或超时剩余时间。
第二层是连续批处理的调度窗口。框架从队列里取请求填充当前batch时，不是随便取的。vLLM内部的Scheduler会预估每个请求未来的KVCache占用量，以及当前GPU还剩余多少可用KV块。如果某个请求太大、剩余块不够，就先跳过它，让后面的小请求先跑。这个机制叫preemption，有swap和recompute两种处理方式：swap是把KVCache换到CPU内存，recompute是丢弃已有结果重新计算，两种都有额外开销，所以调度器会尽量避免preemption发生。
第三层是GPU执行层面。这一步由CUDA Graph等技术来做进一步优化，把多个kernel融合起来，减少启动开销。vLLM的--enforce-eager参数如果设成False，默认会用CUDA Graph捕获推理过程，实测能减少30%的kernel启动时间；代价是显存占用会多一些。
5.3 调度参数调优的经验值参考
以下是基于我在多个生产项目里调出来的相对稳妥的参数范围，具体值还是要以自己环境的压测数据为准：
| 参数 | 参考范围 | 调优目标和注意点 |
|---|---|---|
| max-num-seqs | 64~256 | 并发序列数，太大延迟上不去，太小GPU吃不饱 |
| max-model-len | 2048~8192 | 最长序列长度，撑大了KVCache占用会涨，撑小了长文本被截断 |
| gpu-memory-utilization | 0.85~0.95 | 显存缓存池占比，留出余量给CUDA Graph和碎片 |
| max-num-batched-tokens | 4096~16384 | 单次迭代最多处理的token数，影响吞吐和延迟均衡 |
| block-size | 16~32 | KV块大小，16更省显存，32分配更快 |
这些参数不是越大越好，也不是越小越好，要在压测中用不同的负载模式去验证。注意，单一benchmark工具（如简单的wrk压测）生成的请求模式可能和生产环境差异很大，最好直接从线上流量中录制回放，或者模拟出真实的长尾分布。
6. 实战中的性能压测与问题定位：优化得有自己的数据闭环
调度优化做得对不对，不能靠感觉，要有一整套压测和可观测体系。我这几年最深的体会是：没有数据闭环的优化是伪优化，优化完没压测验证等于没优化。
6.1 压测工具选型与压测方法
推理服务压测和普通Web服务压测不太一样，不能用简单的请求成功率来衡量，要关注token级别的吞吐和延迟。推荐几个工具：
- vLLM自带benchmark：
benchmark_serving.py脚本，模拟OpenAI API请求，输出TTFT（首个Token生成时间）和TPOT（每个输出Token生成时间），是最快的上手方式。 - Locust + 自定义client：如果想模拟更复杂的并发模式，比如用户先连上、Think几秒、再发下一个请求，用Locust写自定义负载脚本更灵活。
- perf(1) + NVIDIA Nsight Systems：前者看系统级指标，后者看GPU kernel级别的时间线，用于定位瓶颈是CPU侧调度还是GPU侧执行。
压测时重点关注四个指标：TTFT、TPOT、P99端到端延迟、吞吐（tokens/s）。其中TTFT对交互式体验影响最大，TPOT影响输出流畅度，二者要分开看。一个典型的优化前后对比表格如下：
| 指标 | 优化前 | 优化后 | 变化 |
|---|---|---|---|
| QPS（吞吐） | 120 | 320 | +167% |
| TTFT P99 | 420ms | 280ms | -33% |
| TPOT P99 | 180ms | 120ms | -33% |
| 显存峰值 | 17.5GB | 14.8GB | -15% |
6.2 GPU Crash Dump：一类容易忽略的严重问题
多卡推理时，我遇到过一个非常隐蔽的问题：负载压到某条线后，某个GPU进程突然崩溃，日志里出现gpu crash dump triggered。这个提示的意思是NVIDIA驱动检测到了GPU的异常状态，把它记录了下来，可能是驱动bug、显存ECC错误、或者显卡硬件不稳定。
处理这个问题，我的排查路径是：
- 用
nvidia-smi -q -d ECC查看显存ECC错误计数，如果SEC（单比特纠错）错误持续快速增长，说明这块卡的显存颗粒可能开始出现老化。 - 用
nvidia-smi -q -d PAGE_RETIREMENT查看是否有显存页面被自动退役。显卡驱动有一定容错能力，但经常出现PAGE_RETIREMENT说明硬件健康状况堪忧。 - 如果排除了硬件问题，就往软件方向查：驱动版本是否是已知有bug的版本、CUDA版本是否匹配、PyTorch是否用了不稳定的CUDA kernel。
这类问题最容易在压测跑满显存和算力时暴露，平时低负载根本发现不了。所以我的压测流程里永远有一个超负荷测试环节：把并发拉到正常峰值的1.5到2倍，跑10-30分钟，专门看稳定性和崩溃问题。如果在这个环节出现gpu crash dump, 那这块卡或者这个环境是不能上生产的。
6.3 定位调度瓶颈的实战排查链路
当系统延迟变高或者吞吐不达标，排查顺序从外到内，我总结为五步：
- 看GPU利用率。如果利用率低（低于50%），说明请求喂不饱GPU，瓶颈在队列、网络或者CPU侧的前置处理。检查CPU核数是否够、请求预处理是否有锁竞争、网络IO是否有阻塞。
- 看显存分配情况。如果显存接近上限，同时出现OOM或者无限排队，说明KVCache池不够大，需要调整gpu-memory-utilization或者减少max-num-seqs。
- 看kernel时间线。如果GPU利用率不低但延迟很高，用NVIDIA Nsight抓一下kernel执行时间线。如果kernel之间有大段空白，说明CPU侧launch kernel的速度跟不上GPU执行速度，可以用CUDA Graph把整个推理图捕获下来一键执行，减少launch开销。
- 看CPU和GPU的交互。用
nvidia-smi的Process ID列，找到具体是哪个进程在占用GPU，再配合top -H -p <pid>看这个进程下哪些线程在跑。推理框架的调度线程如果被频繁抢占或者CPU限流，GPU再强也是白搭。 - 看多卡通信。TP模式下，卡间通信如果走PCIe而不是NVLink，通信时间会占整个迭代的30%以上。用
ncu --metrics看通信kernel的耗时，如果占比过高，要么调整TP大小，要么换卡间拓扑更好的机器。
这套排查链路基本能覆盖90%以上的推理服务性能问题，每一步都有对应的数据指标支撑，不会像无头苍蝇一样乱试。
6.4 不同框架的调度行为差异
vLLM和TensorRT-LLM在调度机制上有些差别，用的时候要注意。vLLM的调度器更偏向通用的动态性，支持连续批处理和抢占，同时支持多模型混合调度（MMDispatcher）；TensorRT-LLM则更强调性能的固化，用in-flight batching + CUDA Graph模板，调度决策在engine compile阶段就固化下来。
体验上的差异是：vLLM改配置即生效，适合快速迭代和实验；TensorRT-LLM的engine编译时间长，但一旦编译好，单请求延迟和吞吐都更稳定。如果生产环境模型不常变、追求极致性能，TensorRT-LLM更合适；如果模型频繁更新、需要弹性调度，vLLM更顺手。
另外提一句SGLang，它引入了RadixAttention机制，能复用前缀的KVCache。如果业务里有大量共享前缀的请求，比如系统提示词很长、多轮对话历史相似，SGLang的缓存命中能大幅降低延迟和算力消耗。这类场景优化空间巨大，有类似需求的值得试试。
7. 针对热门推理场景的专项优化：对话、批量、长文本分类施策
GPU调度优化不能一套方案打天下，不同推理场景的负载特征差异非常大，需要区别对待。我按实际业务里最常见的三类场景拆开讲。
7.1 对话/交互式场景：延迟优先，别为吞吐牺牲体验
对话场景的典型特征是：请求到达随机、并发峰值不可预知、用户对首个token的等待极其敏感。这种场景下，TTFT超过1秒用户就会觉得卡，超过3秒基本要流失。
优化重点放在三个地方：
- 持续批处理开启，保证新请求能快速插入正在执行的batch，不用等轮次。
- KVCache池预留足够大的空闲块，避免因为显存碎片导致新请求排队等待旧请求释放缓存。vLLM的
--max-num-seqs适当调小一点，让单次batch不要太大，减少长尾等待。 - 配合容量管理：设置并发上限，超过上限走排队或降级（比如走一个更小的蒸馏模型），绝不让GPU过载后所有请求一起遭殃。实测中，给在线推理服务加一层简单的令牌桶限流，P99延迟能从800ms降到400ms左右，代价是少数请求被排队。
另外，对话场景中模型输入输出的长度变化极大。有的请求几句话就完事儿，有的请求要生成几千个token。调度器对这两类请求的处理策略应该不一样：长输出请求执行时间久，如果一直占着batch位置，会把后面短请求的延迟拖垮。此时的调度策略是给长输出请求单独分配batch或优先级，或者限制最长生成token数，宁可截断也不能让它的"马拉松"影响全局。
7.2 离线批量推理场景：吞吐优先，最大化GPU饱和
离线批量推理包括内容审核、文档解析、批量文本生成、向量化等任务。这类任务没有在线延迟压力，追求的是单位时间处理最多的请求，GPU利用率越高越好。
优化策略几乎是反过来的：
- batch size拉到尽量大，max-num-seqs可以调到256甚至更高，让GPU的SM满负载运行。
- 关闭不必要的抢占和preemption机制，减少调度开销。既然都是离线任务，让每个请求把KVCache跑完再撤，比频繁打断切换更高效。
- 用更大的
--max-model-len，避免长文本被截断，因为离线任务对完整性要求高。 - 可以结合多个GPU做数据并行，每个GPU独立处理一批请求，互不干扰，整体吞吐线性扩展。这比TP更省事，因为离线任务不需要单卡承载超大模型。
离线批量推理场景还有一个隐藏优化点：请求的预处理和结果后处理通常很耗时，如果放在GPU侧做，会白白浪费GPU算力等CPU。最稳妥的做法是把前后处理拆成独立阶段，或者用异步流水线把CPU和GPU的工作重叠起来，让GPU只管计算，CPU只管搬数据。
7.3 混合负载场景：如何用调度器隔离不同业务
日常生产环境里，在线服务和离线任务往往是跑在同一批GPU资源上的。在线服务吃不满GPU，离线任务就填进来吃剩余算力，这是提高资源利用率的常见做法。但混合负载也容易互相干扰，离线任务的大batch请求如果把显存和算力吃满，在线服务的延迟就会剧烈抖动。
要想控制这种干扰，有几个思路：
- 在NVIDIA MPS层对显存和SM做硬隔离，不同进程分配不同比例的GPU资源。
- 用Kubernetes + 设备插件，给不同推理服务设置不同的GPU显存配额和算力配额。vLLM等框架也能通过环境变量
CUDA_VISIBLE_DEVICES控制在哪些卡上运行。 - 设置服务的优先级，在线服务优先使用GPU资源，离线任务在资源不足时挂起等待。这个需要上层的任务调度器配合，比如Volcano调度器就支持优先级抢占。
我的实践经验是：混合负载至少要做到进程级别的资源配额，否则一旦离线任务跑起来，在线P99延迟从300ms跳到1.2s是完全可能发生的。先做隔离，再做共用，顺序不能反。
8. 从手动调度到自动调度：Operator化和云原生化方向
推理GPU调度优化做到一定阶段，单机手动调参数已经不够用了，要考虑把调度逻辑自动化、平台化。这也是NVIDIA GPU Operator、KuberSnetes生态在AI推理领域越来越重要的原因。
8.1 GPU Operator的价值：驱动和调度器的标准化
NVIDIA GPU Operator是NVIDIA官方提供的Kubernetes扩展，它的主要价值是把GPU驱动的安装和容器环境的配置全部容器化、自动化。用过的人都知道，以前每台GPU节点都要手动装驱动、装Container Toolkit，换一个驱动版本要挨个节点更新，非常痛苦。GPU Operator把这些全部做成了DaemonSet，节点加入集群后自动部署驱动和配套组件，版本管理也简单多了。
对于调度优化来说，GPU Operator带来的最大变化是引入了时间切片（Time Slicing）和MIG（Multi-Instance GPU）两种GPU共享方案。时间切片是一个GPU在不同时间片给不同Pod用，部署灵活但性能隔离较弱；MIG则是把物理GPU切成多个隔离的GPU实例，每个实例有独立的显存和计算资源，性能隔离性好很多，但支持MIG的GPU型号有限（A100、H100等）。
用GPU Operator + MIG，就可以实现真正的"显存和算力按需分配"：一个推理服务分20%算力、另一个分40%，互不干扰。这在多模型共存的场景下是很大的调度优化空间。
8.2 调度器的演进与弹性扩缩容
有了自动化的驱动管理和GPU共享能力，剩下的就是调度策略本身。Kubernetes默认的调度器对GPU资源调度其实比较粗放，它只关注nvidia.com/gpu这个资源数量，没有更细粒度的感知。想做更精细的调度，要用GPU感知的调度插件，比如NVIDIA K8s Device Plugin、HAMi、Volcano等。
HAMi是我自己用过的一个方案，它能对GPU做显存级别的切分和调度，多个Pod可以共享一张卡，同时每个Pod可以设定显存上限。相比原生方案，GPU利用率能提升不少。它同时支持在容器里看到虚拟化的GPU显存和算力状态，对多团队共享GPU集群的场景非常实用。
在弹性扩缩容方面，HPA（Horizontal Pod Autoscaler）配合自定义指标（如队列长度、GPU利用率、请求延迟）可以实现推理服务的自动扩缩容。流量高峰自动扩容更多推理Pod，低谷自动缩容省钱。这套机制跑起来后，GPU资源池的利用率能从30%左右稳定提到60%以上，节省的成本相当可观。
8.3 多租户模型管理：从技术调度走向平台能力
当GPU资源池不可控、模型服务越来越多，调度的核心矛盾从"怎么把单个模型跑快"演变成了"怎么在多个模型之间动态分配资源"。这时候就需要一个模型管理平台层面调度层了。
我自己搭过一套多模型推理平台，整体架构大致是：GPU集群层 -> 推理框架层（vLLM/SGLang/TensorRT-LLM）-> 模型路由层 -> 业务接入层。模型路由层根据请求的目标模型、实时负载、GPU健康状态做路由，把流量导到合适的推理实例上。模型实例做池化部署，多个模型实例在后台复用同一个GPU资源池，请求量上来时自动把闲置实例销毁、换成热门模型实例。
这套架构跑起来之后，资源利用的灵活度远超一台服务器一个模型的做法。某个模型流量突然暴涨，平台可以在几分钟内把其他低负载模型的GPU资源重新分配给热点模型，而不是像以前那样只能干瞪眼等着新机器上线。调度优化从单机维度上升到了平台维度，这也是AI基础设施成熟的方向之一。
9. 框架选型与部署架构：最终还是要落到实际生产
优化方案的最终落地，离不开框架和部署形态选择。这里结合我自己的实践经验，给一些具体的建议。
9.1 vLLM、TensorRT-LLM、SGLang的选型对比
| 框架 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| vLLM | 集成度高、支持多模型、配置简单 | 性能上限略低于TensorRT-LLM | 大多数生产推理服务首选 |
| TensorRT-LLM | 极致推理性能、显存利用率高 | engine编译复杂、模型更新成本高 | 对性能和吞吐要求极高的场景 |
| SGLang | 前缀KV缓存复用、调度灵活 | 生态相对较新、部分模型支持不全 | 长系统提示词、多轮对话、共享前缀场景 |
我的建议是：如果团队还在摸索阶段，直接上vLLM，别浪费时间在底层优化上；如果已经稳定跑了一段时间、对性能有明确痛点，再评估TensorRT-LLM迁移；如果业务有明显的前缀复用特征，把SGLang纳入对比测试是一个明智的选择。
9.2 小模型与轻量化模型的调度特色
不是所有推理都是大模型，小模型（几百MB到2B以下）的调度逻辑其实不同。小模型单卡能放下，显存不紧张，瓶颈主要在CPU侧的数据处理、请求调度和GPU kernel launch开销。
小模型推理优化的重点：
- 尽可能用更大batch，因为小模型单请求GPU算力消耗小，batch越大吞吐越高。
- CUDA Graph的价值比大模型更明显，kernel launch的开销占整个执行时间比例更高。
- 如果部署环境是CPU+GPU混合的，可以考虑用GPU跑计算密集的部分、CPU跑其他逻辑，或者干脆用小模型的CPU量化版省掉GPU卡。
- 多个不同的小模型可以共用一个GPU进程，用加载/卸载（load/unload）策略做切换，不必每个模型独占一张卡。
9.3 部署形态的取舍：裸机、Docker还是Kubernetes
部署形态直接决定调度优化的半径。简单说：
- 裸机直接跑：适合单机单模型的极简场景，调度手段只有进程级的CUDA_VISIBLE_DEVICES，扩展性最差。
- Docker单机模式：适合单机多服务，配合MPS能实现GPU共享，环境隔离性好，部署简单。实测中，这已经能覆盖大部分中小团队的需求。
- Kubernetes集群模式：适合模型数量多、资源池大、需要自动扩缩容的团队。调度层面可以上设备插件、GPU Operator、HAMi等，弹性能力最强，但运维成本也最高。
我见过不少团队从裸机直接跳到Kubernetes，结果运维成本暴涨，反而不如先用Docker+MPS把单机利用率做上去。调度优化应该以业务规模为锚，不要为了技术炫技而上过重的基础设施。小规模时用Docker和MPS，省心又省力；规模真起来了，再平滑过渡到Kubernetes。
9.4 推理服务的性能基线建立与持续优化
最后分享一个非常重要但很多人忽略的环节：性能基线的建立。我要求自己管理的每个推理服务，上线前都必须有一套完整的基线数据，包括不同并发下的吞吐、延迟分位数、显存峰值、错误率。有了基线，后续任何一版代码改动、任何一次配置变更，都拿新数据和基线做对比，是变好还是变坏一目了然，而不是凭感觉说"好像变快了"。
建议把基线数据和压测脚本纳入CI/CD流程。每次代码合并前自动跑一轮小型压测，数据异常直接拦截合并。这套机制帮我避免过至少三次"看起来小改，实际上性能回退20%"的事故。推理性能优化不是一次性的工作，而是一个持续迭代、不断验证的过程。
从底层CUDA环境搭起，到切分策略、调度队列、框架选型、平台化，每一步都有很多细节。文章里说的这些方法，大多是我在生产环境里实际验证过的，但具体数值因模型、显卡、业务流量模式而异，一定要在自己的环境里压测验证后再批量推广。希望这些经验能帮你少走一些弯路。