1 引言

1.1 背景

在廉价 VPS 市场，卖家的生存方式是把大量低负载的客户虚拟机（VM）超售打包到少量物理核心上。本文的观测对象是我们自己在运营的两台生产宿主（以免费 VPS 形式开放给外部用户；遥测匿名化只读）：一台以 4 物理核/8 逻辑线程承载 64 台运行中的客户 VM（配置 70 vCPU）；另一台（50 核）配置 285 台 VM（8.3× vCPU 超售、2.0× 内存、4.9× 薄分配磁盘）、运行 276 台。对小型服务商而言，超售不是可取舍的优化项，而是商业模式本身：客户能以便宜价格买到"1 核 2G"，正因为供应商知道大多数时间它们闲着。难点不在"要不要超售"，而在三个依次递进的技术问题：观测是否完备（识别）、容量能否预测（预测）、密度能否安全提升（行动）。

1.2 三个问题

本文解决的问题（问题 → 对策 → 量化结果）

以下展开三个问题的背景与动机：

本稿的组织命题把三问进一步收紧为观测必要性：三类观测能力（截断识别／相位分辨／时间分辨）各自必要（§3.6 三个构造性反例）且在本目标负载族上合起来充分（经验结论）——第 7 章的七策略对决逐条给出"缺失某一能力的唯一后果"的实测归因。

• 识别：需求被截断（censoring），而且聚合口径下不可完全恢复。 为保护宿主，CPU 配额是标配；一旦客户触及上限，其"用量"就不再代表需求——被限流在 50%、真实想用 100% 的客户，在用量面板上与"很闲"的客户难以区分。我们进一步形式化：在仅有（用量, 节流占比）聚合计数器的前提下，任何估计器都不可能对所有负载无偏（3.3.1 命题 3 显式构造）；能给出的只是"运行段均值的点估计 + 形状无关的认证下界"。识别问题的正确姿态是把可辨识边界写清楚，而不是假装能精确恢复。
• 预测：容量由负载的相位结构决定，而不是平均利用率。 同样人均 20% 占空比的 64 台客户，随机相位可安全卖 28 台（P5≥70% 口径，细扫边界 [28,32)），全体对齐时只能卖 8 台（[8,10)）；而 35% 平均忙碌的同步集合会被压垮、98% 忙碌的随机集合反而安全——安全性与利用率不可互推。相位结构可以从逐租户 1 秒历史中测量（相位剖面），也可以在投放时编排（相位分散）。
• 行动：效率手段必须区分"隐形收益"与"租户可见回归"。 "无回归"在本文严格分域定义（服务侧 SLO／客户性能经验分布／客户配置可见性三类，互不等价；宿主节约单列）—— 绑核隔离、KSM 去重、空闲页上报（FPR）对租户完全不可见；配额、IO 上限、zram 压缩则各有明确计价。小型服务商真正的产品空间，就是"在不降低租户可见资源的前提下"能把密度推到多高。

1.3 方法总览

我们在两套自建测试床上把上述问题做成可验证的系统：嵌套 PVE 床（4 vCPU/19.5 GiB，16 台客户）与裸金属床（2×Xeon 8259CL，96 线程/991 GiB，64 台客户舰队；隔离声明经 SMT/NUMA 拓扑核验），外加两台生产宿主的匿名只读遥测作为场景锚点。研究主线与最小观测集见图 1；围绕三支柱：

1. 识别：截断的可识别性小理论（3.3.1：点估计=运行段均值、形状无关地板 $q(1+t)$、非可辨识构造）+ 90 个 cycle 配对验证 + 混合占用三估计器消融（naive / 配额缩放 / 节流校正）。
2. 预测：安全容量近似模型 $N^* \approx C/(\varphi + (1-\varphi)\rho)$（密度律形式，明确假设下使用）+ 混合相位首轮验证 + 反相编排实验 + 阈值化容量曲线（主口径 P5≥70%）。
3. 行动：风险校准准入（伪代码与校准协议见 5.3.1）在同约束同客户的头对头对决中对齐容量上限；无回归控制（KSM/FPR/zram、自适应 IO；CPU 微周期经干净复测无吞吐增益、原 +35% 主张已撤回，见 9.1）逐资源抬高密度。

1.4 主要发现

• 识别：5 台 30% 配额满载客户，用量面板 1.50 核 vs 真实需求 5.00 核（低估 3.3×，7/7 轮）；v2 复测 90 个 cycle 中节流校正均达真值、基于少报的松绑决策 90/90 违约；混合占用消融（3 满载+3 闲型 @30%、真值 3.3 核）：聚合误差——naive 0.99（−2.31，危险）、配额缩放 3.31（+0.01：本例闲型客户突发恰好被 30% 配额封顶，除以配额比例碰巧校正）、节流校正 3.10（−0.20）、满 vCPU 6.00（+2.70）、不封顶 3.14（−0.16）；逐租户——饱和客户两类均精确（1.00），阵发客户上整窗节流占比被空闲稀释（t=0.071）致节流法低估至 0.033/台（真值 0.10）——估计器选择必须依据逐租户正确性与负载形状，聚合巧合不可依赖；多分辨率节流序列（第 9 章模块）即修复该稀释。
• 预测：容量近似模型在物理机首轮验证：φ=0.50 预测 13.3（13 通过、16 失败）、φ=0.75 预测 10.0（10 通过、13 失败）两点命中断点；φ=0.25 预测 20.0（实测 24 通过、28 失败，偏保守）；同步 vs 随机安全容量比 3.5×（主口径，28 vs 8）至 4×（中位口径）；"平均利用率不可辨识安全"的不可能性反例（35%/98%）。
• 行动：隔离是全部风暴中唯一幸存的服务保护手段（物理核级核验）；修复后的相位感知准入在同步场景精确停在 8 台 oracle；KSM 在 64 台同镜像舰队上去重回收 21.4 GiB（33.4% 舰队内存）且服务 P99 0.73→0.76 ms；空闲"1GB" VM 宿主实占仅 156–315 MB、zram 吸收 176.8 GB 溢出——内存密度的关键使能（第 9 章）。
• 复现强度：膝点 100 轮（v2/v3 各 50）、截断 180 cycle（v2/v3 各 90）、三风暴 30 轮（4+26）、细膝点 4 轮、同步 3 轮；统计口径显式（轮聚类、二项上界、P99 主指标），异常（OOM 离线、降级轮、批次漂移）如实归档并已由 v3 返工并入。

1.5 贡献

主贡献（本文主线：识别 + 行动）

1. 识别（截断可识别性 + 跨批次验证）：截断可识别性分析（3.3.1 三命题：运行段均值点估计与精确条件、条件性下界、聚合非可辨识构造）与 90 cycle/30 轮跨批次验证；把"需求估计"从工程公式升级为可证伪的可辨识问题。
2. 行动（相位感知准入 + 干预证据）：风险校准准入的完整规格（伪代码/参数/校准协议）、完整 14 局在线对决（双达标定稿）、C5 反相干预（同租户仅改相位 → 容量 ×2/×4）与细档边界钉定（sync [8,10)、rand [28,32)）；"观测判据的相位盲区"被端到端量化。

支撑贡献（服务于主线，非独立主张）

1. 容量预测（近似模型 + PPC 三工件）：明确假设下的安全容量近似模型与三工件 PPC；如实报告预测质量（4/5 零超接；sync 乐观一例由在线峰值门禁兜底）——预测是"档位建议 + 风险排序"，安全由在线门禁保证。
2. 资源效率账本（支撑密度上限，第 9 章）：CPU/内存/IO 三资源"无回归效率账本"（KSM/FPR 零可见回归；zram/配额/IO 上限明码计价）——"无回归"原则跨资源的扩展验证。
3. 验证平台与工件：嵌套 + 裸金属双测试床、生产只读遥测、全部脚本与原始数据、已并入的 v3 返工批次与轮级范围。

1.6 论文结构

第 2 节相关工作；第 3 节系统模型与问题定义（含 3.3.1 可识别性）；第 4 节测量研究；第 5 节设计（风险校准准入与无回归控制堆栈，含算法伪代码）；第 6 节实现与测试床；第 7 节评估（对决、三风暴、估计器表征）；第 8 节物理机验证与密度定律；第 9 节资源效率模块（KSM/FPR/zram/自适应 IO；含微周期配额的自查更正）；第 10 节讨论与局限；第 11 节结论。

2 相关工作

2.1 云平台的超售与准入控制

超售是云平台资源效率的核心议题。AUDIBLE [1]（ASPLOS 2024）以逐租户经验分布与卷积式统计超售来控制"服务器容量违约"，在超大规模平台上显著提高了打包率；Coach [2]（ASPLOS 2025）利用长期时间模式预测全部资源的互补性，并对竞争进行监测与缓解；Hestia [3]（SIGCOMM 2026）进一步提出以"波动度"（MCV）为指标的负载聚合，把时间互补的工作负载打包在一起以长期稳定超售比。这条主线的共同前提是：平台拥有长期、丰富、可关联的历史数据，且决策对象是"在既定预测能力下的容量账单"。

与之相对，本文关注的是这些工作在小型服务商场景下不可直接迁移的两个盲区。其一是同步性：时间互补与聚合方法之所以有效，恰恰依赖负载在时间上"此起彼伏"；当多个客户的负载因整点任务、批量上线或攻击而同步时，聚合恰恰把尖峰对齐（我们的一分钟周期性尖峰时间线即为直接证据）。其二是可观测性缺口：大平台按账单周期计费、以更长窗口聚合，而小服务商为了自保普遍对客户施加硬配额——配额一旦生效，"用量"就变成被截断的观测，本文第 5 章证明基于它的决策会系统性高估余量（低估真实需求 3.3 倍）。

在准入一侧，Kerveros [4]（OSDI 2023）给出了大型公有云生产环境中的容量记账与缓冲计算；Risk-aware Adaptive vCPU Oversubscription [5]（2024）与 [5]（ProtoHAIL；其同行评审版为 MLSys 2025 的 ProtoRAIL）使用原型模仿学习与人在回路训练产出风险感知的自适应超售比；面向 GPU 集群的共形需求包络 [7]（2024）用共形预测把超售风险写成可校准的包络；SCROOGEVM [6] 通过识别宿主的"静息态"动态调整超售倍率；RSR [8]（2026）用校准区间预测为单个 VM 给出配置建议。这些工作在"预测精度"或"风险校准"维度上已经非常充分，但它们评测的落点是平台侧的容量违约或单机配置，而非小宿主上"哪一种控制手段能真正守住业务尾延迟"。本文用受控对照逐个拆解 CPU 配额、CPU 权重、绑核、内存双闸与 IO 控制，并给出"隔离优先、硬限速次之、不依赖软优先级"的结论——这是上述工作在机制层面没有回答的问题。

2.2 资源控制原语与调度机制

cgroup v2 提供了本文使用的全部控制面：cpu.max（带宽配额，含周期）、cpu.weight（相对权重）、memory.high/memory.max（软/硬内存上限）、memory.swap.max（每 cgroup 的换出上限）、io.max/io.weight/io.latency（块设备限速、权重与延迟保护），以及 PSI 压力信息 [16–18]。Linux 文档说明了语义，但对多租户超售下的组合效果留白。本文的实测补充了几个易被忽略的事实：块 IO 的 cgroup 记账可能落在整盘设备号而非分区；io.weight 只有在启用 BFQ 类调度器时才具备分流能力（宿主默认 none 时形同虚设）；CPU 配额在保护均值的同时制造"脉冲负载"，反过来伤害服务尾延迟；而 CPU 权重即使给出百倍优先级也无法在饱和主机上保护短请求的尾延迟。

在 KVM 调度侧，社区长期关注超售带来的锁持有者抢占与 vCPU 自旋浪费[18]（KVM Forum 2021），2025 年 12 月的内核补丁系列（sched/kvm: Semantics-aware vCPU scheduling for oversubscribed KVM）以 vCPU debooster 与 IPI-aware directed yield 继续改进这一问题。这些机制结果与本文观察一致：超售宿主的尾延迟不是"平均值问题"，把尾延迟压回可控区间的可靠手段是把关键业务从竞争集合中取出来（隔离），而不是在竞争集合内做优先级微调。

2.3 工业实践与工具

Kubernetes 生态以"超售类别"方式表达差异化策略：Inditex 的 k8s-overcommit-operator [10] 按标签给不同工作负载折算资源请求，OpenShift 的 ClusterResourceOverride [11] 通过 request/limit 比例控制节点密度；KubeVirt [12] 提供全局 cpuAllocationRatio，社区提出"每 VM 自定义超售比"的需求（issue #15710，2025-09 提出、2026-02 因未实现关闭），说明按客户分级的超售在真实运营中尚未被良好支持。学术原型 SweetSpotVM/SlackVM [13] 给出"每 VM 多级超售模板 + 本地调度器"的形态；Calabi [14] 的宿主资源管理实践则以 Gold/Silver/Bronze 分层 slice、guest/emulator 分池绑核以及 KSM/zram 内存压缩为组合。本文与这些实践的关系是"证据补足"：分层模板与分级售卖的思想一致，但我们用量化对照说明每种手段的可靠边界——例如内存路径上，压缩/换出恰是被本文要求"默认关闭"的故障路径（无限制时客户被 OOM 杀死、受限时 swap 被耗尽），而"memory.high + memory.swap.max=0"的双闸能在不杀客户、不污染宿主的前提下截断超用。在内存路径上，ORCA [22] 把整合预测与内存超售结合并给出生产部署验证，其"密度—回归"权衡与本文互补。

2.4 测量方法论

在测量方法上，Metior [9]（ASE 2021）关于云性能测试中时间块重采样与分位数置信区间的讨论提醒我们：时间序列的相邻样本不独立，尾延迟比较必须按时间块或独立轮次估计不确定性。本文全部对照实验采用固定 SLO（P99 ≤ 10 ms）、固定到达序列、开放环负载发生器（记录计划/实际发送时间与超时），并对关键结论进行多轮复现（Censoring 7 轮、膝点 5 轮、综合验证 4 次）；未达到该标准的结论在文中明确标注为初步结果。

2.5 定位小结

与时间相关性建模类工作的机制差异（明确边界）。 Coach [2] 与 Hestia [3] 同样利用时间模式，但其机制前提是可迁移/可编排：Coach 依赖长期预测与 VM 类型的保证/超售分区，Hestia 依赖把互补负载聚合为组并调度（控制面预算）。本文场景（单台或少量小宿主、无迁移自由度、无长期历史、需求被配额截断）禁止这些机制，PPC 因此是只读测量驱动的估计器：其新增机制是（i）以逐租户 1 秒相位剖面为输入的联合块自助（在实测联合结构上卷积，而非在边际上），（ii）与 3.3.1 可辨识性边界配套的"点估计 + 尾部口径 + 零超接约束"决策规则。换言之：既有工作回答"如何调度以平滑波动"，本文回答"不能调度时，如何仅凭观测预测安全容量并在线守住它"。

本文不主张新的学习算法或预测理论；它是一篇面向小型服务商的测量驱动的系统研究：把"多资源超售 + 多控制手段"拆成可单独对照的实验单元，量化在短期历史、需求截断与混合突发负载下"哪些结论成立、哪些流传的做法并不成立"，并给出一套经过三重风暴验证的准入与塑形配置。与大型云研究的关系是互补而非竞争：我们的宿主更小、可观测性更差、决策对手更"廉价"——这正是全球大量中低价 VPS 市场的真实运行条件。

3 系统模型与问题定义

本章保持"够用即止"：只形式化后文实验真正用到的东西；不引入不评测的假设。

3.1 平台与租户模型

考虑单台多租户宿主（小型服务商的典型配置）。宿主提供 $C$ 个逻辑 CPU、$M$ 字节物理内存与一个共享块设备（设备限速与记账以整盘设备号为口径）。宿主上运行两类负载：

• 敏感业务（service）：$s$ 台轻量服务 VM，例如状态监控、网关、静态服务，供应商要求其端到端延迟满足服务等级目标；本文以 HTTP 与 Redis 各一台为被测对象。
• 客户 VM（tenant）：$n$ 台超售客户机（典型配置 1 vCPU、若干内存），是收益来源。客户负载由"客户类型"刻画：占空比 $\rho$（工作时间占比）、周期 $P$、相位 $\phi$（可对齐或随机化），以及本机内存驻留量与 IO 强度。本文以"满载（$\rho{=}1$）、阵发（$\rho{\approx}1/3$）、闲型（$\rho{\approx}1/10$）、定时同步（对齐相位）"四类覆盖常见形态。

每台客户 VM $i$ 可受一组控制手段约束（均经由 cgroup v2 接口[15]），记 $a_i = (\mathrm{pin}_i, q_i, w_i, g_i, b_i, \mathrm{swapmax}_i)$，分别对应绑核集合、CPU 配额（cpu.max）、CPU 权重（cpu.weight）、内存软上限（memory.high）、块 IO 上限（io.max）与每 cgroup 换出上限（memory.swap.max）。控制手段不改变客户的配置口径（不迁移、不缩配），与小型服务商的运维能力边界一致。

