显存比 CPU 更不客气

CPU 服务偶尔超卖还能缓一缓。GPU 推理里显存顶满就是 OOM，进程直接没，用户侧一串 502。所以调度之前先把账算清楚：权重占多少、KV 随并发怎么涨、还要留一点碎片余量。

粗算仍然有用。比如 7B 的 FP16 权重大约十三四 GB，24G 卡能起，但高并发、长上下文时 KV 会很快把余量吃掉。自己的做法是：单请求摸底最小占用，再往上加 max_num_seqs，看显存曲线，留 10%～20% 再对外。

多模型共卡要保守

核心业务、SLO 紧的，倾向独占卡，贵但省心。长尾小模型可以共卡或分时切，但要先压过，别上线才发现互相拖慢。

分时复用适合闲时明显的环境，代价是切换有冷启动。真共卡就给每个实例限显存，并接受「偶发抖动」——接受不了就别共。

K8s 上几点实在做法

nvidia.com/gpu 的 request/limit 按卡声明清楚；不同卡型用节点标签分开，别让调度器随便塞。在线推理实例之间可以加反亲和，避免全挤一台后宿主机抖动一起挂。

多卡张量并行尽量落在同一 NVLink 域，跨 NUMA 硬拼后面延迟和带宽都会怪。训练/离线评测和在线池子分开，避免抢卡。

resources:
  limits:
    nvidia.com/gpu: 1
  requests:
    cpu: "4"
    memory: 32Gi
nodeSelector:
  gpu.family: "ada"

队列比「再加一台」先做

引擎和网关都要有并发上限。超了就 429 或排队超时，总好过把显存打爆集体重启。离线跑评测、刷 embedding，放到低优先队列，错开高峰。

DCGM Exporter 建议接上。利用率长期很低是浪费，长期打满要扩容或降流量；温度和降频能解释「没改代码却突然变慢」。

常见坑

• OOM：先降并发、卡住超长请求，必要时换量化版；碎片严重就重启回收，治本还是限流和分池
• 容器里看不到 GPU：从驱动、runtime、device plugin 一层层查，nvidia-smi 和插件 Pod 日志最有用
• 延迟一阵一阵：查是不是共卡、CPU 是否给够、是不是在边跑边拉权重

每周看一眼卡时利用率和业务量是否匹配。卡空着和卡被离线任务打满，都是钱的问题，只是方向相反。

转载请注明：周志洋的博客 » GPU资源管理与推理集群调度