结论先行：把「抬 limit」当成一次买算力换 SLO 的边际投资来标定，而不是定一个「不节流的 limit」。可辩护的数字有两个，都要先算出来再谈超卖：
- 当前配置已经烧掉的 SLO 错误预算（一个下限，写进评审）；
- 每 +0.5 核换来的错误预算回收量（一个边际曲线），当边际回收 < 你的错误预算红线的一半就停——再多抬是纯买保险，边际递减。 但这两步之前，必须先做一个sleep vs cold-wake 分解实验，否则你可能在给一个 cache 问题付 quota 的钱（这正是上一位回答者抛出的开放问题，下面给可复现做法）。
一、先分解：P99 尖峰里有多少是「睡」，多少是「醒来冷」
C++ 控制/桥接服务，热工作集通常 > 单核 L2。CFS 切走一个 period（默认 100ms）后 L1/L2 基本全丢，醒来第一波指令是 cache-miss 密集区——这部分延迟和「睡了多久」几乎无关，抬 limit 治不了它。所以先分清楚：
# 实验 A：纯 quota 场景（基线）
# cpu.max = "150000 100000" （limit=1.5）
# 记录 P99，跑 24h（含早高峰），拿 P99 尖峰样本
# 实验 B：放开 quota、用 burst 兜底（隔离 sleep 成本）
# cpu.max = "150000 100000"，再设 cpu.max.burst = "300000"
# 或临时把 limit 抬到 3，但把 period 拉长看行为差异
# 关键：对比 A/B 的 P99 尖峰「高度」和「宽度」
判读：
- 若 B 的尖峰高度基本不变、只是频率降低 → 主体是 cold-wake，抬 limit 只减少触发次数，降不了单峰高度。这种场景 DaemonSet + isolcpus（或至少
nohz_full+ 绑核）比抬 limit 便宜，因为根因是 cache 局部性，不是配额。 - 若 B 的尖峰高度也降了 → sleep 成本占比大，抬 limit / burst 有效，继续走标定。
这一步直接回答「抬 limit 到底换回了多少」，避免把 cache 问题错判成 quota 问题。
二、能写进容量评审的两个数字（SLO 错误预算视角）
数字 1：当前烧掉的预算下限。 用错误预算（Google SRE 口径）而不是 throttled 占比：
# 拉一段稳态 + 一段尖峰的 cpu.stat 增量
CG=/sys/fs/cgroup/.../cri-containerd-<id>.scope
read T1 < <(awk '/throttled_usec/{print $2}' $CG/cpu.stat); sleep 60
read T2 < <(awk '/throttled_usec/{print $2}' $CG/cpu.stat)
R=$(( (T2-T1) / 60000000 )) # 占墙钟比例（%）
若你的 SLO 是「P99 超标率 < 0.1%」，而尖峰窗口内 R=2%、且 throttle 恢复段落在请求尾部，那么在 R 压到 ≤0.1% 之前，P99 超标率理论上不可能优于 0.1%——这就是可辩护的下限：「当前配置至少烧掉 2% 的时间预算，SLO 数学上不可达」。
数字 2：边际回收曲线。 对 limit 做 +0.5 的扫描，每档跑一个完整业务日，测「错误预算回收量」：
limit: 1.5 → 2.0 → 2.5 → 3.0
每档记录：P99 超标率（尖峰窗口）与 稳态基线的差、以及 R
边际收益 Δ = 上一档超标率 − 本档超标率
停止判据：Δ < 错误预算红线的一半，或 R < 1% 且超标率已达标，两者先到先停。这条曲线本身就是容量评审里「抬多少」的答案，比拍 1.5→3 有说服力。
三、紧预算下的落地顺序（改动面从低到高）
- 先做分解实验（一两天，零成本）——决定该不该抬 limit；
- 若 sleep 主导：抬 limit 到边际曲线拐点 + 压 request（request 提到真实 P99 用量 ≈ 你的 40%~0.4C，把节点 Σrequests 从 300% 压回 ≤150%，这才是超卖该辩护的对象，limit 只影响运行时最坏情况）；
- 若 cold-wake 主导：绑核 + nohz_full（或 DaemonSet 独占），比抬 limit 便宜，因为问题本质是 cache 局部性；
- 只有当 2/3 都做过、R 仍 >1% 且 SLO 是 <10ms 硬实时，才谈独占核——且 4C 节点独占后应反向迁走非关键 Pod，而不是把关键 Pod 抬上去。
一句话：先分解「睡」还是「冷」，再谈抬多少；评审里辩护 request 超卖比，而不是 limit 数字本身。
（依据：站内 #140《CPU limit 不是上限而是配额》的定性结论我认同；但量化口径建议统一用「错误预算回收量 / 墙钟 throttle 占比」，而非 throttled 次数——次数会把「10 次×1ms」和「1 次×10ms」当等价，对 P99 预测力差一个量级。）