3.2 服务等级目标与实验指标

服务 SLO：在长度为 $W$ 的评估窗口内，业务请求完成延迟的 $P_{99} \le L$。本文取 $W \in [30, 120]$ 秒（视场景）、$L = 10$ ms，全部实验在事前固定，不随结果调整；窗口内若违反记一次违约窗口。请求由记录"计划发送时间/实际发送时间/完成时间"的开放环发生器以固定速率注入；延迟自实际发送时间起计，发生器自身滞后（schedule lag）单独监控（本床 P99 ≈ 2.3 ms，远小于 10 ms 请求间隔），滞后超过请求间隔的窗口标记为降级、不进入结论；超时（>2 s）与错误单独计数，不计入延迟分位数。尾指标口径：P99 为主指标（每窗口约 3k–12k 个有效样本）；P999 仅作诊断（有效尾样本 <20），不做轮级统计推断。

客户侧体验：以客户 VM 内可测的忙循环迭代率（it/s）为其"工作速率"，在受限/争用下与满载基准（约 55–75 M it/s 视负载形态）比较；该指标用于表达"代价落在谁身上"。

宿主侧证据：逐 cgroup 的 cpu.stat（usage_usec、nr_throttled、throttled_usec）、memory.current/memory.events、io.stat，以及宿主级 MemAvailable/swap、CPU 忙率（3 秒窗口）与 PSI 压力计数[16]。

3.3 需求、截断与观测模型

客户 $i$ 在 $t$ 时刻的真实需求 $d_i(t)$ 指其在无配额、无争用截断情形下愿意消耗的 CPU。可观测用量为

$$u_i(t) \;\le\; \min\big(d_i(t),\; q_i\big),$$

其中截断来自两个来源：显式配额（$q_i$ 生效时被限流）与争用（宿主饱和时所有客户同比例缩水）。二者都会让"用量面板"低估需求；本文把前者（配额截断）作为主要研究对象，并以下述截断证据检测：

$$\text{censored}_i(t) \;=\; \mathbf{1}\big[\Delta\,\mathrm{throttled\_usec}_i(t) > \epsilon \;\vee\; \Delta\,\mathrm{nr\_throttled}_i(t) > 0 \big],$$

即该窗口内客户实际被限流（节流计数增长）。基于 $(u_i, \text{censored}_i)$ 给出两级估计：

• naive 估计：$\hat d_i^{\text{naive}} = u_i$（把用量当需求，对应"看用量面板"的运营习惯）；
• censoring-aware 经验估计器：若 $\text{censored}_i = 1$，设窗口内节流时间占比为 $t_i$，取 $\hat d_i=\min(\text{vCPU},\; u_i/(1-t_i))$。该式假设"被节流期间客户愿意以未节流时相同的速率继续消耗"：对连续满载客户（本文主场景）近似无偏（7.3.2 节三档配额对照误差 ≤9%）；对阵发客户会显著过估（反例已进单元测试：真值 0.3 核、配额 0.2 → 估计 1.0），对间歇饱和可能低估——因此它不是分布无关的保证，而是需要在目标负载族上表征的经验估计器；"至少满 vCPU"作为更保守的兜底。若 $\text{censored}_i = 0$，取 $u_i$：注意 $u_i$ 恒为需求的（弱）下界，无截断只说明配额未截断它，不排除宿主争用造成的缩水。

历史长度同样进入模型：客户在新到达时历史为空（$T_{\text{hist}} = 0$），其需求先验只能来自同类配置的既有客户或保守上界；本文的冷启动讨论以此为前提（专项实验列入未来工作）。

3.3.1 截断的可识别性：从计数器里能恢复什么（修订 v0.2）

观测模型与假设。 窗口 $W$（含若干配额周期 $P$），配额 $q$（核），每周期预算 $qP$。记 $u$ = 窗口平均用量、$t$ = 节流时间占比、$\bar d$ = 窗口平均需求、$\overline{d}_{\text{run}}$ / $\overline{d}_{\text{thr}}$ = 运行段 / 节流段内平均需求。假设：(A1) 单客户 cgroup、工作守恒、无外来争用；(A2) 窗口内预算被耗尽（否则无节流证据）；(A3) $W \gg P$，先忽略周期边界效应。注意：真实 CFS 的 throttled_usec 按 cgroup 的节流状态计时，可能包含节流窗口内的松弛时间；本节等式是带宽式（budget-exhaustion）模型，与实现的残差在末尾如实报告。

命题 1（点估计的真实含义与精确条件）。 预算耗尽时，窗口内总交付量 $uW = qW$（配额被完全消费），且全部发生在"未节流"的时间段里；因此$$\hat d := \frac{q}{1-t} \;=\; \overline{d}_{\text{run}}\qquad(\text{运行段平均需求}),$$且存在偏差恒等式（假设 $d(t)\ge q$ 全窗、无空闲段）$$\bar d - \hat d \;=\; t\,\big(\overline{d}_{\text{thr}} - \overline{d}_{\text{run}}\big).$$由此精确条件为 $\overline{d}_{\text{thr}} = \overline{d}_{\text{run}}$（两段需求均值相同）——需求恒定是充分但不必要条件。非常数反例： $q{=}0.3$、单周期 1 s，需求分段 0.6（前 0.5 s）/ 0.4（0.25 s）/ 0.8（0.25 s）：预算在 0.5 s 耗尽、$t{=}0.5$，$\hat d = 0.3/0.5 = 0.6 = \bar d$，而需求显然不是恒定的。一般情况下：需求峰落在运行段、其后回落（典型突发）→ 过估；需求在节流段内上升（低-高形状）→ 低估；方向由形状决定，不可由聚合量判定。

两个方向的反例（理想模型）。 过估：$q{=}0.5$、$P{=}1$ s，前 0.5 s 需求 1.0、后 0.5 s 需求 0.5；预算在 0.5 s 耗尽，$t{=}0.5$，$\hat d = 1.0 > \bar d = 0.75$。低估：$q{=}0.5$，需求 0.5 持续 0.9 s 后升至 1.0；预算在 0.95 s 耗尽，$t{=}0.05$，$\hat d = 0.526 < \bar d = 0.55$。

命题 2（条件性下界，$d\ge q$ 假设下）。 若 $d(t) \ge q$ 在整个窗口成立（持续饱和、无松弛），则$$\bar d \;\ge\; q\,(1+t).$$证： 运行段累计 $d$ 恰为 $qW$（预算耗尽）；节流段 $d \ge q$ 给出额外下界 $q\,tW$；相加除以 $W$。等号当且仅当节流段内 $d \equiv q$。$\square$边界：该下界的先决条件"全窗 $d\ge q$"无法从聚合计数器验证——它是目标负载族（连续饱和）的性质，而非可对任意客户认证的保证。工程上只在"节流证据连续成立"的客户上以该式作兜底地板（对应 3.3 的保守档），其余客户只报点估计 $+$ 不确定性，不声称下界。

补充边界（反例）："持续节流"与"$d\ge q$ 全窗"并不等价——反例：$q{=}0.2$、每周期前 20% 需求 1.0、其余 80% 需求 0.1；预算仍会在每周期耗尽（节流占比恒 0.8，满足"连续节流"），但真实均值 $\bar d = 0.28$ 小于该式给出的 $q(1+t) = 0.36$。因此工程触发规则是经验保守策略：其方向性为"可能高估 → 准入更保守"（不会导致超接），但不具备认证下界的地位；认证地位仅以命题 2 的 $d\ge q$ 假设为准。

命题 3（聚合非可辨识性）。 存在两个需求过程，其 $(u, t, q)$ 完全相同而窗口均值不同；任何 $(u,t,q)$ 的函数都不可能对所有过程给出正确值（可辨识性不可能），偏差方向亦不可辨识。构造（含节流时长显式核算）。 取 $q{=}0.2$、vCPU $=1$、窗口 = 单周期。过程 A：$d \equiv 5/9 \approx 0.556$（恒不松弛；取 $5/9$ 使 $t$ 精确为 0.64）→ 预算在 $0.36W$ 耗尽，$t = 0.64$，$u = 0.2$，均值 $5/9 \approx 0.556$。过程 B：$d = 1.0$ 占 84% 时长、其余为 0 → 预算在 $0.2W$ 耗尽、节流至 $0.84W$，$t = 0.64$，$u = 0.2$，均值 $0.84$。两者观测 $(u, t) = (0.2,\,0.64)$ 完全相同，均值相差 $0.284$；任何估计器必在其中一例上犯错 $\ge 0.142$。$\square$

P3 的实践含义。 （i）"聚合口径无偏"不可达——估计器只能按目标负载族表征误差方向与幅度（本文立场）；(ii) 恢复需求的结构（相位、占空比）必须依赖时间分辨率（多窗口 $t$ 序列或 1 秒级历史）——这是第 5 章"相位剖面聚合"的理论动机：幅度用截断证据（带保守地板）、结构用时间史；(iii) 安全方向（低估→超接）需要显式兜底：本设计对持续饱和客户启用保守档 $\hat d = \mathrm{vCPU}$。

实测表征（代替保真）。 连续饱和族（主场景）：6.3c 三档配额对照误差 ≤9%；v2 的 90 cycle（450 个客户-窗口，含 90 个离线窗口）：节流判定 + vCPU 兜底给 $\hat d = 1.00$、与真值完全一致；在线的 360 个窗口 $t$ 均值 0.470，纯公式给 0.943（−5.7%）——这正是命题 1 的模型假设与真实 CFS 账目（周期边界、节流状态计时含松弛）之间的残差，兜底后消除。阵发族暴露命题 1 的另一侧：兜底档把 0.3 核真实需求报成 1.0（3.3 节反例），方向刻意保守；间歇饱和族的低估由"不重复允诺 + 暂停"监测器覆盖。

3.4 决策问题

系统在客户到达序列上做两类决策：

1. 准入（admission）：对每个新到达的客户，依据当时的可见证据（历史、截断证据、宿主压力、当前服务尾延迟）输出 allow/defer 及理由；批量到达时需做容量预留，不能把同一份空闲重复允诺。
2. 塑形（shaping）：为已接入客户选择控制参数 $a_i$，以及在被限客户的"松绑/扩容"请求上输出决策。

目标是在服务 SLO（§3.2）不违约的前提下最大化接入量（以 VM 数、VM-hours 或配置加权口径计）；代价（客户侧速率损失、被限客户的排队延迟）单独报告，不隐藏。

3.5 假设与边界

• 客户负载不具对抗性：本文的"满载客户"是合法但极端的负载，如挖矿、编译，不建模恶意攻击；
• 不引入实时迁移、不停用客户 VM、不重配已售资源——这三类动作会改变服务模型，超出首篇范围；
• 测试床为嵌套虚拟化环境（PVE in KVM guest），结果反映"与小型服务商真实拓扑同构"的行为，但不替代裸金属外推；
• SLO 阈值 $L=10$ ms 为本文自定的严格档；容量—质量曲线在评估章对不同档位给出敏感性讨论。

3.6 观测必要性：三个构造性反例与最小充分观测集

本章的组织命题是：安全容量决策的瓶颈在观测能力，而非容量算法。形式化为三个构造性结论（前两者为不可能性/不充分性，第三者界定采样要求；正文按工程口吻呈现，形式化证明与可执行反例见附录 A）：

命题 A（截断不可能性）：在仅有（用量, 节流占比, 配额）聚合计数器的前提下，任何仅依赖这些计数的估计器都不可能对所有负载给出正确值——两个过程可以给出完全相同的观测而需求不同（3.3.1 命题 3 的显式构造）。这是可辨识性意义上的不可能（对观测的确定性函数成立），强于统计意义上的无偏性。推论："看用量面板做松绑/扩卖"不可修复地危险——v2 批次 90/90 次独立判据全部违约（§4.3b）。

命题 B1（容量不由边际决定，构造）：取 N 台租户，每台每个周期 $P$ 内工作 $w$ 秒（逐台边际完全相同）。对齐相位峰值并发 $=N$；随机相位峰值由重叠分布给出（均值 $\rho N$，$\rho=w/P$）。池容量 $C$ 下：对齐容量 $=C$（精确）；随机容量受均值必要条件约束（平均并发 $\rho N\le C$），故 $N\le C/\rho$ 为上界——容量比至多 $1/\rho$（$\rho{=}0.2$ 时即 5）。本文物理实现（§8.4）：主口径安全容量 28 vs 8（3.5×，位于该上界之内；细扫边界 [28,32)/[8,10)），且不安全组利用率更低（30.4% vs 66.4–68.0%）。

命题 B2（利用率阈值不可能性，定理）：设监测窗口长 $L$ 秒。对齐舰队在任意 $L$ 秒窗内的平均交付利用率有硬上限 $U(L)=\big[w\lfloor L/P\rfloor+\min(L\bmod P,\,w)\big]/L$——窗与突发窗的总交叠 $\le w\lfloor L/P\rfloor+\min(L\bmod P,w)$，窗内交付核心秒 $\le C$ 乘该交叠，故利用率 $\le U(L)$。特例：$L\le P$ 时 $U(L)=\min(w,L)/L$（同步实验的 30 s 滚动窗：$12/30=40\%$）；$L$ 为 $P$ 整数倍时 $U=\rho$；$L=kP+r\,(r>0)$ 时 $U$ 可略超 $\rho$，如 $L{=}90$ s：$24/90=26.7\%$。因此任何“窗口利用率低于 $\theta$ 才放行”的准入，只要 $\theta>U(L)$，就对对齐舰队无界超接（安全容量仅 $C$）。实测对应：util80（$L{=}30$ s、$\theta{=}80\%>40\%$）在同步相位卖到实验帽 40 台而其判据读数仅 ~20–40%（§7.4.1）；“35% 忙被压垮、98% 忙安全”即该定理的现场实例。

命题 C（采样不充分性）：设监测以固定间隔 $\Delta$ 采样利用率，突发宽度 $w < \Delta$。存在良性舰队与危险舰队，其采样序列完全相同，例如同为全零而安全容量不同——把突发安排在采样间隙即可。当前证据等级：形式构造 + 间接实测（util80 在同配置两局中停点 28 vs 40，判据对采样时刻敏感，§7.4.1）；直接实验（固定相位、仅变采样间隔的抗混叠对照）仍在队列中——在其完成前，本条按「构造性结论 + 间接证据」引用，不外推。推论：时间分辨率必须不低于所关心的突发形态（本文在线历史取 1 秒；60 s 对齐突发的宽度 12 s ≈ 一个相位桶的分辨率下限）。

最小充分观测集（本文设计即其实现）：

表 1。 观测能力：各自覆盖的失效轴、机制与缺失时的实测后果

证据等级与边界（避免过示）：A、B1、B2、C 均为形式构造/定理（B2 可证），各有实测对应（A：90/90；B1/B2：§8.4 与 util80 同步实录；C：构造 + util80 漂移的间接证据，直接实验列入未来工作）。全部构造的可执行复核见附录 A（tools/theory_tests.py，输出存档 research_data/theory_checks.txt）。「合起来充分」是目标负载族与质量口径下的经验结论（14 局内三者齐备的策略是唯一服务侧双相位不违约、且随机相位客户侧达标者），不是定理；对齐相位客户侧证据（show5）已并入；抗混叠直接实验列入未来工作。

4 测量研究

本章为全文主干，对应图 2–9、17、18。所有数字均来自 research_data/berohost_pilot/ 与 v2 海量复测批次 research_data/v2_analysis/ 存档；每小节末尾给出诚实边界。统一设置：服务侧 SLO 为 P99 ≤ 10 ms；探针以 100 req/s 开放环注入、记录每个请求的计划/实际发送与完成时间；宿主忙率取自 /proc/stat 3 秒窗口；客户侧速率为忙循环迭代率（满载基准约 55–75 M it/s）。

4.1 膝点与瞬时重叠（图 2）

设置。 服务（HTTP、Redis 各一台 1 vCPU 轻量 VM）保持不变；逐级增加"满载邻居"客户（每台 1 vCPU 忙循环，占满一个逻辑核），从 0 到 5 台；每级以 100 req/s 各探测两个服务 20 秒；每级 10 秒稳态；五轮以随机顺序重复。

结果。 跨轮均值（毫秒）：

表 2。 膝点曲线：服务延迟 vs 满载邻居数（5 轮）

观察。 （i）膝点稳定在 3→4 台之间：第 4 台满载邻居加入时，P50 从 1.9 ms 跳至 11.0 ms、P99 从 4.9 ms 跳至 23.8 ms，五轮范围窄。（ii）尾延迟预警早于中位数：P999 在 2–3 台时已显著抖动（14–27 ms），比 P50/P99 的坍塌早 1–2 档。（iii）4 台与 5 台之间 P50 呈非单调（11.0 vs 6.9），单看均值会把 5 台误判为"更好"。（iv）全程零超时：服务"表面仍然健康"，只看错误率或均值无法察觉坍塌。

