一、项目背景

我们这边的私有化推理集群，早期为了省事，把 batch size 设成固定值，所有模型共用一套参数。结果低峰时段 GPU 显存占着、算力空转，高峰时段请求堆队列，尾延迟直接飙到十几秒，用户侧的流式输出卡成PPT。老板看月度云账单，觉得钱花得不值，要求我们把利用率和尾延迟同时拉起来。

我们当时接手时有一层误解，以为把 batch 调大就能提吞吐，实测发现 batch 一大，显存抖动让一部分请求直接 OOM 被踢，反而更慢。这个项目让我真正理解了一件事：推理优化的核心不是"多大"，而是"跟着负载和显存实时收着调"，拍脑袋定值迟早翻车。

二、落地场景

落地后的形态是，每个模型实例跑一个连续批处理（continuous batching）的调度器，实时看队列深度和显存水位，在允许区间内动态调 batch。低峰自动收小，省显存也给长请求腾空间；高峰顶着显存上限放大，吃满算力。同时把多模型共享的显存做了硬隔离，避免一个模型把整卡吃光连累邻居。

我们搭了一块利用率与尾延迟的联合看板，GPU 利用率、平均首字延迟、P99 尾延迟、吞吐 QPS 同屏滚动，运维一眼能看出哪台机器在空转或者在挤兑。调度器还接了显存水位联动限流，水位逼近阈值就提前拒绝新请求并友好提示，而不是等 OOM 才崩。

三、关键技术挑战与解决思路

绕不开的是动态 batch 与显存抖动。batch 放大不是线性吃显存，KV cache 的增长在长上下文下会突变。我们没有用固定上限，而是预留一段显存安全垫，调度器按当前活跃序列数和平均长度估下一个 batch 的显存占用，超了就先不发，宁可少装也不 OOM。

紧接着要处理的是连续批处理的聚合窗口。窗口太短，batch 装不满，吞吐上不去；太长，首字延迟涨。我们做了分段窗口，短请求走快窗口，长请求合并进慢窗口，按长度分层聚合，避免长请求拖短请求的节奏。

再往下是尾延迟和吞吐的权衡。我们给延迟敏感类业务打了标记，调度时优先塞进当前 batch，普通请求排队，关键链路不被长尾淹没。这个优先级不是无限优先，超过阈值会降级，防止饿死普通请求。

最后是多模型共享显存隔离。早期几张卡上混部多个模型，一个模型预热就把邻居挤崩。我们按模型画像给每张卡划了显存配额和算力配额，越界直接限流，邻居之间互不踩。

案例片段（已脱敏）： 动态 batch 与显存安全垫配置（节选）：scheduler:  mode: continuous_batching  min_batch: 1  max_batch: 64  kv_cache_safety_pad_mb: 2048     # 显存安全垫  window_ms: {short: 8, long: 40}  # 长短请求分层窗口  latency_sensitive_priority: true  priority_starve_guard_ms: 200     # 防饿死降级阈值  mem_quota_per_model_mb: 12288      # 模型显存硬隔离调优后日志：GPU 利用率由 41% 升至 68%，P99 首字延迟由 11.2s 降至 3.4s。

四、效果数据

调优跑满两周，GPU 平均利用率从四成出头提到六成八，同样的卡数多扛了约六成的有效吞吐。平均首字延迟从四点几秒压到一点九秒，P99 尾延迟从十一秒量级降到三点四秒，流式输出的卡顿基本消失。

显存 OOM 导致的请求踢出，从每天几十次降到个位数，且都发生在显式压测场景而非真实流量。关键链路延迟达标率稳定在九成九以上，没有再出现长尾淹没敏感业务的事故。文中数据为项目复盘口径，均为示意值，非审计级精确数字。

我们当时高估了固定大 batch 的作用，实测证明动态收着调才是正解。唯一没完全解决的是极长上下文（超过八千 token）下的显存尖峰，目前靠显存配额上限兜底，没彻底压平。

五、可复用经验总结

推理集群的 batch 不是越大越好，固定值要么空转要么 OOM，必须跟着队列深度和显存水位实时调，还留一段安全垫。连续批处理的聚合窗口要分长短请求两层，不然长请求会把短请求的延迟节奏拖垮。

延迟敏感业务要单独打标记优先塞 batch，但必须配防饿死降级，否则普通请求会被拖死。多模型混部一定做显存和算力硬隔离，别指望它们自觉互不踩，一张卡被一个模型吃光全卡跟着崩的教训我们已经吃过。

结语

这个项目最大的认知纠偏是别迷信大 batch。我们一开始真以为调大就能提吞吐，结果 OOM 把一批请求直接踢掉，反而更慢，那是实实在在的打脸。后来换成动态收着调加显存安全垫，GPU 利用率和尾延迟才同时下来。多模型混部那一步也省不掉，早期几张卡上模型互相挤，一张卡被一个模型吃光，邻居跟着崩，划显存和算力硬隔离之后才消停。GPU 账单出来，老板也比之前满意，这比任何架构汇报都有说服力。极长上下文的显存尖峰还没彻底压平，目前靠配额上限兜底，算是个留到后面的尾巴。

顺带说一句，利用率看板和尾延迟看板得同屏，运维一眼能看出哪台在空转或在挤兑，这事儿上线前没人提，是跑起来后才补的。显存安全垫留多少也别拍脑袋，我们是按最长上下文压测出来的，留少了照样 OOM 把请求踢掉。