先把结论放在前面AI模型的推理阶段算的不是“模型调得有多好”而是“一秒钟能同时喂饱多少请求、每个请求愿意等多久”。我最近帮某开发团队优化一个线上推荐模型推理服务现象很典型——GPU利用率常年只有20%上下业务高峰期却频繁超时P99延迟飙到让人不敢看。调方案、加并行、扩机器都试过最后发现卡点根本不在模型本身而在计算资源分配策略上。这篇内容我会从资源分配的几个核心矛盾讲起再拆解动态批处理、显存预算、冷热池调度这些具体策略最后附上可以直接抄作业的落地步骤和排查记录。很适合正在做模型部署、推理服务优化或者被“GPU那么贵利用率却上不去”折磨的工程同学参考。1. 资源分配这件事到底在优化什么先说一个最常见的认知误区很多人把推理性能差归结为“模型太慢”或者“卡不行”但大多数情况下模型本身算得快是你的资源分配策略把算力白白浪费了。1.1 训练和推理的资源需求完全不是一回事模型训练的核心诉求是“把大型批次数据尽快喂给GPU算梯度”它可以容忍排队——因为训练任务不在乎单条数据多久返回只要总吞吐高就行。训练时的资源分配策略通常是“能塞多少塞多少尽量打满显存和计算单元”。推理正好相反。每一次请求都是一个在线用户伸着脖子等你返回结果。资源分配的核心矛盾变成了有限算力下同时跑多少请求才不互相踩脚。每个请求能容忍的等待时间有多长。GPU有几个计算核心、多大显存带宽能支撑多大并发。组合起来就是给定QPS、延迟目标、GPU预算求出最优的“并发路数批次大小显存预留”组合。这个组合一旦选错就会出现“卡看起来没闲着但实际大量算力浪费在小矩阵碎片上”和“单请求响应快但一打并发立刻超时”这两种极端。1.2 先看清你手里的牌算力、显存、带宽三个维度推理资源分配策略不是凭空想出来的它受三个硬指标约束。算力TOPS/FLOPS决定一秒钟能做多少次矩阵乘法。这个数字不是瓶颈因为绝大多数模型的推理计算量并没有把GPU的流处理器喂满。显存容量决定你肚子里能装多少“中间状态”。推理过程里最吃显存的不是模型权重而是KV Cache——每一轮生成都要保留已有的键值对新请求一来显存占用就动态增长。不考虑KV Cache的资源分配策略等于“没有策略”。显存带宽则决定算力能不能释放出来。解码阶段是典型的访存密集型每生成一个Token都要把整个KV Cache从头读一遍。带宽不够的话计算单元一直在“等数据送来”时间全部耗在搬运上。我经常用运输场景打比方GPU算力像快递分拣速度显存像仓库容量带宽是仓库到分拣台的传送带速度。你光扩仓库、不换传送带分拣速度提不上来你光提升分拣速度、仓库装不下照样爆仓。1.3 明确优化目标延迟、吞吐、成本三者如何取舍没有目标的资源分配优化都是耍流氓。做策略设计之前必须把这三个指标按业务优先级排好。延迟目标通常看P99意思是99%的请求要在目标时间内返回。推荐类服务压到200毫秒以内是及格对话式模型要看体验定位几百毫秒到几秒都有。吞吐目标单卡每秒处理多少请求QPS决定了你要为业务峰值备多少卡。成本目标单位请求的平均GPU开销。影响成本的主要是大规模闲置而不是算得多不快。这三者互相牵制。想压低P99就要少做批量聚合单独为低延迟预留一部分算力想提高QPS就要把请求攒成大batch代价是单个请求的等待时间上升想让成本降低就必须精确控制服务实例数量让每一块卡在峰谷期都不闲着。好的资源分配策略本质是找出业务层能够接受的甜点区间而不是追求某个单值最优。2. 计算资源分配的核心策略与设计原理搞清楚了优化目标下一步是选策略。这里我会把实践中验证过最有效的几个策略拆开讲重点说明它们各自解决什么问题以及为什么这么设计。2.1 动态批处理把零散请求攒成一波再处理GPU适合处理大的规则矩阵运算单个小请求的计算量相对GPU算力来说只占一个零头大量时间都花在内存搬运和kernel启动的开销上。如果把100个请求分别当作100个独立小任务连续执行GPU算力利用率可能只有30%上下把其中8个请求拼成一个矩阵一起算利用率能拉到70%以上。动态批处理就是干这个的收到请求之后不马上丢给GPU而是先放进一个等待队列攒够预设的batch数量或者达到预设的最大等待时间比如20毫秒再把这一批整体送去推理。这里有一个等待窗口的选择问题。攒得越久batch越大GPU利用率越高但请求的排队时间越长。攒得太短batch太小利用率上不去。我见过最蠢的配置就是有人把batch调成“攒满128个才执行”结果低峰期请求根本攒不满延迟白白多出几秒。实操上比较稳妥的起点参数是目标batch大小16起步观察GPU利用率和P99再涨。最大等待时间20到50毫秒超过这个时间就算不满batch也直接送走。组合策略低峰期等待时间为主高峰期batch数量为主。2.2 连续批处理让一个批次的请求不必同步结束动态批处理有一个天然问题一个batch里的请求长度不可能完全一致有的是短请求生成几秒就结束有的长请求要消化几百个Token。传统做法是“这个batch全部跑完才一起返回”那短请求就得等长请求做完白白浪费GPU计算窗口。连续批处理Continuous Batching的做法是batch里某个请求一旦完成立刻释放它的显存空间然后从等待队列补一个新请求进去。同一时刻GPU上跑的始终是“满了就有新任务顶上”的状态而不是“等最后一个人走完才算结束”。连续批处理对资源分配的直接影响是相同显存下能容纳的有效并发请求数明显增多。显存不再等一个慢请求慢慢释放而是按“完成一个、补充一个”的节奏持续利用。反应到指标上就是同样的GPUQPS能比传统批处理提升30%以上。2.3 显存预算与KV Cache管理分配资源要先知道内存还有多少进入实操之前必须要搞懂的一个概念推理服务预分配多大显存不由模型权重决定而是由“权重显存峰值KV Cache显存推理框架自身开销”共同决定。权重显存固定比如一个7B模型FP16精度大约14GB。KV Cache是动态的每个请求每生成一个Token都要把对应的key和value存在显存里请求越长、并发越多KV Cache占得越大。推理框架还会预留一部分显存做CUDA context和框架内部缓冲这部分也有好几GB。算“最大能同时跑多少个请求”有一个简化公式可用显存容量 权重显存 每Token KV Cache显存 × 平均序列长度 × 并发路数 框架预留在这个公式里可调的资源分配变量有两个一是单请求的最大Token长度限制二是并发请求数目。很多线上OOM就是没算这比账——有人把框架默认的并发拉到100却没意识到平均每个请求生成500个Token时KV Cache早就把显存塞爆了。正确的显存预算分配方式是这样的先量出单请求在线上的平均输入Token数和平均输出Token数。根据模型结构查KV Cache单位显存占用层数×头数×维数×精度字节数。把显存分成三块权重区、KV Cache区、框架缓冲给KV Cache区设硬上限。用KV Cache区上限反推最大并发路数并把这个数门禁写进调度策略里。只要这个预算表摆出来很多“莫名OOM”的病例当场就能确诊。2.4 算力分层请求分级、资源池预留不是所有请求都值得同样对待。资源分配策略要跟业务重要级挂钩才能把好钢用在刀刃上。线上请求大致分三种优先级高的交互请求用户在线实时等待比如搜索推荐的列表刷新。这类请求要给定专属的算力切片不做大规模batch聚合走低延迟通道。普通分析请求能容忍几百毫秒到几秒延迟的报表类推理这些归入大batch高吞吐通道。离线批量请求夜间数据挖掘、批量审核根本不追求在线响应低峰期利用空闲算力跑。按这个思路把资源池拆成冷池与热池热池是常驻GPU实例服务在线实时请求保证P99冷池是可以通过调度系统快速拉起的GPU实例平时不占用量业务高峰前按预测提前几分钟拉起来高峰结束后释放回共享池。冷池的价值是在成本和体验中间找平衡。常驻热池按峰值冗余配置高峰期体验好但平时巨浪费全按共享池动态拉取省钱但又怕扩容来不及。折中方案是日常按平均负载量配热池把峰值溢出的部分交给冷池弹性承接。冷池的GPU实例启动通常要几十秒所以一定要配合流量预测或请求数阈值触发预热不能等已经在超时了再拉。3. 落地实操从一台GPU到一组GPU的资源分配实施策略讲清楚了落地上手才是硬功夫。这一节我按Phase顺序把完整的实施步骤写出来可以直接对着做。3.1 容量规划一天的量到底需要几块卡先做一道算力估算题。假设线上预测某个推荐模型平均输入600 Token、输出120 Token单请求总计算量约合1.2亿Token处理量。一块中端推理GPU实测单请求纯计算延迟35毫秒考虑到拼批效率和生产环境损耗按40%的有效利用率估算单卡每秒大约能消化20个请求。业务日峰值QPS是2000那高峰期一小时就需要同时运行约100个GPU实例。这是保守估算但至少能让你对购买多少卡、租多少卡心里有数。具体数字每家模型和卡型不同公式通用单卡并发能力 有效利用率 × GPU单请求吞吐 × 安全系数(通常取0.7~0.85)容量规划一定要按峰值QPS算但不要按峰值买常驻卡。最佳实践是常驻热池按日均峰值的70%配置再留30%给冷池按需伸缩。这样预算能省下好大一块。3.2 动态批处理参数调优batch大小、等待窗口、最大延迟规划完卡数开始打磨每个GPU实例内部的资源分配参数。我踩坑之后的调优顺序是先设目标batch大小为8最大等待时间50毫秒观察GPU利用率和P99。之后每次把batch目标翻倍16、32、64同时观察P99的变化。如果batch从16涨到32P99还是稳定在目标范围内说明GPU还有余力继续加。一旦发现P99同步显著上涨就退回上一档batch并把最大等待时间调低10毫秒。这里有一个反直觉的经验为了防止在线请求挤在同一个大batch里同时被送进GPU可以采用“窗口错峰”策略把等待队列按到达时间切分为更小的批次窗口每个窗口只送一小批多个窗口之间错开送入时间。这么做延迟收益很明显——大batch的矩阵运算一次要跑很久如果所有请求都同时到达同一个batch里最前面的请求要等最后面的算完才能返回P99直接不可控错峰后每个请求的平均等待时间被压到单个窗口的计算粒度内P99会平滑很多。整个调参过程要记录数据不能拍脑袋。观测维度主要看三个GPU利用率、平均响应时长、P99响应时长。比较理想的状态是GPU利用率维持在50%到70%P99压在目标阈值内且显存水位不超过总显存的85%。3.3 显存监控与自适应并发控制显存资源分配是大多数团队翻车的重灾区问题主要集中在“KV Cache增长比预期快”和“并发明明不高却OOM”。应对思路是把显存控制做成一个实时反馈闭环。具体实施包含三块每个推理请求进入系统前先估算它的最大Token长度输入输出上限累加进一个原子计数器。计数器加预估KV Cache量接近显存预算上限时对新请求临时降级要么拒绝并发配额让它们排队要么启动降级通道把大batch需求的请求转走。请求结束时从计数器里扣减对应的占用允许后续请求继续进入。这套水龙头机制比“等爆了再处理”强得多。实际落地时实时计数器可以用简单的累加器实现也可以用框架自带的并发调度API做限额。我见过某团队把并发数从默认48调成根据显存水位自动在16到48之间滑动上线后OOM告警从一天几十次降到零。3.4 冷热池调度与扩缩容单机内部参数调好了再考虑跨实例的资源池调度。热池实例数量恒定处理实时交互请求冷池弹性伸缩由调度器根据集群排队数和QPS阈值触发。扩容时注意几个细节冷池实例不要用完整启动推理服务的裸配置。提前把模型权重、推理框架、动态批处理参数打包成镜像扩容时直接加载可以明显缩短启动时间。扩缩容要加一个平滑缓冲期。不能刚扩容就立刻把流量全打过去等实例内预热完后再逐步衔接流量。缩容同理先停止接收新流量等存量请求跑完再把实例还回去。不要在请求跑到一半时直接杀掉进程这在线上会产生一堆失败用户请求。这里还要注意扩缩容触发的QPS阈值不能写死要按天级流量曲线做分时设定。比如中午和晚上各有一波高峰中午提前20分钟预置冷池晚上提前15分钟。实际流量与预测偏差大时再把等待队列深度作为一个紧迫信号超过深度就强制扩一批卡。4. 常见问题与排查技巧实录再好的设计上线后都会遇到状况。这一节我把实际排查经验列成速查表按症状直接对症下药。4.1 GPU显存明明还有剩却报OOM这个症状大多数出现在启用动态批处理之后。表面上显存还有几个GB空余但它是一块被CUDA context和碎片占用的“有主地”KV Cache申请的连续内存块需要大块连续空间碎片化导致的失败避不开。排查方法用nvidia-smi查看实际显存占用和进程内存分布同时打开推理框架的显存跟踪日志看KV Cache实际分配率和释放率。解决方向是调低并发配额上限开启框架的显存碎片整理或者预分配池。注意在开动态批处理的项目里OOM前通常有信号——并发路数×平均序列长度的乘积接近某个峰值。提前监控这个乘积比亡羊补牢看报错更有效。4.2 加了batch反而更慢了原因80%出在序列长度差异太大。batch越大矩阵运算是按批次里最长的序列长度对齐计算的一个batch里同时有20 Token的短请求和800 Token的长请求短请求也得等800 Token的计算走完整个批次的延迟全被长尾拖垮。对策有三个方向先把请求按长度分桶再批处理相近长度的才拼一个batch要么给最大长度设硬顶超出就截断或转离线通道要么用连续批处理短请求完成后立刻补充新请求而不是等整个batch走完。4.3 GPU利用率高但P99延迟很差利用率高并不代表做的是“正确的工作”。很可能动态批处理把batch攒得太狠GPU一跑就是一大块矩阵单次推理任务从进去到出来的总等待时间反而上升了。利用率数值高只是说明计算单元没闲着不代表延迟体验好。这种场景下把“平均利用率”当健康指标是危险的。正确做法是同时盯每个请求的排队等待耗时如果排队耗时已经超过总延迟预算的一半就调小目标batch大小、缩短等待窗口牺牲一点利用率换回P99。4.4 扩容之后性能反而下降冷池扩容后性能不如热池最常见的原因是冷池实例规格配置没对齐热池的参数。比如热池是动态批处理冷池镜像里还是旧版固定批量配置或者冷池实例没有做预热首次请求需要重新加载权重文件响应硬生生多出几十秒。解决方法是冷池与热池使用同一套镜像和配置并加一个启动后自检先自动向服务发健康请求完成预热再打开对外流量入口。调度系统看实例状态不能只看进程活着要看“预热完成”这个业务状态。常见问题速查表症状原因解决方向显存未满却OOM碎片化 KV Cache未统计限制并发路数开启显存预分配池加batch延迟反而变差序列长度差异过大按长度分桶分批窗口错峰利用率高但P99超标等待排队时间过长调小batch缩短等待窗口扩容后性能下降镜像配置/预热未对齐统一配置启动自检预热低峰期P99莫名抖动冷池释放时存量请求被强杀排空后缩容带缓冲期这几类问题几乎每家做推理服务的团队都会遇到。排查顺序记一条先看显存水位和排队时间再谈算力效率先确认配置一致再动容量大小。关于“优化AI推理计算资源分配策略”这个方向我自己的体会是GPU资源分配的收益空间很多时候比优化模型结构本身还大因为大多数团队浪费的并不是“不会算”而是“不合理地组织计算”。先把动态批处理和显存预算这两件事做到位线上推理服务的延迟和成本都能有明显的改善。
先把结论放在前面AI模型的推理阶段算的不是“模型调得有多好”而是“一秒钟能同时喂饱多少请求、每个请求愿意等多久”。我最近帮某开发团队优化一个线上推荐模型推理服务现象很典型——GPU利用率常年只有20%上下业务高峰期却频繁超时P99延迟飙到让人不敢看。调方案、加并行、扩机器都试过最后发现卡点根本不在模型本身而在计算资源分配策略上。这篇内容我会从资源分配的几个核心矛盾讲起再拆解动态批处理、显存预算、冷热池调度这些具体策略最后附上可以直接抄作业的落地步骤和排查记录。很适合正在做模型部署、推理服务优化或者被“GPU那么贵利用率却上不去”折磨的工程同学参考。1. 资源分配这件事到底在优化什么先说一个最常见的认知误区很多人把推理性能差归结为“模型太慢”或者“卡不行”但大多数情况下模型本身算得快是你的资源分配策略把算力白白浪费了。1.1 训练和推理的资源需求完全不是一回事模型训练的核心诉求是“把大型批次数据尽快喂给GPU算梯度”它可以容忍排队——因为训练任务不在乎单条数据多久返回只要总吞吐高就行。训练时的资源分配策略通常是“能塞多少塞多少尽量打满显存和计算单元”。推理正好相反。每一次请求都是一个在线用户伸着脖子等你返回结果。资源分配的核心矛盾变成了有限算力下同时跑多少请求才不互相踩脚。每个请求能容忍的等待时间有多长。GPU有几个计算核心、多大显存带宽能支撑多大并发。组合起来就是给定QPS、延迟目标、GPU预算求出最优的“并发路数批次大小显存预留”组合。这个组合一旦选错就会出现“卡看起来没闲着但实际大量算力浪费在小矩阵碎片上”和“单请求响应快但一打并发立刻超时”这两种极端。1.2 先看清你手里的牌算力、显存、带宽三个维度推理资源分配策略不是凭空想出来的它受三个硬指标约束。算力TOPS/FLOPS决定一秒钟能做多少次矩阵乘法。这个数字不是瓶颈因为绝大多数模型的推理计算量并没有把GPU的流处理器喂满。显存容量决定你肚子里能装多少“中间状态”。推理过程里最吃显存的不是模型权重而是KV Cache——每一轮生成都要保留已有的键值对新请求一来显存占用就动态增长。不考虑KV Cache的资源分配策略等于“没有策略”。显存带宽则决定算力能不能释放出来。解码阶段是典型的访存密集型每生成一个Token都要把整个KV Cache从头读一遍。带宽不够的话计算单元一直在“等数据送来”时间全部耗在搬运上。我经常用运输场景打比方GPU算力像快递分拣速度显存像仓库容量带宽是仓库到分拣台的传送带速度。你光扩仓库、不换传送带分拣速度提不上来你光提升分拣速度、仓库装不下照样爆仓。1.3 明确优化目标延迟、吞吐、成本三者如何取舍没有目标的资源分配优化都是耍流氓。做策略设计之前必须把这三个指标按业务优先级排好。延迟目标通常看P99意思是99%的请求要在目标时间内返回。推荐类服务压到200毫秒以内是及格对话式模型要看体验定位几百毫秒到几秒都有。吞吐目标单卡每秒处理多少请求QPS决定了你要为业务峰值备多少卡。成本目标单位请求的平均GPU开销。影响成本的主要是大规模闲置而不是算得多不快。这三者互相牵制。想压低P99就要少做批量聚合单独为低延迟预留一部分算力想提高QPS就要把请求攒成大batch代价是单个请求的等待时间上升想让成本降低就必须精确控制服务实例数量让每一块卡在峰谷期都不闲着。好的资源分配策略本质是找出业务层能够接受的甜点区间而不是追求某个单值最优。2. 计算资源分配的核心策略与设计原理搞清楚了优化目标下一步是选策略。这里我会把实践中验证过最有效的几个策略拆开讲重点说明它们各自解决什么问题以及为什么这么设计。2.1 动态批处理把零散请求攒成一波再处理GPU适合处理大的规则矩阵运算单个小请求的计算量相对GPU算力来说只占一个零头大量时间都花在内存搬运和kernel启动的开销上。如果把100个请求分别当作100个独立小任务连续执行GPU算力利用率可能只有30%上下把其中8个请求拼成一个矩阵一起算利用率能拉到70%以上。动态批处理就是干这个的收到请求之后不马上丢给GPU而是先放进一个等待队列攒够预设的batch数量或者达到预设的最大等待时间比如20毫秒再把这一批整体送去推理。这里有一个等待窗口的选择问题。攒得越久batch越大GPU利用率越高但请求的排队时间越长。攒得太短batch太小利用率上不去。我见过最蠢的配置就是有人把batch调成“攒满128个才执行”结果低峰期请求根本攒不满延迟白白多出几秒。实操上比较稳妥的起点参数是目标batch大小16起步观察GPU利用率和P99再涨。最大等待时间20到50毫秒超过这个时间就算不满batch也直接送走。组合策略低峰期等待时间为主高峰期batch数量为主。2.2 连续批处理让一个批次的请求不必同步结束动态批处理有一个天然问题一个batch里的请求长度不可能完全一致有的是短请求生成几秒就结束有的长请求要消化几百个Token。传统做法是“这个batch全部跑完才一起返回”那短请求就得等长请求做完白白浪费GPU计算窗口。连续批处理Continuous Batching的做法是batch里某个请求一旦完成立刻释放它的显存空间然后从等待队列补一个新请求进去。同一时刻GPU上跑的始终是“满了就有新任务顶上”的状态而不是“等最后一个人走完才算结束”。连续批处理对资源分配的直接影响是相同显存下能容纳的有效并发请求数明显增多。显存不再等一个慢请求慢慢释放而是按“完成一个、补充一个”的节奏持续利用。反应到指标上就是同样的GPUQPS能比传统批处理提升30%以上。2.3 显存预算与KV Cache管理分配资源要先知道内存还有多少进入实操之前必须要搞懂的一个概念推理服务预分配多大显存不由模型权重决定而是由“权重显存峰值KV Cache显存推理框架自身开销”共同决定。权重显存固定比如一个7B模型FP16精度大约14GB。KV Cache是动态的每个请求每生成一个Token都要把对应的key和value存在显存里请求越长、并发越多KV Cache占得越大。推理框架还会预留一部分显存做CUDA context和框架内部缓冲这部分也有好几GB。算“最大能同时跑多少个请求”有一个简化公式可用显存容量 权重显存 每Token KV Cache显存 × 平均序列长度 × 并发路数 框架预留在这个公式里可调的资源分配变量有两个一是单请求的最大Token长度限制二是并发请求数目。很多线上OOM就是没算这比账——有人把框架默认的并发拉到100却没意识到平均每个请求生成500个Token时KV Cache早就把显存塞爆了。正确的显存预算分配方式是这样的先量出单请求在线上的平均输入Token数和平均输出Token数。根据模型结构查KV Cache单位显存占用层数×头数×维数×精度字节数。把显存分成三块权重区、KV Cache区、框架缓冲给KV Cache区设硬上限。用KV Cache区上限反推最大并发路数并把这个数门禁写进调度策略里。只要这个预算表摆出来很多“莫名OOM”的病例当场就能确诊。2.4 算力分层请求分级、资源池预留不是所有请求都值得同样对待。资源分配策略要跟业务重要级挂钩才能把好钢用在刀刃上。线上请求大致分三种优先级高的交互请求用户在线实时等待比如搜索推荐的列表刷新。这类请求要给定专属的算力切片不做大规模batch聚合走低延迟通道。普通分析请求能容忍几百毫秒到几秒延迟的报表类推理这些归入大batch高吞吐通道。离线批量请求夜间数据挖掘、批量审核根本不追求在线响应低峰期利用空闲算力跑。按这个思路把资源池拆成冷池与热池热池是常驻GPU实例服务在线实时请求保证P99冷池是可以通过调度系统快速拉起的GPU实例平时不占用量业务高峰前按预测提前几分钟拉起来高峰结束后释放回共享池。冷池的价值是在成本和体验中间找平衡。常驻热池按峰值冗余配置高峰期体验好但平时巨浪费全按共享池动态拉取省钱但又怕扩容来不及。折中方案是日常按平均负载量配热池把峰值溢出的部分交给冷池弹性承接。冷池的GPU实例启动通常要几十秒所以一定要配合流量预测或请求数阈值触发预热不能等已经在超时了再拉。3. 落地实操从一台GPU到一组GPU的资源分配实施策略讲清楚了落地上手才是硬功夫。这一节我按Phase顺序把完整的实施步骤写出来可以直接对着做。3.1 容量规划一天的量到底需要几块卡先做一道算力估算题。假设线上预测某个推荐模型平均输入600 Token、输出120 Token单请求总计算量约合1.2亿Token处理量。一块中端推理GPU实测单请求纯计算延迟35毫秒考虑到拼批效率和生产环境损耗按40%的有效利用率估算单卡每秒大约能消化20个请求。业务日峰值QPS是2000那高峰期一小时就需要同时运行约100个GPU实例。这是保守估算但至少能让你对购买多少卡、租多少卡心里有数。具体数字每家模型和卡型不同公式通用单卡并发能力 有效利用率 × GPU单请求吞吐 × 安全系数(通常取0.7~0.85)容量规划一定要按峰值QPS算但不要按峰值买常驻卡。最佳实践是常驻热池按日均峰值的70%配置再留30%给冷池按需伸缩。这样预算能省下好大一块。3.2 动态批处理参数调优batch大小、等待窗口、最大延迟规划完卡数开始打磨每个GPU实例内部的资源分配参数。我踩坑之后的调优顺序是先设目标batch大小为8最大等待时间50毫秒观察GPU利用率和P99。之后每次把batch目标翻倍16、32、64同时观察P99的变化。如果batch从16涨到32P99还是稳定在目标范围内说明GPU还有余力继续加。一旦发现P99同步显著上涨就退回上一档batch并把最大等待时间调低10毫秒。这里有一个反直觉的经验为了防止在线请求挤在同一个大batch里同时被送进GPU可以采用“窗口错峰”策略把等待队列按到达时间切分为更小的批次窗口每个窗口只送一小批多个窗口之间错开送入时间。这么做延迟收益很明显——大batch的矩阵运算一次要跑很久如果所有请求都同时到达同一个batch里最前面的请求要等最后面的算完才能返回P99直接不可控错峰后每个请求的平均等待时间被压到单个窗口的计算粒度内P99会平滑很多。整个调参过程要记录数据不能拍脑袋。观测维度主要看三个GPU利用率、平均响应时长、P99响应时长。比较理想的状态是GPU利用率维持在50%到70%P99压在目标阈值内且显存水位不超过总显存的85%。3.3 显存监控与自适应并发控制显存资源分配是大多数团队翻车的重灾区问题主要集中在“KV Cache增长比预期快”和“并发明明不高却OOM”。应对思路是把显存控制做成一个实时反馈闭环。具体实施包含三块每个推理请求进入系统前先估算它的最大Token长度输入输出上限累加进一个原子计数器。计数器加预估KV Cache量接近显存预算上限时对新请求临时降级要么拒绝并发配额让它们排队要么启动降级通道把大batch需求的请求转走。请求结束时从计数器里扣减对应的占用允许后续请求继续进入。这套水龙头机制比“等爆了再处理”强得多。实际落地时实时计数器可以用简单的累加器实现也可以用框架自带的并发调度API做限额。我见过某团队把并发数从默认48调成根据显存水位自动在16到48之间滑动上线后OOM告警从一天几十次降到零。3.4 冷热池调度与扩缩容单机内部参数调好了再考虑跨实例的资源池调度。热池实例数量恒定处理实时交互请求冷池弹性伸缩由调度器根据集群排队数和QPS阈值触发。扩容时注意几个细节冷池实例不要用完整启动推理服务的裸配置。提前把模型权重、推理框架、动态批处理参数打包成镜像扩容时直接加载可以明显缩短启动时间。扩缩容要加一个平滑缓冲期。不能刚扩容就立刻把流量全打过去等实例内预热完后再逐步衔接流量。缩容同理先停止接收新流量等存量请求跑完再把实例还回去。不要在请求跑到一半时直接杀掉进程这在线上会产生一堆失败用户请求。这里还要注意扩缩容触发的QPS阈值不能写死要按天级流量曲线做分时设定。比如中午和晚上各有一波高峰中午提前20分钟预置冷池晚上提前15分钟。实际流量与预测偏差大时再把等待队列深度作为一个紧迫信号超过深度就强制扩一批卡。4. 常见问题与排查技巧实录再好的设计上线后都会遇到状况。这一节我把实际排查经验列成速查表按症状直接对症下药。4.1 GPU显存明明还有剩却报OOM这个症状大多数出现在启用动态批处理之后。表面上显存还有几个GB空余但它是一块被CUDA context和碎片占用的“有主地”KV Cache申请的连续内存块需要大块连续空间碎片化导致的失败避不开。排查方法用nvidia-smi查看实际显存占用和进程内存分布同时打开推理框架的显存跟踪日志看KV Cache实际分配率和释放率。解决方向是调低并发配额上限开启框架的显存碎片整理或者预分配池。注意在开动态批处理的项目里OOM前通常有信号——并发路数×平均序列长度的乘积接近某个峰值。提前监控这个乘积比亡羊补牢看报错更有效。4.2 加了batch反而更慢了原因80%出在序列长度差异太大。batch越大矩阵运算是按批次里最长的序列长度对齐计算的一个batch里同时有20 Token的短请求和800 Token的长请求短请求也得等800 Token的计算走完整个批次的延迟全被长尾拖垮。对策有三个方向先把请求按长度分桶再批处理相近长度的才拼一个batch要么给最大长度设硬顶超出就截断或转离线通道要么用连续批处理短请求完成后立刻补充新请求而不是等整个batch走完。4.3 GPU利用率高但P99延迟很差利用率高并不代表做的是“正确的工作”。很可能动态批处理把batch攒得太狠GPU一跑就是一大块矩阵单次推理任务从进去到出来的总等待时间反而上升了。利用率数值高只是说明计算单元没闲着不代表延迟体验好。这种场景下把“平均利用率”当健康指标是危险的。正确做法是同时盯每个请求的排队等待耗时如果排队耗时已经超过总延迟预算的一半就调小目标batch大小、缩短等待窗口牺牲一点利用率换回P99。4.4 扩容之后性能反而下降冷池扩容后性能不如热池最常见的原因是冷池实例规格配置没对齐热池的参数。比如热池是动态批处理冷池镜像里还是旧版固定批量配置或者冷池实例没有做预热首次请求需要重新加载权重文件响应硬生生多出几十秒。解决方法是冷池与热池使用同一套镜像和配置并加一个启动后自检先自动向服务发健康请求完成预热再打开对外流量入口。调度系统看实例状态不能只看进程活着要看“预热完成”这个业务状态。常见问题速查表症状原因解决方向显存未满却OOM碎片化 KV Cache未统计限制并发路数开启显存预分配池加batch延迟反而变差序列长度差异过大按长度分桶分批窗口错峰利用率高但P99超标等待排队时间过长调小batch缩短等待窗口扩容后性能下降镜像配置/预热未对齐统一配置启动自检预热低峰期P99莫名抖动冷池释放时存量请求被强杀排空后缩容带缓冲期这几类问题几乎每家做推理服务的团队都会遇到。排查顺序记一条先看显存水位和排队时间再谈算力效率先确认配置一致再动容量大小。关于“优化AI推理计算资源分配策略”这个方向我自己的体会是GPU资源分配的收益空间很多时候比优化模型结构本身还大因为大多数团队浪费的并不是“不会算”而是“不合理地组织计算”。先把动态批处理和显存预算这两件事做到位线上推理服务的延迟和成本都能有明显的改善。
知识建站
内容驱动
阅读友好版式
SEO 精细化
线索转化