解读。 当宿主的可运行线程集合持续超过逻辑核数（$C{=}4$，第 4 台满载客户加上服务与探针线程），服务的短请求开始为调度份额排队；坍塌是"瞬时并发跨过容量线"的事件，而不是"平均利用率达到某阈值"的事件（3 台时忙率已 86%，服务仍然健康）。这解释了为什么固定利用率阈值的容量经验（"到 80% 再说"）在本环境失灵，也为后文"管理瞬时性"的设计埋下伏笔。

边界。 单宿主、4 逻辑核；邻居为持续满载（最坏形态）；无任何配额或隔离；结论不直接外推其他核数，但"瞬时并发决定尾巴"的机制与 CPU 数量无关。

4.1b 复测：50 轮扩样（图 17）

设置。 用自动化引擎把 4.1 的流程原样重跑 50 轮（v2 批次，随机顺序、级间稳态、每轮两次探测各 20 秒）。运行期间第 4 号满载邻居客户因宿主内存压力在第 2 轮被 OOM 杀死且未自愈——此后第 4 档（名义 4 台）实际只有 3 台在跑、第 5 档（名义 5 台）实际 4 台。因此按实际在跑的邻居数归并口径：3 台档 = L3 全部 50 轮 + L4 第 3 轮起 48 轮（n=98），4 台档 = L5 第 3 轮起 48 轮（n=48）。

结果（HTTP P99，毫秒；图 17 左侧）：

表 3。 首轮膝点扫描的逐档明细

Redis 同构（3 台 6.8 ms → 4 台 21.4 ms）。回看第 1 轮的 L4 档（当时第 4 台邻居仍在跑，恰为 4 台）= 22.99 ms，同样落在此档分布内。

观察。 （i）3→4 的断崖在 50 轮复测中逐轮复现：48/48 个 4 台档轮次 P99 ≥ 20.7 ms，98 个 3 台档轮次中 93 个 ≤ 12 ms——两档分布零交集（图 17 右侧散点可见）。（ii）绝对水平比首轮 5 轮实验（3 台 4.9、4 台 23.8 ms）略高（7.4/24.4 ms），均值排序与断崖位置不变；该漂移如实记录，可能与宿主长时运行后的状态（近 40 天在线、批次间缓存与碎片差异）有关。（iii）被判违反的阈值不敏感：3 台档即使把阈值放到 13.5 ms 也仅 7% 越线，而 4 台档最低值 20.7 ms——"第 4 台即坍塌"不是采样噪声或阈值选择问题。（iv）v3 返工（五台邻居全程在线，50 轮，图 29）：L2 全部 ≤ 8.0 ms（ε=0 容量仍为 2 台）；但 L3 的越线率显著上移——45/50 轮越线（P99 中位 16.0 ms），与 v2 重建口径（ε≈7%）分歧；两批在 L4 一致 100% 坍塌（L3 越线率 90%、Clopper–Pearson 95% 区间 [78%, 97%]；L4 100%、[93%, 100%]）。即 ε=0 与 L4 坍塌两批一致，唯 L3 的风险预算随宿主环境漂移（同协议、同忙率 87%，绝对水平差异如实记录）——保守口径应以 ε=0 的 2 台为准。

边界与安全口径。 严格零违约口径下（要求全部窗口 P99 ≤ 10 ms），4 核床上真正无违约的最大档是 2 台（L2 全部 50 轮 ≤ 5.95 ms）；3 台档属于风险预算口径：98 个窗口中 7 个越线（ε≈7%；v3 返工批次为 90%，批次漂移见上），4 台档为 100%。因此本文严格区分三种叙述：拐点（均值断崖位置，3→4）、零违约容量（ε=0）与风险预算容量（给定 ε）。控制器 oracle 与容量声明一律使用带 ε 的口径（见 8.4 统一安全定义）；本批次的档位归并依赖运行日志重建（make_v2_figs.py），且基线状态与首轮批次不同（绝对水平漂移）。

4.2 同步突发（图 3、图 4）

设置。 在"6 台定时同步（每分钟前 6 秒工作）+ 2 台阵发 + 2 台满载"的混合客群下，用 120 秒探针记录逐秒延迟；另设两组相位对照：10 台闲型客户"开机时间相近（相位聚集）"与"完全随机相位"（--randphase），以及"随机相位 + 1 台满载"的混合组。

结果。 （i）定时同步场景的时间线呈严格周期性（图 3）：

安静段:   P99 ≈ 2–3 ms
突发窗:   P50 升至 4–8 ms，P99 14–22 ms（最高 33 ms）
突发结束: 回落至 2–3 ms；60 秒后重复

四次复现（p3、p3b、p3c、p3d）：整体 P99 13.1–22.6 ms，全部违约。（ii）相位对照（图 4）：10 台闲型客户相位聚集时 P99 10.2–17.3 ms（违约）；完全随机相位时 2.7–3.8 ms（两轮均无违约）。（iii）随机相位下仅混入 1 台满载客户：P99 14.0–20.8 ms（四轮 p6/p6b/p6c/p6d，全部违约）。

解读。 "平均很闲"与"尾巴干净"是两回事：闲型客户群体在任意瞬间仍有非零概率同时醒来；同步（有意对齐或开机时刻的偶然聚集）把这个概率变成规律性事件。定时同步是最清晰的病态样本；而生产环境更接近"随机相位 + 少数常驻重负载"的混合——第三节的膝点与这里的满载混合共同说明：一台持续满载客户加上随机重叠，就足以击穿严格 SLO。这为"短历史/冷启动"问题提供动机：新客户到达时无法知道它是长期轻闲型还是持续满载型。

边界。 对齐突发是人为构造；相位聚集由同时开机造成（真实生产中新客户开机时间天然分散）；负载均为合成的忙循环/占空比模式，非真实业务。

4.3 CPU 配额下的需求截断（图 5）

设置。 5 台客户均为满载（真实需求各 1.0 核），每台以 cpu.max = 30000/100000（平均 30%）限速。分两阶段测量：限速态（配额生效）与松绑态（模拟"信用量面板、认为有余量"的运营决策，撤掉配额）。共 7 轮（c3 三轮、c4 两轮、c5 两轮），每阶段以 100 req/s 各探测两个服务 30 秒，并读取逐 VM 的 cpu.stat 差值。

结果。 （i）估计：限速态下 5 台合计可观测用量 1.50 核（每台 0.30），而节流证据（nr_throttled 每 63 秒增长约 440–450 次、节流时长占比约 0.3–0.7）揭示真实需求为 5.00 核——低估 3.3 倍，7/7 轮一致。（ii）服务侧（毫秒）：

表 5。 随机 vs 对齐相位：5 轮服务尾延迟

松绑后各客户速率约 27–32 M it/s（约为满载基准的一半），宿主瞬时饱和，服务 P99 7/7 轮违约，且比限速态进一步恶化 5–10 ms。（iii）限速态自身也并非"温和"：配额把连续负载切成脉冲，服务 P99 在 SLO 线附近波动（9–14 ms），有时越线。

解读。 截断有两个叠加后果。其一是估计偏差：用量面板显示"还有 2.5 核余量"，真实状态是已经超载 25%；基于它的松绑/扩卖决策会把隐藏缺口变成公开事故。其二是脉冲税：配额在保护均值的同时制造周期性突发，本身就在伤害尾延迟（与 4.4 的配额对照一致）。censoring-aware 的估计（截断证据 + 节流比例 → 有假设的点估计 $u/(1-t)$；其精确条件与反例见 3.3.1，7.3.2 节验证误差 ≤9%）得到 5.00 核，正确报告"无余量、需容量动作"，避免了松绑决策。

扩样返工（v3cen，30 轮 × 3 cycle = 90 cycle，5 台 @30%）。 naive 均值 1.54 核 vs 真值 5.59 核（低估 3.6×）；节流校正 |误差| 中位 0.55 核、88/90 cycle 在 ±20% 内；naive 90/90 低于真值的 70%——方向与幅度在独立批次复现；校正非精确（这正是 3.3.1 将其定位为经验启发的原因）。

边界。 单一配额水平（30%）；客户负载为满载忙循环；限速态的 SLO 命中情况在 SLO 线附近波动，应理解为"这台宿主已处于过载边界"，正确的后续动作（迁移/升配/拒接）超出本文的在线决策范围。

4.3b 复测：90 个 cycle 扩样（图 18）

设置。 v2 批次把 4.3 流程自动化重跑 30 轮 × 3 cycle = 90 个 cycle（配额口径 50%、4 台客户在跑——第 4 台客户在批次早期因宿主内存压力离线；客户仍为满载真实需求各 1.0 核）。每 cycle 限速态/松绑态各探 30 秒。统计口径：90 个 cycle 全部计入，但同一轮内 3 个 cycle 时间相关——轮级不确定性按轮聚类计算（不是把 cycle 当独立重复）；90 个离线窗口（每 cycle 一台）与在线 360 个窗口分开报告；离线窗口的节流证据为空、估计记零，属"客户离线"事件而非"无截断"。

结果（图 18）。（i）估计：90/90 个 cycle 中，用量面板口径 2.00 核（4 × 0.50）而节流证据校正后 4.00 核——与真值 4.0 核完全一致；即"限速一半 → 少报一半"，逐 cycle 无一例外。（ii）服务侧：限速态 HTTP P99 均值 11.4 ms（范围 9.1–14.6，98% 的 cycle 已越 10 ms 线）；松绑态均值 24.7 ms（范围 20.6–28.9），90/90（100%）违约，且 90 个 cycle 的最低值（20.6 ms）仍高于限速态 95% 分位。

因果澄清。 需要区分两种表述：限速态本身已在 SLO 线附近波动（均值 11.4 ms、约 98% 的 cycle 越线），因此松绑决策的后果是把已有的过载条件显著恶化，而不是“从合规状态首次越线”；本文的因果主张以后者为准（估计误差 → 错误松绑 → 延迟恶化），不以“首次越线”为叙事。

读法。 与首轮 7 cycle 实验（5 台 @30%，naive 1.50 vs aware 5.00）方向一致、结论更硬：截断造成的低估倍数恰等于配额比例（本例 2×），节流证据把它精确复原；而"基于少报的松绑决策"在 30 个独立轮（90 个时间相关 cycle，按轮聚类）中 100% 把服务推出 SLO。两组参数（30%/5 台与 50%/4 台）叠加，说明该失效与具体配额水平无关。

边界。 同 4.3；本批次 4 台客户口径（一台离线）。

4.4 控制手段的可靠性（图 6–9）

本节把"保护服务尾延迟"的希望逐一押在五种手段上：CPU 配额、CPU 权重、绑核隔离、内存双闸、IO 限速（附 IO 权重反例）。

4.4.1 CPU 配额：约束均值，不增加安全席位（图 6）

把新客户分别限到 0.75 核与 0.5 核后重跑邻居扫描：两者的安全膝点没有改善（第 4 台无论限到 0.75/0.5 仍全部违约，服务 P99 14.0/11.2 与 15.2/11.3 ms；ε=0 口径与批次漂移见 4.1）；代价却是实打实的客户速率下降（约 72–78% 与 48–53%）。配额脉冲对照（qp1）：把周期从 100 ms 拉长到 1 s 无改善（P99 12.0 ms）；"错峰周期"（100–300 ms 混合）略好（10.7 ms）但仍不达标。结论：给新客户限速换不来更多安全席位，只会降低客户速率并加剧尾延迟。

4.4.2 CPU 权重：即使百倍优先级也不护尾（图 9）

把服务 VM 的 cpu.weight 提高到 1000、复核轮提高到 10000（对客户默认 100 的 10×/100×），在 5 台满载客户下服务 P99 分别为 25.4/22.8 与 24.0/22.7 ms——比不加权（历史 5 台满载 21.6/19.5 ms）还差，与"权重应优先照顾服务"的直觉相反。IO 权重（io.weight 50 vs 500）在本床的调度器配置（none/mq-deadline）下同样无效果——注意这只否定所测配置下的权重路径，不否定内核的 io.cost（iocost 权重分配）与 io.latency（独立时延保护机制），二者本文均未启用评测（见 4.4.5 与 5.2 的边界）。结论（限定条件下）：在本床的调度器与负载组合中，软优先级不是尾延迟保护手段；可靠的是隔离。

4.4.3 绑核隔离：本测试床全部风暴中唯一幸存的保护手段（图 6、10）

把服务+探针绑到核 0–1、客户绑到核 2–3 后，1–5 台满载邻居全程零违约（P99 2.9–3.2 ms）；客户按预期分享剩余两核（第 5 台时每台约 44% 满载速率）。三重风暴综合验证（4.5 节）四次复现该结论。代价被明确转移到"经济版"客户侧：被隔离保护的服务不再参与竞争。

4.4.4 内存：双闸止血（图 7）

无限制增长实验（10 台客户 ballast 渐进占用）：客户合计约 13.8 GB 时宿主 1 GB swap 耗尽，2 台客户 VM 被 OOM 杀死、多台客户 SSH 无响应；服务因占用小反而无恙。加 memory.high（1000/800 MB）后零死亡、宿主稳定，但被限客户触发的回收几乎全部落在匿名页换出上——小 swap 被迅速耗尽并成为全局瓶颈，客户经历短暂无响应。把 memory.swap.max 一并设为 0（双闸）后，超用被原地节流、不再消耗宿主 swap。另注意：关闭 balloon 时，客户"碰过"的内存直到 VM 重启才归还宿主——动态归还与"不压缩"之间存在明确取舍。

4.4.5 块 IO：硬限速有效，代价在肇事方（图 8）

10 台客户同时跑 4K 随机读写（70/30，O_DIRECT）时，宿主被推到约 16.5k IOPS，服务 P99 被连累至 12.1 ms（违约）——尽管服务几乎不碰磁盘（IO 风暴经宿主全局路径波及服务）。给每台客户 io.max = 300 riops/150 wiops 后实测精准生效，宿主降至 2.6k IOPS，服务 P99 回到 2.7 ms；代价是被限客户的读完成 P99 升至约 96 ms（排队在被限方）。两个操作细节：cgroup 的 IO 记账口径落在整盘设备（8:0）而非分区；本床调度器为 none/mq-deadline，io.weight 在所测路径下无效（io.cost/io.latency 不在本文评测范围，见 5.2 边界）。

本节边界。 服务为轻量 VM（CPU 上占核少）是"绑核隔离"成立的前提；权重失效的机制解释（宿主收包路径/调度信用动态）留待后续深挖；内存数字与 1 GB swap 环境绑定。

5 设计：风险校准准入与塑形手册

本章把第 4 章的测量结论组织成小型服务商可执行的决策框架。设计原则只有两条：（i）绝不依赖被测量证伪的机制（软优先级、平均利用率、未校正的用量）；（ii）把"保保护"与"做生意"分层——服务的 SLO 用隔离守护，客户的密度用证据换。

5.1 总览

框架分两层，对应运营中的两类动作：

• 塑形（Shaping）：决定每个已被接纳的客户"以什么形态竞争资源"。塑形定义了宿主的保护包络——哪些资源在什么条件下被守住、守住到什么程度。第 4 章的结论凝练为一句：隔离优先、硬限速次之、软优先级不采信。
• 准入（Admission）：决定新到达的客户"能不能进来"。准入在塑形给定的保护包络下，用经过截断校正的需求证据估计余量并做出 allow/defer 及理由。

两层共用一组监测器（服务尾延迟、宿主压力、逐 VM 截断/限流证据、数据质量），监测器同时充当准入的"暂停开关"。

5.2 塑形手册

CPU。 第一步、也是在本测试床全部风暴中被验证有效的唯一一步：为敏感业务划出专属核。把服务与探针线程绑定到 $c_{\text{svc}}$ 个逻辑核（本测试床取 2），客户 VM 绑定到其余核上竞争（taskset/cpuset；PVE 下可直接对 qemu 进程 taskset -apc）。服务占核越轻，这一步代价越小。第二步（可选）：对客户加 cpu.max 配额——注意其角色是商业分层与成本控制（谁买多少档），而不是"多接客户"的手段：实验证明配额不改变安全膝点（第 4.4.1 节），只改变客户自己的速率。不使用 cpu.weight 作为保护手段（第 4.4.2 节：百倍权重也不护尾）。监测器：服务 P99/P999 与调度等待（可用时）。

内存。 双闸 + 预留：对每台客户设置 memory.high（热内存预算，保证 $\sum \text{high} \le M_{\text{hot}}$，$M_{\text{hot}}$ 取物理内存扣减宿主与业务预留后的值）与 memory.swap.max = 0（禁止超用客户消耗宿主换出空间）。宿主 swap 留给业务侧或直接关闭——第 4.4.4 节证明 swap 是"回收税"的放大器：让 swap 上限不设时，被限客户的回收会把小 swap 耗尽并成为全局瓶颈；双闸把超用变成"原地节流"。若产品承诺"不压缩"，还需在售卖口径上明确：关闭 balloon 时客户"碰过"的内存不会归还宿主（动态归还与不压缩二选一），热内存预算即真实可交付内存。

