# Context fallback：盈利条件与下一步决策

日期：2026-09-17。范围：既有八路模型 0–10 s、896 个 Jacobian 的历史诊断数据。本轮只做数据归并和预算分析，没有构建新 worker、修改求解器、扩展 semantic replay 或重跑性能实验。

## 结论

**停止按单个 operation 推进 semantic replay。下一次只值得先测 `position379 / PNVO001_1` 中 `state_valve` 数值尾部的 kernel memo。** 原 context 查询、物性写入、valid 演变和 native 调用仍照常发生；这与跳过整个 operation 是不同实验。

- 当前 343 个 fallback operation 的跨组单次均值最高只有 **1.315 µs**；即使拆到 5,157 个 `(group, position)` 组合，最高均值也只有 **1.642 µs**。没有一个能承担当前 **7.109 µs** 的单 operation replay 开销，尚未计 baseline。
- 较贵 interval 是多个廉价 operation 的集合。不能把整个 interval 的预算发给其中每个 operation。
- whole-context guard 成功的 **20,608 次**继续使用原机制；失败的 **139,776 次**不能直接恢复 baseline 全 context，其真实出口均与 baseline context 不同。
- 不继续优化 R288，不启动 position52、R475 或其他区间的 semantic replay 实现。R490 等长区间只保留为预算上的备选，尚不具备立即实验的收益与语义证据。

## 1. 数据覆盖与计时口径

| 数据层 | 覆盖 / 结果 | 本报告用途 |
|---|---|---|
| 全量 census | 115 个失败 interval；156 个 group/interval；343 个 position；5,157 个 group/position | 次数、归属和摊销上限 |
| fallback 原计算 | 139,776 次 interval；4,620,672 次 operation 执行 | 去重后的成本分母 |
| 分层 profiling，扣空标记估计 | 全轨迹 context fallback **613.201 ms** | 总量交叉检查 |
| interval 独立计时 | **682.630 ms** | 原区间预算；含区间调度及诊断 hook，不含失败前的 guard |
| operation 独立计时 | **660.431 ms** | 分离 native 语句与纯代数/alias；operation 预算 |
| function 独立计时 | exclusive 合计 **879.118 ms** | 函数排序，不能加到以上时间或视为净收益 |

interval、operation、function 各三轮；每轮分层抽取 112/896 个 Jacobian，按频率折算全轨迹后取三轮算术平均。这里的“µs/次”是累计折算时间除以全量次数，不是单次延迟分位数。完整表另外保留三轮值和 min/max。

这些是**带插桩的预算估计**。极短 operation 的计时可能明显高估；函数 exclusive 仅扣除已插桩子调用。不同模式的差值不能直接当作 dispatch 成本，更不能叠加。R288 最新实验的机器负载与旧 profiling 不同，跨批代入只用于成本量级情景，不能预测加速。

### 可查验的完整交付物

- [115 个 interval、156 个 group/interval 的全部成本和预算，以及 196 个纯代数连续段](fallback_profitability_intervals.md)。按 `次数 × 单次成本` 排序，含 operation/native 数量、纯代数时间、主要函数、共享上限。
- [343 个 operation 的全部热点和预算](fallback_profitability_operations.md)。含 interval、group、原始 operation ID、原生调用、次数、时间、摊销边界与建议。
- [完整 JSON](../../test/fallback-profitability-20260917/analysis.json)：另含全部 5,157 条 group/position 映射、原代码、逐区间函数数据、三轮折算原始数值、输入 SHA-256、预算情景和检查结果。
- [复现脚本](analyze_fallback_profitability.py)：只读取历史产物。运行 `.venv-win/Scripts/python.exe -B tests/manual/analyze_fallback_profitability.py`。

原始依据：[fallback 诊断](../../test/context-fallback-20260917/report.md)、[原始统计](../../test/context-fallback-20260917/analysis.json)、[代码及依赖计划](../../test/context-fallback-20260917/plan.json)、[分层 profiling](local_probe_profile.md)、[R288 typed 实验](r288_typed_replay_report.md)。当前工作区其他改动未作为这份历史测量的重新验收对象。

