原 Cluster 测量退役后，哪些结论仍有效？¶
主要结论¶
旧吞吐与历史成本测量只对冻结的、已退役的 Controller/Worker 实现有效，不能证明当前 daemon 的吞吐、密度或恢复成本。独立本机容量与 VM 内存 benchmark 仍保留各自的证据范围；这里没有新增测量。
| 需求 | 选型含义 |
|---|---|
| 解读旧 Cluster 结果 | 仅限下列历史负载、制品与预算 |
| 规划本机执行或停驻状态 | 使用容量和VM 内存，不使用 Worker 曲线 |
| 规划 daemon 或比较调度系统 | 未测；不能沿用旧吞吐或历史成本数字 |
Motivation¶
容量决策需要与实际部署实现相匹配的证据。Controller/Worker 退役后，实验对象已不再存在，把旧测量改名会掩盖这一边界。就绪、有效任务完成和可恢复停驻状态回答不同问题。
实验设计¶
仅描述历史实验：Linux/x86_64、单宿主 KVM、从冻结 Controller/Worker 源码构建的 release 二进制。入口脚本、专属测试、绘图和发布 helper 已退役，没有活动复现命令。每批使用新的 Controller 和 1/2/4 个单槽 Worker；整组共同使用两核配额、CPU 0/1、2 GiB 内存和零 swap。Controller 单独限制为 0.25 核/256 MiB，每个 Worker 为 0.5 核/512 MiB；服务及其子进程都在共同父 cgroup 中。因此一个 Worker 不会单独使用整个两核预算。
每批提交相同的 12 个任务，每个任务创建 64 文件 Git 仓库，完整校验 32 MiB 数据八次，修改四个文件并核对 Git 状态和全部内容。任务返回必须属于预期 Worker、状态成功且输出匹配；保留的每个完成记录与汇总再次核对。耗时从提交开始，到 12 个结果全部经过校验；不包含此前启动 Controller/Worker 的时间。
每档三次预热、30 个正式批次；各轮随机交替 Worker 数，保留所有慢样本。OOM、缺失结果、错误输出或资源配置不符的批次不能进入吞吐统计。共同工具/rootfs 已准备并处于热缓存，部分共享缓存可能在父 cgroup 计费。它不包含模型推理、多主机网络或跨主机对账，也不代表真实 Agent 的任务速率。
实验数据和分析¶
完整任务吞吐和物理内存¶
历史 Controller/Worker 批次，测量日期 2026-10-06（本地时间）。以下表格和下载对应退役制品，不是 daemon 测量。每档 N=30 个完整批次、每批 12 个任务；三个条件共校验完成 1,080 个正式任务，零失败、零 OOM。P50 为中位数；峰值内存是整个父 cgroup（含子 cgroup）的 memory.peak，单位 MiB。
| Worker 数 | 完成任务 / 尝试 | 12 任务耗时 P50，s | 有效任务速率 P50，个/s | 整组峰值内存 P50，MiB |
|---|---|---|---|---|
| 1 | 360/360 | 28.28 | 0.424 | 221.3 |
| 2 | 360/360 | 12.47 | 0.962 | 389.0 |
| 4 | 360/360 | 6.93 | 1.731 | 710.6 |
单 Worker 上限为 0.5 核，增加执行槽会增加可用的执行资源，直到共同两核上限约束整组。结果解释了退役实现在这个预算内减少等待的原因；它没有证明调度器在相同有效 CPU 使用量下变得更快。
| 对照（候选 − 单 Worker） | 12 任务中位耗时差，s | 配对 bootstrap 95% 区间，s |
|---|---|---|
| 两个 Worker | −15.81 | [−15.93, −15.03] |
| 四个 Worker | −21.35 | [−21.36, −20.97] |
区间来自同轮 30 对样本、5,000 次重采样；均不包含零。P95 只在下载表中作参考，没有 P99 或生产尾延迟保证。
长期保留历史记录¶
每个规模使用三个新的独立进程/cgroup，固定两核、16 GiB、零 swap；WAL 位于 NVMe。每进程只有一个 ready 探针任务，其余记录已取消；探针用合成失败终态验证 fencing 和回放，不执行工具。物理峰值包含创建历史、记录校验的临时分配、WAL 页缓存与热重启，不是稳定保留态占用。查询在每个进程内测 30 个批次，但重启和内存各只有三个独立观察值，不能合并成 90 个样本。
N=3 个独立进程/规模，表内为 P50；括号是观察到的最小–最大值，不是置信区间。
| 保留记录 | 整组生命周期峰值，MiB | 热日志恢复，s | WAL，MiB |
|---|---|---|---|
| 1,000 | 24.9 (22.8–31.4) | 0.017 (0.017–0.018) | 1.96 |
| 10,000 | 96.3 (96.2–96.7) | 0.143 (0.143–0.145) | 19.62 |
| 100,000 | 827.9 (827.9–828.0) | 1.422 (1.410–1.435) | 196.21 |
| 1,000,000 | 8142.4 (8127.4–8144.1) | 14.622 (14.411–14.710) | 1962.11 |
退役 Controller 的百万记录批次观察到约 8 GiB 生命周期峰值、约 14.62 秒热日志恢复；两者都不是当前容量建议。恢复不包括 Worker 对账或冷磁盘读取。类型化内存查询的各规模的进程中位数汇总约 107–110 ns，仅代表合成状态计数调用，不是 HTTP/CLI 请求延迟；详情见下载表。
与已有调度方案的比较边界¶
Kubernetes、Ray 和云端沙箱的相同负载、共同预算对照未测，不提供数值排名。历史测量不能规划当前 daemon 的容量，也不能作为替换通用调度平台的依据。单任务的 Docker、Firecracker、QEMU 对照见端到端任务。
历史数据下载与来源¶
以下五份 CSV 原字节保留，仅作为退役 Controller/Worker 制品的历史证据。没有活动 Cluster 测量或发布入口；运行手册记录退役范围，不提供新复现命令。
历史成本 CSV · 历史来源摘要 · 吞吐与内存 CSV · 配对比较 CSV · 制品与预算摘要 · 比较方法 · 复现手册
整理表关联同一原始报告及逐任务证据审计摘要。原始报告、完成记录、服务日志、控制配置、源码与二进制保存在本地 .data/。实现分析见Cluster 技术分析。