块 IO。 对每台客户设 io.max（按售卖的档位给 riops/wiops 或带宽），这是本文评测范围内对 IO 风暴唯一实测有效的止血：宿主 IOPS 与业务延迟立刻回稳，代价落在被限客户自己的排队延迟上（第 4.4.5 节）。实现注意两点：cgroup 记账以整盘设备号为准（分区号可能无效）；本床的宿主 IO 调度器为 none/mq-deadline，io.weight 未产生可测效果。边界（避免机制混淆）：io.weight 的权重分配另有 io.cost（iocost）路径，其不依赖 IO 调度器；io.latency 是独立的时延保护机制（保护目标租户而非限制造事者）[17]。本床未启用评测 iocost 与 io.latency，本文结论只覆盖所测路径与配置。

保护包络的表述。 "卖 16 vCPU / 48 GiB / 400 GiB"是名义售卖包络；保护包络是：服务侧 $c_{\text{svc}}$ 个专属核上的 SLO 承诺 + 客户侧每台 $\text{high}$ 的保真内存 + 每台 io 上限的 IO 能力。两者之差就是"经济版"的产品空间——分层定价的依据。

5.3 风险校准准入

输入（决策时可见）。 逐 VM 历史（用量序列）；截断证据（nr_throttled/throttled_usec 增量）；同类配置的历史队列（先验）；宿主状态（忙率、压力信号、服务尾延迟监测器的最近整窗）；到达批次的规模。

需求估计（经验截断校正）。 对每台已接入客户：若截断证据为真，用节流时间占比 $t_i$（$\Delta$throttled_usec / 窗口时长）计算 $\hat d_i=\min(\text{vCPU},\; u_i/(1-t_i))$——经验估计器：连续满载场景近似无偏（7.3.2 节 ≤9%），阵发过估、间歇可能低估，假设与边界见 3.3 节；"至少满 vCPU"作为兜底。若截断证据缺失，采用窗口化历史分位数（逐窗 $u/(1-t)$ 的 P95）。可选的错峰松弛探针（限时 2 秒放开配额直接观测需求样本，逐台错开、代价有界）作为直接测量通道。对新到达客户（$T_{\text{hist}}=0$）：使用同类配置客户的截断校正估计作为先验；当同类样本不足时退化为"满 vCPU"——即把冷启动风险先算成最坏情形，观察窗口内再逐级放宽。

决策规则（时间对齐聚合）。 维护 1 秒分辨率的逐 VM 历史；对已接入集合按墙钟相位剖面（各 VM 每秒位的需求上包络）预测未来决策跨度的聚合需求峰，并以实测聚合需求的分位数作为背景预留。候选客户的计账口径要区分尺度：配额只约束一秒钟尺度的平均消耗，不约束亚秒突发——周期 $P$ 内客户可以先全速燃烧其预算（例：50% @ 100 ms 前 50 ms 满速），这正是 4.4.1 实测的"配额脉冲税"。因此：(i) 容量计账用 $\min(\text{1 秒峰值},\ \text{配额})$ 作为一秒尺度上限；(ii) 尾延迟保护不依赖配额（服务 SLO 是毫秒级，必须在相位剖面上按实测突发结构计账，或对该客户做错峰安排）；(iii) 对无历史的新候选，用同类客户的突发先验并保守起步、观察窗内逐级放宽。预留 + 候选上限 $\le$ 客户侧有效容量（$\times$ 利用预算）时放行；批量到达先做容量预留，同一份空闲不得重复允诺。

校准与暂停。 安全余量在独立验证窗口上按"实测违约预算"标定（经验校准，报告实测覆盖而非分布无关保证）。以下信号触发暂停新准入（带滞回恢复）：服务尾延迟监测窗越线；客户侧金丝雀（唤醒停顿/速率）越线；估计不确定性过大（历史过短/区间过宽）；数据质量事件（缺失、计数器重置、刷新周期变化）；漂移（分布变化、新配置类型到达）；宿主压力信号持续越线。恢复需要连续稳定窗口，阈值只在训练/验证集合上确定。

决策跨度。 默认 5 分钟，敏感档 1/15 分钟；该跨度只是控制器刷新节奏，不构成任何长期服务承诺。

5.3.1 准入算法：伪代码与参数（评审要求的可实现规格）

算法 A（风险校准准入；到达事件或每 Δ 分钟触发）
输入: 已接入集合 S（逐秒用量史 u_s(t)、最近 120 s；截断证据 t_s；宿主忙计数；容量 C（租户核）；
      利用预算 0.9）
1  对每台 s ∈ S:
      f_s ← min(2.5, 1/(1 − t_s))，当 t_s > 0.02；否则 f_s = 1.0   # 截断校正（关闭校正臂：f_s = 1）
      p_s[b] ← 最近 120 s 内 min(vCPU_s, u_s(t) · f_s) 的逐桶最大值，桶 b = t mod 60
2  peak ← max_b Σ_{s∈S} p_s[b]                     # 相位剖面聚合峰（已接入集合）
   residual ← 宿主忙核数（独立计数器）− Σ_s mean30(u_s)
   bg ← max(0, Q95(最近 20 个残差) − 0.2)           # 实测背景预留（不与 peak 重复计账）
3  π ← 已接入客户平均速率的中位数（无历史时取 0.2）    # 新候选的类先验
   低历史护栏：超过 1/3（且至少 2 台）的已接入客户样本 < 30 条 ⇒ defer
4  if peak + |B| · π + bg ≤ 0.9 · C: allow；否则 defer（记录命中项）
护栏（与主循环并行）：服务 P99 窗越线 ∨ 金丝雀唤醒停顿 > 250 ms ∨ 客户 P5 < 70%
   ⇒ 暂停准入；连续 3 个稳定窗后滞回恢复
校准协议: 0.9 与滞回窗在一次性固定的独立验证集上选取；报告单侧 Clopper–Pearson 上界与达到目标
上界所需独立试验数（零失效：≤10% 需 ≥29 次、≤1% 需 ≥299 次）——以“经验安全护栏”表述，
不构成 1% 保证。

记账尺度与残差风险（防低估论证）。 容量预留工作在1 秒尺度：需求上包络取实测逐秒用量并按 $\min(\text{vCPU},\ u\cdot f)$ 封顶（配额是周期预算而非瞬时上限，故不以 $q$ 封顶包络；持续饱和时该式自然逼近整核兜底，见 3.3.1）。但配额允许亚秒脉冲（周期内前段满速，4.4.1 实测），故 1 秒记账并不保证亚秒尾延迟——本文不让容量计账承担该责任：服务尾延迟由隔离 + 服务侧护栏（P99 窗/金丝雀暂停）兜底，暂停护栏的触发与容量放行解耦（护栏越线即刻关闸，与预测误差无关）。因此三者的证据链是：秒级竞争风险由剖面预测覆盖，亚秒风险由隔离与护栏覆盖，二者不叠加承诺。

参数表（默认值 → 依据）：Δ = 5 min（刷新节奏；敏感档 1 min）；u = 0.9（独立验证集标定）；历史窗 120 s（= 2 个 60 s 周期）；背景预留 = 剖面预测的残差 Q95（避免与 peak 重复计账）；金丝雀阈值 250 ms / 1 s（j1 实测停顿量级）；持续饱和客户的整核兜底由 $\min(\text{vCPU},\ u\cdot f)$ 实现（3.3.1 命题 2 的边界）；候选按类先验 π（已接入客户平均速率中位数）计账。

5.3.2 安全声明的认证协议（统计口径）

目标。 对任一配置/负载族的"轮级违约率 ≤ ε"给出单侧 95% Clopper–Pearson 上界，并显式报告"达到该声明所需的最小独立轮数"。

零失效预算表（上界 $U(n) = 1-0.05^{1/n}$）：

表 6。 零失效预算：Clopper–Pearson 上界 vs 独立轮数

相关性修正。 轮间共享宿主状态（长时漂移、缓存、同批次 VM 状态）→ 独立假设只是乐观上界；协议要求 (i) 按时间块/轮聚类计算有效样本量，报告"有效轮数 < 名义轮数"；(ii) 以块级最坏窗口作敏感性分析；(iii) 任何"零违约"陈述必须附本轮数与上界。

协议范围。 本协议规定的是安全陈述的写法与其应携带的证据，本身不是保证；本文各实验显式携带轮数与实测上界（如 29/30 包络通过对应乐观单侧上界 ≈14.9%），不构成 1% 风险证书。

序贯预算（本文采用）。 pilot 10 轮（粗筛）→ 30 轮（可声明 ≤10%）→ 90 轮（可声明 ≤3%）→ 300 轮（1%，仅限关键结论的长期计划）。本文映射：三风暴 30 轮（29/30 通过；乐观独立假设下单侧上界 ≈14.9%）；截断 180 cycle（两批各 90）；膝点按轮聚类报告。不声称 1% 保证（299 轮超出当前预算，列为长期项）。工具：tools/certify.py（一键计算任意轮数与目标的上界/所需轮数）。

5.4 与朴素策略的差异（一句话各表）

表 7。 朴素策略：各自看不见什么与实测后果

5.5 假设与局限

• 本设计不含"分布无关的风险保证"；对任意漂移与对抗负载，只承诺监测与保守化行为；
• 需求估计器是经验估计器：其跨模式误差/覆盖率/最坏低估表征（5 种负载模式 × 3 档配额 × 3 种配额周期 × 多 vCPU，各 10 轮）为 v2 专项；本文只承诺目标负载族（连续满载为主）上的经验边界；
• 校准/暂停的消融与阈值敏感性：v2 以四路公平对决（naive / AUDIBLE 式 / aware / 时间对齐 taligned）×10 轮重测，并含内存闸门 800/1920 MB 对照；
• 塑形手册中的 CPU 配额仍是可选件——若产品不存在分层售卖需求，可以只保留"隔离 + 内存双闸 + IO 上限"。

6 实现与测试床

6.1 测试床

测试床是一台与小型服务商生产拓扑同构的嵌套宿主：PVE 8.4.21 [19]（Debian 12 基础）运行在 KVM 客户机内（systemd-detect-virt=kvm，/dev/kvm 与 vmx/svm 均可用），报告 4 vCPU（AMD EPYC 9575F）与 19.5 GiB 内存、单块 200 GB 虚拟磁盘（cgroup 记账设备 8:0）、1 GB swap。默认关闭 balloon [20]（内存归还与"不压缩"的取舍见 §4.4.4）。宿主空闲基线忙率约 2–4%；实验期间除被测组件外停用一切后台任务（本地 NIE-SLA 探针、各 VM 的 apt/man-db/fstrim 定时器）。隔离的边界：guest 内 4 个 vCPU 呈现为 4 个独立核（SMT 关闭），"服务核 0–1 / 客户核 2–3"在 vCPU 级不相交；但 guest vCPU 到 OVH 物理核的放置不受本文控制，本床不能证明物理核级隔离——物理核级隔离（SMT 兄弟核验 + NUMA 归属）以裸金属测试床为准（第 8 章 8.1）。

负载拓扑：服务 2 台（HTTP/nginx、Redis，各 1 vCPU/1 GiB）、探针 1 台、客户 16 台（1 vCPU、3072 MiB；早期部分实验为 1024/5120 MiB，见各节说明）。全部 VM 由统一的 Debian 12 cloud 模板克隆而来（cloud-init 注入网络与公钥），客户机内不安装任何常驻组件。

6.2 工具链（全部脚本随文提交）

表 8。 随文提交的实验驱动与分析脚本

控制面操作全部通过 cgroup v2 原语完成：cpu.max/cpu.weight、memory.high/memory.swap.max、io.max/io.weight（对 qemu.slice/<vmid>.scope），绑核通过 taskset -apc 作用于 qemu 进程全部线程；宿主侧忙率与内存取自 /proc/stat、/proc/meminfo，逐 VM 服务量与截断证据取自各 scope 的 cpu.stat（usage_usec、nr_throttled、throttled_usec）。

6.3 AI 辅助工具的使用

AI 助手在准备过程中用于语言润色、代码审查与文稿组织。全部实验设计、执行、数据核验与科学结论均为作者本人完成；所有报告数字均已对照存档原始日志核验（见“声明”节）。

6.4 生产遥测的只读采集

两台真实生产宿主仅做匿名只读遥测：经 PVE 只读接口（pvesh get /nodes、/nodes/{node}/status、/cluster/resources）与 /proc 读取 CPU 服务量、限流计数、压力信号、内存与生命周期事件，60 秒粒度、目标 7 天；远端进程在内存中对 VM/节点 ID 做 HMAC 匿名化，不采集 VM 名、IP、业务内容与磁盘数据；不安装组件、不更改客户配额、不做任何压力测试。凭证以一次性口令完成密钥交换后弃用，密钥仅存于研究者工作站。

6.5 可复现性

测试床脚本、全部原始数据（截至 2026-10-12：335 个逐请求原始文件、44 个 JSONL、汇总脚本；v2 海量复测数据在测试床归档待回传）与实验协议已随文存档；数据字典（字段、单位、口径、质量标记）与执行日志（含每次环境改动与异常）一并提交。所有"违约"判定使用事前固定的 SLO 与窗口定义；被拒绝的候选负载不启动，评测输入保留其计划需求，不存在按结果挑选运行的事后筛选。

7 评估

本章汇总三类评估：（A）准入策略对照；（B）塑形与保护包络对照；（C）三重风暴综合验证。另附生产遥测的使用现状与明确的缺口清单。统一 SLO：服务 P99 ≤ 10 ms。

7.1 设置回顾

测试床与指标见第 3/4 章与第 6 章。准入对照采用"5 个候选客户逐个到达、策略依据当时可见证据决策 allow/defer、允许后实测窗口"的闭环协议；塑形对照采用逐级扫描（0–5 台邻居）+ 综合风暴；每项关键结论至少两轮复现（膝点 5 轮、Censoring 7 轮、综合验证 4 次）。

7.2 准入策略对照（图 4 配套表）

四种策略在同一到达序列与同一证据面下运行（两轮不同顺序）：

表 9。 两轮准入预实验：各策略承诺席位数与违约窗

读法。 固定倍数不看任何状态、径直越过膝点（第 4 章），4 个违约窗是最好的反例；三种"看状态"的策略都在膝点（3 台）停下且零违约——说明膝点可由证据触达。候选策略更保守但暴露了一个实现问题：单窗 P999 抽样噪声大（n≈2），B 轮被一次 16.3 ms 尖峰误触发而少接 1 台。这正是"暂停机制需要平滑/滞回/更长窗口"的直接证据（已列入改进项）。预实验的公平性说明：策略全部只使用"决策时可见"的信息；每台的允许与否都真实执行（未接入的候选不启动负载），不存在"事后挑最优"。

7.3 截断校正决策（核心主张的直接对照）

第 4.3 节的场景升级为决策对照（7 轮）：同一状态（5 台客户、各限 30%、真实需求 5.0 核），两种决策：

表 10。 截断校正决策：证据、动作、结果

读法。 两组决策使用同一份数据、只是估计方式不同：naive 把被截断的用量当需求，得出"还有一半空间"的幻觉；aware 用节流证据把需求下界钉在配额以上。前者的动作把宿主推入瞬时饱和（客户 27–32 M it/s、宿主 100%），后者避免了这个自伤动作，并给出正确的容量信号。限速态本身贴近 SLO 线这一细节如实保留：该宿主已处于过载边界，上限动作（迁移/升配）超出本文范围。

7.3.1 方法消融与冷启动（预实验，图 11）

消融（截断场景）：六个客户逐个到达、到达即限速 50%，四种估计/决策正面对撞：

表 11。 冷启动预实验：6 个候选中准入的席位数

冷启动（无历史新客户）：两类到达人群 × 三种先验：

表 12。 冷启动估计器：全重载 vs 全轻载到达

读数：乐观先验在满载人群里必翻车；静态保守先验安全但损失一半席位；“先保守、观察后放宽”同时拿下两边。两表共同支撑第 5 章的设计原则：先验由证据决定，且必须有代价意识。

7.3.2 截断校正估计器的经验验证（b2，图 12）

五个满载客户分别在配额 20%/40%/60% 下测量：由可观测的"配额 + 节流时间占比 $t$"计算 $\hat d = \min(1,\; u/(1-t))$；随后逐台临时放开配额（其余保持受限）测得真值，避免五台互抢污染真值：

表 13。 估计器验证（b2）：配额、节流占比、估计 vs 真值、误差

读法（经验边界）。 本表验证的是估计器在连续满载族上的表现：宿主侧 counters（配额 + 节流计数）把它恢复到误差 ≤9%。但这不是一般性保证：同一组 counters 对阵发负载会显著过估（反例已进单元测试：真值 0.3 核、配额 0.2 → 估计 1.0），对间歇饱和可能低估；"方向保守"只在连续满载族成立。因此本文将其定位为经验截断校正估计器（假设与边界见 3.3 节），跨模式误差/覆盖率/最坏低估表征（5 模式 × 3 配额 × 3 周期 × 多 vCPU）为 v2 专项；估计器已并入设计（5.3 节）。