## 2. 热点：大区间与廉价 operation 必须分开

### 累计成本最高的区间及重要对照

“纯代数 ms”来自 operation 模式，只计完全不含 native 调用的语句；不包含 native 内部的代数部分，后者尚无独立测量。

| interval / 范围 | group | 次数 | 原区间累计 ms | 原区间 µs/次 | ops / native ops | 纯代数 ms |
|---|---|---:|---:|---:|---:|---:|
| R490 [49,184) | 24,25 | 1,792 | 33.807 | 18.865 | 135 / 15 | 4.139 |
| R485 [50,181) | 22,23 | 1,792 | 31.667 | 17.671 | 131 / 14 | 4.072 |
| R480 [51,178) | 20,21 | 1,792 | 30.269 | 16.891 | 127 / 13 | 3.954 |
| R475 [52,175) | 18,19 | 1,792 | 27.257 | 15.211 | 123 / 12 | 3.841 |
| R470 [53,172) | 16,17 | 1,792 | 25.381 | 14.164 | 119 / 11 | 见完整表 |
| R465 [54,169) | 14,15 | 1,792 | 22.936 | 12.799 | 115 / 10 | 见完整表 |
| R460 [55,166) | 12,13 | 1,792 | 22.117 | 12.342 | 111 / 9 | 见完整表 |
| R3 [30,48) | 0 | 896 | 21.393 | 23.876 | 18 / 17 | 0.033 |
| R455 [56,161) | 10,11 | 1,792 | 20.735 | 11.571 | 105 / 8 | 见完整表 |
| R457 [297,444) | 10,11 | 1,792 | 15.880 | 8.862 | 147 / 4 | 5.653 |
| R49 [373,444) | 0 | 896 | 15.782 | 17.614 | 71 / 4 | 1.814 |
| R288 [16,17) | 6 | 896 | 0.918 | 1.024 | 1 / 1 | 0 |

R490–R455 前半区域主要是 `native_pipe_flow_cached_context`，包含 PH context 获取和 `state_valve` 等链路；R457/R49 的四个 native 是 `native_medium_orifice_context`。R3 的 17 个 native 集中在管路/节流流量，因而短区间也可能更贵。

**R49 暂不作首选**：区间模式是 17.614 µs/次，operation 模式总和却只有 7.283 µs/次。三轮区间值都偏高，说明不是简单挑掉一轮就能解决；尚未分离具体原因。不能把两者差额承诺为可消除的调度成本。R3 也存在 23.876 vs 20.471 µs 的模式差异，预算应同时参考两种口径。

group 0–9 合计 **361.823 ms**，group 10–25 合计 **320.807 ms**，group26 为 0。大区间并未占据全部 fallback。

### 累计最贵的几个 operation

| position / 原ID | operation | 失败执行次数 | 原计算累计 ms | µs/次 | 每 Jacobian 结构复用上限 |
|---|---|---:|---:|---:|---:|
| 379 / 24 | PNVO001_1.port_2 | 19,712 | 25.926 | 1.315 | 22 |
| 405 / 28 | PNVO001_3.port_2 | 19,712 | 24.907 | 1.264 | 22 |
| 392 / 26 | PNVO001_2.port_2 | 19,712 | 24.721 | 1.254 | 22 |
| 80 / 88 | PNL00R_4.port_1 | 19,712 | 24.410 | 1.238 | 22 |
| 82 / 90 | PNL00R_5.port_1 | 19,712 | 23.721 | 1.203 | 22 |
| 418 / 30 | PNVO001_4.port_2 | 19,712 | 23.021 | 1.168 | 22 |

