# Jev 10 RPM配置、15 RPM配额和14 RPM离线估算

## 配置在哪里

用户确认服务配额15 RPM；本次没有调用Provider或外部接口再次探测额度。正式准入[providers-before.json](../../experiments/guitaboo-5app-1rep-baseline-comparison-20261107/admission/providers-before.json)记录Gateway Jev为rate_rpm=10、max_inflight=2、timeout=60；submission.json五条Jev配置的provider_snapshot均rate_rpm=10。Native properties无RPM项，Native HTTP先到本地Gateway，因此限速不在Native。

当前平台`lab_platform/provider.py:150–193`的_acquire按provider='jev'查询全局last_sent，pending未发送租约互斥，并检查`last_sent+60/rate_rpm`及全局活动租约数；`request:222–242`轮询准入，每次sleep0.05秒。不是滑动窗口计数器，是全provider固定最短发送间隔。当前实现副本与hash：[provider-current.py](evidence/provider-current.py)、[identity](evidence/provider-current-identity.json)。平台没有可用的历史Git提交/逐字节部署快照，**不把当前文件自动当作冻结历史部署代码**；运行事实由冻结配置与Gateway发送时间支持。

为什么数值选择10而非15：能证实配置被显式设为10，不能从已找到证据确定原始选择者的配额判断/保守理由。不能把10写成Provider强制上限，亦不能仅依据“可能保守”给出确定原因。

## 并发和共享额度

正式本轮[jev_serial_scheduler.py:1–8, 50–86](../../experiments/guitaboo-5app-1rep-baseline-comparison-20261107/admission/jev_serial_scheduler.py)一次只提交一个Jev正式Run，待terminal再提交下一个。这是本批次外部串行提交策略；Gateway租约配置仍为2，不是“Native全局只能一个Jev请求”的硬编码。设备锁/同App设备绑定与Provider限流是另一层约束。

以只读SQLite、限定字段扫描本轮Jev起止时间及前60秒，共691条Gateway调用：686正式HTTP、5条同Run未匹配正式Native fingerprint的准入调用；没有其他Run占用这个窗口的Gateway额度。最大同时上游处理1，最短全局send间隔6.023767秒，中位数6.068512秒，任意半开60秒窗口最多10次。[global-jev-calls.json](evidence/global-jev-calls.json)、[rate-checks.json](evidence/rate-checks.json)。不读取凭据；平台外直接用同key发送的请求及更早未结束租约不能由本快照完全排除，标UNKNOWN。

Scarlet正式send-gap P50=6.063120秒、最短6.028002；Activity P50=6.067621、最短6.023767。请求间隔受Native工作间隙影响，不能每个gap都算成主动sleep6秒。实际上游处理在此窗口最高并发1，现有大量排队与rate pacing一致，不能逐毫秒把全部Gateway残差归成限速sleep。

## 14 RPM可行条件

14 RPM给出60/14=4.285714秒的最小发送间隔。如果15 RPM为同key按请求数配额，且所有共享发送都经过同一个基于实际send时刻的限速器，连续半开60秒最多14次（包含端点的保守窗口至多15），留有余量。当前数据库共享多实例准入设计能避免未发送租约之间的准入空隙；是否与远端计费窗口、token额度和其它key流量完全一致仍未知，不能保证永无429。提高并发、绕过Gateway或未统一计数的重试都可能消耗余量。这里只审计，未修改生产配置。

## 两种离线敏感性计算

**A. 逐请求固定前序实际发送时刻。** 按全局691条实际send排序，保留每条的归档arrival、前一条实际send和未解释的dispatch残差；减少量=max(arrival, prev_send+6)−max(arrival, prev_send+60/14)。它隔离单次间隔参数的作用，不把残差自动算成限速；每条减少量≤1.714286秒。Scarlet443.938秒，Activity236.834秒。不能把各条假设同时发生解释为可实现完整运行轨迹。

**B. 全局固定到达时间的理想队列重放。** 691条共同FCFS，固定上游服务时长，最多2 active，分别间隔6和4.285714秒，后续send使用模拟前序send。没有调用Provider，不模拟APE因回复早而改变下一次到达。由于轮询/identity/DB等未分解，10 RPM基准也不能完全复现原队列，故仅报告“模型内10→14差”，不把观测−理想14全额算成收益。

| App | 正式HTTP | 实测队列秒 | 逐请求固定前序send估算减少秒 | 理想队列10→14减少秒 | 理想10队列秒 | 理想14队列秒 |
|---|---|---|---|---|---|---|
| activitydiary | 243 | 410.307 | 236.834 | 320.323 | 357.427 | 37.104 |
| wikipedia | 25 | 3.115 | 1.714 | 1.714 | 2.263 | 0.549 |
| scarletnotes | 318 | 900.873 | 443.938 | 727.030 | 785.260 | 58.230 |
| omninotes | 80 | 55.344 | 39.288 | 41.642 | 50.464 | 8.822 |
| odkcollect | 20 | 47.512 | 22.333 | 37.246 | 44.098 | 6.852 |

理想10 RPM全局与观测queue残差P50=0.151秒、P95=0.810秒、max1.555秒；Scarlet实测queue900.873而理想10只有785.260，差115.613秒。这是有实质偏差的情景模型，727.030秒是其内部10→14差，**不是已证实能省727秒**；A与B也不是实际效果上下界。Activity内部差320.323秒同理。

完整每调用重放和5条准入调用保留在[rate-limit-simulation.csv](rate-limit-simulation.csv)。所有估算都不换算成动作数、方法数或覆盖率收益；软timeout缩短还会改变到达/取消/再提交，应另行验证，不能与排队估算简单相加。