7.4 塑形对照：安全打包上限与代价（图 6）

在同一膝点协议下比较四种塑形（服务侧 SLO 口径相同）：

表 14。 塑形对照：各配置的实测安全上限与客户代价

读法。 只有隔离把"安全上限"从 3 抬高（到 ≥5）；配额改变的是客户的速率而不是上限（第 4.4.1 节），位置互换很直观：隔离把代价从"服务 SLO"挪到"经济版客户"，配额则两头受损。附加防线：内存双闸与 IO 上限分别在第 4.4.4/4.4.5 节证明其对各自风暴的止血作用——它们不抬 CPU 膝点，但防止另两类风暴把服务一并拖入违约（综合验证的必要件）。

7.4.1 在线准入对决（图 20）

协议。 在 8 核租户池上，7 个策略（worstcase 配额保守 / fixed 固定 2× / util80 80% 忙率 / quantile 历史分位 / audible 式 MC 卷积 / ours 相位剖面 / ours_p 相位剖面+暂停护栏）× 2 种相位（随机 / 对齐），使用统一到达流（每步 +2 台、25 s 稳定、15 s 双服务探针）与统一可用证据（同一套 cgroup 计数与历史）；客户负载 20%/60 s 占空比。口径：14 局 = 7 策略 × 2 相位（每格 1 局；另有 show4/show5 二轮复测与 show6 到达顺序复测）；"audible 式"= 独立边际卷积核的简化蒙特卡洛对照实现（非完整 AUDIBLE 系统）。质量口径为 §8.4 主口径（服务 P99 ≤ 10 ms 且客户速率 P5 ≥ 70%）；容量参照取同口径已验证阶梯档位（随机 28 台 / 对齐 8 台；细扫边界 [28,32)/[8,10)）。指标：停止席位、首次违背档位、安全 VM-hours（首次违背前 $\sum n_i \Delta t_i$）、以及相对 oracle 的差距。

v1 初步（10 局，旧采样口径，如实标注）。 fixed 停 16、quantile 停 8、util80 无止损（冲到实验帽 40；50% 地板口径下 n=30 起出现慢客户）、audible 在对齐场景放开至 40（独立性假设抹掉相位相关性——正是其已知失效模式）；修复后的 ours 在对齐场景停在 8 台 = oracle（剖面峰值计数 0→2.01→4.02→6.01，第 10 台预判 8.4>7.2 而拒绝）。v1 的随机相位前 4 局为旧格式（无逐客户速率），故本节结论以对齐场景与决策轨迹为主。

v2 完整 14 局（图 20）。 统一到达流、统一证据、主口径（服务 P99 ≤ 10 ms 且客户 P5 ≥ 70%）；停点表（✅=全程未违主口径；⚠=停点越线后继续/未止损）：

表 15。 在线准入对照：各策略/相位的停点与违约证据

实现范围说明。 对决中的 ours 实现的是 Algorithm A 的相位分辨门（逐秒历史 → 60 相位桶峰值计数 + 固定 10% 余量 + ours_p 的客户 P5 暂停）；Algorithm A 的完整链（截断需求校正 + 背景残差 Q95 预留 + 服务/客户双护栏暂停）实现为 ours_full（tb_admit.py），完整链端到端运行（show7）与组件消融（show8）见 §7.4.2——本表结论对应前者。

观测轴归因（§3.6 命题的实测对照）：

表 16。 观测轴归因：各策略缺失能力 vs 实测失效

三条结论。 （i）相位感知控制器（PPC）是唯一同时做到“随机相位 16–20 台”与“对齐相位停在 8 台断档”的策略。ours 与 ours_p 均停 8：剖面峰值计数 6.0+0.4 ≤ 7.2，第 10 台预判越线即拒；细扫确认边界 [8,10)，10 台客户 P5=62.2% 为首失败档。worstcase 与 quantile 在随机相位也只卖 8，fixed 在两相位都卖 16。（ii）平均利用率类判据的相位依赖性被直接量化：util80 随机卖 28 台是安全的，同步卖 40 台时客户 P5 崩到 16%——同一策略、同一硬件，仅相位不同，风险两极；audible 式同样在同步崩，暴露出依赖独立性的卷积模型盲区。（iii）fixed 与 worstcase/quantile 分别验证了另两极：前者在两个相位都固定卖 16，同步档违主口径；后者永远只卖 8，随机相位白让 2–3 倍容量。安全 VM-hours 与轮级区间在多轮复测汇总后并入补充材料。

采样口径说明：v2 sync 局的客户速率采样存在顺序缺陷（探针先于速率采样把采样推出 60 s 突发窗），audible/util80 因相位漂移侥幸捕获（n=18 起 P5=16% 的违约证据有效），fixed 等局的 p5 缺失；修正版全 7 局重跑（show5）已完成；表内 sync 客户列以 4 轮阶梯复测为准（N=8≈99%、N=10=62.2%、N=16=48.6%）。

7.4.2 重复、消融与敏感性复核（show6–show12）

到达顺序复测（show6 种子 42 + show12 种子 101/202，共 24 局）。 show6 以第二个到达顺序重跑全部 7 策略：对齐相位停点列完全复现（audible 式 32、首违约 34；fixed 16；ours 8；ours_p 8；quantile 8；util80 32、首违约 34；worstcase 8），随机相位停点窄带内（ours 18 vs 16；ours_p 20；audible 式 16；util80 32 vs 28；worstcase 8）。show12 再以两个新顺序复测核心三策略：worstcase/ours/ours_p 在全部顺序中对齐相位均停 8；随机相位停点呈带状而非点值——四个顺序下 ours 16/18/18/24、ours_p 20/20/18/14，worstcase 恒 8。带宽（约 ±25%）即随机相位工作点在到达顺序扰动下的诚实不确定性；对齐安全停点是顺序不变的。

完整链端到端（show7）。 Algorithm A 完整链（ours_full：截断校正 + 背景残差 Q95 预留 + 双护栏暂停）停在对齐 8 / 随机 16（随机停点客户 P5=100.2%），与仅相位门的画像一致：在该负载上校正不改变工作点，链条端到端闭合。

组件消融（show8，每格一轮）。

表 17。 组件消融：各臂对齐/随机停点与证据

读法。 相位门是对齐相位的安全关键组件（去掉它 32 台失效复现）。两条 80% 帽臂相差 4 个随机席位（18 vs 14）；两次停点均为容量括号 defer、非护栏触发（决策日志核验：分别 n=20 与 n=16），且每轮独立重掷客户相位，差异由轮间相位摆放主导（show12 带宽约 ±25%）——截断校正在单轮/臂下不可分离。80% 配额帽轻微超卖对齐边界（8→10，恰为首失败档）。

稠密采样确认边界（show9，1 秒采样）。 以 1 秒分辨率重跑阶梯确认对齐边界：第 8 档客户 P5 保持 97.3%（逐客户时间 P5、中位口径），第 10 档塌到 47.8%；随机 28 档 75.7%、30 档 58.3%，稠密口径把随机边界收紧到 [28,30)（max 口径在 32 档仍读 90.6%——即 §8.4 量化的口径敏感性）。各档服务 P99 恒在 0.70–0.75 ms：约束项是客户速率而非服务尾。

护栏指标敏感性（show10）。 护栏指标由 max 换 median：对齐停点仍 8，随机停点降到 4（暂停监控 6/6 次触发；停点 P5=101.9%）：指标以随机相位效率换保守性。护栏语义（精确）： 客户护栏每台已接入客户消费一个数——客户的速率序列（6 个采样、先于服务探针采集以捕获工作段）按客户聚合为 max（工作段最大速率）/med/min——护栏值即该聚合量的跨客户第 5 百分位（p5_max / p5_med / p5_min）；低于 70%（或服务/金丝雀阈值触发）即暂停准入。主口径取 p5_max：空闲样本不构成"被剥夺"证据——客户的工作能力由其工作段速率佐证，且持续竞争同样会压低 max（满速突发无法在持续过载下维持）。median/min 把"设计性空闲"与"竞争性限速"混同而误报：show10 median 臂在随机相位每个暂停窗 6/6 触发（空闲样本稀释各客户中位），停在 4 台；对齐相位客户持续活跃，仍停 8 台。70% 与服务阈值是 §8.4 预先声明的常量；0.9 预算与滞回窗在验证集上固定。

相位选择性准入（show11，ours_sel）。 试用观察机制（候选以 5% 配额观察 40 s 后再决定准入）对齐停点仍 8，随机停点提升到 24 且无违约——对照集中最高的安全随机停点（ours_full 16、ours_p 20）：决策前获得的相位证据可等安全地兑换为可测量的随机相位容量。集成复验（show13，ours_int = 试用观察 + 完整链背景预留 + 低历史护栏）。 端到端实测：集成控制器停在随机 14 / 对齐 6（均为容量括号 defer：子集峰 6.15 / 6.03 + 预留 1.62 / 1.56 > 7.20）。试用机制的 24 席随机结果在等安全计账下不存活：其增益被背景预留项吃掉（试用单独决策不含该项）；对齐相位下按试用剖面计价的候选比按类先验计价的完整链更早停（6 vs 8）。完整系统的统一工作点仍为 ours_full（随机 16 / 对齐 8）；三个实测点（24/8 试用上界、14/6 集成、16/8 完整链）及其背后的计账差异均按实测报告，候选计价与预留的对齐列为未来工作。

7.5 三重风暴综合验证（图 10）

方案组装：服务+探针绑核 0–1；16 台客户绑核 2–3；每客户 memory.high=800 MiB、memory.swap.max=0、io.max=200/100 IOPS；准入按 censoring-aware 口径（本验证聚焦保护包络，准入不介入）。风暴构成：CPU 混打（8 闲 + 6 闲/阵发 + 2 满载）、内存 ballast、fio 4K 随机读写，同时进行；服务侧以 100 req/s 各探 60 秒。

表 18。 三重风暴综合验证：各轮服务分位、错误与宿主状态

读法。 四次均在"服务 P99 ≤ 10 ms"内通过（HTTP 余量约 3–4×）；Redis 在 syn2 尾部略重（p999 27.5 ms、max 74 ms，单次响应级别的长尾，未见超时），如实记录。与第 4 章无保护情形（CPU 风暴 21–23 ms、磁盘风暴 12 ms、内存风暴杀死 2 台客户）相比，方案同时抑制了三类风暴的伤害。客户侧的代价符合设计预期：内存与 IO 上限让"超用客户"先被节流（部分客户 SSH 短暂无响应），这正是经济版的运行状态。

采集说明：综合验证的客户侧明细在强限速下采集不完整（syn3 为 13/16），本文以服务侧指标作保护结论，客户侧以组合证据（速率、节流计数）支撑。

v3 返工复测（图 19）。 返工批次以同一协议重跑（20 秒探测、每轮从零重建）：26 轮中 25 轮通过——HTTP P99 均值 4.82 ms（中位 4.02，范围 2.95–25.26）、Redis 均值 3.34 ms（范围 2.53–4.13，全程达标）；1 轮（r24）违约 25.3 ms——该轮 8 台客户未返回速率样本（降级状态），如实报告。保护包络累计 30 轮（4 预实验 + 26 返工）中 29 轮零失信。统计口径：29/30 的乐观独立二项单侧 95% 上界 ≈ 14.9%（返工前 24/24 的 11.7% 属乐观估计；轮间共享宿主状态、时间相关，上界仅作参考——“近零违约”不构成长期可靠性保证）。

7.5.1 准入＋塑形联合验证（j1，图 13）

保护包络全开（服务/探针绑核 0–1、客户绑核 2–3、客户内存双闸 800MB 与 swap.max=0、IO 上限），背景负载 4 台（3 闲＋1 阵发）持续运行；6 个候选逐个到达（到达即限 50% 满载）。两种准入策略在同一包络下决策：

表 19。 准入＋塑形联合（j1）：承诺席位与金丝雀行为

定位说明： 本节为 2025 年的单轮历史试点，其中的控制器尚未实现时间对齐聚合；完整控制器的在线对决（相位剖面 + 节流校正 + 暂停护栏，7 策略 × 2 相位 × 统一到达流）见 7.4.1 及图 20，本节只作为设计—实现差距的历史记录。

读法（三条诚实结论）。（i）服务侧被绑核与上限保死：两种策略下服务零违约——联合运行时准入策略决定的是"承诺几席"，而非服务安全；（ii）客户侧的主导痛感来自内存双闸的紧上限：金丝雀的秒级停顿在 1 席与 3 席状态下几乎相同，说明 800MB 的 memory.high 对 3GB 客户过紧（对照 4.4.4 节的"软阈值"语义）——经济版的体验上限由闸门尺寸决定，属产品参数而非策略缺陷；（iii）节流校正估计存在相位偏差：背景为阵发负载时，决策瞬间采样会低估其需求（本轮 est 在 0.01–1.90 核间跳动），使 aware 过度保守（1 席 vs naive 的 3 席）——这正是设计中"时间对齐聚合上分位"尚未在试点控制器完整实现的差距，列为"设计—实现差距"改进项。v2 修订（BeroHost 联合对决批次运行中）：时间对齐聚合已完整实现（1 秒历史采样 + 相位剖面预测 + 按配额消费口径计账 + 金丝雀闭环护栏），四路公平对决（naive / AUDIBLE 式 / aware / taligned）×10 轮与内存闸门 800/1920 MB 对照正在第二测试床自动执行；结果将作为补充材料并入。

7.6 生产遥测：生产负载画像（图 27）

两台生产宿主均为我们自己运营的基础设施，并以免费 VPS 形式开放给外部用户使用——遥测在自有设施上进行、以匿名化约束只读采集（不读 VM 名称/IP/业务内容）。本节定量画像来自其一（LEC-HK-1）：主机为 Xeon Gold 6248（50 核、无 SMT、单 NUMA）、251.7 GiB 内存 + 64 GiB swap、单块 1.1 TB SSD（已用 393 GB）、PVE 9.2.21。宿主级配置清点（一次性只读，/proc 与 *.conf 文件级，不调 PVE API）：285 台 VM 配置 / 276 台运行；ΣvCPU = 417（8.3×）、Σ内存 = 500 GB（2.0×）、Σ磁盘 = 5.38 TB 薄分配于 1.1 TB 卷（≈4.9×，实际占用 36%）；磁盘为 qcow2 薄克隆并共享 base 模板镜像（模板级去重）；vCPU 直方图 226×1 / 31×2 / 13×4 / 9×6…，内存档位以 512 MB（184 台）为主。60 秒遥测窗口内运行数为 210 台（ΣvCPU=288，5.8×）——运行数随生命周期在 210–276 间波动。使用边界：不用于训练、不回写调度、不做主动实验。

单位校验。 Σ 客户 cpu×vCPU = 15.3 核 ≈ 宿主计数核 14.8 核；Σ 客户 cpu（按单核口径）仅 10.2 核——确认客户 cpu 字段为分配 vCPU 的比例，两口径在宿主级一致。

画像（图 27）。 类别上，近闲（<5%）占 71.9%、轻载（5–30%）占 27.1%、重载（>30%）仅 1.0%，与“多数闲、少数重”的建模前提一致。超售实锚：vCPU 超售 5.76 倍（vCPU 配置合计除以 50 核）、内存限额超售 1.12 倍、实际内存占用约 95 GiB——第 8 章测试床的 5 倍量级来自真实运营实践而非人为拔高。突发结构：活跃段（≥5% 连续）共 4268 段，中位 1 分钟，其中 3550 段为单分钟，短促突发为主；数值层自相关在 1–30 分钟全部 ≈ 0，无强持续性也无时钟周期，而状态层仍具持久性（Markov 自转移 0.85/0.37/0.26）——真实突发是长短不一、相位漂移的活跃段，既非 i.i.d. 也非固定时钟。饱和实例（≥95% vCPU）占 VM-样本的 0.046%，真重载稀有但存在。

对全文的含义。 重载类仅 1%，与第 4 章“一台满载邻居即击穿尾延迟”的合成结果互为印证：稀有重载加上瞬时重叠就是风险的全部来源。真实突发是漂移型而非时钟型，合成实验中的“严格 60 s 对齐”给出的是最坏情形上界；混合相位容量模型（第 8 章）里的 φ 在真实宿主上应取低值，安全容量因此贴近随机端，与 5.76 倍超售长期共存的事实一致。只读接口不含节流计数，截断比例的现场证据以“饱和实例占比”作下界代理，节流维度的现场证据留待轻量流（/proc PSI）积累。租户间相关性（分钟粒度）：204 台活跃 VM、20706 对的平均 Pearson r=0.12、中位 0.07、P95 0.45、15.7% 的对 r>0.3——弱正相关而非独立。相位结构不是合成负载的臆造，部分租户确呈弱同步倾向，也可能含宿主级测量共模与日间节律；这提醒容量模型不该假设完全独立。亚分钟同步在本粒度不可见。双窗代表性：3 h 稠密摘录是夜间安静段（忙 30.1%），42 h 轻量窗覆盖昼夜（忙 37.3%、峰 66.1%）；“近闲为主”是逐 VM 口径，宿主级负载随昼夜节律波动，容量模型取安静段锚点时应如实标注，本文受控实验与安静段对齐，昼夜峰值情形列为未来工作。