重复 22 次让 baseline 有更好的摊销机会，**不能让每次 1.315 µs 的计算承担 7 µs 的 probe 成本**。同一 position 的 baseline 可以在结构上被这些组引用，但查询分支、消费字段、kernel 参数是否相同，仍须单独验证。现有“显式 operation 输入/输出相同”不是这种证明。

## 3. Break-even：必须给 baseline 与 probe 共用一个预算

令 `C` 为每次可省的原计算，`P` 为 validation + patch + commit + 新增调度等 probe 开销，`H` 为每个 Jacobian 新增 baseline 捕获成本，`m` 为这份记录可成功服务的 probe 数。单位均为 µs：

```text
net_per_J = m × (C − P) − H
P < C − H/m
H < m × (C − P)
```

不能同时把 `C` 分别全部分配给 H 和 P。表中 H 上限以 P=0 或指定值计算；只有严格低于上限才盈利。暂用全部成功、无新增失败成本的乐观条件。

若仅有 `k` 次成功、其余尝试付出失败 guard 成本 `F`：

```text
net_per_J = k × (C_success − P_success) − H − (attempts − k) × F
```

同一区间跨组最多共享一次 baseline 的结构上限通常是 1 或 2；operation 跨重叠区间可达到 22。**不能把同一 group/position 在多个 interval 中重复计价**，本分析按 census 的唯一归属去重。若动态 schema 无法共享，m 必须减小；如果要按组捕获 H，则不能继续除以全部组数。

### 用当前 R288 typed 成本作量级筛选

同批实测中位数：原 operation **1.775 µs**，typed 三阶段 **7.109 µs**，完整路径 **7.575 µs**，baseline 新增 **18.258 µs/J**。计入 baseline 的配对净收益为 **−20.415 ms/896 次**；所有轮次均为负。旧批的 1.143/22.521 µs 不能和最新批混为一组对照。

以下把 `H=18.258` 仅作为预算情景；P 也必须覆盖新增调度/统计等成本，使用三阶段 7.109 已比完整路径更乐观。

| 候选 | C µs | m 上限 | Hmax，P=0 | Hmax，P=5 | Pmax，H=18.258 | P≈7.109 的判断 |
|---|---:|---:|---:|---:|---:|---|
| R288，最新同批 native | 1.775 | 1 | 1.775 | −3.225 | −16.483 | 即使H=0也不行；停止 |
| position379，原 operation | 1.315 | 22 | 28.935 | −81.065 | 0.485 | 单operation replay不行 |
| R490，整个区间 | 18.865 | 2 | 37.731 | 27.731 | 9.736 | 一次融合replay账面可行；未验证 |
| R485，整个区间 | 17.671 | 2 | 35.342 | 25.342 | 8.542 | 同上 |
| R480，整个区间 | 16.891 | 2 | 33.783 | 23.783 | 7.763 | 余量很小 |
| R475，整个区间 | 15.211 | 2 | 30.421 | 20.421 | 6.082 | 当前量级不行；不扩展 |
| R3，整个区间 | 23.876 | 1 | 23.876 | 18.876 | 5.619 | 需低于约5µs；op口径仅允许2.213µs |
| R457，整个区间 | 8.862 | 2 | 17.724 | 7.724 | −0.267 | baseline本身已超预算 |

R490 包含 15 个 native operation，若逐个使用 7.109 µs replay，单 probe 仅 replay 就要约 **106.636 µs**，远超整个区间 18.865 µs。表中可行性只适用于**整个区间一次融合处理**。不能假设 15 个 operation 的查询、字段保护与副作用能以一个 R288 的成本处理。

若要求每个长区间 `P<2/5/10 µs`，各自允许的 baseline 成本已在完整表逐项列出；并非只给一个统一的 7 µs 门槛。所有单 operation 的原测量均值都低于 2 µs，甚至 `<2 µs` 本身也不足以证明它们盈利。

## 4. 按真正的函数成本选择方法

以下 exclusive 时间来自函数模式，只作排名，不与 operation 模式相加。`state_valve` exclusive 包括未插桩的数学函数和包装等，**不是已经单独测出的纯数值尾部成本**。

