执行摘要

• 一句话：KV-offload 小评估降配至 1 GiB，修复 CI /dev/shm 不足
• 推荐动作：不值得精读，但值得快速浏览其根因分析方法论：作者准确地把失败定位到 #50094（CPUOffloadingSpec 进入 /dev/shm）与 #50358（容量校验）两条前置变更组成的约束链，并采用 "按用例差异化配置 + unshare 模拟受限环境" 的验证方式，这类定位 CI 资源问题的方法对维护 offloading 相关测试的工程师有参考价值。

功能与动机

PR body 明确指出这些 job 在 H200 CI worker 上因共享 /dev/shm 空间受限而在评估开始前就失败："These jobs share a constrained /dev/shm on H200 CI workers and were failing before evaluation began, despite needing substantially less than 1 GiB during execution." 根因链条为：#50094 将 CPUOffloadingSpec 移入 /dev/shm，#50358 增加了容量校验，而部分共享 H200 worker 可用空间只有 1.4-2.1 GiB，小评估却默认申请 4 GiB，因此启动阶段即被容量校验拒绝。

实现拆解

1. 变更入口：唯一改动文件是 tests/evals/gsm8k/test_gsm8k_offloading.py，其中 OffloadingModelConfig dataclass 的 cpu_offload_gib 默认值为 4，所有评估用例共用该默认值。
2. 核心改动：在 MODELS 列表中，为 OffloadingConnector 下的两个小型用例 offloading-nemotron-h-8b 与 offloading-gemma-4-e4b-it 显式传入 cpu_offload_gib=1，覆盖默认的 4 GiB；qwen3.5-35b 保持默认值，deepseek-v4-flash 维持其显式的 16 GiB，即只对确认用量远小于 1 GiB 的小型用例降配。
3. 配置配套：无需改动任何 schema、环境变量或部署脚本，因为 cpu_offload_gib 是测试内部资源预算参数，仅影响 CI 测试进程自身。
4. 验证方式：作者在单台 H200 上用 unshare --mount 挂载 -o size=2g 的 tmpfs 模拟受限 /dev/shm，并运行 -k "nemotron-h-8b or gemma-4-e4b-it" 的筛选用例；主分支报 RuntimeError: Insufficient space in /dev/shm: 4095/4096 MiB required, 1405 MiB free，PR 分支结果为 4 passed, 5 deselected, 14 warnings in 663.99s。

关键文件：

• tests/evals/gsm8k/test_gsm8k_offloading.py（模块 评估测试；类别 test；类型 test-configuration；符号 OffloadingModelConfig, MODELS）: 唯一变更文件，为两个小型 KV-offload 评估用例（Nemotron-H-8B、Gemma-4-E4B-it）显式设置 cpu_offload_gib=1，解决共享 H200 CI worker 上 /dev/shm 容量不足导致的启动失败。

关键符号：未识别

关键源码片段

tests/evals/gsm8k/test_gsm8k_offloading.py

唯一变更文件，为两个小型 KV-offload 评估用例（Nemotron-H-8B、Gemma-4-E4B-it）显式设置 cpu_offload_gib=1，解决共享 H200 CI worker 上 /dev/shm 容量不足导致的启动失败。

# OffloadingModelConfig 的 cpu_offload_gib 会直接决定 CPUOffloadingSpec
# 在 /dev/shm 中的预占空间：#50094 起 spec 被写入共享内存，#50358 起
# 启动时会做容量校验，因此该值必须小于 worker 实际可用空间。
@dataclass
class OffloadingModelConfig:
    id: str
    model: str
    connector: str
    accuracy_threshold: float
    tolerance: float = 0.05
    extra_server_args: list[str] = field(default_factory=list)
    env_dict: dict[str, str] = field(default_factory=dict)
    cpu_offload_gib: int = 4 # 默认 4 GiB；小型用例在实例级覆盖为 1
    startup_timeout: int = 600
    spec_name: str = "CPUOffloadingSpec"
​
​
MODELS = [
    # ── OffloadingConnector ──────────────────────────────────────────
    OffloadingModelConfig(
        id="offloading-nemotron-h-8b",
        model="nvidia/Nemotron-H-8B-Base-8K",
        connector="OffloadingConnector",
        # 基线 ~0.49（GB200 上 200 题测得）；H200 实际用量远小于 1 GiB
        accuracy_threshold=0.39,
        cpu_offload_gib=1, # 覆盖默认 4 GiB，适配 1.4-2.1 GiB 的 /dev/shm
    ),
    OffloadingModelConfig(
        id="offloading-gemma-4-e4b-it",
        model="google/gemma-4-E4B-it",
        connector="OffloadingConnector",
        # 基线 ~0.64（GB200 上 200 题测得）
        accuracy_threshold=0.55,
        cpu_offload_gib=1, # 与 Nemotron-H-8B 同理，仅保留必要预算
    ),
    # 其余用例（Qwen3.5-35B、DeepSeek-V4-Flash 等）保持默认或 16 GiB，
    # 此类用例 offload 需求更大，不在本次降配范围内。
]

评论区精华

PR 无实质技术争议。claude[bot] 提示这是 fork 来源 PR，自动评审被禁用，需维护者手动触发；维护者 yewentao256 直接批准并留言 "LGTM, thanks for the work!"。整个 review 过程未出现对降配幅度、容量边界或测试覆盖的质疑，说明改动意图清晰、验证充分。

• fork PR 自动评审与维护者批准 (other): 改动较小且验证充分，无技术疑问，直接合并。

风险与影响

• 风险：
  1. 容量边界风险：降配至 1 GiB 后，若未来模型权重、offload 策略或 CPUOffloadingSpec 的实现变化导致实际共享内存占用上升，可能重新触发 Insufficient space，且仅在真实共享 H200 worker（1.4-2.1 GiB）上暴露。
  2. 验证环境差异：作者用 2 GiB tmpfs 模拟，真实 worker 可用空间更小（1.4-2.1 GiB），但实测用量远低于 1 GiB，因此留有余量；不过模拟环境与真实 CI worker 的 tmpfs 行为（如其他 job 并发占用）并不完全一致。
  3. 影响面可控：改动完全限定在 tests/evals/gsm8k/test_gsm8k_offloading.py 的测试配置数据中，不触及任何生产路径、内核或运行时逻辑，回归风险极低。
     - 影响：影响范围集中在 CI 基础设施：解除了两个 GSM8K KV-offload 评估（Nemotron-H-8B、Gemma-4-E4B-it）在共享 H200 worker 上的启动阻塞，避免评估因 /dev/shm 容量校验失败而反复重跑。对最终用户无任何功能影响，对团队而言减少了 CI 噪音与 rerun 成本。改动模式清晰，可复用于后续新增的 offloading 小型评估用例。
     - 风险标记：仅测试配置变更, CI 环境容量适配, 1 GiB 预算依赖硬件, 无生产路径影响

关联脉络

• PR #50094 Move CPUOffloadingSpec into /dev/shm: PR body 明确指出该 PR 是根因起点：将 CPUOffloadingSpec 移入 /dev/shm，使 offload 预算开始消耗共享内存容量。
• PR #50358 Add /dev/shm capacity validation: PR body 指出该 PR 增加了容量校验，从而暴露出小评估默认申请 4 GiB 超出共享 H200 worker 可用空间的失败。