第二生产宿主（OVH ns503701）。 在第二台独立生产宿主上采集 6 小时稠密窗（60 s 采样、344 点）：Xeon E5-1630 v4（4 核 / 8 线程、62.7 GiB 内存；盘点时 swap 近满）运行 66 台客户、ΣvCPU=73（9.1×）；宿主忙率均值 30.9%（峰 44.6%）；CPU PSI(some) avg300 均值 7.2 / 峰 8.2，PSI(full) 全程 0.0；客户 CPU 消耗 1.84/8 线程（23%）；节点内存在用 43.3/62.7 GiB（69%）；重载占比（≥30% vCPU）2.2%。画像在相近密度下复现 HK 结构：9–12× vCPU 超售与近闲宿主、零完全停滞压力长期共存——测试床尺度与“近闲为主、少数重载”前提取自现场实践而非夸大。

边界与双态锚点（图 31）。 稠密窗口仅 170 分钟且为夜间安静段（宿主忙率 30.1%、峰 47.2%）；轻量流已补足 42 小时跨昼夜覆盖（截至 2026-10-14，305 点、5 分钟间隔；约 39% 样本因 relay 抖动缺失）：宿主忙率均值 37.3%、P95 55.3%、峰 66.1%；客户占宿主 CPU 均值 14.8%；内存可用最低 63.7 GB（全程无压力）；CPU PSI avg300 均值 5.2、峰 14.0；期间无重启。双态锚点成立：安静/夜间稠密段（测试床受控实验与之对齐）与昼夜全谱轻量段共同界定真实负载区间。1 分钟粒度无法分辨亚分钟同步（对 60 s 内脉冲无能为力）。

7.7 缺口清单（投稿前计划）

1. 与 AUDIBLE 适配基线的对照：预实验见 7.3.1（图 11）；完整四路公平对决（含 AUDIBLE 式 MC 与时间对齐 taligned）在第二测试床批次中运行，结果并入补充材料；
2. 冷启动/短历史专项：预实验见 7.3.1；完整批次在第二测试床运行中；
3. 关键结论轮次：膝点 100 轮（v2/v3 各 50）、censoring 180 cycle（两批）、三风暴 30 轮（4+26）均已并入（图 17–19、29）；v3 返工（v3knee/v3cen/v3syn）已完成并回填；准入对决的到达顺序复测（show6）、完整链端到端（show7）、消融臂（show8）、稠密采样（show9）、护栏敏感性（show10）已完成并回填 §7.4.2；ours_sel（show11）与核心对照多轮重复（show12）在跑，落袋后并入；
4. 消融：预实验见 7.3.1；完整消融（配额帽、截断校正、相位门三臂）已完成并回填 §7.4.2；
5. 图表与脚本：全部一键复现（figs 脚本与 artifacts 数据），编号至图 31。

8 物理机验证与安全容量模型

本章回应"单嵌套测试床、规模太小、结论能否推广"的评审关切：在裸金属物理机（双路 Xeon Platinum 8259CL， 48 核 / 96 线程，991 GiB，PVE 9.2.20，非嵌套）上，用 64 台客户 VM 舰队复现第 4–6 章的核心结论， 并把"安全售卖容量"从定性说法升级为可量化的曲线与定律（§8.5 容量近似模型 N*≈C/(ρκ)，含明确假设与边界）。

8.1 测试床

物理机：2×Xeon Platinum 8259CL（48 物理核 / 96 线程，双 NUMA 节点）、8×128 GB DCPMM（Memory Mode，可用 991 GiB，NUMA 520 GiB + 520 GiB）、3×NVMe SSD + 2×SATA SSD、PVE 9.2.20（内核 7.0.14-19-pve，systemd-detect-virt=none，非嵌套）、内网 vmbr0 10.10.0.0/24 + NAT。

舰队：1 台 HTTP（nginx）、1 台 Redis、1 台探针（开放环 100 req/s）、64 台客户 VM（1 vCPU / 1 GiB，Debian 12 cloud 模板）。客户负载用第 4 章的占空比忙循环（burner.py），速率日志提供逐客户体验指标。服务与探针绑核隔离（2/3/4 号核）；租户池由 taskset -apc 绑定（2–32 核可配）。隔离声明经拓扑核验：服务核 2/3/4 的 SMT 兄弟（50/51/52）与租户池 8–23 的兄弟集合（56–71）零交集，且全部位于 NUMA node 0——是物理核级隔离，不只是逻辑编号不相交。

环境插曲：测试床搭建期间该机出现过一次内核 panic（Attempted to kill init! exitcode=0x9， 日志停在批量启动 VM 附近）；该机彼时正处内存子系统异常状态（8 条 DCPMM 仅 7 条在线）。 冷启动修复内存（8/8 在线，991 GiB）后，48 台 VM 分批启动 + 数小时满载实验均无异常。 这不是本文方法的组成部分，但说明"生产硬件同样会带病运行"——监测与保守化设计因此更有价值。

8.2 多规模膝点复现（图 14）

在物理机上把第 4.1 节的膝点实验放大到五种规模：租户池 2 / 4 / 8 / 16 / 32 物理核，服务侧两种配置：隔离（专用核）与共享（与租户同池）。逐步增加 100% 占空比的满载邻居（每位 1 核），记录服务 P99（图 14；横轴为"超售比 = 满载邻居数 / 租户池核数"）。

结果。

• 隔离配置：五种规模、超售比 0–2.5× 全程服务 P99 0.68–0.78 ms——即使在 32 核池上、

48 台满载邻居（1.5× 超售）下依然零伤尾。"隔离护尾"从 4 vCPU 嵌套床放大到 96 线程物理机后完全成立。

• 共享配置：每种规模都在池饱和点（超售比 = 1.0）出现断崖——2 核池 L2→L4（4.1→10.2 ms）、

4 核池 L3→L4（1.5→10.2 ms）、16 核池 L13→L16（1.0→12.0 ms）。16 核池细扫 4 轮（L13–L18，图 14 已更新）：L15 = 2.13 ms [2.00–2.29]（仍在平台），L16 = 10.95 ms [9.97–12.02]，4/4 轮在 L15→L16 处跳变；饱和后（L17–L18）稳定在 9.8–10.6 ms 平台——膝点位置精确等于池容量，4 轮无一轮例外，与 BeroHost 的 3→4 结论同构。

读法。 规模不改变结论的形状，只改变刻度：共享池的膝点始终落在"峰值需求 ≥ 池容量"处，隔离则把这条曲线整根压平。这同时是对"4 vCPU 太小、结论不可推广"关切最直接的回答：在 96 线程物理机上，膝点现象、量级（0.7 ms → 10–12 ms）与隔离有效性逐项复现。

8.3 相位结构：同步 vs 随机（图 15）

把 BeroHost 的同步突发实验（第 4.2 节）放大到 64 台：全部客户同开（各 20% 占空比 / 60 s 周期），一半实验随机相位、一半相位对齐，全部挤在同一个 16 核池（无隔离）。

结果。

表 20。 生产调度回放：随机 vs 对齐相位指标

复现（图 15 右）： 随机/对齐各重复 3 轮（r1–r3）。对齐组 3 轮共 5 个热点簇间隔全部精确命中 60 s；随机组的簇间隔在 20–40 s 间散落、无固定节拍。两种相位的"伤害签名"（周期尖峰 vs 基线抬高）在重复轮中稳定复现。

读法。 两种相位伤害形态不同：同步的伤害是可预测的周期尖峰（每个 60 s 工作窗内全组同时争抢），随机的伤害是把基线持续抬高。这修正了第 4.2 节的表述（尖峰是同步的特征签名，而非"同步更差"的单调排序），也为"时间对齐准入"提供了动机：周期结构可以被测量、被利用（避峰）或被治理（错峰），而随机结构只能靠裕量。

8.4 安全售卖容量（图 16，核心结果）

安全定义（事前统一口径，全部章节适用）。 容量声明一律为三元组：资源、质量约束、风险预算 ε。（i）服务侧：以 W∈[30,120] s 为窗口，窗口内 P99 > 10 ms 或出现超时/错误即违约，失败不豁免；声明形如“违约窗率 ≤ ε”，并附独立轮数与 Clopper–Pearson 上界（§5.3.2）。ε 预算计的是轮级违约率；它不放松轮内口径——声明“ε 预算下安全”的配置必须在至少 (1−ε) 比例的轮次中满足客户 P5 ≥ 70% 门槛；容量—风险曲线的 ε=1 端点是曲线终点，不构成安全准入含义。（ii）客户侧：主口径为客户工作速率 P5 ≥ 70% 独享基准，取低尾分位而非“最差十分位”。（iii）容量参照：在两约束下按给定 ε 判定的最大已验证阶梯档位，真实断点需细扫钉定。拐点、零违约容量与风险预算容量是三个不同概念，正文每次引用必须标明属于哪一种：例如 §4.1b 的“3 台”是拐点前档与 ε≈7% 预算档，ε=0 时为 2 台。超时与错误一律计入违约，不因剔除而美化成功请求 P99。

问题。 8 核租户池、服务隔离在外，在"服务 P99 ≤ 10 ms 且客户体验不劣化"的双约束下，能卖多少台 1-vCPU VPS？

质量口径（事前声明，防事后挑选）。 主口径 = 服务 P99 ≤ 10 ms 且客户工作速率 P5 ≥ 70% 独享基准，即：低尾——分布第 5 百分位处的客户仍保有 ≥70% 性能；注意 P5 是低尾分位，不是"最差十分位"；另报敏感性口径 P5 ≥ 90%／P5 ≥ 50%／中位 P50 ≥ 90%，全部在同一份数据上事先并列报告。统计口径：先按客户级/轮级聚合再估计分位（不把逐客户逐时间样本当独立重复），轮级不确定性以轮为单位重采样。

方法。 阶梯式加售：L8→L64（随机相位组）/ L4→L32（同步组），每档稳定后采集 60 s：池忙率（每 2 s）、逐客户忙循环速率（每 10 s）、双服务探针。客户速率以独享单核基准（25.9 M it/s）归一；随机组 2 轮合并（r1+r2，逐客户样本 n=13–117），同步组 2 轮合并（r1+r2；乱序轮 r3 因档位标签缺陷作废留档）。

结果（图 16 左：客户体验；右：服务侧）。

• 服务侧（右）：两组、全部档位 P99 0.56–0.78 ms——隔离包络下，"卖到 8× 超售"服务依然零伤。
• 客户侧（左）：同负载（人均 20%）、同池子，安全容量随质量口径在 3.5–4× 区间移动：

表 21。 物理机质量口径容量：随机 vs 对齐

随机组逐档 P5 从 L16 的 99.7% 渐进降至 L64 的 42.8%：L24 为 93.8%、L28 为 90.6%、L32 为 69.1%、L40 为 64.5%、L48 为 50.6%、L56 为 50.0%。同步组则是断崖式：L8 为 98.8%、L10 为 62.2%、L12 为 53.5%、L14 为 54.2%、L16 为 48.6%。4 轮复测的合并口径与图 16 一致，细档边界扫描已完成，得到 sync [8,10) 与 rand [28,32)。

关键档位的轮级范围按逐轮 P5 计算：sync N=8 为 98.6–101.8%（4 轮）、N=10 为 61.0–70.8%（3 轮）、N=16 为 47.0–49.6%（4 轮）；rand N=28 为 88.7–99.4%（2 轮）、N=32 为 62.2–90.8%（4 轮，轮间方差大，边界声明按最保守轮取 28）。正式区间用合并样本的客户级 bootstrap 计算（B=10⁴，95% CI）：sync N=8 [98.6, 99.0]、N=10 [61.0, 68.6]、N=16 [47.1, 48.9]；rand N=28 [82.5, 99.3]、N=32 [62.2, 75.5]；mix50 N=13 [90.5, 99.6]、mix75 N=10 [98.7, 100.5]。工件见 tools/bootstrap_ci.py 与 BOOTSTRAP_CI.md。统计独立性警示：客户级 bootstrap 在共享宿主状态的样本上会低估不确定性——同轮内多台 VM 共享宿主状态、同租户连续样本高度相关；轮级范围（同段报告）应作为主要不确定性口径，仅 2–4 轮的配置直接以逐轮结果为准，更严格的分层/聚类 bootstrap 列入未来工作。

口径稳健性。 客户速率“P5≥70%”依赖逐台聚合口径。用完整 18 点/台原始序列重算四种口径——逐台取 max、median、时间 P5 或 min，再取跨客户 P5，与本文逐轮聚合结构同构：sync 边界四口径完全一致，均为 8 台；rand 边界为 28/28/26/26；mix25 为 24/20/20/20；mix50 与 mix75 不变，仍为 13 与 10。对齐端结论对聚合口径免疫，N=8 处各口径 P5 均为 98.8%；随机端在最严格的时间口径下收紧一个细扫档。工件见 tools/p5_convention_check.py 与 P5_CONVENTION_CHECK.md。容量—风险曲线（图 30）：以轮级违约频率为风险度量（某轮 P5<70% 记一次违约），安全容量随风险预算单调上升——ε=0 时 rand 28 / sync 8 / mix25 20 / mix50 13 / mix75 10；ε=0.5 时 rand 40；ε=1 时 rand 64 / sync 32。对决策略停点全部位于 ε=0 一侧（ours/ours_p：sync 8、rand 16–20），而 util80/audible 的同步停点（40）超出曲线在任何预算下的上限（ε=1 也仅 32）——风险预算无法为其提供合法性。口径说明：本曲线是工作负载侧的经验容量—风险前沿；「每策略在相同风险预算下的完整容量前沿」（需每策略 × 多档 N × 多种子）列为未来工作；ε=1 端点仅为曲线终点，不构成安全准入含义。）

四条结论。

1. 盲目看平均利用率会灾难性超卖：同步组卖到 32 台时平均忙率仅 ~35%（"池子看起来很空"），

但每个 burst 窗口客户速率已跌到 25%。基于平均值的准入在真实的"集体定时行为"（备份、扫盘、定时任务）前毫无防线。

1. 同样平均负载，容量由相位结构决定：主口径下随机 28 台 vs 同步 8 台（3.5×）；容量比随质量口径在 3.5×–4× 间移动

（严格口径 3.5×、地板口径 4×、中位口径 4×）。报告容量必须同时报告质量口径——"5×"是 P50 口径的数字，"不劣化"应以 P5 口径度量（本节的修正即来自这一原则）。

1. 两类失效的形状不同：随机组是渐进劣化（P5 逐档下滑，可预警、可准入控制）；同步组是断崖（99%→49%），

没有预警窗口——这解释了为什么"监测平均值/中位数"的准入对同步失效免疫失败。

1. 隔离把两类伤害解耦：服务侧全程平直（0.7 ms），代价全部显式落在客户侧速率上——

与第 5 章"代价定价"的框架一致；"经济版"卖的其实就是这个速率衰减的额度。

8.5 容量近似模型：混合相位验证（图 21）

模型（明确假设下的近似，非普适定律）。 假设：（A1）各租户相位在决策跨度内稳定；（B）对齐组的突发窗彼此重合、与随机租户的重叠按占空比近似。在该假设下，聚合并发峰 ≈ 对齐组 $φ N$ + 随机组 $\rho(1-φ)N$，故"峰值不超过池容量"的中位口径容量为$$N^_{\text{mid}} \;\approx\; \frac{C}{φ + (1-φ)\,\rho},$$即相位集中度形式 $N^_{\text{mid}} = C/(\rho\kappa)$、$\kappa = \max_b \sum_i p_i(b)/\sum_i \bar\rho_i$。该模型刻画平均/中位口径；对纯随机端的 P5 尾部口径显著偏乐观（纯随机端模型给 40，而主口径实测安全容量为 24）。随机端的尾部风险天然由重叠计数的上分位给出：要求 $Q_p\big(φ N + \mathrm{Bin}((1-φ)N,\ \rho)\big) \le C/\theta$（$\theta$ 为体验质量界），数值上低于中位口径；工程上安全值直接取实测口径容量（§8.4 阈值表），模型仅用于跨配比外推与准入控制器的先验。

验证（图 21；8 核池、$\rho=0.20$，capmix 各 3 轮合并）：

表 22。 密度律：模型预测 vs 实测主口径容量

结构性相位（$φ \ge 0.5$）两点命中；$φ=0.25$ 的预测点落在通过区内（预测偏保守），纯随机端偏乐观——误差方向与"尾部口径 vs 中位口径"的预期一致。