| 函数 / 工作 | 调用数 | exclusive ms | 平均 exclusive µs | 建议 |
|---|---:|---:|---:|---|
| state_valve | 495,790 | 388.070 | 0.783 | E：先测数值尾部；保留所有context访问 |
| property_pt | 1,225,458 | 114.822 | 0.094 | F：若未来优化查找，必须保持有序first-match；不能承担µs级额外guard |
| local_isentropic | 989,704 | 92.872 | 0.094 | 现有valid命中已跳过部分计算；需先分开hit与真实重算，不能整体memo掉observe/valid写入 |
| native_jacobian_scalar_get | 1,439,304 | 62.124 | 0.043 | 既有memo查询成本；避免再叠通用查表/完整key解释器 |
| property_density | 1,399,544 | 52.772 | 0.038 | 主要是cache/memo路径，保持原机制 |
| native_pipe_flow_context | 379,904 | 50.607 | 0.133 | inclusive约601.523ms包含下游；不能再加到state_valve |
| native_temperature_ph_context | 320,836 | 43.470 | 0.135 | 查询/包装仍发生，实际PH反算为0 |
| native_viscosity | 307,709 | 25.702 | 0.084 | A；单独加memo通常预算太小，尚无盈利证据 |
| native_medium_orifice_context | 125,440 | 17.183 | 0.137 | 包装本身廉价，关注其state_valve数学部分 |
| native_pipe_flow_cached_context | 379,904 | 16.638 | 0.044 | 保留pipe语义；不要为省wrapper引入replay |

`native_temperature_ph`、`native_density`、`native_pipe_resistance` 在这批 fallback 中实际执行次数都为 **0**。它们的昂贵求解已被 Jacobian memo 覆盖，不能再次把这些计算算成新优化的可省部分。

源码依据：归档 [properties.c](../../test/local-probe-20260917/worker/properties.c) 中 `state_valve` 先执行 `isentropic` 与 `property_density`，之后才进行 `pow/sqrt/log/tanh` 等数学计算；[orifice.c](../../test/local-probe-20260917/worker/orifice.c) 的 PNVO 调用链还会获取 PH/PT、更新context并进行有限性返回检查。整个 `state_valve` 并不是无副作用的纯函数。

### A–F 明确决策

| 类型 | 适用对象 | 决策 |
|---|---|---|
| A 直接原计算 | R288/position16；所有当前需要约7µs replay的单operation；廉价lookup/viscosity/alias | 停止逐operation semantic replay；默认重算 |
| B 原whole-context restore | 现有guard成功的20,608次context复用 | 保留原guard与restore；不扩大到guard失败路径 |
| C 切分interval | 196个完全不含native的连续段；例R457 [297,379) | 只考虑批量段和低成本输出恢复；不逐alias加guard |
| D 局部context replay | R490/R485/R480的融合区间是假设候选 | 仅预算保留；没有全区间读写契约，也无足够实测收益，暂不实施 |
| E 昂贵纯数值kernel memo | 首选position379中的state_valve数值尾部 | 下一次唯一建议实验；先测小于µs的真实成本与key复用 |
| F 更便宜方案 | property_pt有序查询、现有memo定位、静态代数段恢复 | 先证明确有热点且额外成本在几十至数百ns预算内；不作为本次扩展任务 |

B 的全部成功区间为 R0、R135、R378、R454、R459、R464、R469、R474、R479、R484、R489、R494。只沿用已经满足原 guard 的 group/interval 对，不由区间ID推导新的复用范围。

## 5. 候选排序：只推荐启动一个

### 第一名：position379 / PNVO001_1 的 state_valve 数值尾部

