3. 资源限制基础:K8s资源单位、Requests与Limits、QoS类别

聊到vLLM在K8s上的部署,资源限制这块是绕不开的坎。我见过太多人栽在这里——要么给太少导致OOM,要么给太多造成浪费。说白了,K8s的资源管理就像给大模型分配「口粮」,给多了浪费,给少了饿死。

3.1 K8s资源单位:CPU核心与内存

先说说单位。K8s里CPU和内存的表示方式,跟咱们平时理解的不太一样。

CPU单位

  • 1 CPU核心 = 1个物理核心或vCPU(在云环境里通常对应一个超线程)
  • m(millicores):毫核,1000m = 1核心。比如500m就是半个核心
  • 最小粒度:1m,但实际生产中很少低于10m
我的经验:vLLM推理任务对CPU的消耗其实不大,瓶颈主要在GPU和内存。CPU给个2-4核心就够用了,除非你同时跑多个推理实例。

内存单位

  • MiB vs MB:K8s默认用二进制单位。1MiB = 2²⁰字节 = 1,048,576字节,而1MB = 10⁶字节。差约4.8%
  • GiB vs GB:同理,1GiB = 1,073,741,824字节
  • 常用写法:128Mi、2Gi、512MiB、4GiB
注意:我曾经在项目中遇到过,有人把内存写成「2G」而不是「2Gi」,结果K8s直接报错。K8s只认Mi、Gi、M、G这种标准后缀,别自己发明缩写。

3.2 Requests与Limits的区别

这两个概念,我刚开始学的时候也绕晕过。简单说:

  • Requests:容器「保证能拿到」的资源量。调度器根据这个决定把Pod放在哪个节点上
  • Limits:容器「最多能用」的资源量。超过这个值,CPU会被限流,内存会被杀掉

为什么会这样设计?你想想看,如果每个Pod都只说自己「想要」多少,那节点资源肯定不够分。Requests就是给调度器看的「承诺」,Limits是给运行时看的「天花板」。

属性 CPU 内存
Requests 调度依据,CFS保证 调度依据,不保证物理分配
Limits 超过则限流(throttle) 超过则OOM Kill
未设置Limits 可使用节点空闲CPU 可使用节点空闲内存
核心原则:对于vLLM推理任务,我建议Requests和Limits设置相同值。为什么呢?因为大模型推理的内存需求是确定的,你给少了它真会OOM。CPU可以适当放宽,但内存必须严格限制。

3.3 QoS类别:Guaranteed / Burstable / BestEffort

K8s根据Requests和Limits的设置方式,把Pod分成三个QoS等级。这玩意儿决定了节点资源紧张时,谁先被「请出去」。

Guaranteed(保证型)

  • 条件:所有容器都设置了Requests和Limits,且两者相等
  • 优先级:最高,几乎不会被驱逐
  • 适用场景:vLLM推理任务、数据库、关键服务

Burstable(可爆发型)

  • 条件:至少有一个容器设置了Requests,但Limits大于Requests或未设置
  • 优先级:中等,资源紧张时可能被驱逐
  • 适用场景:批处理任务、开发环境

BestEffort(尽力型)

  • 条件:没有任何容器设置Requests和Limits
  • 优先级:最低,节点资源不足时第一个被干掉
  • 适用场景:测试、临时任务
避坑指南:我曾经在生产环境里见过有人把vLLM推理Pod设成Burstable,结果节点内存压力一大,Pod直接被驱逐,正在推理的请求全部失败。嗯,从那以后我所有生产推理任务都用Guaranteed。

3.4 资源限制的重要性

为什么我要花这么多篇幅讲这个?因为vLLM推理对资源的要求太特殊了。

  1. 内存是硬约束:模型权重、KV Cache、中间激活值,哪个都离不开内存。给少了直接OOM,给多了浪费GPU显存
  2. CPU影响吞吐:虽然推理主要在GPU上跑,但CPU负责数据预处理、后处理、调度。CPU不够会导致GPU空转
  3. QoS决定稳定性:生产环境必须用Guaranteed,否则节点抖动时你的推理服务可能被「误伤」
  4. 成本控制:资源限制做得好,集群利用率能提升30%以上。我见过一个团队,优化后从20台节点降到14台
我的建议:刚开始部署vLLM时,先给保守的资源限制(比如模型大小的1.2倍),跑几天看看实际使用量,再逐步调整。别一上来就追求极致,稳定第一。

3.5 知识体系图

K8s资源限制核心知识体系 资源单位 • CPU:核心/m • 内存:MiB/GiB • 二进制 vs 十进制 • 最小粒度限制 常见误区: ✗ 用"G"代替"Gi" ✗ 忽略MiB/MB差异 Requests & Limits • Requests:保证量 • Limits:上限 • CPU限流机制 • OOM Kill机制 最佳实践: ✓ 生产环境R=L ✓ 内存严格限制 QoS类别 • Guaranteed • Burstable • BestEffort • 驱逐优先级 推荐选择: ✓ vLLM用Guaranteed ✗ 避免BestEffort 三者共同决定Pod的资源行为与稳定性

这张图把三个核心模块串起来了。资源单位是基础,Requests/Limits是配置手段,QoS是最终效果。你配置资源限制时,其实就是在决定你的Pod属于哪个QoS等级。

一句话总结:对于vLLM推理任务,我建议统一用Guaranteed QoS,Requests和Limits设相同值,内存按模型大小的1.2-1.5倍预留,CPU给2-4核心。这样既稳定又不会太浪费。

公众号:蓝海资料掘金营,微信deep3321