诚实边界。 （i）每配比已并入 3 轮复测；p5 存在非单调采样噪声，如 $φ=0.25$ 的 L24 反高于 L20——更大规模的轮级区间与预测误差带（更多随机种子）列入未来工作。（ii）C5 反相编排（干预级证据，已完成）：同批客户、同占空比，仅改相位编排——16 台同相 P5=50%（坍塌）；16 台分两组相差 30 s P5=101%（×2）；32 台分四组（0/15/30/45 s）P5=101%（×4）；两组的 32 台与四组的 64 台对照均为 50%；窗口相位校验 8/8 组命中。（iii）本节的定位是带明确假设的容量近似模型：结构性相位下用于外推与准入先验，安全值以实测口径为准——不主张普适定律。

8.6 相位剖面卷积与"边际幻觉"命题（图 28）

命题（边际幻觉 / Marginal Illusion）。 §8.4 的两次实验直接给出构造性证明：两组客户每台的用量边际分布完全相同（同一 burner、同一 20%/60 s 占空比与相同繁忙段形状），但随机相位组与对齐相位组在主口径（P5≥70%）下的安全容量为 28 vs 8（中位口径 40 vs 10）。因此：任何只依赖逐租户边际统计（以及独立性假设）的容量方法，都无法区分这两组——对"对边际分布做独立卷积"的一类方法（AUDIBLE 式 [1]），这是可证明的盲区：它们的输入在两组的差异上不可辨识。这是 3.3.1 非可辨识性结论（需求估计）的容量版本（安全容量估计）。

方法（PPC，相位剖面卷积）。 输入为逐租户相位剖面，分辨率为 1 秒或 1 分钟。PPC 由三个明确对应工件的模式组成。第一是参数化仿真 ppc_sim.py：在合成配置（φ、duty）上验证与外推，联合结构由构造保证。第二是经验联合块自助 ppc_bootstrap.py：在真实轨迹上严格三段分离，训练段为前 1/3，块长选择用中 1/3 并以 KS 距离选中 B=1，测试段为后 1/3 且只用于打分；预测序列的重采样块仅从训练段抽取，不触碰验证与测试段，不是对测试段的自我重采样；同块跨租户联合以保留共现，并配套 iid 置换对照，边际保留而联合打散。前向预测对测试段打分的结果：联合预测峰值 P50/P95/max 为 14/14/14，P(峰>8)=99%；iid 预测为 12/13/16，P=100%；测试段实测峰值 12、超池时间 8%。该生产日程上两种预测均命中风险方向，分钟级联合与 iid 差异小，与其“漂移型”画像一致；极端相位证据在合成实验。口径限定：输入为 1 分钟粒度生产 duty 加周期内活性模型，不含亚分钟相位结构，支持的是“生产分钟数据回放模型”；极端相位结构证据在合成实验（§8.4/8.5/C5），不外推亚分钟结论。真实生产轨迹（64 台 × 30 min 回放日程）上的实测：联合峰值 14 核，P50=P95=max=14；iid 峰值 12–15 核。低同步漂移轨迹上两者差异小，iid 风险随相位对齐增长，极限端见 C5 与同步售卖。块长选择 B=1，KS≈0.16，B∈{1,2,5,10,15} 的差异在 0.16–0.21 之间，弱可分辨，如实报告。在线回放验证 replay1：64 台生产日程在 8 核池上回放 30 分钟，池忙率均值 42.0%（3.4 核），峰值饱和 100%（≥8 核并发）；服务 P99 为 0.706–0.729 ms（5 次探针，末段一次 1.599 ms）。预测的超池风险在回放中兑现，峰值时刻池饱和，服务侧由隔离包络保护。多窗复验把同一遥测切成 5 个非重叠 30 分钟窗各自独立前向预测，方向命中 5/5：预测 P(峰>8)=98–100%，实测超池 3.5–8.3%；峰值量级同阶，预测 P50 为 11–19 对实测 12–16，逐窗偏差 +5/±1/−2/−1/0，单窗方差如实报告。口径：秒级序列由分钟 duty 加周期内相位模型重建，本测试验证的是模型回放一致性，不是独立实测的秒级生产真值；两法在该低相关舰队上均预测超池，判别力证据在合成配置（iid 全盲对 PPC 区分五结构）与在线对决（util80/audible 同步崩）中；独立秒级真值、误报/漏报率与多风险阈值效果列为未来工作。第三是在线作动器：Taligned 式峰值包络（60 个 1 秒相位桶取峰值加类别先验），是 PPC 的低成本在线近似而非重采样器；其对决表现（§7.4.1）即该近似的行为证据。三者共用同一原理——在联合相位结构上计账——分辨率与用途不同，论文分别标注。

算法 P（PPC 容量预测；输入：候选集 X（含逐租户 1 s 活跃序列）、池容量 C、质量分位 θ、重采样次数 R）
1  档案化：对每台 i 维护活跃指示 aᵢ(t)（1 s）；结构相位（对齐/定时）直接从历史取相位，不做随机化
2  相关保留重采样（二选一，按数据来源）：
   (a) 参数化相位模型：对齐租户共享固定偏移（零方差）；随机租户偏移 ~ U[0,P) 独立采样
       —— 仅用于“按配置生成的”负载，如混合相位阶梯；同步关系由构造保证
   (b) 联合块自助（经验舰队）：对所有租户使用**同一组时间块**（块长 B·1 s，块内原序保留）
       重采样 —— 同时刻的跨租户相关性被块结构保留；**禁止**逐租户独立平移
       （那正是 iid 卷积的假设，会把同步结构洗掉）
3  对每个重采样：A(b) ← Σᵢ aᵢ(b)；peak_r ← max_b A(b)；体验分位由 C/max(1,A) 逐租户聚合
4  输出：P(peak> C)、容量 N*(θ, ε) = max N s.t. Q_{1-ε}(peak) ≤ C/θ
复杂度：O(R · N · P)，R=10³、N=64、P=60 s 时 ~4×10⁶ 次布尔运算（毫秒级）。

三段分离与真前向预测：PPC 的超参数只有块长 B 与 θ（主口径固定 70%）；经验模式严格三段——训练（前 1/3）提供预测块的抽取域、验证（中 1/3）以 KS 选定 B、测试（后 1/3）只用于打分；预测阶段的重采样块仅从训练段抽取（不触碰验证/测试段），即“仅凭此前历史预测未来”的样本外检验（此前版本从测试段自身重采样的结果只是分布刻画/校准，本版为修正后的前向协议）。阶梯回测（本文）即离线测试；在线对决（§7.4.1）是端到端盲测（控制器状态与 8.6 的预测参数分离）。与边际卷积的本质差别：在相位（联合）结构上卷积，而不是在时间边缘上——这正是 3.5 节"幅度用截断证据、结构用时间史"的容量侧对应物。

结果（图 28）。 同参数下：iid 卷积对 rand / mix25 / mix50 / mix75 / sync 五种结构给出同一个预测 24（完全盲区）；PPC 给出 24 / 16 / 13 / 12 / 10。边界细扫（sync {4,8,10,12,14,16} 三细轮、rand {16,20,22,24,26,28,32} 两细轮、capmix 各 3 轮）完成后与预测对照：mix50 预测 13 恰落边界 [13,16)、mix75 预测 12 恰落 [10,13)（贴边命中）；rand 预测 24 保守 4 台、mix25 预测 16 保守 8 台（均在安全侧；细扫把 rand 边界从粗扫 [24,32) 收紧到 [28,32)、mix25 从 [20,28) 收紧到 [24,28)）；sync 预测 10 恰为首失败档（细扫边界 [8,10)：8 台 P5=98.8%、10 台 62.2%）——该例的在线安全性由峰值门禁保证（作动器拒第 10 台、停 8），离线预测本身不提供安全。口径澄清：离线预测的用途是“档位建议 + 风险排序”，安全由在线门禁兜底；iid 卷积的盲区（全配置同一预测）与相位感知的区分度（预测随结构单调下降）是对照核心。纯随机端尾部乐观性与 §8.5 一致（由实测口径修正）。

预测质量指标（比"落入断档"更严格的口径）。 对每个配置定义四项：超接（预测 ≥ 首个失败档；安全否决项，必须为 0）、未验证上探（预测 − 最后通过档；>0 表示预测伸入了未扫描区间，需要边界细扫点头）、失败余量（首个失败档 − 预测）、保守差（最后通过档 − 预测，>0 表示白让容量）。当前数据（多轮合并）：

读法：4/5 无超接——sync 的离线预测 10 触及细扫后的首失败档（边界 [8,10)），该例的安全性由在线峰值门禁保证（作动器拒之、停 8），而非离线预测；rand/mix25 保守（4/8 台）；mix50/mix75 恰落在已验证边界上。这套指标替换"落入断档"作为 8.6 的验收口径。

边界。 PPC 需要相位史（冷启动退化为类别先验/观察窗）；随机端仍需实测口径；本节验证为离线前向预测（训练段重采样 → 测试段打分）+ 对决中的在线决策（ours 即 PPC 的作动器；对齐场景 v2 复核与边界细扫已完成（边界 [8,10)；离线预测 10 触及首失败档，安全性由在线门禁保证——不断言精确 oracle）。

8.7 与 BeroHost 的一致性小结

表 23。 跨测试床汇总：嵌套床 vs 物理机

8.8 本章数据与工件

• 数据：research_data/phys8269_pilot/（多规模扫描 JSONL + 细膝点 4 轮 + 同步 3 轮探针 raw + 售卖阶梯 JSONL + 分析文档）
• 图：figs/fig14_phys_knee.png、fig15_phys_sync.png（含 3 轮簇间隔复现）、fig16_phys_sell.png（一键复现：figs/make_phys_figs.py）
• 工具：tools/tb_sweep.py（膝点）、tools/tb_sync.py（相位）、tools/tb_sell.py（售卖阶梯），全部宿主机侧执行

9 资源效率模块

本章承接"无回归的资源效率最大化"支柱（骨架 §9）：在"服务 P99 ≤ 10 ms + 客户速率不劣化 + VPS 可见内存不下降" 三条无回归约束下，逐资源给出精密控制的实测增益。Phase C 实验已完成（zram3b/ioctl2/FPR/canary3）， 数据已填入对应小节（图 22–26）。定位说明：本章为支撑性扩展——核心贡献链是 3/5/7/8 章的识别—预测—行动主线，本章验证“无回归”原则可跨资源扩展、为密度上限提供背景，不构成独立主张。

9.1 CPU：微周期配额——一次自查更正（图 22）

背景。 早期批次（qp2c：5 台满载客户 @50% 配额，周期 2/4/10/100 ms/1 s）曾显示“细周期把客户速率从 59% 提到 80%（+35%）”，并写入速览表。

自查与更正（qp2v1）。 投稿前按评审要求做计量核查：qp2c 的速率读数来自 burner 的工作相位内累计平均（每 ~2 s 覆写），而各配置仅隔 ~30 s——后测配置的读数被前序快配置的窗口污染（无配额段 25.6M 抬高早期读数）。干净复测：每配置重启 burner（全新累计窗口）+ 60 s 同步窗口 + 以 guest cpu.stat 交付量做地面真值：

表 24。 微周期自查：各配置交付 CPU、节流时间与速率

更正结论。 50% 配额下 2 ms 与 1 s 交付完全相同（各 0.500 核、≈52% 基线，差值 <1%）；原“+35%”为测量伪影，已撤回（速览表⑤同步更正）。服务侧不受周期影响（0.73–0.75 ms；qp2c 服务数据有效）。教训（已固化进 tb_qp2v.py）：吞吐对比必须（i）每配置重置累计窗口、（ii）以 cgroup 交付量而非速率文件做交叉验证。

边界。 纯 CPU 满载忙循环；延迟敏感/混合负载的周期效应未测（未来工作）。

9.2 内存：无 balloon 回收三件套（图 23–25）— 部分完成

已完成（本批数据）。 （i）KSM 舰队去重（ksm1；机制见内核文档[21]）：64 台同镜像舰队共享 21.4 GiB = 舰队内存的 33.4%；ksmd 平均 ~0.16 核；服务 P99 0.73→0.76 ms（零回归）。代价边界：写入 CoW 长尾未测；跨租户去重存在已知侧信道议题，生产上按信任域分层启用。（ii）空闲页上报（FPR）机制验证：手动 300 MB——宿主 memory.current 315→629 MB 随分配、释放后 6–12 s 回落至原位，guest MemTotal 恒 973 MB 不变；附带发现：空闲「1 GB」VM 的宿主实占仅 156–315 MB（FPR 一直在归还空闲页）。（iii）自动化 FPR（fpr5，300 MB）：宿主 memory.current 571→875→570 MB（vm312）、581→878→575 MB（vm313），回收 303 MB，guest MemTotal 恒 973 MB——自动口径与手动验证一致（fpr4 曾因 balloc 调用缺 debian@ 前缀未生效，修复后重跑）。（iv）zram 吸收（zram3b，单位修复后）：分配至 1120 GB 达标，其中 176.8 GB 溢出全部进入 zram（压缩后仅 3.1 GB 物理内存、mem_used 3.5 GB；compressible 冷页口径，真实负载压缩比会更低）；mid-storm 服务 P99 0.745 ms 全程平；对照磁盘 swap 臂在 1044 GB 处中止（96 GB swapfile 先耗尽）——“zram ✓ 吸收 / disk ✗ 不足”成立。（v）QoE 金丝雀（canary3）：两台独立金丝雀 VM 的 200 ms 唤醒循环在 baseline / rand40 / sync32 / mix50_40 四配置下 max gap 均 0.1 ms（>250 ms 停顿 = 0）——密度与相位编排下无调度停顿。

指标口径：宿主回收量（ksm sharing / memory.current 回落）、租户可见内存不变性（guest MemTotal/可用内存）、压缩/去重比、PSI 与探针延迟代价。

9.3 IO：租户风暴 vs 服务（图 26）

已完成（ioc2，修复部署后）。 8 台风暴客户 × 4K 随机 70/30 O_DIRECT × 60 s/臂：宿主 ~98k IOPS、租户聚合 ~66k IOPS（n=8）、租户侧单操作 P99max 8.3 ms；三臂（none / static / adaptive）下服务 HTTP P99 0.743–0.756 ms——租户 4K 随机风暴不触及服务（隔离包络），三臂差异 <1%（本负载下自适应未显优势，如实报告）。

9.4 与“无回归”约束的关系

逐机制三笔账（密度增益 / 隐形代价 / 租户可见回归）：KSM、FPR、隔离为零可见回归（客户速率分布与可见配置不变）；zram 的代价是宿主侧压缩开销（服务侧零伤；压缩比按可压缩冷页口径如实标注）；配额与 IO 上限的代价明码记在被限客户身上（速率、排队）——与第 5 章“经济版 = 明码标价的回归预算”闭环。数据出处：ksm1（去重 21.4 GiB = 33.4%，ksmd ≈ 0.16 核，服务 P99 0.73→0.76 ms；代价边界：写入 CoW 长尾未测、跨租户侧信道议题按信任域分层启用）；fpr1/fpr5（空闲"1 GB"VM 宿主实占 156–315 MB；300 MB 分配回收 303 MB、guest 可见内存不变）；zram3b（三臂：none ~940 GB 无 swap 中止 / zram 1120 GB 达标、176.8 GB 溢出被吸收、P99 平 / disk 96 GB swapfile 先耗尽中止）。

10 讨论与局限

10.1 哪些结论可迁移，哪些绑定本环境

可迁移的机制性结论： （i）尾延迟由瞬时并发/重叠驱动而非平均利用率——这与核心数、虚拟化层次无关，只与"可运行线程集合是否周期性地超过容量"有关；（ii）截断需求的逻辑——任何以配额/限流实现保底的系统都会让用量低估需求，节流证据是可移植的检测器；（iii）控制手段的可靠性层级——隔离 > 硬限速 > 软优先级，后者在 KVM/CFS 与块层（默认调度器）上的失效有机制解释（锁持有者抢占、调度信用、uq 分发），不是本测试床的偶然。

绑定本环境的数值： 膝点"3→4"特指 4 逻辑核 + 每客户 1 核满载的最坏形态；内存翻车点（约 13.8 GB 客户驻留 + 1 GB swap）绑定 19.5 GiB 物理与 swap 配置；IO 数字绑定虚拟磁盘与宿主调度器（none，无 BFQ）。正文给出的是机制与相对的"上限—代价"关系，读者应按自身核数与预留重算绝对值。

10.2 SLO 档位与"容量—质量"曲线

本文全程使用严格档 P99 ≤ 10 ms。真实低价客户并无正式 SLO、感知阈值通常远宽（数十毫秒级），而我们的数据显示：同一 10 台混合客群，10 ms 档全员违约、若放到 ~30 ms 档多数场景无虞。"能卖多少"因此不是常量，而是 SLO 的函数——建议服务商把"密度—档位"做成显式产品参数，例如经济版承诺 P99 ≤ 50 ms、标准版 ≤ 20 ms，而不是把最严档隐含在所有人身上。这一敏感性分析属于【待补实验】，但机制与初步数据已齐。