- 当前完整 operation 为 **1.315 µs/次**，19,712 次，累计 **25.926 ms**。三轮累计 25.631–26.268 ms。组为 0–5、10–25，共22组。完整 group→interval 映射在JSON中。
- 主要工作是 `native_medium_orifice_context → medium_valve → state_valve`。保留 PH/PT、等熵字段计算/valid写入、density读取及所有context副作用，**只考虑在这些步骤之后**复用数学尾部的 `cm/velocity`。
- 为什么优于 R288 replay：不是因为单次 operation 更贵，而是换成只比较少量最终数值输入的 kernel 机制，避免有序条目重放；baseline 在结构上最多可摊到22组，而 R288 的目标只有1组。候选还是累计最贵的单个 operation，且数值尾部边界可明确核对。
- **可省上界**：25.926 ms 是整个 operation 零成本消失的宽松上界；数值尾部只占其中一部分，实际可省必须更小。没有该position的尾部独立计时，不能把全局0.783µs当作它的实测尾部成本，更不能承诺25.926ms收益。
- 令尾部实测每次成本为 `K`、memo probe成本为 `G`、baseline新增为 `H`，全部22组可命中时必须满足 `G + H/22 < K < 1.315 µs`。一轮净收益是 `19712×(K−G)−896×H` µs；命中不足时另扣miss开销。
- 初始工程目标可设 `G≤0.25 µs`、`H≤1 µs/J`，其成本门槛约 **0.295 µs/命中**；这是待测目标，不是已有实现速度。若尾部K≤该值或实际开销不达标，则停止。若仍沿用18.258µs的baseline新增，则仅H/22就要0.830µs，很可能再次失败。

**下一次实验的边界**：仍用独立 worker，只选这个 position；先采集数学尾部的实际输入位与成本，确认同一Jacobian跨组key重复比例，再实现可拒绝的最小kernel memo。候选key应依据尾部真实使用的 `p/T/pd/g/rho` 等值确定，不拿operation显式输入相同代替。必须核对分支、非有限值、errno/浮点状态、memo生命周期；数学库也可能有副作用，不能默认忽略。

数值尾部不再触碰property context有利于验证，但不是免验。要求所有矩阵、求解输出、context/pipe/memo、warning和计数逐位一致；成本版无shadow。测量命中/拒绝、尾部原成本、key检查、命中返回和baseline新增成本，只有完整机制净收益为正才考虑其他position。**本轮没有实施这个实验。**

### 第二名（备选，不立即启动）：R457 的纯代数连续段

R457/group10,11 整体 8.862µs、15.880ms；主要native仍是4个节流口。真正切分对象为 **[297,379)** 的82个纯代数operation，平均段成本 **1.846µs**，1,792次合计 **3.308ms**。这里不省任何native物理计算，保留全部context操作，可验证性较高。

选择C而非D：每段额外guard/restore加baseline摊销必须 `<1.846µs`，实际应显著低于1µs以留下余量。由于82个短语句分别计时，3.308ms可能含明显marker成本，先用段级低扰动测量核实；不能把该数字当作可兑现收益。全部代数段都低于2µs，逐条加机制会失败。它比R288 replay更简单，但单点总上界较小，排在kernel之后。

### 第三名（预算备选，暂不做）：R490 的融合局部context机制

R490/group24,25 整体 **18.865µs**，1,792次 **33.807ms**；其中15个native语句，主要是pipe flow、state_valve及查询。两个组可结构共享一次baseline，预算明显比R288宽。

若H仍为18.258µs，**全部验证、所有patch和commit合计必须低于9.736µs/整个interval**；要有可靠余量，目标至少应低于5µs。若P=7.109、100%成功且两组共享记录，账面仅剩约 **4.708ms**，尚未扣完整路径额外开销。未知读写覆盖、15个native的effects以及guard扩张很容易用完预算，因此不建议现在开始完整semantic实现。

相比之下，先把state_valve里的数学部分分离，能检验是否存在更低成本方法，再决定是否需要复杂的融合局部context。R485/R480也是同类预算备选，不扩展实现。

## 6. 还剩多少空间：条件上界，不是加速承诺

### 以完整interval只付一次开销的乐观情景