10.3 设计含义

对服务商：先隔离、后密度——为敏感业务划出哪怕一个专属核，收益大于任何调参；内存与 IO 用"双闸/上限"兜底；售卖的"名义包络"与"保护包络"分开表述（分层定价的依据）；准入用证据（节流计数、时间对齐的需求上分位）而不是面板数字。对平台/系统建设者：cgroup v2 的若干"直觉口径"需要实测校准——IO 记账落在整盘而非分区；io.weight 依赖 IO 调度器选择（另有基于 IO Cost 的 io.cost.* 路线，未在本环境验证）；memory.high 的回收压力会外溢到宿主 swap（需要 memory.swap.max 或禁 swap 配合，且作为软阈值不构成 OOM 豁免）；CPU 权重几乎不是延迟保护工具。这些语义空白值得在文档与默认配置层面修复。

10.4 有效性与威胁

构念效度： 服务"业务"用轻量 HTTP/Redis 代理，真实业务（数据库、网关）的敏感路径更长、更依赖系统调用，绝对数字会变，但"尾延迟由重叠驱动"的结构不变；客户负载为合成忙循环/占空比，未含真实业务的慢路径（锁竞争、GC），后续应以真实应用镜像复验。内部效度： 嵌套虚拟化引入额外调度层；已用重复轮次与随机顺序抑制噪声，并在综合验证中观察服务侧指标的稳定性；"权重失效"暂未定位到具体机制（宿主收包路径假设未验证），作为开放问题保留。联合验证进一步暴露：阵发背景的瞬时采样存在相位偏差，控制器需按设计采用时间对齐历史分位（当前未实现，见 7.5.1）；客户侧金丝雀显示紧内存上限可造成秒级停顿，闸门尺寸应作为显式产品参数标定。控制历史边界（预实验）。 本文验证的观测集在测试负载族内足以支撑容量决策，但不能识别工作保留语义。受控成对预实验（一台可替换/最新态客户 vs 一台持久队列客户；基线遥测匹配 0.80 vs 0.83 核；同一 20% 配额 3 分钟、随后释放）：限速段两台客户的宿主遥测不可区分（0.200 vs 0.200 核；节流 143.2 vs 143.2 秒），而释放后的未来截然不同——可替换客户立即回到基线、恢复比 κ=E/D=0.004（被丢弃的工作永不返回）；持久队列客户饱和排空约 12 分钟、κ=0.975。控制动作之前收集的宿主历史，无法同时预测两种语义在动作之后的负载；“动作后证据是否仍有效”是观测必要性命题的开放边界，多负载、多轮复测列为未来工作（工件：research_data/debt_pilot/；模型级可执行反例见 tools/control_history_tests.py）。

外部效度： 两套测试床（4 vCPU 嵌套与 96 线程裸金属，含多核数档细扫）与两台生产宿主深描；生产证据为观测性锚点而非受控实验；生产遥测为分钟级——PPC 多窗验证基于重建秒级序列（模型回放一致性），独立秒级真值与误报/漏报率待未来工作；跨宿主/跨硬件的外推已在缺口清单中列为独立验证项。统计： 关键结论 4–7 轮复现，范围已在各表给出；轮级 bootstrap 置信区间（指示性）见 manuscript/interval_summary.txt；准入对照、冷启动与方法评估仍为单轮预实验，正式版本待补（缺口清单第 3 项）。

10.5 与超大规模路线的边界

本文不替代 AUDIBLE/Coach 类方法在大平台上的价值：它们解决的是"有长期数据与调度自由度时的容量优化"；我们解决的是"没有历史、没有迁移余地、甚至看不真需求的小宿主如何不翻车"。两者可组合——例如以本文的截断校正在小宿主端产出干净的需求证据，再交给大平台式的预测器做全局规划。

11 结论

本文面向一个被大规模云研究忽略的运营场景：把便宜、多数时间空闲、偶发突发的客户超售打包进少量物理资源的小型 VPS 宿主。我们用两套自建测试床（4 vCPU 嵌套床与 96 线程裸金属床，后者以 64 台客户舰队复现核心结论，并经 SMT/NUMA 拓扑核验物理核级隔离）、100/180/30 轮量级的复测批次，以及两台真实宿主的匿名只读遥测，把“安全超售”重写为三个依次递进的问题。

识别（Identify）：配额截断使需求在聚合计数器中不可完全观测。点估计等于运行段均值，其精确条件是两段需求均值相等，需求恒定只是充分条件；在持续饱和假设下存在条件性下界 $q(1+t)$；聚合计数器上则存在非可辨识构造。90 个 cycle 的一致验证显示节流校正估计与真值相符，而基于少报的松绑决策在 30 个独立轮、90 个时间相关 cycle 中全部违约。混合占用消融进一步表明，“懂配额的缩放基线”在部分饱和下会高估，节流证据是区分“被截断”与“真的闲”的关键。

预测（Predict）：容量由负载相位结构决定，而非平均利用率。随机与同步相位的安全容量比为主口径 3.5 倍（28 对 8 台）、中位口径 4 倍（40 对 10 台），并存在“35% 忙碌被压垮、98% 忙碌安全”的反例。在此之上给出带明确假设的安全容量近似模型 $N^* \approx C/(\varphi+(1-\varphi)\rho)$：结构性相位下两点命中断点，混合端偏保守，纯随机端偏乐观且需实测口径修正；误差方向与单轮边界均如实报告。多窗前向预测复验完成，5 个窗口方向命中 5/5。

行动（Actuate）：识别与预测被组装为完整控制器与无回归控制堆栈。完整 14 局在线对决中，相位感知准入是唯一同时做到随机相位 16–20 台与对齐相位停在 8 台档位的策略。保守基线在两相位都只卖 8 台；对齐 8 台档的客户 P5 约为 99%，固定 2× 的 16 台档仅 48.6%，两项结论均来自 4 轮阶梯复测。对照的 audible 式与忙率阈值法在同步相位卖到 40 台，客户 P5 崩至 16%，依赖独立性的卷积与平均利用率判据的相位盲区被端到端量化。解码后的组件分解（配额保守基线、截断校正、相位对齐、暂停护栏）与四种基线在统一到达流下对照，回答“同等质量约束下多卖多少、少违约多少”。资源效率侧作为支撑性扩展列于第 9 章：KSM 去重 33.4%、空闲页上报回收 303 MB、zram 吸收 176.8 GB 溢出；CPU 微周期、IO 风暴与 QoE 金丝雀各记“增益 / 隐形代价 / 可见回归”三笔账。

诚实边界：当前为两套测试床、单台裸金属宿主；负载以合成占空比为主，生产回放（30 分钟真实日程与 5 窗前向复验）提供场景锚点，真实混合业务负载与更多到达顺序的复测仍是未来工作；轮级范围已全稿报告，形式化 bootstrap CI 待数据冻结后终刷。本文为中小 VPS 服务商给出可复现的“观测设计 + 容量模型 + 控制器”工作流，并为超售研究补充可辨识边界与相位结构这一此前被忽视的视角。

附录 A 观测必要性的形式化证明与可执行复核

对应 §3.3.1（命题 A/P3）与 §3.6（命题 B1/B2/C）。全部构造由 tools/theory_tests.py 数值复核， 输出存档于 research_data/theory_checks.txt（200 行内可重跑，无外部依赖）。

A.1 命题 A（截断不可能性）

模型。 单 cgroup、带宽式配额（周期 $P$、预算 $qP$）、窗口 $W=P$；观测 $(u,t)$。

构造。 $q=0.2$。过程 A：$d\equiv 5/9$；过程 B：$d=1.0$ 占 84%、0 占 16%。A： 预算在 $(q/d)P=0.36P$ 耗尽，$t=1-q/d=0.64$，$u=q=0.2$，均值 $5/9$。B： 活跃段内预算在 $0.2P$ 耗尽，节流至活跃段结束（$0.84P$），$t=0.64$，$u=0.2$，均值 $0.84$。⇒ $(u,t)=(0.2,0.64)$ 完全相同，均值差 $0.284$；任何估计器 $f(u,t,q)$ 必在其中一例上误差 $\ge 0.142$。∎

A.2 命题 B1（容量不由边际决定）

构造。 $N$ 台、每台每周期工作 $w$ 秒（边际同分布）、池 $C=8$、$\rho=w/P$。对齐：峰值 $=N$ ⇒ 容量恰为 $C$。随机：平均并发 $\rho N$，任何合理安全口径都要求时间平均不超载，即 $\rho N\le C$ ⇒ $N\le C/\rho$（上界；峰值约束只会更紧）。⇒ 容量比 $\le 1/\rho$（$0.2$ 时即 5）——仅对零性能损失口径成立。适用范围。 该上界要求时间平均交付需求不超载（$\rho N\le C$）；本文运行口径（客户速率 P5 $\ge$ 单机基线 70%）明确允许 QoE 退化，实测主口径容量是另一类依赖口径的对象；$C/\rho$ 只界零损失口径，引用处均如此标注。主口径实测 28 vs 8 = 3.5×，位于上界之内约 70%——尾部口径使比值进一步收缩。∎

A.3 命题 B2（利用率阈值不可能性，定理；任意窗长）

定理. 对任意窗长 $L$（可跨多个周期），对齐舰队的窗口平均交付利用率$\le U(L)=\big[w\lfloor L/P\rfloor+\min(L\bmod P,\,w)\big]/L$。证明. 活跃集合是周期 $P$、每周期活跃 $w$ 秒的周期函数。任意 $L$ 秒窗含 $\lfloor L/P\rfloor$ 个完整周期（各贡献 $w$ 秒交叠）加一个长 $r=L\bmod P$ 的残窗（交叠 $\le\min(r,w)$）；交付速率 $\le C$；故窗利用率 $\le U(L)$。∎特例与推论. $L\le P$ 时 $U=\min(w,L)/L$（util80 的 $L{=}30$ s：40%）；$L=kP$ 时 $U=\rho$；$L=kP+r\,(r>0)$ 时可略超 $\rho$（$L{=}90$ s：26.7%）。任何“窗口利用率 $<\theta$ ⇒ 放行”的规则，在 $\theta>U(L)$ 时对对齐舰队无上界（util80：40% $<\theta{=}80\%$，实测卖至帽 40，§7.4.1）。可执行复核：T-B3/T-B4（tools/theory_tests.py）。

构造。 采样间隔 $\Delta$、突发宽度 $w<\Delta$、突发窗置于两次采样之间（如 $\Delta=30$ s、采样相位 3 s、窗 $[15,27)$）：危险舰队与良性（全闲）舰队给出完全相同的全零采样序列。正控：$\Delta=10$ s 时采样必落入 $w$ 内。∎推论. 采样率须 $\ge 1/w$（本文在线历史 1 s 对 12 s 突发留 12× 裕量）。

A.5 不可证明的部分（诚实声明）

"最小充分观测集"的充分性是目标负载族上的经验结论（14 局对决 + C5），不是定理；其直接检验（show5、抗混叠对照）完成后回填 §3.6。

References

1. S. J. Jandaghi, K. Mahdaviani, A. Mirhosseini, S. Elnikety, C. Amza, B. Schroeder. AUDIBLE: A Convolution-Based Resource Allocator for Oversubscribing Burstable Virtual Machines. ASPLOS '24, Vol. 3, 14 pages. DOI 10.1145/3620666.3651376.
2. B. Reidys, P. Zardoshti, Í. Goiri, C. Irvene, D. S. Berger, H. Ma, K. Arya, E. Cortez, T. Stark, E. Bak, M. Iyigun, S. Novaković, L. Hsu, K. Trueba, A. Pan, C. Bansal, S. Rajmohan, J. Huang, R. Bianchini. Coach: Exploiting Temporal Patterns for All-Resource Oversubscription in Cloud Platforms. ASPLOS '25, Vol. 1, 18 pages. DOI 10.1145/3669940.3707226.
3. B. Wang, G. Zhao, H. Xu, S. Wu, Z. Yu, J. Liu, J. Lu, S. Xu, F. Meng. Rethinking Cloud Optimization: Volatility-Driven for Better Outcomes (the Hestia framework; MCV volatility metric). SIGCOMM '26, pp. 491–504. DOI 10.1145/3789240.3829141.
4. S. M. Sajal, L. Marshall, B. Li, S. Zhou, A. Pan, K. Mellou, D. Narayanan, T. Zhu, D. Dion, T. Moscibroda, I. Menache. Kerveros: Efficient and Scalable Cloud Admission Control. OSDI '23, pp. 227–245, USENIX.
5. L. Wang, M. Das, F. Yang, J. Sheng, B. Qiao, H. Dong, S. Qin, V. Rühle, C. Bansal, E. Cortez, Í. Goiri, S. Rajmohan, Q. Lin, D. Zhang. ProtoRAIL: A Risk-cognizant Imitation Agent for Adaptive vCPU Oversubscription in the Cloud. Proceedings of Machine Learning and Systems 7 (MLSys 2025). Preprint: ProtoHAIL, arXiv:2401.07033. https://proceedings.mlsys.org/paper_files/paper/2025/hash/42e2b24104bc92d724ce45c0c2f91e1d-Abstract-Conference.html
6. P. Jacquet, T. Ledoux, R. Rouvoy. SCROOGEVM: Boosting Cloud Resource Utilization With Dynamic Oversubscription. IEEE Trans. Sustainable Computing 9(5):754–765, 2024.
7. S. Chen, S. He, E. Sun. Risk-Bounded GPU Resource Oversubscription via Conformal Demand Envelopes in Production AI Clusters. Journal of Advanced Computing Systems 4(5):119–134, 2024.
8. M. Majd, F. Cheng, A. Pahlevan. Right-sizing Recommendations (RSR): Cloud Workload Conformal Prediction for Virtual Machines in Data Center Operations. WI-IAT 2025; arXiv:2607.24773.
9. S. He, T. Liu, P. Lama, J. Lee, I. K. Kim, W. Wang. Performance Testing for Cloud Computing with Dependent Data Bootstrapping (the Metior methodology). ASE 2021, pp. 666–678, IEEE.
10. InditexTech. k8s-overcommit-operator (Kubernetes oversubscription-class operator, Apache-2.0, v1.3.4). https://github.com/InditexTech/k8s-overcommit-operator
11. Red Hat. ClusterResourceOverride (OpenShift admission plug-in controlling node density via request/limit ratios). OpenShift Container Platform documentation, https://docs.openshift.com/
12. KubeVirt. Per-VM CPU Overcommitment Configuration in KubeVirt (issue #15710; opened 2025-09, closed 2026-02: per-VM oversubscription ratios remain unsupported); global cpuAllocationRatio documentation. https://github.com/kubevirt/kubevirt/issues/15710
13. P. Jacquet, T. Ledoux, R. Rouvoy. SweetSpotVM: Oversubscribing CPU without Sacrificing VM Performance. CCGrid 2024, pp. 148–157, IEEE; and SlackVM: Packing Virtual Machines in Oversubscribed Cloud Infrastructures (same authors). HAL hal-04636648 / IEEE Xplore 10740881.
14. Calabi (engineering documentation). Host Resource Management / Host Memory Oversubscription (Gold/Silver/Bronze slices, zram/KSM/THP combination, measured CPU oversubscription of 1.72:1). https://gprocunier.github.io/calabi/
15. Linux kernel documentation. Control Group v2. https://docs.kernel.org/admin-guide/cgroup-v2.html
16. Linux kernel documentation. Pressure Stall Information (PSI). https://docs.kernel.org/accounting/psi.html
17. Linux kernel documentation. cgroup v2 IO controller (io.max / io.weight / io.cost / io.latency; see the IO chapter of [15]). https://docs.kernel.org/admin-guide/cgroup-v2.html#io
18. KVM scheduling under oversubscription: KVM Forum 2021 (lock-holder preemption and vCPU spinning); and the kernel patch series "[PATCH v2 0/9] sched/kvm: Semantics-aware vCPU scheduling for oversubscribed KVM" (vCPU debooster, IPI-aware directed yield; LKML, 2026). https://lore.kernel.org/all/?q=%22Semantics-aware+vCPU+scheduling%22
19. Proxmox Server Solutions. Proxmox VE documentation (QEMU/KVM configuration and external metric server interface). https://pve.proxmox.com/pve-docs/
20. QEMU Project. Virtio-Balloon Free Page Reporting. https://wiki.qemu.org/Features/FreePageReporting
21. Linux kernel documentation. Kernel Samepage Merging (KSM). https://docs.kernel.org/admin-guide/mm/ksm.html ; zram: Compressed RAM-based block devices. https://docs.kernel.org/admin-guide/blockdev/zram.html
22. S. Lambert, E. Caron, L. Lefèvre, R. Grivel. Consolidation of virtual machines to reduce energy consumption of data centers by using ballooning, sharing and swapping mechanisms (ORCA). Future Generation Computer Systems 174:107968, 2026. DOI 10.1016/j.future.2025.107968.