每行只统计满足预算的interval，并扣除该行假设的P/H；各行是不同情景，不能相加。H每个Jacobian捕获一次并跨所有失败组共享，100%接受，无新增失败开销。跨批typed数字只用作量级参照。

| 假设每interval的P / baseline H，µs | 过预算interval数 | 涉及原fallback ms | 占原区间fallback | 情景剩余净空间 ms |
|---|---:|---:|---:|---:|
| 2 / 0 | 72 | 613.980 | 89.94% | 438.364 |
| 5 / 0 | 35 | 496.359 | 72.71% | 249.959 |
| 7.109 / 0 | 24 | 415.138 | 60.81% | 160.350 |
| 10 / 0 | 13 | 284.669 | 41.70% | 96.509 |
| 2 / 18.258 | 9 | 235.564 | 34.51% | 57.870 |
| 5 / 18.258 | 6 | 169.775 | 24.87% | 22.341 |
| 7.109 / 18.258 | 3 | 95.742 | 14.03% | 8.448 |
| 10 / 18.258 | 0 | 0 | 0% | 0 |

因此，“高成本interval占60.81%”只对应零baseline、整个interval固定7.109µs的理想条件。计入当前baseline量级后缩到14.03%，而这14.03%也只是**原计算覆盖量**，扣成本后仅8.448ms。三个区间在独立operation模式下也过相同账面门槛，但仍未证明融合实现可以达到该成本。

若每个group都要独立捕获，H不能被2组摊薄；在P=7.109/H=18.258情景下，所有interval都不再盈利。当前没有任何一个新interval被证明具有实际semantic replay净收益。

### 换方法后的空间

- **单operation semantic replay，维持当前成本量级：可盈利覆盖为0%。** 这不是证明所有更便宜的semantic方法都不可能，只是否定当前这条逐operation路径。
- **native语句工作池：577.486ms，占operation模式87.44%。** 这是55个pipe/orifice语句全部计算的宽松上界，里面有必须保留的context访问和现有memo开销，不能全部归给kernel优化。
- **四个PNVO候选position379/392/405/418：98.575ms的整个operation上界。** 下一次只测379，其25.926ms上界之外不先承诺扩展。kernel尾部占比和实际命中率尚未测出，所以不能给出“已值得优化的kernel占fallback百分比”。
- **纯代数/alias：82.944ms，占operation模式12.56%。** 分布在196个连续段，最大段均值也只有1.846µs。只能考虑少数长段的廉价批量恢复；全量消除的82.944ms是含短语句插桩的宽松上界。
- 全部fallback原工作约 **0.61–0.68s/轨迹** 只是所有相关工作免费消失的极宽上界，不能当成可实现的净节省，也不能由此推算最终solver加速比例。其余Jacobian/积分成本仍然存在。

**方向调整**：R288负收益证明的是低成本operation不适合当前这种replay机制，不是semantic replay原理不可行。眼下数据并未发现单次昂贵的fallback operation；发现的是大量重复的小计算，以及由它们组成的大interval。下一步应验证**低成本的kernel复用能否赚回自己的开销**，而不是继续扩大context重放范围。

## 7. 本轮验证与未确定项

分析脚本重新从三轮原始ticks/frequency/采样数还原interval和operation时间，与原analysis逐项核对；检查全部计数、唯一group/position归属、native分类一致性、代数段和各层汇总守恒。生成的JSON保留输入哈希和检查清单。没有用容差修改仿真结果，也没有新增数值正确性声明。

仍未测量：候选379的数学尾部专属成本与key命中率、长区间融合metadata成本、跨组动态契约共享率、切分后低扰动段成本，以及R49跨模式计时差异的成因。这些缺口决定了目前可以提出可证伪的性能实验，不能宣布新的优化已经盈利。

**最终选择：保留whole-context机制和廉价原计算；停止R288 replay；下一次只做position379的state_valve数值尾部kernel memo成本/正确性实验。**